Subject: bgp encap ext-comm in draft-sd-l2vpn-evpn-overlay-01

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 14 Mar 2013 16:06:24 +0000

Hi,

Following up on the question I asked you during the l2vpn session to Ali:

Should we send the BGP encapsulation ext-comm along with the Inclusive
mcast route too?

Section 5.1:
"When the NVEs reside on the hypervisor, the E-VPN BGP routes and
attributes associated with multi-homing are no longer required.
This reduces the required routes and attributes to the following subset of
five out of the set of eight :
- MAC Advertisement Route
- Inclusive Multicast Ethernet Tag Route
- MAC Mobility Extended Community
- Default Gateway Extended Community

As mentioned in section 3.1.1, BGP Encapsulation Extended Community
attribute as defined in [RFC5512] SHOULD be used along with MAC
Advertisement Route or Ethernet AD Route to indicate the supported
encapsulations."

So in this scenario:

VM1--NVE1----------NVE2--VM2

If VM2 MAC has not been advertised yet by NVE2 and since there is no AD
route, how does NVE1 know what encapsulation to use to send unknown
unicast traffic to NVE2?
In my view, the BGP encapsulation ext-comm should be sent along with the
Inclusive mcast route too, but I might be missing something.

Can you please comment on it?
Thank you.
Jorge

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 14 Mar 2013 17:28:48 +0000

Hi Rabadan,

You're right. We need to include this attribute for Inclusive Multicast
route as well.

Cheers,
Ali

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 14 Mar 2013 17:35:06 +0000

Thank you Ali.
Regards,
Jorge

-----Original Message-----
From: "Ali Sajassi   (sajassi)" <[email-masked]>
Date: Thursday, March 14, 2013 10:28 AM
To: Jorge Rabadan <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: bgp encap ext-comm in draft-sd-l2vpn-evpn-overlay-01