[bess] draft-saumvinayak-bess-all-df-bum

["Rabadan, Jorge (Nokia - US/Sunnyvale)" <[e-mail]>]

Dear Saumya and authors,

I wanted to follow up on what I mentioned at the mic this morning during the BESS session:


  1.  You are requesting DF Alg codepoint 2 for this draft, which clashes with https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-08#section-6 – a Working Group draft with multiple implementations, so please remove that from the draft.


  1.  The use of an Ethernet Segment in this application is weird, and IMHO there are better ways to approach the issue. This is the rationale behind that statement:



     *   Eth Segment is defined as a group of links, multi-homed to the same network or CE. I don’t think that fits the use-case.
     *   If I understood the use-case, the only part of the multi-homing procedures you are interested in is the advertisement of the Firewall MAC/IPs in a MAC/IP route that is not subject to mobility, and you want to apply aliasing on the remote PEs. BUM traffic is forwarded by all the PEs.
     *   If (b) is true, I don’t think Ethernet Segments are the correct way to address this. As I mentioned, we use the Default Gateway extended community to indicate a MAC/IP route belongs to a default gateway that is not subject to mobility procedures - https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04#section-10.1. Note that this section even talks about MAC aliasing.
     *   So if I may, my suggestion would be:

                        i.   do not use Eth Segments

                      ii.   Use the default-gateway ext community for the firewall MAC/IP routes. That naturally excludes these MACs from the mobility procedures

                     iii.   Based on the reception on the MAC/IP routes with the def gateway ext community, do MAC aliasing on the remote nodes

Let me know if you have comments.
Thank you.
Jorge