From nobody Wed Sep 10 14:05:21 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205D91A86EB; Wed, 10 Sep 2014 12:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTyzLDBWDaX8; Wed, 10 Sep 2014 12:23:03 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA251A0659; Wed, 10 Sep 2014 12:23:02 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-55-54104d25e967 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B9.16.25146.52D40145; Wed, 10 Sep 2014 15:07:50 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 15:22:51 -0400 From: Gregory Mirsky To: "ipfix@ietf.org" Thread-Topic: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry Thread-Index: Ac/NKwbd4PEEn4EDQnes99jLrEnN8A== Date: Wed, 10 Sep 2014 19:22:51 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B82E898eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyuXSPt66ar0CIwZuT7BbHrr5mt7i1dCWr A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy9q//xlowObDi38LfTA2MJz26GDk5JARMJHY+fcIK YYtJXLi3nq2LkYtDSOAoo8S6zf2MEM5yRokDkzrZQKrYBIwkXmzsYQexRQRUJWZ2nmTpYuTg YBZQljh1VwYkLCwQJHH+2RqoknCJ3R+WsUHYehIfdi8FW8YC1NqwZg5YDa+Ar8Sps5cZQWxG oCO+n1rDBGIzC4hL3HoynwniOAGJJXvOM0PYohIvH/+DOlpJYtLSc6wQJ+RLbFkUDTFSUOLk zCcsExiFZyGZNAuhahaSKogSHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqR 4SZGYFwck2Bz3MG44JPlIUYBDkYlHl4FB/4QIdbEsuLK3EOM0hwsSuK8mtXzgoUE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUwMgrmlYf/0eS9Ghg+TetUfyOPnU75qqmLziovLVzGsWR6+Jv5 qW6qieWuv1N4FfLXK0YEJGpX9y8/ZVTJrCJ98fmkPH8r3pzZG9gEXX028DK7+vC5lR/Rsryl 0xrtqHp1wqov3dxZtfKugbLzq19d/njzr+j7n5KMVbZrTb87NN6/vqHO4I4SS3FGoqEWc1Fx IgDe/iBLbAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/POpxAEnQc-ky0kgtZ_WAQqvk-eM X-Mailman-Approved-At: Wed, 10 Sep 2014 14:05:20 -0700 Cc: "mpls@ietf.org" Subject: [IPFIX] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 19:23:05 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82E898eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, in several places of describing MPLS Label element IEs the registry still r= efers to the EXP field even though the RFC 5462 updated RFC 3032 and rename= d it "Traffic Class" (TC). Below is the list of IEs that may benefit from u= pdating 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 postMplsTopLab= elTc be created instead?) Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B82E898eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

in several places of describing MPLS Label element I= Es the registry still refers to the EXP field even though the RFC 5462 upda= ted 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 a= nd mplsTopLabelTc be created instead?)

·         postMplsTopLabelExp (should this be deprecat= ed and postMplsTopLabelTc be created instead?)

 

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B82E898eusaamb103erics_-- From nobody Wed Sep 10 14:24:53 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C141A0149 for ; Wed, 10 Sep 2014 14:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.291 X-Spam-Level: X-Spam-Status: No, score=-3.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFLAJLXySBTm for ; Wed, 10 Sep 2014 14:24:50 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79421A010A for ; Wed, 10 Sep 2014 14:24:49 -0700 (PDT) Received: from [10.1.14.85] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 10 Sep 2014 17:24:48 -0400 Message-ID: <5410C1A7.6000509@plixer.com> Date: Wed, 10 Sep 2014 17:24:55 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> Content-Type: multipart/alternative; boundary="------------080604040202030205070107" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/rR9TvcoYYTwKCvEhNMMP5g_i7JY Cc: gregory.mirsky@ericsson.com Subject: Re: [IPFIX] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 21:24:52 -0000 --------------080604040202030205070107 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit 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 --------------080604040202030205070107 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit
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
--------------080604040202030205070107-- From nobody Wed Sep 10 14:29:00 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A498D1A0164 for ; Wed, 10 Sep 2014 14:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIxREg87ko9U for ; Wed, 10 Sep 2014 14:28:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFE61A0194 for ; Wed, 10 Sep 2014 14:28:38 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-cb-54106d04ed33 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DD.F9.05330.40D60145; Wed, 10 Sep 2014 17:23:49 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 17:28:36 -0400 From: Gregory Mirsky To: Andrew Feren , "ipfix@ietf.org" Thread-Topic: [IPFIX] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry Thread-Index: Ac/NKwbd4PEEn4EDQnes99jLrEnN8AANCpyAAAheLuA= Date: Wed, 10 Sep 2014 21:28:36 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> In-Reply-To: <5410C1A7.6000509@plixer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B82EA53eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXSPty5rrkCIwb7tbBbPZq1gtTh29TW7 A5PHkiU/mTxO7t/GHMAUxWWTkpqTWZZapG+XwJXx7n1Ewe12xorNn36xNjC2VHYxcnJICJhI fP95lAXCFpO4cG89G4gtJHCUUeLzPKAaLiB7OaNEw4VzjCAJNgEjiRcbe9hBbBEBD4kj23aC NQsLxEkc7P7CDBGPlzjWNJcVwraSuDBnGVA9BweLgKrEtr3JIGFeAV+Jzw87WCB25UocebkF rJVTQEtiZss+sPGMQPd8P7WGCcRmFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCmErSUxaeo4V oj5fYuK+e+wQuwQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMji CxjZVzFylBanluWmGxlsYgTGzjEJNt0djHteWh5iFOBgVOLhVXDgDxFiTSwrrsw9xCjNwaIk zjurdl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaV0jI1+ha5S7d2p1RLLjVdrVph/kDa Szmyekp6iVRVQUL+r5ZPrVcn/Tjztln20Wsr966T59dt/ZvkmnFxJ9uGS/bfm6TmXXvQ1rG7 n++Oajrr6ucvG5PMlU58PHz2qOjpjYulRLwimx7pcyw5Irb76dJ1t7jatn86ed7wi3STzYJz V+pWh4UrsRRnJBpqMRcVJwIATk9ypX4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/v6vODEVY2o-xnraVpSbQ7cLr290 Subject: Re: [IPFIX] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 21:28:58 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82EA53eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 r= efers to the EXP field even though the RFC 5462 updated RFC 3032 and rename= d it "Traffic Class" (TC). Below is the list of IEs that may benefit from u= pdating 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 postMplsTopLab= elTc be created instead?) Did 5462 change just the name from Exp to TC or did the interpretation of t= he bits change? -Andrew --_000_7347100B5761DC41A166AC17F22DF1121B82EA53eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andrew,<= /span>

you’re right, th= e RFC 5462 changed the interpretation of this field as well (section 2 Deta= ils of Change):

2.1.  RFC 3032

 

 

   RFC 3032 states on page = 4:

 

      3.  E= xperimental Use

 

      This three= -bit field is reserved for experimental use.

 

   This paragraph is now change= d to:

 

      3.  T= raffic Class (TC) field

 

      This three= -bit field is used to carry traffic class information,

      and the ch= ange of the name is applicable to all places it occurs

      in IETF RF= Cs and other IETF documents.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   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 I= Es the registry still refers to the EXP field even though the RFC 5462 upda= ted 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 a= nd mplsTopLabelTc be created instead?)

·         postMplsTopLabelExp (should this be deprecat= ed and postMplsTopLabelTc be created instead?)


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

-Andrew

--_000_7347100B5761DC41A166AC17F22DF1121B82EA53eusaamb103erics_-- From nobody Wed Sep 10 14:43:20 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9C81A0184 for ; Wed, 10 Sep 2014 14:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLqUKfg0XK7H for ; Wed, 10 Sep 2014 14:43:16 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2291A0105 for ; Wed, 10 Sep 2014 14:43:16 -0700 (PDT) Received: from [10.1.14.85] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 10 Sep 2014 17:43:15 -0400 Message-ID: <5410C5F9.9030307@plixer.com> Date: Wed, 10 Sep 2014 17:43:21 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Gregory Mirsky , "ipfix@ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> Content-Type: multipart/alternative; boundary="------------090707040204090105040702" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/teOfsm_RS9Qepq-mN7iGCVuPfBk Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 21:43:18 -0000 --------------090707040204090105040702 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit 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 > --------------090707040204090105040702 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit
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


--------------090707040204090105040702-- From nobody Wed Sep 10 23:07:03 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B1C1A0479 for ; Wed, 10 Sep 2014 23:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.752 X-Spam-Level: X-Spam-Status: No, score=-14.752 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEFdLSl-zbBr for ; Wed, 10 Sep 2014 23:06:56 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E051A0473 for ; Wed, 10 Sep 2014 23:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24200; q=dns/txt; s=iport; t=1410415615; x=1411625215; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=zXjLI/J2CMPqnlxaaHp5EudfZ2gZM4YOT4vJcT3B7sk=; b=BBGdUoBzHM+xzJ85sVYX9WUJPCX9gaV/4pHtKXNQ/egyx8l4RRBorEyx BHAbWPjTv7Ald5DqQfd9hTZowATDGVzCz/IDjnqClVcrncnpKfeqx2n3l S28jB3f/MeROZfmMb7eRNm8by0/mvgp+VoLQIj/O5Zl68J5H83ZZLA+qv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEHAOE6EVStJssW/2dsb2JhbABggkeBGVeIV792AQmHTQGBI3iEAwEBAQMBAQEBKkEKBgsLEQQBAQEJFgEDBAcJAwIBAgEVHwkIBgEMBgIBAQWIMQgNv0oBF49TAYRMAQSGTo8rhwOBX4VkhH+Id4IbgUg7LwGCTgEBAQ X-IronPort-AV: E=Sophos;i="5.04,504,1406592000"; d="scan'208,217";a="169131813" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 11 Sep 2014 06:06:52 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8B66qKp005374; Thu, 11 Sep 2014 06:06:52 GMT Message-ID: <54113BFC.3050507@cisco.com> Date: Thu, 11 Sep 2014 08:06:52 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Andrew Feren , Gregory Mirsky , "ipfix@ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> In-Reply-To: <5410C5F9.9030307@plixer.com> Content-Type: multipart/alternative; boundary="------------040906030400060005060804" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/GfOl0V6t1fSJJsoPj_rni1u29Uc Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 06:07:00 -0000 This is a multi-part message in MIME format. --------------040906030400060005060804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 --------------040906030400060005060804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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

--------------040906030400060005060804-- From nobody Wed Sep 10 23:21:12 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EFD1A04AC for ; Wed, 10 Sep 2014 23:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4knm09CwDOw8 for ; Wed, 10 Sep 2014 23:21:06 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0E31A01FF for ; Wed, 10 Sep 2014 23:21:06 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-49-5410e7584e44 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id EC.D8.25146.857E0145; Thu, 11 Sep 2014 02:05:45 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 02:20:56 -0400 From: Gregory Mirsky To: Benoit Claise , Andrew Feren , "ipfix@ietf.org" Thread-Topic: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry Thread-Index: AQHPzYaYrrunPYBzBEmYIYOwkkQ7kpv7c72w Date: Thu, 11 Sep 2014 06:20:54 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82ED47@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> In-Reply-To: <54113BFC.3050507@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B82ED47eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXSPt27kc4EQg00/BSyezVrBanH0sYTF sauv2R2YPab83sjqsWTJTyaPk/u3MQcwR3HZpKTmZJalFunbJXBlrDw8k61gwgnGipMn9rM3 MF7dwNjFyMkhIWAiMb/rOzOELSZx4d56ti5GLg4hgaOMEsdf9LFCOMsZJf5efQpWxSZgJPFi Yw87iC0ikCuxpeEKK4gtLJAn0fa7j6mLkQMoni/RfikZwjSS6D0ZD1LBIqAqMW33HSYQm1fA V+LEp6/MEOPfMUrM3PAObDyngKbE29WfwYoYgQ76fmoNmM0sIC5x68l8JohDBSSW7DkPdbSo xMvH/1ghbCWJj7/ns4PsZQY64e1VR4hdghInZz5hmcAoMgvJpFkIVbOQVEGU6Egs2P2JDcLW lli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDcxAuPpmASb4w7GBZ8sDzEKcDAq8fA+OCkQ IsSaWFZcmXuIUZqDRUmcV7N6XrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRs4ZH67ZvV28 L0X58ufwq0e27TS8cvhu7pqy+AXyp2adY3d5d1+7+aPWU+7t2XtTbJ/2zT8lHc6xdqPVp8sC pSUzvLK9MtlOqBotc1nmHZ7dfe92068r1y5OcVK+JnKuhil008o1uo9bzy0+z2qfmx+d+jXu QeOXmsXvKn8f4Esyqc45/5Uha5USS3FGoqEWc1FxIgCasCfFiAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/KmDzjmUiSEjo5n_1FifNs0ViiVk Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 06:21:10 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82ED47eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 the= se IEs been defined in RFC 5102 (published January 2008). Your suggestions greatly appreciated. Regards, Greg From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Wednesday, September 10, 2014 11:07 PM To: Andrew Feren; Gregory Mirsky; ipfix@ietf.org 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 e= xporter 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 imm= ediately before the label stack entry that would be reported by mplsTopLabe= lStackSection. See the definition of mplsTopLabelStackSection for further d= etails. 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 i= mmediately before the label stack entry that would be reported by mplsTopLa= belStackSection. 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 r= efers to the EXP field even though the RFC 5462 updated RFC 3032 and rename= d it "Traffic Class" (TC). Below is the list of IEs that may benefit from u= pdating 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 postMplsTopLab= elTc be created instead?) Did 5462 change just the name from Exp to TC or did the interpretation of t= he bits change? -Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --_000_7347100B5761DC41A166AC17F22DF1121B82ED47eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benoit,<= /span>

I’d prefer an up= date to existing IEs as well. All but two IEs can corrected by updating the= ir Description and References. Do you think Name of two can be updated in t= he same manner? Errata doesn’t seem as the right way as these IEs been defined in RFC 5102 (published January 2008).<= o:p>

 

Your suggestions great= ly appreciated.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Wednesday, September 10, 2014 11:07 PM
To: Andrew Feren; Gregory Mirsky; ipfix@ietf.org
Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Info= rmation 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 e= xporter 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 mplsTopL= abelStackSection. See the definition of mplsTopLabelStackSection for furthe= r 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 immed= iately before the label stack entry that would be reported by mplsTopLabelS= tackSection. See the definition of mplsTopLabelStackSection for further det= ails.

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, th= e RFC 5462 changed the interpretation of this field as well (section 2 Deta= ils of Change):

2.1. = ; RFC 3032=

 

 

   RFC 3032 states on page = 4:

 

   &nbs= p;  3.  Experimental Use

 

   &nbs= p;  This three-bit field is reserved for experimental use.=

 

   This para= graph is now changed to:

 

   &nbs= p;  3.  Traffic Class (TC) field

 

   &nbs= p;  This three-bit field is used to carry traffic class information,

   &nbs= p;  and the change of the name is applicable to all places it occurs

   &nbs= p;  in IETF RFCs and other IETF documents.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   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 I= Es the registry still refers to the EXP field even though the RFC 5462 upda= ted 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 a= nd mplsTopLabelTc be created instead?)

·         postMplsTopLabelExp (should this be deprecat= ed and postMplsTopLabelTc be created instead?)


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

-Andrew





_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ie=
tf.org/mailman/listinfo/ipfix

 

--_000_7347100B5761DC41A166AC17F22DF1121B82ED47eusaamb103erics_-- From nobody Wed Sep 10 23:32:25 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D101A048E for ; Wed, 10 Sep 2014 23:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t4aNi4_mXBT for ; Wed, 10 Sep 2014 23:32:21 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB411A01FF for ; Wed, 10 Sep 2014 23:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32378; q=dns/txt; s=iport; t=1410417141; x=1411626741; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=vk5t/88Mq2rghHSFh/j5OHN0QZeSUFQPNitHPumjT4M=; b=aXqiX0IyfcYlPEF8jNRbhmKDdqxfNMz51bLrea6mHn3xoi5PMOx/up3U 3Hl0TuLWzfvK8qHkp6d4NLKhjqyyn2I74/4DtklTR15XN0/tOYykTlCXi GP2f0TXAfS/9Ej9LHe4nBDt+64QyLUfY8uAPVMOtGGPKDyIkm5MUbbgBI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwHAHRBEVStJssW/2dsb2JhbABggkeBGVeIV74XgV8BCYdNAYEgeIQDAQEBBAEBASpBChELEQQBAQEJFgEBAgQHCQMCAQIBFR8JCAYBDAYCAQEFiDkNv0gBF45rEQFWAYRMBYZOjyuHA4FfhWSEf4h3ghuBSDsvAYEOgUABAQE X-IronPort-AV: E=Sophos;i="5.04,504,1406592000"; d="scan'208,217";a="173922226" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 11 Sep 2014 06:32:18 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8B6WH7n021260; Thu, 11 Sep 2014 06:32:17 GMT Message-ID: <541141F0.9050703@cisco.com> Date: Thu, 11 Sep 2014 08:32:17 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Gregory Mirsky , Andrew Feren , "ipfix@ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> <7347100B5761DC41A166AC17F22DF1121B82ED47@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82ED47@eusaamb103.ericsson.se> Content-Type: multipart/alternative; boundary="------------070202020705030509030001" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/_ICpTvrS_L5UgAH-3MTE1Io_5e0 Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 06:32:25 -0000 This is a multi-part message in MIME format. --------------070202020705030509030001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 ] is the current complete reference for IPFIX Information Elements. The initial values for this registry were provided by [RFC5102 ]. Regards, Benoit. > > Your suggestions greatly appreciated. > > Regards, > > Greg > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Wednesday, September 10, 2014 11:07 PM > *To:* Andrew Feren; Gregory Mirsky; ipfix@ietf.org > *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? :-) > > 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 > --------------070202020705030509030001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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] is the
   current complete reference for IPFIX Information Elements.  The
   initial values for this registry were provided by [RFC5102].

Regards, Benoit.

 

Your suggestions greatly appreciated.

 

                Regards,

                                Greg

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Wednesday, September 10, 2014 11:07 PM
To: Andrew Feren; Gregory Mirsky; ipfix@ietf.org
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? :-)

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

 


