[ippm] Re： RE: Ask WG for review draft-liu-ippm-srv6-bandwidth-measurement

[Yisong Liu <[e-mail]>]

Hi Thomas，




Thank you very much for your feedback. Please see my response inline with [LYS].  




Due to the Chinese Spring Festival holiday, my response may be slower. I apologize for any delay and thank you for your understanding.








Best Regards

Yisong





 



发件人: Thomas.Graf

时间: 2025/01/27(星期一)00:57

收件人: liuyisong;ippm;

抄送人: draft-liu-ippm-srv6-bandwidth-measurement;

主题: RE: [ippm] Ask WG for review draft-liu-ippm-srv6-bandwidth-measurement       

 

Dear Yisong, 

  

As a contributor. I have reviewed the document and I think it raises from a network operators point of view a very valid point. Even though  with the source routing paradigm the forwarding path throughout the network can be chosen at the source, due to multipathing and ECMP hashing, not all the links are always used equally and therefore the network might be over provisioned and congestion can  occur. 

  

I find the idea interesting to determine based on the packet flow which interfaces the packet traversed and, if I understood correctly, export  the interface speed from each traversed ingress and egress interface of each transit node. 

 [LYS] Yes. I am precisely aiming to obtain the minimum remaining bandwidth on the SRv6 path, which necessitates measuring the actual packet flow of each interface along the way. 

With interface speed I mean 

  

https://datatracker.ietf.org/doc/html/rfc8343#section-5 

  

         leaf speed { 

           type yang:gauge64; 

           units "bits/second"; 

           config false; 

           description 

               "An estimate of the interface's current bandwidth in bits 

                per second.  For interfaces that do not vary in 

                bandwidth or for those where no accurate estimation can 

                be made, this node should contain the nominal bandwidth. 

                For interfaces that have no concept of bandwidth, this 

                node is not present."; 

           reference 

             "RFC  2863: The Interfaces Group MIB - 

                        ifSpeed, ifHighSpeed"; 

         } 

  

I have a few suggestions. At the end of the introduction  https://datatracker.ietf.org/doc/html/draft-liu-ippm-srv6-bandwidth-measurement-00#section-1 you are proposing a solution where the interface bandwidth information is being carried within the packet in IPv6 hop by hop options header as one of the solutions. 

  

Please also consider IOAM direct export, RFC 9326 which exports the metrics on each node along the forwarding path to a data collection. Also  applicable in IPv6 hop by hop and destination options header. What is missing in IPFIX https://www.iana.org/assignments/ipfix/ipfix.xhtml are interface speed entities. 

 [LYS] Thank you very much for your suggestion. We will analyze whether this method of IOAM is feasible. 

In  https://datatracker.ietf.org/doc/html/draft-liu-ippm-srv6-bandwidth-measurement-00#section-4.1 you are describing a new Hop-by-Hop Options Header carrying the information of the minimum available bandwidth. 

  

With https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.2, IOAM Trace Option, where the information is carried in the packet, already has the capability to export ingress and egress  interface id. However lacks the information of interface speed but already supports other interesting properties such as transit delay, queue depth or buffer occupancy which might be interesting as well. 

 [LYS] Thank you very much for your suggestion. We will analyze whether this method of IOAM is feasible. We hope that the measurement results can be directly returned to the headend of the SRv6 path. 

In  https://datatracker.ietf.org/doc/html/draft-liu-ippm-srv6-bandwidth-measurement-00#section-3.3 you are describing with gRPC and Netconf a YANG based approach to export the data. I suggest to adjust to push based, standardized, approach with YANG-Push RFC  8639/8641. In either case, IPFIX or YANG, new entities/module needs to be defined. I suggest to address this in the same document. 

 [LYS] Thank you very much for your suggestion.  Regarding the method of reporting to the controller, we will consider defining new entities in IPFIX or YANG. 

And last but not least. I am a huge fan of running code. I saw that Justin will participate IETF 122 hackathon  https://mailarchive.ietf.org/arch/msg/ippm/6kKd42wbIW0P8IpL7nXWWkjyI7o/ an work on a IOAM DEX IPFIX implementation to measure on-path delay. Adding the interface speed information in IPFIX would address your use case. Could be potentially interesting. 

 [LYS] Thank you for the information you provided. We will focus on this hackathon project and can have a more in-depth discussion on site in the meeting. 

Best wishes 

Thomas 

  

 

 

From: Yisong Liu <[e-mail]> 
 Sent: Friday, January 10, 2025 8:17 AM
 To: ippm <[e-mail]>
 Cc: draft-liu-ippm-srv6-bandwidth-measurement <[e-mail]>
 Subject: [ippm] Ask WG for review draft-liu-ippm-srv6-bandwidth-measurement   

    

 	 	 

 

 Be aware: This is an external email.      

  

 

 

 

Dear WG members,  

 

   

 

 This draft outlines a comprehensive framework that leverages SRv6 capabilities to facilitate efficient and accurate bandwidth measurement. The proposed approach is designed  to enhance network performance monitoring by providing timely and precise bandwidth data, thereby improving the visibility and management of bandwidth resources in SRv6 environments. This contribution is expected to aid in better network optimization and performance  analysis. 

 Please find the draft for review at the following link:  https://datatracker.ietf.org/doc/draft-liu-ippm-srv6-bandwidth-measurement/. 

 We hope you can review this draft and share your feedback. Welcome any questions and comments. Your feedback is invaluable to us. 

 Thank you for your attention and support.  

 

Best Regards  

 

Yisong on behalf of co-authors