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
