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.Graf@swisscom.com
收件人：刘尧00165286;
抄送人：spring@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.yao71@zte.com.cn <liu.yao71@zte.com.cn>
Sent: Tuesday, January 25, 2022 10:27 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <Thomas.Graf@swisscom.com>
Cc: spring@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.Graf@swisscom.com
收件人：刘尧00165286;
抄送人：spring@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&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=pTL80QujKtnQbO4768IYqYtLOQ9ntmd3MGKwNmdmL68%3D&amp;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.yao71@zte.com.cn <liu.yao71@zte.com.cn>
Sent: Thursday, January 20, 2022 10:23 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <Thomas.Graf@swisscom.com>
Cc: spring@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.Graf@swisscom.com
收件人：spring@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&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3ddjRtYSBRRhYWL%2BvNSQgfXMyVgo4Cf2MePjS9vACuA%3D&amp;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&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4zkY3wyX8iuYLYOdIGqpXMimh6ndTv3rT5au5jbjjnc%3D&amp;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-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Saturday, January 15, 2022 10:12 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <Thomas.Graf@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&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=rH4778Kz%2BBppjs7H8r4pReWqB1wu6amfhgAxCwXFBTA%3D&amp;reserved=0
Status:         https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2F&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=CtVBGFg0phEAf9omIt7w%2BVzS5YtFu9mKIua9Gyc6W2c%3D&amp;reserved=0
Htmlized:       https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4zkY3wyX8iuYLYOdIGqpXMimh6ndTv3rT5au5jbjjnc%3D&amp;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
spring@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=H5DssKNneFtZ21DLI6%2FvX8muGs86a09FS2Aps0HYLpI%3D&amp;reserved=0
_______________________________________________
spring mailing list
spring@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=H5DssKNneFtZ21DLI6%2FvX8muGs86a09FS2Aps0HYLpI%3D&amp;reserved=0
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring