Jorge,
Lots of thanks for an encouraging response.
I can imagine an implementation which would derive Type 1 RDs of all per-ES
Ethernet A-D routes from one loopback address and all the rest of Type 1 RDs –
from another loopback address.
Explicitly recommending to derive all Type 1 RDs of all EVPN routes from the
same (loopback) address would at least discourage such implementations.
So if you can add such a sentence, please do that!
Regards,
Sasha
From: Jorge Rabadan (Nokia) <[email protected]>
Sent: Tuesday, May 30, 2023 4:23 PM
To: Alexander Vainshtein <[email protected]>
Cc: [email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and
draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Sasha,
About your suggestion on 7432bis, it’s kind of implicit, but I see no harm in
adding a sentence.
Thanks.
Jorge
From: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Date: Sunday, May 28, 2023 at 1:26 AM
To: Jorge Rabadan (Nokia)
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: RE: [EXTERNAL] Re: [bess] 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.
Jorge,
Lots of thanks for your response.
Please see inline below.
Regards,
Sasha
From: Jorge Rabadan (Nokia)
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, May 16, 2023 11:42 PM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and
draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Sasha,
However, neither 7432bis nor any other RFC or standard I am aware of says that
the same IP address PE address of the PE MUST (or, at least, SHOULD) be used as
the Administrator field of Type 1 RDs in per-ES A-D routes and Type 1 RDs
assigned to MAC-VRFs. And this is obviously a precondition for using the
solution suggested in Section 3.1.2.
[jorge] the example in section 3.1.2 should be enough to clarify that the
administrator part of the RD is the same. Let us know if that is not the case
please.
[[Sasha]] This was a comment about 7432bis. IMHO and FWIW it makes sense to
clarify in this document that the Administrator part of Type 1 RDs used in all
the EVPN routes advertised by a specific PE SHOULD be the same. What do you
think?
I also have some doubts regarding solution that is documented in Section 3.1.3
of the EVPN Inter-Domain Option B draft because:
· Only implementations that do not use OPTIONAL per EVI EVPN A-D routes
can benefit from this solution. In all other cases the per EVI Mass Withdrawal
solution (documented in Section 3.1 of the draft) would work exactly as well
· Such implementations could not benefit from aliasing and/or backup path
EVPN mechanisms (which inherently rely on per EVI EVPN A-D routes) , thus
severely compromising any benefits of the Mass Withdrawal mechanisms.
[jorge] as discussed earlier, this is documenting viable existing solutions
with their trade-offs, not mandating any particular one. Both things you point
out are described in 3.1.3 section. If you don’t think so, please let us know.
[[Sasha]] I have misspoken – my apologies. I should say that I have some doubts
regarding the practical value of the solution documented in Section 3.1.3 of
the EVPN Option-B draft. The solution itself is quite clear.
Thanks!
Jorge
From: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Date: Sunday, May 14, 2023 at 10:31 AM
To: Jorge Rabadan (Nokia)
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: RE: [EXTERNAL] Re: [bess] 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.
Jorge, Yubao and all,
A couple of comments.
The current version of
7432bis<https://clicktime.symantec.com/15t5Zt9SEXGagfrZxwR9z?h=gGcib8S3C26TGyskaohEYo1_njxaFnOgTQKSs6yx1Ww=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-07>
says that:
· Per-ES EVPN A-D routes MUST use Type 1 RDs with the Administrator field
comprising “an IP address of the PE (typically, the loopback address)”
· Per-EVI EVPN A-D routes and EVPN MAC/IP Advertisement routes advertised
by an EVPN Instance locally represented by a MAC-VRF use the RD that is
assigned to this MAC-VRF, and usage of Type 1 RD with the Administrator field
comprising “an IP address of the PE (typically, the loopback address)” is
RECOMMENDED.
RFC 2119 says that “the adjective "RECOMMENDED", mean that there may exist
valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course”. Therefore, I concur with Jorge that 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<https://clicktime.symantec.com/15t5eiLih8xB6cgVWVpJc?h=op8TeX0Vsru5FkDFaRdxWuqgdODq44ba2I1LrFCkDsg=&u=https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b%23section-3.1.2>.
However, neither 7432bis nor any other RFC or standard I am aware of says that
the same IP address PE address of the PE MUST (or, at least, SHOULD) be used as
the Administrator field of Type 1 RDs in per-ES A-D routes and Type 1 RDs
assigned to MAC-VRFs. And this is obviously a precondition for using the
solution suggested in Section 3.1.2.
IMHO and FWIW adding a corresponding RECOMMENDATION to the 7432bis draft would
be very much in place.
I also have some doubts regarding solution that is documented in Section 3.1.3
of the EVPN Inter-Domain Option B draft because:
· Only implementations that do not use OPTIONAL per EVI EVPN A-D routes
can benefit from this solution. In all other cases the per EVI Mass Withdrawal
solution (documented in Section 3.1 of the draft) would work exactly as well
· Such implementations could not benefit from aliasing and/or backup path
EVPN mechanisms (which inherently rely on per EVI EVPN A-D routes) , thus
severely compromising any benefits of the Mass Withdrawal mechanisms.
Hopefully these notes will be useful.
Regards,
Sasha
Regards,
Sasha
From: BESS <[email protected]<mailto:[email protected]>> On Behalf Of
Jorge Rabadan (Nokia)
Sent: Friday, May 12, 2023 7:23 PM
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: [EXTERNAL] Re: [bess] 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:
- 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
- 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: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Date: Friday, May 12, 2023 at 4:54 AM
To:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
Jorge Rabadan (Nokia)
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
