[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 02:49:38 -0400
In message <C7D58AE1.8FE9%[email protected]>
Tony Li writes:
>  
>  
> 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.


My response included the following:

   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.

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

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

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

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.

It doesn't specify "a bit".  I think this would be in the PATH (from
ingress) and maybe in the ERO if at some hops the load split options
were unacceptable but at other hops a suitable method was found.
Anyway that is beyond the requirments stage.

We can rearrange for clarity if we have general agreement on content.
If this were combined with the other LSP parameters it might be more
clear.

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

I've been told that we generally disagree in a very entertaining
fashion.  That has to count for something.  :-)  [what I don't know]

Regards,

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

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