Sasha, Thanks for all these very detailed questions. In addition to what Jorge mentioned, I want to add an additional note - all of it is solely extracted from RFC9136
- As per RFC9136 section 4.4, there are three IP-VRF-to-IP-VRF Model. - Interface-less (4.4.1) allows the selection of Ethernet NVO or IP NVO Tunnel; depending on the encapsulation you will have a inner-MAC or inner-IP header. - The two interface-ful models (4.4.2 and 4.4.3) are always operating in Ethernet NVO, meaning there is always a inner-MAC header given you operate with a MAC recursion. - The overlay index use-case in section 4 are exclusively for the interface-ful models while the IP Aliasing are independent of the same @Jorge, please keep me honest if I misstated anything. Thanks -Lukas > On Jul 11, 2023, at 2:06 PM, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > wrote: > > Hi Sasha, > In-line too. > Thanks. > Jorge > From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> > Date: Tuesday, July 11, 2023 at 9:27 AM > To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > Cc: bess@ietf.org <bess@ietf.org>, > draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org > <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> > Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft > 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. > > Jorge, > Lots of thanks for your response. > Please see more comments inline below. > Regards, > Sasha > From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > Sent: Tuesday, July 11, 2023 6:35 PM > To: Alexander Vainshtein <alexander.vainsht...@rbbn.com> > Cc: bess@ietf.org; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org > Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing > draft > Hi Sasha, > Let me try to reply to your questions: > How can a PE that receives an EVPN Type 1 route decide whether it is a > per-EVI Ethernet A-D route or a per-EVI IP A-D route? > [jorge] The IP A-D per EVI route carries a route target of an IP-VRF. > [[Sasha]] Yes, I have assumed the same. But what is supposed to happen if an > A-D per-EVI route carries RTs that match both some IP-=VRF and some MAC-VRF > in the receiving PE? Should such a route be simply treated as an error (and, > if yes, what would be the action on it), or should one of the two > possibilities given priority? Such a route clearly could not be installed in > both places. > [jorge] I don’t think we need to specify that in the draft, in the same way > we never specified how to import routes with a single label if they come with > multiple route targets and they match different MAC-VRFs and IP-VRFs. Clearly > if the advertising PE does as specified, it will send different routes for > ESIs in MAC-VRFs or in IP-VRFs. So what you are describing is a non-expected > scenario. Even so, the receiving PE could potentially import it in two places > (I don’t see why not), but the route would be of no use in one of the VRFs > unless you received also the proper MAC/IP routes and IP Prefix routes with > the same ESI. > 2. “The draft defines, without going into details, quite a different > procedure for recursive resolution of such routes that uses per EVI IP A-D > routes introduced in the draft. This procedure inherently assumes that > inter-subnet traffic is carried between the PEs as IP-VPN traffic (i.e., > without inner L2 encapsulation). > My question is: How can the PE that receives an EVPN IP Prefix routes with a > non-reserved ESI value decide which of these two procedures it should apply > to each specific route?” > [jorge] As discussed, for IP Prefix routes, the draft extends RFC9136 > section 4.4.1 (we added some text about it) to support the resolution of IP > Prefix routes to IP A-D routes. - RFC9136 section 4.4.1 supports both > Ethernet NVO tunnels and IP NVO tunnels (see the terminology section in > RFC9136). That is, both inner L2 or L3 encapsulation. > - If an implementation receives an IP Prefix route with a non-reserved ESI > value that is imported in an IP-VRF, the procedures in the draft are > followed, irrespective of whether the PEs use Ethernet NVO or IP NVO tunnels. > The route resolution is described in 5.3.1. > - By the way, the recursive resolution is compatible with RFC9136. See > table 1, first two top rows: > +==========+==========+==========+============+===============+ > | ESI | GW IP | MAC* | Label | Overlay Index | > +==========+==========+==========+============+===============+ > | Non-Zero | Zero | Zero | Don't Care | ESI | > +----------+----------+----------+------------+---------------+ > | Non-Zero | Zero | Non-Zero | Don't Care | ESI | > +----------+----------+----------+------------+---------------+ > [[Sasha]] Unfortunately, it doesn’t, it seems that my original question has > been presented clearly enough. > My scope of interest is EVPN over an IP/MPLS core, i.e., I am only discussing > only MPLS tunnels. > My understanding of the interface-less IP-VRF-to-IP-VRF model as described in > 9136 is that it does not imply recursive resolution and inter-subnet traffic > crosses the core as pure IP over MPLS (i.e., the customer IP header > immediately follows the bottom of the label stack). This is fully aligned > with the mechanism used with Symmetric IRB as defined in Section 5.4 of RFC > 9135 that says: “If the tunnel type is that of an MPLS or IP-only NVO tunnel, > then the TS's IP packet is sent over the tunnel without any Ethernet header.” > I assume that your modified model does not change the way customer > inter-subnet traffic is carried across the IP/NMPLS core (you’ve mentioned > that the modified model still does not use SBD). > At the same time, all the scenarios in RFC 9136 that use recursive > resolution imply insertion of an “inner Ethernet header” between the bottom > of the label stack and the customer IP header, and the difference between > these methods is about the way Destination MAC address of this inner Ethernet > header is obtained (from the suitable RT-2, from the Router MAC Extended > Community or by a local policy). This matches my understanding of Asymmetric > IRB as defined in Section 6.3 of RFC 9135: “The ingress PE gets the > destination TS's MAC address for that TS's IP address from its ARP table or > NDP cache. It encapsulates the packet with that destination MAC address and a > source MAC address corresponding to that IRB interface and sends the packet > to its destination subnet MAC-VRF/BT. The destination MAC address lookup in > the MAC-VRF/BT results in a BGP next-hop address of the egress PE along with > label1 (L2 VPN MPLS label or VNI).” > With RFC 9136, the PE that receives an IP Prefix Route can decide whether > its handling by the data plane does or does not involve inclusion of the > “inner L2 header: recursive resolution always implies inner L2 header, if it > is not used, no inner L2 header is needed. > [jorge] Maybe this is the disconnect. RFC9136 is not really mandating that > “recursive resolution” or “overlay index != None” means inner Ethernet > header. Section 3.2 does not specify that at all. So you could receive an IP > Prefix route with the format of the first row in table 1 in your MPLS case, > and based on RFC9136 the route uses the ESI as overlay index, hence it needs > an A-D per EVI route for resolution. > If either the ESI or the GW IP are non-zero, then the non-zero one > is the Overlay Index, regardless of whether the EVPN Router's MAC > Extended Community is present or the value of the label. > Now, while RFC9136 allows the ESI as overlay index with IP NVO encaps (e.g. > MPLS with ip payload), there was not a use-case for it. Hence the ip-aliasing > draft section 1.3 and the text we added (that I thought it addressed your > comments): > > Note that this document modifies [RFC9136] section 4.4.1 (Interface- > less IP-VRF-to-IP-VRF Model) by allowing a non-zero Ethernet Segment > Identifier value on EVPN IP Prefix routes and the recursive > resolution of the ESI to EVPN A-D per EVI routes. > > Your modification breaks this simple rule: data plane handling of a received > and installed an RT-5 with a non-reserved ESI value in its NLRI sometimes > requires usage of inner L2 header (old scenarios from RFC 9136) and sometimes > does not require it (in the new scenario defined in the draft). > [jorge] it does not break the rule, please see above. > My question was: How can the receiving PE differentiate between these two > cases? > [jorge] in both cases an IP Prefix route is received for the IP-VRF with > non-reserved ESI. Then: > - In both cases this means the overlay index is the ESI hence recursive > resolution is needed. > - In the ip aliasing draft, the PE finds a set of IP A-D per EVI routes > imported in the IP-VRF. And these are the routes used for the resolution to > MPLS tunnels > - In RFC9136 section 4.3, the PE finds a set of A-D per EVI routes imported > in the MAC-VRF connected via IRB to the IP-VRF where the prefix is installed > If the RT attached to the received IP Prefix route with a non-reserved ESI > value matches a MAC-VRF in the receiving PE, inner L2 header is required, and > if it matches an IP-VRF, inner L2 header is not required. If this is indeed > the intention, then handling of the case when one of the RTs attached to this > route matches a MAC-VRF while another matches an IP-VRF should be explicitly > defined. > What, if anything, did I miss? > [jorge] That is really not the intention. If the A-D per EVI route is > imported in a MAC-VRF, the encapsulation is indeed Ethernet NVO. If imported > in an IP-VRF, the encapsulation may be Ethernet (e.g., vxlan) or IP NVO > (e.g., mpls). Note that the IP A-D per EVI route carries the BGP > encapsulation extended community. > IMHO I don’t think we need to say much more, but if you still think we > should, please let us know what kind of text would help. > Let me know if it helps. > Thanks. > Jorge > From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> > Date: Sunday, July 9, 2023 at 9:54 AM > To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > Cc: bess@ietf.org <bess@ietf.org>, > draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org > <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> > Subject: Re: RE: Question and comments on the EVPN IP Aliasing draft > 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. > > Jorge and all, > More of the same: > How can a PE that receives an EVPN Type 1 route decide whether it is a > per-EVI Ethernet A-D route or a per-EVI IP A-D route? > My 2c, > Sasha > Get Outlook for Android > From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> > Sent: Sunday, July 9, 2023 12:57:00 PM > To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > Cc: bess@ietf.org <bess@ietf.org>; > draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org > <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> > Subject: RE: Question and comments on the EVPN IP Aliasing draft > Jorge, > Lots of thanks for the new revision, it addresses the majority of my comments. > I still have some doubts about co-existence of the “old” (as in RFC 9136 > Section 4.4.1) and “new” interface-less IP-VRF-to-IP-VRF models. > Specifically: > 1. Section 4.3 of RFC 9136 provides a detailed procedure for recursive > resolution of received EVPN IP Prefix routes with a non-reserved ESI value in > their NLRI. To the best of my understanding, this procedure inherently > assumes that inter-subnet traffic is carried between the PEs as EVPN traffic > (i.e., with inner L2 encapsulation). This procedure uses the Router MAC > Extended Community, or, in the case of its absence, a local policy for > determination of the Destination MAC address in the inner L2 encapsulation/ > 2. The draft defines, without going into details, quite a different > procedure for recursive resolution of such routes that uses per EVI IP A-D > routes introduced in the draft. This procedure inherently assumes that > inter-subnet traffic is carried between the PEs as IP-VPN traffic (i.e., > without inner L2 encapsulation). > My question is: How can the PE that receives an EVPN IP Prefix routes with a > non-reserved ESI value decide which of these two procedures it should apply > to each specific route? > I think that the draft should provide an unambiguous answer to this > question. > Regards, > Sasha > From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > Sent: Thursday, July 6, 2023 9:23 PM > To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; > draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org > Cc: bess@ietf.org > Subject: [EXTERNAL] Re: Question and comments on the EVPN IP Aliasing draft > Sasha, > We just published version 07 of the EVPN IP Aliasing draft, and tried to > address your comments in this thread. Let us know if you have further > comments. > Thank you! > Jorge > From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > Date: Tuesday, April 4, 2023 at 5:09 PM > To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>, > draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org > <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> > Cc: bess@ietf.org <bess@ietf.org> > Subject: Re: Question and comments on the EVPN IP Aliasing draft > Hi Sasha, > I can work on some clarifications in the text based on your feedback. > About whether the draft updates RFC9136, I’m hesitant to add it to the > header, since this spec is obviously optional. > Thanks. > Jorge > From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> > Date: Monday, April 3, 2023 at 5:51 AM > To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, > draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org > <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> > Cc: bess@ietf.org <bess@ietf.org> > Subject: RE: Question and comments on the EVPN IP Aliasing draft > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See > https://clicktime.symantec.com/15siFAdRxjC6ZR12VsdcD?h=9dKjeFiIGxpBYd94GifyAUHFA2O22JVj1NliypFJLQk=&u=http://nok.it/ext > for additional information. > > Hi Jorge, > Lots of thanks for a prompt response. > I have explained my position with regard to IP Aliasing for RT-5 in > Interface-less IP-VRF-to-IP-VRF model in my previous email. > I only can add that the neither the metadata of the IP Aliasing draft nor its > text specify an update to RFC 9136. > Regards, > Sasha > From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > Sent: Monday, April 3, 2023 4:17 AM > To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; > draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org > Cc: bess@ietf.org; Dmitry Valdman <dmitry.vald...@rbbn.com>; Nitsan Dolev > <nitsan.do...@rbbn.com>; Michael Gorokhovsky <michael.gorokhov...@rbbn.com>; > Ron Sdayoor <ron.sday...@rbbn.com>; Egon Haparnass <ehaparn...@rbbn.com>; > Shell Nakash <shell.nak...@rbbn.com>; Marina Fizgeer > <marina.fizg...@rbbn.com>; Orly Kariv <orly.ka...@rbbn.com>; Moti Morgenstern > <moti.morgenst...@rbbn.com>; Rotem Cohen <rotem.co...@rbbn.com> > Subject: [EXTERNAL] Re: Question and comments on the EVPN IP Aliasing draft > Hi Sasha, > Please see in-line with [jorge]. > Thanks for the good questions/points. > Jorge > From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> > Date: Sunday, March 26, 2023 at 11:16 PM > To: draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org > <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> > Cc: bess@ietf.org <bess@ietf.org>, Dmitry Valdman <dmitry.vald...@rbbn.com>, > Nitsan Dolev <nitsan.do...@rbbn.com>, Michael Gorokhovsky > <michael.gorokhov...@rbbn.com>, Ron Sdayoor <ron.sday...@rbbn.com>, Egon > Haparnass <ehaparn...@rbbn.com>, Shell Nakash <shell.nak...@rbbn.com>, Marina > Fizgeer <marina.fizg...@rbbn.com>, Orly Kariv <orly.ka...@rbbn.com>, Moti > Morgenstern <moti.morgenst...@rbbn.com>, Rotem Cohen <rotem.co...@rbbn.com> > Subject: Question and comments on the EVPN IP Aliasing draft > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See > https://clicktime.symantec.com/15t5Zsu7ZPvvXHNzW589B?h=3ceHKr8YVLM3UOko-NyIuMmvVO2HwRp1fi1RLBdLkNo=&u=http://nok.it/ext > for additional information. > > Hi all, > A few questions and comments on the EVPN IP Aliasing draft: > Section 3 of the draft states that a PE that is attached to a MH ES shall > advertise a set of IP per ES A-D routes, and Section 4.1 says that these > routes shall be tagged with Export RTs of all IP-VRFs attached to this MH ES. > The following is not mentioned: > Should the ESI Label Extended Community be attached to these routes? My guess > (FWIW) is that this is necessary, since this is the only way to let the > remote PEs to know the MH mode of the MH ES in question. > [jorge] correct > Assuming an affirmative answer to the previous question, what should the ESI > Label Extended Community attached to these routes carry in its Label field? > My guess (FWIW) is that his field is not relevant and should be set to all > zeroes. > [jorge] yes. We can add a sentence to that respect. The label field SHOULD be > set to 0 and MUST be ignored on reception. > Section 3 of the draft says that “a remote PE that receives an EVPN MAC/IP > Advertisement route or an IP Prefix route with a non-reserved ESI and the RT > of a particular IP-VRF SHOULD consider it reachable by every PE that has > advertised an IP A-D per ES and IP A-D per EVI route for that ESI and IP-VRF”: > Is the statement above applicable in the case of a MH ES in Single-Active MH > Mode? My guess is that it is only applicable to MH Es in All-Active MH mode > [jorge] same as in rfc7432bis, both modes > If the answer to the previous question is negative, should the PE that > receives an EVPN Type 2 route for an IP→MAC pair treat the IP address in this > pair reachable only via he PE that has advertised this route and treating > other PEs as “backup PEs” (similar to what is defined in Section 14.1.1 of > RFC 7432)? > [jorge] yes, assuming that PE the has received the AD routes. > The suggestion to attach the Layer 2 Attributes Extended Community to the per > EVI IP A-D route in Section 3.1 of the draft seems to support my guesses above > I also think that if the MH ES in Single-Active mode is attached o more than > 2 PEs, the Layer 2 Attributes Extended Community MUST be attached to EVPN per > EVI IP A-D routes. > [jorge] at the moment the addition of the L2 Attr ext community is a SHOULD. > I have no problem in making it a MUST assuming my co-authors are ok. > I have to admit that I do not understand how IP Aliasing should work for EVPN > IP Prefix routes in the Interface-less IP-VRF-to-IP-VRF scenario mentioned in > Section 1.2 of he draft: > Table 1 in RFC 9136 states that a non-zero ESI value in the NLRI of IP Prefix > routes is used as an Overlay index for recursive resolution, while that the > Label value in such a NLRI is “Don’t Care”. > At the same time, section 4.1.1 of this RFC states that the ESI field of the > NLRI f these routes is set to all zeroes in the Interface-less > IP-VRF-to-IP-VRF scenario while the Label field in the NRLI of these routes > identifies the IP VRF in question. > Can you please explain how can, in this scenario, the receiving PE associate > received EVPN IP Prefix routes with a specific MH ES? > [jorge] section 1.2 illustrates an RFC9136 interface-less model since there > is no SBD. However, this draft modifies the interface-less model by using > non-zero ESI on the IP Prefix routes and a recursive resolution to A-D per > ES/EVI routes. > Your timely feedback would be highly appreciated. > Regards, and lots of hanks in advance, > Sasha > > Notice: This e-mail together with any attachments may contain information of > Ribbon Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without express > permission is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately and then delete all copies, including > any attachments. > > Notice: This e-mail together with any attachments may contain information of > Ribbon Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without express > permission is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately and then delete all copies, including > any attachments. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
