[OPSAWG] EVPN support in L2NM

Qin Wu <bill.wu@huawei.com> Tue, 15 December 2020 05:32 UTC

From: Qin Wu <bill.wu@huawei.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: EVPN support in L2NM
Thread-Index: AdbSgUE5Zzp51fSSScqqRiQ/gFnVnA==
Date: Tue, 15 Dec 2020 05:31:59 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAADC304C4@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADC304C4dggeml511mbschi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/G-M-k1wWVJptLaoxyEea0G6RhHE>
Subject: [OPSAWG] EVPN support in L2NM
Precedence: list

Hi, all:

We discussed EVPN support for L2NM in past L3NM Design team meetings and tried to identify what are missing parameters for EVPN support in L2NM.

First, EVPN have many different flavors, e.g.,

O MPLS EVPN (RFC7432)

o VXLAN EVPN (RFC8365)

o PBB EVPN (RFC7623)

o VPWs EVPN (RFC8214)

These flavors can be distinguished based on service type in the current model, we also discussed whether vpn node type is needed to distinguish

Different EVPN flavors, based on discussion, we think this vpn node type is redundant, since service type has already played this role.

Secondly, EVPN needs to support split horizon, split horizon can be interpreted as filtering mechanism on the PE node to prevent such loop and packet duplication, e.g., If a CE is multihomed to two or more PEs (represented by an ES ES1) and operating in an All-Active redundancy mode, sends a BUM (i.e., Broadcast, Unknown unicast, or Multicast) packet to one of these PEs, then it is important to ensure the packet is not looped back to the CE via another PE connected to this CE.

In the current model, we have defined split-horizon parameter to classify the connection into different group which implicitly indicate

split horizon support. In the Design team discussion, we discussed whether a Boolean parameter to indicate split horizon support explicitly.But maybe redundant and not need at the VPN node level.

Third, FRR support, in many cases, FRR is used with TE support. However we also see some work discuss how FRR can be supported without TE

https://www.apricot.net/apricot2006/slides/conf/thursday/Stefano_Previdi_IPFRR-Apricot.pdf
https://tools.ietf.org/html/rfc5714

So if FRR is highly tied with TE, we think the best place to define it is in the TE service mapping draft, if FRR can be decoupled with TE, it looks IP FRR can be introduced in L2NM.

Fourth, Diffserv model type support, In the RFC 3270, three MPLS DiffServ models are defined: Uniform, Pipe, and Short Pipe. MPLS Diffserv will be used in both local PE and egress PE to distinguish how data traffic is treated in the ingress node and egress node, which is different from QoS parameters (traffic classification+QoS Policy enforcement)defined in L2NM.

Should this be added as EVPN support? In the current model, we don't have Diffserv support. But it is nice to have this feature.

Fifth, Bridge domain ID support, as described in RFC7209,

"For each of the above services, a single bridge domain is assigned per service instance on the PE supporting the associated service.
For example, in case of the port mode, a single bridge domain is assigned for all the ports belonging to that service instance"
I am wondering whether bridge domain ID should be defined in L2NM as optional parameter.

-Qin

[OPSAWG] EVPN support in L2NM Qin Wu