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

[Rob Wilton (rwilton)]

Hi Benoit,

Yes, that is fine with me.

Regards,
Rob


From: Benoit Claise 
Sent: 16 December 2022 10:13
To: Joe Clarke (jclarke) ; opsawg@ietf.org; 
Rob Wilton (rwilton) 
Subject: Re: [OPSAWG]  WG LC: Export of Segment Routing over IPv6 Information 
in IP Flow Information Export (IPFIX)

Hi Rob,

Do we get the green light to request the IANA early allocation 
[https://datatracker.ietf.org/doc/html/rfc7120#section-2] since there are 
multiple implementations already?

Regards, Benoit
On 12/15/2022 9:32 PM, Joe Clarke (jclarke) wrote:
Closing this WG LC out.  A great deal of support has been expressed for this 
work, and the chairs appreciate the attention to not only IANA but working 
implementations.

This draft will move forward to the IESG.  However, we NEED a shepherd.  I 
personally don’t feel comfortable shepherding this (nor do I really have the 
bandwidth at the moment).  Is there someone – perhaps someone that expressed 
their support – that would be willing to shepherd?

Joe

From: Joe Clarke (jclarke) <mailto:jcla...@cisco.com>
Date: Wednesday, November 30, 2022 at 08:53
To: opsawg@ietf.org<mailto:opsawg@ietf.org> 
<mailto:opsawg@ietf.org>
Subject:  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



___

OPSAWG mailing list

OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>

https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Benoit Claise]

Hi Rob,

Do we get the green light to request the IANA early allocation 
[https://datatracker.ietf.org/doc/html/rfc7120#section-2] since there 
are multiple implementations already?


Regards, Benoit

On 12/15/2022 9:32 PM, Joe Clarke (jclarke) wrote:


Closing this WG LC out.  A great deal of support has been expressed 
for this work, and the chairs appreciate the attention to not only 
IANA but working implementations.


This draft will move forward to the IESG.  However, we NEED a 
shepherd.  I personally don’t feel comfortable shepherding this (nor 
do I really have the bandwidth at the moment).  Is there someone – 
perhaps someone that expressed their support – that would be willing 
to shepherd?


Joe

*From: *Joe Clarke (jclarke) 
*Date: *Wednesday, November 30, 2022 at 08:53
*To: *opsawg@ietf.org 
*Subject: *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


___
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

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

[Joe Clarke (jclarke)]

Closing this WG LC out.  A great deal of support has been expressed for this 
work, and the chairs appreciate the attention to not only IANA but working 
implementations.

This draft will move forward to the IESG.  However, we NEED a shepherd.  I 
personally don’t feel comfortable shepherding this (nor do I really have the 
bandwidth at the moment).  Is there someone – perhaps someone that expressed 
their support – that would be willing to shepherd?

Joe

From: Joe Clarke (jclarke) 
Date: Wednesday, November 30, 2022 at 08:53
To: opsawg@ietf.org 
Subject:  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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Gyan Mishra]

I support publication. The IETF 115 hackathon is a great  data point on
development of interoperability of implementations.

Thanks

Gyan

On Wed, Nov 30, 2022 at 8:54 AM Joe Clarke (jclarke)  wrote:

> 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
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Diego R. Lopez]

Hi,

I support progressing to the next stage with this document. As expressed 
before, it addresses interesting aspects for IPFIX, already demonstrated in 
practice.

Be goode,


--
“Esta vez no fallaremos, Doctor Infierno”

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Mobile: +34 682 051 091
-


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



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Ahmed Abdelsalam (ahabdels)]

Hi

I support the WGLC for this draft. The draft introduces a set of new 
interesting IPFIX IE for SRv6.

Cheers,
Ahmed

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To: opsawg@ietf.org
Subject: [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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Pablo Camarillo (pcamaril)]

Hi,
I support the progression of this document. The proposal has been demonstrated 
at the IETF 115 hackathon, and there are multiple open-source implementations.
Cheers,
Pablo.
From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To: opsawg@ietf.org
Subject: [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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA]

