Hi Joel,
Thank you for your question.
The underlay networks, such as optical OTN network or MTN network, support
periodic OAM transport and detection. OAM detection can determine whether the
ODUk or MTN link is up. If there is a fault, an alarm will be reported and
protection switching will be triggered.
Best regards,
Liuyan
----邮件原文----发件人：Joel Halpern <j...@joelhalpern.com>收件人："韩柳燕"
<hanliu...@chinamobile.com>,draft-dong-spring-sr
<draft-dong-spring-srv6-inter-layer-programm...@ietf.org>,"Alexander.Vainshtein"
<alexander.vainsht...@rbbn.com>,"Dongjie (Jimmy)" <jie.d...@huawei.com>抄 送:
"spring@ietf.org" <spring@ietf.org>发送时间：2024-08-15 23:02:31主题：Re: [spring] Re:
My question at the mikeaboutdraft-dong-spring-srv6-inter-layer-programming
Is there an assumption that some other monitoring exists so
that there is knowledge of whetehr the link is up to control
advertising the new adjacency SID?
Yours,
Joel
On 8/15/2024 6:32 AM, 韩柳燕 wrote:
Hi Sasha,
Thanks a lot for your question at the meeting and via the email
discussions.
I would like to add some clarifications. The new SRv6 behaviors does
not require IGP based link discovery and advertisement for the underlay
connection between the two endpoints, which is needed for End.X
behavior. It is more adaptable to the network situation and has
application advantages. Because for large networks, the nodes at both
ends may span different metropolitan areas networks or even backbone
networks, and may not be in the same IGP domain due to the limited size
of IGP. The new SRv6 behaviors in this draft do not require IGP to be
enabled as the control protocol between the two end nodes of the
underlay link and doesn39t require this link to be visible in L3
topology.
Best regards,
Liuyan
----邮件原文---- 发件人："Dongjie \\(Jimmy\\)"
<jie.dong=40huawei....@dmarc.ietf.org> 收件人：Alexander Vainshtein
<Alexander.Vainshtein=40rbbn....@dmarc.ietf.org>,"draft-dong-spring-srv6-inter-layer-programm...@ietf.org"
<draft-dong-spring-srv6-inter-layer-programm...@ietf.org> 抄 送:
"spring@ietf.org" <spring@ietf.org> 发送时间：2024-08-05 11:38:21
主题：RE: My question at the mike
aboutdraft-dong-spring-srv6-inter-layer-programming
Hi Sasha,
Thanks a lot for your comments during the SPRING session and in
the follow-up mails. Please see some replies inline with
[Jie]:
From: Alexander Vainshtein
[mailto:Alexander.Vainshtein=40rbbn....@dmarc.ietf.org]
Sent: Sunday, July 28, 2024 1:05 AM To:
Dongjie (Jimmy) <jie.d...@huawei.com>
draft-dong-spring-srv6-inter-layer-programm...@ietf.org Cc:
spring@ietf.org Subject: Re: My question at the
mike about
draft-dong-spring-srv6-inter-layer-programming
Jie,
Lots of thanks for your email.
First, I would like to apologize for not responding to your
emails earlier.
[Jie] No problem, it is always good to know your opinion no
matter early or late:)
I think that there is a certain mismatch of terminology that
have resulted in misunderstanding.
[Jie] I also realized this, and have checked with my
colleague who is closer to the implementation.
In my (and, AFAIK, relatively common) terminology frames
received from a Layer 2 logical interface are disposed based
solely in their L2 header. (In the case of Ethernet this would
include Destination and Source MAC addresses and zero, one or
two VLAN tags - but not the "true" Ethertype that follows these
tags. Other L2 media uses similar arrangements). I.e., the
node that receives Ethernet frames from what it
considers a L2 interface cannot differentiate between, say,
IPv4, ARP, IPv6 and MPLS.
[Jie] Agreed, although to my understanding MPLS sits between
layer 2 and layer 3.
It is the ability to differentiate between different protocols
based on the "true" Ethertype and, say, look up the Destination
IPv6 address in the appropriate FIB (which is required for
SRv6) that makes an interface a L3 one from my POV.
[Jie] Agree that for an interface to process SRv6 packets,
it needs to be associated with some L3 functionality.
While it does not need to be a full L3 interface
which is visible in the routing topology. In other word, the
L3 adjacency is better to be avoided. We can add some
clarification in next update.
Regarding your concern about L3 interfaces involving
adjacencies, I also think this is unfounded. It is quite easy
to make an IGP adjacency unusable for normal IP forwarding by
assigning maximum cost to the corresponding link -but using
Adj-SIDs allocated and advertised for such a link in SR-TE
policies that are set up by the appropriate controller.
[Jie] The primary goal here is not about how to make an IGP
adjacency unusable in IP routing, it is about how to
avoid the challenge and cost of establishing IGP
adjacency between two remote endpoints (they can even belong
to different IGP domains). As since the underlay interface
and path can be created/deleted dynamically, adding such link
using Adj-SIDs to IGP would also impact the protocol
stability.
Thus it would be beneficial to distinguish it from the L3
Adj-SIDs/End.X SIDs in SPRING, and its advertisement
can also be separate from the control plane mechanisms
for Adj-SIDs/End.X SIDs.
Hope this helps to clarify the intent of this effort.
Best regards,
Jie
Hopefully these notes will be useful
Regards,
Sasha
Get Outlook for Android
--------------------------------------------------------------------------------
From: Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org>
Sent: Saturday, July 27, 2024 7:59:30 AM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
draft-dong-spring-srv6-inter-layer-programm...@ietf.org
<draft-dong-spring-srv6-inter-layer-programm...@ietf.org>
Cc: spring@ietf.org <spring@ietf.org>
Subject: [EXTERNAL] Re: My question at the mike about
draft-dong-spring-srv6-inter-layer-programming
Hi Sasha, Thanks for your
question at the mic. Please see some replies inline:
________________________________________
From: Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org>
Sent: Saturday, July 27, 2024 5:27 To:
draft-dong-spring-srv6-inter-layer-programm...@ietf.org Cc:
spring@ietf.org Subject: [spring] My question at the mike about
draft-dong-spring-srv6-inter-layer-programming
Hi all, Just repeating the question about the
draft<https://datatracker.ietf.org/doc/html/draft-dong-spring-srv6-inter-layer-programming-08>
I’ve asked at he mike at the SPRING WG session today.
* Suppose that there is an underlay
link between a pair of IP nodes that is not “visible in he L3
topology”. To me this means that there no P-capable (logical)
interfaces associated with the endpoints of this
underlay link [Jie] The interface of the
underlay link is not L3-capable, while it still can have some
packet processing capability. You may consider it as a layer-2
logical interface.
* Suppose further that one of these nodes (the upstream one)
allocates and advertises an SID with End.XU behavior for this
underlay link * The upstream node receives an
IPv6 packets with the tops SRv6 SID on it being the End.XU. It
strips this SID (this the common behavior of all End-like SIDs)
and send the resulting IPv6 packet across the link to the
downstream node/\. Now the question: How should the
downstream node process the received packet if its local
endpoint of the undelay link s not associated with an
IP-capable logical interface?
[Jie] Similar to what I said above, the receiving interface is
not L3-capable, while it can receive and process the packet
properly in layer-2, the inner L3 packet header can be
processed by the node. If the
endpoints of the underlay ink are associated with L3 interfaces
in both nodes, the link becomes visible in L3 topology, and a
regular End.X SID can be allocated and advertised for it.
[Jie] As described in the draft, making it an L3
adjacency between the two endpoints is both challenging
and unnecessary. And operator does not want this link to be
visible in L3 topology. Thus regular End.X SID does not meet
the requirement here. Hope this
help to answer your question. Best regards,
Jie Hopefully this
clarifies my question. Regards,
Sasha
Disclaimer 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.orgTo unsubscribe send an email to
spring-le...@ietf.org
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
