> > > 5. LSP signaling is needed to indicate a preference for placement
> > > on a single component link and to specifically forbid spreading
> > > that LSP over multiple component links based on flow
> > > identification beyond the outermost label entry.
> > [JD]
> > See http://datatracker.ietf.org/doc/draft-ietf-mpls-explicit-resource-
> That is not what we are trying to accomplish.
As I indicated in my previous e-mail, either your problem statement or your
understanding of the I-D is incorrect.
> > > [CV] Awaiting concensus. What I had in mind was two choices, outer
> > > only or all. Do others think we need to specify looking some fixed
> > > depth into the stack for the hash for a given LSP? If so we need to
> > > discuss possible forwarding speed consequences (hash and lookup can't
> > > be done in parallel with hash disposed of if not needed).
> > >
> > > 6. A means to support non-disruptive reallocation of an existing
> > > LSP to another component link is needed.
> > [JD]
> > If an LSP is assigned to a specific component link, RFC 5150
> > (http://datatracker.ietf.org/doc/rfc5150/) (a one hop LSP on the
> > assigned component link) and MBB can be used to move the LSP
> > non-disruptively to another component link.
> The requirements document does not specify solutuions. If the WG may
> pick that solution or they may pick another solution if another
> solution better meets the full set of the requirements.
What are the additional requirements in this area? RFC 5150 was designed for
exactly this situation, although I have always preferred LSP hierarchy.
rtgwg mailing list