Hi Sasha,

Thanks again for your comments.

Yes we have agreed to disagree, as there can be multiple ways to achieve the 
integration of IP and the underlay networks. This document just proposes one 
approach for the scenarios in the draft.

As described both in the draft and in the exchanged mails, in the network 
scenarios we care about, there should be no IP address provisioned on the 
endpoints, there is no IGP nor BGP session between them, and there is a need to 
indicate the specific underlay connection. Thus this connection is not fully 
functioning from the perspective of layer-3.  And it needs to be treated 
differently from normal L3 links in the control plane and management plane.  

We agree that for SRv6 based inter-layer integration, the boundary of L3 may 
get blurred. In our opinion, END.IL is a currently suitable solution for this 
scenario. How this draft can be further improved is something we would like to 
discuss in the WG.

Best regards,

Minxue (on behalf of co-authors)



-------------------------------------
王敏学/ Wang Minxue
中国移动通信研究院 基础网络技术研究所 / China Mobile Research Institute
地址: 北京市西城区宣武门西大街32号创新大厦,100053
电话: 010-15801696688-33202
传真:010-63601087
Email: wangmin...@chinamobile.com
-------------------------------------
 
From: Alexander Vainshtein
Date: 2025-04-15 15:23
To: Alvaro Retana; SPRING WG
CC: draft-dong-spring-srv6-inter-layer-programm...@ietf.org; 
spring-cha...@ietf.org; Zafar Ali (zali); wangmin...@chinamobile.com; Zafar Ali 
(zali)
Subject: RE: [EXTERNAL] [spring] Re: WG Adoption Call for 
draft-dong-spring-srv6-inter-layer-programming
Hi all,
I have checked my archives and I see that I have indeed presented my concerns 
at the SPRING WG session in Vancouver and later clarified them in an email to 
the authors and the WG.
 
This resulted in several email exchanges with the authors, but we have only 
agreed to disagree.
 
I am still convinced that:
The endpoints of the lower layer link discussed in the draft MUST be 
represented by IPv6-capable logical interfaces in order to be able to process 
the remaining SSRv6 SIDs in the SRH (standard or compressed) 
Step S.14 in Section 3 of the draft explicitly supports the situation in which 
the inter-layer SID is not the last SID in the stack
An already defined End behavior (that can represent an Adj-SID for an IGP or a 
BGP peering segment for BGP) is sufficient for all the purposes of the draft. 
Non sunt multiplicanda entia sine necessitate.
 
Regards,
Sasha
 
From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> 
Sent: Monday, April 14, 2025 4:37 PM
To: Zafar Ali (zali) <zali=40cisco....@dmarc.ietf.org>; 
wangmin...@chinamobile.com; Alvaro Retana <aretana.i...@gmail.com>; SPRING WG 
<spring@ietf.org>
Cc: draft-dong-spring-srv6-inter-layer-programm...@ietf.org; 
spring-cha...@ietf.org; Zafar Ali (zali) <z...@cisco.com>
Subject: Re: [EXTERNAL] [spring] Re: WG Adoption Call for 
draft-dong-spring-srv6-inter-layer-programming
 
Dear colleagues,
I concur with Zafar.
 
I have already expressed my position on this draft in various private and 
public discussions (including comments at the mike at the SPRING WG session at 
one if the recent IETF meetings).
 
As Zafar has explained, the endpoints of the optical (or any other) 
"inter-layer" link MUST be IPv6-capable so that they can handle IPv6 packets 
correctly. This strongly suggests to me that a static Adj-SID (associated with 
End.X behavior in SRv6) addresses all the needs I can think about.
 
And it is easy enough to prevent usage of the link in "shortest path" SRv6 
paths. 
 
The bottom line: I respectfully object to WG adoption of this draft because 
frim my POV  it does not meet the first of the two criteria for adoption:
1.      Deals with a real problem
2.      Represents a reasonable starting point towards solution of this problem.
Regards,
Sasha
Regards,
Sasha
 
Get Outlook for Android
 


From: Zafar Ali (zali) <zali=40cisco....@dmarc.ietf.org>
Sent: Thursday, April 10, 2025 4:24:46 PM
To: wangmin...@chinamobile.com <wangmin...@chinamobile.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: [EXTERNAL] [spring] Re: 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)
 


Disclaimer
This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments. 
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

Reply via email to