Hi Ketan，
Sorry for the late reply. Please see inline...
Best Regards,
Ran
Original
From: KetanTalaulikar <ketant.i...@gmail.com>
To: 陈然00080434;
Cc: alexander.vainsht...@rbbn.com
<alexander.vainsht...@rbbn.com>;spring@ietf.org <spring@ietf.org>;
Date: 2022年11月09日 21:57
Subject: Re: [spring] Hope to draw the attention of the Working
Group：draft-han-spring-srv6-underlay-tunnel-programming-01
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Ran,
The questions/points raised by Sasha, et all on the thread below also applies
to this draft that you have brought up - i.e. how things work when this is
modeled as a L1 interface and why not L3.
https://mailarchive.ietf.org/arch/msg/spring/IrzGONQP1zXvBHkvmZyaHOEwC68/
Ran: Our extended END.BXC function is similar to END.BM function, the
difference is our functions mapping the SRv6 tunnel to L1 "tunnle"(L1
conncetion) instead of MPLS tunnel. Thus we can support a end-to-end SRv6
tunnel which across an underlay L1 connection with stitching mode.
Additionally, I am not familiar with the concept of "channel" used here and
specifically what standard covers that. Would be good if you can elaborate.
Ran：Channel means L1 connection without packet forwarding from ITU-T transport
network, just like OTN connection, but in our draft, the channel is created by
ITU-T MTN(G.8310).
Otherwise, the draft-dong and draft-han are similar with the main difference
being that one is proposing a variant of End.X while the other is End.B (BSID).
On a side note (but important one), I am concerned when you said that this
proposal has been implemented by ZTE but I find no allocation made for the code
point. Please do not squat - especially in this case where the registry is
FCFS:
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors
Ran：We are temporarily using the code point not assigned by IANA, thanks for
the reminder, we'll apply right away.
Thanks,
Ketan
On Wed, Nov 9, 2022 at 1:21 PM <chen....@zte.com.cn> wrote:
Hi Joel，Sasha，Ketan and WG
There is a similar proposal ， and in which we want to provide the end-to-end
SRv6 tunnel to bind the L1 connection directly. It defines a new SRv6 END.BXC
behavior for inter-layer network programming. The SRv6 END.BXC Function
mechanism has been implemented by ZTE, and China Mobile has successfully
completed the basic verification of this function. The link is:
https://datatracker.ietf.org/doc/draft-han-spring-srv6-underlay-tunnel-programming/
Abstract
This document defines a new SRv6 Endpoint behavior which can be used
for SRv6 underlay tunnel (e.g.L1 channel) Programming, called
END.BXC, this behavior are used to bind an underlay tunnel.
Any comments are welcome.
Best Regards，
Ran
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
