[Isis-wg] Ccomments on Draft "Metrics and Resource Classes for TE"

[Alex Zinin]

Don,

My 2c on this (just to make sure it's bitten to death ;) :

We have:

>2. Routing Metrics
>
>   A metric is a weight that is assigned to links in the network to
>   indicate the relative preference of a link during path computation.
>   Usually, metrics are selected so that they allow the computation of
>   paths that meet certain constraints.  Metrics for path selection can
>   be classified using the following two criteria:

I think it would be more correct to say that metric is a characteristic
of a route or a routing table entry, not a link. Link cost, BW, delay, 
etc. are the attributes that are taken into consideration while 
calculating the metric of a path/route, for example, the summary
number of hopes (RIP) or the summary link cost (LS protocols).
So these are the attributes that can be additive/non-additive and
static/dynamic.


>   - Additive/non-additive: This refers to whether or not the path
>     metric is obtained by adding the metric value for all links in the
>     path.  Examples of additive constraints include delay and hop
>     count.  Bandwidth is an example of a non-additive constraint.  On
>     the other hand, it is also possible to look at bandwidth as an
>     additive metric by using link costs that are in inverse proportion
 >    to available bandwidth; in such cases, the shortest path
 >    corresponds to the path with the most bandwidth.

1. When you treat costs in inverse proportion to the BW as
    additive, you effectively minimize the summary serialization
    delay (not including the propogation one) of the path,
    but you do not maximize the bandwidth, i.e., the semantics
    is changed.

2. Consequently, there's no reason to calculate the inverse proportion
    of the *available* bandwidth when you add the costs


>3.1 Multiple traffic engineering (TE) metrics
>
 ...
>   In such systems the metric type chosen is a guide to generating
>   paths and will attempt to minimize the metric subject to the other
>   constraints. There is little overhead for advertising multiple
>   metrics for traffic engineering since only the static metrics need
>   to be propagated.

Why only the static metrics? What about available bandwidth that
changes dynamically as more LSPs are established?

>   4.3 Standardizing resource classes
>
>   It is worthwhile to explore the demand for standardized resource
>   masks.  This will allow requests to propagate seamlessly across
>   areas since the semantics of the bits will have a universal value.
...

>   Bits 0-15: Global use
>
>   Bit 0: satellite
>   Bit 1: terrestrial
>   Bit 2: highest reliability
>   Bit 3: high reliability
>   Bit 4: medium reliability
>   Bit 5: low reliability
>   Bits 6-15: reserved
>
>   Bits 16-32: Local use

I believe you're talking about the RsCls field in LDP's 0x822 TLV.
My opinion is that specific bits should not be assigned to specific
colors/characteristics, instead the bit semantics should be
starndardized. If the semantics is clear, it doesn't really matter
which attribute each bit reflects and the priveledge of meaning
assignment should be left to the admin ([s]he may not care about
the reliability at all if all links are equally reliable, etc.)
Draft "draft-ietf-mpls-cr-ldp-03.txt" does not explicitly specify how
the mask should be used. It may be advantegous to introduce
sub-TLVs in the ResCls-TLV, each containing a kind of op-code
(exact mask match, any bit match, speficied bits cleared, etc.)

Best,
------------------------------------------------------------------
Alex D. Zinin, Consultant
CCSI #98966
CCIE #4015