Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019BDC151997; Wed, 29 Jan 2025 22:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrg9EH6G7b-b; Wed, 29 Jan 2025 22:45:53 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2883C16A128; Wed, 29 Jan 2025 22:45:53 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-2166022c5caso5751735ad.2; Wed, 29 Jan 2025 22:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738219553; x=1738824353; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JnimnKfwXLoSiTcrn2XJ8saiQntaRy5rzJSuWtmeiZ0=; b=BGMOhQLfjoO1CJYYZythIAJiv44SpaHSKY63eOFlnLZSOlMdtPya1BsP5esv9WU9Tw 1WQE3NCZ3KIimxYyfMJj19GJQI4k88X0GvCFTH79w13Eiu9MvwmC7ac7PmRb/SM2NYai W/Rny4/u9wH6LeKj8S3rPG3/nsEtzuppp4OdYoxENNXCzmnqZAgehRXhUp6RXlrH0dNB 2Y45u8JwN57vo3h3327HZ/9JtJkOUJZvP80P6l35j1TwZAxI1ylFG9R4KbFDpolfEeTC vavVhQ/DlvPATI7Na41t754IzKj/T7e+Pp+NxTLv0iqecan1CvGSj/FbW5/D9nQU9Zd5 GIkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738219553; x=1738824353; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JnimnKfwXLoSiTcrn2XJ8saiQntaRy5rzJSuWtmeiZ0=; b=dKIHptIFC3rl/qSqkUOJk95eCius+h+1ct5htEkVUYOiJh/3dU7/dJIobUBxx3y8Gf V7kHJF0RS0smMH2nUmIpFmBBehAhisX+2qLnXgFXGflm4WX0y55e49lFZlfIh1OV7MTd IscLb0JHnbMN9mwbPm6hDM5XhRRzX2wNDVxnuWhKzdciZMr6yq4skm609HrPOCTlmNna qeDXpHnMjZ4yUbjzwtbVBgkGuVfQOFqQVMx177doOzLgz8PdyL8mDd0POuC2ABS8QcUc F2SkMHT1ry7aP0laecu9inqMC+Z8fRyuL/pBF0TGY+reEtQenXrXr5TRRRt5qk5vt0pK hYew== X-Forwarded-Encrypted: i=1; AJvYcCUA1RMyQi53OC4c7aF8HS4Cn/VjAK5ujwnmiWyq74uMIQ9IPKkVkq733egCj7zrjmZKvYakcjMUjULRnsWZnhvjtUSMR9vNni/M+uKpvwsu1ZPW1iAQc4GT@ietf.org, AJvYcCWl5l2lDB3CcaMiYkk+QtC4UvPBSHkE9Jcx28Y76VpwYHzcNDHlAlzhfKtiqGN1N2vDpI28@ietf.org X-Gm-Message-State: AOJu0YzSEiNOIUUqhHamaTZ7ghVwJeSUBUlUH00/Rzs/HO/m+s9pbZua e9yomz+WDLh40GOHX/hysDvcomMYYG1AzUJWyAvCdmt5lCgWVNbHR+ljEtUUnjlAJxrTxXXFxs6 QjLF7d1FUT0GsS6Ezm5Qit3uUJRU= X-Gm-Gg: ASbGncuEQ8sSQieJ1r9lnLegqdX7I9jK6QvDaLOfp19j+0kgORJcyTEBvqkVYCzknC7 AxZfaVJhcm7zLAqtjWDSTjn/o3qF0e7HR7iUVT3yrvVStkfg9MxOpmNsys/mWEFd+RBygH6blMH IysQIghjoMb040IKcaOS9uTTI1N1Ri894= X-Google-Smtp-Source: AGHT+IFgDjeJ6vbtDxjtiA8r8KuabHWAiZV5fg/4dJxT0M9hmMU5cZbAil9PGYUfWVdyFeq0zad6tuJo3r/T3yoooE4= X-Received: by 2002:a05:6a21:1508:b0:1e0:dc7b:4ee9 with SMTP id adf61e73a8af0-1ed7a5b66c4mr10283649637.8.1738219553061; Wed, 29 Jan 2025 22:45:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Thu, 30 Jan 2025 01:45:42 -0500 X-Gm-Features: AWEUYZm4fx_rZe1YIeIJ1zKq9W-MzeQC0abXmpf8aHe6Lyfo2j8LLhz9eDj59QA Message-ID: To: "Jorge Rabadan (Nokia)" Content-Type: multipart/alternative; boundary="00000000000000845c062ce6c733" Message-ID-Hash: CWYQLJNRAAEPGVZNHCIS7MHTNOS6E3SY X-Message-ID-Hash: CWYQLJNRAAEPGVZNHCIS7MHTNOS6E3SY X-MailFrom: hayabusagsm@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Stephane Litkowski (slitkows)" , "draft-ietf-bess-evpn-ipvpn-interworking@ietf.org" , "bess@ietf.org" , "Voyer, Daniel" , "Bernier, Daniel" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bbess=5D_Re=3A_Short_new_WGLC_and_IPR_poll_for_draft-ietf-bess-e?= =?utf-8?q?vpn-ipvpn-interworking-12?= List-Id: BGP-Enabled ServiceS working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000000845c062ce6c733 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jorge Responses in-line Thanks Gyan On Wed, Jan 29, 2025 at 8:28 AM Jorge Rabadan (Nokia) < jorge.rabadan@nokia.com> wrote: > Hi Gyan, > > Thanks for reviewing the draft. > Please see my comments in-line. > > From: Gyan Mishra > Date: Tuesday, January 28, 2025 at 9:02=E2=80=AFPM > To: Stephane Litkowski (slitkows) > Cc: draft-ietf-bess-evpn-ipvpn-interworking@ietf.org < > draft-ietf-bess-evpn-ipvpn-interworking@ietf.org>, bess@ietf.org < > bess@ietf.org>, Voyer, Daniel , Bernier, Daniel < > daniel.bernier@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=E2=80=99t think the draft needs to d= iscuss any > underlay aspects. If you think the scope should clarify that the procedur= es > are independent of the underlay, we can do it in the introduction.* > Gyan> yes please clarify in the introduction why the procedures are independent of the underlay and why. There are a variety of different underlays and depending on the underlay type the solution maybe completely different as it would require a special gateway / IW feature specific to the two underlays that need to communicate with some type of translation. Also the underlay protocol maybe a mismatch IPv4 on one side and IPv6 on the other and that poses a another problem. In my initial email I mentioned inter-as opt-a because it is plain IP back to back VRF and the underlay transport IW is taken out of the picture and only service IW is dealt with and it works seamlessly and is thus underlay independent. > Example of draft for MPLS/SR-MPLS to SRv6 GW/IW uses a GW for transport translation interworking & service interworking. This is just one draft but their are many drafts on interworking between technologies and both transport and service interworking concepts. https://datatracker.ietf.org/doc/html/draft-agrawal-spring-srv6-mpls-interw= orking-15 > 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 limite= d > to an Autonomous System or an IGP instance. The PEs in a domain can all b= e > part of the same or different Autonomous System, and an Autonomous System > can also contain multiple domains.* > > *So it is independent of the underlay =E2=80=9Cdomains=E2=80=9D. * > Domain is not the same think as underlay. Domain is very generic. When I say underlay I am talking about the technology used in the underlay that may require some sort of translation or gateway interworking at the transport underlay level. Along the same lines for any technology their is transport interworking which is for the underlay technology and service interworking which is the overlay. > > 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 mayb= e > but the draft does not talk about it at all. > *[jorge] Not sure what you mean by =E2=80=9Cfrom ISF to SAFI 128=E2=80=9D= . SAFI 128 routes > are deined as ISF routes too in the document. Also if by =E2=80=9CRT=E2= =80=9D you mean > route targets, sections 5 and 8 describe how route targets are treated wh= en > routes are readvertised into the adjacent domain. * > Gyan> Sorry I should be more by ISF I meant L2 VPN EVPN and SAFI 128 I meant IP VPN. Yes by RT I mean route target. So in a composite domain the tenant VRFs are advertised in both EVPN & IP VPN and so they have identical set of prefixes. I would think the difference would be EVPN has MAC VRF RT-2 so not identical but would be preferred due to longer matches. In figure 9 it=E2=80=99s not clear is PE1 have EVPN and IPVPN peer to IPVPN? I= did not think that was possible? In section 8 figure 8 the gateway device has a safi-x peer and a safi-y peer and is able to propagate the prefixes from any of the 4 NLRI let=E2=80=99s say safi-x is RT-2 / RT-5 and safi-y is IPV= PN. How is that possible as the SAFI are different I would not think the safi-x routes would automatically propagate to safi-y and vice versa. Am I missing something.. > > I think this is critical to the progression of the draft. > > My recommendation is to rename the draft to =E2=80=9CEVPN to IPVPN IW wi= th > D-PATH=E2=80=9D 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 inte= r > 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=E2=80=99t touch e= ach 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=E2=80=99t require any sp= ecial > 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=E2=80=99m 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 =E2=80=9Ca".* > Gyan> yes this example is subinterfaces and not tunnels in my opt-a example. Since this draft is talking about the all the permutations and details of service interworking and transport independence I wonder if it would be possible to include as it does not require any gateway feature and the routes get propagated between domains. > > 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 th= e > 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 unica= st > 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. * > Gyan> Agreed. I did please see my comments on 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 suffice= s. > > *[jorge] this spec is about ISF routes, that is, Inter Subnet Forwarding > routes, and not layer-2 information. For EVPN that includes routes that a= re > processed in the context of an IP-VRF route table, which includes IP Pref= ix > routes and MAC/IP routes when processed as in RFC9135 symmetric IRB model= . > That=E2=80=99s because both types are used for inter subnet forwarding in= EVPN > networks. Please let me know if I=E2=80=99m missing something.* > *Thank you.* > *Jorge* > Gyan> Understood. I was excluding the RT-2 for summarization with RT-5 only advertised inter domain but agreed for consistency the RT-2 should be included. > > Using this solution it=E2=80=99s 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) 40cisco.com@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 w= ith >> 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 docume= nt >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> >> >> >> >> Thank you >> >> >> >> Brgds, >> >> >> >> >> >> Stephane, Matthew, Jeffrey (BESS chairs) >> >> >> >> >> >> >> _______________________________________________ >> BESS mailing list -- bess@ietf.org >> To unsubscribe send an email to bess-leave@ietf.org >> > --00000000000000845c062ce6c733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Jorge=C2=A0
<= br>
Responses in-line=C2=A0
<= br>
Thanks=C2=A0

