Hi Zafar, The ingress and egress nodes of the underlay connection are L3 capable nodes, while they are not adjacent in L3 (there are other L3 nodes in the middle). The underlay connection between the ingress and egress can be used to bypass the transit L3 nodes to provide the characteristics required by some service traffic. Before the packet is sent on the underlay connection, the required layer-2 encapsulation is added. This is described in section 3, and could be elaborated in future revisions. Regarding the BSID, you also agree that it would be different from the existing SRv6 binding SID behaviors (no encapsulation), then a new behavior would be needed, its basic behavior is to abstract/hide the implementation of an underlay connection and represent it using an SRv6 SID. Whether the new behavior can fit in the SR Policy structure or not can be something to be further discussed in the WG. Best regards, Minxue
------------------------------------- 王敏学/ Wang Minxue 中国移动通信研究院 基础网络技术研究所 / China Mobile Research Institute 地址: 北京市西城区宣武门西大街32号创新大厦,100053 电话: 010-15801696688-33202 传真：010-63601087 Email: wangmin...@chinamobile.com ------------------------------------- From: Zafar Ali (zali) Date: 2025-04-10 21:23 To: wangmin...@chinamobile.com; Alvaro Retana; SPRING WG CC: draft-dong-spring-srv6-inter-layer-programm...@ietf.org; spring-cha...@ietf.org; Zafar Ali (zali) Subject: Re: Re: [spring] WG Adoption Call for draft-dong-spring-srv6-inter-layer-programming Hi Minxue Thanks for your follow-up email. Re: “The egress (and Ingress) of the underlay connection should also be capable of L3 processing. It is just the connection between them is not L3.” Can you please elaborate on if the ingress & egress are capable of processing L3, why the link does not have L3 or L2 termination? How do you “directly” take L3 packet (Srv6 encap) over an optical interface (e.g., lambda)? Re: “Regarding your suggestion of using BSID, the binding SID (H.Encaps or End.B6.Encaps in SRv6) was used to instruct a node to encapsulate a new IPv6 header and SRH to the packet” Of course, in the optical interlayer case, the BSID cannot encapsulate a new IPv6 header and SRH to the packet. However, it can hide the optical interface or possible interfaces (optionally with the lambda value) behind the BSID construct or packet termination. In your case, you can have an SR policy with single candidate path that identifies the optical interface identified by “S” in line S15 of your pseudocode. Please have a look at an earlier work on this. https://datatracker.ietf.org/doc/html/draft-anand-spring-poi-sr-08 Re: Your question on IP side debugging is not quite clear to me Think about how you would debug END.IL where the packet forwarding happens on the wrong optical interface. Thanks Regards … Zafar From: wangmin...@chinamobile.com <wangmin...@chinamobile.com> Date: Thursday, April 10, 2025 at 2:16 AM To: Zafar Ali (zali) <z...@cisco.com>, Alvaro Retana <aretana.i...@gmail.com>, SPRING WG <spring@ietf.org> Cc: draft-dong-spring-srv6-inter-layer-programm...@ietf.org <draft-dong-spring-srv6-inter-layer-programm...@ietf.org>, spring-cha...@ietf.org <spring-cha...@ietf.org>, Zafar Ali (zali) <z...@cisco.com> Subject: Re: Re: [spring] WG Adoption Call for draft-dong-spring-srv6-inter-layer-programming Hi Zafar, Thanks for your interests and comments on this draft. Regarding your question on whether existing SRv6 behaviors can be used, section 2 of this draft has shown the challenges in establishing L3 adjacency between the two endpoints of the underlay connection. If it is not an L3 adjacency, then SRv6 End.X behavior is not applicable, something new is needed for indicating the forwarding instruction to an non-L3 underlay connection. Regarding your question on the implementation, section 3 of this draft provides specifications on how the layer-2 encapsulation information can be obtained. With that, S15 can be implemented. S14 is executed on the sending side of the underlay connection, which is capable of processing IPv6 header and SRH. The egress of the underlay connection should also be capable of L3 processing. It is just the connection between them is not L3. Actually there are already implementations which proved the feasibility of this function. Regarding your suggestion of using BSID, the binding SID (H.Encaps or End.B6.Encaps in SRv6) was used to instruct a node to encapsulate a new IPv6 header and SRH to the packet, which is quite different from the expected behavior in this inter-layer case, as no new IPv6 header or SRH should be added. Your question on IP side debugging is not quite clear to me, you may want to elaborate on it. To me the OAM of the inter-layer paths can be something discussed in a separate document. As a network operator who owns multi-layered networks, this function is needed for efficient inter-layer path integration, and your contribution is welcome. Best regards, Minxue ------------------------------------- 王敏学/ Wang Minxue 中国移动通信研究院 基础网络技术研究所 / China Mobile Research Institute 地址: 北京市西城区宣武门西大街32号创新大厦,100053 电话: 010-15801696688-33202 传真：010-63601087 Email: wangmin...@chinamobile.com ------------------------------------- From: Zafar Ali (zali) Date: 2025-04-09 07:02 To: Alvaro Retana; SPRING WG CC: draft-dong-spring-srv6-inter-layer-programm...@ietf.org; spring-cha...@ietf.org; Zafar Ali (zali) Subject: Re: [spring] WG Adoption Call for draft-dong-spring-srv6-inter-layer-programming Dear author and the WG, There was a lot of discussion on this draft, especially on the need for defining "End.IL", which is the basis of the draft. As far as I know the discussion was not closed and authors have not established the need for defining "End.IL". To keep myself honest, I will also respond to one of the original emails in that thread. I am happy to be corrected if a closure was obtained. Comments from that discussion++; Why a locally instantiated static adjacency SID cannot be used? The reason given was this is a non-IP link but then the question is how I will implement the following code in the (IPv6) packet path S14. Update IPv6 DA with Segment List[Segments Left] S15. Send the packet through the underlay network connection identified by S. S16. } How would I implement S15. To implement S15, I need some local construct to forward the digitally encoded packet on the optical link S. That local construct can very well be a locally instantiated static adjacency SID. It is also not clear how the receiving side processes the “optical signal” to continue processing of the IPv6 packet (i.e., how to implement the receive side of S14). Again, you need a packet termination endpoint for it to work. · There was discussion on the packet termination part does not have IP address associated with it. o Use of unnumbered interface was suggested. If the true need to “hide” optical interfaces behind “S” – use of BSID provides much better construct for "abstraction" of optical network/ interfaces to packet network was done here, as suggested in the following draft. https://datatracker.ietf.org/doc/html/draft-anand-spring-poi-sr-08#section-5 The way the draft tries to hide optical interface looks like a Layer violation. · How do I debug IP side if the END.IL is mis-forwarding – assume I can implement it. As the authors have not established the need for END.IL and hence the draft, I respectfully object to the adoption call. · For the reason mentioned above, I do not know how to implement End.IL as it is defined or if it is at all needed (see comment above)· I am happy to participate in the closure of any gap but in its current state the draft is not ready for adoption. Thanks Regards … Zafar From: Alvaro Retana <aretana.i...@gmail.com> Date: Wednesday, April 2, 2025 at 3:06 PM To: SPRING WG <spring@ietf.org> Cc: draft-dong-spring-srv6-inter-layer-programm...@ietf.org <draft-dong-spring-srv6-inter-layer-programm...@ietf.org>, spring-cha...@ietf.org <spring-cha...@ietf.org> Subject: [spring] WG Adoption Call for draft-dong-spring-srv6-inter-layer-programming Dear WG: This message starts a two-week adoption call for draft-dong-spring-srv6-inter-layer-programming, ending on April/16. From the Abstract: Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. https://datatracker.ietf.org/doc/draft-dong-spring-srv6-inter-layer-programming/ Please review the draft and consider whether you support its adoption by the WG. Please share any thoughts with the list to indicate support or opposition -- this is not a vote. If you are willing to provide a more in-depth review, please state it explicitly to give the chairs an indication of the energy level in the working group willing to work on the document. WG adoption is the start of the process. The fundamental question is whether you agree the proposal is worth the WG's time to work on and whether this draft represents a good starting point. The chairs are particularly interested in hearing the opinions of people who are not authors of the document. Thanks! Alvaro (for the Chairs)
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
