[email protected]
[Top] [All Lists]

RE: composite link - candidate for respin, second try

Subject: RE: composite link - candidate for respin, second try
From: John E Drake
Date: Thu, 1 Apr 2010 07:35:45 -0700
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, March 31, 2010 11:36 PM
> To: John E Drake
> Cc: [email protected]; [email protected]
> Subject: Re: composite link - candidate for respin, second try
> 
> 
> 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.
[JD] 

One of the primary goals of LSP stitching was to allow the functionality in 
your penultimate paragraph, above.  In stitching, the LSP segment is created 
and then signaling between the segment endpoints is used to bind the e2e LSP to 
it, with no awareness by the e2e LSP endpoints. 
  
> 
> Curtis
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

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