Gyan


<= /div>


On Wed, Jan 29, = 2025 at 8:28 AM Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com> wrote:
Hi Gyan,

Thanks for reviewing the draft.
Please see my comments in-line.

From: Gyan Mishra= <hayabusagsm@gmail.com>
Date: Tuesday, Ja= nuary 28, 2025 at 9:02=E2=80=AFPM
To: Stephane Litk= owski (slitkows) <slitkows=3D40cisco.com@dmarc.ietf.org= >
Cc: draft-ietf-bess-evpn-ipvpn-interworking@ietf.org<= /a> <draft-ietf-bess-evpn-ipvpn-i= nterworking@ietf.org>, bess@ietf.org <bess@ietf.org>, Voyer, Daniel <daniel.voyer@bell.ca>, Bernier,= Daniel <daniel.bernier@bell.ca>
Subject: Re: [bes= s] Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-= 12

=C2=A0
CAUTION:= This is an external = email. Please be very careful when clicking links or opening attachments. S= ee the URL nok.it/ext for additional information.

=C2=A0


=C2=A0I support progressing this draft with some slight modifications below= .

I have a very important addition to the draft that I think is pertinent tha= t 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 whic= h is very important.
[jorge]=C2=A0the proce= dures we're outlining are independent of the underlying infrastructure = in each domain. I don=E2=80=99t think the draft needs to discuss any underl= ay aspects. If you think the scope should clarify that the procedures are i= ndependent of the underlay, we can do it in the introduction.

