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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 08 August 2016 21:27 UTC

Return-Path: <zzhang@juniper.net>
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 CC79012D191; Mon, 8 Aug 2016 14:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 oh2Xm9KX2YAR; Mon, 8 Aug 2016 14:27:24 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0099.outbound.protection.outlook.com [104.47.38.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5937412D1A6; Mon, 8 Aug 2016 14:27:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b9Bljo06P9tyfD7UimxUpXKBvYsJ9vv1QPYw3o6Ubx4=; b=ClTEPGQTqTIX7LN/6EaZ7F5A1NwxsFDeWPuS5/JvfRaq22z82lRgvRdfVmOZZiimKoh0qGGzG9CxrQs5uO3TQ0TGaW6Sd9H+iFpV9Xtt7wnoGIbZxWYTvTWrcCjzLnWmeEU29lr0v9UW/GrVyP96IKgQL4c+0ovPhcje1FEw+Jg=
Received: from DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) by DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.4; Mon, 8 Aug 2016 21:27:21 +0000
Received: from DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) by DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) with mapi id 15.01.0544.024; Mon, 8 Aug 2016 21:27:21 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>, Brian E Carpenter <brian.e.carpenter@gmail.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>
Thread-Topic: Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-05
Thread-Index: AQHR8Ex7DRiH+tAazUKh4asmnfiJ/qA/WTkAgAAqVACAAAwmgIAABmSQ
Date: Mon, 08 Aug 2016 21:27:20 +0000
Message-ID: <DM5PR05MB31450ECE7E1D36D20EEB43B4D41B0@DM5PR05MB3145.namprd05.prod.outlook.com>
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>
In-Reply-To: <D3CE6B15.768D6%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net;
x-originating-ip: [66.129.241.14]
x-ms-office365-filtering-correlation-id: f8a167b6-55b4-4c40-5a39-08d3bfd2c817
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3145; 6:rqEiA9LsDRCeSv6KaYjUsKaBNZL+e2lCAITrx3XDGsvEbI7rKMyKEFm2LAkS5TYE6yxFaPt/EB1+MYYQxZVn3DT82kGWnoFaZOfmUYVQXdXlyniXhgPXulDnOXESWb4iFkt98EPVu3GdEs39WiBEYAyK5/B4OBvvy800WuSJz2LqlrsSFAqz8NxNWjDo48Hr6Ls1EU50Na7d8Ltixj636V1MkvWVAFmVP8Prmbdf008+fBTkiJMV1aFdjDa686nmPobhzPQPgZ58IXfgvjzZsFD1CfKT4XMq5vvyqKWWAVH3iHJZF2AigVSMzbK/u77uJjqqOdPQx5wAKzXJP0moUA==; 5:cby51Fsg59FkLgV77qOz7V+bI5E+wyylVbDL43EEPGwUJzLg7FnzZReJzIMlkZJIQVn3mOqUybqqtvRXK064VHmnSY8ScEuIrU/CNcHf1UTSmK6T0KSWNkAKl1l/0Nn2umsfwCyHU0skPOi4/itlTw==; 24:8YpB/A7x8AbkZEMzuvsEJjuJdAHi+d4h8uj64wifFvf4hL6Fugr64D/lSiRx+V86VgxnT2Jo7If2te5mtjalQKRGRfesfbH3YCuc1cX6yuQ=; 7:qyaHrgtBDenat5n4uc72napgs9OCqTnv7COCcusYS+F4faJskgkWg4VVsKZ9ZChwUhM574x6Nky8qcPVxFWh0GQyErvj//KBlwVe0Qs60Nc1WFvsP9McgZIpqBDHbRFwceAoZ24Mb8+pzNOn6VMZS80HUBRivDAfW1nAJ3VBUX1XSb5EQjwS8c9cSqTsX6iwy63HOvKj4DjDaaZnUTYkMhu5VsUvkfZ9UY10Q4i61LrBpGnGl5cV1xY4hVqKjxmQ
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR05MB3145;
x-microsoft-antispam-prvs: <DM5PR05MB31458ACB413C2F55287F636ED41B0@DM5PR05MB3145.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM5PR05MB3145; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3145;
x-forefront-prvs: 00286C0CA6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(377424004)(199003)(377454003)(13464003)(3846002)(102836003)(6116002)(2906002)(2950100001)(105586002)(122556002)(66066001)(10400500002)(76576001)(74316002)(2900100001)(77096005)(8676002)(93886004)(15975445007)(5001770100001)(97736004)(81166006)(81156014)(11100500001)(189998001)(107886002)(8936002)(7736002)(76176999)(3280700002)(5002640100001)(7696003)(50986999)(54356999)(230783001)(68736007)(92566002)(101416001)(106116001)(586003)(2501003)(9686002)(87936001)(33656002)(106356001)(99286002)(19580405001)(19580395003)(7846002)(305945005)(3660700001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3145; H:DM5PR05MB3145.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 21:27:20.9289 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3145
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/Ob_F6d3_iXa8zGdyFcc-_BEp4aE>
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 21:27:28 -0000

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