Subject: Re: [CCAMP] index field in draft-ietf-ccamp-ethernet-traffic-parameters

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 26 Jun 2009 16:25:38 +0200

Hi Benoit, 

see in-line for the answers:

________________________________

	From: Benoit C Tremblay [mailto:[email-masked]] 
	Sent: Friday, June 26, 2009 4:02 PM
	To: PAPADIMITRIOU Dimitri; [email-masked]
	Subject: index field in draft-ietf-ccamp-ethernet-traffic-parameters

	Hello Dimitri, 

	I have further comments on the section decribing the index field. 

	1) There is a reference to an expired draft (draft-minei-diffserv-te-multi-class).  It should be removed.  

I am not sure how to deal with this - remove is not an option (as the doc. makes use of an object of that ref.)
You will find a version here <http://tools.ietf.org/id/draft-minei-diffserv-te-multi-class-02.txt>

	2) The requirement that "the index field value MUST correspond to at least one of the index values included in the CLASSTYPE object" is a bit problematic as a single CLASSTYPE object can be present in a PATH message and a single classtype can be represented with this object. The requirement would then exclude the possibility to insert multiple bandwidth profile TLVs in the SENDER_TSPEC.  I suggest that this requirement should be conditional to the presence of thhe CLASSTYPE object.  If a CLASSTYPE object is present, then a single BW profile TLV shall be present and the index value must be the CT defined in the CLASSTYPE object.  If no CLASSTYPE object is present, multiple BW profile TLV (up to 8) can be present and the index value either represent a CT (values in [0, 7]) or a predefined set of CT (values in [8, 247]).

It is exactly the reason for using the EXTENDED version of the CLASSTYPE. Note that the latter option does not apply (cf. MUST) when used. 

Also important to remember the BW per CTi field MAY be used for bandwidth accounting purposes (the BW per CTi does not replace the TSPEC BW sub-TLV i.e. "The Ethernet SENDER_TSPEC object MAY include more than one Ethernet Bandwidth Profile TLV").

	3) Also, it should be clarified that the 240 pre-defined sets of CTs are not standard.  The following text is proposed to be included :

I will the first sentence, the other should be included in i-d's making use of these traffic parameters.

Thanks,
-dimitri.

	"To ensure coherent operation, the network administrator MUST configure exactly the same pre-defined CT sets on all LSRs of the GMPLS domain. Proper configuration needs also to be agreed between administrative domains if this feature is used over UNI. The mean to pre-configured those sets and their definitions are out of scope of this specification. "

	Regards, 

	Benoit 

	Picture (Metafile) 
	Benoit Tremblay 
	Broadband and Systems Research 
	Ericsson Canada 
	8400 Décarie    Mount-Royal 
	Tel: +1 514 345-7900 x45064 
	Cell.: +1 514 501-0236 
	Fax: +1 514 345-6105 
	mailto: [email-masked]

---

From: "Benoit C Tremblay" <[email-masked]>
Date: Fri, 26 Jun 2009 11:26:36 -0400

Hello Dimitri,

Thanks for the clarification.

I am not sure to understand why we need the BW in both the EXTENDED_CLASSTYPE and the SENDER_TSPEC. Can't the BW accounting use the information from the SENDER_TSPEC (either CIR or CIR+EIR) instead of relying on the EXTENDED_CLASSTYPE?

Regards,
Benoit

> -----Original Message-----
> From: PAPADIMITRIOU Dimitri 
> [mailto:[email-masked]] 
> Sent: June-26-09 10:26 AM
> To: Benoit C Tremblay; [email-masked]
> Subject: RE: index field in 
> draft-ietf-ccamp-ethernet-traffic-parameters
> 
>  
> Hi Benoit, 
> 
> 
> 	Subject: index field in 
> draft-ietf-ccamp-ethernet-traffic-parameters
> 	
> 	
> 
> 	Hello Dimitri, 
> 
> 	1) There is a reference to an expired draft 
> (draft-minei-diffserv-te-multi-class).  It should be removed.  
> 
> 
> I am not sure how to deal with this - remove is not an option 
> (as the doc. makes use of an object of that ref.) You will 
> find a version here 
> <http://tools.ietf.org/id/draft-minei-diffserv-te-multi-class-02.txt>
> 
> 	2) The requirement that "the index field value MUST 
> correspond to at least one of the index values included in 
> the CLASSTYPE object" is a bit problematic as a single 
> CLASSTYPE object can be present in a PATH message and a 
> single classtype can be represented with this object. The 
> requirement would then exclude the possibility to insert 
> multiple bandwidth profile TLVs in the SENDER_TSPEC.  I 
> suggest that this requirement should be conditional to the 
> presence of thhe CLASSTYPE object.  If a CLASSTYPE object is 
> present, then a single BW profile TLV shall be present and 
> the index value must be the CT defined in the CLASSTYPE 
> object.  If no CLASSTYPE object is present, multiple BW 
> profile TLV (up to 8) can be present and the index value 
> either represent a CT (values in [0, 7]) or a predefined set 
> of CT (values in [8, 247]).
> 
> 
> It is exactly the reason for using the EXTENDED version of 
> the CLASSTYPE. Note that the latter option does not apply 
> (cf. MUST) when used. 
> 
> Also important to remember the BW per CTi field MAY be used 
> for bandwidth accounting purposes (the BW per CTi does not 
> replace the TSPEC BW sub-TLV i.e. "The Ethernet SENDER_TSPEC 
> object MAY include more than one Ethernet Bandwidth Profile TLV").
> 
> 
> 	3) Also, it should be clarified that the 240 
> pre-defined sets of CTs are not standard.  The following text 
> is proposed to be included :
> 
> I will the first sentence, the other should be included in 
> i-d's making use of these traffic parameters.
> 
> Thanks,
> -dimitri.
> 
> 	"To ensure coherent operation, the network 
> administrator MUST configure exactly the same pre-defined CT 
> sets on all LSRs of the GMPLS domain. Proper configuration 
> needs also to be agreed between administrative domains if 
> this feature is used over UNI. The mean to pre-configured 
> those sets and their definitions are out of scope of this 
> specification. "
> 
> 	Regards, 
> 
> 	Benoit 
> 
> 	Picture (Metafile) 
> 	Benoit Tremblay

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 26 Jun 2009 17:56:44 +0200

Hello Benoit, 

> Sent: Friday, June 26, 2009 5:27 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> I am not sure to understand why we need the BW in both the 
> EXTENDED_CLASSTYPE and the SENDER_TSPEC. 

As I stated below BW in the EXTENDED version is not required for BW settings but I can not forbid it.

> Can't the BW 
> accounting use the information from the SENDER_TSPEC (either 
> CIR or CIR+EIR) instead of relying on the EXTENDED_CLASSTYPE?

You can. I just did not want to prevent existing use of the EXTENDED version of the CLASSTYPE. The EXTENDED CLASSTYPE in its minimum usage is just for the multiple CTi it permits.

Thanks,
-dimitri.