Hi Gyan,
Thanks for reviewing the draft.
Please see my comments in-line.
From: Gyan Mishra <hayabusa...@gmail.com>
Date: Tuesday, January 28, 2025 at 9:02 PM
To: Stephane Litkowski (slitkows) <slitkows=40cisco....@dmarc.ietf.org>
Cc: draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org
<draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org>, bess@ietf.org
<bess@ietf.org>, Voyer, Daniel <daniel.vo...@bell.ca>, Bernier, Daniel
<daniel.bern...@bell.ca>
Subject: Re: [bess] Short new WGLC and IPR poll for
draft-ietf-bess-evpn-ipvpn-interworking-12
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
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.
[jorge] the procedures we're outlining are independent of the underlying
infrastructure in each domain. I don’t think the draft needs to discuss any
underlay aspects. If you think the scope should clarify that the procedures are
independent of the underlay, we can do it in the introduction.
The draft does not talk about intra-domain scenario within a NVO VXLAN or MPLS
/ SR-MPLS / SRv6 fabric.
[jorge] the document defines a domain as follows:
Domain: Two PEs are in the same domain if they are attached to the same tenant
and the packets between them do not require a data path IP lookup (in the
tenant space) in any intermediate router. A gateway PE is always configured
with multiple DOMAIN-IDs. The domain boundaries are not limited to an
Autonomous System or an IGP instance. The PEs in a domain can all be part of
the same or different Autonomous System, and an Autonomous System can also
contain multiple domains.
So it is independent of the underlay “domains”.
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.
[jorge] Not sure what you mean by “from ISF to SAFI 128”. SAFI 128 routes are
deined as ISF routes too in the document. Also if by “RT” you mean route
targets, sections 5 and 8 describe how route targets are treated when routes
are readvertised into the adjacent domain.
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.
[jorge] I'm not sure I agree. D-PATH is only one aspect. The spec also talks
about Path attribute propagation, route selection across ISF routes, composite
and gateway procedures, error handling, etc.
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)
[jorge] I’m not sure if I follow. RFC4364 section 10 option a is IP-VRF to
IP-VRF connectivity via subinterfaces, not tunnels. This spec does not
introduce any procedures for option “a".
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
[jorge] this falls under the gateway procedures in the draft. Please check out
section 8.
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.
[jorge] this spec is about ISF routes, that is, Inter Subnet Forwarding routes,
and not layer-2 information. For EVPN that includes routes that are processed
in the context of an IP-VRF route table, which includes IP Prefix routes and
MAC/IP routes when processed as in RFC9135 symmetric IRB model. That’s because
both types are used for inter subnet forwarding in EVPN networks. Please let me
know if I’m missing something.
Thank you.
Jorge
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=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> 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 -- bess@ietf.org<mailto:bess@ietf.org>
To unsubscribe send an email to bess-le...@ietf.org<mailto:bess-le...@ietf.org>
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org
