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

[Benoit Claise]

Hi,

The issues are that:
1. we are redefining the scope field 
(https://datatracker.ietf.org/doc/html/rfc7011#section-3.4.2.1) for 
instance. Actually multiple identical scope fields in the flow records, 
which is not foreseen in the IPFIX spec.
2. we still depend on the order ... of the scope in this case.
    At this one is a MUST
   If a
   different order of Scope Fields would result in a Record having a
   different semantic meaning, then the order of Scope Fields MUST be
   preserved by the Exporting Process.

3. we start to put instance specific into fixed IE. RFC6313 is the 
answer but doesn't fly for data plane flows

Regards, Benoit

On 9/20/2022 3:00 PM, mohamed.boucad...@orange.com wrote:

Re-,

Yes, you got it.

Maybe it is simple to consider a new IE that carries in the first 8 
bits the routing type and the occurrence in the remaining 8 bits. 
Multiple instances can be then sent if needed. Another approach for 
encoding both the order and occurrence is to have an IE that prepends 
the types with the same type repeated when multiple instances are 
present.

Cheers,

Med

*De :*thomas.g...@swisscom.com <thomas.g...@swisscom.com>
*Envoyé :* mardi 20 septembre 2022 14:06
*À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; 
benoit.cla...@huawei.com; jclarke=40cisco....@dmarc.ietf.org; 
opsawg@ietf.org
*Cc :* pierre.franc...@insa-lyon.fr
*Objet :* RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Med,

You read my mind. If I read yours correctly you mean that there can be 
multiple extension headers which could be exposed each with one IE64 
ipv6ExtensionHeaders. What we don't know is how many times each header 
type occurs and the order in the packet. What is also missing is the 
distinguisher between the routing types. Correct?
Best wishes
Thomas

*From:*mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>
*Sent:* Tuesday, September 20, 2022 11:13 AM
*To:* Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com>; 
benoit.cla...@huawei.com; jclarke=40cisco....@dmarc.ietf.org; 
opsawg@ietf.org
*Cc:* pierre.franc...@insa-lyon.fr
*Subject:* ***Signed_Message*** RE: CALL FOR ADOPTION: 
draft-tgraf-opsawg-ipfix-srv6-srh

Hi Thomas,

This is a useful addition. Thanks.

A more general question is to check whether one can report the 
identity of the EHs that form the Header Chain, but this is not 
specific to this draft. The current ipv6ExtensionHeaders does not 
allow for that.

Cheers,

Med

*De :*thomas.g...@swisscom.com <thomas.g...@swisscom.com>
*Envoyé :* lundi 19 septembre 2022 16:47
*À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; 
benoit.cla...@huawei.com; jclarke=40cisco....@dmarc.ietf.org; 
opsawg@ietf.org
*Cc :* pierre.franc...@insa-lyon.fr
*Objet :* RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Med,

Benoit will feedback on your reply.

In the meanwhile I like to take the opportunity to get your feedback 
on an additional operational consideration section I added based on an 
off list feedback I received from a software developer implementing 
the draft document.

https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt 
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fgraf3net%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2Fmain%2Fdraft-ietf-opsawg-ipfix-srv6-srh-01.txt&data=05%7C01%7CThomas.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xPFmIIS%2Bo7VVshlpesBx5v6OCtC5oJVGAkZQ5ap4xFE%3D&reserved=0>

5.3.  Multiple Segment Routing Headers

   [RFC8200] describes the support of multiple extension headers in one

   IPv6 packet.  Allowing the use of multiple SRH per SRv6 packet.  The

   export of the same IE multiple times in one data-record and data-

   template is supported and the order within the packet SHOULD be

   preserved in the IPFIX export according to Section 8 of [RFC7011].

   If the network node is not capable to export IPFIX for more than one

   SRH, it MUST export IPFIX for the active SRH.

Best wishes

Thomas

*From:*mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>
*Sent:* Monday, September 19, 2022 2:22 PM
*To:* Benoit Claise <benoit.cla...@huawei.com>; Graf Thomas, 
INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com>; 
jclarke=40cisco....@dmarc.ietf.org; opsawg@ietf.org
*Cc:* pierre.franc...@insa-lyon.fr
*Subject:* RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

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.

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”.

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.

Cheers,

Med

*De :*Benoit Claise <benoit.cla...@huawei.com>
*Envoyé :* samedi 17 septembre 2022 17:39
*À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; 
thomas.g...@swisscom.com; jclarke=40cisco....@dmarc.ietf.org; 
opsawg@ietf.org
*Cc :* pierre.franc...@insa-lyon.fr; me <benoit.cla...@huawei.com>
*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 
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fipv6-parameters%2Fipv6-parameters.xhtml%23segment-routing-header-flags&data=05%7C01%7CThomas.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JL1l5%2FMF4kuugfBlw5oDeOnvG9II1U4wJET9cBM2mrE%3D&reserved=0> 
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, mohamed.boucad...@orange.com 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fipv6-parameters%2Fipv6-parameters.xhtml%23segment-routing-header-flags&data=05%7C01%7CThomas.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JL1l5%2FMF4kuugfBlw5oDeOnvG9II1U4wJET9cBM2mrE%3D&reserved=0>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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9259&data=05%7C01%7CThomas.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iMoVMkCP94TxZteB3EmJePTmxI%2BewNRsARG%2FzsUa5M8%3D&reserved=0>
   |

                          +-----+-------------+-----------+

    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 
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fipv6-parameters%2Fipv6-parameters.xhtml%23segment-routing-header-flags&data=05%7C01%7CThomas.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JL1l5%2FMF4kuugfBlw5oDeOnvG9II1U4wJET9cBM2mrE%3D&reserved=0> 
is "IETF review" while 
https://www.iana.org/assignments/ipfix/ipfix.xhtml 
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fipfix%2Fipfix.xhtml&data=05%7C01%7CThomas.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7MkKV2NRl0OFbZYgE5%2BtseErVg%2BODHbLcTwydsxVKOQ%3D&reserved=0> 
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
    
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fsegment-routing%2Fsegment-routing.xhtml%23srv6-endpoint-behaviors&data=05%7C01%7CThomas.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ggzqTrPpyTZM7MpWHbVCB0fbpWLY%2FExC%2Fz6ARVIUOu0%3D&reserved=0>.


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 :*thomas.g...@swisscom.com <thomas.g...@swisscom.com>
    <mailto:thomas.g...@swisscom.com>
    *Envoyé :* jeudi 15 septembre 2022 20:08
    *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
    <mailto:mohamed.boucad...@orange.com>;
    jclarke=40cisco....@dmarc.ietf.org; opsawg@ietf.org
    *Cc :* benoit.cla...@huawei.com; pierre.franc...@insa-lyon.fr
    *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
    
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fgraf3net%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2Fmain%2Fdraft-ietf-opsawg-ipfix-srv6-srh-01.txt&data=05%7C01%7CThomas.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xPFmIIS%2Bo7VVshlpesBx5v6OCtC5oJVGAkZQ5ap4xFE%3D&reserved=0>

    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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ipfix-srv6-srh-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgraf3net%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2Fmain%2Fdraft-ietf-opsawg-ipfix-srv6-srh-01.txt&data=05%7C01%7CThomas.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m8Il%2FKVGzd69GsHldGPKvRlvHTE4VK9d6yC5aKMPO%2FM%3D&reserved=0>

    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 <opsawg-boun...@ietf.org> *On Behalf Of
    *mohamed.boucad...@orange.com
    *Sent:* Tuesday, September 6, 2022 10:19 AM
    *To:* Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>;
    opsawg@ietf.org
    *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%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v8H6N3reiWT7ewGbmz13bvMFaBOpRUJVA1Wbz645NAY%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%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iFprB%2Fa0q4eEKdVwmX6ZYOd3%2FbkHkolYelq%2FUap%2BgLY%3D&reserved=0>

    Cheers,

    Med

    *De :*OPSAWG <opsawg-boun...@ietf.org> *De la part de* Joe Clarke
    (jclarke)
    *Envoyé :* jeudi 18 août 2022 22:14
    *À :* opsawg@ietf.org
    *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

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg