Re: [bess] PLEASE LOOK: minor change to draft-ietf-bess-evpn-df-election-framework-05 => two weeks poll to get feedback

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Fri, 23 November 2018 00:23 UTC

Return-Path: <sajassi@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 8126B130DD9; Thu, 22 Nov 2018 16:23:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.958
X-Spam-Level:
X-Spam-Status: No, score=-15.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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, URIBL_BLOCKED=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 RdLBkMxZbBq6; Thu, 22 Nov 2018 16:22:59 -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 354A4130DD0; Thu, 22 Nov 2018 16:22:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43490; q=dns/txt; s=iport; t=1542932579; x=1544142179; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f2Nj0aaikjSn6JMp6+YwEJGImPpQjW2x2lGCyFrEhVw=; b=K2h6EjbS5hYLXT4K4ct1Cb+z4WhUXDCUf1SwfPJjIaLEuLqBKWCZGMfl g5qqOIHwvxLX3XbSWGZg5ityQSRcw06sE0mSCh1Xhz/1Xky1LZdS1rWZK PTSqkq733iHm/VTrnT9EgT2pcLvkrPBeb4ZSCediD2yF2iBnX7Krc007T s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADzR/db/5pdJa1iGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1ILmaBAicKg2+IGI4MlzsUgWYLAQE?= =?us-ascii?q?fhE0CF4N5IjQJDQEDAQECAQECbRwMhTwBAQEBAyNWEAIBCBEDAQEBIQECBAM?= =?us-ascii?q?CAgIwFAkIAQEEAQ0FgyEBgR1kD6dpgS+KFgWMCReBf4ERJx+CTIMbAQEDgSs?= =?us-ascii?q?BDAYBNgkMCoJOMYImAokHCoVxhjSJd1UJAoZ6ijMYgVmFC4h2gS6NQ4pGAhE?= =?us-ascii?q?UgScfOGRxcBVlAYJBgicXEohMhT5BMYsQDheBCIEfAQE?=
X-IronPort-AV: E=Sophos;i="5.56,267,1539648000"; d="scan'208,217";a="203036116"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2018 00:22:58 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id wAN0MvLc021136 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Nov 2018 00:22:57 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 22 Nov 2018 19:22:56 -0500
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1395.000; Thu, 22 Nov 2018 19:22:56 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "bess@ietf.org" <bess@ietf.org>
CC: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "martin.vigoureux@nokia.com" <martin.vigoureux@nokia.com>
Thread-Topic: PLEASE LOOK: minor change to draft-ietf-bess-evpn-df-election-framework-05 => two weeks poll to get feedback
Thread-Index: AdSBeVzJDePAdkxYRPe/rc2WvXNgcwBMCueA
Date: Fri, 23 Nov 2018 00:22:56 +0000
Message-ID: <D44CA846-AEA6-4F00-94D0-FA05B6739D48@cisco.com>
References: <14620_1542791324_5BF5209C_14620_311_1_9E32478DFA9976438E7A22F69B08FF924B772FA0@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <14620_1542791324_5BF5209C_14620_311_1_9E32478DFA9976438E7A22F69B08FF924B772FA0@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.4.181110
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.76.53]
Content-Type: multipart/alternative; boundary="_000_D44CA846AEA64F0094D0FA05B6739D48ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.141, xch-rtp-001.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/NMOtEsLTtYUyUidodKu9QZ30KE0>
Subject: Re: [bess] PLEASE LOOK: minor change to draft-ietf-bess-evpn-df-election-framework-05 => two weeks poll to get feedback
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: Fri, 23 Nov 2018 00:23:02 -0000

Hi Stephane,

The rational for the suggested change comes from recent requirements for per-mcast-flow DF election where it is required to be able to do DF election for multicast traffic independently from Broadcast and Unknown Unicast traffic. Up to this point, DF election has been done for the entire BUM traffic; whereas, there are some asks that DF election for BU traffic to be done by one algorithm (e.g., vlan carving) and the DF election for M traffic to be done by HRW.  To accommodate this requirements, the proposed change is to limit the “DF-Alg” field to five bits and use the remaining three bits for M-traffic (let’s call this new field DF-M). A value 0 for DF-M indicates that multicast traffic  is governed by the same algorithm represented by “DF-Alg” field. For example, 0x01 means HRW algorithm to be used for All BUM traffic. A none zero value for DF-M means that multicast traffic to be governed by the indicated DF-M typ.  For example, 0x20 means use VLAN carving for BU traffic an HRW for (S,G) flows and 0x40 means use VLAN carving for BU traffic and HRW for (*,G) flows. This stuff will be described in details in per-mcast-flow-df-election draft.

