Re: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04

[Krzysztof Grzegorz Szarkowicz <[e-mail]>]

Hi Luc,

Restricting Modulo function to octets 3-7, means, we are restricting optimized operation of draft-brissette-bess-evpn-mh-pa-04 to deployments, where ESI is differentiated within the subset of octets specified in this draft. While I agree, that best practice is to differentiate ESIs within octets 1-6 (or 2-7 -> depending how we number them), I see no reason to put such restriction, as I don’t see any complexity here, when all 10 octets are used instead of 5 octets.

My teenager son, who just recently started to learn python, has prepared python script to calculate IBAN (International Back Account Number) CHECKSUM (https://www.iban.com/iban-checker <https://www.iban.com/iban-checker>):

IBAN CHECKSUM

This is the first and most important check we perform.
The IBAN check digit consists of two digits in positions 3 and 4 of the IBAN.
It is calculated using the MOD97 algorithm and provides the primary integrity check for the IBAN standard.
Supported for all 116 countries.


within 20 minutes (and the script has only 8 lines). And, IBANs are longer (up to 24 digits).


So, what is the complexity here, that would mandate to restrict the Modulo function to 5 octets only?



Regards,
Krzysztof Grzegorz Szarkowicz
Juniper Networks




> On 2020 -Jan-21, at 19:05, Luc André Burdet <[e-mail]> wrote:
> 
> Hi Krystof,
>  
> Already tracking issue #1 for update, thanks for picking it up though
>  
> Issue #2 we’ve discussed before but the entropy here is meant to provide some delta “between ES” for DF... RFC7432 modulo doesn’t go into complicated HRW and this should not either...
> The specific set of bytes chosen are supposed to vary some but don’t have to vary tremendously. VLAN-ID/EVI in 7432 doesn’t very tremendously either.
> The byte(s) definitely vary more than byte 10 in previous versions which, for some ESI types, is 00...
> Why use 10 bytes for an even/odd decision on 2PE when basically... one is enough? I don’t see the need to bring in HRW’s complexity to simply match RFC7432 DF-modulo.
> FYI we have added a section specifically addressing HRW df-mode.
>  
> Regards,
> Luc André Burdet |  Cisco  |  [e-mail] <mailto:[e-mail]>  |  Tel: [phone]
>  
>  
> From: BESS <[e-mail] <mailto:[e-mail]>> on behalf of Krzysztof Grzegorz Szarkowicz <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, January 21, 2020 at 12:19
> Cc: "[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]>>
> Subject: Re: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04
>  
> Hello, 
>  
>  
> I have two comments regarding section 4.2 
>  
>  
> Comment 1:
>  
> draft-brissette-bess-evpn-mh-pa-04: “ES-Import RT community inherits from ESI only byte 1-7,”
>  
> As per RFC 7432, ES-Import RT community inherits from ESI only 6 (not 7, as in draft-brissette-bess-evpn-mh-pa-04) octets from ESI
> 
> 
> 
> 
> Comment 2:
> 
> 
> What is the benefit of restricting Modulo calculation to 5 octets only (draft-brissette-bess-evpn-mh-pa-04 specifies here octets 3-7), instead of taking all 9 (or even all 10) octets into account. For example, for HRW, RFC 8584 already describes computing a 32 bit CRC over the concatenation of Ethernet Tag and ESI, so *all 10* ESI octets are used for better entropy. What is the benefit of restricting here for only subset of ESI octets?
>  
>  
>  
> Thanks,
> Krzysztof
>  
> 
> 
> On 2020 -Jan-21, at 17:58, Acee Lindem (acee) <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Support – though I’ve always thought MC-LAG was a hack, it is part of the landscape.
> Thanks,
> Acee
>  
> From: BESS <[e-mail] <mailto:[e-mail]>> on behalf of "Bocci, Matthew (Nokia - GB)" <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, January 21, 2020 at 9:51 AM
> To: "[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]>" <[e-mail] <mailto:[e-mail]>>
> Subject: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04
>  
> Hello,
>  
> This email begins a two-weeks WG adoption poll for draft-brissette-bess-evpn-mh-pa-04 [1] .
>  
> Please review the draft and post any comments to the BESS working group list.
>  
> We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>  
> If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors.
>  
> Currently, there are no IPR disclosures against this document.
>  
> If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.
>  
> This poll for adoption closes on Tuesday 4th February 2020.  
>  
> Regards,
> Matthew and Stephane
>  
> [1] https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-mh-pa/ <https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-mh-pa/>
>  
>  
>  
>  
>  
> _______________________________________________
> BESS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/bess <https://www.ietf.org/mailman/listinfo/bess>