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]> 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]> on behalf of Jorge Rabadan (Nokia) < > [email protected]> > *Date: *Friday, March 3, 2023 at 11:06 PM > *To: *Gyan Mishra <[email protected]> > *Cc: *mdodge <[email protected]>, [email protected] <[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]> > *Date: *Friday, March 3, 2023 at 11:50 PM > *To: *Jorge Rabadan (Nokia) <[email protected]> > *Cc: *Menachem Dodge <[email protected]>, [email protected] <[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]> 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]> on behalf of Menachem Dodge < > [email protected]> > *Date: *Friday, February 10, 2023 at 8:10 AM > *To: *[email protected] <[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]. 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 > > [image: signature_3305758272] > > +972-526175734 > > [email protected] > > follow us on Linkedin <https://www.linkedin.com/company/drivenets> > > www.drivenets.com > > [image: DriveNets Network Cloud] > <https://get.drivenets.com/mwc-2023-schedule-a-meeting> > > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
