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

"Les Ginsberg (ginsberg)" <> Fri, 02 June 2017 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C8421200C1 for <>; Fri, 2 Jun 2017 13:24:55 -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 55jpkBBPs6p7 for <>; Fri, 2 Jun 2017 13:24:53 -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 EB5631201FA for <>; Fri, 2 Jun 2017 13:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31894; q=dns/txt; s=iport; t=1496435093; x=1497644693; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TU5IsPNwqSgsfDWziAQAS3xn/IWGXadC4VB1WJY1+GA=; b=ARUbd8r57Li679zT79L8klF/soaHppfawlYZh9uLaAglUTJH9bt6rdPu BghbIppVfzi1dMdwJIGKCF3aJ/yj0LHpvYsouBj78bvO2pR+HX1a/1zHz c5W8/U6kIHDThuekP2zREwv9uyE2JXqu3lNkYKUaw9oe1ZYHST7cBt/XX U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.39,286,1493683200"; d="scan'208,217";a="434376038"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2017 20:24:52 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v52KOpJX032143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Jun 2017 20:24:51 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Jun 2017 15:24:51 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 2 Jun 2017 15:24:51 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Alia Atlas <>
CC: "" <>
Thread-Topic: [Isis-wg] Proposed Liaison response on Ethernet Jumbo Frames
Thread-Index: AQHS27uRpY0xAGqXbEeZp8hqSyW9E6IR6bRAgABoGgD//7AY8A==
Date: Fri, 2 Jun 2017 20:24:50 +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_9b086bec29844afa8e14c4f6b8fd2376XCHALN001ciscocom_"
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 20:24:55 -0000

Alia –

draft-ietf-isis-ext-eth-01 is a de facto standard. Having the IEEE standard doesn’t change anything other than place an official stamp on what folks have already implemented.

Padding hellos is a base protocol functionality. From IS-IS POV it is simply told what the interface MTU is. IS-IS itself does not need to know whether the frame is Jumbo or not.
The encap done for Jumbo frames is done at lower layers – not in the protocol. Officially (from a standards perspective) this would be part of what OSI refers to as the Subnetwork Dependent Convergence Function (SNDCF).


From: Alia Atlas []
Sent: Friday, June 02, 2017 12:59 PM
To: Les Ginsberg (ginsberg)
Subject: Re: [Isis-wg] Proposed Liaison response on Ethernet Jumbo Frames

Hi Les,

On Fri, Jun 2, 2017 at 3:04 PM, Les Ginsberg (ginsberg) <<>> wrote:
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.

Right - my question is, given that draft-ietf-isis-ext-eth-01 isn't an RFC and that there is now (hopefully with
Ethertype 88-70) an IEEE standard, is there a benefit to being explicit about the related IS-IS padded hellos?  This is someplace where I believe there are slightly different implementations & defaults.

That's the only work I was picturing.


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.