>> I think that where we're getting in trouble here is the analogy to Diffserv.
>> I'm not certain that Curtis intended to invoke all of the differentiators
>> here that you're objecting to. Could we simply drop the analogy and delete
>> the second and third sentences?
> Let me know if the modified version in the
Saw that. I can live with it, but would prefer more brevity. The inverse
definition (this is not XYZ ...) holds little value for me.
> What I had was an item #1 which was to retain aggregation of
> information and iten #3 was to partially deaggregate.
> For example, if there is a microwave link on mountaintops across a
> body of water woth 4 x OC12 (0.65) at a shorter delay and a fiber path
> with longer delay but 12 x 10G, then the advertisement could have a
> set of link bundle like TLVs on the link advertisement with:
> Max BW: 122.5G
> Bax LSP: 10G
> Group 1:
> Max BW: 2.5G (nominal)
> Max LSP: 0.65G (nominal)
> delay: 2 msec (big puddle)
> Group 2:
> Max BW: 120G
> Max LSP: 10G
> delay: 5 msec
> load balance: full stack to N=8
> Maybe not the best example, but the point is the first two would be
> for backward compatibility with link bundle and the rest would be for
> the more enlightenned ingress LER.
Or, we go down the path of advertising vectors of more explicit information
on a per-component basis. This may be necessary when we start talking about
It also occurs to me that we need to resolve whether or not our goals
include the capability of doing globally optimal calculations. To do so
requires that we be able to do centralized computations and establish paths
down to the component level.
>>>> 4. A mechansism is needed to signal an LSP such that a component
>>>> link with specific characteristics are chosen, if a preference
>>>> exists. For example, the shortest delay may be required for
>>>> some LSP, but not required for others.
> Is RSVP-TE LSP setup signaling? If I change signal to setup in the
> above sentence are we OK?
Yes, I consider RSVP-TE LSP setup to be signaling. No, changing this to
setup doesn't work for me. Again, are we fulfilling the requirements at
path computation time or setup time? At this point, I don't think we want
to bind to one approach.
>>>> 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.
>>> Need to clarify whether this applies to outer LSP and/or Inner LSP(s).
>> I think the point here was that we should provide a knob. I concur.
> My response to Dave was the we should specify only one of two options.
> Either use the outer labels (usually means just top unless a POP
> occurs) and don't load balance the LSP or use the whole label stack
> and spread the traffic.
> We could also defer discussion of the shape of the knob to later.
I don't see that we're going to be able to pick and choose here. Some
networks will not need diversity for their LSPs. Others will require it. I
think we have to be more granular.
rtgwg mailing list