Re: [bess] [Pals] [EXTERNAL] [Technical Errata Reported] RFC7432 (7758)

[Alexander Vainshtein <[e-mail]>]

Andy,
Lots of thanks for a prompt response.
There seems to be a consensus about the disposition of this Erratum, so I do not expect any problems.

Regards,
Sasha

From: Andrew G. Malis <[e-mail]>
Sent: Thursday, January 11, 2024 3:04 PM
To: Alexander Vainshtein <[e-mail]>
Cc: Pavel Mykhailyk <[e-mail]>; RFC Errata System <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Pals] [EXTERNAL] [Technical Errata Reported] RFC7432 (7758)

Sasha,

Andrew will take care of it.

Cheers,
Andy


On Thu, Jan 11, 2024 at 5:37 AM Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:
Pavel,
Lots of thanks for your email.
Looks as we are aligned😊. I am not sure if the reporter of an Erratum can revoke it (never tried this).


Regards,
Sasha

From: Pavel Mykhailyk <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, January 11, 2024 12:33 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: RFC Errata System <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758)

Hi
Sorry, looks like i just misunderstood some terms, so ES route means EVPN Type 4 (not 1) -  you are absolutely right, it is used for DF and limited to PEs that are connected to MH Po.

Thanks for clarification
With Regards

чт, 11 янв. 2024 г. в 11:56, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>:
Hi all,

IMHO and FWIW the corrected text proposed in this Erratum is technically incorrect, and. Therefore, the Erratum must be rejected.

Ethernet Segment (EVPN Type 4) routes are used solely for discovery of all PEs that participate in the process of election of the Designated Forwarder (DF)for the specific MH ES, and their parameters that affect the election process (e.g., DF Election algorithm and its parameters).  This includes all the PEs that are attached to the MH ES in question, and none other.

The PEs that are not attached to the MH ES in question do not participate in the DF election and, by design, are not aware of the DF election results.
In the case of All-Active multi-homing, there is no need for such PEs to be aware of these results.
The case of Single-Active multi-homing is addressed by the following statement from Section 8.4 of RFC 7432 (the relevant text is highlighted):

   The backup path is a closely related function, but it is used in
   Single-Active redundancy mode.  In this case, a PE also advertises
   that it has reachability to a given EVI/ES using the same combination
   of Ethernet A-D per EVI route and Ethernet A-D per ES route as
   discussed above, but with the "Single-Active" bit in the flags of the
   ESI Label extended community set to 1.  A remote PE that receives a
   MAC/IP Advertisement route with a non-reserved ESI SHOULD consider
   the advertised MAC address to be reachable via any PE that has
   advertised this combination of Ethernet A-D routes, and it SHOULD
   install a backup path for that MAC address.

AFAIK, EVPN implementation that follow the design defined in 7432 have been widely deployed for years.

My 2c,
Sasha

From: Pals <[e-mail]<mailto:[e-mail]>> On Behalf Of RFC Errata System
Sent: Thursday, January 11, 2024 10:03 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758)

The following errata report has been submitted for RFC7432,
"BGP MPLS-Based Ethernet VPN".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7758<https://www.rfc-editor.org/errata/eid7758>

--------------------------------------
Type: Technical
Reported by: Pavel Mykhailyk <[e-mail]<mailto:[e-mail]>>

Section: 8.1.1

Original Text
-------------
The Ethernet Segment route filtering MUST be done such that the
Ethernet Segment route is imported only by the PEs that are
multihomed to the same Ethernet segment

Corrected Text
--------------
The Ethernet Segment route filtering MUST be done such that the
Ethernet Segment route is imported only by the PEs that are
connected to same EVI

Notes
-----
In all text in context of evpn-multihoming term ES used for logical set of links - distributed PortChannel when CE use several links to different PEs as single aggregate link. But in section 8.1.1 term ES can't be used in same way, becouse ES routes must be distributed for all PE that hold same VLAN. For example PE1 and PE2 connected to CE1 with EVPN-MH PortChannel (ESI-1) and use VLAN 10, CE2 connected to PE3 and use VLAN 10 but not use any aggregation - not included to any ES. PE3 build mac table for CE1 mac and must use ESI-1 as next-hop, so it must apply ES route and not filter it, regardles of local connection to ES in terms of EVPN-MH PortChannel. So each PE connected to EVI import this route

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7432 (draft-ietf-l2vpn-evpn-11)
--------------------------------------
Title : BGP MPLS-Based Ethernet VPN
Publication Date : February 2015
Author(s) : A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, W. Henderickx
Category : PROPOSED STANDARD
Source : Layer 2 Virtual Private Networks
Area : Routing
Stream : IETF
Verifying Party : IESG

_______________________________________________
Pals mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pals<https://www.ietf.org/mailman/listinfo/pals>


Disclaimer

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.
_______________________________________________
Pals mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pals<https://www.ietf.org/mailman/listinfo/pals>