=C2=A0 =C2=A0 Gyan> yes please cl= arify in the introduction why the procedures are independent of the underla= y and why.

There are a v= ariety of different underlays and depending on the underlay type the soluti= on maybe completely different as it would require a special gateway / IW fe= ature specific to the two underlays that need to communicate with some type= of translation.=C2=A0 Also the underlay protocol maybe a mismatch IPv4 on = one side and IPv6 on the other and that poses a another problem.=C2=A0 In m= y initial email I mentioned inter-as opt-a because it is plain IP back to b= ack VRF and the underlay transport IW is taken out of the picture and only = service IW is dealt with and it works seamlessly and is thus underlay indep= endent.

Example of draft for MPL= S/SR-MPLS to SRv6 GW/IW uses a GW for transport translation interworking=C2= =A0
& service interworking. This is just one dra= ft but their are many drafts on interworking between technologies and both = transport and service interworking concepts.



The draft does not talk about intra-domain scenario within a NVO VXLAN or M= PLS / SR-MPLS / SRv6 fabric.=C2=A0
[jorge] the document d= efines a domain as follows:
Domain: Two PEs are in= the same domain if they are attached to the same tenant and the packets be= tween them do not require a data path IP lookup (in the tenant space) in an= y intermediate router. A gateway PE is always configured with multiple DOMA= IN-IDs. The domain boundaries are not limited to an Autonomous System or an IGP in= stance. The PEs in a domain can all be part of the same or different Autono= mous System, and an Autonomous System can also contain multiple domains.
So it is independent o= f the underlay =E2=80=9Cdomains=E2=80=9D.=C2=A0

