IETF Logo Mail Archive

Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02

Fred Baker <fredbaker.ietf@gmail.com> Fri, 21 April 2017 19:00 UTC

Return-Path: <fredbaker.ietf@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E2F12EB1B for <v6ops@ietfa.amsl.com>; Fri, 21 Apr 2017 12:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iJwmFo02LWit for <v6ops@ietfa.amsl.com>; Fri, 21 Apr 2017 12:00:28 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF9D12EAF6 for <v6ops@ietf.org>; Fri, 21 Apr 2017 12:00:24 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id k87so132006512ioi.0 for <v6ops@ietf.org>; Fri, 21 Apr 2017 12:00:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5s7eGK2VkH3U/QQv84/c8psAX+9QxGmoA58/ZqvkTNk=; b=dwiKNGcA8+DsRMhpmqbSx1LgWpmkfsbeKYKnchXjFJixVm2q9diw1vsrZOggNLqcYj Be4Mbcj066co66p1y2ULhgrQPJ9w1BQMpCaJBtVoRV2jGe4QSW4c6q/QBG9Wg+R+/ERJ TvD585s3ak3boXsYhNqOgMdxek4NVGUe8tKz0gZ+2oJpwrOBtNuClNPIqN2DJegebDKo 2rcu+UnhLglaaoH/VEHmW5Jxb9aMK7tPsWOuCvURqw/IIpJgQrVasKpdTppxzcIYb/qP rmyWIiYs0Bh0QWAyyv7ncR35Qsek7mlYLzJBHllAhODWQeTUhzLXbkrV84Cl0aAgH4aU E24w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5s7eGK2VkH3U/QQv84/c8psAX+9QxGmoA58/ZqvkTNk=; b=o97jEnTu73OeugcTMN19BW+5x2Y9205osGvyV5NunhY4aMkrVhKcDV2CGJ/hA/SqNd V+CTtM2EoQGjfzBMg5mHW7CfB2MhIiVUATKT5Q696i8wSiRGq0T4bzx8GZG+D5RCBJq4 YAqBtybpPDkD82+gYmGhBX5/uHOc9/Svop6D7Ta9o2/1XF3vJr3hfjOk7cWJ6iR0mUor oY43f/jVH9sfbav0RkH8GLl/itCK/2QMytXrTy2HXpI4Q+VrU+dbSU+AJuCX185UmnAA U+rPnqCuY3212lAcae2KE23uYC09L/6O8WZVk/WXbZFKIyF4Lav/hiVB+4asZlbY0tas 1PeQ==
X-Gm-Message-State: AN3rC/7oT2a7grbft7edWgCpzY2tjsoTyik5o8ShdMgS6hrsbWAbNUx1 U3C57fofBQTtuA==
X-Received: by 10.99.3.212 with SMTP id 203mr13860496pgd.0.1492801220077; Fri, 21 Apr 2017 12:00:20 -0700 (PDT)
Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id w129sm17371313pfb.130.2017.04.21.12.00.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 12:00:19 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <alpine.DEB.2.02.1704211545060.5591@uplift.swm.pp.se>
Date: Fri, 21 Apr 2017 12:00:17 -0700
Cc: IPv6 Ops WG <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <401B16AB-4480-486E-9579-313940BE5A53@gmail.com>
References: <BLUPR0501MB20513F21FE599ED243BA9AAFAE3C0@BLUPR0501MB2051.namprd05.prod.outlook.com> <alpine.DEB.2.02.1704211545060.5591@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/VX_TeE49qGT0W6xgd3yKKqMQ2fs>
Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 19:00:31 -0000

> On Apr 21, 2017, at 6:54 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> On Wed, 22 Mar 2017, Ron Bonica wrote:
> 
>> 3) The title of Section 5.3 is "Maximum Transmission Unit and Jumbo Frames". However, there is no further mention of Jumbo Frames. Could we explore Jumbo's possibly with an eye towards deprecation.
> 
> I am strongly in favour of support of jumbo frames.
> 
> I would like to see the document specify an L3 MTU of 9180 as its SHOULD requirement. All major core router vendor supports this today. The reason for 9180 is that this is what RFC2225, RFC2492, RFC1209 mention.

We may need to clarify the meaning of the term. RFC 2460 removed references to Jumbograms (from the RFC 1883 text), moving it to a separate document. That document is RFC 2675, which says:

   The IPv6 header [IPv6] has a 16-bit Payload Length field and,
   therefore, supports payloads up to 65,535 octets long.  This document
   specifies an IPv6 hop-by-hop option, called the Jumbo Payload option,
   that carries a 32-bit length field in order to allow transmission of
   IPv6 packets with payloads between 65,536 and 4,294,967,295 octets in
   length.  Packets with such long payloads are referred to as
   "jumbograms".

From that perspective, a 9K byte message is a "normal" IPv6 message - the payload length fits in the provided 16 bit field.

Yes, I'm in favor of 9K byte messages too. But they are not "jumbo" from this perspective.

> Other comments:
> 
> 3.3 It would be good if the draft referenced for instance RFC8071 for Netconf-call-home and draft-ietf-netconf-zerotouch-13 for zerotouch plug'n'play provisioning.
> 
> 5.4. The ICMP ECHO/REPLY requirement here opposes what's in RFC4890. I prefer what RFC4890 says.
> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email