Hi Chris, > -----Original Message----- > From: Christopher Morrow [mailto:christopher.mor...@gmail.com] > Sent: Thursday, November 17, 2011 9:48 PM > To: Templin, Fred L > Cc: grow-cha...@tools.ietf.org; grow@ietf.org grow@ietf.org; > Martin J. Levy > Subject: Re: [GROW] ixp jumbo frames doc > > On Thu, Nov 17, 2011 at 1:08 PM, Templin, Fred L > <fred.l.temp...@boeing.com> wrote: > > Hi Chris, > > > > See below for some follow-up: > > > >> -----Original Message----- > >> From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On > >> Behalf Of Christopher Morrow > >> Sent: Thursday, November 17, 2011 12:09 AM > >> To: grow-cha...@tools.ietf.org; grow@ietf.org grow@ietf.org; > >> Martin J. Levy > >> Subject: [GROW] ixp jumbo frames doc > >> > >> We had a bit of a lively discussion in the meeting today about: > >> <http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00> > >> > >> Some of the topics covered were: > >> o Is there a problem with CRC problems with 9k ? > > > > Please note that the concern is specifically for CRC-32. > > Several works have discussed the error characteristics > > of CRC-32 in relation to data set sizes: > > > > Koopman, P., "32-Bit Cyclic Redundancy Codes for > > Internet Applications", Dec. 2002. > > > > Stone, J. & Partridge, C., "When the CRC and TCP > > Checksum Disagree", Aug. 2000. > > > > Jain, R., "Error Characteristics of Fiber Distributed > > Data Interface (FDDI), August 1990. > > > > Those works tend to support the assertion that CRC-32 > > is adequate for data set sizes up to "about 9k or even > > a little bit more". > > > > That said, I can easily imagine something stronger than > > CRC-32, and it is the responsibility of the link layer > > to provide adequate error checking if it intends to > > support larger MTUs. > > > >> o is this something that the IEEE reigns supreme on? > > > > It is the link layer's job to ensure that it performs > > adequate error checking for packets of various sizes; > > it is not the network layer's place to guess at how well > > the link layer is doing its job. So, the link layer's > > advertised MTU is a certification that suitable error > > detection will be performed for packets no larger than > > the MTU; otherwise, it will become known as a "bad link". > > > >> o should there be other methods of deployment? > > > > Other methods of deployment than what? > > > > Sorry, I was rushing :( One of the proposals was to use a secondary > VLAN at the exchange for 'larger' packets, one was to forklift the > exchange, I believe there was a third discussed in the meeting as > well.
Thanks for the clarification; I have no further comment on this. > >> o is this a BCP instead of Informational doc? > > > > The document is proposing jacking up the Internet cell > > size from 1500 to 9000, where 9000 seems like a good > > fit for the vast majority of link paths anticipated > > for the near future. That seems like BCP to me. > > Err, it's proposing setting the IXP interfaces to 'larger than 1500'. > One of the problems is that some networks already show up at exchanges > with 'larger than 1500 on their backbone/core facing interfaces, and > likely on most other interfaces in the network as well, so these IXP > interfaces are one-off situations :( Right, but it is asking for a specific minimum MTU of 9000 in the core and is hence striving for a new Internet cell size. IMHO, this is a necessary first step toward migration to larger MTUs. Don't get me wrong, though - the Internet will still need to accommodate MTU diversity since there is no way to legislate a sweeping change of this nature that can be deployed all at once. That means PMTUD will still be necessary, and should be made as robust as possible. > I don't see this proposal as jacking up the whole of the Internet, > there are still a vast number of edge interfaces which are not capable > of changing MTU, but making the one-off problems go away seems like a > good idea. Right; there are certainly edge interfaces for which larger MTUs are not practical. Most wireless devices fall under that category. However, migrating the core to 9000+ allows edge devices that can do better than 1500 to discover larger MTUs. > > At the same time, at some point down the road we may > > need to turn the crank again and jack up from 9000 > > to something still larger. Hence, the BCP for the > > near term should leave open the door for an update > > at some point in the future. > > > >> o should this be adopted for WG work? > > > > Yes. > > thanks! Fred fred.l.temp...@boeing.com > -chris > > > Thanks - Fred > > fred.l.temp...@boeing.com > > > >> We'll pass along a separate call for adoption as well, but > keep these > >> points in mind (and hopefully let's chat some about these as well) > >> > >> -chris > >> (co-chair) > >> _______________________________________________ > >> GROW mailing list > >> GROW@ietf.org > >> https://www.ietf.org/mailman/listinfo/grow > >> > > > _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
