Hi Sasha, Here are some thoughts about why the MTN or optical underlay connection may not be seen as L3 links.
MTN or Optical underlay path is usually unidirectional from the ingress IP node to the egress IP node, although provisioning and associating them into bidirectional paths is possible. This makes it different from a functional layer-3 link. Thus we think it needs to be distinguished from a layer-3 adjacency. In addition, for such an underlay path, the associated attributes could be different from those of L3 links, this could be reflected in the distribution of the underlay path information in control plane. With the above difference, do you think a new variant of End.X behavior is needed? Thanks. Best regards, Jie From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Sent: Wednesday, November 9, 2022 6:50 AM To: 韩柳燕 <hanliu...@chinamobile.com>; Dongjie (Jimmy) <jie.d...@huawei.com>; draft-dong-spring-srv6-inter-layer-programm...@ietf.org Cc: spring@ietf.org; Michael Gorokhovsky <michael.gorokhov...@rbbn.com>; Nitsan Dolev <nitsan.do...@rbbn.com>; Rotem Cohen <rotem.co...@rbbn.com> Subject: Re: [EXTERNAL] Re: RE: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming Liuyan, Lots of thanks for your response. Two points that I have been trying to make: 1. (Minor) The draft does not say how the information required for forwarding Layer 3 (IP or MPLS) packets via a Layer 1 path can be obtained and used. It does not even mention that such information is required 2. (Major) The new End behavior seems superfluous because, as I see it, the same functionality can be provided by annuunsing the underlay path to the IP layer and using already defined and deployed mechanisms. Hopefully these notes will be useful. Regards, Sasha Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: 韩柳燕 <hanliu...@chinamobile.com<mailto:hanliu...@chinamobile.com>> Sent: Wednesday, November 9, 2022, 02:54 To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; draft-dong-spring-srv6-inter-layer-programm...@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programm...@ietf.org> <draft-dong-spring-srv6-inter-layer-programm...@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programm...@ietf.org>> Cc: spring@ietf.org<mailto:spring@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: RE: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming Hi Sasha, Thank you for your questions and discussion. I'm sorry I hesitated for a while online and lost the chance to reply it in time. Jie (also author) answered this on the spot. As Jie stated, I think the possible ways: the underlay path information could be announced to the IP layer by the control plane, or all the information (non-IP) is collected by the centralized controller. The intermediate node that is allocated an END.XU SID could perform the processing according to the pre configured or pre notified L2/L1 mapping relationship (I think it will not rely on the packet L2 encapsulation). The examples we gave yesterday were mainly L1. We can add some more in the next version. Thanks. Best regards, Liuyan 2022-11-09 ________________________________ ------------------------------------- 韩柳燕 / Han Liuyan 中国移动通信研究院 网络技术研究所 / China Mobile Research Institute 地址: 北京市西城区宣武门西大街32号创新大厦,100053 电话: 010-15801696688-33076 传真：010-63601087 手机: 15810339103 Email: hanliu...@chinamobile.com<mailto:hanliu...@chinamobile.com> ------------------------------------- ________________________________ 发件人： Dongjie (Jimmy) 发送时间： 2022-11-08 18:45:40 收件人： Alexander Vainshtein; 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; Nitsan Dolev; RotemCohen 主题： RE: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming Hi Sasha, This is a good question. I tried to answer your question on the mic. My reply was that such information may be obtained as part of the underlay path instantiation via either control plane or management plane. The detail of layer-2 encapsulation is not covered in the current draft. We will add something in next version. Best regards, Jie From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of Alexander Vainshtein Sent: Tuesday, November 8, 2022 10:27 AM To: draft-dong-spring-srv6-inter-layer-programm...@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programm...@ietf.org> Cc: 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: [spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming 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/15t5Zs5jSWemT7Dk8pugX?h=wPozKPXDLeGHRvEtpMbdBrAxN8jofY3wm_tWbfJrQMc=&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/15t5ehH1u8LMs43fgPJq9?h=RLOWlbz2OCMTaTgR5WVyfcz9lNVAL5FLEbD-XJINGWI=&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. 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
