答复: Request to adopt draft-sd-l2vpn-evpn-overlay-03

[Haoweiguo <[e-mail]>]

Hi John,

Thank you very much.

You are right. Local bias on ingress NVE and  tracking other NVEs IP on egress PE provide completed split-horizon filtering solution in NVO3 network. Local bias is different from split-horizon filtering mechanism in EVPN base protocol.

Thanks

weiguo

________________________________

发件人: John E Drake [[e-mail]]
发送时间: 2014年7月8日 21:08
收件人: Haoweiguo; Ali Sajassi (sajassi); Bitar, Nabil N; Giles Heron
抄送: [e-mail]
主题: RE: Request to adopt draft-sd-l2vpn-evpn-overlay-03

Weiguo,

With local bias, an ingress PE sends a copy of a BUM packet received from a CE to every ES to which it is attached, regardless of whether it is the DF for a given ES.  An egress PE sends a copy of a BUM received from an ingress PE to every ES for which it is the DF, except for those ESes which it has in common with the ingress PE.

Yours Irrespectively,

John

From: Haoweiguo [mailto:[e-mail]]
Sent: Tuesday, July 08, 2014 2:06 AM
To: John E Drake; Ali Sajassi (sajassi); Bitar, Nabil N; Giles Heron
Cc: [e-mail]
Subject: 答复: Request to adopt draft-sd-l2vpn-evpn-overlay-03


Hi John,

Can you give more explanation on the split-horizon mechanism provided in section 5.1.3? I think a single IP address per NVE can't satisfy the split-horizon requiements in some scenarios. I think at least one IP should be configured for each ESI. If multiple ESIs attached to same NVE group, one IP can be shared by these ESIs for split-horizon. Pls see my detail description in the previous reply.

Thanks

weiguo

________________________________
发件人: Haoweiguo
发送时间: 2014年7月2日 10:29
收件人: John E Drake; Ali Sajassi (sajassi); Bitar, Nabil N; Giles Heron
抄送: [e-mail]<mailto:[e-mail]>
主题: 答复: Request to adopt draft-sd-l2vpn-evpn-overlay-03

Hi John,

Thanks for your quick answer.



OK, section 5.1.3 describes how to construct  EVPN BGP Routes, the MPLS Label field in the MAC Advertisement, Ethernet AD per EVI, and
Inclusive Multicast Ethernet Tag routes is used to carry the VNI or VSID.



As for section 8.3.1, split-horizon mechanism relies on tracking other NVEs ip address, each ingress NVE only uses a single IP address for split-horizon, as opposed to requiring an IP address per Ethernet
Segment per NVE.  I think a single IP address can't satisfy the requirements in the following scenario.
                                +-----------+
                                |   Router  |
                                +-----------+

                                 |     |    |
                         --------      |     --------
                        |              |             |
                      +------+      +-------+      +------+
                      |(NVE1) |     |(NVE2) |      | NVE3 |
                      +------+      +-------+      +------+
                        *   |         *  |  ^        * |  ^
                        *   |         *  |  ^^^^^^^^^^^^^^^^
                        *   ----------*--------------*-|     ^
                        ****************************** |        ^
                MC-LAG1 *                      MC-LAG2 | MC-LAG3   ^
                    +------+                       +------+    +------+
                    |  CE1 |                       | CE2  |    | CE3  |
                    +------+                       +------+    +------+

In above figure,CE1 and CE2 are active-active accessed to NVE1,NVE2 and NVE3,CE3 is active-active accessed to NVE2 and NVE3. CE1,CE2 and CE3 belongs to a VN.
NVE1,NVE2 and NVE3's IP addresses are 10.1.1.1,20.1.1.1 and 30.1.1.1 respectively.
When NVE1 receives multicast traffic from CE1, the NVE uses 10.1.1.1 as outer tunnel source IP. When the traffic is injected to NVO3 network, NVE2 and NVE3 should filter out the traffic to avoid the traffic loop back to CE1.
But this forwarding principle will let CE3 can't receive the traffic.

