Hi Sasha,
Thanks for your interests in investigating this document further.
Regarding the text in section 3, it shows that layer-2 encapsulation may be
required, and if that is the case, several approaches to obtain the layer-2
encapsulation information could be used. As mentioned in the draft, one
approach is to use special MAC address for the underlay connection. Using
static ND cache could be another option, while it is not chosen by the current
implementation. In any case it does not reply on the ND protocol. This is
because when a packet is sent via the underlay connection, the updated
destination address and next-hop is not looked up.
We could rephrase the text to make this clearer. And this can be seen as one
difference between End.X and End.IL.
Sincerely,
Minxue
-------------------------------------
王敏学/ Wang Minxue
中国移动通信研究院 基础网络技术研究所 / China Mobile Research Institute
地址: 北京市西城区宣武门西大街32号创新大厦,100053
电话: 010-15801696688-33202
传真：010-63601087
Email: wangmin...@chinamobile.com
-------------------------------------
From: Alexander Vainshtein
Date: 2025-04-20 16:29
To: bruno.decra...@orange.com; wangmin...@chinamobile.com
CC: draft-dong-spring-srv6-inter-layer-programm...@ietf.org;
spring-cha...@ietf.org; Zafar Ali (zali); Alvaro Retana; SPRING WG
Subject: RE: [EXTERNAL] [spring] Re: WG Adoption Call for
draft-dong-spring-srv6-inter-layer-programming
Hi all,
I’d like to bring your attention the following text fragment from Section 3 of
draft-dong that complements the definition of End.IL procedures in Section 3 of
draft-dong :
When forwarding packets through the underlay network connection towards the
remote endpoint node, depending on the type of connection, layer-2
encapsulation may be required. The information needed for layer-2 encapsulation
may be provisioned via mechanisms such as static Neighbor Discovery (ND) cache
or using specific MAC address.
I assume that the “ND cache” mentioned in this fragment is the Neighbor Cache
as defined in Section 5.1 of RFC 4861 and copied here for your convenience.
Neighbor Cache
- A set of entries about individual neighbors to
which traffic has been sent recently. Entries are
keyed on the neighbor's on-link unicast IP address
and contain such information as its link-layer
address, a flag indicating whether the neighbor is
a router or a host (called IsRouter in this
document), a pointer to any queued packets waiting
for address resolution to complete, etc. A
Neighbor Cache entry also contains information used
by the Neighbor Unreachability Detection algorithm,
including the reachability state, the number of
unanswered probes, and the time the next Neighbor
Unreachability Detection event is scheduled to take
place.
Please note the reference to the neighbor’s on-link unicast IPv6 address in the
quoted text.
If my assumption above is correct, then the local endpoint of the so-called
“network-connection” becomes undistinguishable from any other IPv6-capable
interface, and any difference between End.X and End.IL disappears.
My 2c,
Sasha
From: bruno.decra...@orange.com <bruno.decra...@orange.com>
Sent: Friday, April 18, 2025 8:58 PM
To: wangmin...@chinamobile.com
Cc: draft-dong-spring-srv6-inter-layer-programm...@ietf.org;
spring-cha...@ietf.org; Zafar Ali (zali) <z...@cisco.com>; Alvaro Retana
<aretana.i...@gmail.com>; SPRING WG <spring@ietf.org>
Subject: [EXTERNAL] [spring] Re: WG Adoption Call for
draft-dong-spring-srv6-inter-layer-programming
Hi Minxue,
I have clarification questions.
Looking at the specification of End.IL and End.X, the only difference seems to
be
End.IL:
S15. Send the packet through the underlay network connection
identified by S.
End.X
S15. Submit the packet to the IPv6 module for transmission
to the new destination via a member of J
Is that a correct understanding?
If so, are those different words to express the same forwarding behavior?
Otherwise, could you point out the technical difference in term of data plane
behavior?
Please distinguish the difference which are required to the signaled to the
source (i.e., why the source would have an incorrect behavior if End.X was
signaled instead of End.IL)
Since some of the discussion focuses on the term “layer 3 adjacency” from
End.X, would it work if instead of defining End.IL, your document would extend
End.X as below:
OLD: Any SID instance of this behavior is associated with a set, J, of one or
more L3 adjacencies.
NEW: Any SID instance of this behavior is associated with a set, J, of one or
more L3 adjacencies or network connections.
Thanks,
Best regards,
--Bruno
From: wangmin...@chinamobile.com <wangmin...@chinamobile.com>
Sent: Thursday, April 10, 2025 8: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;
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)
____________________________________________________________________________________________________________Ce
message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent doncpas etre diffuses, exploites
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
le signalera l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This
message and its attachments may contain confidential or privileged information
that may be protected by law;they should not be distributed, used or copied
without authorisation.If you have received this email in error, please notify
the sender and delete this message and its attachments.As emails may be
altered, Orange is not liable for messages that have been modified, changed or
falsified.Thank you.
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
