Jorge, Again, lots of thanks for your response. I have doubts regarding your statement “the IP A-D per EVI route carries the BGP encapsulation extended community” in the context of pure EVPN-MPLS.
1. My reading of Section 5.3.1 of RFC 8365<https://www.rfc-editor.org/rfc/rfc8365.html#section-5.1.3>, nodes that support only MPLS encapsulation are not required to add this Extended Community to any EVPN routes, and the nodes that receive EVPN routes without this Extended Community attached assume MPLS encapsulation 2. Section 4.4.1 of RFC 9136 also does not require adding this Extended Community to EVPN IP Prefix routes, only mentions that it (as well as the Router’s MAC Extended Community) “may be added” 3. Last but not least, Encapsulation Extended community is not mentioned at all in Section 3.1 of the draft<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-07#section-3.1> that defines construction of IP per-EVI A-D routes. With regard to your statement “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” : I agree that this has never been specified, but, IMHO, this was not really needed, because, until now, the standards defining these routes have never allowed any alternatives. From my POV the draft creates a new situation, where, locking just at the NLRI of the EVPN Type 1 route, it is impossible to decide whether it will be installed in the FDB of a MAC-VRF/BD, or in the RIB (and FIB) of an IP-VRF. So I think some text in the draft clarifying this would be most useful. Regards, Sasha From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Sent: Tuesday, July 11, 2023 9:06 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, In-line too. Thanks. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Tuesday, July 11, 2023 at 9:27 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto: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<mailto:jorge.raba...@nokia.com>> Sent: Tuesday, July 11, 2023 6:35 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: bess@ietf.org<mailto:bess@ietf.org>; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto: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<https://clicktime.symantec.com/15t5ZtTi24XoxDagvpRXN?h=ikytnyONCwNSZuh45Yp8SCvUitBHujRvBAsUxWjMTJc=&u=https://datatracker.ietf.org/doc/html/rfc9136%23section-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<mailto:alexander.vainsht...@rbbn.com>> Date: Sunday, July 9, 2023 at 9:54 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto: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<https://clicktime.symantec.com/15sLvSrP5CLHBNV5D1ben?h=tSgtELOk8fh63wAQLCkLBPtuKy-15fqWvT19hbmH8Eo=&u=https://aka.ms/AAb9ysg> ________________________________ From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Sent: Sunday, July 9, 2023 12:57:00 PM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto: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<mailto:jorge.raba...@nokia.com>> Sent: Thursday, July 6, 2023 9:23 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> Cc: bess@ietf.org<mailto: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<mailto:jorge.raba...@nokia.com>> Date: Tuesday, April 4, 2023 at 5:09 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>, draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto: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<mailto:alexander.vainsht...@rbbn.com>> Date: Monday, April 3, 2023 at 5:51 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto: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<mailto:jorge.raba...@nokia.com>> Sent: Monday, April 3, 2023 4:17 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> Cc: bess@ietf.org<mailto:bess@ietf.org>; Dmitry Valdman <dmitry.vald...@rbbn.com<mailto:dmitry.vald...@rbbn.com>>; Nitsan Dolev <nitsan.do...@rbbn.com<mailto:nitsan.do...@rbbn.com>>; Michael Gorokhovsky <michael.gorokhov...@rbbn.com<mailto:michael.gorokhov...@rbbn.com>>; Ron Sdayoor <ron.sday...@rbbn.com<mailto:ron.sday...@rbbn.com>>; Egon Haparnass <ehaparn...@rbbn.com<mailto:ehaparn...@rbbn.com>>; Shell Nakash <shell.nak...@rbbn.com<mailto:shell.nak...@rbbn.com>>; Marina Fizgeer <marina.fizg...@rbbn.com<mailto:marina.fizg...@rbbn.com>>; Orly Kariv <orly.ka...@rbbn.com<mailto:orly.ka...@rbbn.com>>; Moti Morgenstern <moti.morgenst...@rbbn.com<mailto:moti.morgenst...@rbbn.com>>; Rotem Cohen <rotem.co...@rbbn.com<mailto: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<mailto:alexander.vainsht...@rbbn.com>> Date: Sunday, March 26, 2023 at 11:16 PM To: draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, Dmitry Valdman <dmitry.vald...@rbbn.com<mailto:dmitry.vald...@rbbn.com>>, Nitsan Dolev <nitsan.do...@rbbn.com<mailto:nitsan.do...@rbbn.com>>, Michael Gorokhovsky <michael.gorokhov...@rbbn.com<mailto:michael.gorokhov...@rbbn.com>>, Ron Sdayoor <ron.sday...@rbbn.com<mailto:ron.sday...@rbbn.com>>, Egon Haparnass <ehaparn...@rbbn.com<mailto:ehaparn...@rbbn.com>>, Shell Nakash <shell.nak...@rbbn.com<mailto:shell.nak...@rbbn.com>>, Marina Fizgeer <marina.fizg...@rbbn.com<mailto:marina.fizg...@rbbn.com>>, Orly Kariv <orly.ka...@rbbn.com<mailto:orly.ka...@rbbn.com>>, Moti Morgenstern <moti.morgenst...@rbbn.com<mailto:moti.morgenst...@rbbn.com>>, Rotem Cohen <rotem.co...@rbbn.com<mailto: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<https://clicktime.symantec.com/15t5ei6Q21cWwECv3dXHo?h=hLCOzcf5t8oR3LIGwDra1wBHCN4UcxyL3SN_N-D7vPY=&u=https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-06>: 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<https://clicktime.symantec.com/15t5pNUxwEyhm7rm8kKb3?h=m9ESlNFEXlL5s4xyn-g6bmr0dWvx9li2FHAjKrC16c0=&u=https://www.rfc-editor.org/rfc/rfc7432.html%23section-14.1.1>)? [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<https://clicktime.symantec.com/15t5jYHgUdJ7MB2qbBvSR?h=3pwOHmxhy4P_vmCrfN-Bzd29Fz_PC1o-KGYWe1eTTfY=&u=https://datatracker.ietf.org/doc/html/rfc9136%23fields_overlay_table> 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
