Subject: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-00 and/or draft-ietf-bess-evpn-inter-subnet-forwarding

From: <[email-masked]>
Date: Wed, 3 Jul 2019 09:25:34 +0800 (CST)

Hi Ali and everyone,

I reviewed the [EVPN IP Aliasing] draft and found that it conflicts with draft-ietf-bess-evpn-inter-subnet-forwarding-05 in MPLS encapsulation.

<snip>

draft-sajassi-bess-evpn-ip-aliasing-00 section 2.1 Constructing Ethernet A-D per EVPN Instance Route

... ...

   * The L3 EAD/EVI SHOULD carry one or more IP VRF Route-Target (RT)       

   attributes.

   * The L3 EAD/EVI SHOULD carry the RMAC Extended Community attribute.    

   * The MPLS Label usage should be as described in RFC 7432. 

... ..

</snip>

<snip>

draft-ietf-bess-evpn-inter-subnet-forwarding-05 section 3.2.3 Data Plane - Ingress PE

 ... ...

   If the tunnel type is that of MPLS or IP-only NVO tunnel, then TS's

   IP packet is sent over the tunnel without any Ethernet header.

   However, if the tunnel type is that of Ethernet NVO tunnel, then an

   Ethernet header needs to be added to the TS's IP packet. The source

   MAC address of this inner Ethernet header is set to the ingress PE's

   router MAC address and the destination MAC address of this inner

   Ethernet header is set to the egress PE's router MAC address. The

   MPLS VPN label or VNI fields are set accordingly and the packet is

   forwarded to the egress PE. 

 ... ...

</snip>

In the first draft the L3 EAD/EVI Route for symmetric IRB uses a L2 MPLS Label, 

so the PE expects to receive a EVPN data packet with an overlay ethernet header as per RFC7432.

But unfortunatly, in the second draft, the inter-subnet forwarding procedures for symmetric IRB 

will always send the EVPN data packet without the overlay ethernet header. 

So I think these two drafts conflicts with each other, and one of them should be updated.

and I propose that the [EVPN IP Aliasing] draft should use a L3 MPLS Label in the L3 EAD/EVI route.

How do you think about it?

Best Regards

Bob