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:
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>
*Envoyé :* mercredi 4 janvier 2023 18:43
*À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>;
thomas.g...@swisscom.com; opsawg@ietf.org
*Cc :* 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
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 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 <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
Cc :pierre.franc...@insa-lyon.fr;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-
ietf-opsawg-ipfix-srv6-srh-
05.txt&url2=https://raw.githubusercontent.com/graf3net/draft-ietf-
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 <mohamed.boucad...@orange.com>
<mailto:mohamed.boucad...@orange.com>
Sent: Friday, December 16, 2022 9:24 AM
To: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 Envoyé : vendredi 16 décembre 2022 08:50 À :
i-d-annou...@ietf.org Cc :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.
