Hi Benoit, We will review the IANA Considerations section of this document and get back to you soon.
Thanks, Sabrina Tanamal Lead IANA Services Specialist On Mon Sep 26 10:03:12 2022, benoit.cla...@huawei.com wrote: > Dear IPFIX doctors, (IANA), > > We would like to get your feedback regarding the IANA section in > draft-ietf-opsawg-ipfix-srv6-srh-01. > Especially, the two following information elements: > srhFlagsIPv6: > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6- > srh-01#section-5.1 > srhSegmentEndpointBehavior: > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6- > srh-01#section-5.11 > > I went to the IANA table in Philly and we discussed those. Hence I > copied IANA here. > In the currentdraft-ietf-opsawg-ipfix-srv6-srh-01 > <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6- > srh-01> > version, we created two IPFIX subregistries, which mimic existing > Segment Routing registries. > The main reason is that we are in favor of having a self contained > IPFIX > IANA registry, which we can download as a cron job in the collector. > We > discussed such a project with Michelle Cotton in the past (I know that > Michelle moved on). On top of that, it might be beneficial for the > IPFIX > experts to review any changes coming from a registry we mimic, just to > see if there are no new inconsistencies from an IPFIX point of view. > > However, Med, in cc., has a valid point that the current IPFIX IANA > entries are inconsistencies already. > Ex: destinationTransportPort points to a different registry > Ex: tcpControlBit. See > https://datatracker.ietf.org/doc/draft-boucadair-opsawg-rfc7125- > update/ > So he advocated that we don't duplicate, with an IPFIX subregistry, > information stemming from a different source. Pointing to the existing > registry (ex: "Segment Routing Header Flags") + a RFC reference is > sufficient for him. Solving the self-contained IPFIX registry issue > would be a (too) huge job at this point in time. > > This is what we currently have in the draft: > > 5.1 > <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6- > srh-01#section-5.1>. > srhFlagsIPv6 > > Name: srhFlagsIPv6 > > ElementID: TBD1 > > Description: This Information Element identifies the 8-bit flags > defined in the SRH. Values for this Information Element are > listed in the "IPFIX IPv6 SRH Flags" registry, see [IANA-IPFIX > <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6- > srh-01#ref-IANA-IPFIX>]. > srhFlagsIPv6 values must not be directly added to this "IPFIX IPv6 > SRH Flags" registry. They must instead be added to the "Segment > Routing Header Flags" registry. Both the "IPFIX IPv6 SRH Flags" > and the "Segment Routing Header Flags" registries must be kept in > synch. Initial values in the registry are defined by the table > below. > > +--------+-------------------+--------------------------------------+ > | Value | Description | Reference | > +--------+-------------------+--------------------------------------+ > | 0-1 | Unassigned | | > +--------+-------------------+--------------------------------------+ > | 2 | O-flag | [RFC-ietf-6man-spring-srv6-oam-13] | > +--------+-------------------+--------------------------------------+ > | 3-7 | Unassigned | | > +--------+-------------------+--------------------------------------+ > > Table 2: "IPFIX IPv6 SRH Flags" registry > > > Note to IANA: Add a note to the "IPFIX SRV6 Endpoint Behavior" > registry so that new values are echoed in the new "IPFIX SRv6 > EndPoint Behavior > > Abstract Data Type: unsigned8 > > Data Type Semantics: flags > > Reference: [RFC-to-be],RFC8754 > <https://datatracker.ietf.org/doc/html/rfc8754> > > This is what Med proposes: > > 5.1 > <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6- > srh-01#section-5.1>. > srhFlagsIPv6 > > Name: srhFlagsIPv6 > > ElementID: TBD1 > > Description: This IE identifies the 8-bit flags defined in the SRH. > Assigned flags and their meanings are provided in the "Segment > Routing > Header Flags" registry. > > Abstract Data Type: unsigned8 > > Data Type Semantics: flags > > Reference: [RFC-to-be],RFC8754 > <https://datatracker.ietf.org/doc/html/rfc8754> > > > We basically agree that a registry lookup is required for the IPFIX > Collector. > An IPFIX Exporter will export what he sees, regardless of the semantic > or an IANA registry. The IPFIX Collector will report a potential > problem > if the observed value is not in the IANA registry (bug, IANA entry > hijacked, another convention => if value not observed, I'll send an > error code instead, etc) > > Bottom line: we have two different ways to model the srhFlagsIPv6 and > srhSegmentEndpointBehavior in IANA, with or without an IPFIX > subregistry. > Can you share your views on the best way to register those IEs. > > Thanks and regards, Benoit _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
