[email protected]
[Top] [All Lists]

RE: composite link - candidate for respin, maybe

Subject: RE: composite link - candidate for respin, maybe
From: "So, Ning"
Date: Mon, 29 Mar 2010 15:09:06 +0000
Tony and Curtis,

Thanks a lot for the great input and comments.  I am trying to take care
of my family and my day job which pays my salary at Verizon first since
I was gone from both last week :)  I will try to catch up on this e-mail
thread later this week and get back to you.  I am slow, but hopefully


Ning So
Lead Engineer
Global Data Network Traffic Planning

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Tony Li
Sent: Monday, March 29, 2010 2:03 AM
To: [email protected]
Cc: [email protected]
Subject: Re: composite link - candidate for respin, maybe

>    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.
> So what I'm saying is you could do that.  I think it is a real bad
> idea, but you could do it.

I think we're miscommunicating.  Rather than have a big ERO, I'm
that this info go into the IGP and that the ERO specify the specific
I'm not so scared about adding to the IGP as we can start by advertising
about 275KB per router without a challenge.

>> I'm fine with that, but we may also want to specify the component in
>> ERO.
> Again, if you specificy the group, and there is only one component in
> the group, then you have that behavior.  There is also the option of
> putting more than one component in the group.  We are getting past
> requirements.  This would be fine fodder for a framework (aliteration
> was unitentional, but amusing nonetheless).

Concur, but we seem to be characterizing the requirements around a
particular approach.  I'm trying to avoid doing that.

>> No, I'm suggesting that we need a bit in the RESV to say that this
>> should be demuxed by inner labels or kept atomic.
> That is in there but whether it is one bit is not defined:
>   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.

Do you meant to imply that there would also be a way to indicate a
preference for diverse placement of a hierarchical LSP?


rtgwg mailing list
[email protected]
rtgwg mailing list
[email protected]

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