Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df
Hi Stephane, Thanks for the review and my apologies for the delay. We just posted a new revision. As usual, very good points. Please see in-line. Thx Jorge From: "slitkows.i...@gmail.com" Date: Wednesday, February 26, 2020 at 3:20 PM To: "draft-ietf-bess-evpn-pref...@ietf.org" , 'BESS' Cc: "bess-cha...@ietf.org" Subject: Shepherd's Review of draft-ietf-bess-evpn-pref-df Resent-From: Resent-To: , , , , , , Resent-Date: Wednesday, February 26, 2020 at 3:20 PM Hi Authors, Here is my review of the document: Please look at the nits and fix them. https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-pref-df-05.txt [Jorge] done. Section 3: - Is the DF preference field only there when DF Alg=2 ? I mean if DF Alg !=2, can the reserved field be encoded differently ? This should be clear IMO. [Jorge] ok, added: “If the DF Alg is different than Alg 2, these two octets can be encoded differently.” Section 4.1: “ Note that, by default, the Highest-Preference is chosen for each ES or vES, however the ES configuration can be changed to the Lowest-Preference algorithm as long as this option is consistent in all the PEs in the ES. I don’t think it is a good idea to open this modification. People can play with preference values to achieve the required behavior while always keeping high pref. We have no way to ensure consistency, except if we advertise the behavior as part of the exct. Consistency of DF election is key and needs to be ensured as much as we can. [Jorge] the idea is have the highest preference as default (maybe use normative language?), which means that it will work fine. Opening to lowest is to give more flexibility, knowing that if the user has to change the config from the default, they will do it in all the PEs of the ES. In case of equal Preference in two or more PEs in the ES, the tie-breakers will be the DP bit and the lowest IP PE, in that order. For instance: The sentence is not clear enough and must use normative language. Example: In case of equal Preference between two or more PEs in the ES, an implementation MUST first prefer PEs advertising the DP bit set and then prefer the PE with the lowest IP address. Which IP address are we talking about exactly here ? [Jorge] I change this text to: “In case of equal Preference in two or more PEs in the ES, the DP bit and the lowest IP of the candidate PEs are used as tie-breakers. After selecting the PEs with the highest Preference value, an implementation MUST first select the PE advertising the DP bit set, and then select the PE with the lowest IP address (if the DP bit selection does not yield a unique candidate). The PE's IP address is the address used in the candidate list and it is derived from the Originating Router's IP address of the ES route. Some examples of the use of the DP bit and IP address tie-breakers follow…” Section 4.3: Typo on: A new "Don't Preempt Me" capability is defined on a per-PE per-ES Basis Should be : “A new "Don't Preempt Me" capability is defined on a per-PE basis [Jorge] actually the DP capability is defined per ES on each PE. So I changed it to the following to make it clear: “A new "Don't Preempt Me" capability is defined on a per-PE/per-ES basis,” s/however this document do not enforces the/however this document does not enforce the/ Question: Why don’t you enforce consistency ? What is the side effect of not ensuring consistency ? [Jorge] The “SHOULD” term is because normally you would expect all the PEs in the ES to be consistent in the use of DP. But the procedures are really independently run by each PE and there is no negative side effect if only part of the PEs are configured as non-revertive. Former DF PEs configured without this capability will preempt the DF when they recover after a failure, but that is of course expected. In any case, I added: “In case of inconsistency in the support of the DP capability in the PEs of the same ES, non-revertive behavior is not guaranteed.” “When PE3's vES2 comes back up, PE3 will start a boot-timer (if booting up) or hold-timer (if the port or EVC recovers). That timer will allow some time for PE3 to receive the ES routes from PE1 and PE2. » Are you changing the way the DF election works ? Usually, PE advertises its route and then wait to receive other routes. [Jorge] those timers are on top of the FSM defined in RFC8584, e.g. we need to give some extra time before the ES goes up and we advertise the ES route, if the ES is configured with the DP capability. This is because the advertised preference and DP values may not be the same as the configured ones, and the ‘in-use’ values will depend on the other ES routes in the ES. If we advertise the ES route immediately after the ES is up, we may not have received the other ES routes and we don’t know what “in-use” values
[bess] I-D Action: draft-ietf-bess-evpn-pref-df-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : Preference-based EVPN DF Election Authors : J. Rabadan S. Sathappan T. Przygienda W. Lin J. Drake A. Sajassi S. Mohanty Filename: draft-ietf-bess-evpn-pref-df-06.txt Pages : 16 Date: 2020-06-19 Abstract: The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the PE responsible for sending Broadcast, Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/ network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single-active multi-homing. The DF is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default DF Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the DF across different Ethernet Tags in the ES, there are some use-cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on-demand DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes an extension to the Default DF election procedures so that the above requirements can be met. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-06 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-pref-df-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Integrated Routing and Bridging in EVPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Integrated Routing and Bridging in EVPN' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-07-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract EVPN provides an extensible and flexible multi-homing VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and End Devices while maintaining the multi-homing capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3352/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Request BESS WG adoption for draft-dunbar-bess-bgp-sdwan-usage-07
Correcting Stephane’s email address. From: "Bocci, Matthew (Nokia - GB)" Date: Friday, 19 June 2020 at 10:00 To: Linda Dunbar , "bess@ietf.org" , "stephane.litkow...@orange.com" , "Mankamana Mishra (mankamis)" Subject: Re: Request BESS WG adoption for draft-dunbar-bess-bgp-sdwan-usage-07 Hi Linda This is in our queue (see the WG Wiki at https://trac.ietf.org/trac/bess/wiki). Expect a poll for adoption shortly. Matthew From: Linda Dunbar Date: Thursday, 18 June 2020 at 18:09 To: "bess@ietf.org" , "Bocci, Matthew (Nokia - GB)" , "stephane.litkow...@orange.com" , "Mankamana Mishra (mankamis)" Subject: RE: Request BESS WG adoption for draft-dunbar-bess-bgp-sdwan-usage-07 Matthew and Stephane It has been almost 2 months since our presentation at the IETF107 virtual meeting and our request for WG adoption. Can you let us know what else we need to do to move forward to the WG Adoption call? Thank you very much. Linda From: Linda Dunbar Sent: Wednesday, April 29, 2020 11:34 AM To: bess@ietf.org; Bocci, Matthew (Nokia - GB) ; stephane.litkow...@orange.com; Mankamana Mishra (mankamis) Subject: Request BESS WG adoption for draft-dunbar-bess-bgp-sdwan-usage-07 Matthew and Stephane Thank you for the opportunity for us to present the draft at April 28 Interim meeting. https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/?include_text=1 We understand that the draft has been on the https://trac.ietf.org/trac/bess/wik as Candidates for WG Adoption. We are asking BESS WG Chairs to start the WG Adoption call for the draft. This draft demonstrates how & why BGP-based control plane can be effectively used for large scale SDWAN overlay networks, which is very beneficial to the industry and to other SDOs that have on-going SDWAN projects, such as MEF, BBF, ONUG etc. So that they don’t have to re-invent the wheel. Thank you very much. Linda Dunbar ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Request BESS WG adoption for draft-dunbar-bess-bgp-sdwan-usage-07
Hi Linda This is in our queue (see the WG Wiki at https://trac.ietf.org/trac/bess/wiki). Expect a poll for adoption shortly. Matthew From: Linda Dunbar Date: Thursday, 18 June 2020 at 18:09 To: "bess@ietf.org" , "Bocci, Matthew (Nokia - GB)" , "stephane.litkow...@orange.com" , "Mankamana Mishra (mankamis)" Subject: RE: Request BESS WG adoption for draft-dunbar-bess-bgp-sdwan-usage-07 Matthew and Stephane It has been almost 2 months since our presentation at the IETF107 virtual meeting and our request for WG adoption. Can you let us know what else we need to do to move forward to the WG Adoption call? Thank you very much. Linda From: Linda Dunbar Sent: Wednesday, April 29, 2020 11:34 AM To: bess@ietf.org; Bocci, Matthew (Nokia - GB) ; stephane.litkow...@orange.com; Mankamana Mishra (mankamis) Subject: Request BESS WG adoption for draft-dunbar-bess-bgp-sdwan-usage-07 Matthew and Stephane Thank you for the opportunity for us to present the draft at April 28 Interim meeting. https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/?include_text=1 We understand that the draft has been on the https://trac.ietf.org/trac/bess/wik as Candidates for WG Adoption. We are asking BESS WG Chairs to start the WG Adoption call for the draft. This draft demonstrates how & why BGP-based control plane can be effectively used for large scale SDWAN overlay networks, which is very beneficial to the industry and to other SDOs that have on-going SDWAN projects, such as MEF, BBF, ONUG etc. So that they don’t have to re-invent the wheel. Thank you very much. Linda Dunbar ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
