[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG last call: draft-ietf-tewg-diff-te-proto-03.txt
Francois,
Since "Max Link Bw" is correct in the CAC formulas, where is
"Max Reservable Bw" used?
Also, I agree with Dimitry's suggested replacement text below
for "Max Reservable Bw," which is more neutral and independent
of BC models. I think the current text in the Proto draft is
slanted towards RDM.
As discussed in
http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00184.html
the current MAM definition in the Requirements draft allows
preemption across CTs. Clarification as described in this
posting can be added to the MAM spec. Thus, there is no
inconsistency in the Requirements draft. We do not need a
new name for an old model.
Thanks, Wai Sum
-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
Sent: Friday, April 25, 2003 9:50 AM
To: Dimitry Haskin; te-wg@ops.ietf.org
Subject: RE: WG last call: draft-ietf-tewg-diff-te-proto-03.txt
Dimitry,
Please check the draft text I proposed in message titled "Reflecting
new-MAM/SAM definition in diff-te drafts" (assuming the enhancement to
MAM definition). This should address your comments on section 5.1.
BTW: any thoughts on the "SAM" name?
Regarding your other comment, I actually think that "Max Link Bw" is
correct in the CAC formulas.
draft-ietf-isis-traffic-xx says:
"This sub-TLV contains the maximum bandwidth that can be used on this
link in this direction (from the system originating the LSP to its
neighbors). This is useful for traffic engineering."
I believe the intent is that one given TE-tunnel can not exceed the max
link Bw. I believe this check is commonly implemented by multiple
implementations. Perhaps the text of draft-ietf-isis-traffic could be
made a little clearer on that. I will mention this to the authors (and
same for OSPF draft).
Also, it wouldn't make much sense to me to check separately that B is
below Max Reservable Bw, since Unreserved Bw will always be smaller than
Max Reservable bw.
Thanks for your review.
Francois
>> -----Original Message-----
>> From: Dimitry Haskin [mailto:dhaskin@axiowave.com]
>> Sent: 11 April 2003 21:05
>> To: 'Jim Boyle'; te-wg@ops.ietf.org
>> Subject: RE: WG last call: draft-ietf-tewg-diff-te-proto-03.txt
>>
>>
>>
>> Section 5.1, page 10:
>>
>> "With DS-TE, the existing "Maximum Reservable Bw" sub-TLV
>> is retained
>> with a generalized semantic so that it MUST now be interpreted as
>> Bandwidth Constraint 0 (BC0)."
>>
>> also Section 5.1, page 10:
>>
>> "A DS-TE LSR which does advertise Bandwidth Constraints, MAY also
>> include the existing "Maximum Reservable Bw" sub-TLV. This may be
>> useful in migration situations where some LSRs in the
>> network are not
>> DS-TE capable (see Appendix C) and thus do not understand the new
>> "Bandwidth Constraints" sub-TLV. In that case, the DS-TE
>> LSR MUST set
>> the value of the "Maximum Reservable Bw" sub-TLV to the
>> same value as
>> the one for BC0 encoded in the "Bandwidth Constraints" sub-TLV.
>>
>> A DS-TE LSR receiving both the old "Maximum Reservable Bw" sub-TLV
>> and the new "Bandwidth Constraints" sub-TLV for a given link MAY
>> ignore the "Maximum Reservable Bw" sub-TLV."
>>
>> The above statements are implying that the "Maximum
>> Reservable Bw" sub-TLV
>> is redundant in the presence of Bandwidth Constraints.
>> Furthermore, they
>> indicate that BC0 has semantics of the maximum reservable
>> bandwidth. This
>> could be true for the RD model. However it is clearly not
>> true for other
>> models. Therefore these statements should be removed from
>> the specification
>> or, even better, replaced with something along the following lines:
>>
>> The "Maximum Reservable Bw" sub-TLV represents the
>> aggregate bandwidth
>> constraint of the link and as such complements the
>> advertised Bandwidth
>> Constraints.
>>
>>
>> Section 10.2, page 20:
>>
>> "A DS-TE LSR MUST support the following admission control rule:
>>
>> Regardless of how the admission control algorithm actually
>> computes
>> the unreserved bandwidth for TE-Class[i] for one of its
>> local link,
>> an LSP of bandwidth B, of set-up preemption priority p and
>> of Class-
>> Type CTc is admissible on that link iff:
>>
>> B <= unreserved bandwidth for TE-Class[i], AND
>> B <= Max Link Bandwidth
>>
>> Where
>>
>> - TE-Class [i] maps to < CTc , p > in the LSR's
>> configured TE-
>> Class mapping
>> - Max Link Bandwidth is the maximum link bandwidth
>> configured
>> on the link and advertised in IGP."
>>
>>
>> "Max Link Bandwidth" should be replaced with "Maximum
>> Reservable Bandwidth".
>>
>>
>> Section 10.3.4, page 22
>>
>> "Regardless of how the admission control algorithm
>> actually computes
>> the unreserved bandwidth for TE-Class[i] for one of its
>> local link,
>> an LSP of bandwidth B, of set-up preemption priority p and
>> of Class-
>> Type CTc is admissible on that link iff:
>>
>> (i) B <= unreserved bandwidth for TE-Class[i], AND
>> (ii) B <= Max Link Bandwidth
>>
>> Where
>>
>> - TE-Class [i] maps to < CTc , p > in the LSR's
>> configured TE-
>> Class mapping
>> - Max Link Bandwidth is the maximum link bandwidth
>> configured
>> on the link and advertised in IGP."
>>
>> "Max Link Bandwidth" should be replaced with "Maximum
>> Reservable Bandwidth".
>>
>>
>> Dimitry
>>
>>
>>
>> > -----Original Message-----
>> > From: Jim Boyle [mailto:jboyle@pdnets.com]
>> > Sent: Monday, April 07, 2003 11:56 PM
>> > To: te-wg@ops.ietf.org
>> > Subject: WG last call: draft-ietf-tewg-diff-te-proto-03.txt
>> >
>> >
>> >
>> > http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-pr
>> > oto-03.txt
>> >
>> > This is WG last call for this draft to be advanced standards track.
>> > Since notice was sent to other WGs for review, we will
>> take 3 weeks.
>> >
>> > Last call for this draft closes 4/28.
>> >
>> > thanks,
>> >
>> > Jim Boyle
>> >
>> >
>> >
>>
>>