--------------070202020705030509030001-- From nobody Wed Sep 10 23:40:18 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AF11A04D2; Wed, 10 Sep 2014 23:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na39d7pxkA2e; Wed, 10 Sep 2014 23:40:12 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C04DE1A04B4; Wed, 10 Sep 2014 23:40:11 -0700 (PDT) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 49A0F1A00B1; Thu, 11 Sep 2014 08:40:10 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_E649ED3D-C730-419C-ACD1-C32644223B2D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <54113BFC.3050507@cisco.com> Date: Thu, 11 Sep 2014 08:40:09 +0200 Message-Id: <3F00C681-E3DA-4B1B-8F2F-B1341DDE95F1@trammell.ch> References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/jKqHPudFk8ek8CGFecIw3JyFWhQ Cc: Gregory Mirsky , ie-doctors@ietf.org, "ipfix@ietf.org" Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 06:40:15 -0000 --Apple-Mail=_E649ED3D-C730-419C-ACD1-C32644223B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 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? :-) >=20 > 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. >=20 >=20 > The size of this Information Element is 3 octets. >=20 > NEW: >=20 > 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. >=20 >=20 > The size of this Information Element is 3 octets. >=20 > And change > - the reference from RFC3032 to RFC5462 > - the revision +1 >=20 > Regards, Benoit >=20 >=20 >=20 >=20 >> Then perhaps the right thing is to deprecate the lot and replace them = all. >>=20 >> Thanks, >> -Andrew >>=20 >> On 09/10/2014 05:28 PM, Gregory Mirsky wrote: >>> Hi Andrew, >>> you=92re right, the RFC 5462 changed the interpretation of this = field as well (section 2 Details of Change): >>> 2.1. RFC 3032 >>> =20 >>> =20 >>> RFC 3032 states on page 4: >>> =20 >>> 3. Experimental Use >>> =20 >>> This three-bit field is reserved for experimental use. >>> =20 >>> This paragraph is now changed to: >>> =20 >>> 3. Traffic Class (TC) field >>> =20 >>> 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. >>> =20 >>> Regards, >>> Greg >>> =20 >>> From: Andrew Feren [mailto:andrewf@plixer.com]=20 >>> 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 >>> =20 >>> Hi Greg, >>>=20 >>> 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 =93Traffic Class=94 (TC). Below is the list of IEs that = may benefit from updating Description and Reference information: >>> =B7 mplsTopLabelStackSection >>> =B7 mplsTopLabelStackSection2 >>> =B7 mplsTopLabelStackSection3 >>> =B7 mplsTopLabelStackSection4 >>> =B7 mplsTopLabelStackSection5 >>> =B7 mplsTopLabelStackSection6 >>> =B7 mplsTopLabelStackSection7 >>> =B7 mplsTopLabelStackSection8 >>> =B7 mplsTopLabelStackSection9 >>> =B7 mplsTopLabelStackSection10 >>> =B7 mplsTopLabelExp (should this be deprecated and = mplsTopLabelTc be created instead?) >>> =B7 postMplsTopLabelExp (should this be deprecated and = postMplsTopLabelTc be created instead?) >>>=20 >>> Did 5462 change just the name from Exp to TC or did the = interpretation of the bits change? >>>=20 >>> -Andrew >>=20 >>=20 >>=20 >> _______________________________________________ >> IPFIX mailing list >>=20 >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_E649ED3D-C730-419C-ACD1-C32644223B2D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUEUPJAAoJENt3nsOmbNJcdJQH/1q2PQ7AIi/qjaoRADUOc1EN zVp6n5+N9mV4j23PQTHxjH5symGEM1O1GCBDxoAVkcThNdRdUZE4Po7xY6StQaNm gVOH6CbdzGyOvZ8DuuHEcTxCFRMAJ+x6P/yLVA/2WXr7yYKvX+usbUFqXUGnq97h vV/yMhTtctNU3L//PX+lUcDU80Dvs2SLli2pPridoAXtysmNaFpbIDWeIzsTx6TT 1npeWYX8olyekOWTamIHHOs+nNS1oZtDRm6dM4IPzEdY9z6b8z1TJUZU6aDuGp3s ae+3UW0apePQCGljsbcrgtwMWGe3/GRIC4beF/XeDjuagroEBzmMvbrZGuvibnk= =kQKT -----END PGP SIGNATURE----- --Apple-Mail=_E649ED3D-C730-419C-ACD1-C32644223B2D-- From nobody Thu Sep 11 00:39:06 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DED21A06C9; Thu, 11 Sep 2014 00:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veAf7hJwJW1Q; Thu, 11 Sep 2014 00:39:01 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA08F1A0601; Thu, 11 Sep 2014 00:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5611; q=dns/txt; s=iport; t=1410421143; x=1411630743; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2porvOWsdQ0lGNxTehKIoevjIR4Agf+r19uj5o2JlGg=; b=H06mUxVwQvdEaShPzIfzQQlt84kawVw95Nqv94xuyPx06817w/KzjI9g RwJDMQz8EFE9HfH4GlAnB0yK9JgbpPgCPXMMcBrCXXHOX9HiU5ii7wzgV frLEW6gY7XK/PlzgkCDTpTu7RwFcgu9vgekjZzn9B2nAqMhQTlgC3Xdn1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEACZREVStJssW/2dsb2JhbABgg2BXyCgKh00BgSB4hAMBAQEDAQEBAS8BBTYKARALDgMEAQEBCRYEBAcJAwIBAgEVHwkIBg0BBQIBAYg2CA2/VwEXj00HhEwBBJV5hwOBX4VkhH+Id4IbgUg7LwGCTgEBAQ X-IronPort-AV: E=Sophos;i="5.04,504,1406592000"; d="scan'208";a="169208449" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 11 Sep 2014 07:39:00 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8B7cw2X032193; Thu, 11 Sep 2014 07:38:58 GMT Message-ID: <54115192.7010204@cisco.com> Date: Thu, 11 Sep 2014 09:38:58 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Brian Trammell References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> <3F00C681-E3DA-4B1B-8F2F-B1341DDE95F1@trammell.ch> In-Reply-To: <3F00C681-E3DA-4B1B-8F2F-B1341DDE95F1@trammell.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/EQ1w5QoVB_kdBz1653LdbfK9eNg Cc: Gregory Mirsky , ie-doctors@ietf.org, "ipfix@ietf.org" Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 07:39:03 -0000 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 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 From nobody Thu Sep 11 00:43:45 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3361A063B; Thu, 11 Sep 2014 00:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tlMhQ6x8ftx; Thu, 11 Sep 2014 00:43:41 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 36FE11A0601; Thu, 11 Sep 2014 00:43:41 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::1008] (unknown [IPv6:2001:67c:10ec:2a49:8000::1008]) by trammell.ch (Postfix) with ESMTPSA id 3F3521A08CD; Thu, 11 Sep 2014 09:43:10 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_45761199-D38B-4444-94B2-97AAB5B5D838"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <54115192.7010204@cisco.com> Date: Thu, 11 Sep 2014 09:42:58 +0200 Message-Id: <5A7017D1-99F2-4287-A251-564041F65BB7@trammell.ch> References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> <3F00C681-E3DA-4B1B-8F2F-B1341DDE95F1@trammell.ch> <54115192.7010204@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/pSvQdmBeftuntrPZ4EC3dI5wBok Cc: Gregory Mirsky , ie-doctors@ietf.org, "ipfix@ietf.org" Subject: Re: [IPFIX] [Ie-doctors] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 07:43:43 -0000 --Apple-Mail=_45761199-D38B-4444-94B2-97AAB5B5D838 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 11 Sep 2014, at 09:38, Benoit Claise wrote: > On 11/09/2014 08:40, Brian Trammell wrote: >> hi Benoit, Greg, >>=20 >> This change looks to be interoperable to me under Section 5.2 of = 7103, points 5 and 7. 7 seems clear: >>=20 >> (7) it harmonizes with an external reference that was itself = corrected. >>=20 >> 5 is less so: >>=20 >> (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 >>=20 >> 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". >>=20 >> (Perhaps we should file a technical erratum for the next 7013 = revision changing point 5 to reflect this; i.e. NEW: ) >>=20 >> (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. >=20 >>=20 >>=20 >> 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? Yep. > Regards, Benoit >>=20 >> Cheers, >>=20 >> Brian >>=20 >> On 11 Sep 2014, at 08:06, Benoit Claise wrote: >>=20 >>> 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? :-) >>>=20 >>> 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. >>>=20 >>>=20 >>> The size of this Information Element is 3 octets. >>>=20 >>> NEW: >>>=20 >>> 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. >>>=20 >>>=20 >>> The size of this Information Element is 3 octets. >>>=20 >>> And change >>> - the reference from RFC3032 to RFC5462 >>> - the revision +1 >>>=20 >>> Regards, Benoit >>>=20 >>>=20 >>>=20 >>>=20 >>>> Then perhaps the right thing is to deprecate the lot and replace = them all. >>>>=20 >>>> Thanks, >>>> -Andrew >>>>=20 >>>> On 09/10/2014 05:28 PM, Gregory Mirsky wrote: >>>>> Hi Andrew, >>>>> you=92re 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, >>>>>=20 >>>>> 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 =93Traffic Class=94 (TC). Below is the list of = IEs that may benefit from updating Description and Reference = information: >>>>> =B7 mplsTopLabelStackSection >>>>> =B7 mplsTopLabelStackSection2 >>>>> =B7 mplsTopLabelStackSection3 >>>>> =B7 mplsTopLabelStackSection4 >>>>> =B7 mplsTopLabelStackSection5 >>>>> =B7 mplsTopLabelStackSection6 >>>>> =B7 mplsTopLabelStackSection7 >>>>> =B7 mplsTopLabelStackSection8 >>>>> =B7 mplsTopLabelStackSection9 >>>>> =B7 mplsTopLabelStackSection10 >>>>> =B7 mplsTopLabelExp (should this be deprecated and = mplsTopLabelTc be created instead?) >>>>> =B7 postMplsTopLabelExp (should this be deprecated and = postMplsTopLabelTc be created instead?) >>>>>=20 >>>>> Did 5462 change just the name from Exp to TC or did the = interpretation of the bits change? >>>>>=20 >>>>> -Andrew >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPFIX mailing list >>>>=20 >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > ie-doctors mailing list > ie-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/ie-doctors --Apple-Mail=_45761199-D38B-4444-94B2-97AAB5B5D838 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUEVKNAAoJENt3nsOmbNJcDloH/iDnRhBQ/Xw2jQbUwuKPFxCz tuCsK0pHv8+XbeGE+0FGcERepYhwao/nBfZOYV2H8x/GJj6LdMudbMRhcoihZQLs sq4vYtR8eU5zkvCMHOfxifjt6KcuwXG6laCitXoSuL81fA+2FyoDMYkl/J7Cucyj hKdWzHJBrVc+LfY74wNmb+yCQJCjKS2SsOgjf5CMurVB1W0dJRNDqUcKm1TSqFMo lnsQ0xKCPFlC6071YXJ0vZ5geC/UkizUOKHhxZbPFed0MWisHEcKd8fugXLoHkFj 8rEi+7Ee478ApkB/K5LIqGUE8zGd5H2rdQPgBHgF7JzVZo69YwXxoyK0Bhlx72o= =Uspu -----END PGP SIGNATURE----- --Apple-Mail=_45761199-D38B-4444-94B2-97AAB5B5D838-- From nobody Thu Sep 11 04:06:55 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1D71A893E for ; Thu, 11 Sep 2014 04:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjmalQOFD3WB for ; Thu, 11 Sep 2014 04:06:50 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EAD81A8924 for ; Thu, 11 Sep 2014 04:06:49 -0700 (PDT) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0181.006; Thu, 11 Sep 2014 07:06:48 -0400 From: Andrew Feren To: Benoit Claise , Gregory Mirsky , "ipfix@ietf.org" Thread-Topic: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry Thread-Index: AQHPzYaiZ1ddE2nNUECh3SyxCUPORpv7xRaL Date: Thu, 11 Sep 2014 11:06:47 +0000 Message-ID: <8E7542283B89BB4DB672EB49CEE5AAB70682D90D@PLXRDC01.plxr.local> References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com>,<54113BFC.3050507@cisco.com> In-Reply-To: <54113BFC.3050507@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.91.78.244] Content-Type: multipart/alternative; boundary="_000_8E7542283B89BB4DB672EB49CEE5AAB70682D90DPLXRDC01plxrloc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/m4gvHrrTAREsWIpla2OUgvH6Beo Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 11:06:53 -0000 --_000_8E7542283B89BB4DB672EB49CEE5AAB70682D90DPLXRDC01plxrloc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 depre= cate all of them. -Andrew ________________________________ From: Benoit Claise [bclaise@cisco.com] Sent: Thursday, September 11, 2014 2:06 AM To: Andrew Feren; Gregory Mirsky; ipfix@ietf.org 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 e= xporter 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 imm= ediately before the label stack entry that would be reported by mplsTopLabe= lStackSection. See the definition of mplsTopLabelStackSection for further d= etails. 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 i= mmediately before the label stack entry that would be reported by mplsTopLa= belStackSection. 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=92re right, the RFC 5462 changed the interpretation of this field as we= ll (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 r= efers to the EXP field even though the RFC 5462 updated RFC 3032 and rename= d it =93Traffic Class=94 (TC). Below is the list of IEs that may benefit fr= om updating Description and Reference information: =B7 mplsTopLabelStackSection =B7 mplsTopLabelStackSection2 =B7 mplsTopLabelStackSection3 =B7 mplsTopLabelStackSection4 =B7 mplsTopLabelStackSection5 =B7 mplsTopLabelStackSection6 =B7 mplsTopLabelStackSection7 =B7 mplsTopLabelStackSection8 =B7 mplsTopLabelStackSection9 =B7 mplsTopLabelStackSection10 =B7 mplsTopLabelExp (should this be deprecated and mplsTopLabelTc b= e created instead?) =B7 postMplsTopLabelExp (should this be deprecated and postMplsTopL= abelTc be created instead?) Did 5462 change just the name from Exp to TC or did the interpretation of t= he bits change? -Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --_000_8E7542283B89BB4DB672EB49CEE5AAB70682D90DPLXRDC01plxrloc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Benoit,

