Hi Sasha, Thanks for the useful discussion. Please see some replies inline:
From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Sent: Thursday, November 10, 2022 3:02 PM To: Dongjie (Jimmy) <jie.d...@huawei.com> Cc: 韩柳燕 <hanliu...@chinamobile.com>; 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: [EXTERNAL] Re: RE: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming Hi Jie, First a couple of question for my education. I have looked up ITU-T G.8310 and it states that MTH is an ITU-T term for what earlier has been known as Flex-Ethernet. Is this understanding correct? And if yes, does the MTN path to which you refer an equivalent to a Flex-Ethernet channel? [Jie] In G.8310, the architecture of MTN is defined, which consists of multiple layers including the MTN section layer (MTNS), MTN path layer (MTNP) and the client layer. The MTN path layer provides cross-connect channel forwarding of Ethernet frames. The MTNS layer is based on Flex Ethernet, and it provides fixed point-to-point connectivity for the MTNP layer. Now back to the business: In my experience, optical (say, DWDM) paths are typically bi-directional, and so are Flex-Ethernet channels. But a unidirectional entity (e.g., an TE LSP) can still be used as a Layer 3 construct – you may look at unidirectional RSVP-TE LSPs as IGP shortcuts in RFC 3906<https://datatracker.ietf.org/doc/html/rfc3906> as an example. [Jie] The MTN path can be unidirectional, so do the optical paths. To my understanding, the bi-directional connectivity is the requirement of a IP link. When TE LSPs are used as IGP shortcuts, they are only used locally by the tunnel ingress nodes and are not advertised to other nodes for path computation. IGP FA allows a node to advertise a TE tunnel as a IGP link for use in the IGP computation by other nodes, while it does require bidirectional connectivity (a reverse tunnel is required). In the use cases described in this document, the underlay path is advertised to the controller or the ingress nodes for cross-layer TE path computation and to build the SRv6 SID list for cross-layer packet forwarding. Thus a reverse path may exist but is not required to be functional for the computation and forwarding. The mechanism proposed is to allow the underlay path to be advertised and used in path computation, without the constraints of IP links (bidirectional, IP addresses, etc.). In addition, it can help to distinguish the IP links from these underlay paths, so that they can be used in path computation for different types of services separately. Admittedly, you would not be able to run ARP or ND via a unidirectional construct, and would have to rely on something like static ARP/static Neighbor Cache entries. [Jie] Yes some static ARP/MAC entries could be used for this link, this also shows it is different from the normal IP link. But this is quite well understood, I think. And in an case this configuration would be local to the head-end node of the unidirectional path, and I do not see no need to expose to the other nodes the fact that your SR policy uses a special unidirectional path as one of its segments. Therefore, I still do not understand he motivation for defining a new endpoint behavior and associating it with some SID. [Jie] As mentioned above, the information and the SID of this underlay path needs to be advertised to controller or the ingress nodes for cross-layer path computation. In that case, it is different from the mechanism with IGP shortcut or IGP FA. Thus it is needed to define its semantic and behavior explicitly. Best regards, Jie Regards, Sasha From: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>> Sent: Thursday, November 10, 2022 10:38 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; 韩柳燕 <hanliu...@chinamobile.com<mailto:hanliu...@chinamobile.com>>; 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: RE: [EXTERNAL] Re: RE: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming 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<mailto:alexander.vainsht...@rbbn.com>> Sent: Wednesday, November 9, 2022 6:50 AM To: 韩柳燕 <hanliu...@chinamobile.com<mailto:hanliu...@chinamobile.com>>; Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; 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: 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://clicktime.symantec.com/15sLvRUsZ78JHk2dckb9k?h=LDx06GbcmsvOhs7zJzz-IwzfiUhBsHAkulN97qYKev0=&u=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. 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
