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

[Alex Zinin]

Don,

At 14:17 27.10.99 -0500, Don Fedyk wrote:
>Alex
>
>> 
>> >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?
>
>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.
> 

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 ?

>Simply we feel there is a need for multiple metrics, if some of these 
>are dynamic in the future that is not precluded.
>
>> 
>> >   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.
>Yes we should refer to the document, good point. 
>
>> 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.)
>
>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.

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

>
>Thanks,
>Don
>
------------------------------------------------------------------
Alex D. Zinin, Consultant
CCSI #98966
CCIE #4015