Jie, Lots of thanks for your email. First, I would like to apologize for not responding to your emails earlier.
I think that there is a certain mismatch of terminology that have resulted in misunderstanding. In my (and, AFAIK, relatively common) terminology frames received from a Layer 2 logical interface are disposed based solely in their L2 header. (In the case of Ethernet this would include Destination and Source MAC addresses and zero, one or two VLAN tags - but not the "true" Ethertype that follows these tags. Other L2 media uses similar arrangements). I.e., the node that receives Ethernet frames from what it considers a L2 interface cannot differentiate between, say, IPv4, ARP, IPv6 and MPLS. It is the ability to differentiate between different protocols based on the "true" Ethertype and, say, look up the Destination IPv6 address in the appropriate FIB (which is required for SRv6) that makes an interface a L3 one from my POV. Regarding your concern about L3 interfaces involving adjacencies, I also think this is unfounded. It is quite easy to make an IGP adjacency unusable for normal IP forwarding by assigning maximum cost to the corresponding link -but using Adj-SIDs allocated and advertised for such a link in SR-TE policies that are set up by the appropriate controller. Hopefully these notes will be useful Regards, Sasha Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org> Sent: Saturday, July 27, 2024 7:59:30 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; draft-dong-spring-srv6-inter-layer-programm...@ietf.org <draft-dong-spring-srv6-inter-layer-programm...@ietf.org> Cc: spring@ietf.org <spring@ietf.org> Subject: [EXTERNAL] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programming Hi Sasha, Thanks for your question at the mic. Please see some replies inline: ________________________________________ From: Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org> Sent: Saturday, July 27, 2024 5:27 To: draft-dong-spring-srv6-inter-layer-programm...@ietf.org Cc: spring@ietf.org Subject: [spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming Hi all, Just repeating the question about the draft<https://datatracker.ietf.org/doc/html/draft-dong-spring-srv6-inter-layer-programming-08<https://datatracker.ietf.org/doc/html/draft-dong-spring-srv6-inter-layer-programming-08>> I’ve asked at he mike at the SPRING WG session today. * Suppose that there is an underlay link between a pair of IP nodes that is not “visible in he L3 topology”. To me this means that there no P-capable (logical) interfaces associated with the endpoints of this underlay link [Jie] The interface of the underlay link is not L3-capable, while it still can have some packet processing capability. You may consider it as a layer-2 logical interface. * Suppose further that one of these nodes (the upstream one) allocates and advertises an SID with End.XU behavior for this underlay link * The upstream node receives an IPv6 packets with the tops SRv6 SID on it being the End.XU. It strips this SID (this the common behavior of all End-like SIDs) and send the resulting IPv6 packet across the link to the downstream node/\. Now the question: How should the downstream node process the received packet if its local endpoint of the undelay link s not associated with an IP-capable logical interface? [Jie] Similar to what I said above, the receiving interface is not L3-capable, while it can receive and process the packet properly in layer-2, the inner L3 packet header can be processed by the node. If the endpoints of the underlay ink are associated with L3 interfaces in both nodes, the link becomes visible in L3 topology, and a regular End.X SID can be allocated and advertised for it. [Jie] As described in the draft, making it an L3 adjacency between the two endpoints is both challenging and unnecessary. And operator does not want this link to be visible in L3 topology. Thus regular End.X SID does not meet the requirement here. Hope this help to answer your question. Best regards, Jie Hopefully this clarifies my question. Regards, Sasha 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
