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

[[e-mail]]

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&url2=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 <[e-mail]>
Sent: Saturday, December 3, 2022 3:07 PM
To: Joe Clarke (jclarke) <jclarke=[e-mail]>; [e-mail]
Cc: Graf Thomas, INI-NET-TCZ-ZH1 <[e-mail]>
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 this helps network operators to get quickly started. Of course there would be many other possibilities, combinations which makes sense, though we believe that is not in the scope of the document.

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.

TG > Very valid point. This has been discussed previously in the working group and with IANA. Ideally the IPFIX registry information at IANA can be exposed through an API and semantics can be imported to the IPFIX data-collection. Linking IPFIX entities to other registry however brings the challenge for IANA to resolve such dependencies.

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

TG > Yes there will in the additional information field where [RFC-to-be] is written.

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?

TG > Very valid point. In section 6.2, https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh#section-6.2, we describe how compressed SID can be de-composed. For this the SRv6 endpoint behavior and the locator length is needed. This information can be obtained through YANG push, BMP (BGP link-state redistribution) or through a IPFIX options template as described in https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh#appendix-A.2. We understood from network vendors and operators that the implementation in IPFIX options template is the preferred way. Having one protocol with all the informations.

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?

TG > This is implied by RFC 7011. A data record supports the same IE multiple times and in section 8 of RFC 7011 it is described how the order must be preserved. https://datatracker.ietf.org/doc/html/rfc7011#section-8. As part of the next IETF hackathon we are currently developing this in the pmacct open-source project which we referenced in this document.

11. Section 9
s/the allocation/allocation

TG > taken thanks!

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?

TG > I am not aware that the decomposition of the SRH SID list into segmentIPv6BasicList would impose any security risk.

-Qin
发件人: OPSAWG [mailto:[e-mail]] 代表 Joe Clarke (jclarke)
发送时间: 2022年11月30日 21:54
收件人: [e-mail]<mailto:[e-mail]>
主题: [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/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-srv6-srh%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7Ce239cd9ee26c43b0919c08dad537b302%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056732444903117%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eYhzgvTpWpPkfazPAG042ICa2%2Boruo5g9V939qsIk4s%3D&reserved=0>

Please review the current -04 draft, post your comments and/or your thoughts on the current text.

Thanks.

Joe