Re: [OSPF] Spencer Dawkins' No Objection on draft-ietf-ospf-transition-to-ospfv3-09: (with COMMENT)

joel jaeggli <joelja@bogus.com> Sun, 26 June 2016 06:00 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F56112B041; Sat, 25 Jun 2016 23:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 zgBh7xby7seP; Sat, 25 Jun 2016 23:00:41 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2D412B042; Sat, 25 Jun 2016 23:00:41 -0700 (PDT)
Received: from mb-2.local ([IPv6:2601:647:4201:9e61:8982:d59b:183a:400a]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u5Q60YWc032668 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 26 Jun 2016 06:00:37 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:8982:d59b:183a:400a] claimed to be mb-2.local
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
References: <20160626032124.17217.72089.idtracker@ietfa.amsl.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <35576982-1e65-9cc8-f39a-86b1a882f285@bogus.com>
Date: Sat, 25 Jun 2016 23:00:31 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0
MIME-Version: 1.0
In-Reply-To: <20160626032124.17217.72089.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="hcSUmCob25ecvfSaw9mlQLaIgDeVwOw9V"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/2hRSZZs4gZ1qqK48u9xKn_9bpL8>
Cc: ospf@ietf.org, draft-ietf-ospf-transition-to-ospfv3@ietf.org, ospf-chairs@ietf.org, wenhu.lu@gmail.com
Subject: Re: [OSPF] Spencer Dawkins' No Objection on draft-ietf-ospf-transition-to-ospfv3-09: (with COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jun 2016 06:00:43 -0000

On 6/25/16 8:21 PM, Spencer Dawkins wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-ospf-transition-to-ospfv3-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This was nice work.
> 
> I did have one question - I don't think it would be a likely problem, but
> is it worth pointing out that you're taking OSPFv3 payloads that might
> have been sized for IPv6, and encapsulating them as IPv4 payloads that
> might have a smaller MTU?

Given that these devices have a common link mtu (otherwise they would
have trouble forming adjcency over the broadcast domain) the opfv3
payload will always be sized for the v6 network which means the ipv4
variant of the packet packet will always be 20 bytes smaller due to the
ipv6 header being 20 bytes larger then the v4 one..

> If you tell me this isn't a problem, I'll believe you, of course, but I
> needed to ask :-)
>
>