Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt

RJ Atkinson <rja.lists@gmail.com> Mon, 10 February 2014 19:42 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7C91A0886 for <ospf@ietfa.amsl.com>; Mon, 10 Feb 2014 11:42:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 TnFUj0-fgPFC for <ospf@ietfa.amsl.com>; Mon, 10 Feb 2014 11:42:32 -0800 (PST)
Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 06AF61A087D for <ospf@ietf.org>; Mon, 10 Feb 2014 11:42:31 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id i13so10136521qae.41 for <ospf@ietf.org>; Mon, 10 Feb 2014 11:42:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:resent-from:date :content-transfer-encoding:resent-date:resent-to:message-id:to; bh=UFRBh5Ot4jkUnf7za/i6Kg89VebDO7At7KngKfQpBBw=; b=HKYu7ha5eDCkV63SS8+POp/3ij0gsioVoxCzxHfpoffnaY1nFNwZTSD2FNy/vNifj2 Ukl2dd81hIwZikdhmstkyn3o2ds4dcDUzu9Cw+rwoE8DzOX5vsPd0XDtTjPPsuhW0Pp8 hLpb6SXhx1W+k03KnKAbUNw3P1Fv8ZwwKvKCXz/C0060At6HvDaSBjZ1iTRF3LE31mcY NgUWwoczaVSazFw3gUmEwsw7vj35pFxNQ7nmGefW9ZekA/lQg5HcmE0pQsdbqXBpxh3h 0I7+z39p5y2XlpC+Xg2lxhIsHXlor+PKkmIeixco1nTqhFS57LZROBKa3ruuhJYKlXrd vs7A==
X-Received: by 10.140.30.66 with SMTP id c60mr47542442qgc.13.1392061351683; Mon, 10 Feb 2014 11:42:31 -0800 (PST)
Received: from [10.30.20.14] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id d7sm45592936qad.10.2014.02.10.11.42.31 for <ospf@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 11:42:31 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: RJ Atkinson <rja.lists@gmail.com>
Resent-From: RJ Atkinson <rja.lists@gmail.com>
Date: Mon, 10 Feb 2014 14:33:05 -0500
Content-Transfer-Encoding: quoted-printable
Resent-Date: Mon, 10 Feb 2014 14:42:30 -0500
Resent-To: ospf@ietf.org
Message-Id: <D15BB47E-2576-4AB9-83F2-3CA4CB282A5C@gmail.com>
To: ospf@ietf.org
X-Mailer: Apple Mail (2.1283)
Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 10 Feb 2014 19:42:39 -0000

Earlier, Karsten Thomann wrote, in part:
> I don't know if i have missed that part, but what would happen if OSPFv3 
> is running over IPv4 and there are two (or more) IPv6 Islands already deployed 
> within the network, should there be any LSA flooding checks, like do not flood 
> LSA with IPv6 networks over IPv4 only links, or should the route 
> calculation/installation of the information simply fail 
> as there is no valid path?

The OSPF deployments I am familiar with did not "auto deploy"
or "self deploy".  Instead, all of the OSPF deployments that I am
familiar with had engineers making deliberate decisions about how
to configure the OSPF deployment, and also how to configure the
OSPF routers in that deployment.

One deployment option, already deployed in some places, is to run
"ships in the night".  In this model, the IPv4 topology exclusively
uses OSPFv2 over IPv4 and the IPv6 topology exclusively uses OSPFv3
over IPv6.  For some sites, that is a good option.  A number of my
clients are very interested in this new I-D because it optimises
their IPv6 transition strategy.

For some sites, IPv6 transition is simplified, optimised, and also
cost-reduced by using OSPFv3 over IPv4 initially, and carrying both 
IPv4 prefixes and IPv6 prefixes inside that one OSPFv3 deployment 
(i.e. using the Address Family extension to keep the prefixes clearly 
differentiated within a single OSPFv3 deployment).  This can lower
operational costs because one can get by with managing only OSPFv3,
rather than having to manage both OSPFv2 and OSPFv3.

If one's "IPv6 islands" (to use your term) are really dual-stack
(aside: having dual-stack rather than IPv6-only would be expected
and normal if another part of one's OSPF deployment is using 
OSPF over IPv4), then EITHER the whole deployment should be configured 
to run over IPv4  XOR  the whole deployment should be configured 
to run over IPv6.  

Having different "IPv4 islands" and "IPv6 islands" is an explicit choice 
of a configuration engineer or design engineer.  That probably is not 
the optimal deployment choice for an engineer to make.  It definitely 
is NOT a choice that I would make or that I would recommend to my clients.

From the descriptions and definitions in the draft, it would not be 
"normal" or "expected" to mix IPv6 transport with IPv4 transport
within a single OSPFv3 deployment.

> Is there any explicit preference over which version the adjacency 
> is build if v4 and v6 is available in that specific part of the network?

The choice of preferred OSPF transport really is something that the 
configuration engineer ought to configure.  As the details of configuring 
any IP router are outside the scope of the IETF, I am not sure that 
this I-D properly can or should say very more than it already says.

Perhaps the I-D could add clarifying text along these lines
somewhere in Section 2:

 "Implementers of OSPFv3 over IPv4 SHOULD add a configuration
  knob to let the router administrator select whether a given
  OSPFv3-enabled interface should use OSPFv3 over IPv4 or 
  OSPFv3 over IPv6.  Except when an OSPFv3 deployment is being 
  transitioned from using IPv4 transmission to using IPv6 
  transmission, it is RECOMMENDED that all routers within an 
  OSPFv3 deployment use the same IP version for OSPFv3 packet 
  transmission."

> What should happen when an IPv4 Link gets v6 added, graceful reestablish 
> the adjacency over IPv6, or wait until forced protocol switch?

See my answer just above.  

I would expect that any router that implements this I-D also would implement 
a configuration knob to indicate whether IPv4 transmission or IPv6 transmission 
is preferred.  Over time, a configuration engineer might change this 
(e.g. manually change from IPv4 transmission to IPv6 transmission AFTER 
an entire IPv4 network has been deployed-with/converted-to dual-stack
IPv4 and IPv6).

Yours,

Ran Atkinson