Hi Sasha, Allocating IP addresses is one aspect to be considered here. As I mentioned in the chat window, these underlay paths can be created for specific services (not for all services), thus it is not expected that they appear in the L3 topology and used for normal IP path computation. So it is necessary to distinguish them from the normal IP links.
Best regards, Jie From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Sent: Tuesday, November 8, 2022 1:20 PM To: Dongjie (Jimmy) <jie.d...@huawei.com> Cc: draft-dong-spring-srv6-inter-layer-programm...@ietf.org; spring@ietf.org; Michael Gorokhovsky <michael.gorokhov...@rbbn.com>; Nitsan Dolev <nitsan.do...@rbbn.com>; Rotem Cohen <rotem.co...@rbbn.com>; Ketan Talaulikar <ketant.i...@gmail.com> Subject: RE: [spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming Jie, and all, IMHO there is no need to allocate dedicated IP addresses to the endpoints of the optical path. You could define them as unnumbered IPv4-capable interfaces borrowing some loopback address of he containing node (which in any case exists) or, in an IPv6-only scenario, allocate just link-local IPv6 addresses to these endpoints. You could then use some existing mechanisms for each endpoint to learn the MAC address of the other. Once this happens, End.X would work without any changes IMHO. Regards, Sasha From: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>> Sent: Tuesday, November 8, 2022 10:46 AM To: Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>>; Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: draft-dong-spring-srv6-inter-layer-programm...@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programm...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; Michael Gorokhovsky <michael.gorokhov...@rbbn.com<mailto:michael.gorokhov...@rbbn.com>>; Nitsan Dolev <nitsan.do...@rbbn.com<mailto:nitsan.do...@rbbn.com>>; Rotem Cohen <rotem.co...@rbbn.com<mailto:rotem.co...@rbbn.com>> Subject: [EXTERNAL] RE: [spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming Hi Ketan, In the use cases presented during the meeting, no IP address needs to be provisioned on the endpoints of the underlay path, thus to my understanding they are not IP enabled optical paths. Best regards, Jie From: Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> Sent: Tuesday, November 8, 2022 10:33 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: draft-dong-spring-srv6-inter-layer-programm...@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programm...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; Michael Gorokhovsky <michael.gorokhov...@rbbn.com<mailto:michael.gorokhov...@rbbn.com>>; Nitsan Dolev <nitsan.do...@rbbn.com<mailto:nitsan.do...@rbbn.com>>; Rotem Cohen <rotem.co...@rbbn.com<mailto:rotem.co...@rbbn.com>> Subject: Re: [spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming Hi Sasha, Your point is very valid and I assumed that the optical path is IP enabled but there is no routing protocol running over it. There may be a mix up between the terms L3 adjacency and IGP adjacency. RFC8986 Section 4.2 End.X works for L3 adjacency (with or without routing protocol running over the link) as well as L2 bundle members of an L3 LAG interface. In all cases, the neighbor resolution and handling for IP packets is expected. Thanks, Ketan On Tue, Nov 8, 2022 at 3:57 PM Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> wrote: Hi, I would like to repeat the question I have asked at the mike during the SPRING WG session today about draft-dong-spring-srv6-inter-layer-programming<https://clicktime.symantec.com/15t5Zs5Wh91bPMQ9TR9nW?h=dDfw036YxeQFRNa8ajR8qlqeAI8RvZ3iLZhO8gcfBPI=&u=https://datatracker.ietf.org/doc/html/draft-dong-spring-srv6-inter-layer-programming-04>: How would the node that has allocated an End.XU SID for a specific underlay link (i.e., non-IP) identify the Layer 2 encapsulation that has to be pushed on the packet with the End.XU SID exposed? The reference to End.X behavior in Section 4.2 of RFC 8986<https://clicktime.symantec.com/15t5ehGo9khBoJE4zyYw8?h=mMx_9LBKQMNnIC9R12iF9YbkpOtphR8ALGiAT_goRgc=&u=https://datatracker.ietf.org/doc/html/rfc8986%23section-4.2> looks incorrect to me since End.X explicitly speaks about a L3 X-connect and usual Layer 2 helpers ARP and/or ND) would be applicable. But this is not the case for a path for a non-IP path IMHO. I may have missed the details of the response by the presenter, but my gut feeling is that my question has not been answered. Regards, and thanks n advance for the feedback, Sasha Notice: 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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/15t5jXU5cNNnDF3zYXx5k?h=YvrCLbNoZB9SMyuNlItelAoOyyxFqRKtkoZYPYScUCE=&u=https://www.ietf.org/mailman/listinfo/spring> Notice: 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 https://www.ietf.org/mailman/listinfo/spring
