Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

[Benoit Claise <[e-mail]>]

Hi Med,

On 9/19/2022 2:21 PM, [e-mail] 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 <[e-mail]>
> *Envoyé :* samedi 17 septembre 2022 17:39
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>; 
> [e-mail]; jclarke=[e-mail]; 
> [e-mail]
> *Cc :* [e-mail]; me <[e-mail]>
> *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, [e-mail] 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 :*[e-mail] <[e-mail]>
>     <mailto:[e-mail]>
>     *Envoyé :* jeudi 15 septembre 2022 20:08
>     *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
>     <mailto:[e-mail]>;
>     jclarke=[e-mail]; [e-mail]
>     *Cc :* [e-mail]; [e-mail]
>     *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 <[e-mail]> *On Behalf Of
>     *[e-mail]
>     *Sent:* Tuesday, September 6, 2022 10:19 AM
>     *To:* Joe Clarke (jclarke) <jclarke=[e-mail]>;
>     [e-mail]
>     *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 <[e-mail]> *De la part de* Joe Clarke
>     (jclarke)
>     *Envoyé :* jeudi 18 août 2022 22:14
>     *À :* [e-mail]
>     *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.