Re: [bess] Adam Roach's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

"Satya Mohanty (satyamoh)" <satyamoh@cisco.com> Tue, 15 January 2019 22:11 UTC

Return-Path: <satyamoh@cisco.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233BE1294FA; Tue, 15 Jan 2019 14:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.053
X-Spam-Level:
X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwa-fHaYGP6P; Tue, 15 Jan 2019 14:11:45 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F47127598; Tue, 15 Jan 2019 14:11:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20344; q=dns/txt; s=iport; t=1547590304; x=1548799904; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0pofvFsr2SgPTTjh/R3jmcqQ+AgzKmMpyekBCzLJcIM=; b=EbyAnogykOCYDxt4m366pTsyfgnSJ46/S+kqaihEPFd2NLuygMNo0dIj FrzJkVwf6+gBHnC+qOklL7ZqvHP19ICZ9d3sG+rx06ANUXEwT/XEmUD3L dCZYymvHV4xo/yvUC2Rlz+wi35YOFr6X5QvcusrCdvh/Dykpi0U8DX/8I 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAAA7Wj5c/4QNJK1jDgsBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENdmaBAicKg3eIGo1bJZIUhWgUgWcLAQElhEcCF4IrIjQJDQEDAQECAQECbRwMhUsBBAEjVgULAgEILRUCAgIwJQIEAQ0FgyIBgR1cCA+sXYEvhEJAhSgFjD8XgUA/gTgME4JMgx4CAQIBgRgSARIBA1uCSjGCJgKJOCSGBpIjCQKHHoptGIFkhSaKdol4hRGLQAIRFIEnHzhlWBEIcBVlAYJBgiYYE4hMhQQ7QTEBiGuBH4EfAQE
X-IronPort-AV: E=Sophos;i="5.56,483,1539648000"; d="scan'208,217";a="226496562"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2019 22:11:43 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x0FMBhNK026594 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Jan 2019 22:11:43 GMT
Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 15 Jan 2019 17:11:42 -0500
Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1395.000; Tue, 15 Jan 2019 17:11:42 -0500
From: "Satya Mohanty (satyamoh)" <satyamoh@cisco.com>
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
CC: "draft-ietf-bess-evpn-df-election-framework@ietf.org" <draft-ietf-bess-evpn-df-election-framework@ietf.org>, Stephane Litkowski <stephane.litkowski@orange.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Adam Roach's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
Thread-Index: AQHUqK4mAIEFuKY4uECOoz7df7rR5KWwuu6A
Date: Tue, 15 Jan 2019 22:11:42 +0000
Message-ID: <8E51BEEB-21BD-42CE-9180-701B42DC7E4E@cisco.com>
References: <154710188920.4967.4360194300297894536.idtracker@ietfa.amsl.com>
In-Reply-To: <154710188920.4967.4360194300297894536.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.163.104]
Content-Type: multipart/alternative; boundary="_000_8E51BEEB21BD42CE9180701B42DC7E4Eciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/y-ssZ0ONzqzQALe-OrsaZ4f2e70>
Subject: Re: [bess] Adam Roach's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jan 2019 22:11:47 -0000

Adam,



Thanks to you and Benjamin for this review and feedback on the hashing. Please see inline [Satya].

I will add my response to other queries in the forthcoming Jorge's reply to  Benjamin (as there are other comments to be addressed).



Best,

--Satya



On 1/9/19, 10:31 PM, "Adam Roach" <adam@nostrum.com> wrote:



    Adam Roach has entered the following ballot position for

    draft-ietf-bess-evpn-df-election-framework-07: No Objection



    When responding, please keep the subject line intact and reply to all

    email addresses included in the To and CC lines. (Feel free to cut this

    introductory paragraph, however.)





    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

    for more information about IESG DISCUSS and COMMENT positions.





    The document, along with other ballot positions, can be found here:

    https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/







    ----------------------------------------------------------------------

    COMMENT:

    ----------------------------------------------------------------------



    I have one minor comment that the authors may wish to consider.



    §1.2.1:



    >  It is well-known that for good

    >  hash distribution using the modulus operation, the modulus N should

    >  be a prime-number not too close to a power of 2 [CLRS2009].



    I suppose this refers to the explanation in [CLRS2009] §11.3.1. The

[Satya] Yes, it is from [CLRS2009] §11.3.1

    description there is pretty hand-wavy and not completely accurate except under

    certain (admittedly common) conditions -- in which this case is not included.

    You may wish to consider instead citing "The Art of Computer Programming (Vol.

    3)" by Knuth, as it captures a lot more of the nuance behind why this rule of

    thumb is frequently true, and covers the general case. There is probably a set

    of considerations to take into account for Ethernet Tags with an even

    distribution, but only because you have a relatively small set of potential

    inputs -- not for any of the reasons cited in [CLRS2009]. Quoting Knuth:



      In general, we want to avoid values of M that divide r^k+a or r^k−a, where k

      and a are small numbers and r is the radix of the alphabetic character set

      (usually r=64, 256 or 100), since a remainder modulo such a value of M tends

      to be largely a simple superposition of key digits. Such considerations

      suggest that we choose M to be a prime number such that r^k!=a(modulo)M or

      r^k!=−a(modulo)M for small k & a.



    I see that Benjamin has made a related comment. I share his objection to

    the way point #2 is phrased, and think it needs to be reworded to properly

    capture the subtleties implied by the preceding passage.



[Satya] Yes, noted. I will change point #2.  Here is a suggested description of Point #2



Th Ethernet tag that identifies the BD can be as large as 2^24; however, it is not guaranteed that the tenant BD on the ES will conform to a uniform distribution. In fact, it up to the customer what BDs they will configure on the ES. Quoting Knuth [Art of Computer Programming Pg. 516]



  " In general, we want to avoid values of M that divide r^k+a or r^k−a, where k

      and a are small numbers and r is the radix of the alphabetic character set

      (usually r=64, 256 or 100), since a remainder modulo such a value of M tends

      to be largely a simple superposition of key digits. Such considerations

      suggest that we choose M to be a prime number such that r^k!=a(modulo)M or

      r^k!=−a(modulo)M for small k & a."



In our case, N is the number of PEs in RFC 7432 which corresponds to M above.

Since N, N-1 or N+1 need not satisfy the primality properties of the M above; as per RFC 7432 modulo based DF assignment, whenever a PE goes down or a new PE boots up (hosting the same Ethernet Segment), the modulo scheme need not necessarily map BDs to PEs uniformly.