Dear Group: Based on the minutes and transcript of the SPRING session at IETF 126, I summarized the questions and suggestions raised by the experts during the meeting and thanks Daniel Bernier and Sasha Vainshtein. I will discuss the suggestions in this email with the aim of soliciting more advice from the experts.
Question 1: Whether using PPPoE over SRv6 is necessary when PPP over SRv6 could be run directly. Because PPPoE has a session ID, which can later be used to perform keep-alive and quality monitoring for user traffic based on that session ID. For intensive data transmission, real-time status is very important, so the AC side needs the session ID. PPP does not have a session ID and is therefore unsuitable for session performance monitoring at the AC. Furthermore, the necessity of PPPoE over SRv6 is reflected in two aspects: a) In many cases, the PPPoE server for intensive data transmission services is located inside a DC, so it is on a different Layer 2 network from the customer’s network; therefore, Layer 3 is needed to interconnect them, which is why SRv6 is used for transport. b) The reason for continuing to use PPPoE is as stated in the first answer—for subscriber session monitoring, the PPPoE-specific session ID is required. Thus, PPP over SRv6 is not suitable; PPPoE over SRv6 is needed. Question 2: Suggested bringing the subscriber steering requirements to the Broadband Forum (BBF). The expert is correct. BBF has WT-474 which standardizes Subscriber Session Steering and dynamic subscriber placement. One co-author of this draft also participates in BBF, and we will promote this content in BBF. However, the new End behaviors needs to be defined in IETF. Question 3:Slide 7. Typo or mistake? PPPoE is an EtherType inside the Ethernet frame rather than an upper-layer header type in SRv6. The expert is right; this was an error. The EtherType only indicates what type of content is carried in the subsequent payload, and is not an upper header. Therefore, I revised Section 7 “Pseudocode describing the behaviors” and changed “upper header” to “etherType” in the S03 line. Question 4: PPPoE has been successfully carried over MPLS pseudowires for two decades without requiring special pseudowire types. I think the expert means that since PPPoE over MPLS did not require a special pseudowire type, SRv6 likewise does not need a new behavior. As mentioned earlier, the main purpose of the defined behavior is to steer the plain data user into a network slice after the PPPoE tunnel is terminated; thus, its primary goal is to add a network slice ID, not specifically to strip the PPPoE header. Question 4 (continued):This is already a very mature technology; there is no need to define a new SID behavior. I agreed that It is a mature technology, and many vendors have implemented PPPoE over SRv6 by combining different functions in series, for example the expert’s suggestion of using End.DX6 + ABF (ACL-Based Forwarding) . However, cross-connect and VPN are likewise mature and widely deployed long ago—so why were End.DX2 and End.DT46 defined? I believe defining End.D.addslice.PPPOE has the same rationale as defining End.DX2, and is also the reason for Segment Routing itself: to facilitate network programming. Building PPPoE over SRv6 requires vendors to statically configure between functional modules; one can only know a router’s complex capabilities by reading its manual. If these scattered functions are packaged into a specific combined function with a name (the behavior name), it can be advertised via BGP, so everyone knows the router’s complex capability—greatly easing automated network programming instead of manual static config. It also helps later interoperability and visual O&M. Question 5:Talk about potential deployment. Please don’t talk about revenue, cost, and profit. Noted; I will pay attention to this in the future. Additionally, I have updated the draft to version 01 draft-huang-spring-pppoe-srv6-01 and now uploading it. Please take the time to review it if you are interest in it, and we look forward to your further comments and suggestions. Cancan Huang China Telecom
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
