Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

Hi Benoit and Brian,
do you mean that approach "That goes in the direction of updating the description/reference and leaving the name unchanged?" is sufficient for the two IEs that have 'Exp' as part of their names:

>>>> *         mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be created instead?)
>>>> *         postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc be created instead?)

	Regards,
		Greg

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Thursday, September 11, 2014 12:39 AM
To: Brian Trammell
Cc: Andrew Feren; Gregory Mirsky; ipfix@ietf.org; ie-doctors@ietf.org
Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

On 11/09/2014 08:40, Brian Trammell wrote:
> hi Benoit, Greg,
>
> This change looks to be interoperable to me under Section 5.2 of 7103, points 5 and 7. 7 seems clear:
>
> (7)    it harmonizes with an external reference that was itself corrected.
>
> 5 is less so:
>
> (5)    it defines a previously undefined or reserved enumerated value,
>         or one or more previously reserved bits in an Information Element
>         with flag semantics; or
>
> since these are neither enumerated values nor "flags"; however, the text in the section wasn't really written with elements with internal structure in mind (see 7013 section 4.5, though the label stack IEs are permissible under point 4 of that list), so I would see point 5 as covering this under "previously reserved bits".
>
> (Perhaps we should file a technical erratum for the next 7013 revision 
> changing point 5 to reflect this; i.e. NEW: )
>
> (5)    it defines a previously undefined or reserved enumerated value,
>         or one or more previously reserved bits in an Information Element
>         with flag semantics or internal structure; or
That would make sense if a bis document would ever be worked on.

>
>
> That said these IEs are a terrible hack and I'd love to see them 
> deprecated and replaced with something slightly less broken (see 7013 
> sections 4.6 and 4.9 paragraph 5). But it's hard to argue with an 
> update to a set of IEs which corresponds to what any implementation 
> will do _anyway_ without being updated (i.e. just keep copying those 
> bits even though we have an agreement to believe they mean something 
> different now.)
That goes in the direction of updating the description/reference and leaving the name unchanged?

Regards, Benoit
>
> Cheers,
>
> Brian
>
> On 11 Sep 2014, at 08:06, Benoit Claise <bclaise@cisco.com> wrote:
>
>> Two points:
>> - The EXP bits have been used for QoS mapping for years, even before 
>> 2009 (RFC 5462 publication date)
>> - Do you believe that deprecating/replacing all these IEs will imply 
>> that exporter implementations will update their code, just for new 
>> ElementID? :-)
>>
>> I would use the procedure in 
>> http://tools.ietf.org/html/rfc7013#section-5.2
>> Something like:
>> OLD:
>> The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsTopLabelStackSection. See the definition of mplsTopLabelStackSection for further details.
>>
>>
>> The size of this Information Element is 3 octets.
>>
>> NEW:
>>
>> The Label, Traffic Class (previously called Exp in RFC3032), and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsTopLabelStackSection. See the definition of mplsTopLabelStackSection for further details.
>>
>>
>> The size of this Information Element is 3 octets.
>>
>> And change
>> - the reference from RFC3032 to RFC5462
>> - the revision +1
>>
>> Regards, Benoit
>>
>>
>>
>>
>>> Then perhaps the right thing is to deprecate the lot and replace them all.
>>>
>>> Thanks,
>>> -Andrew
>>>
>>> On 09/10/2014 05:28 PM, Gregory Mirsky wrote:
>>>> Hi Andrew,
>>>> you're right, the RFC 5462 changed the interpretation of this field as well (section 2 Details of Change):
>>>> 2.1.  RFC 3032
>>>>   
>>>>   
>>>>     RFC 3032 states on page 4:
>>>>   
>>>>        3.  Experimental Use
>>>>   
>>>>        This three-bit field is reserved for experimental use.
>>>>   
>>>>     This paragraph is now changed to:
>>>>   
>>>>        3.  Traffic Class (TC) field
>>>>   
>>>>        This three-bit field is used to carry traffic class information,
>>>>        and the change of the name is applicable to all places it occurs
>>>>        in IETF RFCs and other IETF documents.
>>>>   
>>>>                  Regards,
>>>>                                  Greg
>>>>   
>>>> From: Andrew Feren [mailto:andrewf@plixer.com]
>>>> Sent: Wednesday, September 10, 2014 2:25 PM
>>>> To: ipfix@ietf.org
>>>> Cc: Gregory Mirsky
>>>> Subject: Re: [IPFIX] MPLS IEs in IANA's IP Flow Information Export 
>>>> (IPFIX) Entities registry
>>>>   
>>>> Hi Greg,
>>>>
>>>> On 09/10/2014 03:22 PM, Gregory Mirsky wrote:
>>>> Dear All,
>>>> in several places of describing MPLS Label element IEs the registry still refers to the EXP field even though the RFC 5462 updated RFC 3032 and renamed it "Traffic Class" (TC). Below is the list of IEs that may benefit from updating Description and Reference information:
>>>> *         mplsTopLabelStackSection
>>>> *         mplsTopLabelStackSection2
>>>> *         mplsTopLabelStackSection3
>>>> *         mplsTopLabelStackSection4
>>>> *         mplsTopLabelStackSection5
>>>> *         mplsTopLabelStackSection6
>>>> *         mplsTopLabelStackSection7
>>>> *         mplsTopLabelStackSection8
>>>> *         mplsTopLabelStackSection9
>>>> *         mplsTopLabelStackSection10
>>>> *         mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be created instead?)
>>>> *         postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc be created instead?)
>>>>
>>>> Did 5462 change just the name from Exp to TC or did the interpretation of the bits change?
>>>>
>>>> -Andrew
>>>
>>>
>>> _______________________________________________
>>> IPFIX mailing list
>>>
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix