[email protected]
[Top] [All Lists]

Re: composite link - candidate for respin, maybe

Subject: Re: composite link - candidate for respin, maybe
From: Tony Li
Date: Fri, 26 Mar 2010 15:55:01 -0700
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?

>>   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?


>>   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.


>>   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...


>>   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.

'Nuf for now,
Tony


_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

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