Hi Med,
On 9/19/2022 2:21 PM, [email protected] wrote:
Hi Benoît,
Thank you for the follow-up.
Actually, the more I look into this, the more I’m convinced that we
don’t need a new registry for the flags and that the statement “Values
for this Information Element are listed in the "IPFIX IPv6 SRH Flags"
registry” is restrictive (inaccurate(?)). The flags should be exported
as ** observed ** not as set in the registry.
Observed for sure, but for one specific flag value, we must find the
semantic.
This is where the registry comes in place, for matching an observed
value with a semantic
Think about discarded packets because some flags are set (including
those already for which a meaning is already defined such as the O
flag) while the processing of these flags is not supported by a
router. In such cases, one use of the srhFlagsIPv6 IE would be to
display the erroneous set of flags together with some error counters.
The values of the IE is not “taken from the IANA registry”.
Am I wrong, or in case, you are overloading the srhFlagsIPv6 with your
own convention?
How do you want the collector to interpret this flow.
That said, I fully agree that the spec has to indicate “Data Type
Semantics: flags” for that IE.
The same would apply for the srhSegmentEndpointBehavior IE.
Please let me know if I’m missing something. Thanks.
Maybe we speak cross purposes. Shall we set up a quick call?
Regards, Benoit
Cheers,
Med
*De :*Benoit Claise <[email protected]>
*Envoyé :* samedi 17 septembre 2022 17:39
*À :* BOUCADAIR Mohamed INNOV/NET <[email protected]>;
[email protected]; [email protected];
[email protected]
*Cc :* [email protected]; me <[email protected]>
*Objet :* Re: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh
Hi Med,
Thanks for your comments.
I visited IANA in Philly to validate this propose, but we could
re-evaluate & discuss about it.
We need a registry because just telling that we take the value from
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags
is not sufficient as we also need to specify the following IPFIX fields:
- Abstract Data Type. (unsigned8 in this srhFlagsIPv6 case)
- Data Type Semantics (flags in srhFlagsIPv6 case)
Now, if your point is that we don't really to mention the initial
values ...
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
... I agree it's not strictly necessary but it helps (me/the IPFIX
experts) to understand, from this document, which type of values are
currently available.
See inline.
On 9/16/2022 9:34 AM, [email protected] wrote:
Hi Thomas,
Thank you for preparing this revised version.
I think almost all my comments are addressed in this version.
However, I still don’t see the need to have new registries that
only mirror existing ones. For example, and unless I missed some
subtleties, it would be sufficient to say that the flag values are
taken from
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags
<https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags>rather
than adding the following in the I-D:
+--------+-------------------+--------------------------------------+
| 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
which is similar in term of encoding and values as what was set by
RFC9256:
IANA has registered the following in the "Segment Routing Header
Flags" subregistry in the "Internet Protocol Version 6 (IPv6)
Parameters" registry:
+=====+=============+===========+
| Bit | Description | Reference |
+=====+=============+===========+
| 2 | O-flag |RFC 9259
<https://datatracker.ietf.org/doc/html/rfc9259> |
+-----+-------------+-----------+
BTW, I guess you initially meant:
NEW:
Table 2: "IPFIX IPv6 SRH Flags" registry
Note to IANA: Add a note to the "Segment Routing Header Flags"
registry
so that new values are echoed in the new "IPFIX IPv6 SRH Flags”
You are right (since
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags
is "IETF review" while
https://www.iana.org/assignments/ipfix/ipfix.xhtml is "Expert Review")
instead of CURRENT:
Table 2: "IPFIX IPv6 SRH Flags" registry
Note to IANA: Add a note to the registry so that new values are
echoed in the new "IPFIX SRv6 EndPoint Behavior
The same comment applies for the values that can be directly taken
from
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors.
Yes
OLD:
Table 4: "IPFIX SRV6 Endpoint Behavior" registry
Note to IANA: Add a note to the registry so that new values are
echoed in the new "IPFIX SRv6 EndPoint Behavior
NEW:
Table 4: "IPFIX SRV6 Endpoint Behavior" 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
Regards, Benoit
Cheers,
Med
*De :*[email protected] <[email protected]>
<mailto:[email protected]>
*Envoyé :* jeudi 15 septembre 2022 20:08
*À :* BOUCADAIR Mohamed INNOV/NET <[email protected]>
<mailto:[email protected]>;
[email protected]; [email protected]
*Cc :* [email protected]; [email protected]
*Objet :* RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh
Dear Med,
Many thanks for the comprehensive review. Much appreciated. We
merged all your input to the upcoming -01 release.
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt
The diff to the current -00 version can be found here:
https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt
<https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt>
For some we need further clarifications if we addressed them
correctly. I would appreciate if you could clarify the following
three points:
Med> Section 2, remark: "Why do we need three IE,
srhSegmentIPv6ListSection, srhSegmentIPv6BasicList and
srhSectionIPv6, to expose SRH Segment List
Thomas> Section 5.1 should provide the answer. If that should not
be sufficient, please suggest how this could be better expressed.
Med> Section 2: remark: "as series of n octets" is not clearly
comprehensible.
Thomas> Extended to "as series of n octets in IPFIX". Does that
makes it clearer?
Med> Section 4.11, remark: "Do you really need to define a new
registry here?"
Thomas> The registry could potentially be used (and updated) by
non IPFIX people.
Best wishes
Thomas
*From:*OPSAWG <[email protected]> *On Behalf Of
*[email protected]
*Sent:* Tuesday, September 6, 2022 10:19 AM
*To:* Joe Clarke (jclarke) <[email protected]>;
[email protected]
*Subject:* Re: [OPSAWG] CALL FOR ADOPTION:
draft-tgraf-opsawg-ipfix-srv6-srh
Hi all,
I support.
FWIW, the authors may found some quick comments at:
1. pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgraf-opsawg-ipfix-srv6-srh-05-rev%20Med.pdf
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-05-rev%2520Med.pdf&data=05%7C01%7CThomas.Graf%40swisscom.com%7C9b7f1961451f468f5ed208da8fe08358%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637980491680499647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GmDWAcd71AYy6N%2BWx5469KaEjcmDCLJ%2FDsVv3LINv88%3D&reserved=0>
2. doc:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgraf-opsawg-ipfix-srv6-srh-05-rev%20Med.doc
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-05-rev%2520Med.doc&data=05%7C01%7CThomas.Graf%40swisscom.com%7C9b7f1961451f468f5ed208da8fe08358%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637980491680499647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RCDJoUkBTJ%2Fooe%2BvJEOTagdDY64LIVvfrH4RhyBsAKI%3D&reserved=0>
Cheers,
Med
*De :*OPSAWG <[email protected]> *De la part de* Joe Clarke
(jclarke)
*Envoyé :* jeudi 18 août 2022 22:14
*À :* [email protected]
*Objet :* [OPSAWG] CALL FOR ADOPTION:
draft-tgraf-opsawg-ipfix-srv6-srh
Hello, WG. We’d like to begin a two week call for adoption of
this work. Even as an individual draft it has already received
some reviews and has iterated quite a bit. Based on IETF 114
there does seem to be interest in adopting this in opsawg, but we
need a formal adoption poll.
Please review and provide your adoption thoughts no later than
September 1, 2022.
Thanks.
Joe
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
