+1
On Tue, Nov 8, 2022 at 6:50 PM Alexander Vainshtein < alexander.vainsht...@rbbn.com> wrote: > 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> > *Sent:* Tuesday, November 8, 2022 10:46 AM > *To:* Ketan Talaulikar <ketant.i...@gmail.com>; Alexander Vainshtein < > alexander.vainsht...@rbbn.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> > *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> > *Sent:* Tuesday, November 8, 2022 10:33 AM > *To:* Alexander Vainshtein <alexander.vainsht...@rbbn.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> > *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> 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 > 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
