Hi Jorge, Thanks for your response. Please see in-line with [SD]
Regards, Saumya. From: Jorge Rabadan (Nokia) [mailto:jorge.raba...@nokia.com] Sent: Thursday, January 25, 2024 10:25 PM To: Dikshit, Saumya <saumya.diks...@hpe.com>; BESS <bess@ietf.org>; draft-sajassi-bess-evpn-ip-alias...@ietf.org Cc: bess-cha...@ietf.org Subject: Re: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html Hi Saumya, Thank you for patience and feedback. I think we can address some of your comments in the next version. Please see in-line with [Jorge]. From: Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>> Date: Monday, January 15, 2024 at 7:24 AM To: BESS <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org> <draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org>> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>> Subject: RE: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> 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. Resending To the email-alias “draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org>” for authors Hello Authors of draft https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> I have following queries and comments on the draft. Kindly help with your response >>> Context of section >>> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html#section-4<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html#section-4> >>> , I have two queries about “A PE may need to advertise more than one IP >>> A-D per ES route for a given ES because the ES may be in a multiplicity of >>> IP-VRFs and the Route Targets for all of these IP-VRFs may not fit into a >>> single route.” 1. What is the deployment scenario for this ? 2. Is it EVPN connectivity between the PE and CE, which maps to more than one Tenant VRFs. But then EVPN between PE and CE will render the ES as inactive, [Jorge] In RFC7432 Ethernet Segments, a multi-homed ethernet segment can be used by multiple BDs. Here an Ethernet Segment can also be used by multiple IP-VRFs. As an example, take figure 1 and suppose ES1 is attached to BD1 (where H1 is hosted) and BD2 (where H2 is hosted) on the multihomed PEs. BD1 is linked to IP-VRF-1 via IRB, and BD2 to IP-VRF-2 via IRB. In this case PE1 and PE2 will advertise an IP AD per ES route with the route targets of IP-VRF-1 and IP-VRF-2. If you keep adding IP-VRFs on the same ES of the example, at some point the number of route targets will for the PEs to use more than one route. [SD] That was an overlook from my end. Thanks for clarifying In the other use cases it would also be possible. If you are referring to the third use case, you would normally have a single IP-VRF on the ES, but nothing prevents you from having multiple IP-VRFs and one BGP PE CE session each, everyone using the same loopback on the CE. >>> In section >>> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html#name-ethernet-segments-for-l3-al<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html#name-ethernet-segments-for-l3-al> >>> , Do we need to rewrite this sentence “, an active static route to >>> 192.0.2.1 via next hop 192.51.100.2 would make the ES operationally active >>> in PE1, and the eBGP routes received from CE1 with next hop 192.0.2.1 will >>> be re-advertised as RT-5 routes with ESI-1.” 3. Why eBGP routes ? Why not same AS, iBGP/ISIS/OSPF ? [Jorge] the text is focused on the use-cases given in section 1, which are common use cases deployed in networks and DCs, but it should be okay to generalize the procedures. Indeed, the PE-CE routing protocol could be iBGP or an IGP. Let us know if you want us to write some text along those lines. >>> Under section >>> https://<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html>www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html#section-4.3<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html>: >>> Handling Silent Host MAC/IP route for IP >>> <https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> >>> Aliasing<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html>, >>> I have few queries The applicability to other models like “Snooping in interface less IP-VRF” scenario ? How is that to be handled. [Jorge] same as explained. It applies to also use case 2, since the host is also learned on the PEs via ARP/ND. We can make it explicit. [SD] Thanks. As you mentioned, good to have explicit mention that “In enterprise deployments, the PE and CE can be part of the same Autonomous system” and/or The “Ebgp Routes” can be replaced with just “Routes”. The section heading needs to be rectified, to be made generic for silent host handling. [Jorge] agreed. We can replace it as follows: s/Handling Silent Host MAC/IP route for IP Aliasing/Handling Silent Hosts for IP Aliasing/ [SD] Thanks. That should surely help generalizing. The following statement “Thus, to avoid packet loss, when PE2 detects loss of reachability to PE1, it should trigger ARP/ND requests for all remote IP prefixes received from PE1 across all affected IP-VRFs. ” It should not be remote IP Prefixes. Giving the impression that it’s learnt from other PEs and not local to the segment. [Jorge] they are remote prefixes in the sense that PE2 learned them as /32 or /128 prefixes with next-hop PE1 (in its IP-VRFs), even if the hosts belong to a local subnet. [SD] I understand that they are learnt over control plane, but it will typically not trigger ARP/ND requests unless it has a live traffic destined to those hosts. This is a special case of trigger ARP/ND request for hosts on a shared segment with PE1 on loss of connectivity. >>> Section >>> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html#name-ip-aliasing-for-evpn-ip-pre<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html#name-ip-aliasing-for-evpn-ip-pre> >>> : Aliasing for EVPN IP Prefix >>> <https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> >>> routes<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> How should PE2 react to PE1 withdraw for EVPN IP routes? [Jorge] as usual, nothing especial is specified. Normally this is deployed with multiple PEs in the ES (more than 2) and two BGP sessions from the CE, for redundancy reasons. So if the PE that terminates one of the BGP sessions fail, the CE routes are still received by another PE in the ES, and that PE can still advertise the RT5s with the ESI. We can add some text in this regard too. [SD] It will be good to add an explicit case. As mentioned in the draft, if only one PE is having control plane connectivity, and all other PEs (hosting the same segment) only have, let’s say, reachability to CE (next-hop) via static-routes. >>> Section >>> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html#name-ip-aliasing-for-evpn-ip-pre<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html#name-ip-aliasing-for-evpn-ip-pre> >>> : Case: IP >>> <https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> >>> Aliasing in a Centralized Routing >>> Model<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> How is CE router ID reachability over EVPN. Shouldn’t it be via an underlay network route ? [Jorge] no, reachability is in the overlay. PEC resolves the PE-CE route’s next-hop to an EVPN route. [SD] I believe, this is by leveraging Overlay Index ? Thank you. Jorge Regards, Saumya.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