Regards,
Ali

From: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
Date: Wednesday, November 21, 2018 at 1:08 AM
To: Cisco Employee <sajassi@cisco.com>om>, "bess@ietf.org" <bess@ietf.org>
Cc: "bess-chairs@ietf.org" <bess-chairs@ietf.org>rg>, "martin.vigoureux@nokia.com" <martin.vigoureux@nokia.com>
Subject: PLEASE LOOK: minor change to draft-ietf-bess-evpn-df-election-framework-05 => two weeks poll to get feedback

Hi Ali,

Thanks a lot for your email.

Speaking as chair, could you please highlight to the working group the rationale of the change and associated use case ? Just to give the context…


To WG Folks,

Please review this change with care. There are two points that I would like to highlight:


  *   We need to ensure that there is no current implementation using the value 255. Please raise your voice if you are aware of one.
  *   The encoding of the mcast DF election algorithm could now be decorrelated from the base DF alg (applicable to Broadcast and Unknown traffic). The proposed encoding uses 3 bits for the mcast DF alg. We have to ensure that:
     *   3 bits is enough
     *   There will “never” (at least not mid term) be a requirement for variable parameters for mcast DF election (like in DF pref draft).

I will let some time to think about this change and raise your support or concerns.
The poll starts now and will end on Dec 5th.
This DF election framework will be an important component of EVPN and we need to ensure that we are providing the required level of flexibility to address the different use cases.

Thanks !


From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Wednesday, November 21, 2018 00:25
To: bess@ietf.org
Cc: bess-chairs@ietf.org
Subject: minor change to draft-ietf-bess-evpn-df-election-framework-05


Folks,

The authors of  the above draft are purposing a minor change to the draft and since the draft is currently under review by IESG, the chair has asked to send an email to the WG to solicit inputs and ensuring that there is no objection. The proposed change is as follow:

Currently, the above draft defines an eight-bit “DF Alg” field as shown in the following figure. The proposed change is to reduce the eight-bit field to a five-bit field.

*** OLD Text

              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | Type=0x06     | Sub-Type(0x06)|   DF Alg      |    Bitmap     |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |     Bitmap    |            Reserved                           |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o DF Alg (1 octet) - Encodes the DF Election algorithm values
     (between 0 and 255) that the advertising PE desires to use for the
     ES. This document requests IANA to set up a registry called "DF Alg
     Registry" and solicits the following values:

     - Type 0: Default DF Election algorithm, or modulus-based algorithm
       as in [RFC7432<https://tools.ietf.org/html/rfc7432>]2>].

     - Type 1: HRW algorithm (explained in this document).

     - Types 2-254: Unassigned.

     - Type 255: Reserved for Experimental Use.

***NEW Text

              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | Type=0x06     | Sub-Type(0x06)| RSV |  DF Alg  |    Bitmap    |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |     Bitmap    |            Reserved                           |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o DF Alg (5 bits) - Encodes the DF Election algorithm values
     (between 0 and 31) that the advertising PE desires to use for the
     ES. This document requests IANA to set up a registry called "DF Alg
     Registry" and solicits the following values:

     - Type 0: Default DF Election algorithm, or modulus-based algorithm
       as in [RFC7432<https://tools.ietf.org/html/rfc7432>]2>].

     - Type 1: HRW algorithm (explained in this document).

     - Types 2-30: Unassigned.

     - Type 31: Reserved for Experimental Use.


The remaining 3-bits of that octet (bits 16, 17, and 18 in the above figure) will be used by per-mcast-flow-df-election and will be expanded and described there and will be discussed in the next IETF as usual at the BESS WG session.

Regards,
Ali & other co-authors

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.