Thanks for the clarification.  I don't really know the RFCs in questio= n and took the previous reply that the interpretation of the bits had chang= ed at face value.

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

-Andrew

From: Benoit Claise [bclaise@cisco.com] Sent: Thursday, September 11, 2014 2:06 AM
To: Andrew Feren; Gregory Mirsky; ipfix@ietf.org
Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Info= rmation 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 e= xporter 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 mplsTopL= abelStackSection. See the definition of mplsTopLabelStackSection for furthe= r 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 immed= iately before the label stack entry that would be reported by mplsTopLabelS= tackSection. See the definition of mplsTopLabelStackSection for further det= ails.

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=92re right, the RF= C 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.&n= bsp; Experimental Use

 

      This= three-bit field is reserved for experimental use.

 

   This paragraph is now = changed to:

 

      3.&n= bsp; 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 I= ETF RFCs and other IETF documents.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Andrew Feren [mailto:andrewf@pli= xer.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 I= Es the registry still refers to the EXP field even though the RFC 5462 upda= ted RFC 3032 and renamed it =93Traffic Class=94 (TC). Below is the list of = IEs that may benefit from updating Description and Reference information:

=B7         mplsTopLabelStackSection

=B7         mplsTopLabelStackSection2

=B7         mplsTopLabelStackSection3

=B7         mplsTopLabelStackSection4

=B7         mplsTopLabelStackSection5

=B7         mplsTopLabelStackSection6

=B7         mplsTopLabelStackSection7

=B7         mplsTopLabelStackSection8

=B7         mplsTopLabelStackSection9

=B7         mplsTopLabelStackSection10

=B7         mplsTopLabelExp (should this be deprecated and mplsTop= LabelTc be created instead?)

=B7         postMplsTopLabelExp (should this be deprecated and pos= tMplsTopLabelTc be created instead?)


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

-Andrew




_______________________________________________=0A=
IPFIX mailing list=0A=
IPFIX@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/ipfix<=
/a>=0A=

--_000_8E7542283B89BB4DB672EB49CEE5AAB70682D90DPLXRDC01plxrloc_-- From nobody Thu Sep 11 09:17:03 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614231ACCEE; Thu, 11 Sep 2014 09:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sJfN06CcEWM; Thu, 11 Sep 2014 09:16:39 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A7F1ACC88; Thu, 11 Sep 2014 09:16:39 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-09-5411755b3eb0 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 26.C7.05330.B5571145; Thu, 11 Sep 2014 12:11:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 12:16:37 -0400 From: Gregory Mirsky To: Benoit Claise , Brian Trammell Thread-Topic: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry Thread-Index: AQHPzYaYrrunPYBzBEmYIYOwkkQ7kpv7vnaAgAAQbwCAAEysAA== Date: Thu, 11 Sep 2014 16:16:36 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82F09D@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> <3F00C681-E3DA-4B1B-8F2F-B1341DDE95F1@trammell.ch> <54115192.7010204@cisco.com> In-Reply-To: <54115192.7010204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPgm50qWCIweYLxhbPZq1gtTj6WMJi xYuDrBYbW96xWRy7+prdgdVjyu+NrB5Llvxk8ji5fxuzx5P9M1kCWKK4bFJSczLLUov07RK4 Mv4/n85UsMq4Ys6/2UwNjH/Uuxg5OSQETCRmXD3MBGGLSVy4t56ti5GLQ0jgKKPE9m9rmSGc 5YwS7xdOZQapYhMwknixsYcdxBYR8JD4uxuim1mgXOJvy2swW1ggT6Ltdx+QzQFUky/RfikZ otxJYtOX22CtLAKqEjMf7mIDsXkFfCUenJvLDrHrEJPE+3u3wXZxCmhKrJ29DcxmBLru+6k1 ULvEJW49mQ91tYDEkj3nmSFsUYmXj/+xQtiKEvv6p7ND1OtILNj9iQ3C1pZYtvA1M8RiQYmT M5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUVI0dpcWpZbrqRwSZGYFwdk2DT3cG456XlIUYBDkYl Ht4HJwVChFgTy4orcw8xSnOwKInzzqqdFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0Sss d+O2jQ7T0hmO32zPuT1PZ+vPpRdLLuccfx86yyhQ9+285e0LzTe3h7lu3fE5+TLDk1Wznpq+ qHtsaLyoIHvn6Yu3vi+dx7Mq5NGPs8kGTb23fykUvNgftFnTeM7Czbwa7yWcRbZUPTbOi1K0 +MAaeXuG+juD1DyxLw92+m6Z2ywmzW/w0l6JpTgj0VCLuag4EQDs9YdujAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/O0ZsLs-fqS8fx_7BBA2UGxsH8W8 Cc: "ie-doctors@ietf.org" , "ipfix@ietf.org" Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:16:49 -0000 Hi Benoit and Brian, do you mean that approach "That goes in the direction of updating the descr= iption/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 mplsTopLabelT= c be created instead?) >>>> * postMplsTopLabelExp (should this be deprecated and postMplsT= opLabelTc be created instead?) Regards, Greg -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com]=20 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, po= ints 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 u= nder 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=20 > 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=20 > deprecated and replaced with something slightly less broken (see 7013=20 > sections 4.6 and 4.9 paragraph 5). But it's hard to argue with an=20 > update to a set of IEs which corresponds to what any implementation=20 > will do _anyway_ without being updated (i.e. just keep copying those=20 > bits even though we have an agreement to believe they mean something=20 > different now.) That goes in the direction of updating the description/reference and leavin= g the name unchanged? Regards, Benoit > > Cheers, > > Brian > > On 11 Sep 2014, at 08:06, Benoit Claise wrote: > >> Two points: >> - The EXP bits have been used for QoS mapping for years, even before=20 >> 2009 (RFC 5462 publication date) >> - Do you believe that deprecating/replacing all these IEs will imply=20 >> that exporter implementations will update their code, just for new=20 >> ElementID? :-) >> >> I would use the procedure in=20 >> 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 mplsTopL= abelStackSection. See the definition of mplsTopLabelStackSection for furthe= r details. >> >> >> The size of this Information Element is 3 octets. >> >> NEW: >> >> The Label, Traffic Class (previously called Exp in RFC3032), and S field= s from the label stack entry that was pushed immediately before the label s= tack entry that would be reported by mplsTopLabelStackSection. See the defi= nition 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 a= ll. >>> >>> 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 >>>> =20 >>>> =20 >>>> RFC 3032 states on page 4: >>>> =20 >>>> 3. Experimental Use >>>> =20 >>>> This three-bit field is reserved for experimental use. >>>> =20 >>>> This paragraph is now changed to: >>>> =20 >>>> 3. Traffic Class (TC) field >>>> =20 >>>> This three-bit field is used to carry traffic class information= , >>>> and the change of the name is applicable to all places it occur= s >>>> in IETF RFCs and other IETF documents. >>>> =20 >>>> Regards, >>>> Greg >>>> =20 >>>> 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=20 >>>> (IPFIX) Entities registry >>>> =20 >>>> 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 st= ill refers to the EXP field even though the RFC 5462 updated RFC 3032 and r= enamed it "Traffic Class" (TC). Below is the list of IEs that may benefit f= rom updating Description and Reference information: >>>> * mplsTopLabelStackSection >>>> * mplsTopLabelStackSection2 >>>> * mplsTopLabelStackSection3 >>>> * mplsTopLabelStackSection4 >>>> * mplsTopLabelStackSection5 >>>> * mplsTopLabelStackSection6 >>>> * mplsTopLabelStackSection7 >>>> * mplsTopLabelStackSection8 >>>> * mplsTopLabelStackSection9 >>>> * mplsTopLabelStackSection10 >>>> * mplsTopLabelExp (should this be deprecated and mplsTopLabelT= c be created instead?) >>>> * postMplsTopLabelExp (should this be deprecated and postMplsT= opLabelTc 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 From nobody Thu Sep 11 22:25:43 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EBA1A0538; Thu, 11 Sep 2014 22:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgFJAy8qzaEB; Thu, 11 Sep 2014 22:25:36 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C45B91A0537; Thu, 11 Sep 2014 22:25:35 -0700 (PDT) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 6B9951A00AC; Fri, 12 Sep 2014 07:25:34 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_8CF2D361-2184-434E-B691-66D8D61D062A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82F09D@eusaamb103.ericsson.se> Date: Fri, 12 Sep 2014 07:25:31 +0200 Message-Id: References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> <3F00C681-E3DA-4B1B-8F2F-B1341DDE95F1@trammell.ch> <54115192.7010204@cisco.com> <7347100B5761DC41A166AC17F22DF1121B82F09D@eusaamb103.ericsson.se> To: Gregory Mirsky , "ie-doctors@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/SRPaYMKGnYSX0PxKZ3fiwOP-Rsg Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 05:25:39 -0000 --Apple-Mail=_8CF2D361-2184-434E-B691-66D8D61D062A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Greg, IE-Doctors, On 11 Sep 2014, at 18:16, Gregory Mirsky = wrote: > 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: >=20 >>>>> * mplsTopLabelExp (should this be deprecated and = mplsTopLabelTc be created instead?) >>>>> * 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,=20 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 > Regards, > Greg >=20 > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > 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 >=20 > On 11/09/2014 08:40, Brian Trammell wrote: >> hi Benoit, Greg, >>=20 >> This change looks to be interoperable to me under Section 5.2 of = 7103, points 5 and 7. 7 seems clear: >>=20 >> (7) it harmonizes with an external reference that was itself = corrected. >>=20 >> 5 is less so: >>=20 >> (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 >>=20 >> 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". >>=20 >> (Perhaps we should file a technical erratum for the next 7013 = revision=20 >> changing point 5 to reflect this; i.e. NEW: ) >>=20 >> (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. >=20 >>=20 >>=20 >> That said these IEs are a terrible hack and I'd love to see them=20 >> deprecated and replaced with something slightly less broken (see 7013=20= >> sections 4.6 and 4.9 paragraph 5). But it's hard to argue with an=20 >> update to a set of IEs which corresponds to what any implementation=20= >> will do _anyway_ without being updated (i.e. just keep copying those=20= >> bits even though we have an agreement to believe they mean something=20= >> different now.) > That goes in the direction of updating the description/reference and = leaving the name unchanged? >=20 > Regards, Benoit >>=20 >> Cheers, >>=20 >> Brian >>=20 >> On 11 Sep 2014, at 08:06, Benoit Claise wrote: >>=20 >>> Two points: >>> - The EXP bits have been used for QoS mapping for years, even before=20= >>> 2009 (RFC 5462 publication date) >>> - Do you believe that deprecating/replacing all these IEs will imply=20= >>> that exporter implementations will update their code, just for new=20= >>> ElementID? :-) >>>=20 >>> I would use the procedure in=20 >>> 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. >>>=20 >>>=20 >>> The size of this Information Element is 3 octets. >>>=20 >>> NEW: >>>=20 >>> 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. >>>=20 >>>=20 >>> The size of this Information Element is 3 octets. >>>=20 >>> And change >>> - the reference from RFC3032 to RFC5462 >>> - the revision +1 >>>=20 >>> Regards, Benoit >>>=20 >>>=20 >>>=20 >>>=20 >>>> Then perhaps the right thing is to deprecate the lot and replace = them all. >>>>=20 >>>> Thanks, >>>> -Andrew >>>>=20 >>>> 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 >>>>>=20 >>>>>=20 >>>>> RFC 3032 states on page 4: >>>>>=20 >>>>> 3. Experimental Use >>>>>=20 >>>>> This three-bit field is reserved for experimental use. >>>>>=20 >>>>> This paragraph is now changed to: >>>>>=20 >>>>> 3. Traffic Class (TC) field >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Regards, >>>>> Greg >>>>>=20 >>>>> 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=20= >>>>> (IPFIX) Entities registry >>>>>=20 >>>>> Hi Greg, >>>>>=20 >>>>> 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?) >>>>>=20 >>>>> Did 5462 change just the name from Exp to TC or did the = interpretation of the bits change? >>>>>=20 >>>>> -Andrew >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPFIX mailing list >>>>=20 >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >=20 --Apple-Mail=_8CF2D361-2184-434E-B691-66D8D61D062A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUEoPLAAoJENt3nsOmbNJcnUgH/j3KItyAPbZzn+fp/77p73K+ 4roaFAj82N0HhuflbWVjAaxETi7IUecS/b8o/7lp819WvQIplUK6w/WJMDGJFFmd 6hrUR53AfmppvmMDI58o5+BY6mDWXZ6X+fHLizifwWDKSDGJr8zmRe31BNL2umH4 ekFRCgj1N4BACp5J3h+dpapzZAC0ecNeQjToBbpEqGLClpOK3L779QLZ8D+s02pH YNs+V1BBMHPNdXD+51o3Ay69Pr9ncdnu0tC+FT5WrRhnEjOq4mdr6jjYMEmN5YfJ R+5E4cu+4fDIPSiYJK4Ehz8g4yCL0mmVcc8Dqejlp5CGngHVIcSUIM5YqBsME80= =fYR3 -----END PGP SIGNATURE----- --Apple-Mail=_8CF2D361-2184-434E-B691-66D8D61D062A-- From nobody Thu Sep 11 22:47:20 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F174F1A0647; Thu, 11 Sep 2014 22:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEUG1JHToubm; Thu, 11 Sep 2014 22:47:13 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A3D1A0644; Thu, 11 Sep 2014 22:47:13 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-a6-541230db12cf Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7E.8C.25146.BD032145; Fri, 12 Sep 2014 01:31:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Fri, 12 Sep 2014 01:47:03 -0400 From: Gregory Mirsky To: Brian Trammell , "ie-doctors@ietf.org" Thread-Topic: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry Thread-Index: AQHPzYaYrrunPYBzBEmYIYOwkkQ7kpv7vnaAgAAQbwCAAEysAIABIGCA///CN7A= Date: Fri, 12 Sep 2014 05:47:02 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8312B8@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> <3F00C681-E3DA-4B1B-8F2F-B1341DDE95F1@trammell.ch> <54115192.7010204@cisco.com> <7347100B5761DC41A166AC17F22DF1121B82F09D@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPlO5tA6EQgx3v9SyOPpawWPHiIKvF xpZ3bBbHrr5md2DxmPJ7I6vHkiU/mTye7J/JEsAcxWWTkpqTWZZapG+XwJWx6MUN1oItzhWv Lio3MLaZdjFyckgImEgceXGCCcIWk7hwbz1bFyMXh5DAUUaJnRu2skI4yxklWjZvZgepYhMw knixsQfMFhEIkXgwdSUziM0s4CFx9t1/RhBbWCBPou13H9BUDqCafIn2S8kQ5X4SvyYdBCth EVCVOLFxOgtICa+Ar0T7Dy6QsJDAbmaJLVOsQWxOAXuJGS1/2EBsRqDbvp9awwSxSVzi1pP5 UDcLSCzZc54ZwhaVePn4HyuErSixr386O0S9jsSC3Z/YIGxtiWULX4PV8woISpyc+YRlAqPY LCRjZyFpmYWkZRaSlgWMLKsYOUqLU8ty040MNzECo+eYBJvjDsYFnywPMQpwMCrx8D44KRAi xJpYVlyZe4hRmoNFSZxXs3pesJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGiv4HzcH3ZqqH njgWU2HsGrcz1HfNm2kcOefOzmEy333iv9ZfrjwBMwWb+bIed+JyhG4LP7rw3nA/0wHZYzlM hkydl7e9L89+yR17ZEZOtPJULraW5aclJznF3010L8pZ0s2snvnD6N0G4/yjTNMC587TnXzn gO00JpHpfXNSbC6vcu7UWxusxFKckWioxVxUnAgAQcp3hn8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/3LhwwmGloURoJ-q0Z9BzqVI-b18 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 05:47:16 -0000 Hi Brian, thank you, that will work. What would be in the Requester column if we're not updating the RFC 7012 (p= erhaps through Errata)? Regards, Greg -----Original Message----- From: Brian Trammell [mailto:ietf@trammell.ch]=20 Sent: Thursday, September 11, 2014 10:26 PM To: Gregory Mirsky; ie-doctors@ietf.org Cc: Benoit Claise; Andrew Feren; ipfix@ietf.org Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow Information= Export (IPFIX) Entities registry hi Greg, IE-Doctors, On 11 Sep 2014, at 18:16, Gregory Mirsky wrot= e: > Hi Benoit and Brian, > do you mean that approach "That goes in the direction of updating the des= cription/reference and leaving the name unchanged?" is sufficient for the t= wo IEs that have 'Exp' as part of their names: >=20 >>>>> * mplsTopLabelExp (should this be deprecated and mplsTopLabel= Tc be created instead?) >>>>> * postMplsTopLabelExp (should this be deprecated and postMpls= TopLabelTc be created instead?) Yep. The IEs will still be named (post)mplsTopLabelExp, but the language ch= anged 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 tha= t 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 wi= ll be changed to point to RFC5462. The text of postMplsTopLabelExp's descri= ption does not need to change. IE-Doctors: any problem with this change to the topLabelExp fields? I'd lik= e to call the question and send this up to IANA early next week. Cheers, Brian > Regards, > Greg >=20 > -----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=20 > Information Export (IPFIX) Entities registry >=20 > On 11/09/2014 08:40, Brian Trammell wrote: >> hi Benoit, Greg, >>=20 >> This change looks to be interoperable to me under Section 5.2 of 7103, p= oints 5 and 7. 7 seems clear: >>=20 >> (7) it harmonizes with an external reference that was itself correcte= d. >>=20 >> 5 is less so: >>=20 >> (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 >>=20 >> 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". >>=20 >> (Perhaps we should file a technical erratum for the next 7013=20 >> revision changing point 5 to reflect this; i.e. NEW: ) >>=20 >> (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. >=20 >>=20 >>=20 >> That said these IEs are a terrible hack and I'd love to see them=20 >> deprecated and replaced with something slightly less broken (see 7013=20 >> sections 4.6 and 4.9 paragraph 5). But it's hard to argue with an=20 >> update to a set of IEs which corresponds to what any implementation=20 >> will do _anyway_ without being updated (i.e. just keep copying those=20 >> bits even though we have an agreement to believe they mean something=20 >> different now.) > That goes in the direction of updating the description/reference and leav= ing the name unchanged? >=20 > Regards, Benoit >>=20 >> Cheers, >>=20 >> Brian >>=20 >> On 11 Sep 2014, at 08:06, Benoit Claise wrote: >>=20 >>> 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=20 >>> that exporter implementations will update their code, just for new=20 >>> ElementID? :-) >>>=20 >>> 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 mplsTop= LabelStackSection. See the definition of mplsTopLabelStackSection for furth= er details. >>>=20 >>>=20 >>> The size of this Information Element is 3 octets. >>>=20 >>> NEW: >>>=20 >>> The Label, Traffic Class (previously called Exp in RFC3032), and S fiel= ds from the label stack entry that was pushed immediately before the label = stack entry that would be reported by mplsTopLabelStackSection. See the def= inition of mplsTopLabelStackSection for further details. >>>=20 >>>=20 >>> The size of this Information Element is 3 octets. >>>=20 >>> And change >>> - the reference from RFC3032 to RFC5462 >>> - the revision +1 >>>=20 >>> Regards, Benoit >>>=20 >>>=20 >>>=20 >>>=20 >>>> Then perhaps the right thing is to deprecate the lot and replace them = all. >>>>=20 >>>> Thanks, >>>> -Andrew >>>>=20 >>>> On 09/10/2014 05:28 PM, Gregory Mirsky wrote: >>>>> Hi Andrew, >>>>> you're right, the RFC 5462 changed the interpretation of this field a= s well (section 2 Details of Change): >>>>> 2.1. RFC 3032 >>>>>=20 >>>>>=20 >>>>> RFC 3032 states on page 4: >>>>>=20 >>>>> 3. Experimental Use >>>>>=20 >>>>> This three-bit field is reserved for experimental use. >>>>>=20 >>>>> This paragraph is now changed to: >>>>>=20 >>>>> 3. Traffic Class (TC) field >>>>>=20 >>>>> This three-bit field is used to carry traffic class information= , >>>>> and the change of the name is applicable to all places it occur= s >>>>> in IETF RFCs and other IETF documents. >>>>>=20 >>>>> Regards, >>>>> Greg >>>>>=20 >>>>> 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 >>>>>=20 >>>>> Hi Greg, >>>>>=20 >>>>> On 09/10/2014 03:22 PM, Gregory Mirsky wrote: >>>>> Dear All, >>>>> in several places of describing MPLS Label element IEs the registry s= till 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 mplsTopLabel= Tc be created instead?) >>>>> * postMplsTopLabelExp (should this be deprecated and postMpls= TopLabelTc be created instead?) >>>>>=20 >>>>> Did 5462 change just the name from Exp to TC or did the interpretatio= n of the bits change? >>>>>=20 >>>>> -Andrew >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPFIX mailing list >>>>=20 >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >=20 From nobody Fri Sep 12 01:43:35 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB51A012D; Fri, 12 Sep 2014 01:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLfQV_kxQodN; Fri, 12 Sep 2014 01:43:31 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D828B1A0084; Fri, 12 Sep 2014 01:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19075; q=dns/txt; s=iport; t=1410511411; x=1411721011; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=3vQej3Mik/oSRlW8shH/95abTdkmmjBm9aTGkmTWBqw=; b=ZFosOSf1QIT9MgkYaWzKrlcRgloKgSdBgVDDmntZkqCHQZAAaRgjSeAH FQfbAF5TDm++keSLHsKqSrTJx/N8PwRMuTWTGQ4MlsXYEfa5Qkb7HYCKl QfcDPthoT3zl40A9PYZq4ggn6MK5FLGD+aF5tMHSOTUVro8cshk7KhSVa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAMyxElStJssW/2dsb2JhbABfg2BXiFfABQEJh04BgSV4hAMBAQEEAQEBawoBDAQLDgMEAQEBCRYIBwkDAgECARUfCQgGAQwBBQIBAYg+Db4aARePTQcGhEYFlgCHA4FfhWWEf4h4g2I8LwGCTgEBAQ X-IronPort-AV: E=Sophos;i="5.04,511,1406592000"; d="scan'208,217";a="174540587" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 12 Sep 2014 08:43:28 +0000 Received: from [10.61.99.35] (dhcp-10-61-99-35.cisco.com [10.61.99.35]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8C8hRSg009254; Fri, 12 Sep 2014 08:43:28 GMT Message-ID: <5412B224.5070604@cisco.com> Date: Fri, 12 Sep 2014 09:43:16 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Trammell , Gregory Mirsky , "ie-doctors@ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> <3F00C681-E3DA-4B1B-8F2F-B1341DDE95F1@trammell.ch> <54115192.7010204@cisco.com> <7347100B5761DC41A166AC17F22DF1121B82F09D@eusaamb103.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010404090600050803050002" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/VaFKQ6sDUs1SIEOdaESsS7A3_FU Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 08:43:34 -0000 This is a multi-part message in MIME format. --------------010404090600050803050002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, I don't see anything in 7013 that prevents us from updating the name too. P. On 12/09/2014 06:25, Brian Trammell wrote: > hi Greg, IE-Doctors, > > On 11 Sep 2014, at 18:16, Gregory Mirsky wrote: > >> 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?) > 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 > >> 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 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 > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------010404090600050803050002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Brian,

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

P.


On 12/09/2014 06:25, Brian Trammell wrote:
hi Greg, IE-Doctors,

On 11 Sep 2014, at 18:16, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:


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

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


	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


      

      

      

      

      

      
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


    

    

  


--------------010404090600050803050002--


From nobody Fri Sep 12 02:34:50 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060FE1A06A8; Fri, 12 Sep 2014 02:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnYXGnmAdwZC; Fri, 12 Sep 2014 02:34:45 -0700 (PDT)
Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 060FA1A06B5; Fri, 12 Sep 2014 02:34:43 -0700 (PDT)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 507861A09DA; Fri, 12 Sep 2014 11:34:41 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_99B71E81-AB8F-47F1-ACCA-B2DEC3EA4C4B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Brian Trammell 
In-Reply-To: <5412B224.5070604@cisco.com>
Date: Fri, 12 Sep 2014 11:34:41 +0200
Message-Id: <4FEE5A41-C8C0-4DAE-A1FB-AAFB08A6AA18@trammell.ch>
References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <5410C1A7.6000509@plixer.com> <7347100B5761DC41A166AC17F22DF1121B82EA53@eusaamb103.ericsson.se> <5410C5F9.9030307@plixer.com> <54113BFC.3050507@cisco.com> <3F00C681-E3DA-4B1B-8F2F-B1341DDE95F1@trammell.ch> <54115192.7010204@cisco.com> <7347100B5761DC41A166AC17F22DF1121B82F09D@eusaamb103.ericsson.se>  <5412B224.5070604@cisco.com>
To: Paul Aitken 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/2EfYu5rPjvgWwJ5SR5V8kOjWlV0
Cc: Gregory Mirsky , "ie-doctors@ietf.org" , "ipfix@ietf.org" 
Subject: Re: [IPFIX] [Ie-doctors] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Sep 2014 09:34:48 -0000

--Apple-Mail=_99B71E81-AB8F-47F1-ACCA-B2DEC3EA4C4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

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  wrote:

> Brian,
>=20
> I don't see anything in 7013 that prevents us from updating the name =
too.
>=20
> P.
>=20
>=20
> On 12/09/2014 06:25, Brian Trammell wrote:
>> hi Greg, IE-Doctors,
>>=20
>> On 11 Sep 2014, at 18:16, Gregory Mirsky=20
>> 
>>  wrote:
>>=20
>>=20
>>> 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:
>>>=20
>>>=20
>>>>>>> *         mplsTopLabelExp (should this be deprecated and =
mplsTopLabelTc be created instead?)
>>>>>>> *         postMplsTopLabelExp (should this be deprecated and =
postMplsTopLabelTc be created instead?)
>>>>>>>=20
>> 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:
>>=20
>> OLD mplsTopLabelExp:
>>=20
>> 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.
>>=20
>> 0   1   2   3   4   5   6   7
>> +---+---+---+---+---+---+---+---+
>> |     don't care    |    Exp    |
>> +---+---+---+---+---+---+---+---+
>>=20
>> NEW mplsTopLabelExp:
>>=20
>> The Traffic Class field (formerly named Exp) from the top MPLS label =
stack entry,=20
>> i.e., the last label that was pushed.
>> Bits 0-4:  Don't Care, value is irrelevant.
>> Bits 5-7:  MPLS Traffic Class field.
>>=20
>> 0   1   2   3   4   5   6   7
>> +---+---+---+---+---+---+---+---+
>> |     don't care    |    TC     |
>> +---+---+---+---+---+---+---+---+
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Cheers,
>>=20
>> Brian
>>=20
>>=20
>>> 	Regards,
>>> 		Greg
>>>=20
>>> -----Original Message-----
>>> From: Benoit Claise [
>>> mailto:bclaise@cisco.com
>>> ]=20
>>> Sent: Thursday, September 11, 2014 12:39 AM
>>> To: Brian Trammell
>>> Cc: Andrew Feren; Gregory Mirsky;=20
>>> ipfix@ietf.org; ie-doctors@ietf.org
>>>=20
>>> Subject: Re: [IPFIX] [SPAM I AM] RE: MPLS IEs in IANA's IP Flow =
Information Export (IPFIX) Entities registry
>>>=20
>>> On 11/09/2014 08:40, Brian Trammell wrote:
>>>=20
>>>> hi Benoit, Greg,
>>>>=20
>>>> This change looks to be interoperable to me under Section 5.2 of =
7103, points 5 and 7. 7 seems clear:
>>>>=20
>>>> (7)    it harmonizes with an external reference that was itself =
corrected.
>>>>=20
>>>> 5 is less so:
>>>>=20
>>>> (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
>>>>=20
>>>> 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".
>>>>=20
>>>> (Perhaps we should file a technical erratum for the next 7013 =
revision=20
>>>> changing point 5 to reflect this; i.e. NEW: )
>>>>=20
>>>> (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
>>>>=20
>>> That would make sense if a bis document would ever be worked on.
>>>=20
>>>=20
>>>>=20
>>>> That said these IEs are a terrible hack and I'd love to see them=20
>>>> deprecated and replaced with something slightly less broken (see =
7013=20
>>>> sections 4.6 and 4.9 paragraph 5). But it's hard to argue with an=20=

>>>> update to a set of IEs which corresponds to what any implementation=20=

>>>> will do _anyway_ without being updated (i.e. just keep copying =
those=20
>>>> bits even though we have an agreement to believe they mean =
something=20
>>>> different now.)
>>>>=20
>>> That goes in the direction of updating the description/reference and =
leaving the name unchanged?
>>>=20
>>> Regards, Benoit
>>>=20
>>>> Cheers,
>>>>=20
>>>> Brian
>>>>=20
>>>> On 11 Sep 2014, at 08:06, Benoit Claise=20
>>>> 
>>>>  wrote:
>>>>=20
>>>>=20
>>>>> Two points:
>>>>> - The EXP bits have been used for QoS mapping for years, even =
before=20
>>>>> 2009 (RFC 5462 publication date)
>>>>> - Do you believe that deprecating/replacing all these IEs will =
imply=20
>>>>> that exporter implementations will update their code, just for new=20=

>>>>> ElementID? :-)
>>>>>=20
>>>>> I would use the procedure in=20
>>>>>=20
>>>>> http://tools.ietf.org/html/rfc7013#section-5.2
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>> The size of this Information Element is 3 octets.
>>>>>=20
>>>>> NEW:
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>> The size of this Information Element is 3 octets.
>>>>>=20
>>>>> And change
>>>>> - the reference from RFC3032 to RFC5462
>>>>> - the revision +1
>>>>>=20
>>>>> Regards, Benoit
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> Then perhaps the right thing is to deprecate the lot and replace =
them all.
>>>>>>=20
>>>>>> Thanks,
>>>>>> -Andrew
>>>>>>=20
>>>>>> On 09/10/2014 05:28 PM, Gregory Mirsky wrote:
>>>>>>=20
>>>>>>> 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
>>>>>>>=20
>>>>>>>=20
>>>>>>>    RFC 3032 states on page 4:
>>>>>>>=20
>>>>>>>       3.  Experimental Use
>>>>>>>=20
>>>>>>>       This three-bit field is reserved for experimental use.
>>>>>>>=20
>>>>>>>    This paragraph is now changed to:
>>>>>>>=20
>>>>>>>       3.  Traffic Class (TC) field
>>>>>>>=20
>>>>>>>       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.
>>>>>>>=20
>>>>>>>                 Regards,
>>>>>>>                                 Greg
>>>>>>>=20
>>>>>>> From: Andrew Feren [
>>>>>>> mailto:andrewf@plixer.com
>>>>>>> ]
>>>>>>> Sent: Wednesday, September 10, 2014 2:25 PM
>>>>>>> To:=20
>>>>>>> ipfix@ietf.org
>>>>>>>=20
>>>>>>> Cc: Gregory Mirsky
>>>>>>> Subject: Re: [IPFIX] MPLS IEs in IANA's IP Flow Information =
Export=20
>>>>>>> (IPFIX) Entities registry
>>>>>>>=20
>>>>>>> Hi Greg,
>>>>>>>=20
>>>>>>> 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?)
>>>>>>>=20
>>>>>>> Did 5462 change just the name from Exp to TC or did the =
interpretation of the bits change?
>>>>>>>=20
>>>>>>> -Andrew
>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> IPFIX mailing list
>>>>>>=20
>>>>>>=20
>>>>>> IPFIX@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>> _______________________________________________
>>>>> IPFIX mailing list
>>>>>=20
>>>>> IPFIX@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>=20
>>=20
>> _______________________________________________
>> IPFIX mailing list
>>=20
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>=20
> _______________________________________________
> ie-doctors mailing list
> ie-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/ie-doctors


--Apple-Mail=_99B71E81-AB8F-47F1-ACCA-B2DEC3EA4C4B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUEr4xAAoJENt3nsOmbNJc0igH/AtlQyYYsfPdw4kioqlj2yVy
7F2+clflJQQclwSDPBZyo3XukleMlO0I0M1Xo1V2GkM3pyUg1eg4F68B3lqc2DsG
auPt8YoQI2cSBqG/2nrINtfEbKBgvhw5SupPk60GwDsPOHa3s3xl3LJ4VChb52O8
ak5sjo1ZmSgAAW3brfA/BErztLu4kR39PUI/H/QJsdlIH94KKtcYK7+2sCxGEVfJ
3YlyAqekZdzxlvtgZpqtiom++bi/63+NrSjhCHGn0SwABPo9TqMa37qF85UiqI8s
XId5UbmrUviqPK6VA6JXtVryDvDrrmjNeZRIWwLT6181vpVCJ2VbwpSDsxysIAQ=
=O5yV
-----END PGP SIGNATURE-----

--Apple-Mail=_99B71E81-AB8F-47F1-ACCA-B2DEC3EA4C4B--


From nobody Fri Sep 19 02:45:20 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6E91A006B; Fri, 19 Sep 2014 02:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.601
X-Spam-Level: 
X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQZRSrdVQHe8; Fri, 19 Sep 2014 02:45:15 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732001A006A; Fri, 19 Sep 2014 02:45:15 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-eb-541ba53136d1
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F5.97.05330.135AB145; Fri, 19 Sep 2014 05:38:26 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 19 Sep 2014 05:45:05 -0400
From: Gregory Mirsky 
To: Loa Andersson , "ipfix@ietf.org" 
Thread-Topic: [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry
Thread-Index: Ac/NKwbd4PEEn4EDQnes99jLrEnN8AG4pmqAAAfuZqA=
Date: Fri, 19 Sep 2014 09:45:05 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B833FDE@eusaamb103.ericsson.se>
References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <541BF749.6010907@pi.nu>
In-Reply-To: <541BF749.6010907@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.12]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPiK7RUukQgy8nOCyOXX3NbvFv7hxm izcnDjFa3Fq6ktWBxWPJkp9MHrOmt7EFMEVx2aSk5mSWpRbp2yVwZTx+fZGpYCNfxYHt15kb GFdxdzFyckgImEi86n3BBmGLSVy4tx7I5uIQEjjKKDHp2CVGkISQwHJGiTl78kFsNgEjiRcb e9hBbBEBB4nXT7+wgtjMAiESeyYtB6sXFoiVWNz0mAWiJk5i/9TdrBC2lcTPhptgy1gEVCWO bjwCNodXwFdizozb7BC7MiQ+3XsLNocTqGb61Otg9YxAx30/tYYJYpe4xK0n85kgjhaQWLLn PDOELSrx8vE/VghbSWLO62vMEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYxWYhGTsLScss JC2zkLQsYGRZxchRWpxalptuZLCJERg5xyTYdHcw7nlpeYhRgINRiYd3gax0iBBrYllxZe4h RmkOFiVx3lm184KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MM4teHhiy77HyjV/WfMlz61o 4Fr8vvy25lZev0oZ/ZuaH47FHWDmnvziVFb+bRnlTIkn80/q6lRWrjD9YpnnKv5iWryw8avl p9Un88TozHnhpH/N5tDq9xU1x2P3y3Got+m6vJXz/HdxxtMZm7ltWw7tdwu/vmTz3daW2wty 3p6UXis6ddpdt2dKLMUZiYZazEXFiQCcH8rYfQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/wlTQ9p_YzLPXLwGfuNAmmCaHJZs
Cc: "mpls@ietf.org" , "MIB Doctors \(E-mail\)" 
Subject: Re: [IPFIX] [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Sep 2014 09:45:17 -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:loa@pi.nu]=20
Sent: Friday, September 19, 2014 10:29 AM
To: Gregory Mirsky; ipfix@ietf.org
Cc: mpls@ietf.org; MIB Doctors (E-mail)
Subject: Re: [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) E=
ntities registry

Greg,

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

Can we get an mib doctor advice on this?

/Loa

On 2014-09-10 21:22, Gregory Mirsky wrote:
> Dear All,
>
> in several places of describing MPLS Label element IEs the registry=20
> still refers to the EXP field even though the RFC 5462 updated RFC=20
> 3032 and renamed it "Traffic Class" (TC). Below is the list of IEs=20
> 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=20
> created instead?)
>
> *postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc=20
> be created instead?)
>
> Regards,
>
>          Greg
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

