Hi Jorge In section 7 composite PE with congruent IPVPN & EVPN PEs at the inter domain boundary between the domains, I wanted to confirm that this is also underlay independent and hence the IPVPN and EVPN prefixes would be automatically propagated between domains without any reorigination.
The composite case applies to this draft below and so could be an alternative to draft below drafts service interworking solution. The other alternative I had come up with that I mentioned is inter-as opt-a for 7.2 service IW. Your composite PE section 7 is much better as it’s a single peer. https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00 Last question on reorigination versus readvertisement. We have the new paragraph addition which says reorigination but I don’t see anywhere in the draft saying reorigination but do see readvertising. If we are using reorigination in the paragraph then then the draft maybe wherever we say readvertising we should change reorigination to match or vice versa. I believe for service interworking there is a reorigination keyword used for GW/IW function going from safi-x to safi-y. Thanks <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:06 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > > 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
