Re: Proposed Liaison response on Ethernet Jumbo Frames

"Les Ginsberg (ginsberg)" <[email protected]>
Newsgroups gmane.ietf.isis
Message-ID <[email protected]>
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).

   Les


From: Alia Atlas [mailto:[email protected]]
Sent: Friday, June 02, 2017 12:59 PM
To: Les Ginsberg (ginsberg)
Cc: [email protected]
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) <[email protected]<mailto:[email protected]>> 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.

Regards,
Alia


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.

   Les

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

Hi,

At the end of the ISIS WG meeting at IETF 98, I called attention to the recent liaison from IEEE -  https://datatracker.ietf.org/liaison/1509/<https://datatracker.ietf.org/liaison/1509/>.  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.

=========
Colleagues,

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.

Regards,
Alia

_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.