Dear OPSAWG,

I support this document to move forward. SRv6 has gained lot of traction, thus, 
having a way to collect SR information through a standard mechanism like IPFIX 
will enhance the monitoring of the network.

In addition, the proposal has already been validated in the IETF 115 hackathon 
through multiple open-source implementations, which will help in adopting this 
extension of IPFIX.

Thank you for this contribution,

Best regards,
Nacho.

From: OPSAWG  on behalf of "Joe Clarke (jclarke)" 

Date: Wednesday, 30 November 2022 at 14:54
To: "opsawg@ietf.org" 
Subject: [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



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Paolo Volpato]

Dear WG,
I have read the draft and support moving this work toward publication.
It is relevant as it specifies new IPFIX Information Elements necessary for the 
export of SRv6-related information and the management of an SRv6 network.

Best Regards
Paolo


From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To: opsawg@ietf.org
Subject: [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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Alex Huang Feng]

Dear OPSAWG,

In the same lines, I just wanted to say that I implemented this draft in the 
open-source project Fd.io  VPP (*) and found no issues.

Alex

(*) https://github.com/insa-unyte/vpp-srh-onpath-telemetry 


> On 5 Dec 2022, at 20:26, Paolo Lucente  wrote:
> 
> 
> Hi,
> 
> Speaking with my hat of software developer: I have implemented this in the 
> free open-source flow collector pmacct (*) as part of the IETF 115 hackathon 
> and found no issues. I hence support WGLC of the document.
> 
> Paolo
> 
> (*) https://github.com/pmacct/pmacct
> 
> 
> On 30/11/22 10:53, Joe Clarke (jclarke) wrote:
>> 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
>> ___
>> 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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Chongfeng Xie]

Hi Chairs, folks,

I support the Last Call of this draft.

The approach defined in this draft is very useful for operators who have 
deployed SRv6, and the text is well written, I hope it can progress and enter a 
new stage to meet the requirement of SRv6 operation.  

Thanks are given to the authors for their work.

Best regards

Chongfeng

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To: opsawg@ietf.org
Subject: [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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Paolo Lucente]

Hi,

Speaking with my hat of software developer: I have implemented this in 
the free open-source flow collector pmacct (*) as part of the IETF 115 
hackathon and found no issues. I hence support WGLC of the document.


Paolo

(*) https://github.com/pmacct/pmacct


On 30/11/22 10:53, Joe Clarke (jclarke) wrote:
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


___
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

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

[Benoit Claise]

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  ]. _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  *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.

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

[Alex Huang Feng]

Dear OPSAWG,

As a contributor, I believe this work is ready and necessary for SRv6 networks. 
I support the WG LC.

Regards,
Alex

> On 30 Nov 2022, at 14:53, Joe Clarke (jclarke) 
>  wrote:
> 
> 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
> ___
> 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

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

[Thomas.Graf]

Dear Qin,

Thanks a lot for the detailed review and comments. This is much appreciated. My 
answers inline.

I am tracking the changes in here:

https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-srv6-srh-04.txt=https://raw.githubusercontent.com/graf3net/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-05.txt

Best wishes
Thomas

From: Qin Wu 
Sent: Saturday, December 3, 2022 3:07 PM
To: Joe Clarke (jclarke) ; opsawg@ietf.org
Cc: Graf Thomas, INI-NET-TCZ-ZH1 
Subject: RE:  WG LC: Export of Segment Routing over IPv6 Information in IP 
Flow Information Export (IPFIX)

Hi, All:
Thanks authors to write this draft and validate it using Hackathon project. I 
take some time to review this draft, my general position is to support moving 
this work toward publication.
Here are a few comments and suggestions:

1.   Abstract:
What is the difference between “the SRv6 behavior that traffic is being 
forwarded with. “ and SRv6 forwarding plane? Should we just use SRv6 forwarding 
plane to replace original wording? Maybe I miss something.
But we need to consider consistency between abstract and introduction 
description.

