Subject: [IPFIX] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

From: Gregory Mirsky <[email-masked]>
Date: Wed, 10 Sep 2014 19:22:51 +0000

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

Regards,
        Greg

---

From: Andrew Feren <[email-masked]>
Date: Wed, 10 Sep 2014 17:24:55 -0400

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

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 10 Sep 2014 21:28:36 +0000

Hi Andrew,
you're right, the RFC 5462 changed the interpretation of this field as well (section 2 Details of Change):
2.1<http://tools.ietf.org/html/rfc5462#section-2.1>.  RFC 3032<http://tools.ietf.org/html/rfc3032>

   RFC 3032<http://tools.ietf.org/html/rfc3032> 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:[email-masked]]
Sent: Wednesday, September 10, 2014 2:25 PM
To: [email-masked]
Cc: Gregory Mirsky
Subject: Re: [IPFIX] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

Hi Greg,

Did 5462 change just the name from Exp to TC or did the interpretation of the bits change?

-Andrew

---

From: Andrew Feren <[email-masked]>
Date: Wed, 10 Sep 2014 17:43:21 -0400

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* <http://tools.ietf.org/html/rfc5462#section-2.1>*.  RFC 3032
> <http://tools.ietf.org/html/rfc3032>*
>
>  
>
>  
>
>    RFC 3032 <http://tools.ietf.org/html/rfc3032> states on page 4:
>
>  
>
>       3.  Experimental Use
>
>  
>
> *From:*Andrew Feren [mailto:[email-masked]]
> *Sent:* Wednesday, September 10, 2014 2:25 PM
> *To:* [email-masked]
> *Cc:* Gregory Mirsky
> *Subject:* Re: [IPFIX] MPLS IEs in IANA's IP Flow Information Export
> (IPFIX) Entities registry
>
>  
>
> Hi Greg,
>
>     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:
>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Sep 2014 08:06:52 +0200

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
    <http://www.iana.org/go/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 <http://www.iana.org/go/rfc3032> to RFC5462
- the revision +1

Regards, Benoit

>>     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
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 11 Sep 2014 06:20:54 +0000

Hi Benoit,
I'd prefer an update to existing IEs as well. All but two IEs can corrected by updating their Description and References. Do you think Name of two can be updated in the same manner? Errata doesn't seem as the right way as these IEs been defined in RFC 5102 (published January 2008).

Your suggestions greatly appreciated.

                Regards,
                                Greg

From: Benoit Claise [mailto:[email-masked]]
Sent: Wednesday, September 10, 2014 11:07 PM
To: Andrew Feren; Gregory Mirsky; [email-masked]
Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

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

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.

NEW:

