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

From: Brian E Carpenter <[email-masked]>
Date: Sun, 7 Aug 2016 13:38:52 +1200

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?

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

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

Finally, to put this on the standards track, I would really expect to see
an Implementation Status section (RFC 7942). Has this been tested?

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?

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?

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 8 Aug 2016 17:47:20 +0000

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.

>IETF LC End Date: 2016-08-15

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

I, for one, would be very happy to have consensus of precisely what
constitutes update to an existing RFC. If we don’t update the existing
RFCs, we would avoid the pre-2008 IPR language.

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

>Also, please reference the relevant RFCs (7770 and whatever defines the

3.7 and 4 are both fixed in -06 based on comments from Alia.

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

We will add the reference.

>Two-Part Metric bit on and off, causing all its OSPF peers to continually

This is no more of a risk than other intra-area metric change.

Thanks,
Jeffrey and Acee

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Aug 2016 08:18:50 +1200

Hi Acee,

Thanks, just a few points in line:

> or Router-to-Network metric).

OK, fair comment.

> 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

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?

> 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

MUCH better. It also clarifies the "Updates:" aspect.

Thanks
   Brian

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 8 Aug 2016 21:02:19 +0000

Hi Brian, 

See one inline. 

>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

>>> What does that mean? What does "its" refer to? Is W adjacent to V, or
>>>is
>>> W adjacent
>>> That's easy to say but hard to prove. Shouldn't you at least refer to
>>>the
>>> security
>>> 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?
>>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 8 Aug 2016 21:27:20 +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:[email-masked]]
> Sent: Monday, August 08, 2016 5:02 PM
> To: Brian E Carpenter <[email-masked]>; draft-ietf-ospf-two-
> [email-masked]; General Area Review Team <[email-masked]>
> Subject: Re: Gen-ART Last Call review of draft-ietf-ospf-two-part-metric-
> 05
> 
> Hi Brian,
> 
> See one inline.
> 
> >>> Also, please reference the relevant RFCs (7770 and whatever defines
> the
> >>> Sub-TLV registries.)
> >>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Aug 2016 10:32:47 +1200

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 10 Aug 2016 02:09:40 +0000

Hi Brian, 
I believe we got a warning from xml2rfc when we didn’t use the pre-2008
disclaimer (since the draft “updates” RFC 2328).
Thanks,
Acee 

On 8/8/16, 6:32 PM, "Brian E Carpenter" <[email-masked]>
wrote:

>>>>>> If that is so, the text needs to explain what is changed in those
>>>>>>two
>>>>>> RFCs. Since
>>>>>> I can't parse that sentence. If we delete the subordinate clauses,
>>>>>>we
>>>>>> get
>>>>>>
>>>>>     in section 16.1 of [RFC 2328] and modified for OSPFv3 as
>>>>>described
>>>>> in
>>>>>     (joined by a link in V’s corresponding Network-LSA) is being
>>>>>added
>>>>> to
>>>>>> This calls for a Router Functional Capability Bit assignment under
>>>>>>RFC
>>>>>> 7770.
>>>>>> TBD2, TBD3, TBD4 and the TBDs elsewhere in the text should be
>>>>>>updated
>>>>>> correspondingly.
>>>>>> Finally, to put this on the standards track, I would really expect
>>>>>>to
>>>>>> see
>>>>>> Please check the three occurrences of lower-case "must" in Section
>>>>>>3.
>>>>>> Should they be "MUST"?
>>>>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Aug 2016 16:35:51 +1200

> disclaimer (since the draft “updates” RFC 2328).

That's correct, it generates such a warning, but it's more in the form
of a question ("do you need this?" not "you need this!"). It's confusing.
Most times, it's not needed.

I was in at the birth of that waiver; it drove me nuts that we had to allow
for it.

   Brian