In message <C7D28955.8E44%[email protected]>
Tony Li writes:
> Hi Dave,
> >> flow - A flow in the context of this document is a aggregate of
> >> traffic for which packets should not be reordered. A flow is
> >> similart to a microflow or ordered aggregate as defined in
> >> [diffserv framework]. The term "flow" is used here for brevity.
> >> This definition of flow should not be interpreted to have broader
> >> scope than this document.
> > Note that Diffserv microflow includes source address, source port,
> > destination address, destination port and protocol id. See scope
> > decision.
> 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
> >> outer and inner LSP - The LSP associated with labels in the outer
> >> encapsulation are called outer LSP. Those LSP which are
> >> associated with inner encapsulation (closer to the label entry
> >> containing the S-bit) are called inner LSP. These are not called
> >> top and bottom LSP since MPLS and PWE draw the label stack in
> >> opposite directions with PWE putting the outermost label on the
> >> bottom of diagrams (and confusing people in doing so).
> > Need to cover case with more than two LSPs. Would using inner LSPs. (For
> > brevity is last sentence necessary?
> How about innermost?
Again see response to Dave.
> >> 1. Aggregated control information which summarizes multiple
> >> parallel links into a single advertisement is required to reduce
> >> information load and improve scaleability.
> > Based upon Tony's comments, I think that the objective is to convey the
> > same information as a set of parallel links with different
> > characteristics more efficiently and in a more scalable manner than
> > making an advertisement for each parallel link. As discussed,
> > summarization (e.g., more than one value for latency) is a specific
> > solution. Comments, other recollections?
> Agreed. Perhaps it would be useful here to again back up and define our
> requirements. How many total components are we willing to advertise from a
> single router? How many routers do we see in a particular IGP area/level?
> Obviously we can't carry additional information in zero bits, but we can
> afford some bits per link if we're willing to carry a larger link state
> database (LSDB). If we can define what we're targeting, then we can do the
> computations to see if everything would fit.
> Note that asking for infinite of everything is by definition not helpful.
> While that precludes carrying things in the IGP, that also effectively
> precludes using crankback as a solution as well, as crankback setup times
> will explode.
> As always, we need to make an intelligent time/space tradeoff.
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
Max BW: 2.5G (nominal)
Max LSP: 0.65G (nominal)
delay: 2 msec (big puddle)
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.
> >> 3. In some more than one set of metrics is needed to accommodate a
> >> mix of capacity with different characteristics, particularly a
> >> bundle where a subset of component links have shorter delay.
> > I would avoid use of metric to avoid confusion with current solutions.
> > Proposed rewording as follows:
> > A means in control and data plane protocols is needed to accomodate a
> > composite link composed of component links with different
> > characteristics, including at least: capacity, current latency,
> > indication of whether latency can change, ... others?
> I don't find 'metric' as ambiguous, as we've dealt with multi-metric based
> IGP's before.
> >> 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.
> > As discussed in the meeting, picking the shortest delay per composite
> > link is one requirement as you state above.
> > We need to add the other service provider requirement described in the
> > meeting where certain LSPs have a latency that is less than a specified
> > end-end value.
> > In my view, these are separate requirements, which may have different
> > solutions.
> And again, this wording seems to imply that we're doing path selection via
> signaling and not routing. How about s/signal/compute/? Same below...
Is RSVP-TE LSP setup signaling? If I change signal to setup in the
above sentence are we OK?
> >> 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.
> 'Nuf for now,
Plenty for now.
rtgwg mailing list