[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues in draft-ietf-tewg-diff-te-reqts-02.txt
Waisum, Jim, and all,
At 11:46 04/12/2001 -0500, Jim Boyle wrote:
>My $.02 inline.
My Euro .02 in line:
>regards,
>
>Jim
>
>
>On Tue, 27 Nov 2001, Lai, Wai S (Waisum), ALSVC wrote:
>
> > During the preparation of DS-TE Requirements
> > <draft-ietf-tewg-diff-te-reqts-02.txt>, some issues needed further
> > discussion and hence were not incorporated into the text. To facilitate
> > more discussion, they are listed below.
> >
> > Please comment on the issues. If there are no objections raised, we
> suggest
> > that the changes be incorporated into the next update of the above I-D.
> >
> > Thanks, Wai Sum and Jerry.
> >
> > Issue 1: CT definition
> > ----------------------
> > In Section 3.2, Class-Type (CT) is defined as
> > "the set of Traffic Trunks which share the exact same Bandwidth Constraint,
> > or set of Bandwidth Constraints, on all links, for the purpose of
> Constraint
> > Based Routing and Admission Control."
> >
> > The above definition is technically incorrect. A given LSP instance
> has the
> > same bandwidth "on all links," but a class type cannot have the same
> > constraints "on all links," as exemplified by Scenario 2. A workable
> > definition is provided below.
>
>Diffserv is by definition hop by hop, but I see no need to limit CTs as
>such. I think the existing text is fine. A certain CT, in my view,
>consist of all the resources in a network available to the CT, and all
>of the LSPs that call upon those resources.
I agree with Jim that current text is fine.
In any case, the text should convey that the traffic trunks of a given CT
share Bandwidth Constraints throughout the network. In case Waisum's
concern is that the text above may be misleading by suggesting that the
actual value of the constraint should be the same on every link, we can
rephrase to:
"the set of Traffic Trunks which, on all links, share the exact same
Bandwidth Constraint,
or set of Bandwidth Constraints configured on that link for the purpose of
Constraint Based Routing and Admission Control."
Does that work for you?
> >
> > Class Type (CT): the set of Traffic Trunks crossing a link that is governed
> > by a specific set of bandwidth constraints and whose packets receive either
> > the same or closely related DiffServ forwarding treatment. CT is used for
> > purposes of link bandwidth allocation, constraint based routing, and
> > admission control.
> >
> > Issue 2: Split EF
> > -----------------
> > Also in Section 3.2, another example can be added as follows:
> >
> > A network operator may split the EF traffic into two different sets of
> > traffic trunks, so that one set of traffic trunks is given higher priority
> > access to bandwidth than the other set, to satisfy some QoS objectives. In
> > this case, two distinct CTs are defined: one for the EF traffic with high
> > priority, the other for EF traffic with normal priority.
> >
> > (This example of split-EF traffic was already discussed within the author
> > team and no objections were raised.)
>
>This falls into the category of "Does one CT correspond to one and only
>one OA", or stated another way "Are we interested in tying DSTE lock-step
>to Diffserv, or is it something more flexible"
>
>Several have expressed a desire to make it more general, along the lines
>of what CT is refered to in the principles draft. I agree, and think the
>above scenario is a valid way that a carrier might want to have two TE
>"classes" which are tangible and distinct, but both of which are one OA.
>You are right that we need to generalize CTs.
I am fine with the idea of providing an additional example to illustrate
the generality of the CT definition.
I do have one problem with the above text because I think the 2nd sentence
is not the most natural way to solve the need described in the first sentence.
If SP wants to split EF into two sets for the purpose of giving each a
different priority in how they access bandwidth, then I think the most
natural way to do this is to use two different preemption levels in the
same CT.
I would thus propose a slightly modified text:
"A network operator may split the EF traffic into two different sets of
traffic trunks, so that each set of traffic trunks is subject to different
constraints on the bandwidth it can access. In this case, two distinct CTs
are defined: one for the EF traffic subject to the first (set of) bandwidth
constraint(s), the other for the EF traffic subject to the second (set of)
bandwidth constraint(s)."
> >
> > Issue 3: Max number of BW constraints
> > -------------------------------------
> > It is proposed to add the following requirement in Section 3.3.
> >
> > By definition of CT, each CT is assigned either a Bandwidth Constraint,
> or a
> > set of Bandwidth Constraints. Since there is a maximum of 8 CTs, there is
> > correspondingly a maximum of 8 sets of Bandwidth Constraints. That is,
> > maxCT = maxBC = 8, for IGP advertisement purposes.
> >
> > There is the possibility that some related CTs may be grouped together and
> > share a common set of bandwidth constraints. However, such kind of
> grouping
> > can be handled and enforced purely inside a router without being advertised
> > by the IGP. This is because the use of such information in the computation
> > of unreserved bandwidths is a local matter.
>
>I agree that we should try to limit the amount of bandwidth constraints
>that are advertised, though additional "internal" constraints might be in
>use within an LSR (for instance, grouping bandwidth usage of two CTs).
I am quite happy with the document limiting the maximum number of Bandwidth
Constraints and 8 is a fine number.
But I find the text proposed above misleading in the sense that it seems to
suggest that because there is only 8CTs there could only be 8 BCs which is
absolutely untrue since we do not defined the set of bandwidth constraints
applying to CTs. With an open BC model, one could define a BC model with
one BC per CT plus an additional aggregate BC for all the CTs, that would
mean 9 BCs.
My proposal would be to simply add at the end of section 3.3 something like:
"Regardless of the Bandwidth Constraint Model, the DS-TE solution must
allow up to a maximum of 8 BCs."
> >
> > Issue 4: Suppression of preemption
> > ----------------------------------
> > It is proposed to add the following requirement in Section 3.4.
> >
> > A service provider preferring not to use preemption for user traffic should
> > not be burdened by the overheads associated with preemption. Thus, a
> > service provider should not need to set all class types to the same
> > preemption level to avoid using preemption.
>
>As in the rsvp draft and with some implementations, use of preemption
>should be optional.
I need to think more about this.
> >
> > Issue 5: Relationship between preemption and CT
> > -----------------------------------------------
> > In Section 3.4 it says:
> >
> > "In other words, DS-TE must offer eight(8) preemption priority levels to be
> > used by an LSP, that are completely orthogonal to that any other LSP's
> > attributes (eg LSP's OA, LSP's Class Type, etc.)."
> >
> > The utility of the concept of preemption being orthogonal to CT is not
> > clear. If each CT is assigned one preemption level only, it appears that
> > such concept is no longer necessary. A one-to-one mapping between CT and
Section 3.4 also says:
" Thus, DS-TE must allow two different LSPs transporting Traffic
Trunks of the same Class-Type to use different preemption
priorities, and allow the LSP with higher priority to preempt the
other one when they contend for resources."
so there is obviously not a one-to-one mapping .
> > preemption level does not preclude the possibility that some related
> CTs may
> > be grouped together, as discussed in Issue 3. We propose that the
> statement
> > of orthogonality be removed.
> >
Arguably, there is some redundancy in 3.4. So I have no objection to
removing the sentence containing the word "orthogonal" as long as the the
2nd paragraph of 3.4 remains intact.
Cheers
Francois
>Maybe they are not so much orthoginal, as not necessarily unique?
>
>I do like limiting the amount of external information, and of course I
>like reusing the existing advertisement structure and codepoints.
>Decoupling the advertised values from the actual priority could be useful.