In message <C7D59EC8.901B%[email protected]>
Tony Li writes:
> > 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.
> >> 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).
> Concur, but we seem to be characterizing the requirements around a
> particular approach. I'm trying to avoid doing that.
I'm giving an example in email. There is no indication of such an
approach in the revised text I sent.
Aggregating information in the IGP is still a requirement. It is at
least desireable. I think highly desireable. Specifying more than
one metric is covered. I gave the example of one component per group
if someone really fealt a need to pick the component in the ERO rather
than a group with known characteristics.
> >> 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?
That is definitely one of the choices. Just as is done today.
rtgwg mailing list