Re: [Isis-wg] Proposed Liaison response on Ethernet Jumbo Frames

"Les Ginsberg (ginsberg)" <> Fri, 02 June 2017 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 497D2129420 for <>; Fri, 2 Jun 2017 12:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 00mhKbwW059g for <>; Fri, 2 Jun 2017 12:04:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D911126CB6 for <>; Fri, 2 Jun 2017 12:04:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=20356; q=dns/txt; s=iport; t=1496430262; x=1497639862; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=oXk9+2NpLe+36PWhvLV3n4YCL3miwSiurmHD27bL1kE=; b=TjX08tF0pTSuz0jzt4p14RtLHDCSKPnqBXNgvviin5gKE1l4eIiONAGs 2ET83EdqnmEU5rFdwWNIzKSc6k3IKVjGWVcKgLcUWvTsJ4V2REkHqa9HR cUqj9qaaMW0rnh5iibNkFRZHIDYBV+N9NvWYVZol59MtiQTFuAZKTevvd s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.39,286,1493683200"; d="scan'208,217";a="432865327"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2017 19:04:21 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v52J4LND000552 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Jun 2017 19:04:21 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Jun 2017 14:04:20 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 2 Jun 2017 14:04:20 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Alia Atlas <>, "" <>
Thread-Topic: [Isis-wg] Proposed Liaison response on Ethernet Jumbo Frames
Thread-Index: AQHS27uRpY0xAGqXbEeZp8hqSyW9E6IR6bRA
Date: Fri, 2 Jun 2017 19:04:20 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_16f9a396d9b548fba23ca570b6580394XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] Proposed Liaison response on Ethernet Jumbo Frames
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Jun 2017 19:04:24 -0000

Alia –

First, I want to thank you for all the work you did in clearing the issues. You have cleared the way for the outcome which I think we want – and done so very expeditiously – which hopefully will minimize any deployment of the unwanted alternate Ethertype defined by IEEE.

I am fine with the text below. However, I am not sure what you are concerned about regarding:

“Please also discuss whether there is additional ISIS work to be done.  I'm specifically thinking about sending hello packets at the MTU.”

It is padded hellos which are the most common use case for Jumbo frames as that is the default behavior for the protocol.
It is also possible to send Jumbo LSPs – but this can only be done if all routers are configured to support a larger lsp-mtu setting and all links in the network on which IS-IS operates have an MTU large enough to accommodate the larger LSPs.

In any case I don’t believe there is any work to be done here. Implementations which support draft-ietf-isis-ext-eth-01 already do this.

The only work would be if we are required to support the IEEE specified Ethertype (C9-D1) as a transition mechanism or – perish the thought – as a permanent alternate. What we hope to achieve by this liason is to kill the new ethertype before it gets deployed.


From: Isis-wg [] On Behalf Of Alia Atlas
Sent: Friday, June 02, 2017 9:16 AM
Subject: [Isis-wg] Proposed Liaison response on Ethernet Jumbo Frames


At the end of the ISIS WG meeting at IETF 98, I called attention to the recent liaison from IEEE -<>9/>.  There was significant concern expressed about the decision to use a new EtherType instead of EtherType 88-70, which is widely deployed.

Here is a proposed liaison response, which should also update you on progress that has been made in this area. I would prefer to get this liaison, with any improvements, agreed to by June 15.


Thank you very much for your liaison on March 25.  We are happy to learn that IEEE now has a standard, IEEE Std 802.1AC-2016, for encoding LLC frames and that its use appears to be exactly as described in draft-ietf-isis-ext-eth-01.  There are a large number of pre-standard implementations and deployments of this functionality.

With informal discussion, we were able to determine the current owner of EtherType 88-70 and have what we believe is the necessary statement so that this EtherType is now available for this functionality.  I would like to thank both Yaakov Stein, CTO RAD, for making this happen and David Aviv, CTO Radware.  As these types of challenges come up and have large impact, we would prefer to learn of them earlier so that we can try and assist sooner in the process.

We are quite concerned about the allocation of a new EtherType given the extremely large deployment of this pre-standard common feature.  We would encourage the IEEE 802.1 Working Group to strongly consider updating IEEE Std 802.1AC to use the deployed EtherType 88-70 that is now available for this purpose.

The ISIS Working Group will discuss whether there is additional work to do now that IEEE Std 802.1AC-2016 is available.

Warmest regards,
Alia Atlas, IETF Routing Area Director
Chris Hopps, ISIS Working Group Chair
Hannes Gredler, ISIS Working Group Chair


Please also discuss whether there is additional ISIS work to be done.  I'm specifically thinking about sending hello packets at the MTU.