Dear Med,
Also many thanks from my side. Much appreciated. I just submitted the -06 version. If there aren't any objections anymore I think Joe can go ahead from here. Best wishes Thomas From: Benoit Claise <benoit.cla...@huawei.com> Sent: Thursday, January 5, 2023 10:08 AM To: mohamed.boucad...@orange.com; Graf Thomas, INI-NET-VNC-HCS <thomas.g...@swisscom.com>; opsawg@ietf.org Cc: pierre.franc...@insa-lyon.fr Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-05.txt Hi Med, Perfect. That makes sense. Let's execute on this proposal below. Let me stress again: thanks for your continuous effort to improve this draft. Regards, Benoit On 1/5/2023 9:18 AM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Benoît, You got it. We are not defining a new ordering behavior, but simply adhering to what the IPFIX spec says on this matter. I would mix your proposed wording with what Thomas already implemented in https://raw.githubusercontent.com/graf3net/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-06.txt<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fgraf3net%2Fdraft-ietf-opsawg-ipfix-srv6-srh%2Fmain%2Fdraft-ietf-opsawg-ipfix-srv6-srh-06.txt&data=05%7C01%7CThomas.Graf%40swisscom.com%7C030c14372af44186df3f08daeefc654b%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638085065034569126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8Gbgh5prOWQNqCKPgZ6rFGBYpg%2BJWIMxZ6TmYoF9UtA%3D&reserved=0>: NEW: If multiple SRHs are observed (for reasons that are not detailed here), the export of the same IE multiple times in one data record and related template record is supported. In such a case, the following IPFIX behavior in Section 8 of [RFC7011] applies: "If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process". If the network node is not capable to export IPFIX for more than one SRH, it MUST export IPFIX for the SRH of the active segment. Thank you. Cheers, Med De : Benoit Claise <benoit.cla...@huawei.com><mailto:benoit.cla...@huawei.com> Envoyé : mercredi 4 janvier 2023 18:43 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>; thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>; opsawg@ietf.org<mailto:opsawg@ietf.org> Cc : pierre.franc...@insa-lyon.fr<mailto:pierre.franc...@insa-lyon.fr> Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-05.txt Hi Med, Thanks for your continuous effort to improve this draft. Help me understand your point of view regarding your comment: Thanks for preparing this revised version. The changes look good. However, and as discussed previously, I was expecting to see s/packet SHOULD be preserved in the IPFIX export according/packet should be preserved in the IPFIX export according. Actually, we have this specific sentence in https://www.rfc-editor.org/rfc/rfc7011#section-8<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7011%23section-8&data=05%7C01%7CThomas.Graf%40swisscom.com%7C030c14372af44186df3f08daeefc654b%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638085065034569126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PKxT4VMFnU71WksqBevXvHU7Guc458g1x8LmcK5Rvx0%3D&reserved=0> If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process. This sentence applies to the case of multiple SRHs in a Flow Record and this specification MUST be followed in such a case. This was actually our intent with this paragraph in the draft version 5, that is drawing attention to that specific sentence: 6.3. Multiple Segment Routing Headers [RFC8200] describes the support of multiple extension headers such as the SRH in one IPv6 packet. The export of the same IE multiple times in one data record and related 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 Do we agree so far on the intent of this paragraph? I believe so when I re-read your initial comment: I suggest to simplify the wording of 6.3 to basically say: if multiple SRHs are observed (for reasons that are not detailed here), exporting multiple IEs is allowed + follow the base reco in 7011 for the ordering. No normative language is needed for this behavior. Reco? Granted, we most likely did not express ourselves correctly in section 6.3. For ex, we used a SHOULD to be aligned with the sentence in RFC7011. Is this this issue at stake here: this might be perceived as we are writing a new IPFIX spec? If we agree till this point, what about this? 6.3. Multiple Segment Routing Headers [RFC8200] describes the support of multiple extension headers such as the SRH in one IPv6 packet. The export of the same IE multiple times in one flow record and related template record is supported. In such case the following IPFIX specification in Section 8 of [RFC7011] applies: "If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process." If the network node is not capable to export IPFIX for more than one SRH, it MUST export IPFIX for the active SRH Please let us know. Regards, Benoit On 1/4/2023 5:05 PM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Thomas, Thanks for preparing this revised version. The changes look good. However, and as discussed previously, I was expecting to see s/packet SHOULD be preserved in the IPFIX export according/packet should be preserved in the IPFIX export according. Some minor nits: * Please note that there are still some occurrences in the draft about many subregistries, while only ** one ** is created, e.g., This document specifies eleven new IPFIX Information Elements (IEs) and three new subregistries within the "IPFIX Information Elements" registry [RFC7012], for SRv6 purposes. or This document requests IANA to create new IEs (see table 1) and three new subregistries called "IPFIX IPv6 SRH Flags" (table 2), "IPFIX IPv6 SRH Segment Type" (table 3), and "IPFIX SRv6 Endpoint Behavior" (table 4) under the "IPFIX Information Elements" registry [RFC7012] available at [IANA-IPFIX]. * Please fix the numbering of your tables. * s/RFC8986 Section 3.1/Section 3.1 of RFC8986 * s/RFC8986 Section 4/ Section 4 of RFC8986 * s/The SID Locator as described in section 3.1 [RFC8986]/ The SID Locator as described in Section 3.1 of [RFC8986] * This is not a new requirement: OLD: (*) The Length MUST be calculated to include the optional Type Length Value objects. NEW: (*) The Length must be calculated to include the optional Type Length Value objects. (There are two occurrences in the draft to be fixed). * "for the values presented in Table 12": couldn't find that table. Cheers, Med -----Message d'origine----- De : thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> <thomas.g...@swisscom.com><mailto:thomas.g...@swisscom.com> Envoyé : samedi 17 décembre 2022 08:16 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>; opsawg@ietf.org<mailto:opsawg@ietf.org> Cc : pierre.franc...@insa-lyon.fr<mailto:pierre.franc...@insa-lyon.fr>; benoit.cla...@huawei.com<mailto:benoit.cla...@huawei.com> Objet : RE: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh- 05.txt Dear Med, Many thanks for the review and my apology that we missed your input on section 5.9 I updated the document on section 5.9 and 6.3 as per input. Please review and comment before we submit. https://author- tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft&data=05%7C01%7CThomas.Graf%40swisscom.com%7C030c14372af44186df3f08daeefc654b%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638085065034569126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aqJctEMAYCJNI%2B5Uu7VwdrmfCv0QJ4uORBp8QwH3eZY%3D&reserved=0>- ietf-opsawg-ipfix-srv6-srh- 05.txt&url2=https://raw.githubusercontent.com/graf3net/draft-ietf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fgraf3net%2Fdraft-ietf&data=05%7C01%7CThomas.Graf%40swisscom.com%7C030c14372af44186df3f08daeefc654b%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638085065034569126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DF0QH%2BUPYwop%2FzkgRWEPA76maNhUHJzkJp74uhdF%2BLg%3D&reserved=0>- opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-06.txt We agree that RFC 8200 doesn't explicitly describe the use of multiple SRH and therefore the wording in section 6.3 is misleading as you pointed out. Therefore we removed the RFC 8200 reference and used your wording proposal. In section 6.3 we want to ensure that there is no ambiguity how IPFIX needs to be implemented in case more than one SRH is present. Section 8 of RFC 7011 describes only the case when both SRH can be exported. Since section 6 is devoted to operational considerations, the authors believe it make sense to spend a paragraph in describing both cases, when both SRH can be export versus when only the SRH of the active segment can be exported in IPFIX to have a complete description. Does that make sense? Best wishes Thomas -----Original Message----- From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com> Sent: Friday, December 16, 2022 9:24 AM To: opsawg@ietf.org<mailto:opsawg@ietf.org>; Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com><mailto:thomas.g...@swisscom.com> Subject: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6- srh-05.txt Hi Thomas, all, Thanks for preparing this version. However, I think that not all the issues were fixed: * Section "5.9. srhActiveSegmentIPv6Type": please add the pointer to the IANA registry under "Additional Information". Please see the proposal from Benoît at: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F mailarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2FZZ5anFVYpabnmm12sfkmG B6nHYI%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea 48ca6a0d08dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C 638067758737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata= 1X%2BI2yBo6C5NApGb053NIyCj2LYIdWlZWaxjbj0kr5A%3D&reserved=0 * The text about multiple SRH is somehow "misleading" as it can be interpreted as 8200 discusses explicitly multiple SRHs case. Also, and unless I' mistaken, there is no spring document that motivates the need for multiple SRHs or how these can be used. I suggest to simplify the wording of 6.3 to basically say: if multiple SRHs are observed (for reasons that are not detailed here), exporting multiple IEs is allowed + follow the base reco in 7011 for the ordering. No normative language is needed for this behavior. * Please define what is meant by "active SRH". Thank you. Cheers, Med -----Message d'origine----- De : OPSAWG <opsawg-boun...@ietf.org><mailto:opsawg-boun...@ietf.org> De la part de internet- dra...@ietf.org<mailto:dra...@ietf.org> Envoyé : vendredi 16 décembre 2022 08:50 À : i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> Cc : opsawg@ietf.org<mailto:opsawg@ietf.org> Objet : [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh- 05.txt A New Internet-Draft is available from the on-line Internet- Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) Authors : Thomas Graf Benoit Claise Pierre Francois Filename : draft-ietf-opsawg-ipfix-srv6-srh-05.txt Pages : 28 Date : 2022-12-15 Abstract: This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of Segment Routing over IPv6 (SRv6) related information such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 endpoint behavior that traffic is being forwarded with. The IETF datatracker status page for this draft is: _________________________________________________________________________________________________________________________ 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
