Hi Chongfeng

To expand on the use case for the disparate network PEs is the they have
IPv6 connectivity between them so could be remote PE gateways under their
admin control however all intermediate nodes are outside their admin
control. Data plane stitch even without overlay stitch does require some
 trust level.  Also generally if you are able to stitch data plane more
then likely trust level is such that  you can extend the overlay as well.

This is a good use case for SRv6 Compression C-SID Nexf SID (uSID)  which
allows you to use IPv6 data plane to stitch so can stitch seamlessly and
the other side does not have to be aware and can blindly forward the
packets.

So the situation use case is interesting but I think corner case.

Kind Regards

Gyan


On Fri, Jul 26, 2024 at 11:59 PM Gyan Mishra <hayabusa...@gmail.com> wrote:

>
> Hi Chongfeng
>
> This is a very intriguing solution.
>
> The use case for this solution is EVPN L2 stretch  over the internet or
> disparate IP networks that could be in the same OAD admin domain and have
> IP connectivity between disparate PEs but do not have the availability to
> natively extend the EVPN control plane but are able to stitch the data
> plane.
>
> I think if you are able to extend EVPN control plane natively then you
> would do regular EVPN but if you cannot then you are stuck and this
> solution fills that gap.
>
> I guess there could be case of a Telco cloud providet with hybrid cloud on
> prem and off prem DC CSP cloud provider through a CXP POP and now this
> could be method of providing L2 stretch of data plane via EVN6 control
> plane.
>
> With the procedure once the tunnel is established at the beginning once
> the dynamic mapping happens would you not need DF election ?
>
> Since this is all new procedures from RFC 7432 and RFC 8365 base RFCs
> would you have to write the entire new EVPN control plane procedures.  For
> example how would RFC 9135 inter subnet forwarding work?
>
> Very nice indeed!
>
> Kind Regards
>
> Gyan
>
>
> On Fri, Jul 26, 2024 at 12:52 AM Chongfeng Xie <chongfeng....@foxmail.com>
> wrote:
>
>>
>> Hello everyone,
>> We have submitted a new draft on "EVPN Route Types and Procedures for
>> EVN6" to BESS WG,  it proposes extensions to EVPN for EVN6. EVN6 is a
>> Layer-2 network model built on top of the IPv6 underlay to provide
>> connectivity between dispersed customer sites, the draft of EVN6 has been
>> presented in Intarea and v6ops WGs.  We are looking forward to your review
>> and comments to this new draft.
>> Thanks.
>>
>> Best regards
>> Chongfeng
>>
>>
>> *From:* 【外部账号】 <internet-dra...@ietf.org>
>> *Date:* 2024-07-26 12:25
>> *To:* Chongfeng Xie <xie...@chinatelecom.cn>; Guoliang Han
>> <guoliang....@indirectionnet.com>; Jibin Sun <su...@chinatelecom.cn>; Xing
>> Li <x...@cernet.edu.cn>
>> *Subject:* New Version Notification for
>> draft-xie-bess-evpn-extension-evn6-00.txt
>> A new version of Internet-Draft draft-xie-bess-evpn-extension-evn6-00.txt
>> has
>> been successfully submitted by Chongfeng Xie and posted to the
>> IETF repository.
>>
>> Name:     draft-xie-bess-evpn-extension-evn6
>> Revision: 00
>> Title:    EVPN Route Types and Procedures for EVN6
>> Date:     2024-07-25
>> Group:    Individual Submission
>> Pages:    13
>> URL:
>> https://www.ietf.org/archive/id/draft-xie-bess-evpn-extension-evn6-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-xie-bess-evpn-extension-evn6/
>> HTMLized:
>> https://datatracker.ietf.org/doc/html/draft-xie-bess-evpn-extension-evn6
>>
>>
>> Abstract:
>>
>>    EVN6 is a mechanism designed to carry Ethernet virtual networks,
>>    providing Ethernet connectivity to customer sites dispersed on public
>>    IPv6 networks.  At the data layer, EVN6 directly places the Ethernet
>>    frames in the payload of IPv6 packet, and dynamically generates the
>>    IPv6 addresses of the IPv6 header using host MAC addresses and other
>>    information, then sends them into IPv6 network for transmission.
>>    This document proposes extensions to EVPN for EVN6, including two new
>>    route types and related procedures.
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> BESS mailing list -- b...@ietf.org
>> To unsubscribe send an email to bess-le...@ietf.org
>>
>
_______________________________________________
nvo3 mailing list -- nvo3@ietf.org
To unsubscribe send an email to nvo3-le...@ietf.org

Reply via email to