Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

[[e-mail]]

Re-,

 

Yes, you got it. 

 

Maybe it is simple to consider a new IE that carries in the first 8
bits the routing type and the occurrence in the remaining 8 bits.
Multiple instances can be then sent if needed. Another approach for
encoding both the order and occurrence is to have an IE that prepends
the types with the same type repeated when multiple instances are
present. 

 

Cheers,

Med

 

De : [e-mail] <[e-mail]> 
Envoyé : mardi 20 septembre 2022 14:06
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
[e-mail]; jclarke=[e-mail];
[e-mail]
Cc : [e-mail]
Objet : RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

 

Hi Med,

 

You read my mind. If I read yours correctly you mean that there can be
multiple extension headers which could be exposed each with one IE64
ipv6ExtensionHeaders. What we don't know is how many times each header
type occurs and the order in the packet. What is also missing is the
distinguisher between the routing types. Correct?
 
Best wishes
Thomas

 

From: [e-mail]
<mailto:[e-mail]>  <[e-mail]
<mailto:[e-mail]> > 
Sent: Tuesday, September 20, 2022 11:13 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <[e-mail]
<mailto:[e-mail]> >; [e-mail]
<mailto:[e-mail]> ; jclarke=[e-mail]
<mailto:jclarke=[e-mail]> ; [e-mail]
<mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]>

Subject: ***Signed_Message*** RE: CALL FOR ADOPTION:
draft-tgraf-opsawg-ipfix-srv6-srh

 

Hi Thomas, 

 

This is a useful addition. Thanks.  

 

A more general question is to check whether one can report the
identity of the EHs that form the Header Chain, but this is not
specific to this draft. The current ipv6ExtensionHeaders does not
allow for that. 

  

Cheers,

Med

 

De : [e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> > 
Envoyé : lundi 19 septembre 2022 16:47
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]
<mailto:[e-mail]> >; [e-mail]
<mailto:[e-mail]> ; jclarke=[e-mail]
<mailto:jclarke=[e-mail]> ; [e-mail]
<mailto:[e-mail]> 
Cc : [e-mail]
<mailto:[e-mail]> 
Objet : RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

 

Hi Med,

 

Benoit will feedback on your reply. 

 

In the meanwhile I like to take the opportunity to get your feedback
on an additional operational consideration section I added based on an
off list feedback I received from a software developer implementing
the draft document.

 

https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-sr
v6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw
.githubusercontent.com%2Fgraf3net%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%
2Fmain%2Fdraft-ietf-opsawg-ipfix-srv6-srh-01.txt&data=05%7C01%7CThomas
.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7
420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZs
b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C3000%7C%7C%7C&sdata=xPFmIIS%2Bo7VVshlpesBx5v6OCtC5oJVGAkZQ5ap4xFE%3
D&reserved=0> 

 

5.3.  Multiple Segment Routing Headers

 

   [RFC8200] describes the support of multiple extension headers in
one

   IPv6 packet.  Allowing the use of multiple SRH per SRv6 packet.
The

   export of the same IE multiple times in one data-record and data-

   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.

 

 

Best wishes

Thomas

 

From: [e-mail]
<mailto:[e-mail]>  <[e-mail]
<mailto:[e-mail]> > 
Sent: Monday, September 19, 2022 2:22 PM
To: Benoit Claise <[e-mail]
<mailto:[e-mail]> >; Graf Thomas, INI-NET-TCZ-ZH1
<[e-mail] <mailto:[e-mail]> >;
jclarke=[e-mail]
<mailto:jclarke=[e-mail]> ; [e-mail]
<mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]>

Subject: RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

 

Hi Benoît, 

 

Thank you for the follow-up. 

 

Actually, the more I look into this, the more I’m convinced that we
don’t need a new registry for the flags and that the statement “Values
for this Information Element are listed in the "IPFIX IPv6 SRH Flags"
registry” is restrictive (inaccurate(?)). The flags should be exported
as ** observed ** not as set in the registry. 

 

