Hi Thomas, et al., what do you think of the new SPRING WG draft that introduces two methods of the compressed SRv6 SID list encoding in the SRH <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-00> ?
Regards, Greg On Sat, Feb 12, 2022 at 12:10 AM <thomas.g...@swisscom.com> wrote: > Dear Yao, > > Thanks a lot for the detailed description. Both understood, acknowledged > and being merged to the -01 version. Feedback welcome. > > > https://www.ietf.org/rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-01.txt > > I will publish -01 in the upcoming weeks before IETF 113. > > Best wishes > Thomas > > -----Original Message----- > From: liu.ya...@zte.com.cn <liu.ya...@zte.com.cn> > Sent: Monday, February 7, 2022 10:42 AM > To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com> > Cc: spr...@ietf.org > Subject: Re:[spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > > Hi Thomas, > > Sorry for the late reply. Please see inline [Yao2]. > > [Yao] Segments left is one of the elements to identify an SRH. For > example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) > (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also > useful when exporting SRv6 information. > Would you agree that ipv6SRHSegmentList at node egress would be equal to > Segments left? Or in other words segments left would only differ at ingress > to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. > Would you please describe me what kind of use case you have in mind. > [Yao2] I mean without segment left, it's difficult to distinguish between > packets of the same segment list in some cases. > Below is one scenario I can think of. The corresponding segment list of > path 1--A--2--3--1--A--4 is <SID-1,SID-A,SID-2,SID-3,SID-1,SID-A,SID-4>. > 3 > / \ > / \ > 1 2 > \ / > \ / > A-----4 > The flow passes node A twice. > The first time, the packet is > (SA,DA=SID-A)<SID-1,SID-A,SID-2,SID-3,SID-1,SID-A,SID-4; segment left=5>. > The second time, the packet is > (SA,DA=SID-A)<SID-1,SID-A,SID-2,SID-3,SID-1,SID-A,SID-4; segment left=1>. > If one wants to collect the info of these two traffic separately, the > segment left element is needed. > But to be honest, I'm not sure whether this requirement is strong. > > > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while > other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are > defined. What if the user want to export the SRH TLV info of the packets? > You mean the entire SRH header without disassemble the dimensions into > IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this > makes a lot of sense and I consider this to the -01 version of the > document. > [Yao2] Yes, that's what I mean. > > Best Regards, > Yao > > > > > > ------------------原始邮件------------------ > 发件人：thomas.g...@swisscom.com > 收件人：刘尧00165286; > 抄送人：spr...@ietf.org; > 日 期 ：2022年01月30日 14:17 > 主 题 ：Re: [spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Hi Yao > Thanks a lot for your input. > > [Yao] Segments left is one of the elements to identify an SRH. For > example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) > (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also > useful when exporting SRv6 information. > Would you agree that ipv6SRHSegmentList at node egress would be equal to > Segments left? Or in other words segments left would only differ at ingress > to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. > Would you please describe me what kind of use case you have in mind. > > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while > other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are > defined. What if the user want to export the SRH TLV info of the packets? > You mean the entire SRH header without disassemble the dimensions into > IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this > makes a lot of sense and I consider this to the -01 version of the document. > Looking forward to your clarifications. > Best wishes > Thomas > -----Original Message----- > From: liu.ya...@zte.com.cn <liu.ya...@zte.com.cn> > Sent: Tuesday, January 25, 2022 10:27 AM > To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com> > Cc: spr...@ietf.org > Subject: Re:[spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Hi Thomas, > Please see inline [Yao]. > Best Regards, > Yao > ------------------原始邮件------------------ > 发件人：thomas.g...@swisscom.com > 收件人：刘尧00165286; > 抄送人：spr...@ietf.org; > 日 期 ：2022年01月23日 01:16 > 主 题 ：Re: [spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Hi Yao, > Many thanks for the review and feedback. > > 1) But this draft describes the routing protocol where the last SRv6 > segment has been learned from, instead of the SRv6 segment to be processed > by the current hop. > I am going to rephrase the sentences to refer to the active segment. Which > should make it less ambiguous. > > 2) but in SRv6, segment list and segments left(currently not defined in > the draft) are both needed to provide the similar information. > Could you elaborate the use case for segments left in this context. This > document covers all dimensions being present in the SRv6 segment routing > header described in section of RFC8754 ( > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8754%23section-2&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n6Y0xX3DT1BmusOLbuUXDZHb2CQ%2BiJlY%2FSOPxIcTr7c%3D&reserved=0) > with the exception of "Last Entry". > [Yao] Segments left is one of the elements to identify an SRH. For > example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) > (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also > useful when exporting SRv6 information. > > 3) Element for SRH TLV is not defined in the draft, what's the > consideration about that? > Could you elaborate further please. The document refers to RFC 8754 where > the SRH TLV is being described. > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while > other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are > defined. What if the user want to export the SRH TLV info of the packets? > Best wishes > Thomas > -----Original Message----- > From: liu.ya...@zte.com.cn <liu.ya...@zte.com.cn> > Sent: Thursday, January 20, 2022 10:23 AM > To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com> > Cc: spr...@ietf.org > Subject: Re:[spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Hi Thomas, > I've read the draft and have some questions. > 1) RFC 9160 introduces new protocol types for SR-MPLS top label. > Considering that the MPLS top label is always the label to be processed, > the user can know which protocol the SR-MPLS SID to be processed is learned > from. > But this draft describes the routing protocol where the last SRv6 segment > has been learned from, instead of the SRv6 segment to be processed by the > current hop. > As for my understanding, the current draft is inconsistent with RFC 9160 > in this aspect. > 2) Related to point 1，in SR-MPLS, exporting the top label can provide the > information of the segment to be processed, but in SRv6, segment list and > segments left(currently not defined in the draft) are both needed to > provide the similar information. > 2) Element for SRH TLV is not defined in the draft, what's the > consideration about that? > Best Regards, > Yao > ------------------原始邮件------------------ > 发件人：thomas.g...@swisscom.com > 收件人：spr...@ietf.org; > 日 期 ：2022年01月15日 17:27 > 主 题 ：[spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Dear SPRING working group, > Following up on just released RFC 9160 ( > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9160&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZRYzSkFXCDSSUYprLXjgHAdfQHPLFnTl6sA8xMW2Ur4%3D&reserved=0), > IPFIX code points for MPLS Segment Routing, > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OWgQAA7bC98QKCgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&reserved=0 > has been submitted for the SRV6 data-plane. > The document aims to be on par with MPLS-SR. Describe the routing protocol > or PCEP extension where the last SRv6 segment has been learned from, the > SRv6 segment list and all other properties from the Segment Routing header. > I would appreciate your document review and feedback. > I aim to present at IETF 113 at OPSAWG and SPRING and request adoption at > OPSAWG. > Best wishes > Thomas > -----Original Message----- > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > Sent: Saturday, January 15, 2022 10:12 AM > To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com> > Subject: New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > has been successfully submitted by Thomas Graf and posted to the IETF > repository. > Name: draft-tgraf-opsawg-ipfix-srv6-srh > Revision: 00 > Title: Export of Segment Routing IPv6 Information in IP Flow > Information Export (IPFIX) > Document date: 2022-01-15 > Group: Individual Submission > Pages: 9 > URL: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-00.txt&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=XSp7znVjIkQqPZLpCUx04tD1eaH9RoOHT6xJlX1cMq0%3D&reserved=0 > Status: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=e80kd7Krk7V4yiw6jtjyh7O144HPwwAlJkUMNYcOzXc%3D&reserved=0 > Htmlized: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OWgQAA7bC98QKCgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&reserved=0 > Abstract: > This document introduces new IP Flow Information Export (IPFIX) code > points to identify which traffic is being forwarded with which Segemnt > Routing Header dimensions based on which SRv6 control plane protocol. > The IETF Secretariat > _______________________________________________ > spring mailing list > spr...@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2mFSurxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=0 > _______________________________________________ > spring mailing list > spr...@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2mFSurxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=0 > _______________________________________________ > spring mailing list > spr...@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2mFSurxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=0 > _______________________________________________ > spring mailing list > spr...@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
