Hi Joel,
Great suggestion and question. This part of the requirement was not expanded in
the current draft. We considered that the OAM functions have been supported in
the existing underlay TDM technologies and can be used to determine the
availability of the underlay connection. We can add some explanations in the
draft later to make it clearer.
Best regards,
Liuyan
----邮件原文----发件人：Joel Halpern <jmh.dir...@joelhalpern.com>收件人："韩柳燕"
<hanliu...@chinamobile.com>,Joel Halpern
<j...@joelhalpern.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-16 20:51:01主题：Re: [spring] Re:
My question at themikeaboutdraft-dong-spring-srv6-inter-layer-programming
I may have missed it, but the draft does not seem to make
clear the requirement on the underlay to be used with this inter-layer
programming. WHile the ddraft lists optical and MTN as examples, it
is not explicit about the restrictions that need to be met.
Yours,
Joel
On 8/16/2024 6:30 AM, 韩柳燕 wrote:
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
