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

Sabrina Tanamal via RT <iana-issues@iana.org> Mon, 10 August 2020 21:43 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 175033A0D77 for <mpls@ietfa.amsl.com>; Mon, 10 Aug 2020 14:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 0XSgSAS9GjBz for <mpls@ietfa.amsl.com>; Mon, 10 Aug 2020 14:43:36 -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 5853F3A0B48 for <mpls@ietf.org>; Mon, 10 Aug 2020 14:43:36 -0700 (PDT)
Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 3A580E011C; Mon, 10 Aug 2020 21:43:36 +0000 (UTC)
Received: by request4.lax.icann.org (Postfix, from userid 48) id 363342047B; Mon, 10 Aug 2020 21:43:36 +0000 (UTC)
RT-Owner: sabrina.tanamal
From: Sabrina Tanamal via RT <iana-issues@iana.org>
Reply-To: iana-issues@iana.org
In-Reply-To: <a6bf71f4-7495-de06-bd38-cc12390901d6@pi.nu>
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>
Message-ID: <rt-4.4.3-5345-1597095816-1787.1175554-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1175554
X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: sabrina.tanamal@icann.org
To: loa@pi.nu
CC: mpls@ietf.org, thomas.graf@swisscom.com
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Mon, 10 Aug 2020 21:43:36 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/6Du4FHOgT8mHf-AX7aJq12LtkBk>
Subject: [mpls] [IANA #1175554] 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: Mon, 10 Aug 2020 21:43:38 -0000

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%2Ftool
> >> 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%7C637319524588913415&amp;s
> >> data=KVpjfCOYwZoJen3uAqID0sK%2FrWIujm4q7vDigug2%2B9A%3D&amp;reserved=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%7C364e5b87c1c7420d9beec35d19b55
> >> 7a1%7C1%7C0%7C637319524588913415&amp;sdata=U9jmYfa0Kxd7ewrOmAgBpoiFLFg
> >> 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%2BZCF%2B
> >> FaKjdEDB0hdvku7RkzsMLGPDLQ4y8%3D&amp;reserved=0
> >>
> >