The Label, Traffic Class (previously called Exp in RFC3032<http://www.iana.org/go/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.

And change
- the reference from RFC3032<http://www.iana.org/go/rfc3032> to RFC5462
- the revision +1

Regards, Benoit

Thanks,
-Andrew

      3.  Experimental Use

                Regards,
                                Greg

From: Andrew Feren [mailto:[email-masked]]
Sent: Wednesday, September 10, 2014 2:25 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Gregory Mirsky
Subject: Re: [IPFIX] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

Hi Greg,

-Andrew

IPFIX mailing list

[email-masked]<mailto:[email-masked]>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Sep 2014 08:32:17 +0200

Hi Gregory,
>
> Hi Benoit,
>
> I'd prefer an update to existing IEs as well. All but two IEs can 
> corrected by updating their Description and References. Do you think 
> Name of two can be updated in the same manner?
>
We should review if RFC 7013 allows a name change... THe IE-DOCTORS will 
give a definitive answer.
Let me send them an email.
>
> Errata doesn't seem as the right way as these IEs been defined in RFC 
> 5102 (published January 2008).
>
This is not an issue. Since 7012, which updates RFC5102, IANA is the THE 
registry for IEs,  not the RFCs any longer.

        The IANA "IPFIX Information Elements" registry [IANA-IPFIX  <http://tools.ietf.org/html/rfc7012#ref-IANA-IPFIX>] is the
        current complete reference for IPFIX Information Elements.  The
        initial values for this registry were provided by [RFC5102  <http://tools.ietf.org/html/rfc5102>].

Regards, Benoit.
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* Wednesday, September 10, 2014 11:07 PM
> *To:* Andrew Feren; Gregory Mirsky; [email-masked]
> *Subject:* Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow 
> Information Export (IPFIX) Entities registry
>
> Two points:
> I would use the procedure in 
> http://tools.ietf.org/html/rfc7013#section-5.2 
> <http://tools.ietf.org/html/rfc7013#section-5.2>
> Something like:
> OLD:
>
> pushed immediately before the label stack entry that would be reported 
> by mplsTopLabelStackSection. See the definition of 
>     <http://www.iana.org/go/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.
>
>         you're right, the RFC 5462 changed the interpretation of this
>         field as well (section 2 Details of Change):
>
>         *2.1* <http://tools.ietf.org/html/rfc5462#section-2.1>*. RFC
>         3032 <http://tools.ietf.org/html/rfc3032>*
>
>         *To:* [email-masked] <mailto:[email-masked]>
>         *Cc:* Gregory Mirsky
>         *Subject:* Re: [IPFIX] MPLS IEs in IANA's IP Flow Information
>         Export (IPFIX) Entities registry
>
>         Hi Greg,
>
>             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:
>
>             ·mplsTopLabelExp (should this be deprecated and
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 11 Sep 2014 08:40:09 +0200

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

Cheers,

Brian

On 11 Sep 2014, at 08:06, Benoit Claise <[email-masked]> wrote:

> 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 reference from RFC3032 to RFC5462
> - the revision +1
> 
> Regards, Benoit
> 
> 
> 
> 
>>> 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
>>>  
>>> 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:
>>> ·         mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be created instead?)
>>> ·         postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc be created instead?)
>>>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Sep 2014 09:38:58 +0200

>         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…
That goes in the direction of updating the description/reference and 
leaving the name unchanged?

Regards, Benoit

---

From: Brian Trammell <[email-masked]>
Date: Thu, 11 Sep 2014 09:42:58 +0200

On 11 Sep 2014, at 09:38, Benoit Claise <[email-masked]> wrote:

> That goes in the direction of updating the description/reference and leaving the name unchanged?

Yep.

> ie-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ie-doctors

---

From: Andrew Feren <[email-masked]>
Date: Thu, 11 Sep 2014 11:06:47 +0000

Hi Benoit,

Thanks for the clarification.  I don't really know the RFCs in question and took the previous reply that the interpretation of the bits had changed at face value.

If Exp has effectively always been TC then I also don't see a need to deprecate all of them.

-Andrew

________________________________
From: Benoit Claise [[email-masked]]
Sent: Thursday, September 11, 2014 2:06 AM
To: Andrew Feren; Gregory Mirsky; [email-masked]
Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

Two points:

NEW:

And change

Regards, Benoit

Thanks,
-Andrew

      3.  Experimental Use

                Regards,
                                Greg

Hi Greg,

-Andrew

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 11 Sep 2014 16:16:36 +0000

Hi Benoit and Brian,

	Regards,
		Greg

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]] 
Sent: Thursday, September 11, 2014 12:39 AM
To: Brian Trammell
Cc: Andrew Feren; Gregory Mirsky; [email-masked]; [email-masked]
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:
> (Perhaps we should file a technical erratum for the next 7013 revision 
> changing point 5 to reflect this; i.e. NEW: )
>

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

Regards, Benoit

---

From: Brian Trammell <[email-masked]>
Date: Fri, 12 Sep 2014 07:25:31 +0200

hi Greg, IE-Doctors,

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

Yep. The IEs will still be named (post)mplsTopLabelExp, but the language changed to reflect the renaming of the Exp field as in the other IEs:

OLD mplsTopLabelExp:

The Exp field from the top MPLS label stack entry, i.e., the last label that was pushed.
Bits 0-4:  Don't Care, value is irrelevant.
Bits 5-7:  MPLS Exp field.

0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|     don't care    |    Exp    |
+---+---+---+---+---+---+---+---+

NEW mplsTopLabelExp:

The Traffic Class field (formerly named Exp) from the top MPLS label stack entry, 
i.e., the last label that was pushed.
Bits 0-4:  Don't Care, value is irrelevant.
Bits 5-7:  MPLS Traffic Class field.

0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|     don't care    |    TC     |
+---+---+---+---+---+---+---+---+

For both mplsTopLabelExp and postMplsTopLabelExp, the References section will be changed to point to RFC5462. The text of postMplsTopLabelExp's description does not need to change.

IE-Doctors: any problem with this change to the topLabelExp fields? I'd like to call the question and send this up to IANA early next week.

Cheers,

Brian

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 12 Sep 2014 05:47:02 +0000

Hi Brian,
thank you, that will work.
What would be in the Requester column if we're not updating the RFC 7012 (perhaps through Errata)?

	Regards,
		Greg

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Thursday, September 11, 2014 10:26 PM
To: Gregory Mirsky; [email-masked]
Cc: Benoit Claise; Andrew Feren; [email-masked]
Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

hi Greg, IE-Doctors,

