In message <C7D45297.8F8D%[email protected]>
Tony Li writes:
> Hi Curtis,
> >> 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.
In general that is true. In this case there is a significant tendency
to equate CL flow with diffserv microflow. It might be a necessary
I'll look at it again and try to be more concise.
> > 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
> allocated capacity.
> 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.
What we don't want to do (IMHO) is completely remove aggregation of
the bundle (aka CL) advertisement. If there are a dozen identical
links and four that are differnt there is no need to pick exactly one,
just one from either set, or don't care.
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.
> >>>> 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.
The ingress has to indicate which group of links to use, in the
example, the lower delay group, or the fatter pipe, or don't care.
The ingress decides this in RSVP-TE or in MPLS-TP without a control
plane the management plane provides this information.
If you consider RSVP-TE to be signaling, this is correct. In the
absense of a control plane it is not needed but in the presence of a
control plane it is needed.
> >>>> 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.
OK. So what is your objection? Are you suggesting that we need to
restrict the load balance to look down N labels from the top and no
Good to be working with you again.
rtgwg mailing list