This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF20AF.FB8BBB2C Content-Type: text/plain; charset="iso-8859-1" Alex > -----Original Message----- > From: Alex Zinin [mailto:zinin@amt.ru] > Sent: Tuesday, October 26, 1999 4:48 AM > To: Fedyk, Don [BL3:2001-I:EXCH] > Cc: te-wg@uu.net; isis-wg@external.juniper.net > Subject: Ccomments on Draft "Metrics and Resource Classes for TE" > > > 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. Thank you. I will consider this for the update of this draft. > > - 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 > 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. > > >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. 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. Thanks, Don > > Best, > ------------------------------------------------------------------ > Alex D. Zinin, Consultant > CCSI #98966 > CCIE #4015 > > ------_=_NextPart_001_01BF20AF.FB8BBB2C Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">RE: Ccomments on Draft "Metrics and Resource Classes for TE" Alex
> -----Original Message-----
> From: Alex Zinin [mailto:zinin@amt.ru]
> Sent: Tuesday, October 26, 1999 4:48 AM
> To: Fedyk, Don [BL3:2001-I:EXCH]
> Cc: te-wg@uu.net; isis-wg@external.juniper.net
> Subject: Ccomments on Draft "Metrics and Resource Classes for TE"
>
>
> 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.Thank you. I will consider this for the update of this draft.
> > - 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
>
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.>
> >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.
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.Thanks,
Don>
------_=_NextPart_001_01BF20AF.FB8BBB2C--
> Best,
> ------------------------------------------------------------------
> Alex D. Zinin, Consultant
> CCSI #98966
> CCIE #4015
>
>