Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 08 August 2016 22:32 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22E012D0F9; Mon, 8 Aug 2016 15:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 8YwcnPHEMFD3; Mon, 8 Aug 2016 15:32:51 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 966EB12D0CB; Mon, 8 Aug 2016 15:32:51 -0700 (PDT)
Received: by mail-pa0-x22f.google.com with SMTP id ti13so39350369pac.0; Mon, 08 Aug 2016 15:32:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XpfPScMh97thHxpokeIqiO18b619tM5i61J0+FJhqQU=; b=eb7E92S0nRMjtygl4f4gJVgtkuVlfa9wgXguGIviz1k1FaNwdY0QPf6RksJ+Q/o64m +RD6lz028lXObPXfI9iGh1COFjUDjZae+qVx63ziIpX0xGiqyxtxpq0JDakyejP/E0F8 VV621EUjDLy5tVIAkr2lFZMqBlem6yMizaRjGIQu761z3bjl2MK/9LtIGIzaDTfMgoT9 atyFBsWLkXwqmoWUkuhRREXQSlQ6GglqpZLTE9EG/IllFbAU+9rdaNknZcNsYJrRzHY/ PCwBslxaOL41bz3405fkwNjDK6lHlmIFL6kCBlf1Nko4XZVgFDbumsUfnk63jFIpnIYZ Elng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=XpfPScMh97thHxpokeIqiO18b619tM5i61J0+FJhqQU=; b=HUfYlEk8Wj1eImQumfpx1FpeEBkXWDsDrZjplKU36NjZXUBPWVydH7F4e1YJAlPZ5b 1tTOaoHlYiLXDn+wvy2eanL02Pggc0NidC4M+pxFGSMbio32GMSnUQrAE0WJcPPGFru4 tq5KQ9RxnW/OjzX8BV896Yv53Qfe2zWISbK3GAgfoPc8SW5OeDwdYMwxWSovktnpfspi E3q3DU6isCnnP4Xi1N3TtXdTz9HivCxGWKFX/7I0KpgyV9fLMVZNIn0SkPdTqKvjtWFC V9WInyUo5ipDby/M06PR+uQo+9aZ29GLjfKmWzoewFO29+/Fu+vo9XduHtTbvi3iP1k/ eFSA==
X-Gm-Message-State: AEkoouvgBs86+aoDEVCHwWqW/MkhsL1N2Qk8sxFjkvIo6mxNydP6YHUmn1OoiBjRcsKjPw==
X-Received: by 10.66.221.229 with SMTP id qh5mr82059372pac.66.1470695571009; Mon, 08 Aug 2016 15:32:51 -0700 (PDT)
Received: from ?IPv6:2406:e007:7ab6:1:28cc:dc4c:9703:6781? ([2406:e007:7ab6:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c82sm50432916pfb.72.2016.08.08.15.32.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Aug 2016 15:32:50 -0700 (PDT)
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-ospf-two-part-metric.all@ietf.org" <draft-ietf-ospf-two-part-metric.all@ietf.org>, General Area Review Team <gen-art@ietf.org>
References: <4ee8e895-a939-d747-a82f-fb7c8696b36e@gmail.com> <D3CE3687.7666E%acee@cisco.com> <7b3e0da4-2cf9-d91d-d179-1d6179c0f9b3@gmail.com> <D3CE6B15.768D6%acee@cisco.com> <DM5PR05MB31450ECE7E1D36D20EEB43B4D41B0@DM5PR05MB3145.namprd05.prod.outlook.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <3f178376-8fbb-d21c-81b2-061afefb7d30@gmail.com>
Date: Tue, 9 Aug 2016 10:32:47 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <DM5PR05MB31450ECE7E1D36D20EEB43B4D41B0@DM5PR05MB3145.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/z4NAuHW-GqfATdKxsLhQKEabSIw>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2016 22:32:54 -0000

Hi,

That's all good. With the clarifcations, I think the "Updates" is OK too.
I still don't think you need the pre-2008 disclaimer, but that's a nit.

Thanks
   Brian

On 09/08/2016 09:27, Jeffrey (Zhaohui) Zhang wrote:
> Please see -07 version that should address the issues raised by Brian (except that "update" part).
> 
> https://tools.ietf.org/html/draft-ietf-ospf-two-part-metric-07
> 
> Thanks.
> Jeffrey
> 
>> -----Original Message-----
>> From: Acee Lindem (acee) [mailto:acee@cisco.com]
>> Sent: Monday, August 08, 2016 5:02 PM
>> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; draft-ietf-ospf-two-
>> part-metric.all@ietf.org; General Area Review Team <gen-art@ietf.org>
>> Subject: Re: Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-
>> 05
>>
>> Hi Brian,
>>
>> See one inline.
>>
>> On 8/8/16, 4:18 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
>> wrote:
>>
>>> Hi Acee,
>>>
>>> Thanks, just a few points in line:
>>>
>>> On 09/08/2016 05:47, Acee Lindem (acee) wrote:
>>>> Hi Brian,
>>>>
>>>> Thanks much for the thorough review. Jeffrey and I discussed your
>>>> comments
>>>> this morning. See responses to your major/minor comments below. We will
>>>> incorporate all the nits.
>>>>
>>>> On 8/6/16, 9:38 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
>>>> wrote:
>>>>
>>>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>>>> by the IESG for the IETF Chair.  Please treat these comments just
>>>>> like any other last call comments.
>>>>>
>>>>> For more information, please see the FAQ at
>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>>
>>>>> Document: draft-ietf-ospf-two-part-metric-05.txt
>>>>> Reviewer: Brian Carpenter
>>>>> Review Date: 2016-08-07
>>>>> IETF LC End Date: 2016-08-15
>>>>> IESG Telechat date:
>>>>>
>>>>> Summary: Almost ready
>>>>> --------
>>>>>
>>>>> Major issues:
>>>>> -------------
>>>>>
>>>>>> Updates: 2328, 5340 (if approved)
>>>>>
>>>>> If that is so, the text needs to explain what is changed in those two
>>>>> RFCs. Since
>>>>> this draft describes an "optional extension" to OSPF, it does not
>>>>> obviously update
>>>>> them. Is any text in those two RFCs made invalid by this draft?
>>>>
>>>> This has been an ongoing debate as to whether an RFC the augments an
>>>> existing draft updates it or whether it must actually change the
>>>> existing
>>>> behavior. In this case, the SPF calculation is modified as specified in
>>>> section 3.6 but only when the new Network-to-Router metric is
>>>> advertised.
>>>> In RFC 2328 and RFC 5340, this cost is always zero (i.e., cost to reach
>>>> all routers connected to the network is solely the outgoing metric
>>>> metric
>>>> or Router-to-Network metric).
>>>
>>> OK, fair comment.
>>>
>>>>
>>>> I, for one, would be very happy to have consensus of precisely what
>>>> constitutes update to an existing RFC.
>>>
>>> So would many people, and since it affects all RFC streams, not just the
>>> IETF stream, I happen to know that the RFC Editor is working on
>>> definitions
>>> for both "updates" and "obsoletes".
>>>
>>>> If we don’t update the existing
>>>> RFCs, we would avoid the pre-2008 IPR language.
>>>
>>> That doesn't seem right. You only need that language if you are updating
>>> whole chunks of older text. If you take a paragraph from a pre-2008
>>> document,
>>> change a few words, and patch it into the new document, you need either
>>> the agreement of the original authors or the pre-2008 disclaimer. But I
>>> don't think you're doing that in this case, are you?
>>
>> No. We are simply using the context of the existing SPF calculation to
>> describe the additional function.
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>>
>>>>>> 3.6.  SPF Calculation
>>>>>>
>>>>>>   During the first stage of shortest-path tree calculation for an
>>>>>> area,
>>>>>>   when a vertex V corresponding to a Network-LSA is added to the
>>>>>>   shortest-path tree and its adjacent vertex W (joined by a link in
>>>>>> V's
>>>>>>   corresponding Network LSA), the cost from V to W, which is W's
>>>>>>   network-to-router cost, is determined as follows:
>>>>>
>>>>> I can't parse that sentence. If we delete the subordinate clauses, we
>>>>> get
>>>>>
>>>>>  When a vertex V is added to the shortest-path tree and its adjacent
>>>>> vertex W,
>>>>>  the cost from V to W is determined as follows:
>>>>>
>>>>> What does that mean? What does "its" refer to? Is W adjacent to V, or
>>>>> is
>>>>> W adjacent
>>>>> to the existing tree? Is W added to the tree before V, or is V added
>>>>> before W?
>>>>> If I was coding this, I'd have no idea what to do.
>>>>
>>>> You really do have to look at RFC 2328 to understand it.
>>>
>>> Yes, I did that in some detail when I was teaching routing a few years
>>> ago ;-)
>>>
>>>> Does this
>>>> modified text parse better?
>>>>
>>>>     The first stage of the shortest-path tree calculation is described
>>>>     in section 16.1 of [RFC 2328] and modified for OSPFv3 as described
>>>> in
>>>>     section 4.8.1 of [RFC 5340]. When a vertex V corresponding to a
>>>> Network-LSA
>>>>     has just been added to the Shortest Path Tree (SPT) and an adjacent
>>>> vertex W
>>>>     (joined by a link in V’s corresponding Network-LSA) is being added
>>>> to
>>>>     the SPT, the cost from V to W (W’s network-to-router cost) is
>>>> determined
>>>>     as follows:
>>>
>>> MUCH better. It also clarifies the "Updates:" aspect.
>>>
>>> Thanks
>>>   Brian
>>>
>>>>
>>>>>
>>>>>> 3.7.  Backward Compatibility
>>>>>
>>>>> This calls for a Router Functional Capability Bit assignment under RFC
>>>>> 7770.
>>>>> The bit number should be given as (say) TBD1 not as 0.
>>>>>
>>>>>> 4.  IANA Considerations
>>>>>
>>>>> The IANA considerations ask for four assignments. These should be
>>>>> specified as TBD1,
>>>>> TBD2, TBD3, TBD4 and the TBDs elsewhere in the text should be updated
>>>>> correspondingly.
>>>>> Also, please reference the relevant RFCs (7770 and whatever defines
>> the
>>>>> Sub-TLV registries.)
>>>>
>>>> 3.7 and 4 are both fixed in -06 based on comments from Alia.
>>>>
>>>>>
>>>>> Finally, to put this on the standards track, I would really expect to
>>>>> see
>>>>> an Implementation Status section (RFC 7942). Has this been tested?
>>>>
>>>> The implementation of this stalled. However, it is viewed by the WG as
>>>> straight-forward enough to advance.
>>>>
>>>>
>>>>>
>>>>> Minor issues:
>>>>> -------------
>>>>>
>>>>> Please check the three occurrences of lower-case "must" in Section 3.
>>>>> Should they be "MUST"?
>>>>>
>>>>>> 5.  Security Considerations
>>>>>>
>>>>>>   This document does not introduce new security risks.
>>>>>
>>>>> That's easy to say but hard to prove. Shouldn't you at least refer to
>>>>> the
>>>>> security
>>>>> considerations of OSPFv2 and OSPFv3?
>>>>
>>>> We will add the reference.
>>>>
>>>>>
>>>>> Also, does section 3.7 introduce a new risk whereby a rogue router
>>>>> could
>>>>> flap its
>>>>> Two-Part Metric bit on and off, causing all its OSPF peers to
>>>>> continually
>>>>> recalculate
>>>>> their routes?
>>>>
>>>> This is no more of a risk than other intra-area metric change.
>>>>
>>>> Thanks,
>>>> Jeffrey and Acee
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Nits:
>>>>> -----
>>>>>
>>>>>> Requirements Language
>>>>>
>>>>> It's unusual to put this at the front. The normal place is after the
>>>>> Introduction.
>>>>>
>>>>>>  This document may contain material from IETF Documents or IETF
>>>>>>  Contributions published or made publicly available before November
>>>>>>  10, 2008. ...
>>>>>
>>>>> Why is this needed? What did you copy from an old document?
>>>>>
>>>>>> 0 OSPF Two-part Metric [TPM]
>>>>>
>>>>> The abbreviation TPM is defined but not used, so why bother? Also,
>>>>> s/[TPM]/(TPM)/ to
>>>>> avoid confusion with a reference.
>>>>>
>>>>>> routes w/o considering any network-to-router costs.
>>>>>
>>>>> Just say "without".
>>>>
>>>
>