=C2=A0 =C2=A0 Domain is not the same= think as underlay.=C2=A0 Domain is very generic.=C2=A0 When I say underlay= I am talking about the technology used in the underlay that may require so= me sort of translation or gateway interworking at the transport underlay le= vel.=C2=A0 Along the same lines for any technology their is transport inter= working which is for the underlay technology and service interworking which= is the overlay.

Also this draft talks mostly all about the new D-PATH path attribute but do= es not talk about any details of the gateway function going from ISF to SAF= I 128 and how that would work.=C2=A0 Is the RT reoriginated at the domain b= oundary as the other type of SAFI in either direction I am guessing maybe but the draft does not talk about it = at all. =C2=A0
[jorge] Not sure what you= mean by =E2=80=9Cfrom ISF to SAFI 128=E2=80=9D. SAFI 128 routes are deined= as ISF routes too in the document. Also if by =E2=80=9CRT=E2=80=9D you mea= n route targets, sections 5 and 8 describe how route targets are treated when routes are readvertised into the adjacent domain.=C2=A0

=C2=A0 =C2=A0 Gyan> Sorr= y I should be more by ISF I meant L2 VPN EVPN and SAFI 128 I meant IP VPN.= =C2=A0 Yes by RT I mean route target.=C2=A0 So in a composite domain the te= nant VRFs are advertised in both EVPN & IP VPN and so they have identic= al set of prefixes.=C2=A0 I would think the difference would be EVPN has MA= C VRF RT-2 so not identical but would be preferred due to longer matches. I= n figure 9 it=E2=80=99s not clear is PE1 have EVPN and IPVPN peer to IPVPN?= I did not think that was possible?=C2=A0 In section 8 figure 8 the gateway= device has a safi-x peer and a safi-y peer and is able to propagate the pr= efixes from any of the 4 NLRI let=E2=80=99s say safi-x is RT-2 / RT-5 and s= afi-y is IPVPN.=C2=A0 How is that possible as the SAFI are different I woul= d not think the safi-x routes would automatically propagate to safi-y and v= ice versa.=C2=A0 Am I missing something..
=

I think this is critical to the progression of the draft. =C2=A0

My recommendation is to rename the draft to =E2=80=9CEVPN to IPVPN =C2=A0IW= with D-PATH=E2=80=9D 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 attribut= e propagation, route selection across ISF routes, composite and gateway pro= cedures, error handling, etc.

In the context of IPVPN & EVPN interaction and ISF and SAFI 128 there i= s 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=C2=A0=C2=A0of L2 & L3 NLRI successfully a= cross domain boundaries and within a domain a translation gateway.

In most all cases generally the composite PE, composite domain works seamle= ssly no issues as two ships in the night that don=E2=80=99t touch each othe= r.=C2=A0

