I would think that based DF is good with simplest one. There are different type of deployments and different carving can be used.
Mankamana From: BESS <[email protected]> on behalf of Gyan Mishra <[email protected]> Date: Sunday, March 5, 2023 at 10:40 PM To: Satya Mohanty (satyamoh) <[email protected]> Cc: Jorge Rabadan (Nokia) <[email protected]>, [email protected] <[email protected]>, mdodge <[email protected]> Subject: Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis Hi Satya Backwards compatibility is critical and completely understand. However let’s say all routers are upgraded to support 8584 and Type 1 HRW and negotiate the AC-DF capability exchange codepoint P2P then would all routers supporting type 1 automatically start using Type 1 HRW Alg? Kind Regards Gyan On Mon, Mar 6, 2023 at 12:21 AM Satya Mohanty (satyamoh) <[email protected]<mailto:[email protected]>> wrote: Thanks Jorge. Gyan, indeed all the three algorithms have their use-cases. As pointed out below in case of inconsistency (the “Alg type”) in the DF election extended community for a given ES, it was decided that the DF election must default to the modulo-based simply because modulo-based was proposed first and all existing deployments already had it, before the other two (Pref-based and HRW) came into existence. https://www.rfc-editor.org/rfc/rfc8584.html#section-2.2.1 Thanks, --Satya From: BESS <[email protected]<mailto:[email protected]>> on behalf of Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>> Date: Friday, March 3, 2023 at 11:06 PM To: Gyan Mishra <[email protected]<mailto:[email protected]>> Cc: mdodge <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis Hi Gyan, I agree with your two first statements, but I’m afraid I don’t agree with this one: “I would think HRW would be the new default algorithm used for DF election and would not be a knob as it fixes the major deficiencies with the modulus algorithm.” The modulo-based DF algorithm remains the default algorithm in case of inconsistency in the Ethernet Segment peers. It uses DF Alg 0, while HRW uses type 1 and Preference type 2. HRW is not obsoleting the modulo-based or anything like that. The three algorithms are widely used in networks, and while the default one has limitations, it is simple and works out in many networks. Thank you! Jorge From: Gyan Mishra <[email protected]<mailto:[email protected]>> Date: Friday, March 3, 2023 at 11:50 PM To: Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>> Cc: Menachem Dodge <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/ext for additional information. Hi Jorge As defined in RFC 8584 AC-DF and HRW are independent of each other. RFC 8584 updates RFC 7432, however RFC 7432 bis does not update any aspect of RFC 8584 including HRW as you stated. I would think HRW would be the new default algorithm used for DF election and would not be a knob as it fixes the major deficiencies with the modulus algorithm. Thanks Gyan On Fri, Feb 10, 2023 at 2:01 PM Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi Menachem, The way I see it, draft-ietf-bess-rfc7432bis will obsolete RFC7432, but it does not update or change RFC8584, so I don’t think draft-ietf-bess-rfc7432bis needs to repeat the aspects of RFC8584. In particular, the AC-DF, as the other capabilities defined in other documents, is a capability that can be turned on or off. While it is very useful in many cases, it actually needs to be disabled in some others, e.g., draft-ietf-bess-evpn-mh-pa-07<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-pa-07> So the answer to your second question could be that the AC-DF capability should be configurable in the implementation, and used on all cases where issues with individual Attachment Circuits may create blackholes. However, it has to be disabled in case of port-active multi-homing. My 2 cents.. Thanks. Jorge From: BESS <[email protected]<mailto:[email protected]>> on behalf of Menachem Dodge <[email protected]<mailto:[email protected]>> Date: Friday, February 10, 2023 at 8:10 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis Some people who received this message don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hello All, In section 8.5 of draft-ietf-bess-rfc7432bis there is a reference to the Finite State Machine in section 2.1 of RFC 8584. However, in section 4 of RFC 8584 the AC Influenced DF Election Capability is described and it states that this updates Step 3 of the procedure for service carving of RFC 7432. Shouldn’t this AC-DF update be mentioned in the procedures of section 8.5 of draft-ietf-bess-rfc7432bis? Is AC Influenced DF Election the preferred DF election method ? According to RFC 8584 “ The procedure discussed in this section is applicable to the DF election in EVPN services [RFC7432<https://datatracker.ietf.org/doc/html/rfc7432>] and EVPN VPWS [RFC8214<https://datatracker.ietf.org/doc/html/rfc8214>]. “ Thank you kindly. Best Regards, Menachem Dodge System Architect [signature_3305758272] +972-526175734<tel:+972-526175734> [email protected]<mailto:[email protected]> follow us on Linkedin<https://www.linkedin.com/company/drivenets> www.drivenets.com<http://www.drivenets.com/> [DriveNets Network Cloud]<https://get.drivenets.com/mwc-2023-schedule-a-meeting> _______________________________________________ BESS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