--=20


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


From nobody Fri Sep 19 02:53:46 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3661A004C; Fri, 19 Sep 2014 02:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.202
X-Spam-Level: 
X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6LW3hVP5Hf6; Fri, 19 Sep 2014 02:53:41 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463971A004B; Fri, 19 Sep 2014 02:53:41 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DEC93E86; Fri, 19 Sep 2014 11:53:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PYis_z1wZmlJ; Fri, 19 Sep 2014 11:53:18 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 19 Sep 2014 11:53:39 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 178AB20035; Fri, 19 Sep 2014 11:53:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id K8hhCEcs0KcK; Fri, 19 Sep 2014 11:53:37 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E98120036; Fri, 19 Sep 2014 11:53:37 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 104D52E6836D; Fri, 19 Sep 2014 11:53:36 +0200 (CEST)
Date: Fri, 19 Sep 2014 11:53:36 +0200
From: Juergen Schoenwaelder 
To: Loa Andersson 
Message-ID: <20140919095336.GA22032@elstar.local>
Mail-Followup-To: Loa Andersson , Gregory Mirsky , "ipfix@ietf.org" , "mpls@ietf.org" , "MIB Doctors (E-mail)" 
References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <541BF749.6010907@pi.nu>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <541BF749.6010907@pi.nu>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/WSFqHwq9EXyeBEXJiwzcDn41MLs
Cc: Gregory Mirsky , "mpls@ietf.org" , "ipfix@ietf.org" , "MIB Doctors \(E-mail\)" 
Subject: Re: [IPFIX] [MIB-DOCTORS] [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Sep 2014 09:53:43 -0000

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:
> 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:
> >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
> >
> >
> >
> >_______________________________________________
> >mpls mailing list
> >mpls@ietf.org
> >https://www.ietf.org/mailman/listinfo/mpls
> >
> 
> -- 
> 
> 
> Loa Andersson                        email: loa@mail01.huawei.com
> Senior MPLS Expert                          loa@pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> 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         


From nobody Fri Sep 19 15:02:34 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B6D1A0079; Fri, 19 Sep 2014 02:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level: 
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4Hk3NcF4EbL; Fri, 19 Sep 2014 02:28:41 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF461A007B; Fri, 19 Sep 2014 02:28:40 -0700 (PDT)
Received: from [192.168.0.100] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 132941801487; Fri, 19 Sep 2014 11:28:39 +0200 (CEST)
Message-ID: <541BF749.6010907@pi.nu>
Date: Fri, 19 Sep 2014 11:28:41 +0200
From: Loa Andersson 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Gregory Mirsky ,  "ipfix@ietf.org" 
References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/qKHtWl9WMiL4cNzo6TQ-8sZ8X2E
X-Mailman-Approved-At: Fri, 19 Sep 2014 15:02:32 -0700
Cc: "mpls@ietf.org" , "MIB Doctors \(E-mail\)" 
Subject: Re: [IPFIX] [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Sep 2014 09:28:43 -0000

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:
> 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
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


From nobody Sun Sep 21 14:24:53 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7CE1A031D for ; Sat, 20 Sep 2014 21:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.052
X-Spam-Level: 
X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPaOgGSC4XSj for ; Sat, 20 Sep 2014 21:30:27 -0700 (PDT)
Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923661A0329 for ; Sat, 20 Sep 2014 21:30:26 -0700 (PDT)
Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-05v.sys.comcast.net with comcast id tgWC1o00A4s37d401gWRzY; Sun, 21 Sep 2014 04:30:25 +0000
Received: from JV6RVH1 ([67.189.237.137]) by resomta-po-01v.sys.comcast.net with comcast id tgWP1o0032yZEBF01gWPsV; Sun, 21 Sep 2014 04:30:25 +0000
From: "ietfdbh" 
To: "'t.petch'" , "'Loa Andersson'" , "'Gregory Mirsky'" , 
References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <541BF749.6010907@pi.nu> <004a01cfd3ff$da773380$4001a8c0@gateway.2wire.net>
In-Reply-To: <004a01cfd3ff$da773380$4001a8c0@gateway.2wire.net>
Date: Sun, 21 Sep 2014 00:30:16 -0400
Message-ID: <061e01cfd554$bfe4dd50$3fae97f0$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ5+qvJ1UOOe6iVwTjJOiME8Dlb3wMzivs2AiQJ/4Sai/cpMA==
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411273825; bh=oQsmIid9ODWhxDgEEvzwLcIDjtEuhYTam52jex9il2Q=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=FiokpnflyURK2/gbCdi3VuBFXj9RNjm7mUEFBCJL5+By0paGOzt510/Z+Rd57URKM UlC8nErs7Yihd+Zht2p9pNeHHgWKjP8jqfnXDSTVn3lypPpolllA5jAggM0QLIPhiL r6yOQsqMLwo7gdItQ2R8FUV5fqlzE853OCI7iz1015rQKpCoLz+j2GsPINKJtwjTZW TpoLXHZl01OgVclLUHOS8dG4EU3mcbmtMuo1GMlYLMaw+CHvhnKfg6PdqdHyrG/7dZ o+KIszKwLRAYbU2OllxzqA9bUtltEkIVIxy79yy65ac3c3zBekCLnjGPzS2PBNFCio ESfrycsb8S3uw==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/Nju7tYPAPBCZLrCLotI-1X_OiHU
X-Mailman-Approved-At: Sun, 21 Sep 2014 14:24:51 -0700
Cc: mpls@ietf.org, "'MIB Doctors \(E-mail\)'" 
Subject: Re: [IPFIX] [MIB-DOCTORS] [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Sep 2014 04:30:29 -0000

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

David Harrington
ietfdbh@comcast.net
+1-603-828-1401
> -----Original Message-----
> From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of
> t.petch
> Sent: Friday, September 19, 2014 7:50 AM
> To: Loa Andersson; Gregory Mirsky; ipfix@ietf.org
> Cc: mpls@ietf.org; MIB Doctors (E-mail)
> Subject: Re: [MIB-DOCTORS] [mpls] MPLS IEs in IANA's IP Flow Information
> Export (IPFIX) Entities registry
> 
> ----- Original Message -----
> From: "Loa Andersson" 
> To: "Gregory Mirsky" ; 
> Cc: ; "MIB Doctors (E-mail)" 
> Sent: Friday, September 19, 2014 10:28 AM
> 
> Greg,
> 
> I'm not sure about this - would changing the names require updating all
> existing deployed MIBs?
> 
> 
> 
> 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]
> 
> 
> 
> 
> Can we get an mib doctor advice on this?
> 
> /Loa
> 
> On 2014-09-10 21:22, 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?)
> >
> > Regards,
> >
> >          Greg
> >
> >
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> 
> --
> 
> 
> Loa Andersson                        email: loa@mail01.huawei.com
> Senior MPLS Expert                          loa@pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors


From nobody Mon Sep 22 05:25:28 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4BC1A1AAC; Mon, 22 Sep 2014 05:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.687
X-Spam-Level: 
X-Spam-Status: No, score=-14.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYqydeRgtire; Mon, 22 Sep 2014 05:25:19 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D3F1A1AB3; Mon, 22 Sep 2014 05:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3393; q=dns/txt; s=iport; t=1411388719; x=1412598319; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gfRB/HC1DsXv4/557YY+jqGSzN/mNxmIFpcoKX3ZvHw=; b=exdPiBxBrXiFLsrs0/p64/7Mn/P9pBlaVzqswlhdcYDm6cDPuS0jssU8 X1V/aGvQrhP1A5aUumgob4IqNaLFJ8DMkyj1CuSFu8EVgsSkVn/LHjjFk Uk2Tjx9t+ZJwggshS+9gKRDhmeTAuwhj2yjlYh+VAUYb26ACg5BWfPfAf E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AswUALgUIFStJssW/2dsb2JhbABdA4NhV8pKCguHPQMCAYEhAXmEAwEBAQQBAQEvAQUzAwoBDAICCxEEAQEBCRYIBwkDAgECAQkMHwkIBgEMAQUCAQGIJgMRDbxXCIc0ARMEBI8gEQFAEAcGC4Q6AQSdFodMhQKJBIIegUU7L4EPgTsBAQE
X-IronPort-AV: E=Sophos;i="5.04,571,1406592000"; d="scan'208";a="185394664"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 22 Sep 2014 12:25:17 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8MCPH5O024936; Mon, 22 Sep 2014 12:25:17 GMT
Message-ID: <5420152C.2060501@cisco.com>
Date: Mon, 22 Sep 2014 14:25:16 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: ietfdbh , "'t.petch'" , "'Loa Andersson'" , "'Gregory Mirsky'" , ipfix@ietf.org
References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <541BF749.6010907@pi.nu> <004a01cfd3ff$da773380$4001a8c0@gateway.2wire.net> <061e01cfd554$bfe4dd50$3fae97f0$@comcast.net>
In-Reply-To: <061e01cfd554$bfe4dd50$3fae97f0$@comcast.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/esF3iQ5dkHqHb8R-6di0MplTlJY
Cc: mpls@ietf.org, "'MIB Doctors \(E-mail\)'" 
Subject: Re: [IPFIX] [MIB-DOCTORS] [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 12:25:21 -0000

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
> Updating the description would be a problem if you change the semantics of
> the object.
>
> David Harrington
> ietfdbh@comcast.net
> +1-603-828-1401
>> -----Original Message-----
>> From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of
>> t.petch
>> Sent: Friday, September 19, 2014 7:50 AM
>> To: Loa Andersson; Gregory Mirsky; ipfix@ietf.org
>> Cc: mpls@ietf.org; MIB Doctors (E-mail)
>> Subject: Re: [MIB-DOCTORS] [mpls] MPLS IEs in IANA's IP Flow Information
>> Export (IPFIX) Entities registry
>>
>> ----- Original Message -----
>> From: "Loa Andersson" 
>> To: "Gregory Mirsky" ; 
>> Cc: ; "MIB Doctors (E-mail)" 
>> Sent: Friday, September 19, 2014 10:28 AM
>>
>> Greg,
>>
>> I'm not sure about this - would changing the names require updating all
>> existing deployed MIBs?
>>
>> 
>>
>> 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]
>>
>>
>>
>>
>> Can we get an mib doctor advice on this?
>>
>> /Loa
>>
>> On 2014-09-10 21:22, 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?)
>>>
>>> Regards,
>>>
>>>           Greg
>>>
>>>
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>> --
>>
>>
>> Loa Andersson                        email: loa@mail01.huawei.com
>> Senior MPLS Expert                          loa@pi.nu
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>> _______________________________________________
>> MIB-DOCTORS mailing list
>> MIB-DOCTORS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mib-doctors
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors
> .
>