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

Acee Lindem <acee.lindem@ericsson.com> Wed, 26 February 2014 23:32 UTC

Return-Path: <acee.lindem@ericsson.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 B083E1A0792 for <ospf@ietfa.amsl.com>; Wed, 26 Feb 2014 15:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=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 sd8uOr9yHw7T for <ospf@ietfa.amsl.com>; Wed, 26 Feb 2014 15:32:41 -0800 (PST)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 82AF61A06E8 for <ospf@ietf.org>; Wed, 26 Feb 2014 15:32:41 -0800 (PST)
X-AuditID: c618062d-b7f858e0000031c7-d9-530e7993fe6b
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E3.5A.12743.3997E035; Thu, 27 Feb 2014 00:32:35 +0100 (CET)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 18:32:38 -0500
From: Acee Lindem <acee.lindem@ericsson.com>
To: Karsten Thomann <karsten_thomann@linfre.de>, "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt
Thread-Index: AQHPLASQC4hPn9qVfUSdHygqv/z3N5q6NRiAgA3WoQA=
Date: Wed, 26 Feb 2014 23:32:38 +0000
Message-ID: <CF33B971.27D16%acee.lindem@ericsson.com>
In-Reply-To: <4840600.E243vrriOs@linne>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [147.117.188.10]
Content-Type: multipart/alternative; boundary="_000_CF33B97127D16aceelindemericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXSPt+7kSr5gg1tXNSy23DrKZNFy7x67 A5PHkiU/mTweHjzEHsAUxWWTkpqTWZZapG+XwJWx6f8zloKHq5kqbu5vZG5gXNfO1MXIySEh YCJxe9J8FghbTOLCvfVsXYxcHEICRxglbjd+ZoVwljNK3J8C0cEmoCPx/NE/ZhBbRCBIYtO3 I2DdwgL2Ep8XvGOFiDtI9Jx5BFVjJXH++3FGEJtFQFXi96HvYHFeAVOJvv0PgHo5ODgF1CWu LlMDCTMCHfH91BqwVcwC4hK3nsyHOlRAYsme88wQtqjEy8f/wFaJCuhJdM9azgoRV5KYtPQc K0RvlMTHPwcYIVYJSpyc+YRlAqPILCRjZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZ IWxriRkXPjAiq1nAyLGKkaO0OLUsN93IYBMjMLKOSbDp7mDc89LyEKM0B4uSOO+Xt85BQgLp iSWp2ampBalF8UWlOanFhxiZODilGhh7J/66s3D1yk2WT5iTV10q3LSm0O7s/U39XwxWSj5o XhEkyctvbSf02DXm+NzsyJVr57QZWclF6b304BRd8en8jhuHREQenOdx/VL/V0qH8aDPLNfV C3QqNi3f8C5kpZV78pv1flo8vg26V375fxJm+RD9JYFTxn6PbHCbccL9mzIlXM/KfNcosRRn JBpqMRcVJwIAVCrFGHoCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/vn5aX_eSIFxNrfxicakRtTRmvwY
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: Wed, 26 Feb 2014 23:32:47 -0000

Thanks Karsten – we will include all these editorial changes in the next revision.
Acee

From: Karsten Thomann <karsten_thomann@linfre.de<mailto:karsten_thomann@linfre.de>>
Date: Monday, February 17, 2014 12:13 PM
To: Ericsson <acee.lindem@ericsson.com<mailto:acee.lindem@ericsson.com>>, OSPF - OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt


Hi Acee,



found some nits to resolve in the next draft.

1. Introduction

s/to to/to



2. Encapsulation in IPv4

First sentence of the second passage

s/by a OSPF/by an OSPF



3. Security Considerations

In the second passage is a little typo it should be RFC6506 instead of 6505



5.2 Informative References



Headline is right for RFC 6506 and is correct after the headline but listed wrong as RFC6505.



Kind regards,

Karsten



Am Montag, 17. Februar 2014, 17:20:33 schrieben Sie:

Hi Karsten,

We wil add Ran's suggested text to the next revision.

Thanks,

Acee


From: Karsten Thomann <karsten_thomann@linfre.de<mailto:karsten_thomann@linfre.de>>
Date: Saturday, February 15, 2014 4:22 AM
To: OSPF - OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt


Am Montag, 10. Februar 2014, 14:33:05 schrieb RJ Atkinson:

> 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.

I know that such deployments are normally well planned, but as there is already a draft about ospfv3 autoconfig, even if it is not designed to be used in company networks.



> 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.

I would not do it either, but I have already seen some strange ospf designs..., and as mentioned it is a case which can happen with ospf autoconfiguration, but we don't need to discuss it further as it is for homenetworks



> 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



Thanks for the detailed anwsers, I'm satisfied with the addition.



Kind regards,

Karsten

>

>

> _______________________________________________

> OSPF mailing list

> OSPF@ietf.org<mailto:OSPF@ietf.org>

> https://www.ietf.org/mailman/listinfo/ospf