Hi Thomas,
I have modified section 2.2 (copied below) to elaborate why coloring approach
for Leaf/Root MAC addresses is used in this draft. Also, the use of single RT
for this scenario is mentioned just as “MAY”. Please review the text below and
let me know if you still have questions/comments:
2.2 Scenario 2: Leaf OR Root site(s) per AC
In this scenario, 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 a Root AC or a Leaf AC
(but not both).
+---------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+
|CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2|
+---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+
| |VRF| | | /IP | | |VRF| |
| | | | | | | | | | +---+
| | | | | | | | +--+---ES2/AC2--+CE3|
| +---+ | +------+ | +---+ | (Root) +---+
+---------+ +---------+
Figure 2: Scenario 2
In this scenario, just like the previous scenario (in section 2.1),
two Route Targets (one for Root and another for Leaf) can be used.
However, the difference is that on a PE with both Root and Leaf ACs,
all remote MAC routes are imported and thus there needs to be a way
to differentiate remote MAC routes associated with Leaf ACs versus
the ones associated with Root ACs in order to apply the proper
ingress filtering.
In order to support such ingress filtering on the ingress PE with
both Leaf and Root ACs, one the following two approaches can be used:
A) Color MAC addresses with Leaf (or Root) color before distributing
them in BGP to other PEs depending on whether it is learned on a Leaf
AC (or a Root AC)
B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs
and another for Leaf ACs.
Maintaining two bridge tables per VLAN requires either two lookups be
performed per MAC address in either direction in case of a miss, or
duplicating many MAC addresses between the two bridge tables
belonging to the same VLAN (same E-TREE instance). The duplication of
MAC addresses are need for both locally learned and remotely learned
MAC addresses. Locally learned MAC addresses from Leaf ACs need to be
duplicated onto Root bridge table and locally learned MAC addresses
from Root ACs need to be duplicated onto Leaf bridge table. Remotely
learned MAC addresses from Root ACs need to be copied onto both Root
and Leaf bridge tables. Neither double lookups nor MAC duplications
are considered viable options; therefore, this draft recommends the
use of MAC address coloring for this scenario as detailed in section
3.1.
For this scenario, if for a given EVI, the vast majority of PEs will
have both Leaf and Root sites attached, even though they may start as
Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in
order to alleviate additional configuration overhead associated with
using two RTs per EVI at the expense of having unwanted MAC addresses
on the Leaf-only PEs.
Regards,
Ali
From: Thomas Morin <[email protected]<mailto:[email protected]>>
Organization: Orange
Date: Thursday, December 15, 2016 at 4:12 AM
To: Cisco Employee <[email protected]<mailto:[email protected]>>, Loa Andersson
<[email protected]<mailto:[email protected]>>, "George Swallow -T (swallow - MBO PARTNERS INC
at Cisco)" <[email protected]<mailto:[email protected]>>, Eric Rosen
<[email protected]<mailto:[email protected]>>, BESS
<[email protected]<mailto:[email protected]>>
Cc: Martin Vigoureux
<[email protected]<mailto:[email protected]>>
Subject: Re: shepherd review of draft-ietf-bess-evpn-etree
Hi Ali,
2016-12-13, Ali Sajassi (sajassi):
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.
2nd try. As my 1st response got truncated for some reason.
The reason that impacts more sections than just sec. 2, is that the proposed
2.2.1 would be an alternative option for section 3.1. In section 3.1, the
root/leaf indication for MAC addresses are done via flag-bit defined in section
5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) per RFC
7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN, then that
is an alternative way of doing the same thing described in section 3.1. This
alternative way has big ramifications on the platform as it requires
duplicating MACs and managing multiple bridge tables per VLAN.
Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (they
only require split-horizon locally in Leaf MAC-VRFs), if you state clearly that
the procedures in the document are here to address 2.2.2 and 2.3, then you
don't need to modify the content of the document after section 2 (more
exactly, you will need minor update like changing the current "This scheme
applies to all scenarios described in section 2." in section 3 into "This
scheme applies to scenarios described in 2.2.2 and 2.3".
The "big ramifications" above are then not about section 3, but just the
(platform specific-drawbacks) of 2.2.2 that we have already discussed and that
can be covered in 2.2.2.
Maybe what you really want is to allow for scenario 2.2 to operate with two RTs
which has the benefits of both 2.2.1 and 2.2.2 and non of the drawbacks. So,
maybe we can clarify the current text to make sure that this comes out clearly
– ie, a PE can have single MAC–VRF can have multiple RTs.
You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identified
drawbacks)
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".
I tried to explain the relationship between EVI, MAC-VRF, bridge table, and
VLAN in my previous email per RFC 7432. However, lets park this discussion for
time being as I think it is secondary.
Ok, feel free to revisit if you think that RFC7432 would preclude procedures
that end up being described in this draft
I think you agree that if we have a single solution that has all the benefits
of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much more
preferable with having two solutions each with its own advantages and draw
backs, right? If so, then existing text in 2.2 was intended to convey that.
However, we can clarify it further – e.g, make it clear that for PE with root &
leaf in the same EVI, we can use a single MAC-VRF with two RTs (one for leaf
and another for root).
As said above my key concern is having the document clearly spell out the
motivation for new specs.
If this implies documenting the fact that already existing procedure can be
used, but have drawbacks, then so be it ; there would be no point in hiding
that, right ?
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).
So, hopefully the answers to these three questions are now clear. I believe
your main concern is to ensure that we can apply two-RT approach of sec. 2.1
to sec. 2.2 (and we can still do and still have a single MAC-VRF)
See above.
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 ?
Sure, I can do that. [...]
Ok.
I'll be happy to review a new revision and hopefully post the shepherd review.
Thanks,
-Thomas
(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 addresses
on
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
