[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Reflecting new-MAM/SAM definition in diff-te drafts
Francois,
I have some major concerns about your proposed MAM/SAM direction. I don't think we want to introduce all this increased complexity in the BC models. We can resolve the issues raised in recent discussions much more easily:
1. The MAM definition can be clarified in the current MAM specification draft to address the possible ambiguity in the DSTE requirements draft. The DSTE requirements draft doesn't serve to be the defining I-D for any of the BC models, that's the purpose of the functional specifications of the various BC models.
2. Regarding the allowance of cross-CT preemption in MAM, it should be allowed (as several have assumed/interpreted), and that point should be clarified in the MAM specification draft.
3. The 'maximum link bandwidth' parameter is a physical constraint and serves to limit the assignable sum of link bandwidth across class types. In the recent discussion, this constraint has sometimes been referred to as an 'implicit max link BW constraint'. However there is nothing 'implicit' about this constraint/parameter, it is an existing link parameter and a physical constraint on assignable link bandwidth.
4. Given comment #3, we don't need to use the 'max reservable link bandwidth' parameter instead of the 'maximum link bandwidth' parameter, as you have proposed.
Other related comments:
1. We definitely don't want to further extend ospf/isis to advertise more bandwidth constraints, as you stated in your email on 3/25/03:
"Where MAM currently has a Maximum Number of Bandwidth Constraints of 8 (i.e. one per CT), this model would have a maximum of 9 BCs (i.e. one per CT plus one aggregate). BTW, this in turn, would require change to the ISIS/OSPF extensions which can only advertise 8 Bandwidth Constraints."
Further complexity in ospf/isis lsa advertisements is unacceptable.
2. There is no need to add another BW constraint model (SAM), as you have proposed, to serve as an 'enhanced MAM'. The point is to clarify MAM as stated above, which in fact has the same functionality you propose for SAM, we only need to make the clarifications in the MAM functional specification I-D.
Once again, we don't want to introduce all this additional complexity. All we need to do at this point is to make some clarifications in the MAM functional specification I-D.
Thanks,
Jerry
-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
Sent: Wednesday, April 23, 2003 5:26 AM
To: te-wg@ops.ietf.org
Subject: Reflecting new-MAM/SAM definition in diff-te drafts
Hello,
Assuming there is agreement to add the enhancement to the current MAM
definition, below is a first cut at the main changes that would result
in the diff-te drafts.
Could you check these out?
Thanks
Francois
MAM/SAM draft - Definition
===========================
The "newMAM/SAM" definition could look like this:
o Maximum Number of Bandwidth Constraints (MaxBC)=
Maximum Number of Class-Types (MaxCT) + 1 = 9
(where one of the bandwidth constraints is the "Max reservable
Bandwidth")
o for each value of b in the range 0 <= b <= 7:
Reserved (CTb) <= BCb,
o SUM (Reserved (CTc)) <= Max Reservable Bandwidth,
for all "c" in the range 0 <= c <= (MaxCT-1)
Illustration diagram would look like:
I------------------------------------------------------------I
I--------------II-------------II-------------I I
I CT2 II CT1 II CT0 I CT2+CT1+CT0 I
I--------------II-------------II-------------I I
I------------------------------------------------------------I
<-----BC2------><-----BC1-----><-----BC0----->
<------------------------Max Reservable Bandwidth------------>
MAM/SAM draft - Formulas for computing Unreserved bandwidth
============================================================
The example formulas for computing Unreeserved Bandwidth would be
changed to:
"Unreserved TE-Class [i]" =
MIN [
[ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p ,
[Max Reservable Bandwidth - SUM ( Reserved (CTb,q) ) ] for q
<= p and 0 <= b <= 7,
]
RDM draft - Definition
===========================
The RDM definition could be slightly updated (to clarify relationship to
Max Res Bw which is differnet to new-MAM/SAM) like this:
o Maximum Number of Bandwidth Constraints (MaxBC)= Maximum
Number of Class-Types (MaxCT) = 8
(where BC0 is the "Max reservable Bandwidth")
o for each value of b in the range 0 <= b <= (MaxCT - 1):
SUM (Reserved (CTc)) <= BCb,
for all "c" in the range b <= c <= (MaxCT - 1)
Illustration diagram becomes:
I------------------------------------------------------I
I-------------------------------I I
I--------------I I I
I CT2 I CT2+CT1 I CT2+CT1+CT0 I
I--------------I I I
I-------------------------------I I
I------------------------------------------------------I
I-----BC2------>
I----------------------BC1------>
I-------------------------BC0 = Max Reservable Bw------>
Protocol draft "4.1.1. Bandwidth Constraints (BCs)"
==============================================
For DS-TE, the existing "Maximum Reservable link bandwidth" parameter
is retained and its semantic is generalized as the aggregate bandwidth
constraints across all Class-Types. So that, independently of the
Bandwidth
Constraint Model in use, :
SUM (Reserved (CTc)) <= Max Reservable Bandwidth,
for all "c" in the range 0 <= c <= (MaxCT-1).
Additionally, on every link, a DS-TE implementation MUST provide for
configuration of up to 8 additional link parameters which are the
eight other potential Bandwidth Constraints i.e. BC0, BC1 , ... BC7.
The LSR MUST interpret these Bandwidth Constraints in accordance with
the supported Bandwidth Constraint Model (i.e. what bandwidth
constraint applies to what Class-Type and how).
Where the Bandwidth Constraint Model imposes some relationship among
the values to be configured for these Bandwidth Constraints, the LSR
MUST enforce those at configuration time. For example, when the
"Russian Doll" Bandwidth Constraints Model is used (See [DSTE-
RUSSIAN]), the LSR must ensure that BCi is configured smaller or
equal to BCj, where i is greater than j, and that BC0 is equal
to the Max Reservable Link Bandwidth.
As another example, when the "Separate and Aggregate constraint Model"
is used
(See [DSTE-SAM]), the LSR must ensure that all BCi are configured
smaller or
equal to the Maximum Reservable Bandwidth.
Protocol draft "5.1. Bandwidth Constraints "
============================================
(this should also address some of Dimitry's Last Call comments on -proto
draft).
As detailed above in section 4.1.1, up to 8 Bandwidth Constraints
( BCb, 0 <= b <= 7) are configurable on any given link.
With DS-TE, the existing "Maximum Reservable Bw" sub-TLV is retained
with a generalized semantic so that it MUST now be interpreted as
the aggregate bandwidth constraint across all Class-Types, independently
of the Bandwidth Constraints Model.
This document also defines the following new optional sub-TLV to
advertise the eight potential Bandwidth Constraints (BC0 to BC7):
"Bandwidth Constraints" sub-TLV:
Bla, bla, bla : unchanged
A DS-TE LSR MAY optionally advertise Bandwidth Constraints.
A DS-TE LSR which does advertise Bandwidth Constraints MUST use the
"Maximum Reservable Bw" sub-TLV and the new "Bandwidth Constraints"
sub-TLV to do so. For example,
considering the case where a Service Provider deploys DS-TE with TE-
classes associated with CT0 and CT1 only, and where the Bandwidth
Constraints model is such that only BC0 and BC1 are relevant to CT0
and CT1: a DS-TE LSR which does advertise Bandwidth Constraint would
include the "Max Reservable Bw" sub-TLV and the "Bandwidth Constraints"
sub-TLV in the IGP advertisement
and the latter should contain only BC0 and BC1.
Note that including the existing "Maximum Reservable Bw" sub-TLV when
advertising Bandwidth Constraints is
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.
Rest of section is unchanged.
RDM draft - handling advertisement of both "Max Res bw" and BC0
===============================================================
Some of the text that usd to be in proto needs to be moved (somewhere)
into Russian draft, as it is now specific to RDM. This text relates to
behaviour when receiving in IGP advertisment both a "Max Res Bw" and
BC0. It could read :
[DSTE-PROTO] states that
"A DS-TE LSR which does advertise Bandwidth Constraints MUST use the
"Maximum Reservable Bw" sub-TLV and the new "Bandwidth Constraints"
sub-TLV to do so. "
With RDM, BC0 is the Maximum Reservable Bandwidth. A DS-TE LSR receiving
both the
old "Maximum Reservable Bw" sub-TLV and the new "Bandwidth Constraints"
sub-TLV for
a given link where the RDM model is used, MAY ignore the "Maximum
Reservable Bw" sub-TLV.