Re: [bess] Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html

["Jorge Rabadan (Nokia)" <[e-mail]>]

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 <[e-mail]>
Date: Monday, January 15, 2024 at 7:24 AM
To: BESS <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: Queries to authors of 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 “[e-mail]” for authors

Hello Authors of draft 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  , 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.
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 ,  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.

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/

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.

>>> Section 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.

>>> Section  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.

Thank you.

Jorge

Regards,
Saumya.