TG > With "SRv6 behavior" the "SRv6 endpoint behavior" is meant from RFC 8986 
section 4 (https://datatracker.ietf.org/doc/html/rfc8986#section-4). We will 
change the wording in the abstract from "SRv6 behavior" to "SRv6 endpoint 
behavior".

2.Section 3, the definition of srhFlagsIPv6
At the current stage, 8 bit flags defined in SRH are all unused according to 
RFC8754,however looking up IANA registry for Segment Routing Header Flags,
Only OAM flag is allocated for RFC9259, I am wondering whether OAM flag should 
be reported together with other unused flags.
What is the impact on this parameter when some other flags have been allocated 
from Segment Routing Header Flags registry, it seems no harm, but do you think 
we should clarify only OAM flag is allocated in this srhFlagsIPv6 definition.


TG > We clarified this with IANA extensively. As described in 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh#section-5.1,
 we refer to the "Segment Routing Header Flags" IANA registry where the flags 
are defined for the segment routing header. IPFIX doesn't allocate new entities.

3.Section 3, the definition of srhTagsIPv6
I am wondering whether we need to have some out-band  mechanism to define the 
meaning or purpose of using these srhTagIPv6, when we say a group of packet 
sharing the same set of properties, what is the example of these properties? 
Should these srhTagIPv6 global unique? Or local scope specific?

TG > The SRH tags are defined and described in 
https://datatracker.ietf.org/doc/html/rfc8754#section-2. They are currently not 
used but in context of IPFIX could become very useful since we now can mark and 
group packets with the same properties. It is outside of the scope of 
draft-ietf-opsawg-ipfix-srv6-srh to describe the usage of SRH tags.

4.Section 3 the definition of srhSegmentIPv6ListSection
I am not sure I understand the difference between srhSegmentIPv6BasicList and 
srhSegmentIPv6ListSection?
I know you provide an usage example to explain this, but  for the reader who 
are not familiar with IPFIX, it is hard to parse this. Would it be great to add 
some text in the definition of srhSegment IPv6ListSection to clarify this 
difference.
Maybe add a pointer to section 6.1

TG > Correct section 6.1 describes the differences between 
srhSegmentIPv6BasicList and srhSegmentIPv6ListSection. We could add a pointer.

Also I believe srhSegmentIPv6BasicList and srhSegmentIPv6ListSection should not 
be reported at the same time? Two IE should be mutually excluded? No?

TG > We don't prevent this. That would go to far. We describe under operation 
consideration in section 6.1 that this would not be an expected behavior.

   It is not expected that an exporter would support both
   srhSegmentIPv6BasicList and srhSegmentIPv6ListSection at the same
   time.

5.Section 3. The definition of srhSection IPv6
The same comment is applied to srhSection IPv6, I think we should add more 
texts to explain how srhSectionIPv6 organized? Or what information is included 
in srhSectionIPv6

TG > srhSectionIPv6 exports the entire SRH and its TLVs as specified in 
https://datatracker.ietf.org/doc/html/rfc8754#section-2. For the authors the 
description makes sense. Could you propose a wording which would make more 
sense to you?

6.Section 4
It looks these information in section 4 can be used to provide SRv6 visibility 
or troubleshooting, for the answer 2, I am wondering what else does the 
management system do for troubleshooting? Or the network devices have already 
done everything for the management system regarding troubleshooting?

TG > In this section we describe use cases how this metrics can be used. We 
follow the same pattern as we did for MPLS-SR 
(https://datatracker.ietf.org/doc/html/rfc9160#section-2). We believe 

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

[Qin Wu]

Hi, All:
Thanks authors to write this draft and validate it using Hackathon project. I 
take some time to review this draft, my general position is to support moving 
this work toward publication.
Here are a few comments and suggestions:

1.   Abstract:
What is the difference between “the SRv6 behavior that traffic is being 
forwarded with. “ and SRv6 forwarding plane? Should we just use SRv6 forwarding 
plane to replace original wording? Maybe I miss something.
But we need to consider consistency between abstract and introduction 
description.

2.Section 3, the definition of srhFlagsIPv6
At the current stage, 8 bit flags defined in SRH are all unused according to 
RFC8754,however looking up IANA registry for Segment Routing Header Flags,
Only OAM flag is allocated for RFC9259, I am wondering whether OAM flag should 
be reported together with other unused flags.
What is the impact on this parameter when some other flags have been allocated 
from Segment Routing Header Flags registry, it seems no harm, but do you think 
we should clarify only OAM flag is allocated in this srhFlagsIPv6 definition.

3.Section 3, the definition of srhTagsIPv6
I am wondering whether we need to have some out-band  mechanism to define the 
meaning or purpose of using these srhTagIPv6, when we say a group of packet 
sharing the same set of properties, what is the example of these properties? 
Should these srhTagIPv6 global unique? Or local scope specific?

4.Section 3 the definition of srhSegmentIPv6ListSection
I am not sure I understand the difference between srhSegmentIPv6BasicList and 
srhSegmentIPv6ListSection?
I know you provide an usage example to explain this, but  for the reader who 
are not familiar with IPFIX, it is hard to parse this. Would it be great to add 
some text in the definition of srhSegment IPv6ListSection to clarify this 
difference.
Maybe add a pointer to section 6.1

Also I believe srhSegmentIPv6BasicList and srhSegmentIPv6ListSection should not 
be reported at the same time? Two IE should be mutually excluded? No?

5.Section 3. The definition of srhSection IPv6
The same comment is applied to srhSection IPv6, I think we should add more 
texts to explain how srhSectionIPv6 organized? Or what information is included 
in srhSectionIPv6

6.Section 4
It looks these information in section 4 can be used to provide SRv6 visibility 
or troubleshooting, for the answer 2, I am wondering what else does the 
management system do for troubleshooting? Or the network devices have already 
done everything for the management system regarding troubleshooting?

7 Section5.2
When the device export srhTagIPv6 value to the management system, Who will tell 
the device or the management system about the meaning or purpose of srhTagIPv6? 
It is probably beyond scope, but it will be nice to clarify the mechanism to be 
used.

8. Section 5.9.1
For IPFIX IPv6 SRH Segment Type Subregistry,
I am wondering whether this draft-ietf-opsawg-ipfix-srv6-srh should also be 
added into additional information

9.Section 6.2
Is there any IPFIX mechanism to tell two side of communication between the 
management system and network devices whether compressed SID is used or 
non-compressed SID is used?

10.Section 6.3
When the management system and the network device exchange IPFIX information, 
how does two side know whether carrying multiple same IE in one data record is 
supported? Is there any capability exchanged in the IPFIX mechanism?

11. Section 9
s/the allocation/allocation
The security consideration is over simplified, I am wondering whether exposing 
detailed segmentIPv6BasicList has some security risk? Is there any security 
enhancement that need to be considered?

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2022年11月30日 21:54
收件人: opsawg@ietf.org
主题: [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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Giuseppe Fioccola]

Hi All,
I have read the document and I support advancing it. It is relevant as it 
specifies IPFIX extensions to export SRv6 related information.

Regards,

Giuseppe

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To: opsawg@ietf.org
Subject: [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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Haoyu Song]

Dear OPSAWG，

I support the WGLC for this document and believe it’s an important extension to 
IPFIX to address the emerging SRv6 use case. Thanks!

Haoyu

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To: opsawg@ietf.org
Subject: [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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Thomas.Graf]

Dear OPSAWG,

Writing as one of the authors. Talking to various network operators deploying 
SRv6 and network vendors implementing the document in the last few months, 
refining the document steadily and arrived at this stable state, I believe this 
document is ready for working group last call.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To: opsawg@ietf.org
Subject: [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


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[mohamed.boucadair]

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”.
  *   Section 6.3:
 *   Is there any SPRING document that explains the motivation for having 
more than one SRH?
 *   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.


 *   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.


 *   What is an “active SRH”?

I support advancing this spec assuming these comments are addressed. Thanks.

Cheers,
Med

De : OPSAWG  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