Re: [OPSAWG] 🔔 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. 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)
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 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 belie
