Hi Sasha,
I agree with you on the following:
1) in the case of EVPN, it is really important to guarantee that MAC-VRFs that
locally represent the same EVI in different PEs are assigned with different RDs.
2) Type 1 RD is easier to achieve above goal, especially when the RD is
auto-generated.
But type 0/2 RD can also achieve above goal, and as far as I know, RFC4364 had
not forbidden this way of using type 0/2 RD. Thus type 0/2 RD don't always
means the same RD on different PE.
Many existing deployments are using type 0/2 RD. I think it will be enough to
point out that "it is important to guarantee that MAC-VRFs that locally
represent the same EVI in different PEs are assigned with different RDs", but
don't have to limit it to using type 1 RD. At least a RR is not necessary to
drop an A-D per ES route with a type 0/2 RD.
Thanks,
Yubao
原始邮件
发件人：AlexanderVainshtein
收件人：王玉保10045807;
抄送人：draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;bess@ietf.org;jorge.raba...@nokia.com;draft-ietf-bess-rfc7432...@ietf.org;
日 期 ：2023年05月16日 14:38
主 题 ：RE: [EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on
rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Yubao,
The scenario in which MAC-VRFs that locally represent the same EVI in
different nodes may have severe implications on the EVPN operation.
E.g., consider the scenario in which:
An EVI that implements LAN-based service interface:
Is instantiated in 3 nodes – PE-1, PE-2 and PE-3,
Is attached to single-homed Ethernet Segments in PE-1 and PE2
MAC-VRFs that locally represent this EVI in PE-1 and PE-2 use the same RD.
Initially, MAC-VRF in PE-1 locally learns reachability to a certain MAC address
M from the single-homed Ethernet Segment to which it is attached and advertises
reachability of this MAC address in an EVPN MAC/IP Advertisement (Type 2)
route. Both the ESI and Ethernet Tag ID field in the NLRI of this route would
be set to all zeroes
Both PE-2 and PE-3 receive and install this route in the FDB of their MAC-VRFs
At some stage, MAC address M moves to a different customer site and is locally
learned by the MAC-VRF in PE-2 from the single-homed Ethernet Segment to which
it is attached. As the result
PE-2 advertises reachability of M advertises reachability of this MAC address
in an EVPN MAC/IP Advertisement (Type 2) route and attaches a MAC Mobility
Extended Community with increased sequence number to this route.
MP-BGP PE-3 receives this route, and notes that the comparable fields of its
NLRI (RD, ES, Ethernet Tag ID, MAC address and IP address (if present) match
these fields of a route that it has received from PE-1 because MAC-VRFs in PE-1
and PE2 have been assigned with the same RD. In this case BGP performs the path
selection process to decide which of these two routes with the same
|destination” should be used.
i. If BGP
decides that the route that has been advertised by PE-1 is preferable to the
route advertised by PE-2 (e.g., if the IGP cost from PE3 to PE-1 happens to be
less than the IGP cost from PE-3 to PE-2) the route advertised by PE-2 will be
silently ignored.
ii.
Therefore, MAC-VRF in PE-3 will not update its FDB, and any traffic it locally
receives with Destination MAC address M will be blackholed.
To me this means that, in the case of EVPN, it is really important to guarantee
that MAC-VRFs that locally represent the same EVI in different PEs are assigned
with different RDs.
Encoding of Route Distinguishers has been defined in Section 4.2 of RFC 4364 .
This document states that with Type 1 RDs:
1. The Administrator subfield is a 4-octet IP address (making it an IPv4
address) state
2. If this address belongs to the public IPv4 address space, it must have
been assigned by the appropriate authority. To me (and, AFAIK, to others) this
means that this IP address has been assigned to node in which the VRF (or
MAC-VRF) resides.
3. Usage of addresses from the private IP address space is strongly
discouraged.
These definitions guarantee that RDs assigned to VRFs (and MAC-VRFs) residing
in different PEs will be always different.
With Type 0 and Type 2 RDs the same document states that the Administrator
subfield must be a 2-octet (with Type 0 RDs) or a 4-octet (with Type 2 RDs)
Autonomous System Number.
If this number is from the publics AS Number space, it must have been assigned
by the appropriate authority while usage AS Numbers from the private space is
strongly discouraged. To me (and, AFAIK, to others) this means that this AS
Number has been assigned to the AS containing the node in which the VRF (or
MAC-VRF) resides, and, therefore would be the same for all the nodes within
the same AS. Therefore, there are no guarantees that VRFs (or MAC-VRFs) that
locally represent the same EVI in different nodes would use different RDs.
Please note also that both RFC 7432 and of 7432bis draft pay special attention
to the so-called “Unique VLAN EVPN scenario” and define special procedures for
deriving both the RD and the RT of all the MAC-VRFs that locally represent such
an EVPN instance from the VLAN ID value associated with this EVPN. AFAIK, many
implementations have explicitly incorporated this mechanism in their
implementations so tha the operators using these implementations, only confiure
the same “EVPN ID” value (the same in all the PEs whener this EVPN instance is
instantiated) and letting the PEs to auto-derive both the RDs and RTs of the
corresponding MAC-VRFs. This scheme has been also adopted by the authors of the
(expired) EVPN YANG data model draft.
The bottom line:
I do not see any operational advantage in assigning Type 0 or Type 2 RDs to
MAC-VRFs, and I see quite a few potential pifalls with such usage.
Therefore:
I think that both the restriction to just Type 1 RDs in EVPN per ES Ethernet
A-D routes and recommendation to assign Type 1 RDs for MAC-VRFs should be
retained in 7432bis
I also suggest adding a recommendation in 7432bis to use the same IP address in
the Administartor subfield of Type 1 RDs of all EVPN routes advertised by a
specific PE.
Regards,
Sasha
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Sent: Tuesday, May 16, 2023 7:07 AM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Cc: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; rfc7432...@ietf.org;
bess@ietf.org; jorge.raba...@nokia.com
Subject: [EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on
rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Sasha,
When a MAC-VRF use a type 1 RD, is it expected that the RD of the EVPN
Instance has differnet RD on different PE? When a MAC-VRF use a type 2 RD, is
it expected that the RD of the EVPN Instance has the same RD on different PE?
In many deployment, whether the RD of the EVPN Instance has different RD-value
on different PE is independent of the RD-type.
The RD of A-D per ES route is limited to type 1 RD just because orther RD-types
are assumed that they will have the same value for a specified EVI on different
PEs.
Is my understanding correct?
Another way is constructing each A-D per ES route separately by using the RD of
corresponding MAC-VRF, as described in
draft-rabadan-bess-evpn-inter-domain-opt-b.
Thanks,
Yubao
原始邮件
发件人：AlexanderVainshtein
收件人：王玉保10045807;
抄送人：draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;rfc7432...@ietf.org;bess@ietf.org;jorge.raba...@nokia.com;
日 期 ：2023年05月15日 21:24
主 题 ：RE: [EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on rfc7432bis and
draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Yubao,
Can you please clarify what you mean by “another way to construct A-D per ES
route has been in sight”?
From my POV using Type 1 RDs in all types of EVPN routes has multiple
advantages – starting from the fact that it prevents RRs suppressing routes
advertised by different PEs as part of the BGP path selection process. (The
same actually applies for VPN-IP routes as well). IMHO and FWIW the operators
should be discouraged from using other RD types even when it is not already
prohibited.
The bottom line: For the record I strongly oppose the proposal to relax the
limitation on RDs in EVPN per ES Ethernet A- (Type 1) routes that exists from
the -00 revision of the EVPN draft.
Regards,
Sasha
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Sent: Monday, May 15, 2023 3:56 PM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Cc: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; rfc7432...@ietf.org;
bess@ietf.org; jorge.raba...@nokia.com
Subject: [EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on rfc7432bis and
draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Sasha,
Thanks for your helpful notes.
There is only one method to determine the RD of A-D per ES routes in the
original years of RFC7432, but now there are at least two methods to determine
the RD of A-D per ES routes.
If it is the only reason why RFC7432 restrict the RD of A-D per ES route to
type 1 RD, maybe it is a good chance for the restriction to be relaxed, because
another way to construct A-D per ES route has been in sight.
The original way can still be “RECOMMENDED”while other ways don't have to be
forbidden. Maybe we can say that it is out of the scope of rfc7432bis (but not
forbidden).
If RFC7432 is not revised, people who decide not to assign Type 1 RDs to
MAC-VRFs should bear the consequences in mind, including non-applicability of
the solution suggested in Section 3.1.2 of the EVPN Inter-Domain Option B
draft, as you point out in another mail. But when RFC7432 is revised and
rfc7432bis is still a draft, I think it will be better to take new scenarios
into account.
Especially on a RR node, according to RFC7432 or current rfc7432bis, a RR has
to discard the A-D per ES routes which don't have a type 1 RD, but a RR is not
responsible for selecting different RD for different set of route-targets at
all. A RR has no difficulty to permit a A-D per ES route with other RD-type to
pass through, while it has to discard it according to current rfc7432bis.
Thanks,
Yubao
原始邮件
发件人：AlexanderVainshtein
收件人：王玉保10045807;
抄送人：draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;rfc7432...@ietf.org;bess@ietf.org;jorge.raba...@nokia.com;
日 期 ：2023年05月15日 16:09
主 题 ：RE: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and
draft-rabadan-bess-evpn-inter-domain-opt-b
Yubao,
Please note that an EVPN PE that s attached to a MH ES, generally speaking, has
to generate multiple per-ES A-D routes with the ESI of this MH ES in their NLRI.
This happens because:
1. The set of these routes, in its entirety, must carry the Route Targets
of all the EVI that are local attached to this MH ES
2. The number of Route Targets that can be caried in a single BGP Update
message is limited.
For BGP path selection process not to suppress some of these routes, these
routes in this set must include different RDs in their NLRI.
Since the set of these routes changes dynamically as new EVIs are attached
to/detached from the MS EH in question, these RDs have to be auto-generated by
the PE itself.
This, in its turn requires usage of Type 1 RDs because these can be
auto-generated by the PEs while remaining globally unique.
The bottom line: Restriction of RDs used in the NLRI of per-ES Ethernet A-D
routes cannot be relaxed.
Hope this helps.
Regards,
Sasha
From: BESS <bess-boun...@ietf.org> On Behalf Of wang.yub...@zte.com.cn
Sent: Monday, May 15, 2023 10:40 AM
To: jorge.raba...@nokia.com
Cc: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; rfc7432...@ietf.org;
bess@ietf.org
Subject: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and
draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Jorge,
I think the description in draft-rabadan-bess-evpn-inter-domain-opt-b is OK.
But I don't know why the RD of AD per ES route is limited to type 1 RD. That's
why I talk about this together with rfc7432bis.
If the scenario from draft-rabadan-bess-evpn-inter-domain-opt-b has shown out
that it will be useful for the RD-type of AD per ES route being consistence
with MAC-VRF RD, I think maybe it is not necessary for rfc7432bis to keep these
restraints unchanged. I notice that you are also a co-author of rfc7432bis, how
do you think from the viewpoint of rfc7432bis?
Thanks,
Yubao
原始邮件
发件人：JorgeRabadan(Nokia)
收件人：王玉保10045807;draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;rfc7432...@ietf.org;
抄送人：bess@ietf.org;
日 期 ：2023年05月13日 00:23
主 题 ：Re: Discussion on rfc7432bis and
draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Yubao,
Thanks for reviewing the document.
I don’t see any conflicting information:
1. On one hand the use of type 1 RD for MAC-VRF is RECOMMENDED in
rfc7432bis, which means that normally people will have a type 1 RD in MAC-VRFs.
If you don’t follow that strong recommendation for the MAC-VRF RD, you can’t
use the documented solutions in 3.1.2 or 3.1.3
2. On the other hand draft-rabadan-bess-evpn-inter-domain-opt-b is
documenting some existing solutions, but not specifying or imposing any in
particular.
So I don’t think there is conflicting information. But if you still think we
should clarify that in draft-rabadan-bess-evpn-inter-domain-opt-b we’ll be
happy to do it.
Thanks.
Jorge
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Friday, May 12, 2023 at 4:54 AM
To: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org
<draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>, Jorge Rabadan (Nokia)
<jorge.raba...@nokia.com>, rfc7432...@ietf.org <rfc7432...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Discussion on rfc7432bis and
draft-rabadan-bess-evpn-inter-domain-opt-b
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Hi Authors,
It seems that draft-rabadan-bess-evpn-inter-domain-opt-b has conflicting
discription with rfc7432 about the RD-type of AD per ES routes:
Section 3.1.3 of draft-rabadan-bess-evpn-inter-domain-opt-b-00: "If that is
the case, now the A-D per ES routes can use the route distinguisher assigned to
the EVPN Instance (or VRF), which is the same one used by the routes type 2 or
5 for the EVI."
Section 8.2.1 of rfc7432bis: "The Route Distinguisher MUST be a Type 1 RD
[RFC4364]. The value field comprises an IP address of the PE (typically, the
loopback address) followed by a number unique to the PE."
The RD of EVI is not always a Type 1 RD but rfc7432 says that the RD of AD per
ES route MUST be a Type1 RD. If it is not necessary to prevent other RD-types
from being used in AD per ES routes, is it better for rfc7432bis to change the
"MUST" to "MAY" ? I think such change is also compatible.
Thanks,
Yubao
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential and/or
proprietary for the sole use of the intended recipient. Any review, disclosure,
reliance or distribution by others or forwarding without express permission is
strictly prohibited. If you are not the intended recipient, please notify the
sender immediately and then delete all copies, including any attachments.
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential and/or
proprietary for the sole use of the intended recipient. Any review, disclosure,
reliance or distribution by others or forwarding without express permission is
strictly prohibited. If you are not the intended recipient, please notify the
sender immediately and then delete all copies, including any attachments.
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential and/or
proprietary for the sole use of the intended recipient. Any review, disclosure,
reliance or distribution by others or forwarding without express permission is
strictly prohibited. If you are not the intended recipient, please notify the
sender immediately and then delete all copies, including any attachments._______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
