Hi Sasha,
Thanks a lot for your very useful comments.
Please find the following response.
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
[Liuyan] The current version mainly tries to discuss the requirement scenario
and the possible endpoint solution. The information is mentioned and the
related details have not been expanded yet. In the draft, it is mentioned that
"
Note that the underlay interface and the associated connection in
step 15 SHOULD be established before the associated End.XU SID is
announced into the network.
"
"
the End.XU SID defined in this document is used
to announce this optical path as an underlay connection with specific
attributes into the IP network, the headend node or the controller in
IP layer can program an inter-layer path along {P7, P1, End.XU (O1,
O2, O3), P3, P8} which may provide lower latency.
The optical path between O1 and O3 may be created in advance or as a
result of the request from the IP layer. The creation should be done
by the optical network controller (not shown in the Figure). The
details of the process are out of scope of this document, and may
refer to [I-D.ietf-teas-actn-poi-applicability].
"
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.
[Liuyan] The end behavior in this draft to programme the underlay path into the
end-to-end list is different from the current well-known endpoint
behaviors.Take one MTN node for example, this new SID instance is associated
with a new table to map the received SID packets to one selected MTN Path
channel. There is no need to assign IPv6 address for this MTN Path channel
endpoint.
Using a new end to describe this behavior will bring benefits on both the
forwarding and control planes. We can make full use of the resources of MTN
paths and programme it. (In general, the underlying direct connection of MTN
path means lower latency processing and transmission guarantee.) Otherwise, the
resource will not be visible and can not be freely selected in the SRv6 layer.
For operators, the whole network resources can not be arranged and controlled
in a unified scheme.
Any further discussions are welcome. Thanks.
Best regards,
Liuyan
2022-11-10
-------------------------------------
韩柳燕 / Han Liuyan
中国移动通信研究院 网络技术研究所 / China Mobile Research Institute
地址: 北京市西城区宣武门西大街32号创新大厦,100053
电话: 010-15801696688-33076
传真：010-63601087
手机: 15810339103
Email: [email protected]
-------------------------------------
发件人： Alexander Vainshtein
发送时间： 2022-11-09 14:55:26
收件人： 韩柳燕; Dongjie (Jimmy);
[email protected]
抄送： [email protected]; Michael Gorokhovsky; Nitsan Dolev; RotemCohen
主题： Re: [EXTERNAL] Re: RE: My question at the
mikeaboutdraft-dong-spring-srv6-inter-layer-programming
Liuyan,
Lots of thanks for your response.
Two points that I have been trying to make:
(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
(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
From: 韩柳燕 <[email protected]>
Sent: Wednesday, November 9, 2022, 02:54
To: Dongjie (Jimmy) <[email protected]>; Alexander Vainshtein
<[email protected]>;
[email protected]
<[email protected]>
Cc: [email protected] <[email protected]>; Michael Gorokhovsky
<[email protected]>; Nitsan Dolev <[email protected]>; Rotem
Cohen <[email protected]>
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: [email protected]
-------------------------------------
发件人： Dongjie (Jimmy)
发送时间： 2022-11-08 18:45:40
收件人： Alexander Vainshtein;
[email protected]
抄送： [email protected]; 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 <[email protected]> On Behalf Of Alexander Vainshtein
Sent: Tuesday, November 8, 2022 10:27 AM
To: [email protected]
Cc: [email protected]; Michael Gorokhovsky <[email protected]>; Nitsan
Dolev <[email protected]>; Rotem Cohen <[email protected]>
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:
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 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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
