[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 21:53:47 -0400
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.

> Tony

rtgwg mailing list
[email protected]

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