Subject: Few editorial comments/questions: draft-ietf-tewg-diff-te-proto-0 0

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Mon, 18 Mar 2002 08:49:48 -0500

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.

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.

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)
  
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

     (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
         [May be this should be clarified some where in
         the text]
5. [General -Question]
   Are the following assumptions correct ?
    a. BCO  MUST be defined in ALL the LSRs in the domain
    b. CT0  MUST be defined in ALL the LSRs in the domain
    c. TE-Class[0] MUST be defined in ALL the LSRs in the
       domain.
6. [Section 3.1.2] 
   Do you think the discussion related to "LSP Size Overbooking"
   adds any thing to the section ? 

7. [Section 3.1.2 6th para However..]
   "..., the overbooking ration already enforced by the "LSP
   Size overbooking" method. "
   Is this correct ? 

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 ?

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.
   b. If using the Russian Doll Model, All the LSRs in
      the domain MUST be same AND MUST be consecutive.

10. [Section 4.2]
    TE-Class index in a domain must be consecutive 
    (0,1,2,3 and not 0,1,5)?

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 18 Mar 2002 14:52:13 +0100

Sanjaya,

Thanks again for your comments. Responses embedded:

>    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.

>    it may not be bad idea to refer to it in this

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.

>    from the bandwidth allocation prospective.

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).

>          defining the TE-Class map.  TRUE/FALSE

TRUE.

>          if c does not appear in any of the pairs defining

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

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."

>     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

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.)

>    adds any thing to the section ?

yes.

>    Size overbooking" method. "

I believe so.

>     if BCi < BC j, then BCi * LOMi < BCj * LOMj

I would expect those conditions to be typically true, but I don't believe 
they MUST be true.

>    a. All the LSRs in the domain MUST support same

yes.

>       the domain MUST be same AND MUST be consecutive.

I didn't get this one.

>     TE-Class index in a domain must be consecutive

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