Hi Jorge Please see in-line
<http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347* On Fri, Jan 31, 2025 at 11:16 AM Jorge Rabadan (Nokia) < jorge.raba...@nokia.com> wrote: > Hi Gyan, > > > > Please see in-line. > > > > > > *From: *Gyan Mishra <hayabusa...@gmail.com> > *Date: *Thursday, January 30, 2025 at 11:19 PM > *To: *Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > *Cc: *Stephane Litkowski (slitkows) <slitkows=40cisco....@dmarc.ietf.org>, > draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org < > draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org>, bess@ietf.org < > bess@ietf.org>, 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. > > > > Hi Jorge > > > > Responses in-line > > > > On Thu, Jan 30, 2025 at 8:02 AM Jorge Rabadan (Nokia) < > jorge.raba...@nokia.com> wrote: > > Hi Gyan, > > > > Thank you for your comments. > > I added this text at the end of the introduction section: > > > > "The interworking procedures in this document always require creating an > IP-VRF on the interworking PE. When connecting different domains, the > interworking PE follows these steps: it receives routes from one domain > (along with that domain’s encapsulation parameters), installs them in the > IP-VRF route table, and then reoriginates the routes with the encapsulation > parameters of the adjacent domain before advertising them. This > reorigination process ensures that the procedures remain independent of the > specific transport tunnels used in each domain.” > > > > I hope it helps. > > > > Gyan> I want to make sure I understand the reorigination with the > gateway function see below: > > > > So this solution is definitely service interworking with the reorigination > which makes it underlay protocol independent. Please mention service > interworking and transport protocol independence > > *[jorge] Since the procedures mention IP-VPN and EVPN AFI-SAFIs, I think > it is clear that the procedures happen in the context of a VRF, i.e. a > service. But sure, no issue in adding “service interworking” to the > clarification text.* > Gyan> Thank you > > > > > In a composite domain or PE, IPVPN and EVPN must have different VRF as the > different SAFI cannot share the same VRF. > > *[jorge] Gyan, I have to say that is not true. In our implementations and > a few others, IP-VRFs support multiple intersubnet forwarding families in > the same IP-VRF. IPVPN and EVPN (L3) can definitively use the same IP-VRF. > As described in the text, the IP-VRF in figure 1 can be programmed with ISF > routes of different types at the same.* > > Gyan> I was not sure and was thinking that using a different VRF would be > a way to identify an IPVPN peer from EVPN peer, and the reorigination of > the routes, however I see now EVPN (L3) can be the same VRF as IPVPN as > you said. I was thinking L2/L3 but as this is L3 for both SAFI, as ISF > routes can be different route types. Agreed. > > GW > > IPVPN = VRF IPVPN > > EVPN = VRF EVPN > > > > Domain 1 Domain 2 > > VXLAN SRv6 > > R1 - EVPN - GW - PE1 EVPN / IPVPN > > > > GW receives the EVPN routes on EVPN peer (safi-x) and reoriginates the > routes on IPVPN peer (safi-y) > > > > So basically we are just taking the routes from safi-x EVPN peer and > reoriginating the routes on safi-y IPVPN peer. In my original examples the > unicast SAFI on both ends of peering does not require any reorigination > since it’s the same safi. However here we are taking the NLRI and > translating the SAFI from EVPN to IPVPN. So in that case all the RT-2 mac > VRF host routes and RT-5 prefix would all get propagated out to PE1 as > IPVPN routes using the new RT/RD defined for the IPVPN VRF. Same would > happen in the opposite direction. The gateway is configured with > encapsulation for vxlan domain with NVE tunnnel and also has SRv6 locator > config and under VRF peer has SRv6 sid allocation mode per-VRF so it’s not > really underlay independent but underlay dependent since both left vxlan > domain underlay and right side SRv6 domain are stretched to the GW which is > siting on both transports. So in that way it’s doing transport > interworking by butting up the two adjacent domain types to the GW box. In > the case GW box is the VXLAN DCI or ASBR and so sits on the VXLAN side > already so only have to extend the SRv6 domain over to the GW box on the > right side. > > *[jorge] it is independent of the underlay in the sense that importing > routes with certain encapsulation parameters and exporting routes with > certain encapsulation parameters is something specified in other specs and > this one does not change anything about that termination/origination. For > instance, import/export of EVPN VXLAN routes is specified in RFC8365, IPVPN > or EVPN for SRv6 routes is specified in RFC9252 (and so forth)* > Gyan> Since on the Gateway the link to safi-x on left has the left domain encapsulation parameters and the link to safi-y on right has left domain different encapsulation parameters so by doing so I can see the underlay does not come into play making it underly independent. I’m in agreement. > > > > > Please let me know if I got it right. > > > > I modified the paragraph slightly based on my understanding. Figure 8 is > a bit confusing for GW diagram. I would think the GW box since it sits in > the DC side and is the EVPN Denmark PE to the core it should have EVPN > MAC-VRF like Figure 7 being a composite PE. The diagram shows the NVO > tunnels on PE1 and PE2 and the stretched MPLS tunnels to the gateway which > is perfect for the transport interworking. The point I am making about > gateway placement is important as it would always sit on the DC side and > connect to the core PE. You may have to redraw a bit the diagrams so they > all match up. > > Since you have 2 DC one on left and one on right with core in the middle > we are missing a few routers. > > I would make PE1-4 core boxes. I would give different names for DC side > call it leaf for very left and right PE device and add a single GW PE on > left and right side that connects to PE5 and PE1 and PE2. On the right > side GW PE that sits between PE3 PE4 and PE6. We can clean up figure 9 to > also have the clear core & dc demark. The device that connects to the > gateway PE in the DC call if a leaf. > > *[jorge] I believe Figure 8 accurately represents the example we want to > illustrate. For a given tenant, the Gateways can have a single IP-VRF > (without a MAC-VRF) and handle IPVPN (RFC 4364) and EVPN IFL (RFC 9136) > routes within that IP-VRF* > > Gyan> I see now it does since it’s EVPN (L3) and both IPVPN and EVPN > share the same VRF so the drawing illustrates correctly showing all nodes > having IP-VRF. > > > > > > I would label core & dc so you know the demark point for each domain. That > way it matches as well the paragraph below. > > > "The interworking gateway procedures in this document always require > creating an IP-VRF on the gateway PE. When connecting to the core > domains, the gateway PE follows these steps: it receives routes from dc > domain (along with that domain’s dc underlay encapsulation parameters), > installs them in the MAC-VRF route table, and then reoriginates the routes > with the core underlay encapsulation parameters before advertising them to > core PE. This reorigination process as it happens on the core IPVPN peers > with the underlay encapsulation to core PE, it provides the transport > interworking congruence dependency on the specific transport tunnel type by > extending that transport tunnel to the gateway. > > *[jorge] The issue with your text is that core and dc domains are only one > very specific example. This spec covers interworking in any type of > network. Also, as discussed there is no MAC-VRF involved in the procedures > for ISF routes. How about:* > > > *“The interworking procedures in this document always require creating an > IP-VRF on the interworking PE. When connecting different domains, the > interworking PE follows these steps: it receives routes from one domain > (along with that domain’s encapsulation parameters), installs them in the > IP-VRF route table, and then reoriginates the routes with the encapsulation > parameters of the adjacent domain before advertising them. This > reorigination process ensures that the procedures remain independent of the > specific transport tunnels used in each domain, as it functions as a > service interworking solution.”* > > Gyan> Agreed to make generic with the node naming keep as-is. Text looks > perfect!! > Excellent job with this work as it’s extremely helpful for operators for IW between mix technologies. > *Thanks!* > > *Jorge* > > > > > > > > > > About this: > > 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-interworking-15 > > > > We spoke with the authors before draft-ietf-spring-srv6-mpls-interworking > <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00#name-gateway-interworking> > was adopted by SPRING. They will add references to our document for their > section 7.2.1 Gateway Interworking, which is a high level description of > the gateway model we are specifying in our document in detail for > intersubnet forwarding. As discussed, > draft-ietf-bess-evpn-ipvpn-interworking procedures work irrespective of the > encapsulation of the domains, since there is always an IP-VRF instantiation > and the routes are reoriginated with the encapsulation parameters of the > destination domain. > > > > About this: > > 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. > > I don’t think there is anything new to specify with respect to RFC4364 > section 10 option a to guarantee interoperability, and that is not already > described. It would be good to hear from others too, in case I’m > missing something. > > > > Gyan> I understand this gateway procedures much better now and agree > nothing additional is needed. > > > > Thanks. > > Jorge > > > > > > *From: *Gyan Mishra <hayabusa...@gmail.com> > *Date: *Wednesday, January 29, 2025 at 10:46 PM > *To: *Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > *Cc: *Stephane Litkowski (slitkows) <slitkows=40cisco....@dmarc.ietf.org>, > 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. > > > > > Hi Jorge > > > > Responses in-line > > > > Thanks > > > > Gyan > > > > > > > > > > On Wed, Jan 29, 2025 at 8:28 AM Jorge Rabadan (Nokia) < > jorge.raba...@nokia.com> wrote: > > 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.* > > > > 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-interworking-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 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”. * > > > > 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 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. * > > > > 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’s 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’s say safi-x is RT-2 / RT-5 and safi-y is IPVPN. 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 “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".* > > > > 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 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. * > > > > 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 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* > > > > 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’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> 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 > To unsubscribe send an email to bess-le...@ietf.org > >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
