Re: [NSIS] QSPEC Questions

Hannes Tschofenig wrote:
> Based on Dan's AD review comments for draft-ietf-dime-qos-parameters-06 I
> need to ask a few questions regarding the QSPEC draft:
>
> * There is no description of the differences between TMOD-1 and TMOD-2.
> Useful to say something about the difference?
The reason for two TMODs given in the Qspec draft is (from s3.3.1):

   Two TMOD parameters are defined in Section 5, <TMOD-1> and <TMOD-2>,
   where the second (<TMOD-2>) parameter is specified as could be needed
   to support some DiffServ applications.  For example, it is typically
   assumed that DiffServ EF traffic is shaped at the ingress by a single
   rate token bucket.  Therefore, a single TMOD parameter is sufficient
   to signal DiffServ EF traffic.  However, for DiffServ AF traffic two
   sets of token bucket parameters are needed, one token bucket for the 
   average traffic and one token bucket for the burst traffic.
   [RFC2697] defines a Single Rate Three Color Marker (srTCM), which
   meters a traffic stream and marks its packets according to three
   traffic parameters, Committed Information Rate (CIR), Committed Burst
   Size (CBS), and Excess Burst Size (EBS), to be either green, yellow,
   or red.  A packet is marked green if it does not exceed the CBS,
   yellow if it does exceed the CBS, but not the EBS, and red otherwise.  
   [RFC2697] defines specific procedures using two token buckets that
   run at the same rate.  Therefore 2 TMOD parameters are sufficient to
   distinguish among 3 levels of drop precedence.  An example is also
   described in the Appendix to [RFC2597].

A piece of this probably needs to be in the dime doc.

>   
>
> * Where does the description for <Path Jitter>, <Path PLR> and <Path PER>
> come from? There is no reference to another RFC given in these sections.
>
> * Why is Path Jitter STAT4(Reserved) included in the <Path Jitter>
> parameter? 
>
> * The encoding of the  <RPH Priority> Parameter is not inline with
> http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-09.txt. The ALRP
> Priority and the Reserved octets 
> positions are inversed. 
>
> * <DSTE Class Type> Parameter
>
> The QSPEC draft says:
> "
>  DSTE Class Type: Indicates the DSTE class type.  Values currently
>    allowed are 0, 1, 2, 3, 4, 5, 6, 7.
> "
>
> RFC 4124 does not define a value of 0. Where does 0 come from? 
> In RFC 4124 the field is only 3 bits long. Why is it 8 bytes long in the
> QSPEC document? 
>   
Technically 0 is reserved in RFC4124.   This  probably ought to be 
reproduced in the Qspec and DIME docs.
I take it you meant 8 bits long.  Actually, the CLASSTYPE is 32 bits in 
RFC4124 with 29 bits reserved.
In practice it seems unlikely any extra classes will be defined so the 
different definitions are unlikely to cause issues, but given that each 
TLV has 32 bits it might have been sensible to match the RFC4124 definition.

I note that RFC 4124 does not offer an IANA registry for DSTE values: 
But the Qspec and DIME docs generate two separate registries.  Since the 
meanings are supposed to be common this doesn't make a lot of sense.  
This may apply to other Qspec and DIME registries.

/Elwyn

> Your feedback is appreciated!
>
> Ciao
> Hannes
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www.ietf.org/mailman/listinfo/nsis
>
>   
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www.ietf.org/mailman/listinfo/nsis