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