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

Sabrina Tanamal via RT <iana-issues@iana.org> Wed, 02 September 2020 23:19 UTC

Return-Path: <iana-shared@icann.org>
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 EA7B53A0406 for <mpls@ietfa.amsl.com>; Wed, 2 Sep 2020 16:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 ro1noacVauNe for <mpls@ietfa.amsl.com>; Wed, 2 Sep 2020 16:19:49 -0700 (PDT)
Received: from smtp01.icann.org (smtp01.icann.org [192.0.33.81]) (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 B71013A0400 for <mpls@ietf.org>; Wed, 2 Sep 2020 16:19:49 -0700 (PDT)
Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 77B0EE0F1D; Wed, 2 Sep 2020 23:19:49 +0000 (UTC)
Received: by request4.lax.icann.org (Postfix, from userid 48) id 75C6420476; Wed, 2 Sep 2020 23:19:49 +0000 (UTC)
RT-Owner: sabrina.tanamal
From: Sabrina Tanamal via RT <iana-issues@iana.org>
Reply-To: iana-issues@iana.org
In-Reply-To: <ZRAP278MB0125F2989023DD913DDC75FD892E0@ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM>
References: <RT-Ticket-1177073@icann.org> <RT-Ticket-1175554@icann.org> <1811130370.3403178.1595923899529@ss007565> <000862e2-a9c4-e6c9-5580-29fa06a9769e@pi.nu> <1248898123.1692458.1596779549400@ss002889> <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> <ZRAP278MB0125C2654D594DCC4BDF03C189420@ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM> <ZRAP278MB0125F2989023DD913DDC75FD892E0@ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM>
Message-ID: <rt-4.4.3-12524-1599088789-1805.1177073-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1177073
X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: sabrina.tanamal@icann.org
To: thomas.graf@swisscom.com
CC: loa@pi.nu, mpls@ietf.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Wed, 02 Sep 2020 23:19:49 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/3a1BfCQZTraurcfa_AZbENonl7k>
Subject: [mpls] [IANA #1177073] RE: Re: draft-tgraf-ipfix-mpls-sr-label-type
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Sep 2020 23:19:52 -0000

Hi Thomas, 

> Hi Sabrina, Hi Loa
> 
> I would appreciate if you could feedback the following remaining
> questions
> 
> > 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.

That's correct. The "References" section can point to any document. 

> > If above statement  is correct, would it make sense to correct IE46
> > accordingly? I am gladly assist to add the reference links and review
> > it with the IE doctor.

We'll have to ask the IE Doctors about updating IE46. If you'd like us to request another IE Doctors review, please let us know. 

> Thanks for clarifying that.
> 
> Best Wishes
> Thomas

Best regards, 

Sabrina Tanamal
Senior IANA Services Specialist

> -----Original Message-----
>  From: Graf Thomas, INI-NET-DCF
> Sent: Wednesday, August 12, 2020 10:33 AM
> To: iana-issues@iana.org; loa@pi.nu
> Cc: mpls@ietf.org
> Subject: RE: [IANA #1175554] Re: [mpls] 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
> > >