The complexity and possible loops that D-PATH solves the Gateway scenario.<= /div>

A typical method which is very commonly done for eBGP peering =C2=A0to prop= agate EVPN RT-5 prefixes to IP VPN.=C2=A0 One end of eBGP peering is NVO VX= LAN/GENEVE ASBR (CE) and other end is MPLS IP VPN SAFI 128 PE.=C2=A0 The pe= ering is inter-as opt-a back to back VRF IPv4 Unicast and IPv6 unicast peering. This works extremely well and both ends can be p= retty much any kind of underlay data plane mismatch and you don=E2=80=99t r= equire any special gateway transport or service interworking in the case of= any of the following:

MPLS / SR-MPLS to SRv6. =C2=A0
MPLS / SR-MPLS to VXLAN
SRv6 to VXLAN

Stick diagram (eBGP)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Inter-as opt-a

If the underlay =C2=A0on core & dc is the same then you still have to u= se inter-as opt-a

ASBR (DC EVPN) <-> PE (Core IP VPN)
[jorge] I=E2=80=99m not s= ure if I follow. RFC4364 section 10 option a is IP-VRF to IP-VRF connectivi= ty via subinterfaces, not tunnels. This spec does not introduce any procedu= res for option =E2=80=9Ca".
<= /div>

=C2=A0 =C2=A0 Gyan> yes this example is subinterfaces and not tun= nels in my opt-a example.=C2=A0 Since this draft is talking about the all t= he permutations and details of service interworking and transport independe= nce I wonder if it would be possible to include as it does not require any = gateway feature and the routes get propagated between domains.

If you have underlay =C2=A0mismatch then there is also IW/GW transport or ser= vice interworking=C2=A0

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 so= lved by NVO VXLAN/GENEVE EVPN =C2=A0on one end iBGP to =C2=A0PE with IP VPN= SAFI 128 PE.=C2=A0 The EVPN leaf-1 =C2=A0advertises the routes IPv4 unicast / IPv6 unicast routes RT-5 prefixes to an intermed= iate router (GW) PE SAFI 128 -> VPNv4 / VPNv6 (RR) -> propagates VPNv= 4/VPNv6 to rest of fabric.=C2=A0

Stick diagram (iBGP)

leaf-1 <-> GW <-> (RR) <-> rest of fabric=C2=A0
[jorge] this falls und= er the gateway procedures in the draft. Please check out section 8. =C2=A0<= /b>

=C2=A0 =C2=A0 Gyan> Agreed.=C2= =A0 I did please see my comments on section 8.=C2=A0
=

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 pref= ixes and not the MAC VRF RT-2 host routes so the RT-5 summary suffices. =C2= =A0=C2=A0
[jorge] this spec is a= bout ISF routes, that is, Inter Subnet Forwarding routes, and not layer-2 i= nformation. 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 route= s when processed as in RFC9135 symmetric IRB model.=C2=A0 That=E2=80=99s because = both types are used for inter subnet forwarding in EVPN networks. Please le= t me know if I=E2=80=99m missing something.
Thank you.
<= div>
Jorge

=C2=A0 =C2=A0 Gyan> Understood.= =C2=A0 I was excluding the RT-2 for summarization with RT-5 only advertised= inter domain but agreed for consistency the RT-2 should be included.
=
<= br>
Using this solution it=E2=80=99s 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 Steph= ane Litkowski (slitkows) <slitkows=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,

=C2=A0

As draft-ietf-bess-evpn-ipvpn-interworking went thro= ugh 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 fo= rward with the draft.

=C2=A0

The WGLC poll starts today and will end on 2/3.

=C2=A0

Similarly, as the last IPR poll was done a long time= back. We are also polling for knowledge of any undisclosed IPR that applie= s to this document (see RFCs 3979, 4879, 3669 and 5378 for more details).

=C2=A0

=C2=A0

Thank you

=C2=A0

Brgds,

=C2=A0

=C2=A0

Stephane, Matthew, Jeffrey (BESS chairs)

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
BESS mailing list -- bes= s@ietf.org
To unsubscribe send an email to bess-leave@ietf.org
--00000000000000845c062ce6c733--