[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

[Gyan Mishra <[e-mail]>]

 I support progressing this draft with some slight modifications below.

I have a very important addition to the draft that I think is pertinent
that I would like to share.

Before I get to that I had a comment on the draft as it exists today.

The draft does not talk about underlay mismatch at the domain boundary
which is very important.

The draft does not talk about intra-domain scenario within a NVO VXLAN or
MPLS / SR-MPLS / SRv6 fabric.

Also this draft talks mostly all about the new D-PATH path attribute but
does not talk about any details of the gateway function going from ISF to
SAFI 128 and how that would work.  Is the RT reoriginated at the domain
boundary as the other type of SAFI in either direction I am guessing maybe
but the draft does not talk about it at all.

I think this is critical to the progression of the draft.

My recommendation is to rename the draft to “EVPN to IPVPN  IW with D-PATH”
would make more sense the way the draft is written.

In the context of IPVPN & EVPN interaction and ISF and SAFI 128 there is a
myriad of scenarios that can exist.

This is an extremely important topic as it comes up all the time for inter
domain boundaries propagating  of L2 & L3 NLRI successfully across domain
boundaries and within a domain a translation gateway.

In most all cases generally the composite PE, composite domain works
seamlessly no issues as two ships in the night that don’t touch each other.

The complexity and possible loops that D-PATH solves the Gateway scenario.

A typical method which is very commonly done for eBGP peering  to propagate
EVPN RT-5 prefixes to IP VPN.  One end of eBGP peering is NVO VXLAN/GENEVE
ASBR (CE) and other end is MPLS IP VPN SAFI 128 PE.  The peering is
inter-as opt-a back to back VRF IPv4 Unicast and IPv6 unicast peering. This
works extremely well and both ends can be pretty much any kind of underlay
data plane mismatch and you don’t require any special gateway transport or
service interworking in the case of any of the following:

MPLS / SR-MPLS to SRv6.
MPLS / SR-MPLS to VXLAN
SRv6 to VXLAN

Stick diagram (eBGP)

                     Inter-as opt-a

If the underlay  on core & dc is the same then you still have to use
inter-as opt-a

ASBR (DC EVPN) <-> PE (Core IP VPN)

If you have underlay  mismatch then there is also IW/GW transport or
service interworking

This same concept works with iBGP peering within the data center where the
concept requires an intermediate router we can call a Gateway and can be
solved by NVO VXLAN/GENEVE EVPN  on one end iBGP to  PE with IP VPN SAFI
128 PE.  The EVPN leaf-1  advertises the routes IPv4 unicast / IPv6 unicast
routes RT-5 prefixes to an intermediate router (GW) PE SAFI 128 -> VPNv4 /
VPNv6 (RR) -> propagates VPNv4/VPNv6 to rest of fabric.

Stick diagram (iBGP)

leaf-1 <-> GW <-> (RR) <-> rest of fabric

In both the eBGP & iBGP use case we are trying to get the EVPN mac VRF
routes reachability imported into SAFI 128 but all we need is the RT-5
prefixes and not the MAC VRF RT-2 host routes so the RT-5 summary suffices.


Using this solution it’s very simple and elegant and no loops.

Is it possible to add my comments to the draft.

Many Thanks!!

Gyan


On Mon, Jan 27, 2025 at 5:25 AM Stephane Litkowski (slitkows) <slitkows=
[e-mail]> wrote:

> Hi,
>
>
>
> As draft-ietf-bess-evpn-ipvpn-interworking went through multiple
> discussions that seem to be closed now. We would like to do a new short
> WGLC of 1-week to gather any additional comment before we move forward with
> the draft.
>
>
>
> The WGLC poll starts today and will end on 2/3.
>
>
>
> Similarly, as the last IPR poll was done a long time back. We are also
> polling for knowledge of any undisclosed IPR that applies to this document
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
>
>
> Thank you
>
>
>
> Brgds,
>
>
>
>
>
> Stephane, Matthew, Jeffrey (BESS chairs)
>
>
>
>
>
>
> _______________________________________________
> BESS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>