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>
Envoyé : samedi 17 décembre 2022 08:16
À : BOUCADAIR Mohamed INNOV/NET<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>
Sent: Friday, December 16, 2022 9:24 AM
To:opsawg@ietf.org; Graf Thomas, INI-NET-TCZ-ZH1
<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> 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:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
datatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-srv6-
srh%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea48c
a6a0d08dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638
067758737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yHP
X83xmakzfCRJZMxdJ5oq9T3xHbvCN9C2HHMGYaDg%3D&reserved=0
There is also an htmlized version available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg-ipfix-
&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea48ca6a0d0
8dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638067758
737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xZjDt94k7
d99AQtEzMjXpO7Im2XD8Cqhn3cqvMTpO24%3D&reserved=0
srv6-srh-05
A diff from the previous version is available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
author-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-ipfix-
&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea48ca6a0d0
8dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638067758
737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mJK3LG78C
v9ZrnCKjUVSRoVIG9cobzA39Rw3S9xMFRk%3D&reserved=0
srv6-srh-05
Internet-Drafts are also available by rsync at
rsync.ietf.org::internet-drafts
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=05%7C01%7CThomas.G
raf%40swisscom.com%7Cf3bfd5fa3dea48ca6a0d08dadf3ef5aa%7C364e5b87c1
c7420d9beec35d19b557a1%7C0%7C0%7C638067758737320741%7CUnknown%7CTW
FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CZyegNLrHoOuaEI8F%2FacJvryhilFtr8
0r8j0is6Iors%3D&reserved=0
__________________________________________________________________
_______________________________________________________
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