To satisfy universal scenario, NVE edge group concept should be introduced, each NVE has one IP address for a edge group. When multiple CEs attach to the exact same set of NVEs, those NVEs can be considered as a single edge group. An NVE can be in more than one edge group.

For example, in the above figure scenario, NVE1,NVE2 and NVE3 forms a edge group, NVE2 and NVE3 forms a edge group.
A IP address can be configured or dynamically allocated for each edge group, assuming the IP address for edge group 1 is 10.1.1.2, edge group 2 is 20.1.1.2.

When NVE1 receives multicast traffic from CE1 and injects it to NVO3 network, 10.1.1.2 should be used as outer tunnel source IP, NVE2 and NVE3 relies on the source IP to perform split-horizon filtering. NVE2 and NVE3 won't forward the traffic to CE1 to avoid loop. If the port connecting to CE3 on NVE2 is DF port, NVE2 will forward the traffic to CE3,NVE3 won't forward the traffic to CE3.

In summary, when each NVE recieves BUM traffic from local connecting CE, the local forwarding principle on each NVE is as follows:
1. Local replication to non mc-lag ports(this is single homed ports).
2. Local replication to the ports associated with the same edge group,regardless of the DF Election state
3. Local replication to the mc-lag DF port associated with different edge group. Do not replicate to mc-lag non-DF port associated with different edge group.

Through this solution, IP address also can be greatly saved and can satisfy all scenarios. If this solution is used, EVPN should be extended to support IP address dynamic allocation for each edge group to simplify service provisioning.



As for section 8.3.2, i have no doubts.



Thanks

weiguo



________________________________
发件人: John E Drake [[e-mail]]
发送时间: 2014年7月1日 21:48
收件人: Haoweiguo; Ali Sajassi (sajassi); Bitar, Nabil N; Giles Heron
抄送: [e-mail]<mailto:[e-mail]>
主题: RE: Request to adopt draft-sd-l2vpn-evpn-overlay-03
Weiguo,

See sections 5.1.3, 8.3.1, and 8.3.2.

Yours Irrespectively,

John

From: L2vpn [mailto:[e-mail]] On Behalf Of Haoweiguo
Sent: Tuesday, July 01, 2014 1:18 AM
To: Ali Sajassi (sajassi); Bitar, Nabil N; Giles Heron
Cc: [e-mail]<mailto:[e-mail]>
Subject: 答复: Request to adopt draft-sd-l2vpn-evpn-overlay-03


Hi Authors,

In draft-sd-l2vpn-evpn-overlay-03 draft, i think on the whole the process is clear, but how to construct EVPN BGP routes is not detail described.
In EVPN network, MPLS Label is carried in Ethernet Auto-Discovery (A-D) route,MAC/IP advertisement route,ESI Label Extended Community. In NVO3 network, it is based on native IP, so all this MPLS Label should be replaced with IP address. All process relies on MPLS label in EVPN should be modified to adapt to NVO3 network, such as split horizon, unicast traffic forwarding,load balancing and aliasing,and etc.

So i hope this draft had better provide more detail description about EVPN routes format and corresponding procedures.

Thanks

weiguo

________________________________
发件人: L2vpn [[e-mail]] 代表 Ali Sajassi (sajassi) [[e-mail]]
发送时间: 2014年6月26日 6:25
收件人: Bitar, Nabil N; Giles Heron
抄送: [e-mail]<mailto:[e-mail]>
主题: Request to adopt draft-sd-l2vpn-evpn-overlay-03

Giles, Nabil:

This draft https://datatracker.ietf.org/doc/draft-sd-l2vpn-evpn-overlay/?include_text=1  (initially called draft-sajassi-drake-l2vpn-evpn-overlay) was first published in December 2012 after the merged between two other drafts: draft-drake-nvo3-evpn-control-plane-00 and draft-sajassi-nvo3-evpn-overlay-01. After the merged, the resultant draft has gone through several iterations to incorporate WG comments. The authors believe there is good consensus for this draft and would like to request for the WG call.

Regards,
Ali