[email protected]
[Top] [All Lists]

Re: composite link - candidate for respin, second try

Subject: Re: composite link - candidate for respin, second try
From: Curtis Villamizar
Date: Thu, 01 Apr 2010 02:36:13 -0400
In message <[email protected]>
John E Drake writes:
>  
> > 
> > 
> > > >   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-
> > control-bundle/
> > 
> > 
> > That is not what we are trying to accomplish.
> [JD] 
>  
> 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.
> [JD] 
>  
> What are the additional requirements in this area?  RFC 5150 was
> designed for exactly this situation, although I have always preferred
> LSP hierarchy.


The requirement that is missing is that the movement of the LSP is a
local matter handled by the midpoint LSR and requires no signaling or
notification of the ingress.  That was in the draft prior to the IETF
meeting but is missing here.

I think that is where we have a disconnect.  With stitching I don't
see how the midpoint LSR moves the LSP to another component with
minimal disruption and no signaling from the ingress and no
requirement for notification to the ingress or the downstream LSR.  If
stitching can do that, please explain how.

Curtis
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

<Prev in Thread] Current Thread [Next in Thread>