[email protected]
[Top] [All Lists]

RE: composite link - candidate for respin, maybe

Subject: RE: composite link - candidate for respin, maybe
From: "Mcdysan, David E"
Date: Mon, 29 Mar 2010 14:22:38 -0400
Comments in linbe below.


> -----Original Message-----
> From: Tony Li [mailto:[email protected]] 
> Sent: Monday, March 29, 2010 3:03 AM
> To: [email protected]
> Cc: Mcdysan, David E; [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 suggesting that this info go into the IGP and that the 
> ERO specify the specific member.
> I'm not so scared about adding to the IGP as we can start by 
> advertising about 275KB per router without a challenge.

This is how I had interpreted Tony's comment at the mike. If all of the
"useful" characateristics component links are carried in the composite
link advertisement, then optimization can be done on a specified metric
(e.g., IGP "cost", TE-metric, or a "latency" related metric), then SPF
can be done at the source subject to constraints. For example, if
"latency" and available capacity is advertised, then a solution to
requirement 10 that Curtis wanted to make out of scope seems like a
straightforward extension, without using crankback signaling. 

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

I think this is a valid construct. Propose that the definition of
composite link allow one or more component links. 

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 
> >> 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.
> Do you meant to imply that there would also be a way to 
> indicate a preference for diverse placement of a hierarchical LSP?
> Tony
rtgwg mailing list
[email protected]

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