Re: [OPSAWG] 🔔 WG LC: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)

[Benoit Claise <[e-mail]>]

Hi Med,


On 11/30/2022 4:12 PM, [e-mail] 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 <[e-mail]> *De la part de* Joe Clarke 
> (jclarke)
> *Envoyé :* mercredi 30 novembre 2022 14:54
> *À :* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg