[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Few editorial comments/questions: draft-ietf-tewg-diff-te-proto-0 0
Sanjaya,
Thanks again for your comments. Responses embedded:
At 08:49 18/03/2002 -0500, Choudhury, Sanjaya wrote:
>Hi! Here are few editorial comments/ questions related
>to the draft draft-ietf-tewg-diff-te-proto-00.
>
>1. It will be nice to use the words MUST/SHOULD/
> MAY etc to clearly indicate implementation
> requirements expected from the vendors.
We've already aligned to "must/should/may" in most places, but I had a
quick look again and you're right there are a few places which still need
clean-up (also we should capitalise). will be done.
>2. [Section 2, Class-Type definition]
> DS-TE-REQTS mentions "By definition each CT is
> assigned to a BC or a set of BC".
>If you think
> this statement will contribute to the clarity,
> it may not be bad idea to refer to it in this
> section.
The CT definition which is quoted already says "the set of Traffic Trunks
... that is governed by a specific set of BCs". So I don't think it really
adds much to add immediately after "By definition each CT is assigned to a
BC or a set of BC". This last statement is only used in the REQTS draft in
the section on BC for readability (because the BC section is quite a few
paragraphs further down from the actual CT definition). It was not used in
the CT section.
So, I'd rather leave this at is is.
>3. [Section 2, TE-Class definition]
> Before the statement "A pair of....", it may be
> helpful, to add a conceptual definition of
> TE-Class.
>
> (ex: The TE-Class associated with a LSP,
> identifies the BCs that must be applied to it,
> along with the relative importance of the LSP
> from the bandwidth allocation prospective.
> --just an idea)
Well, definition is really the turf of the REQTS draft. In the PROTO draft,
all we want to do is include relevant exerpts from REQTS definition without
altering/complementing these definitions.
So the question becomes: should we add this in the REQTS draft first?
If we want to add a conceptual description we need to refine it a bit more
to reflect the fact that an LSP actually has both a setup and holding
priorities , so in effect it can be associated with two TE-classes (ie two
pairs of CT/preemption).
We could simply change your statement to allow plural i.e.
"The TE-Class(es) associated with a LSP,
identifies(y) the BCs that must be applied to it,
along with the relative importance of the LSP
from the bandwidth allocation prospective."
but then it may sound like an LSP can be associated with many TE-classes.
My impression is we would end up with either a fairly inaccurate statement
or a fairly compliacted statement , so I am tempted to avoid the conceptual
definition (unless someone comes up with one that is both acurate and simple).
>
>4. [Section 2: TE-Class definition]
> From the definition can we assume the following:
> (a) If a request to setup a LSP with a setup
> priority p and Class-Type c arrives at a
> transit LSR, it should be REJECTED, if p
> does not appear in any of the <c, --> pairs
> defining the TE-Class map. TRUE/FALSE
TRUE.
> (b) If a request to setup a LSP with a Class-Type
> c arrives at a transit LSR, it should be REJECTED,
> if c does not appear in any of the pairs defining
> the TE-Class TRUE/FALSE
TRUE.
you can even generalise that by :
If a request to setup a LSP with a Class-Type
c arrives at a transit LSR, it should be REJECTED,
if <c,P> is not one of the pairs defined in
the TE-Class
> [May be this should be clarified some where in
> the text]
Those cases are already discussed in the RSVP section (Appendix A, sction 3):
"An LSR receiving a Path message with the CLASSTYPE object, which:
- recognizes the CLASSTYPE object,
- supports the particular Class-Type, but
- determines that the tuple formed by (i) this Class-Type and
(ii) the set-up priority signaled in the same Path message,
is not one of the eight TE-classes configured in the TE-class
mapping,
must send a PathErr towards the sender with the error code 'Diff-
Serv-aware TE Error' and an error value of 'CT and setup priority do
not form a configured TE-Class'. Those are defined below in section
5. "
and
"An LSR receiving a Path message with the CLASSTYPE object, which:
- recognizes the CLASSTYPE object,
- supports the particular Class-Type, but
- determines that the tuple formed by (i) this Class-Type and
(ii) the holding priority signaled in the same Path message,
is not one of the eight TE-classes configured in the TE-class
mapping,
must send a PathErr towards the sender with the error code 'Diff-
Serv-aware TE Error' and an error value of 'CT and holding priority
do not form a configured TE-Class'. Those are defined below in
section 5."
>5. [General -Question]
> Are the following assumptions correct ?
> a. BCO MUST be defined in ALL the LSRs in the domain
True.
> b. CT0 MUST be defined in ALL the LSRs in the domain
well, one does not really "define" CTs (defining BC0 is sufficient to
consider that CT0 is active) so I am not sure exactly what you mean here.
But , in any case, the solution does not preclude that CT0 is not used by
any LSP (ie. it is OK if no LSPs actually make use of CT0).
> c. TE-Class[0] MUST be defined in ALL the LSRs in the
> domain.
False.
It would be OK if SP decided to configure TE-CLass[0] as currently unused.
This will simply result in the first "bandwidth" value advertised in IGP
("Unreserved TE-CLass[0]) always being advertised as zero (see section 4.2:
"If TE-Class[i] is unused the value to be advertised by the IGP in
"Unreserved TE-Class [i]" is zero.)
>6. [Section 3.1.2]
> Do you think the discussion related to "LSP Size Overbooking"
> adds any thing to the section ?
yes.
>7. [Section 3.1.2 6th para However..]
> "..., the overbooking ration already enforced by the "LSP
> Size overbooking" method. "
> Is this correct ?
I believe so.
>8. [Section 3.1.2]
> I think, certain conditions MUST be satisfied while
> configuring the local multiplier. For example
> if BCi < BC j, then BCi * LOMi < BCj * LOMj
> Am I correct ?
I would expect those conditions to be typically true, but I don't believe
they MUST be true.
>9. [Section 3.2.1, last statement]
> can we infer the following from the last statement
> of this section ?
> [ALL the LSRs in the domain must have the same TE
> -Class mapping]
> a. All the LSRs in the domain MUST support same
> set of CTs.
yes.
> b. If using the Russian Doll Model, All the LSRs in
> the domain MUST be same AND MUST be consecutive.
I didn't get this one.
>10. [Section 4.2]
> TE-Class index in a domain must be consecutive
> (0,1,2,3 and not 0,1,5)?
>
>
I assume you are talking about the TE-Class index for *active* TE-classes,
right?
Then, I don't think it MUST be consecutive. I think the solution would work
fine if there were only 4 active TE-Classes and if those used the TE-CLass
indexes of 0,1,3,5.
In that case, in the IGP you would see < Unreserved TE-CLass[0], Unreserved
TE-CLass[1], 0, Unreserved TE-Class[3],0, Unreserved TE-Class[5],0,0 >
Cheers
Francois
>
>
>
>
>
>
>