Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

["Jorge Rabadan (Nokia)" <[e-mail]>]

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 <[e-mail]>
Date: Friday, March 3, 2023 at 11:50 PM
To: Jorge Rabadan (Nokia) <[e-mail]>
Cc: Menachem Dodge <[e-mail]>, [e-mail] <[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Menachem Dodge <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 10, 2023 at 8:10 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis
Some people who received this message don't often get email from [e-mail]<mailto:[e-mail]>. 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]
[phone]<tel:[phone]>
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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 [e-mail]<mailto:[e-mail]>

M 301 502-1347