Re: [OSPF] AD review of draft-ietf-ospf-transition-to-ospfv3-07

Alia Atlas <akatlas@gmail.com> Thu, 09 June 2016 22:59 UTC

Return-Path: <akatlas@gmail.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 8700412B02C for <ospf@ietfa.amsl.com>; Thu, 9 Jun 2016 15:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level:
X-Spam-Status: No, score=-102.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 hlxoRPZJj8yT for <ospf@ietfa.amsl.com>; Thu, 9 Jun 2016 15:59:24 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 33DEE12D5FC for <ospf@ietf.org>; Thu, 9 Jun 2016 15:59:24 -0700 (PDT)
Received: by mail-qg0-x230.google.com with SMTP id q32so28400940qgq.3 for <ospf@ietf.org>; Thu, 09 Jun 2016 15:59:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xDFjc4lAaZerGWW3yOmMByVvcAA1wOZLUQzP+dwgt04=; b=q2ZdxMie5A/ERsEYI4yzd/MIt2CUYDTwkifGsSBHXsObtVaiCMFZhkHfLW39iAdn0G S1gz7rypsBufavuHb7xtG4kGrDYSBnBDF8svg064g9FLELd8uDvf5s8swvn1QIyUlito 9vKFhbd27tLZdQx60I5SvECpePtKg+5kcPfMM2H9kacbqRjUH4aPF269N52G44D/12cs zLQEjF12D7Ogiv8p8gIBip/n65Qhx5aMtqQEv2bMQu+IJXNr2ZJHP8CjPgmrSjtaI1i1 t66yYQaamO+2QnfWau/JZpKyU5YqBVqf8f5PliNha472iahHXeImIaEAFZdSbk1q3Kod siMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xDFjc4lAaZerGWW3yOmMByVvcAA1wOZLUQzP+dwgt04=; b=L0xCSji2mmI1mVvNzqiAEGpGlvlQOSTeqUgGW/Oc6mLHB+T9dr3hOUFcuaCt2Mixfn wd1IZUi0oDXTXqgNsl+FIghRsrZQoM1B8Ijf1+LNj3YUrnE625jRNUiI7Qtgusi2tX8+ 5jAk4eSJCI7Xw7ABfbC34wgCCOJ7ejhKm+y6xcBmrLeC2S7lsposthwHN+hCHhmt0oDV Wn/U4qT2sEq+WZfzTBqsWUNQx6xYJAdZPUGYupwbS53C+GoUiPPZ44aauAQWix5EkMnN 4/E1N1Gs8u8T2AtyNmkggDGQ1CylwhlHZ+F2L/2+qFrv594mq56JTd1C8gnzv4OqHQyK QXTw==
X-Gm-Message-State: ALyK8tK7HfAWOTX0cMEyn89wamn6LtMp51Hn1+tWQ9g0Bw1tLd1SO5BplzaNWTynlJ54Jj4PU1vqhShH6Yp83w==
X-Received: by 10.140.175.135 with SMTP id v129mr10776670qhv.5.1465513163382; Thu, 09 Jun 2016 15:59:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.57.81 with HTTP; Thu, 9 Jun 2016 15:59:22 -0700 (PDT)
In-Reply-To: <D37F6772.63F09%acee@cisco.com>
References: <CAG4d1rf0JHe=4TZVcOfdBFA13WpRWHpXF5=AHCysyKzXTiX-WQ@mail.gmail.com> <D37F6772.63F09%acee@cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Thu, 09 Jun 2016 18:59:22 -0400
Message-ID: <CAG4d1rfNNy5_TGFf=EWetzeKVx6X0ZNsxsLgx7iaxRfwCXub0A@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Content-Type: multipart/alternative; boundary="001a113a64e08464c80534e05f90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/UGhOGaisFacBDvryhPqWS_pQBrQ>
Cc: OSPF List <ospf@ietf.org>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-transition-to-ospfv3-07
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: Thu, 09 Jun 2016 22:59:30 -0000

Hi Acee,

On Thu, Jun 9, 2016 at 6:42 PM, Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Alia,
>
> Thanks for the review - you caught some rather subtle points.
>

thanks - this was a nice tractable draft to read in a short time.



> From: OSPF <ospf-bounces@ietf.org> on behalf of Alia Atlas <
> akatlas@gmail.com>
> Date: Thursday, June 9, 2016 at 3:57 PM
> To: OSPF WG List <ospf@ietf.org>
> Subject: [OSPF] AD review of draft-ietf-ospf-transition-to-ospfv3-07
>
> As is customary, I have done my AD review
> of draft-ietf-ospf-transition-to-ospfv3-07.
> First, I would like to thank the authors for their work on this document.
> It looks like
> very useful technology.
>
> I have a few minor questions below.  I will put this into IETF Last Call
> as well while
> waiting for the authors to update the draft ASAP.   That gives a chance of
> making it
> on to the June 30 telechat if the authors are responsive.
>
> Minor:
>
> 1) Sec 3.1:  "If this is supported, the IPv4 data plane MUST resolve
>      the layer-2 address using Address Resolution Protocol (ARP) on
>      multi-access networks and point-to-point over LAN [RFC5309] for
>      direct next-hops on different IPv4 subnets."
>
>      I believe it is the IPv4 (i.e. layer-3) address to be resolved with
> ARP - not the
>      layer-2 address.
>
>
> Ok - this text comes from me and I was viewing resolution from the
> standpoint of the “to” address family rather than the “from” address
> family. I agree the “from” address family is probably a more common
> characterization.
>

Feel free to say "MUST resolve from the IPv4 address to the layer-2 address
using ARP...." if you
want extreme clearness.



>
>
> 2) Sec 3.3: "If IPv4 transport, as specified herein, is used for IPv6
> address
>      families, virtual links cannot be
>      supported. Hence, it is RECOMMENDED to use the IP transport
>      matching the address family in OSPF routing domains requiring
>      virtual links."
>
>      From this section, I was expecting that "cannot" would be a "can".
> Did
>      I miss something?  Can you clarify further?
>
>
> The draft doesn’t address virtual link support in deployments where the
> address-family doesn’t match the transport. Hence, the text is correct as
> written.
>

Ok - but the draft  just says
"Hence, it is RECOMMENDED to use the IP transport
     matching the address family in OSPF routing domains requiring
     virtual links."

Can you clean this up to be extremely clear?
With an IPv4 transport, IPv6 virtual links are not supported.
With an IPv4 transport, IPv4 virtual links are supported.

and vice versa.

I read the relaxation as applying to both IPv4 and IPv6; maybe I was
reading too fast, but a few clarifying
words would probably help.

3) Sec 1: 2nd to last paragraph: "In situations where the IPv6 deployment
> is a
>    proper superset of the IPv4 deployment, it is expected that OSPFv3
>    would be transported over IPv6."
>
>    I believe the "proper" should be removed.   If the IPv6 deployment is
> exactly the same
>    as the IPv4 deployment, then it is expected that OSPFv3 would be
> transported over
>    IPv6.     As it is,how the case of equal deployment is handled is
> unspecified.
>
>
> I agree. We will remove “proper".
>

thanks,
Alia

>
>


> Thanks,
> Acee
>
>
>
> Thanks,
> Alia
>
>