Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-etree-12

"Alvaro Retana (aretana)" <aretana@cisco.com> Tue, 22 August 2017 17:54 UTC

Return-Path: <aretana@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 D0A72132139; Tue, 22 Aug 2017 10:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MYxo9VFaU4Jx; Tue, 22 Aug 2017 10:54:22 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF27132031; Tue, 22 Aug 2017 10:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31814; q=dns/txt; s=iport; t=1503424462; x=1504634062; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L80FIwj/hZttN9Z1SsMPMM591wLs9TQfgEgl3uiixLQ=; b=hYh0s2L6b+4JJ0s7MqDSnniHCj7t1n/6X/4edvD5NK5k/PlH8SwwKkJX Ctk8dS4VC0k+TpDJOsgCGxX0AlWTWFYuOSohRHn7IfGsfR+L5CTRN5ubJ EcT3mKo0MV4D6hsUPPnFn559jeicOXcKH0oSRZu+vtOT8BYKi15T9H5+A U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQAeb5xZ/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEVB54mgUwiiDiNdYIEhUcCGoQXQxQBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMjVhACAQgRAwECIQcDAgICHxEUCQgCBAENBYlNTAMVrR6CJieHEQ2EH?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKoICgUyBYysLgnGCV4FpARIBPxaCXTC?= =?us-ascii?q?CMQWYIYd4PAKPS4R2AoIOkFCJbYJRiWoBNiF/C3cVWwGHB3aIY4EjgQ8BAQE?=
X-IronPort-AV: E=Sophos;i="5.41,413,1498521600"; d="scan'208,217";a="285976955"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2017 17:54:21 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7MHsLFX004919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Aug 2017 17:54:21 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 22 Aug 2017 12:54:20 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 22 Aug 2017 12:54:20 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "draft-ietf-bess-evpn-etree.all@ietf.org" <draft-ietf-bess-evpn-etree.all@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-bess-evpn-etree-12
Thread-Index: AQHTFvNSjAEtixCLIESUCrqobB2KyKKPIlIAgAA02gCAAAjygIAAG+eAgAD/rACAABQ8gA==
Date: Tue, 22 Aug 2017 17:54:20 +0000
Message-ID: <81463068-6059-4FC3-972F-EC75527491E3@cisco.com>
References: <D5BA373E.2160EF%sajassi@cisco.com> <1C29B427-1C0F-4267-ACBD-5DB9A59E9492@cisco.com> <D5C0C271.216F19%sajassi@cisco.com> <D5C0CC4B.216F6E%sajassi@cisco.com> <C123EA1A-66D0-4117-8152-3DAF632BF7CE@cisco.com> <D5C1B90E.216FA3%sajassi@cisco.com>
In-Reply-To: <D5C1B90E.216FA3%sajassi@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.25.0.170815
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.78.15]
Content-Type: multipart/alternative; boundary="_000_8146306860594FC3972FEC75527491E3ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/B-0m2EJmYoCe-UCwCiGS6LKMxnM>
Subject: Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-etree-12
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
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, 22 Aug 2017 17:54:25 -0000

I was referring to this document being marked as Updating rfc7385.

In any case, that works for me.

Thanks!

Alvaro.

On 8/22/17, 10:41 AM, "Ali Sajassi (sajassi)" <sajassi@cisco.com<mailto:sajassi@cisco.com>> wrote:

Hi Alvaro,

I am not modifying rfc7385 but rather trying to maintain backward/forward compatibility with it. The reason, I am defining additional “experimental" and “reserved” code points, is to maintain backward/forward compatibility with the rfc7385 code points. The new “experimental” and “reserved” code points (i.e., 0x7B – 0x7E, and 0x7F) are mirror images of the ones in rfc7385 (i.e., 0xFB – 0xFE, and 0xFF). If I don’t create these mirror images and leave them “unassigned”, then if somebody creates a tunnel type of 0x7B, then the corresponding composite tunnel type of that would be 0xFB which will conflict with existing code points in rfc7385 (i.e., 0xFB is defined as experimental).

Cheers,
Ali

From: "Alvaro Retana (aretana)" <aretana@cisco.com<mailto:aretana@cisco.com>>
Date: Monday, August 21, 2017 at 6:26 PM
To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, "ops-dir@ietf.org<mailto:ops-dir@ietf.org>" <ops-dir@ietf.org<mailto:ops-dir@ietf.org>>
Cc: "draft-ietf-bess-evpn-etree.all@ietf.org<mailto:draft-ietf-bess-evpn-etree.all@ietf.org>" <draft-ietf-bess-evpn-etree.all@ietf.org<mailto:draft-ietf-bess-evpn-etree.all@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12

