Just a minor clarification. The registry for SRv6 behaviors is FCFS.
THere is no requirement for IETF specifications or IETF RFCs.
Specifications are very helpful, and often IETF handling of
specifications is useful. But it is not required by the registry process.
Yours,
Joel
On 7/23/2026 12:08 PM, Cancan Huang wrote:
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.*
1. 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.
2. 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 [email protected]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
