I support the adoption. However, have a few comments:

The intended status of the draft is Informational, but it doesn't look
right.

The abstract says:
  This document specifies how the different EVPN
   functional modes and types can interoperate with each other. This
   document doesn't aim to redefine the existing functional modes
*but   extend them for interoperability*.

In addition, the draft has multiple normative statements. Hence,
believe the intended status should be standards track instead..

Section 4.2 says:
   With PE2 operating in Symmetric IRB and with enabled interop mode,
   the MAC/IP route from PE1 (Asymmetric IRB) is processed in the
   respective bridging, routing and adjacency table. Based on the Route-
   Target for MAC-VRF1, the MAC address M1 will be imported into MAC-
   VRF1 respectively and placed within BD0.

* In addition, the host-   binding information M1/IP1 MUST be installed
within PE2s adjacency   table.*

For a PE operating in symmetric IRB mode, it is not required to install
M1/P1 in the ARP/ND/adjacency table as
per draft-ietf-bess-evpn-inter-subnet-forwarding. Hence, I think this draft
is updating/extending draft-ietf-bess-evpn-inter-subnet-forwarding.

The draft has the foll. description for Figure 2:
   The IRB interfaces for a common MAC-VRF/BD on
   PE1 and PE2 use the *same IP address*. With the difference of the IRB
   modes between PE1 (Asymmetric IRB) and PE2 (Symmetric IRB), there is
   a difference in the MPLS Label presence as part of the MAC/IP routes
   exchanged between the PEs.

I guess it should say "same IP address and MAC address". Otherwise, it is
not necessary to install M1/P1 in PE2's adj table. If PE2 receives a packet
destined to P1, PE2 will initiate a glean procedure causing the host having
(M1, P1) to respond. The response will reach PE2, so PE2 will install in
its adjacency. The problem occurs only when both PE1 and PE2 use the same
anycast default gateway IP and MAC addresses (which is also the recommended
option as per draft-ietf-bess-evpn-inter-subnet-forwarding), in which case
the response from the host will be locally consumed by PE1.

Regards,
Muthu

On Mon, Apr 19, 2021 at 11:36 PM <[email protected]> wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-krattiger-evpn-modes-interop-03 [1].
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not  progress without answers from all of the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on 4th May 2021.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1]  https://datatracker.ietf.org/doc/draft-krattiger-evpn-modes-interop/
>
>
> _______________________________________________
> BESS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bess
>
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess

Reply via email to