Subject: [bess] Question(s) on draft-ietf-bess-evpn-inter-subnet-forwarding-00

From: "Russ White" <[email-masked]>
Date: Wed, 18 Feb 2015 21:53:42 -0500

Before I get into a lot of edits and thoughts -- In section 2:

==
In the above scenario, the term "route aggregation" refers to the case where
a node situated at the WAN edge of the data center network behaves as a
default gateway for all the destinations that are outside the data center.
The absence of route aggregation refers to the scenario where NVEs within a
data center maintain individual (host) routes that are outside of the data
center.
==

Reading through the rest of the draft, there seems to be a lot of
interchange between "WAN gateway," "route aggregation," and "default
gateway." Let me try describing two switching paths, and then try to sort if
they actually cover all the different scenarios given in the draft.

Assume you have:

TS1--NVE1--R1--R2--NVE2--TS2

TS1 wants to send a packet to TS2; however, TS2 is on a different subnet.
TS1 examines its local tables, and determines that TS2 is on a different
subnet, so it transmits the packet to the default gateway (it actually
doesn't matter if TS1 itself sends this packet, or if TS1 is a switch, and
some device behind TS1 sends this packet -- the result is the same). In this
case, let's assume NVE1 is the default gateway, so it receives and must
process the packet. There are two options at this point.

NVE2 could have a routing entry directly to TS2 which includes layer 2
information through an EVPN advertisement in BGP (or other means outside the
scope of the document). In this case, NVE2 uses the layer 2 information
contained in the BGP advertisement to build a MAC header rewrite string,
stuffs the packet into the correct outer header (MPLS or VXLAN or whatever
else), and ships it towards NVE2. NVE2 pulls the tunnel headers and fowards
based on the layer 2 information.

NVE2 could have a routing entry directly to TS2 which does not include layer
2 information. In this case, NVE2 simply forwards the packet based on any
local layer 3 information it might have. Let's say this layer 3 information
is either a default or more specific route advertised by R2. In either case,
NVE1 wraps the packet in the correct tunnel information to reach R2 and
ships it. R2 removes the tunnel information and forwards it to NVE2 based on
local forwarding information (which could be a layer 2 advertisement or a
layer 3 advertisement -- from NVE1's perspective this isn't important). 

These two seem to cover all five of the possibilities covered in section 2.
Where TS2 is located -- within or outside the local data center -- doesn't
really make any difference (unless you assume there will never be a default
route advertised between IP subnets within a data center, or there will
never be IP only connectivity between two different subnets within the same
data center, both of which seem like a bad assumptions to me). Is there a
specific reason why the location of the "wan default gateway" makes any real
difference in the different scenarios? Or why the default route is a special
case (other than requiring the device advertising the default route to be
able to interconnect an EVI and an IP-VPN)?

Russ

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 19 Feb 2015 06:45:59 +0000

The corresponding solutions for each of the scenarios outlined in section
2 are different and that¹s why they are listed as such.

Scenario-1 doesn¹t require any DCI solution and doesn¹t require any
interop to IP-VPN
Scenario-2 requires a DCI solution w/o maintaing an IP-VRF at the GW
Scenario-3 requires a DCI solution that needs an IP-VRF at the GW
Scenario-4 requires inter-op between EVPN and IP-VPN

Cheers,
Ali

On 2/18/15, 6:53 PM, "Russ White" <[email-masked]> wrote:

>_______________________________________________
>BESS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bess

---

From: "Russ White" <[email-masked]>
Date: Thu, 19 Feb 2015 07:13:42 -0500

> Scenario-1 doesn¹t require any DCI solution and doesn¹t require any
interop
> to IP-VPN

But this doesn't make sense from a forwarding perspective. What you're
really talking about is what type of connectivity is available between the
source and destination, not where these devices are located. I don't care if
TS1 and TS2 are in the same data center or different ones. What matters is
--

- I have layer 2 connectivity with a common control plane
- I have layer 2 connectivity with different control planes
- I have layer 3 connectivity (and I don't care what sort of layer 3
connectivity it is) 

Further, the entire idea of "aggregated" versus "not aggregated" is
completely mixed up with the concept of a default gateway, and completely
ignores the part the host plays in the forwarding process (choosing whether
or not to use the default gateway). 

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Thu, 19 Feb 2015 08:23:57 -0500

> > Scenario-4 requires inter-op between EVPN and IP-VPN

Let me try to clarify a bit on what I'm asking, perhaps --

- Scenario-1 is essentially using eVPNs as a DCI solution across the "WAN."
This is simple, just extend the eVPN domain, and is a natural progression
from a "within the DC" eVPN devployment, so I'm not really certain why it
needs to be discussed (?). I think maybe the point here is to bring out the
"aggregated" and "not aggregated" cases, but those could occur within a data
center -- and there are problems with the way these are described (IMHO,
anyway -- but that's a separate discussion). 

- Scenerio-2 and Scenerio-3 seem to be a layer 2 connection other than eVPNs
connecting the eVPN deployments; both require some sort of interop between
the two layer 2 domains, generally speaking some sort of gateway that will
interconnect them. This is identical to the case where you have VLANs and
eVPNs running within the same data center, and need a "gateway" between the
two. 

- Scenerio-4 appears to be "there is only a layer 3 IP-VPN connection
(L3VPN?) between two eVPN segments." This could easily arise within a single
data center -- there's no reason to postulate a "WAN gateway," in this case.
There's the default gateway, after which the packet is routed -- there might
be ways to optimize the routing, but that seems to be outside the scope of
eVPNs (?).

So -- I don't really know why all of this needs to be put in the context of
inter-DC connectivity (or DCI). Each of these situations would/could also
arise in the context of a single data center. 

Russ