IETF Logo Mail Archive

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

"Acee Lindem (acee)" <acee@cisco.com> Thu, 09 June 2016 22:42 UTC

Return-Path: <acee@cisco.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 C89F112D5CB for <ospf@ietfa.amsl.com>; Thu, 9 Jun 2016 15:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 0L6hJ_JLu9pi for <ospf@ietfa.amsl.com>; Thu, 9 Jun 2016 15:42:32 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DEB12B05B for <ospf@ietf.org>; Thu, 9 Jun 2016 15:42:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11255; q=dns/txt; s=iport; t=1465512152; x=1466721752; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qMtSwboUkrz80nOMSNWkZLenwn++oZz2KqJHr/XAbGY=; b=I9+8DE102rkR9bQaacDe2o4giMlgxEhpy5xpJDgB5N+6nClRCkyWoi72 PVP+oRj/TlknhPg6Wu955YplKbSfWndcx14q1sAa/1caHlcL4zeOPUvcU kXy4zvmR7qW+QzJoLffCEOlhqOE6IC7r7kLmHJquM9y0pxFd2ZLj1YkdB g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BBAgCi71lX/4UNJK1egnBOgVMGrxaHAIJwgg+BeoYTAhyBIDgUAQEBAQEBAWUnhEUBAQEEI2YCAQgOAwMBAigDAgICHxEUCQgCBAESiBUDF61kjG0Ng3sBAQEBAQEBAQIBAQEBAQEBIIp0gkOCHYJhglkFkzyEZTQBjCyBeoFpjTeGQIE5h2sBHjaCBxyBS26JCX8BAQE
X-IronPort-AV: E=Sophos;i="5.26,447,1459814400"; d="scan'208,217";a="111360517"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jun 2016 22:42:31 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u59MgUOZ022356 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jun 2016 22:42:31 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 18:42:30 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 9 Jun 2016 18:42:30 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Alia Atlas <akatlas@gmail.com>, OSPF List <ospf@ietf.org>
Thread-Topic: [OSPF] AD review of draft-ietf-ospf-transition-to-ospfv3-07
Thread-Index: AQHRwok+uUYZzsz18kaAeu9BATV60Z/hu1EA
Date: Thu, 09 Jun 2016 22:42:30 +0000
Message-ID: <D37F6772.63F09%acee@cisco.com>
References: <CAG4d1rf0JHe=4TZVcOfdBFA13WpRWHpXF5=AHCysyKzXTiX-WQ@mail.gmail.com>
In-Reply-To: <CAG4d1rf0JHe=4TZVcOfdBFA13WpRWHpXF5=AHCysyKzXTiX-WQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: multipart/alternative; boundary="_000_D37F677263F09aceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/5972lcpvfXtq75RNghuU9LJ17Pk>
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:42:34 -0000

Hi Alia,

Thanks for the review - you caught some rather subtle points.

From: OSPF <ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org>> on behalf of Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Date: Thursday, June 9, 2016 at 3:57 PM
To: OSPF WG List <ospf@ietf.org<mailto: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.



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.



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,
Acee



Thanks,
Alia

v2.23.0 | Report a Bug | By Email