Hi Med,
On 11/30/2022 4:12 PM, mohamed.boucad...@orange.com wrote:
Hi all,
This version addresses all the comments raised in my previous review
of the document. I have only very few comments:
* Section “5.9. srhActiveSegmentIPv6Type”: please add the pointer
to the IANA registry under “Additional Information”.
That makes sense.
OLD:
Additional Information: [RFC-to-be]
NEW:
Additional Information: [IPFIX IPv6 SRH Segment Type Subregistry]
Note to IANA: replace [IPFIX IPv6 SRH Segment Type Subregistry] with the URL
Now, I double-checked the first three subregistries in [IPFIX-IANA], with an
IPFIX subregistry.
_mplsTopLabelType = 46_ There is a discrepancy between the URL in
"Description" and "Additional Information " Actually, the one in
"Additional Information " is wrong _Forwarding Status = 89._
I would have been expecting the "Additional Information" to contain a pointer tohttps://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status
Instead it contains: See "NetFlow Version 9 Flow-Record Format" [CCO-NF9FMT <http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html>]. _classificationEngineId = 101_ The following must move from the
description to the "Additional Information" Values for this field are
listed in the Classification Engine IDs registry. See
[https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids]
So it seems that we need to update our
https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/ draft. :-)
*
* Section 6.3:
o Is there any SPRING document that explains the motivation for
having more than one SRH?
Let me search for this.
*
o
o Please reword these two sentences:
OLD:
[RFC8200] describes the support of multiple extension headers in one
IPv6 packet. Allowing the use of multiple SRH per SRv6 packet.
o I’m afraid the SHOULD normative language for the ordering is
not required as it is redundant (?) with this part from RFC7011:
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.
proposal:
OLD:
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].
NEW:
The export of the same IE multiple times in one data record and related
template is supported, following the IPFIX specifications [RFC7011] that
mentions:
"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."
o What is an “active SRH”?
I guess the right terminology is "active segment" instead of "active SRH"
The/active segment/is indicated by the destination address of the packet
[RFC8402]
Proposal: remove "active SRH" by "active segment" in the sentence.
I support advancing this spec assuming these comments are addressed.
Thanks.
Regards, Benoit
Cheers,
Med
*De :*OPSAWG <opsawg-boun...@ietf.org> *De la part de* Joe Clarke
(jclarke)
*Envoyé :* mercredi 30 novembre 2022 14:54
*À :* opsawg@ietf.org
*Objet :* [OPSAWG] 🔔WG LC: Export of Segment Routing over IPv6
Information in IP Flow Information Export (IPFIX)
Hello, WG. As discussed at IETF 115, we want to conduct a WG LC for
draft-ietf-opsawg-ipfix-srv6-srh. The authors believe this work is
stable and moreover used the 115 hackathon to develop a interoperable
implementations (linked in Data Tracker) . Additionally, IANA has
already weighed in on this work and agree with the considerations
approach.
Therefore, we are calling for a two week LC. We will conclude on
December 14.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/
Please review the current -04 draft, post your comments and/or your
thoughts on the current text.
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.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
