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 doesn't 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 <https://aka.ms/AAb9ysg>
------------------------------------------------------------------------
*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
tospring-le...@ietf.org
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
