Dear Yao, Yao> So should the name be "psidMpls" for SR-MPLS PSID?
My bad. I missed the it should be lower case at the beginning. Yes, your proposal the way to do it. Best wishes Thomas From: [email protected] <[email protected]> Sent: Thursday, September 11, 2025 11:38 AM To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: Re: [OPSAWG]CALL FOR ADOPTION: Export of SRv6 Path Segment Identifier Information in IPFIX,draft-liu-opsawg-ipfix-path-segment-03 Be aware: This is an external email. Hi Thomas, Thanks a lot for pointing out the element naming rules. From my reading, one of the rules also said that names of IEs have to start with lowercase letters. So should the name be "psidMpls" for SR-MPLS PSID? Regards, Yao Original From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> To: 刘尧00165286; Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>>; Date: 2025年09月11日 15:43 Subject: RE: [OPSAWG]CALL FOR ADOPTION: Export of SRv6 Path Segment Identifier Information in IPFIX,draft-liu-opsawg-ipfix-path-segment-03 Dear Yao, Thanks a lot for addressing my comments and including MPLS-SR in the scope of the document. All my comments are addressed thank you very much! One minor remark. Please change the IE naming from PsidMPLS to PsidMpls to be in accordance with https://datatracker.ietf.org/doc/html/rfc7013#section-4.1 o use capital letters for the first letter of each component except for the first one (aka "camel case"). All other letters are lowercase, even for acronyms. Exceptions are made for acronyms containing a mixture of lowercase and capital letters, such as 'IPv4' and 'IPv6'. Examples are "sourceMacAddress" and "destinationIPv4Address". Best wishes Thomas From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Thursday, September 11, 2025 4:15 AM To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [OPSAWG]CALL FOR ADOPTION: Export of SRv6 Path Segment Identifier Information in IPFIX,draft-liu-opsawg-ipfix-path-segment-03 Be aware: This is an external email. Hi Thomas, Thanks very much for your very detailed review and helpful comments！ Attachment is the updated version based on your comments, especially for the MPLS PSID case, I separated SR-MPLS and SRv6 in different sections hoping to avoid too much overlap. About the operational considerations， I thought that there's already a section for SRv6 PSID in v-03, and a subsection of operational considerations for IPFIX SR-MPLS PSID is added in the new version. Please let me know whether it addresses your comments. Thanks, Yao Original From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>>; Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Date: 2025年09月06日 13:32 Subject: RE: [OPSAWG]CALL FOR ADOPTION: Export of SRv6 Path Segment Identifier Information in IPFIX,draft-liu-opsawg-ipfix-path-segment-03 Dear opsawg, draft-liu-opsawg-ipfix-path-segment authors, I support the document adoption. The document covers a very important aspect, segment routing flow visibility in network observability. It is important that OPSAWG takes on this work. Speaking as a network engineer at a network operator. When performing lab validation of RFC 9487 across different SRv6 implementations, exactly as described in this document, challenges in flow identification due to reduced SRH or compress SID occurred. SR policy identification was under certain circumstances difficult. This makes closed loop operated networks where a segment routing controller steers traffic a challenge. I am more than happy to see that not only the IETF defined with RFC 9545 and draft-ietf-spring-srv6-path-segment defined a path sid identity but with this document enables IPFIX flow visibility. I suggest to expand the scope of the document also to MPLS-SR as described in my document review docx: https://github.com/network-analytics/ietf-network-analytics-document-status/blob/main/document-review/draft-liu-opsawg-ipfix-path-segment-03.docx pdf: https://github.com/network-analytics/ietf-network-analytics-document-status/blob/main/document-review/draft-liu-opsawg-ipfix-path-segment-03.pdf Best wishes Thomas From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Thursday, September 4, 2025 8:00 AM To: [email protected]<mailto:[email protected]> Subject: [OPSAWG]CALL FOR ADOPTION: Export of SRv6 Path Segment Identifier Information in IPFIX,draft-liu-opsawg-ipfix-path-segment-03 Be aware: This is an external email. Dear all, The IPR poll has concluded (no known IPR has been disclosed), and we would like to start a two weeks adoption poll for draft-liu-opsawg-ipfix-path-segment-03<https://datatracker.ietf.org/doc/draft-liu-opsawg-ipfix-path-segment/>. Please respond on-list with support and especially comments. From the IETF 123 meeting minutes<https://datatracker.ietf.org/doc/minutes-123-opsawg-202507241500/>, we can observe the following poll results: Poll: who thinks this is interesting work to adopt? yes: 10, no: 0, no opinion: 11 Getting the authors support is kind of obvious (at least we hope), so non authors feedback is really welcome. The adoption call will run till Sept 18th. Regards, Joe and Benoit
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
