Speaking as a participant, why can they not be unnumbered IP
interfaces? No address allocation. And you can omit them from the IGP
if you want (so that it is only used by steered traffic?)
Yours,
Joel
On 11/8/2022 10:47 AM, Dongjie (Jimmy) wrote:
Hi Sasha,
Allocating IP addresses is one aspect to be considered here. As I
mentioned in the chat window, these underlay paths can be created for
specific services (not for all services), thus it is not expected that
they appear in the L3 topology and used for normal IP path
computation. So it is necessary to distinguish them from the normal IP
links.
Best regards,
Jie
*From:*Alexander Vainshtein <alexander.vainsht...@rbbn.com>
*Sent:* Tuesday, November 8, 2022 1:20 PM
*To:* Dongjie (Jimmy) <jie.d...@huawei.com>
*Cc:* 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>; Ketan Talaulikar <ketant.i...@gmail.com>
*Subject:* RE: [spring] My question at the mike about
draft-dong-spring-srv6-inter-layer-programming
Jie, and all,
IMHO there is no need to allocate dedicated IP addresses to the
endpoints of the optical path.
You could define them as unnumbered IPv4-capable interfaces borrowing
some loopback address of he containing node (which in any case exists)
or, in an IPv6-only scenario, allocate just link-local IPv6 addresses
to these endpoints. You could then use some existing mechanisms for
each endpoint to learn the MAC address of the other.
Once this happens, End.X would work without any changes IMHO.
Regards,
Sasha
*From:*Dongjie (Jimmy) <jie.d...@huawei.com>
*Sent:* Tuesday, November 8, 2022 10:46 AM
*To:* Ketan Talaulikar <ketant.i...@gmail.com>; Alexander Vainshtein
<alexander.vainsht...@rbbn.com>
*Cc:* 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:* [EXTERNAL] RE: [spring] My question at the mike about
draft-dong-spring-srv6-inter-layer-programming
Hi Ketan,
In the use cases presented during the meeting, no IP address needs to
be provisioned on the endpoints of the underlay path, thus to my
understanding they are not IP enabled optical paths.
Best regards,
Jie
*From:*Ketan Talaulikar <ketant.i...@gmail.com>
*Sent:* Tuesday, November 8, 2022 10:33 AM
*To:* Alexander Vainshtein <alexander.vainsht...@rbbn.com>
*Cc:* 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: [spring] My question at the mike about
draft-dong-spring-srv6-inter-layer-programming
Hi Sasha,
Your point is very valid and I assumed that the optical path is IP
enabled but there is no routing protocol running over it. There may be
a mix up between the terms L3 adjacency and IGP adjacency.
RFC8986 Section 4.2 End.X works for L3 adjacency (with or without
routing protocol running over the link) as well as L2 bundle members
of an L3 LAG interface. In all cases, the neighbor resolution and
handling for IP packets is expected.
Thanks,
Ketan
On Tue, Nov 8, 2022 at 3:57 PM Alexander Vainshtein
<alexander.vainsht...@rbbn.com> wrote:
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/15t5Zs5Wh91bPMQ9TR9nW?h=dDfw036YxeQFRNa8ajR8qlqeAI8RvZ3iLZhO8gcfBPI=&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/15t5ehGo9khBoJE4zyYw8?h=mMx_9LBKQMNnIC9R12iF9YbkpOtphR8ALGiAT_goRgc=&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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
<https://clicktime.symantec.com/15t5jXU5cNNnDF3zYXx5k?h=YvrCLbNoZB9SMyuNlItelAoOyyxFqRKtkoZYPYScUCE=&u=https://www.ietf.org/mailman/listinfo/spring>
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
