Hi Ali,
2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE,
impacts lot more sections than just section 2.2 for which you
suggested some texts. It drastically impacts section 3.1 (known
unicast traffic), and it also impacts section 3.2 (BUM traffic) and
section 5.1.
Can you detail why ?
The understanding that leads me to this suggestion is that the
2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a
2.2.1 would not require new procotol procedures nor changes in the text
that as I understand provides procedures for 2.2(.2) and 2.3.
Furthermore, it creates a new paradigm for EVPN that was never
intended for because of creating two MAC-VRFs (and two bridge tables)
for the same VLAN.
The "<new thing> created a new paradigm that <RFX xyz> was never
intended for" is a not generally valid, or sufficiently detailed,
argument: if it was, then you might go as far as challenging the whole
E-Tree spec on the same kind grounds (and many other new things).
So here is where it seems we have a gap to bridge: I still don't
understand what in RFC7432 describes an intention of "not supporting two
MAC-VRFs for the same VLAN".
The WG LC was completed on 3/29/16 and I am sure it is not your
intention to have major changes to the doc at this stage where
multiple vendors have already implemented the draft.
As you know, there are different stages at which people do reviews on a
doc after WGLC, an which may lead doc editors to introduce significant
--editorial or technical-- changes in a document. Sometimes that leads
to documents going back to the working group.
However my root intention as doc shepherd, of course, is not to propose
a major change, but merely to able to answer the standard question of
the shepherd review -- on the reviews done, on document readiness, and
on the document quality -- in a way as positive and sincere as possible.
In particular questions (3) (4) and (6).
This draft talks about two kinds of traffic filtering: a) ingress
filtering for known unicast and b) egress filtering for BUM traffic.
What you are suggesting is an alternate mechanism for ingress filtering.
(well I'm not suggesting the mechanism itself --which section 2.1
already does-- but simply to document that it can still apply without
the constraint of avoiding the presence of a Root MAC-VRF and a Leaf
MAC-VRF on a same PE)
Although having multiple VRFs (and forwarding tables) are fine for
IP-VPNs because the unknown traffic is always dropped, multiple VRFs
for the same VLAN is not OK for L2 traffic because of flooding of
unknown traffic. That’s why in section 6 of RFC 7432, for all service
interface types, the draft talks about a single MAC-VRF per EVI per PE
and in case of VLAN-aware mode, multiple VLANs per MAC-VRF but only a
single bridge table per VLAN. In other words, the bottom line is that
there can only be a single bridge table per VLAN in order to avoid
unnecessary flooding.
When you have two MAC-VRFs per VLAN (one for root ACs and another for
Leaf ACs), then you either need to duplicate lots of MAC addresses
between these two VRFs, or do lookup on both of these VRFs. Either
ways this is not a good option relative to keeping a single VRF table
for both root and leaf sites and just have a single-bit indication on
whether a MAC is associated with root or leaf (as currently described
approach in the draft). I
In the above, it seems you agree that it can work, and you are able to
offer reasons why it is not the preferred option, then why not just
document that it can work and provides these reasons as the motivations
that lead to proposing a new specs ?
(it seems you have an unfinished last sentence: "I [...]" )
(assuming the previous point is resolved:)
With this mechanism above, isn't it possible to have on a given PE,
for a single E-TREE EVI, both Leaves and Roots, as long as distinct
MAC-VRFs are used (one for Leaves and one for Roots) ? (it seems
to me that the assymetric import/export RT would do what is needed
to build an E-TREE, we would just have a particular case where a
Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a
single PE)
That’s not possible because per definition of an EVI, there is only
a single MAC-VRF per EVI for a PE.
Where can I read such a definition ? (the Terminology section in
RFC7432 does not say that, unless I'm missing something).
And that seems a completely arbitrary restriction.
(just thinking that a given PE device can be split in two logical
devices show that it can work)
Section 6 of RFC7432 where it gives definitions for different service
interface types, it specifies the relationship between MAC-VRF and
VLAN (bridge table) and how many MAC-VRF (and bridge tables) can be
per EVI.
This section of RFC7434 discusses many different things for the
different variants.
Can you provide a specific pointer about "how many MAC-VRFs can be per
EVI" ?
Ali> Section 6 of RFC7432 spells out the relationship between EVI,
MAC-VRF, and bridge tables for all service interfaces very clearly.
In all service interfaces, the RFC says there is one MAC-VRF per EVI
on a given PE.
Now, if the service interface is “vlan-aware”, then there are several
bridge tables for that single MAC-VRF – ie, one bridge table per VLAN.
In all service interfaces, you can ONLY have one bridge table per VLAN.
This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be
possible to extract quotes about "there is one MAC-VRF per EVI on a
given PE", right ?
In bridging world, there can only be a single bridge table per VLAN
in a device.
I still don't find here anything that would preclude having, on a
given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots
MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with
translation if the external VLANs are constrained).
Ali> Lets assume we are using vlan-based service and thus there is
only a single bridge table per MAC-VRF, then what you are suggesting
is two use two MAC-VRFs (two bridge tables) for the same EVI (same
VLAN). This results in some duplications of MAC addresses and would
only work if flooding is disabled (more on this later).
"results in some duplications of MAC" is perhaps a drawback, but nothing
like "just does not work" ?
"would only work if flooding is disabled": why ? (you wrote "(more on
this later)" but I couldn't identify anything recent from you in the
rest of the email below)
From an helicopter view, I can't see what fundamentally would become
problematic between "two MAC-VRFs on two distinct PEs" and the same "two
MAC-VRFs on a same PEs", at worse it is as efficient or as inefficient
as having them on separate PEs (think logical router without anykind of
dataplane optimisation), and we can't exclude that the PE could have
local implementation details to do better than that.
Besides, I don’t understand what good does it do to have two
MAC-VRFs on the same PE (one for Leafs and another for Roots)
Well, the "what is good for" is pretty simple: it means you can have,
just by tailoring the import/export policies like in 2.1, something
as useful as the scenario in 2.2.
There can only be a single bridge table per VLAN. Now even if you add
some kind of logic to form two logical PEs in single physical PE, you
end up replicating all the MAC addresses associated with the root
sites in two bridge tables.
Your point above certainly does not sound to me as "it can't be done":
some may think that the above is an acceptable cost, some others may
find ways to make this "replication" with a low overhead, on some
platforms the cost may be negligible, etc.
because Leafs and Roots need to talk to each other and thus we want
them to be in the same MAC-VRF.
The fact that Leafs and Roots need to talk to each other does not
mean that they *have* to be in the same MAC-VRF, you can rely on the
local MPLS dataplane inside the PE to carry the traffic between Roots
and Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF
(and you can possibly implement a shortcut not involving MPLS
encap/decap).
Anything is possible but at what cost.
You know, for cost it is not always obvious to reach conclusions that
are true for all implementations and all targets.
The current proposal is very efficient in terms of forwarding path as
well as control plane.
Sure, but what I question is not the new solution but the lack of
discussion on why using the existing specs was not considered good enough.
I think that my concern of clearly explaining the scenarios and
motivations for this new spec could be addressed by splitting section
2.2 into a 2.2.1 describing the approach from 2.1 and its possible
drawbacks, and a 2.2.2 having essentially the content of current
section 2.2.
Here is a proposal:
2.2 Scenario 2: Leaf of Root site(s) per AC
In these scenarii, a PE receives traffic from either Root OR Leaf
sites (but not both) on a given Attachment Circuit (AC) of an EVI. In
other words, an AC (ES or ES/VLAN) is either associated with Root(s)
or Leaf(s) (but not both).
2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root
MAC-VRFs
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+
|CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2|
+---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+
| |VRF| | | /IP | | '---' |
| | | | | | | .---. |
| | | | | | | |MAC| | +---+
| | | | | | | |VRF+--+---ES2/AC2--+CE3|
| +---+ | +------+ | +---+ | (Root) +---+
+---------+ +---------+
Figure 2: Scenario 2a
In this scenario, the RT constraint procedures described in section
2.1 could
also be used. The feasibility and efficiency of this approach
depends on
platforms specifics.
This approach will lead toduplication of a large proportion of MAC
addresseson
PEs having both Leaf and Root sites, and is hence considered less
suitable for
deployment contexts where the vast majority of PEs are likely to
ultimately
have both Leaf and Root sites attached to them.
2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+
|CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2|
+---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+
| |VRF| | | /IP | | |VRF| |
| | | | | | | | | | +---+
| | | | | | | | +--+---ES2/AC2--+CE3|
| +---+ | +------+ | +---+ | (Root) +---+
+---------+ +---------+
Figure 2: Scenario 2b
This scenario will alleviate keys drawbacks from Scenario 2a, in
particular
by avoiding duplication of MAC addresses on Leaf/Root PEs and
avoiding the
operational overhead of managing more than one RT.
This approach comes at the expense of having routes for unneeded
MAC addresses on Leaf-only PEs, and is hence considered less suitable
for deployment contexts where the vast majority of PEs would remain
Leaf-only. Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures
provided in this document.
(And this last sentence should be added to section 2.3 as well)
For this scenario, if for a given
EVI, the majority of PEs will eventually have both Leaf and Root
sites attached, even though they may start as Root-only or Leaf-only
PEs, then it is recommended to use a single RT per EVI and avoid
additional configuration and operational overhead.
Why this recommendation ?
Even with a majority of PEs having both Leaves and Roots, there can
remain (up to 49% of) PEs having only Leaves, which will uselessly
have all routes to other Leaves.
So "it is recommended" above, deserves to be explained more, I think.
OK, I changed “majority” to “vast majority” :-)
My point was not to nit pick on "majority", but was that you should
explain why you recommend that.
As the text currently reads, the cost of the recommendation can be
identified: having useless routes on the fraction of PEs having only
Leaves.
But the gain brought by the recommendation is not even mentioned, not
to say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, even if
only one, PE ?)
Changed the last sentence from:
"then it is recommended to use a single RT per EVI and avoid
additional configuration and operational overhead.”
To
"then it is recommended to use a single RT per EVI and avoid
additional configuration and operational overhead
at the expense of having unwanted MAC addresses on the Leaf PEs."
Ok. I adapted and incorporated this addition into my proposed text
splitting 2.2 into a 2.2.1 and a 2.2.2.
Best,
-Thomas
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
