Hi Amanda, IPFIX IE doctors,
See inline.
On 9/30/2022 4:58 AM, Amanda Baber via RT wrote:
Hi Benoit, all,
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
We can keep separate registries in sync (although we don't currently have
automation to ensure this), but is the intention for the IPFIX IPv6 SRH Flags
and IPFIX SRV6 Endpoint Behavior registries to be contained within each IPFIX
IE registration's Description field?
In 2020, with IE Doctor approval, all IPFIX IE Description field tables that constituted
sub-registries were replaced with links to separate sub-registries located outside of the
IPFIX Information Elements registry. You can see the list of sub-registries under the
heading "Registries included below":
https://www.iana.org/assignments/ipfix
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).
I'm afraid we don't have any of Michelle's notes on this topic. What will you
need IANA to do? We may need to put you in touch with IANA's technical
director. In the future, the registries will be moved from an XML-based to a
database-based registry system.
Regarding the argument of "having a self having a self contained IPFIX
IANA registry, which we can download as a cron job in the collector",
what we need is the ability to retrieve either the entire registry in
one go, or have pointers to other (registries) the IPFIX collector has
to take into account ... in an automatic manner
The former, with subregistries duplication (and synchronization) might
be beyond repair at this point in time (at least, I don't have the
courage to engage), on top of pushing much administration to IANA for
the synchronization/maintenance
Looking closer at the IFPIX registry, let me provide a logic that might
work, without too much changes IMO.
Let's say I take care of a IPFIX collector, which I need to update on
regular basis, there are different cases:
1. A new IPFIX IE is added in the registry
Ex: Let's say I specify in IANA the IPFIX IE 492 = "my-new-field"
I download the entire registry as a cronjob, install it in my
collector, and I can now understand all flow records that contain the
new IPFIX IE 492
2. A new value is added for one of the IPFIX sub-registries
Ex: Let's say I add value 25 = "my-new-classification-engine-id" at
https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids
What is the logic?
I download the entire registry as a cronjob, parse the file, when I
arrive at IPFIX field 101 (classificationEngineId) => I do a lookup on
*[https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids]
in the Description field* , read the new value 25, install it in my
collector, and I can now understand all flow records that contain a
classificationEngineId value 25.
3. A new value is added for in the external (non-IPFIX) registry
Ex: a new port is added to
https://www.iana.org/assignments/service-names-port-numbers].
The following IPFIX IEs refer to this registry:
sourceTransportPort, destinationTransportPort, udpSourcePort,
udpDestinationPort, udpDestinationPort, etc.
What is the logic?
I download the entire registry as a cronjob, parse the file, when I
arrive at any of those IPFIX IEs => I do a lookup**on
https://www.iana.org/assignments/service-names-port-numbers*in the
Addition Information field*, read the new port value, install it in my
collector, and I can now understand all flow records that contain the
new port value
At least the logic could work (even if looking up two fields is not
ideal from a logic point of view)
I checked all http links in the IPFIX registry and found 3 "exceptions"
- [http://standards.ieee.org/regauth/ethertype/eth.txt], will not work,
but we might consider this one as an exception.
- portRangeStart and portRangeEnd point to
https://www.iana.org/assignments/service-names-port-numbers. Not to sure
how to treat this one in an automatic way
- [https://www.iana.org/assignments/ianaiftype-mib] should be treated
differently, but that's fine.
One conclusion is that there are different treatments whether the links
are in the *Description field* or the *Additional Information* field.
Interestingly, RFC 7102 doesn't mention this *Additional Information*
field :-) And this is precisely this one that I would like to use below,
since we speak about non-IPFIX registries in
draft-ietf-opsawg-ipfix-srv6-srh.
If we don't pay attention to that detail, here is a proposal (combining
Med proposal with the logic above)
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>
*Additional reference:
****https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags*
Note: and similarly for5.9
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.9>.
srhActiveSegmentIPv6Type Note: as you can see, I have a different opinion that Med on this one => we need to point to the specific registry within the group, for automatic treatment
Would that work, or IANA/IPFIX doctors will frown upon because the*"additional
information"* field is not mentioned in RFC7102?
Regards, Benoit
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>
When IANA links to this registry, will the link have to point to,
e.g.,https://www.iana.org/assignments/segment-routing/segment-routing#the-specific-registry,
or would it be sufficient to point
tohttps://www.iana.org/assignments/segment-routing (the registry group, rather
than the specific registry within it)?
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
thanks,
Amanda Baber
IANA Operations Manager
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
