[email protected]
[Top] [All Lists]

Re: composite link - candidate for respin, maybe

Subject: Re: composite link - candidate for respin, maybe
From: Tony Li
Date: Sun, 28 Mar 2010 22:38:25 -0700
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.

> 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

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

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


rtgwg mailing list
[email protected]

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