OLD mplsTopLabelExp:

0   1   2   3   4   5   6   7

NEW mplsTopLabelExp:

The Traffic Class field (formerly named Exp) from the top MPLS label stack entry, i.e., the last label that was pushed.
Bits 0-4:  Don't Care, value is irrelevant.
Bits 5-7:  MPLS Traffic Class field.

0   1   2   3   4   5   6   7

Cheers,

Brian

> Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow 
>> (Perhaps we should file a technical erratum for the next 7013 
>> revision changing point 5 to reflect this; i.e. NEW: )
>>

---

From: Paul Aitken <[email-masked]>
Date: Fri, 12 Sep 2014 09:43:16 +0100

Brian,

I don't see anything in 7013 that prevents us from updating the name too.

P.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 12 Sep 2014 11:34:41 +0200

hi Paul,

I'm fine either way. Probably makes sense to rename things while we still can.

Cheers,

Brian

On 12 Sep 2014, at 10:43, Paul Aitken <[email-masked]> wrote:

>> On 11 Sep 2014, at 18:16, Gregory Mirsky 
>> <[email-masked]>
>>  wrote:
>> 
>> 
>>> Hi Benoit and Brian,
>>> From: Benoit Claise [
>>> mailto:[email-masked]
>>> ] 
>>>> On 11 Sep 2014, at 08:06, Benoit Claise 
>>>> <[email-masked]>
>>>>  wrote:
>>>> 
>>>> 
>>>>> Two points:
>>>>>>> From: Andrew Feren [
>>>>>>> mailto:[email-masked]
>>>>>>> ]
>>>>>>> To: 
>>>>>>> [email-masked]

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 19 Sep 2014 09:45:05 +0000

Hi Loa,
I haven't thought of possible impact of RFC 5462 to existing MIBs nor I've checked for it.

	Regards,
		Greg

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Friday, September 19, 2014 10:29 AM
To: Gregory Mirsky; [email-masked]
Cc: [email-masked]; MIB Doctors (E-mail)
Subject: Re: [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

Greg,

I'm not sure about this - would changing the names require updating all existing deployed MIBs?

Can we get an mib doctor advice on this?

/Loa

On 2014-09-10 21:22, Gregory Mirsky wrote:
> 3032 and renamed it "Traffic Class" (TC). Below is the list of IEs 
> *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?)
>
> Regards,
>
>          Greg
>
>
>
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Sep 2014 11:53:36 +0200

Hi,

IEs are not used by MIB modules. Not sure this is relevant but
according to SMIv2 rules, you can't rename a Textual Convention (TC).
All you can do is create a new one and deprecate the old one. The
question is whether doing this is worth anything.

/js

On Fri, Sep 19, 2014 at 11:28:41AM +0200, Loa Andersson wrote:
> >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:
> >
> >·postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc
> >be created instead?)
> >
> >Regards,
> >
> >         Greg
> >
> >
> >
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 19 Sep 2014 11:28:41 +0200

Greg,

I'm not sure about this - would changing the names require updating all
existing deployed MIBs?

/Loa

--

---

From: "ietfdbh" <[email-masked]>
Date: Sun, 21 Sep 2014 00:30:16 -0400

Updating the description would be a problem if you change the semantics of
the object.

David Harrington
[email-masked]
+1-603-828-1401
> From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of
> t.petch
> Sent: Friday, September 19, 2014 7:50 AM
> To: Loa Andersson; Gregory Mirsky; [email-masked]
> Subject: Re: [MIB-DOCTORS] [mpls] MPLS IEs in IANA's IP Flow Information
> ----- Original Message -----
> From: "Loa Andersson" <[email-masked]>
> To: "Gregory Mirsky" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Friday, September 19, 2014 10:28 AM
> 
> Greg,
> 
> <tp>
> Yes. See RFC2578 s.10.  You cannot reuse an OID so this would need a new
> OID; messy, best left as one of those quaint, historic anomalies that
> litter our work.
> 
> Updating the DESCRIPTION and REFERENCE is not a problem  (but issuing
> any MIB module is a lot of work).
> 
> Tom Petch
> [not a MIB doctor]
> 
> 
> 
> 
> 3032
> > and renamed it "Traffic Class" (TC). Below is the list of IEs that may
> > .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?)
> >
> > Regards,
> >
> >          Greg
> >
> >
> >

---

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Sep 2014 14:25:16 +0200

We could argue whether the semantic was actually changed since the EXP 
bits were used for QoS.
Anyway, let's quote Jürgen: "The question is whether doing this is worth 
anything.". I'm not convinced...

Regards, Benoit
> .