Subject: Working Group last call on Four Ethernet Drafts

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 24 Jan 2009 22:27:00 -0000

We want to last call four Ethernet drafts in a batch.

All of the drafts are quite short, but we need to give you a little extra 
time to read and comment, so this will be a three week last call ending on 
Monday 16th February at 12 noon GMT.

Please send your comments to the CCAMP list.

The drafts are:

Ethernet Traffic Parameters
draft-ietf-ccamp-ethernet-traffic-parameters-06.txt

Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel 
Set Label Extensions
draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt

Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 
Ethernet Service Switching
draft-ietf-ccamp-gmpls-ether-svcs-02.txt

Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 
User-Network Interface (UNI)
draft-ietf-ccamp-gmpls-mef-uni-01.txt

I note that the last three of these are due to expire on February 8th (i.e. 
during the last call) so I hope that the authors can refresh the drafts with 
a new revision with no other changes except for the IPR boilerplate.

Thanks,
Adrian

---

From: <[email-masked]>
Date: Mon, 26 Jan 2009 12:02:03 -0000

Adrian Farrel wrote 24 January 2009 22:27 (snipped)

 

When we define the required performance behaviour of a layer network
(any, so this is more general than 'Ethernet') we often make an
unconscious assumption about the nature of the lower layer networks that
are in place......and this has certainly been the case in the past wrt
ITU performance HRXs for various technologies and the partitioned
breakdown of their objective allocations.

Now a link connection (== hop) at layer N is formed by a lower level
network connection (if co) or connectionless flow (if cl) at layer N-1.
Similarly a link connection at layer N-1 is formed by a network
connection/flow at layer N-2....and this relationship recurses to the
bottom-of-stack section layer, ie it recurses 'to the duct'.

What this means in practice is that the performance experienced by the
layer N network is not only a function of impairments sourced from
within the layer N nodes (which includes the effects of congestion due
to peaks in layer N traffic load, eg delay, loss) but also impairments
from the layer N link connections which are *inherited* from *all* the
lower layer network right down to the duct.

Now some impairments are environmental (eg lightning strikes causing
error/loss events) but some impairments are a function of the traffic
load in the layer network being considered (ie delay/loss)....the key
point being that whilst we might have little control over the former
type of impairment (and which are generally rare) we can exercise
control over the impairments due to (variable) traffic load.

Now the party owning the layer N network would normally require that its
performance is independent of the effects of lower level traffic load,
noting that the party owning the layer N network won't be able to
control this if they do not also own these lower layer networks.  An
alternative way to put this, which may be more striking, is to say that
the performance experienced by client X should not be a function of the
traffic behaviour of clients Y, Z, etc (who are also using the services
of the lower layer network).

The only way to ensure that the performance specification of layer N is
a function of its own traffic load and not the traffic load of any lower
layer networks is to require:
-	that all the link connections in layer N are served by
connections (which have a specific definition, principle of which is
that connections can only have a single source) in layer N-1....this is
a necessary condition;
-	that the resources of the connections in layer N-1 are not
overbooked.....this is a full sufficiency condition. 

These requirements are always assured (ie there is no choice) when the
layer N-1 connections use a co-cs mode technology.....and this is the
unconscious (ie unstated) assumption in all ITU performance HRXs to
date.  These requirements can also be assured by suitable engineering of
a co-ps mode technology at layer N-1.  These requirement however cannot
be assured by a cl-ps mode server layer technology.

And clearly these requirements are recursive through all lower layer
networks to the duct.

So the key point about all this is that it is all very well to specify
the performance (for traffic) one requires in some layer N network
mode/technology (here Ethernet), but unless one can ensure that all
lower layer networks to the duct are co-cs or co-ps_CBR in nature then
one does not have complete control of the performance one will
experience in the layer N network on the assumption that it is only
dependent on its own traffic load design.

Adrian, since you are tracking the MPLS-TP list you will no doubt
recognise that I have raised a similar issue there.....so have you any
views on how we can take this observation into account within IETF,
given it is more general than this draft (or indeed MPLS-TP)?  I have
raised this matter with my colleagues who are working on G.800 (unified
modelling of networks) and I am hoping that that it will at some stage
be clearly captured in this Recommendation....folks like Andy Reid and
Alan McGuire certainly understand the point I am raising here.

regards, Neil

---

From: Nic Neate <[email-masked]>
Date: Thu, 29 Jan 2009 16:05:28 +0000

Some low-level comments on draft-ietf-ccamp-ethernet-traffic-parameters-06.

