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?
