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

From: Alex Zinin <[email-masked]>
Date: Tue, 26 Oct 1999 11:47:58 +0300

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

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 27 Oct 1999 14:17:53 -0500

Alex

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 4:48 AM
> To: Fedyk, Don [BL3:2001-I:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: Ccomments on Draft "Metrics and Resource Classes for TE"
> 
> 
> Don,
> 

Thank you. I will consider this for the update of this draft. 

>     of the *available* bandwidth when you add the costs
This section will be re-worded. Unfortunately in the haste to get the 
draft out I was not that very careful with my English. Several people 
have pointed this out. The point was that there is a desire to 
seek the shortest path with the largest bandwidth. 

Available bandwidth used for the metric was again a static. 
In other words, the actual link capacity or speed.

> changes dynamically as more LSPs are established?

It is true that bandwidth allocation is broadcast in the form of 
available bandwidth to allocate at a priority, but this is 
dynamic addition of static numbers.  What I am trying to say is
it is not related to the dynamic utilization number. I can 
lay down a path for 2 Meg and only use it 1 day of the week 
but I want it to be there for me when I use it.
 
Simply we feel there is a need for multiple metrics, if some of these 
are dynamic in the future that is not precluded.

> I believe you're talking about the RsCls field in LDP's 0x822 TLV.
Yes we should refer to the document, good point. 

> (exact mask match, any bit match, speficied bits cleared, etc.)

We agree and that is why we took a stab standardizing it. 
In general we saw many operations but the simple & and compare 
operation seemed most workable.
If you don't have an agreement on bits, you can have two networks 
join with different bits meanings and you cannot interwork them. 
Several of our customers have joined two networks that started out
as separate administrative networks. How do you change the bits 
once set? 

I like your op-code idea, we just didn't think it was simple
enough to standardize.

Thanks,
Don

---

From: Alex Zinin <[email-masked]>
Date: Thu, 28 Oct 1999 21:09:23 +0300

Don,

>but I want it to be there for me when I use it.

I may be missing something, but what is the purpose of establishing
an LSP along a path with some BW value if this value is not guaranteed
to be up to date?
Example---you have two alternate paths---one with BW of 1.5M
and another with BW of 2Ms. You need to establish say 5 LSPs
and the constraint is max BW. If LSPs are established incrementally,
you will have all of them traversing the 2M path, because there
is no info on how much BW has left unreserved/unprovisioned.
On the other side I would understand static Delay attribute calculated
in inverse proportion to the BW, but it's not BW itself.
Am I really missing something ?

>I like your op-code idea, we just didn't think it was simple

I understand your concern about different bit assignment, but
what worries me is that we have only 32bits for the color mask and
the document proposes to define a static meaning to some of
them. One could foresee problems in the nearest future or
in some already installed networks. For example, in a pure
ATM-based network utilizing say well-designed SDH links,
all bits 0 through 5 lose their purpose. We also do not and
cannot know which classes are gonna be needed in the future.

Another concern is how these bits are used----e.g. bits 0 and 1
are mutually exclusive, so we basically need only one to
indicate the state of Satellite/Terrestrial link attribute.
The level of reliability, in turn, can easily be coded in 3 bits
instead of 5 (I remember the concerns on checking and
standardization). 

Now imagine that another draft appears trying to assign
static meaning to bits 6--15 and then some customers
appear that need globally significant bits with absolutely
different meaning....What do you do ? 
You may think of a method of mapping different bit
schemes to each other, maybe....

These are just thoughts yet...

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 29 Oct 1999 17:12:16 -0500

Resent to lists.
----
Alex

> Sent: Thursday, October 28, 1999 2:09 PM
> Cc: [email-masked]; [email-masked]
> Subject: RE: Ccomments on Draft "Metrics and Resource Classes for TE"
> 
> 
> Don,
> 
When you have an accurate bandwidth profile or traffic profile it does 
not add value to maximize bandwidth, as you point out, you really 
want to minimize something else like delay or perhaps hops or cost. 
The allocation takes care of the bandwidth part. If you do not 
have bandwidth profile (or the amount is small) you may want to 
use another criteria to mimimize or a constraint, that does 
attempt to satisfy the your criteria. Both scenarios are possible. 
In some amount of time, the link allocation information 
is distributed (either by the IGP or by the feedback mechanisms 
we are proposing.) 

So if we go to the originating node, the minimized metric has 
not changed but perhaps now you are laying LSPs on the one 
path and you have another path that is equal. As the designer 
of a path selection algorithm you may choose to make it more 
or less elaborate. The choice is one of load sharing versus 
leaving bandwidth for large connections. It also depends on how 
fast you lay down LSPs. Under failure conditions elabortate 
algorithms may not be accurate. Under long term conditions 
offline traffic engineering may prove more fruitful. 

As far as the LSP goes the bandwidth allocation numbers should 
be accurate in the long run if the traffic class competes for 
scheduling resources.  Best effort LSPs do not (well they are on 
the lowest runge anyways) . This is no different than 
ATM where a service class results in a connection admission
 of a certain BW size.  There are several drafts that 
talk about changing LSP reservation to match the actual 
or even setting up a new path and hot swapping. All these 
things make the world more dynamic and accurate.

> These are just thoughts yet...

Points taken.

Don