Think about discarded packets because some flags are set (including
those already for which a meaning is already defined such as the O
flag) while the processing of these flags is not supported by a
router. In such cases, one use of the srhFlagsIPv6 IE would be to
display the erroneous set of flags together with some error counters.
The values of the IE is not “taken from the IANA registry”. 

 

That said, I fully agree that the spec has to indicate “Data Type
Semantics:  flags” for that IE. 

 

The same would apply for the srhSegmentEndpointBehavior IE. 

 

Please let me know if I’m missing something. Thanks. 

 

Cheers,

Med

 

De : Benoit Claise <[e-mail]
<mailto:[e-mail]> > 
Envoyé : samedi 17 septembre 2022 17:39
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]
<mailto:[e-mail]> >; [e-mail]
<mailto:[e-mail]> ; jclarke=[e-mail]
<mailto:jclarke=[e-mail]> ; [e-mail]
<mailto:[e-mail]> 
Cc : [e-mail]
<mailto:[e-mail]> ; me <[e-mail]
<mailto:[e-mail]> >
Objet : Re: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

 

Hi Med,

Thanks for your comments.

I visited IANA in Philly to validate this propose, but we could
re-evaluate & discuss about it.

We need a registry because just telling that we take the value from
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
#segment-routing-header-flags
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.iana.org%2Fassignments%2Fipv6-parameters%2Fipv6-parameters.xhtml%23se
gment-routing-header-flags&data=05%7C01%7CThomas.Graf%40swisscom.com%7
C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7
C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
=JL1l5%2FMF4kuugfBlw5oDeOnvG9II1U4wJET9cBM2mrE%3D&reserved=0>  is not
sufficient as we also need to specify the following IPFIX fields:
- Abstract Data Type. (unsigned8 in this srhFlagsIPv6 case)
- Data Type Semantics (flags in srhFlagsIPv6 case)

Now, if your point is that we don't really to mention the initial
values ...

Initial values in the registry are defined by the table
      below.

 
+--------+-------------------+--------------------------------------+
      | Value  |    Description    |              Reference
|
 
+--------+-------------------+--------------------------------------+
      | 0-1    | Unassigned        |
|
 
+--------+-------------------+--------------------------------------+
      | 2      | O-flag            |
[RFC-ietf-6man-spring-srv6-oam-13]  |
 
+--------+-------------------+--------------------------------------+
      | 3-7    | Unassigned        |
|
 
+--------+-------------------+--------------------------------------+

                   Table 2: "IPFIX IPv6 SRH Flags" registry

... I agree it's not strictly necessary but it helps (me/the IPFIX
experts) to understand, from this document, which type of values are
currently available.

See inline.

On 9/16/2022 9:34 AM, [e-mail]
<mailto:[e-mail]>  wrote:

Hi Thomas, 

 

Thank you for preparing this revised version. 

 

I think almost all my comments are addressed in this version. However,
I still don’t see the need to have new registries that only mirror
existing ones. For example, and unless I missed some subtleties, it
would be sufficient to say that the flag values are taken from
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.iana.org%2Fassignments%2Fipv6-parameters%2Fipv6-parameters.xhtml%23se
gment-routing-header-flags&data=05%7C01%7CThomas.Graf%40swisscom.com%7
C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7
C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
=JL1l5%2FMF4kuugfBlw5oDeOnvG9II1U4wJET9cBM2mrE%3D&reserved=0>
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
#segment-routing-header-flags rather than adding the following in the
I-D: 

 

 
+--------+-------------------+--------------------------------------+

      | Value  |    Description    |              Reference
|

 
+--------+-------------------+--------------------------------------+

      | 0-1    | Unassigned        |
|

 
+--------+-------------------+--------------------------------------+

      | 2      | O-flag            |
[RFC-ietf-6man-spring-srv6-oam-13]  |

 
+--------+-------------------+--------------------------------------+

      | 3-7    | Unassigned        |