Ali:

Hi!

RFC7385 already defines an Experimental range, why do we need another one?  Same question about reserving 0x7F (if rfc7385 already reserved 0xFF).

One of the reasons I’m asking is because if you’re only changing the 0x0C – 0xFA range, which is currently unassigned, the you (1) only need to include those values in this document, and (2) you don’t need to Update rfc7385:

Thanks!

Alvaro.


On 8/21/17, 5:47 PM, "Ali Sajassi (sajassi)" <sajassi@cisco.com<mailto:sajassi@cisco.com>> wrote:


Trying for the 2nd time because of the format scramble in the previous email.

Value               Meaning                            Reference
0x0C-0x7A      Unassigned
0x7B-0x7E      Experimental                    this document
0x7F                Reserved                           this document
0x80-0xFA      Reserved for Composite tunnel      this document
0xFB-0xFE      Experimental                    [RFC7385]
0xFF                Reserved                           [RFC7385]


From: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>
Date: Monday, August 21, 2017 at 5:14 PM
To: "Alvaro Retana (aretana)" <aretana@cisco.com<mailto:aretana@cisco.com>>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, "ops-dir@ietf.org<mailto:ops-dir@ietf.org>" <ops-dir@ietf.org<mailto:ops-dir@ietf.org>>
Cc: "draft-ietf-bess-evpn-etree.all@ietf.org<mailto:draft-ietf-bess-evpn-etree.all@ietf.org>" <draft-ietf-bess-evpn-etree.all@ietf.org<mailto:draft-ietf-bess-evpn-etree.all@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12
Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
Resent-To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>, <ssalam@cisco.com<mailto:ssalam@cisco.com>>, <jdrake@juniper.net<mailto:jdrake@juniper.net>>, <ju1738@att.com<mailto:ju1738@att.com>>, <sboutros@vmware.com<mailto:sboutros@vmware.com>>, <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>, <thomas.morin@orange.com<mailto:thomas.morin@orange.com>>, <martin.vigoureux@nokia.com<mailto:martin.vigoureux@nokia.com>>, <aretana@cisco.com<mailto:aretana@cisco.com>>, <db3546@att.com<mailto:db3546@att.com>>, <akatlas@gmail.com<mailto:akatlas@gmail.com>>, Thomas Morin <thomas.morin@orange.com<mailto:thomas.morin@orange.com>>
Resent-Date: Monday, August 21, 2017 at 5:15 PM


Hi Alvaro,

You’re right. I had some holes in my assignment. Following should fix it.

   ValueMeaningReference
   0x0C-0x7AUnassigned
   0x7B-0x7EExperimentalthis document
   0x7FReservedthis document
   0x80-0xFAReserved for Composite tunnelthis document
   0xFB-0xFEExperimental RFC7385]
   0xFFReserved[RFC7385]

Thanks,
Ali

From: "Alvaro Retana (aretana)" <aretana@cisco.com<mailto:aretana@cisco.com>>
Date: Monday, August 21, 2017 at 1:05 PM
To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, "ops-dir@ietf.org<mailto:ops-dir@ietf.org>" <ops-dir@ietf.org<mailto:ops-dir@ietf.org>>
Cc: "draft-ietf-bess-evpn-etree.all@ietf.org<mailto:draft-ietf-bess-evpn-etree.all@ietf.org>" <draft-ietf-bess-evpn-etree.all@ietf.org<mailto:draft-ietf-bess-evpn-etree.all@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12

Ali:

Hi!

So, you’re really only changing the 0x0C – 0xFA range, right?

If my hex is not wrong, you’re missing some pieces below: 0x40-0x7F, and 0xC0-0xCF, which I’m assume remain Unassigned, right?

Thanks!

Alvaro.

On 8/16/17, 5:54 PM, "Ali Sajassi (sajassi)" <sajassi@cisco.com<mailto:sajassi@cisco.com>> wrote:

To maximize backward/forward compatibility, let's retain the value for "Experimental Use” and “Reserved” as before per [RFC7385] and reduce the range for Composite tunnel for this draft. So, the changes will be
From existing IANA assignments:
0x0C - 0xFA Unassigned
0xFB - 0xFE Experimental [RFC7385]
0xFF Reserved [RFC7385]
To:
  0x0C – 0x3F Unassigned
  0x80 – 0xBF reserved for composite tunnel
  0xD0 – 0xFA Unassigned
  0xFB - 0xFE Experimental [RFC7385]
  0xFF
 Reserved [RFC7385]