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_01BF225A.ADDA4B4E Content-Type: text/plain; charset="iso-8859-1" Resent to lists. ---- Alex > -----Original Message----- > From: Alex Zinin [mailto:zinin@amt.ru] > Sent: Thursday, October 28, 1999 2:09 PM > To: Fedyk, Don [BL3:2001-I:EXCH] > Cc: te-wg@UU.NET; isis-wg@external.juniper.net > Subject: RE: Ccomments on Draft "Metrics and Resource Classes for TE" > > > 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 ? > 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. > >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... Points taken. Don > > > > >Thanks, > >Don > > > ------------------------------------------------------------------ > Alex D. Zinin, Consultant > CCSI #98966 > CCIE #4015 > > ------_=_NextPart_001_01BF225A.ADDA4B4E Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">FW: Ccomments on Draft "Metrics and Resource Classes for TE" Resent to lists.
----
Alex> -----Original Message-----
> From: Alex Zinin [mailto:zinin@amt.ru]
> Sent: Thursday, October 28, 1999 2:09 PM
> To: Fedyk, Don [BL3:2001-I:EXCH]
> Cc: te-wg@UU.NET; isis-wg@external.juniper.net
> Subject: RE: Ccomments on Draft "Metrics and Resource Classes for TE"
>
>
> 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 ?
>
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.> >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...Points taken.
Don
------_=_NextPart_001_01BF225A.ADDA4B4E--
>
> >
> >Thanks,
> >Don
> >
> ------------------------------------------------------------------
> Alex D. Zinin, Consultant
> CCSI #98966
> CCIE #4015
>
>