Re: [mpls] [IANA #1175554] Re: draft-tgraf-ipfix-mpls-sr-label-type

Tianran Zhou <zhoutianran@huawei.com> Wed, 12 August 2020 13:14 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26A3A1289; Wed, 12 Aug 2020 06:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.332
X-Spam-Level:
X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 xV9-MF3JypJA; Wed, 12 Aug 2020 06:14:17 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C9A3A1285; Wed, 12 Aug 2020 06:14:16 -0700 (PDT)
Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DE370482A8AAF640BF8B; Wed, 12 Aug 2020 14:14:13 +0100 (IST)
Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 12 Aug 2020 14:14:12 +0100
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 12 Aug 2020 21:14:10 +0800
Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Wed, 12 Aug 2020 21:14:10 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: "Thomas.Graf" <Thomas.Graf@swisscom.com>, iana-issues <iana-issues@iana.org>, Loa Andersson <loa@pi.nu>
CC: mpls <mpls@ietf.org>, opsawg <opsawg@ietf.org>
Thread-Topic: [mpls] [IANA #1175554] Re: draft-tgraf-ipfix-mpls-sr-label-type
Thread-Index: AQHWcIOAbwIfxyR2GUK3o++k9ONK9ak0c+fx
Date: Wed, 12 Aug 2020 13:14:10 +0000
Message-ID: E458E6BF-E32E-4B9C-881F-4D67D50A7DD9
References: <RT-Ticket-1175554@icann.org> <1811130370.3403178.1595923899529@ss007565> <000862e2-a9c4-e6c9-5580-29fa06a9769e@pi.nu> <1248898123.1692458.1596779549400@ss002889> <a6bf71f4-7495-de06-bd38-cc12390901d6@pi.nu> <rt-4.4.3-5345-1597095816-1787.1175554-37-0@icann.org> <CANZnSTrw67Xmy3NGdiA9c73GV2s1OF1+PB2q_qzBjrOQUh=VRQ@mail.gmail.com> <rt-4.4.3-28824-1597124816-1914.1175554-37-0@icann.org> <rt-4.4.3-14305-1597168743-684.1175554-37-0@icann.org>, <780006881.1120725.1597221183901@ss002890>
In-Reply-To: <780006881.1120725.1597221183901@ss002890>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_E458E6BFE32E4B9C881F4D67D50A7DD9_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/q_fnYjIxfdP0hvUWbMyqyav3clE>
Subject: Re: [mpls] [IANA #1175554] Re: draft-tgraf-ipfix-mpls-sr-label-type
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2020 13:14:20 -0000

Hi All,


I would like to share the discussion to the OPSAWG mailing list.


Cheers,

Tianran

--------------------------------------------------
Sent from WeLink

发件人:Thomas.Graf <Thomas.Graf@swisscom.com>
收件人:iana-issues <iana-issues@iana.org>;Loa Andersson <loa@pi.nu>
抄 送:mpls <mpls@ietf.org>
时 间:2020-08-12 16:35:14
主 题:Re: [mpls] [IANA #1175554] Re: draft-tgraf-ipfix-mpls-sr-label-type

Hi Sabrina, Hi Loa

Thanks a lot for the feedback regarding the "Requester" column. For clarification, and I think this is what Loa is referring to, the "Requester" column refers to the document that the code point requested, where the "Reference" column links to the document where the metric value is coming from. Please correct me if my understanding is wrong.

As an example, in the IPFIX Information Elements registry
https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-elements

code point 10, ingressInterface. points to RFC 2863 where ifindex is described.

Looking at IPFIX MPLS label type (Value 46) registry
https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type

There the "Reference" column for code points 1-5 links to
https://tools.ietf.org/html/rfc5102#section-7.2

In my opinion, this link should be under "Requester" and not under "Reference" column.

If we take code point 4, "BGP: Any label associated with BGP or BGP routing", the  "Reference" column should link to
https://tools.ietf.org/html/rfc8277

If my understanding is correct, would it make sense to correct it accordingly. I am gladly assist to add the reference links and review it with the IE doctor.

Regarding TBD2, OSPFv3 Segment Routing in draft-tgraf-ipfix-mpls-sr-label-type. This has been added after the IE doctor review based on feedback from SPRING wg. Same as for TBD4, SrSidType, new registry, this had been added after the IE doctor review as well. I received another feedback from LSR wg to add another code point for BGP Prefix-SID, RFC 8669 which will be added in draft-tgraf-ipfix-mpls-sr-label-type-05. With this, the list of all routing protocols capable of carrying segment routing labels and all segment routing SID types should be covered.

Once this is all updated at OPSAWG adopted, I planned to approach IE doctor for another review. I hope this makes sense.

Best wishes
Thomas

-----Original Message-----
From: Sabrina Tanamal via RT <iana-issues@iana.org>
Sent: Tuesday, August 11, 2020 7:59 PM
To: loa@pi.nu
Cc: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; mpls@ietf.org
Subject: [IANA #1175554] Re: [mpls] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas, Loa,

Loa, thanks for the review.

Thomas, Loa has pointed out some issues with the document. Please see below and apply the appropriate changes. Can you let us know when the document has been updated so we can ask the IE Doctors to do another review?

Best regards,

Sabrina Tanamal
Senior IANA Services Specialist

On Tue Aug 11 05:46:56 2020, loa.pi.nu@gmail.com wrote:
> Sabrina,
>
> From a registry point of view the split between "Reference" and
> "Requester"
> will work though it seems odd to deviate from the meaning of any other
> registry when it comes to naming "Reference" information.
>
> You mention that IE Doctors specifically requested  references to
> RFC8667
> and RFC8665, is this true also for RFC 8666?
>
> This document specifies three additional code points for IS-IS, OSPv2
> and OSPFv3 Segment Routing extension in the existing sub-registry
> "IPFIX MPLS label type (Value 46)" of the "IPFIX Information Elements"
> and one new "IPFIX Information Element" with a new sub- registry in
> the "IP Flow Information Export (IPFIX) Entities" name space.
>
> ----------------------------------------------
> | Value|       Description       | Reference |
> |--------------------------------------------|
> | TBD1 | OSPFv2 Segment Routing  |  RFC8665
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
> ls.ietf.org%2Fhtml%2Frfc8665&amp;data=02%7C01%7CThomas.Graf%40swisscom
> .com%7C6f51599d207b4faeec6208d83e203ef0%7C364e5b87c1c7420d9beec35d19b5
> 57a1%7C1%7C0%7C637327655514916466&amp;sdata=6CBHC%2F%2FGr5H%2B3Mt9CeSA
> VgGdD%2B2cZG94i84bJv0PkGA%3D&amp;reserved=0>  |
> |--------------------------------------------|
> | TBD2 | OSPFv3 Segment Routing  |  RFC8666
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
> ls.ietf.org%2Fhtml%2Frfc8666&amp;data=02%7C01%7CThomas.Graf%40swisscom
> .com%7C6f51599d207b4faeec6208d83e203ef0%7C364e5b87c1c7420d9beec35d19b5
> 57a1%7C1%7C0%7C637327655514916466&amp;sdata=9NTeQLQNbc9SuLuKrfv0cJYUyf
> klyWFUmC5uKbblL1w%3D&amp;reserved=0>  |
> |--------------------------------------------|
> | TBD3 | IS-IS Segment Routing   |  RFC8667
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
> ls.ietf.org%2Fhtml%2Frfc8667&amp;data=02%7C01%7CThomas.Graf%40swisscom
> .com%7C6f51599d207b4faeec6208d83e203ef0%7C364e5b87c1c7420d9beec35d19b5
> 57a1%7C1%7C0%7C637327655514916466&amp;sdata=i7551OWxpbM2BNcqdVTisbBs0l
> %2BYb%2B6LEfP67U7WVRI%3D&amp;reserved=0>  |
> ----------------------------------------------
>
>
>
> The test actually says "three additional code points" they are called
> TDB1,
> TBD2 and TBD3, this indicates that the have  not been specified
> anywhere else, if they have this should be made clear.
>
> I was also concerned that I couldn't find the definition of code point
> TBD1 in RFC8665. Exactly what is referenced?
>
> I have similar concerns on "New "IPFIX Information Element #TBD4"
> which
> sadi to be a new registry. Buet the cases I was looking for in 8402 I
> could not find.
>
> /Loa
>
>
> Den tis 11 aug. 2020 kl 05:43 skrev Sabrina Tanamal via RT <
> iana-issues@iana.org>:
>
> > Hi Loa,
> >
> > The IPFIX Information Elements registry is unique in that it has a
> > "Requester" column. The requester is the document that makes the
> > registration (if there is a document), but the "References" section
> > can point to any document.
> >
> > When the IE Doctors reviewed version 01 in March, they specifically
> > asked that references to RFC8667 and RFC8665 be added for the two
> > IPFIX MPLS label type (Value 46) registrations, which at that point
> > weren't associated with any references. Because that registry has
> > only a "Reference"
> > column
> > and no "Requester" column, those registrations may not refer to this
> > document at all (which is not uncommon). However, we could ask the
> > IE Doctors whether these registrations should also refer to this
> > document.
> >
> > This will have to be reviewed by the IE Doctors again at some point,
> > as they've added several registrations.
> >
> > Best regards,
> >
> > Sabrina Tanamal
> > Senior IANA Services Specialist
> >
> > On Fri Aug 07 07:51:13 2020, loa@pi.nu wrote:
> > > Thomas, (including IANA for advice)
> > >
> > > There might be something I don't understand.
> > >
> > > Tentatively I think what has happened is some documents defined
> > > code points without make IANA allocations? What you reference
> > > below as the "RFC's where they are actually described."
> > >
> > > What I see is is that all the values you are asking for is called
> > > TBDx, which means that when this document is approved, IANA will
> > > review  and assign values for each code point. This looks to me
> > > like the reference  in the registry should be be to this document.
> > >
> > > I also think that the document should include clear references to
> > > the document and section where the code points are defined. I
> > > don't have an objection to place this in the list, but there
> > > should also be at lest some text explaining what we are doing.
> > >
> > > An example what could suffice:
> > >
> > > Figure 2: New "IPFIX Information Element #TBD4"
> > >
> > > ----------------------------------------------+
> > > | Value |  Description      | Reference       |
> > > |---------------------------------------------|
> > > | TBD5  | Unknown SID Type  | This document   |
> > > |       |                   | this code point |
> > > |       |                   | is defined in   |
> > > |       |                   | RFC8402 sect. x |
> > > |---------------------------------------------|
> > > | TBD6  | Prefix-SID        | This document   |
> > > |       |                   | this code point |
> > > |       |                   | is defined in   |
> > > |       |                   | RFC8402 sect.  -|
> > > |---------------------------------------------|
> > > |       |                   |                 |
> > >
> > > Only that RFC 8401 does not have a description of an Unknow SID
> > > Type, and says that Prefix-SID is an IPv6 address (nothing about a
> > > code point).
> > >
> > >
> > >
> > > /Loa
> > >
> > > On 07/08/2020 13:52, Thomas.Graf@swisscom.com wrote:
> > > > Hi Loa,
> > > >
> > > > Thanks a lot for your feedback. I do understand your input in
> > > > regards of referring the code points to this document instead of
> > > > the RFC's where they are actually described.
> > > >
> > > > A bit of the history this document went through. IANA requested
> > > > a formal document for which this document was created for.
> > > > Giving the context and use cases. The IANA section of this
> > > > document has then been reviewed by IE doctors and updated
> > > > accordingly.
> > > >
> > > > Please correct me if I am wrong. Looking at the IANA IPFIX
> > > > registry, the references are always to documents where the
> > > > values are actually defined. So I do think that the original RFC
> > > > references are correct, but I am not the expert.
> > > >
> > > > I will take your input and double check when this document will
> > > > receive the final IE doctor review which I am going to request
> > > > before going last call.
> > > >
> > > > Best Wishes
> > > > Thomas
> > > >
> > > > -----Original Message-----
> > > > From: Loa Andersson <loa@pi.nu>
> > > > Sent: Sunday, August 2, 2020 10:07 AM
> > > > To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>;
> > > > mpls@ietf.org
> > > > Subject: Re: [mpls] draft-tgraf-ipfix-mpls-sr-label-type
> > > >
> > > > Thomas,
> > > >
> > > > I have a question on the IANA section of this document.
> > > >
> > > > For every new code point, e.g.:
> > > >
> > > > This document specifies three additional code points for IS-IS,
> > > > OSPv2
> > > > and OSPFv3 Segment Routing extension in the existing
> > > > sub-registry "IPFIX MPLS label type (Value 46)" of the "IPFIX
> > > > Information Elements" and one new "IPFIX Information Element"
> > > > with a new sub- registry in the "IP Flow Information Export (IPFIX) Entities"
> > > > name
> > > > space.
> > > >
> > > > ----------------------------------------------
> > > > | Value|       Description       | Reference |
> > > > |--------------------------------------------|
> > > > | TBD1 | OSPFv2 Segment Routing  |  RFC8665  |
> > > > |--------------------------------------------|
> > > > | TBD2 | OSPFv3 Segment Routing  |  RFC8666  |
> > > > |--------------------------------------------|
> > > > | TBD3 | IS-IS Segment Routing   |  RFC8667  |
> > > > ----------------------------------------------
> > > >
> > > > Figure 1: Updates to "IPFIX Information Element #46" SubRegistry
> > > >
> > > > you put in a reference to old documents that does not define
> > > > these code points. Shouldn't the reference say "this document"?
> > > >
> > > > I think this is true for almost all references you have put into
> > > > the IANA section.
> > > >
> > > > For the new sub-registry:
> > > >
> > > > -----------------------------------------
> > > > | Value |  Description      | Reference |
> > > > |---------------------------------------|
> > > > | TBD5  | Unknown SID Type  |  RFC8402  |
> > > > |---------------------------------------|
> > > > | TBD6  | Prefix-SID        |  RFC8402  |
> > > > |---------------------------------------|
> > > > | TBD7  | Node-SID          |  RFC8402  |
> > > > |---------------------------------------|
> > > > | TBD8  | Anycast-SID       |  RFC8402  |
> > > > |---------------------------------------|
> > > > | TBD9  | Adjacency-SID     |  RFC8402  |
> > > > |---------------------------------------|
> > > > | TBD10 | LAN-Adjacency-SID |  RFC8402  |
> > > > |---------------------------------------|
> > > > | TBD11 | PeerNode-SID      |  RFC8402  |
> > > > |---------------------------------------|
> > > > | TBD12 | PeerAdj-SID       |  RFC8402  |
> > > > |---------------------------------------|
> > > > | TBD13 | PeerSet-SID       |  RFC8402  |
> > > > |---------------------------------------|
> > > > | TBD14 | Binding-SID       |  RFC8402  |
> > > > -----------------------------------------
> > > >
> > > > Figure 3: New "IPFIX Information Element #TBD4" SubRegistry
> > > >
> > > > You will have to define Registration Procedues!
> > > >
> > > > /Loa
> > > >
> > > > On 28/07/2020 16:11, Thomas.Graf@swisscom.com wrote:
> > > >> Dear mpls,
> > > >>
> > > >> I presented the following draft
> > > >>
> > > >> Export of MPLS Segment Routing Label Type Information in IP
> > > >> Flow Information Export (IPFIX)
> > > >>
> > > >>
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fto
> > ol
> > > >> s.ietf.org%2Fhtml%2Fdraft-tgraf-ipfix-mpls-sr-label-type-
> > > >> 04&amp;data=0
> > > >> 2%7C01%7CThomas.Graf%40swisscom.com
> > %7C1de9406dba0e422fa27508d836bb1ee2
> > > >> %7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C63731952458891341
> > > >> 5&amp;s
> > > >> data=KVpjfCOYwZoJen3uAqID0sK%2FrWIujm4q7vDigug2%2B9A%3D&amp;res
> > > >> erved=0
> > > >>
> > > >> at the spring working group at IETF 108 yesterday
> > > >>
> > > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F
> > > >> %2Fwww
> > .
> > > >> ietf.org%2Fproceedings%2F108%2Fslides%2Fslides-108-spring-ip-
> > > >> flow-
> > > >> info
> > > >> rmation-export-ipfix-
> > > >> 00.pdf&amp;data=02%7C01%7CThomas.Graf%40swisscom.
> > > >> com%7C1de9406dba0e422fa27508d836bb1ee2%7C364e5b87c1c7420d9beec3
> > > >> 5d19b55
> > > >> 7a1%7C1%7C0%7C637319524588913415&amp;sdata=U9jmYfa0Kxd7ewrOmAgB
> > > >> poiFLFg
> > > >> JkytxRvGCAX5egZs%3D&amp;reserved=0
> > > >>
> > > >> and today at OPSAWG where I call for adoption.
> > > >>
> > > >> This draft adds additional segment routing code points for in
> > > >> the IANA IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and
> > > >> segment routing SID types to gain further insights into the
> > > >> MPLS-SR forwarding- plane.
> > > >>
> > > >> I have been asked to not only gather feedback from spring and
> > > >> opsawg but also from lsr and mpls working groups since these
> > > >> code points are related to link state routing protocols and
> > > >> mpls data plane.
> > > >>
> > > >> I am looking forward to your feedback and input.
> > > >>
> > > >> Best Wishes
> > > >>
> > > >> Thomas Graf
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> mpls mailing list
> > > >> mpls@ietf.org
> > > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F
> > > >> %2Fwww
> > .
> > > >> ietf.org
> > %2Fmailman%2Flistinfo%2Fmpls&amp;data=02%7C01%7CThomas.Graf%40
> > > >> swisscom.com
> > %7C1de9406dba0e422fa27508d836bb1ee2%7C364e5b87c1c7420d9bee
> > > >> c35d19b557a1%7C1%7C0%7C637319524588913415&amp;sdata=Rk6q0lYc3%2
> > > >> BZCF%2B
> > > >> FaKjdEDB0hdvku7RkzsMLGPDLQ4y8%3D&amp;reserved=0
> > > >>
> > > >
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=02%7C01%7CThomas.Gra
> > f%40swisscom.com%7C6f51599d207b4faeec6208d83e203ef0%7C364e5b87c1c742
> > 0d9beec35d19b557a1%7C1%7C0%7C637327655514916466&amp;sdata=p2xYjuKPUC
> > 3Wi4Gw2M7D1gtKQ%2B0umWfHmzR0xF5cqe8%3D&amp;reserved=0
> >