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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess