[email protected]
[Top] [All Lists]

Re: composite link - candidate for respin, maybe

Subject: Re: composite link - candidate for respin, maybe
From: Curtis Villamizar
Date: Mon, 29 Mar 2010 22:18:53 -0400
In message <[email protected]>
John E Drake writes:
>  
> Comments inline

John,

Another top posting windoze user?  I'm disappointed.  :-)

> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of
> > Tony Li
> > Sent: Sunday, March 28, 2010 10:38 PM
> > To: [email protected]
> > Cc: [email protected]
> > Subject: Re: composite link - candidate for respin, maybe
> > 
> > 
> > Hi Curtis,
> > 
> > > What we don't want to do (IMHO) is completely remove aggregation of
> > > the bundle (aka CL) advertisement.  If there are a dozen identical
> > > links and four that are differnt there is no need to pick exactly one,
> > > just one from either set, or don't care.
> > 
> > My concern is that down the road, as resources get used, the links will no
> > longer be identical.   Each will have its own unique usage levels.  Global
> > planning and optimization can use this information to determine exactly
> > how
> > many LSPs and at what sizes can fit down the link.
> [JD] 
>  
> Then why bother with link bundling?  This level of control has been
> part of TE since the beginning.  Link bundling was introduced to trade
> information hiding for scalability.


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.

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.


> > > 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.


> > > 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.

The point is to allow a midpoint or pair of midpoints on either end of
a CL to perform such tasks as rearranging LSP to fix a bad bin packing
outcome with minimal changes to the way an LSP is set up.  If the
commitment of the RRO is to use any LSP within a group that has a
specific set of characteristics, and to stay within some parameters
related to anchoring the LSP (not an absolute commitemtn to never move
the LSP but a commitment to move it only within some time limits or
under specific conditions).


> > > Good to be working with you again.
> > 
> > Likewise.  While we have a history of disagreeing, I find it far
> > preferable
> > to disagree intelligently with someone than some of the other discussions
> > that I've been having lately.  ;-)
> > 
> > Tony


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

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