|

 
+--------+-------------------+--------------------------------------+

 

                   Table 2: "IPFIX IPv6 SRH Flags" registry

 

which is similar in term of encoding and values as what was set by
RFC9256:

 

   IANA has registered the following in the "Segment Routing Header
   Flags" subregistry in the "Internet Protocol Version 6 (IPv6)
   Parameters" registry:
 
                     +=====+=============+===========+
                     | Bit | Description | Reference |
                     +=====+=============+===========+
                     | 2   | O-flag      | RFC 9259
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
atracker.ietf.org%2Fdoc%2Fhtml%2Frfc9259&data=05%7C01%7CThomas.Graf%40
swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9bee
c35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJW
IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
7C%7C%7C&sdata=iMoVMkCP94TxZteB3EmJePTmxI%2BewNRsARG%2FzsUa5M8%3D&rese
rved=0>   |
                     +-----+-------------+-----------+

 

 

BTW, I guess you initially meant: 

 

NEW:

 

                   Table 2: "IPFIX IPv6 SRH Flags" registry

 

 

   Note to IANA:  Add a note to the "Segment Routing Header Flags"
registry

      so that new values are echoed in the new "IPFIX IPv6 SRH Flags”

You are right (since
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
#segment-routing-header-flags
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.iana.org%2Fassignments%2Fipv6-parameters%2Fipv6-parameters.xhtml%23se
gment-routing-header-flags&data=05%7C01%7CThomas.Graf%40swisscom.com%7
C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7
C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
=JL1l5%2FMF4kuugfBlw5oDeOnvG9II1U4wJET9cBM2mrE%3D&reserved=0>  is
"IETF review" while https://www.iana.org/assignments/ipfix/ipfix.xhtml
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.iana.org%2Fassignments%2Fipfix%2Fipfix.xhtml&data=05%7C01%7CThomas.Gr
af%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420
d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
3000%7C%7C%7C&sdata=7MkKV2NRl0OFbZYgE5%2BtseErVg%2BODHbLcTwydsxVKOQ%3D
&reserved=0>  is "Expert Review")

 

 

instead of CURRENT: 

 

                   Table 2: "IPFIX IPv6 SRH Flags" registry

 

 

   Note to IANA:  Add a note to the registry so that new values are

      echoed in the new "IPFIX SRv6 EndPoint Behavior

 

The same comment applies for the values that can be directly taken
from
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml
#srv6-endpoint-behaviors
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.iana.org%2Fassignments%2Fsegment-routing%2Fsegment-routing.xhtml%23sr
v6-endpoint-behaviors&data=05%7C01%7CThomas.Graf%40swisscom.com%7C3773
3f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C
0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ggzq
TrPpyTZM7MpWHbVCB0fbpWLY%2FExC%2Fz6ARVIUOu0%3D&reserved=0> .


Yes
OLD:

               Table 4: "IPFIX SRV6 Endpoint Behavior" registry


   Note to IANA:  Add a note to the registry so that new values are
      echoed in the new "IPFIX SRv6 EndPoint Behavior

NEW:

               Table 4: "IPFIX SRV6 Endpoint Behavior" registry


   Note to IANA:  Add a note to the "IPFIX SRV6 Endpoint Behavior"
registry so that new values are
      echoed in the new "IPFIX SRv6 EndPoint Behavior

Regards, Benoit

 

Cheers,

Med

 

De : [e-mail] <mailto:[e-mail]>
<mailto:[e-mail]> <[e-mail]> 
Envoyé : jeudi 15 septembre 2022 20:08
À : BOUCADAIR Mohamed INNOV/NET  <mailto:[e-mail]>
<[e-mail]>; jclarke=[e-mail]
<mailto:jclarke=[e-mail]> ; [e-mail]
<mailto:[e-mail]> 
Cc : [e-mail] <mailto:[e-mail]> ;
[e-mail] <mailto:[e-mail]> 
Objet : RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

 

