Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Jeffrey,

A few points: 

1) There have been lots of discussions on this topic but you were not in
attendance for some of them including the ones held at the last IETF in
Bones Aires. So, before jumping into a haste conclusion that there were
not consensus on section 10, please check with your own colleagues who
participated in those meetings.

2) Regarding the current text in section 10: this text is consistent with
the one that was checked for IETF at Yokohama and it is also consistent
with RFC 7432 operation. We still require Eth A-D per ES in order to
validate Eth A-d per EVI, the only difference is that the mass-withdraw
doesn¹t work (i.e., route validation still works).

3) Your so-called ³easy solution² doesn¹t work in all scenarios so there
is no point in documenting something that works sometimes :-) If you
recall several years ago, we went to great length to accommodate
multi-homing across multiple AS¹s and that¹s why we added originating
router¹s IP address to the ES route. The 4 byte field in RD type-1, is a
router ID (for both IPv4 and IPv6) and per RFC 6286, router-id is unique
within an AS only. Thus the suggested solution won¹t work when a CE is
dual-homed to two PEs in two different AS¹s.

We are currently separately documenting a proper solution based on a new
sub-TLV added to the attribute in idr-tunnel-encap draft to identify the
originating PE. A solution based on this attribute will work for all
scenarios. Now the question is what to do in short term. We can either go
with the text that it is in section 10.2 of the evpn-overlay draft, plus
go with the new draft, or just go with the new draft and remove the
suggested solution in section 10.2. I am open to both.

Cheers,
Ali 







On 6/10/16, 1:03 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang"
<[e-mail] on behalf of [e-mail]> wrote:

>I want to bring up an old discussion about the following:
>
>   In summary, it can be seen that aliasing (and backup path)
>   functionality should work as is for inter-AS option B without
>   requiring any addition functionality in ASBRs or PEs. However, the
>   mass-withdraw functionality falls back from per-ES mode to per-EVI
>   mode for inter-AS option B - i.e., PEs receiving mass-withdraw route
>   from the same AS use Ether A-D per ES route; whereas, PEs receiving
>   mass-withdraw route from different AS use Ether A-D per EVI route.
>
>There have been lot of discussions on this - offline and in Yokohama
>(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). The
>above text does not reflect the consensus among some of us and in
>particular does not reflect what was presented in Yokohama.
>
>There are two issues with inter-as option B as currently specified in RFC
>7432.
>
>A minor issue is that mass-withdraw degrades from per ES to from per (ES,
>EVI) (with the clarification in this overlay draft), which would not
>exist if the main issue is resolved as presented in Yokohama.
>
>The main one is the following requirement in RFC 7432:
>
>   Note that the Ethernet A-D per EVI route may be received by a remote
>   PE before it receives the set of Ethernet A-D per ES routes.
>   Therefore, in order to handle corner cases and race conditions, the
>   Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by
>   a remote PE until it also receives the associated set of Ethernet A-D
>   per ES routes.
>
>Basically, the per-EVI A-D routes cannot be used before the corresponding
>per-ES A-D routes are received and associated. Either that requirement
>must be removed, or there must be a way to associate the per-ES routes
>and per-EVI routes from the same PE.
>
>There is an easy solution to the latter, which was presented in Yokohama
>(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). That
>does require a beefed up requirement: the routes from the same PE MUST
>have the same global admin field in the RDs. That should be reasonable,
>and RFC already uses RECOMMEND keyword:
>
>7.9.  Route Distinguisher Assignment per MAC-VRF
>
>   The Route Distinguisher (RD) MUST be set to the RD of the MAC-VRF
>   that is advertising the NLRI.  An RD MUST be assigned for a given
>   MAC-VRF on a PE.  This RD MUST be unique across all MAC-VRFs on a PE.
>   It is RECOMMENDED to use the Type 1 RD [RFC4364].  The value field
>   comprises an IP address of the PE (typically, the loopback address)
>   followed by a number unique to the PE.
>
>Notice the "RECOMMEND" in the above paragraph.
>
>8.4.1.  Constructing Ethernet A-D per EVPN Instance Route
>   ...
>   The Route Distinguisher (RD) MUST be set per Section 7.9.
>
>8.2.1.  Constructing Ethernet A-D per Ethernet Segment Route
>   ...
>   The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364].  The
>   value field comprises an IP address of the PE (typically, the
>   loopback address) followed by a number unique to the PE.
>
>As long as 8.4.1 or 7.9 says Type 1 RD MUST be used, then all the
>problems are solved. While RFC 7432 did not use MUST, I doubt there is
>any implementation not using a Type 1 RD for the per-EVI route.
>
>Jeffrey
>
>_______________________________________________
>BESS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bess