(1) TLV type definition (page 5):

              Type     Length   Format            Description 
              ------------------------------------------------------  
              1        TBD      Reserved          Reserved value 
              2        24       see Section 3.1   Ethernet Bandwidth 
                                                  Profile [MEF10.1] 
              3        8        [GMPLS-ESVCS]     Layer 2 Control 
                                                  Processing (L2CP) 

The reference to section 3.1 should be 4.1.

(2) Ethernet Bandwidth Profile TLV Index field (page 6):

                      The index field value MUST correspond to at least one 
           of the index value included in the extended ClassType object ([DS- 
           TE], [MCOS]). 

The [DS-TE] reference is missing from chapter 11.  Note also that CLASSTYPE is defined in [DS-TE] (RFC 4124) whereas EXTENDED_CLASSTYPE is defined in [MCOS] (draft-minei-diffserv-te-multi-class).  This could be made clearer by updating the text to say "The index field value MUST correspond to at least one of the index values included in the CLASSTYPE object ([DS-TE]) or EXTENDED_CLASSTYPE object ([MCOS])".

(3) Ethernet Bandwidth Profile TLV Index field (page 6):

           A given index value j can be associated to at most N Class-Type 
           values CTi (i =< N) of the extended Class-Type object. This 
           applies in case a set of one or more CTi maps a single (shared) BW  
           profile. An example of value setting consists then in assigning 
           an arbitrary value (comprised within the range [0x08,0xF8],  
           defined by the 5 MSB of the Index field) associated to a set of  
           CTi. This allows mapping to one of 248 pre-defined CTi sets. 

It is unclear exactly what the range of values for defining a set of CTi is.
-  The range [0x08,0xF8] contains 241 values, not 248.
-  The 5 most significant bits of the Index field can only be used to create 31 values (excluding 0), not 248.

I think the text should say "...an arbirary value from the range [0x08,0xFF] associated to a set of CTi.  This allows mapping to one of 248 pre-defined CTI sets."

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aria - Adrian Farrel Personal
Sent: 24 January 2009 22:27
To: [email-masked]
Cc: Brungard, Deborah A, ALABS
Subject: Working Group last call on Four Ethernet Drafts

All of the drafts are quite short, but we need to give you a little extra time to read and comment, so this will be a three week last call ending on Monday 16th February at 12 noon GMT.

The drafts are:

Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt

Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching draft-ietf-ccamp-gmpls-ether-svcs-02.txt

Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) draft-ietf-ccamp-gmpls-mef-uni-01.txt

I note that the last three of these are due to expire on February 8th (i.e. 
during the last call) so I hope that the authors can refresh the drafts with a new revision with no other changes except for the IPR boilerplate.

Thanks,
Adrian

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 30 Jan 2009 14:42:09 +0100

Nic:
 
> From: Nic Neate 
> Sent: 29 January 2009 16:05
> To: [email-masked]
> Subject: RE: Working Group last call on Four Ethernet Drafts
> 
> Some low-level comments on 
> draft-ietf-ccamp-ethernet-traffic-parameters-06.
> 
> 

indeed.

> The [DS-TE] reference is missing from chapter 11.  Note also 
> that CLASSTYPE is defined in [DS-TE] (RFC 4124) whereas 
> EXTENDED_CLASSTYPE is defined in [MCOS] 
> (draft-minei-diffserv-te-multi-class).  This could be made 
> clearer by updating the text to say "The index field value 
> MUST correspond to at least one of the index values included 
> in the CLASSTYPE object ([DS-TE]) or EXTENDED_CLASSTYPE 
> object ([MCOS])".

I will clarify.

> -  The 5 most significant bits of the Index field can only be 
> used to create 31 values (excluding 0), not 248.