Dear Med,

 

Many thanks for the comprehensive review. Much appreciated. We merged
all your input to the upcoming -01 release.
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-sr
v6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw
.githubusercontent.com%2Fgraf3net%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%
2Fmain%2Fdraft-ietf-opsawg-ipfix-srv6-srh-01.txt&data=05%7C01%7CThomas
.Graf%40swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7
420d9beec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZs
b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C3000%7C%7C%7C&sdata=xPFmIIS%2Bo7VVshlpesBx5v6OCtC5oJVGAkZQ5ap4xFE%3
D&reserved=0> 

 

The diff to the current -00 version can be found here:
https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draf
t-ietf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubusercontent
.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg
-ipfix-srv6-srh-01.txt

 

For some we need further clarifications if we addressed them
correctly. I would appreciate if you could clarify the following three
points:

 

Med> Section 2, remark: "Why do we need three IE,
srhSegmentIPv6ListSection, srhSegmentIPv6BasicList and srhSectionIPv6,
to expose SRH Segment List

Thomas> Section 5.1 should provide the answer. If that should not be
sufficient, please suggest how this could be better expressed.

 

Med> Section 2: remark: "as series of n octets" is not clearly
comprehensible.

Thomas> Extended to "as series of n octets in IPFIX". Does that makes
it clearer?

 

Med> Section 4.11, remark: "Do you really need to define a new
registry here?"

Thomas> The registry could potentially be used (and updated) by non
IPFIX people.

 

Best wishes

Thomas

 

From: OPSAWG <[e-mail] <mailto:[e-mail]>
> On Behalf Of [e-mail]
<mailto:[e-mail]> 
Sent: Tuesday, September 6, 2022 10:19 AM
To: Joe Clarke (jclarke) <jclarke=[e-mail]
<mailto:jclarke=[e-mail]> >; [e-mail]
<mailto:[e-mail]> 
Subject: Re: [OPSAWG] CALL FOR ADOPTION:
draft-tgraf-opsawg-ipfix-srv6-srh

 

Hi all, 

 

I support. 

 

FWIW, the authors may found some quick comments at:

 

1.	pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgra
f-opsawg-ipfix-srv6-srh-05-rev%20Med.pdf
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-tgraf
-opsawg-ipfix-srv6-srh-05-rev%2520Med.pdf&data=05%7C01%7CThomas.Graf%4
0swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9be
ec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
%7C%7C%7C&sdata=v8H6N3reiWT7ewGbmz13bvMFaBOpRUJVA1Wbz645NAY%3D&reserve
d=0> 
2.	doc:
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-tgraf
-opsawg-ipfix-srv6-srh-05-rev%2520Med.doc&data=05%7C01%7CThomas.Graf%4
0swisscom.com%7C37733f5fdae34ccb6f4508da9ae85748%7C364e5b87c1c7420d9be
ec35d19b557a1%7C0%7C0%7C637992621065808523%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
%7C%7C%7C&sdata=iFprB%2Fa0q4eEKdVwmX6ZYOd3%2FbkHkolYelq%2FUap%2BgLY%3D
&reserved=0>
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgra
f-opsawg-ipfix-srv6-srh-05-rev%20Med.doc

 

Cheers,

Med

 

De : OPSAWG <[e-mail] <mailto:[e-mail]>
> De la part de Joe Clarke (jclarke)
Envoyé : jeudi 18 août 2022 22:14
À : [e-mail] <mailto:[e-mail]> 
Objet : [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

 

Hello, WG.  We’d like to begin a two week call for adoption of this
work.  Even as an individual draft it has already received some
reviews and has iterated quite a bit.  Based on IETF 114 there does
seem to be interest in adopting this in opsawg, but we need a formal
adoption poll.

 

Please review and provide your adoption thoughts no later than
September 1, 2022.

 

Thanks.

 

Joe