[email protected]
[Top] [All Lists]

RE: composite link - candidate for respin, maybe

Subject: RE: composite link - candidate for respin, maybe
From: John E Drake
Date: Tue, 30 Mar 2010 08:05:53 -0700
> 
> You are missing a few things.
> 
> One is the abilit to move LSP from one component to another.  In
> Tony's view that would not be possible because the LSP is nailed to
> one component, not a group with common attributes and a specification
> of maximum dynamic.
[JD] 

Moving a section of an LSP from one path to another does not require link 
bundling.

> 
> Another is the ability to allow an LSP to be load split across a set
> of components.  The top LSP may (if signaling indicates this is OK) be
> split among component links.  This is the only way to support LSP of
> greater than 100G in the near future.
[JD] 

The discussion was about IGP scaling.  Both examples you describe deal with 
signaling and could be decoupled from any IGP enhancements that are made.

> 
> 
> > > > If we don't put a bound on the number of sets, in the limit each
> > > > component could be advertised with the added semantic that there is
> a
> > > > sharing option.  In that case the LSP may need to specify the set of
> > > > "groups" (as I have it above in the absense of a term) that are
> > > > acceptable.  This could make for a very big ERO.  It should be
> > > > adequate to indicate in the RRO that the bundle is being used with a
> > > > field indicating which member was currently in use (if nailed in
> > > > place).  This is beyond requirements, so if we are OK with the
> stated
> > > > requirement, let defer the details to later.
> > >
> > > I'm fine with that, but we may also want to specify the component in
> the
> > > ERO.
> > [JD]
> >
> > See
> > http://datatracker.ietf.org/doc/draft-ietf-mpls-explicit-resource-
> control-bundle/
> 
> 
> The functionality I mentioned above is missing.
[JD] 

Then you need to re-phrase your requirement (or re-read the I-D)

> 
> 
> > > > OK.  So what is your objection?  Are you suggesting that we need to
> > > > restrict the load balance to look down N labels from the top and no
> > > > further?
> > >
> > > No, I'm suggesting that we need a bit in the RESV to say that this LSP
> > > should be demuxed by inner labels or kept atomic.
> > [JD]
> >
> > In current link bundling an LSP is either assigned to a specific
> > component link or split across all of the component links.  In
> > the latter case this effectively means all or a subset of the
> > component links.
> >
> > 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
> 
> 
> Creating every LSP by stitching one hop LSPs together is a very poor
> solution IMO.  The requirement though do not specify a solution.
[JD] 

It depends upon how many LSPs need this behavior.  LSP Hierarchy would also 
work.  So the requirement needs to be more precise.

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

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