There are 16 bits in this field, the 3 lsb are used to encode the 8 cti
defined in DS-TE: from 0x00000|000 (0x00) to 0x00000|111 (0x07), so 8
values [0x00,0x08[ in the group 0.

The remaining values [0x08,0xFF] are allocated as follows:

- The values in the range [0x08,0xF8[ are used for encoding CTi sets so
240 sets (30 groups as defined per msb of 8 values each) 

- The values in the range [0xF8,0xFF] are reserved (= 8 sets) i.e. the
last group of 8 values is reserved.

So, the last sentence should read "This allows mapping to one of 248
pre-defined CTi sets" but i will change the parenthesis from ] to [.
thanks for catching it. i also need to change capital to minus letters
for msb and lsb description.

Thanks,
-dimitri.

> I think the text should say "...an arbirary value from the 
> range [0x08,0xFF] associated to a set of CTi.  This allows 
> mapping to one of 248 pre-defined CTI sets."
> 
> 
> Nic
> 
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Aria - Adrian 
> Farrel Personal
> All of the drafts are quite short, but we need to give you a 
> little extra time to read and comment, so this will be a 
> three week last call ending on Monday 16th February at 12 noon GMT.
> 
> Generalized MPLS (GMPLS) Data Channel Switching Capable 
> (DCSC) and Channel Set Label Extensions 
> Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and 
> G.8011 Ethernet Service Switching 
> Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and 
> G.8011 User-Network Interface (UNI) 
> during the last call) so I hope that the authors can refresh 
> the drafts with a new revision with no other changes except 
> for the IPR boilerplate.
> 
> Thanks,
> Adrian
> 
> 
> 
>

---

From: "Benoit C Tremblay" <[email-masked]>
Date: Fri, 30 Jan 2009 11:53:51 -0500

Hello,

I would like to understand the motivation behind the use of the
classtype object instead of simply using the index field as a bit vector
for ethernet priorities as it is specified in the OIF UNI 2.0.  This
simplifies the interpretation of the index field and reduces the number
of objects that need to be included in the message.  

Regards,

Benoit Tremblay

> [mailto:[email-masked]] On Behalf Of PAPADIMITRIOU Dimitri
> Sent: January-30-09 8:42 AM
> To: Nic Neate; [email-masked]
> > The [DS-TE] reference is missing from chapter 11.  Note also that 
> > CLASSTYPE is defined in [DS-TE] (RFC 4124) whereas 
> EXTENDED_CLASSTYPE 
> > is defined in [MCOS] (draft-minei-diffserv-te-multi-class).  This 
> > could be made clearer by updating the text to say "The index field 
> > value MUST correspond to at least one of the index values 
> included in 
> > the CLASSTYPE object ([DS-TE]) or EXTENDED_CLASSTYPE object 
> ([MCOS])".
> 
> I will clarify.
> 
> > It is unclear exactly what the range of values for defining 
> a set of 
> > CTi is.
> > -  The 5 most significant bits of the Index field can only 
> be used to 
> > create 31 values (excluding 0), not 248.
> 
> There are 16 bits in this field, the 3 lsb are used to encode 
> the 8 cti defined in DS-TE: from 0x00000|000 (0x00) to 
> 0x00000|111 (0x07), so 8 values [0x00,0x08[ in the group 0.
> 
> - The values in the range [0x08,0xF8[ are used for encoding 
> CTi sets so 240 sets (30 groups as defined per msb of 8 values each) 
> 
> - The values in the range [0xF8,0xFF] are reserved (= 8 sets) 
> i.e. the last group of 8 values is reserved.
> 
> So, the last sentence should read "This allows mapping to one 
> of 248 pre-defined CTi sets" but i will change the 
> parenthesis from ] to [.
> thanks for catching it. i also need to change capital to 
> minus letters for msb and lsb description.
> 
> Thanks,
> -dimitri.
> 
> > I think the text should say "...an arbirary value from the range 
> > [0x08,0xFF] associated to a set of CTi.  This allows 
> mapping to one of 
> > [mailto:[email-masked]] On Behalf Of Aria - Adrian Farrel 
> > Personal
> > All of the drafts are quite short, but we need to give you a little 
> > extra time to read and comment, so this will be a three 
> week last call 
> > ending on Monday 16th February at 12 noon GMT.
> > 
> > I note that the last three of these are due to expire on 
> February 8th 
> > (i.e.
> > during the last call) so I hope that the authors can refresh the 
> > drafts with a new revision with no other changes except for the IPR 
> > boilerplate.
> > 
> > Thanks,
> > Adrian
> > 
> > 
> > 
> > 
> 
>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 30 Jan 2009 18:21:14 +0100

Benoit:

> From: Benoit C Tremblay [mailto:[email-masked]] 
> Sent: Friday, January 30, 2009 5:54 PM
> To: PAPADIMITRIOU Dimitri; Nic Neate; [email-masked]

Because, more than 8 values are needed. Now if you only use 8 values the
current spec does not prevent to do so.

Thanks,
-dimitri.

> > >                                                   Profile 
> [MEF10.1] 
> > >            defined by the 5 MSB of the Index field) 
> associated to a 
> > > set of