Re: [bess] few queries regarding rfc9014 : https://datatracker.ietf.org/doc/html/rfc9014

["Dikshit, Saumya" <[e-mail]>]

Thanks Jorge. Will it need an addendum draft for best practices. Are there any drafts floating around which can accommodate.

Regards,
Saumya.

From: BESS [mailto:[e-mail]] On Behalf Of Jorge Rabadan (Nokia)
Sent: Tuesday, February 27, 2024 3:48 PM
To: Dikshit, Saumya <[e-mail]>; BESS <[e-mail]>
Cc: [e-mail]
Subject: Re: [bess] few queries regarding rfc9014 : https://datatracker.ietf.org/doc/html/rfc9014

Hi Saumya,

Not really, RFC9014 was published long ago, and there is no issue with the text as far as I can tell. So this is not an errata but my own considerations.
Thanks.
Jorge

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 27, 2024 at 1:00 AM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, BESS <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: few queries regarding rfc9014 : https://datatracker.ietf.org/doc/html/rfc9014<https://datatracker.ietf.org/doc/html/rfc9014>

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.


Thanks a lot Jorge for responding as always.
Is it possible to update rfc9014 with these insinuations.

Regards,
Saumya.

From: Jorge Rabadan (Nokia) [mailto:[e-mail]]
Sent: Tuesday, February 27, 2024 1:30 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; BESS <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: few queries regarding rfc9014 : https://datatracker.ietf.org/doc/html/rfc9014<https://datatracker.ietf.org/doc/html/rfc9014>

Hi Saumya,

Please see in-line with [jorge].


From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Date: Monday, February 26, 2024 at 9:31 PM
To: BESS <[e-mail]<mailto:[e-mail]>>, Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: few queries regarding rfc9014 : https://datatracker.ietf.org/doc/html/rfc9014<https://datatracker.ietf.org/doc/html/rfc9014>

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.


Anything from authors and/or others on rfc9014 queries

From: Dikshit, Saumya
Sent: Friday, February 16, 2024 7:23 AM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; BESS <[e-mail]<mailto:[e-mail]>>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: few queries regarding rfc9014 : https://datatracker.ietf.org/doc/html/rfc9014<https://datatracker.ietf.org/doc/html/rfc9014>

Gentle reminder to authors or anyone who can answer.

Regards,
Saumya.

From: BESS [mailto:[e-mail]] On Behalf Of Dikshit, Saumya
Sent: Tuesday, February 13, 2024 5:20 PM
To: BESS <[e-mail]<mailto:[e-mail]>>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [bess] few queries regarding rfc9014 : https://datatracker.ietf.org/doc/html/rfc9014<https://datatracker.ietf.org/doc/html/rfc9014>

Hello Authors of https://datatracker.ietf.org/doc/html/rfc9014<https://datatracker.ietf.org/doc/html/rfc9014>

I have few queries specifically on the “UMR” and “arp/nd flooding control” and might be inter-related
>>>> https://datatracker.ietf.org/doc/html/rfc9014#section-3.5.1<https://datatracker.ietf.org/doc/html/rfc9014#section-3.5.1> MAC Address Advertisement Control<https://datatracker.ietf.org/doc/html/rfc9014#name-mac-address-advertisement-c>
Host1-----NVE1-----PE1-----(WAN)-----PE2-----NVE2----Host2
For realization of UMR usage, does the logic entails that

the end-host (host1) shall learn the remote-hosts (host2) MAC and IP (in a remote DC/fabric/site for same-subnet) over data-plane via normal flood and learn via typical APR request/response; and

 the eventual data flow from host1 to the host2 shall hits the UMR on NVE1 (first hop Vtep)

the first-hop vtep (NVE1) will not learn the MAC bindings over Control plane from the PE1

as the PE1 will publish only UMR in place of all remote MACs hosted in remote DC/fabric/site. ?

This shall also mandate proxy-arp functionality on PE1 for the requests arising from the hosts (host1) in attached DC,

else request for same credentials (host2) shall flood the WAN from other attached hosts to the fabric.
Or there is something more to it.
[jorge] host1 and host2 learn about each other as usual. What UMR provides is a way to efficiently reduce the amount of unknown unicast traffic within each DC, assuming that all the hosts are learned by the attached NVEs. In your example, there is not much gain since unknown traffic from the NVEs only goes to the PEs anyway 😊. But basically, if NVE1 understands UMR, and host2 MAC is not on the FIB, NVE1 unicasts the traffic to PE1.
Note that if you want to do proxy-arp/nd on the NVEs, you really need the MAC/IPs installed in the NVEs, so you may argue that the UMR is not that useful.
>>>> https://datatracker.ietf.org/doc/html/rfc9014#section-3.5.2<https://datatracker.ietf.org/doc/html/rfc9014#section-3.5.2>: ARP/ND Flooding Control<https://datatracker.ietf.org/doc/html/rfc9014#name-arp-nd-flooding-control>
The ARP/ND queries should also be proxied by PE’s (PE1 and PE2) to the request generated from inside the attached DC/fabric, as it will save on flooding over WAN.
Anyways, PE shall absorb all the remote fabric info (RT-2’s from remote fabrics) to realize UMR and shall avoid relaying it to the attached fabric/DC.
[jorge] note that the text talks about ARP-Requests/NS from the WAN to protect the DC from ARP/ND flooding. The PEs could reply to requests from inside too, but then – and this is more like a design choice – I would argue that it would be better to distribute the proxy-arp/nd functions to the NVEs and not use UMR.
My 2 cents.
Thanks.
Jorge


Any thoughts on above shall be great.

Regards,
Saumya.