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
