Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-ospf-prefix-link-attr-10.txt

From: Suresh Krishnan <[email-masked]>
Date: Wed, 19 Aug 2015 02:14:30 +0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-ospf-prefix-link-attr-10.txt
Reviewer: Suresh Krishnan
Review Date: 2015/08/18
IESG Telechat date: 2015/08/20

Summary: The draft is almost ready for publication as Proposed Standard 
but there are some minor issues that need to be addressed as stated in 
my last call review. We are on the process of converging on the fixes by 
email.

* Section 2

* In the packet format described in Figure "OSPFv2 Extended Prefix 
Opaque LSA" the numbers 9, 10 and 11 are shown in a field. I think it 
would be better if these are replaced by the text "LS type" as it is the 
actual field. This will provide consistency with the rest of the figure. 
The following text can then describe the allowed LS types as 9,10, and 11.

s/differential/differentiate/

* Padding of TLVs. I am assuming that the TLVs are padded using zero 
octets. If so, please state it explicitly.

* Section 2.1.

* In the packet format the "Address Prefix" field is marked as variable 
length when it actually *is not*. It is always encoded as 32 bits long, 
right? If so please the "(variable)" designation needs to be removed
for the Address Prefix.

* Shouldn't there be some IANA instructions for further extensions to 
the Flags field in the OSPFv2 Extended Prefix TLV? Or is this field not 
expected to be extended?

* IANA Considerations

* The Opaque LSA Options types used by this document (7 & 8) seem to be 
wrongly entered into the IANA registry and are pointing to 
[draft-ietf-ospf-segment-routing-extensions] instead of this draft. It 
is probably worth taking this up during the IANA check.

Thanks
Suresh

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Aug 2015 10:53:10 +0000

Hi Suresh, 
I thought Peter had addressed your comments. See inline.

>The following text can then describe the allowed LS types as 9,10, and 11.

I do agree that it is not consistent. However, this is inherited from RFC
5250 which is a BIS of 2370. Anyway, I can fix it.

>s/differential/differentiate/

Already fixed in -11 version.

>octets. If so, please state it explicitly.

This text regarding OSPF TLVs has been in at least 1/2 dozen RFCs without
confusion (starting with RFC 3630). I think the concept of padding is well
understood in the OSPF community. “The padding is composed of zeros.” has
been added. 

>right? If so please the "(variable)" designation needs to be removed

Already fixed in -11 version.

>the Flags field in the OSPFv2 Extended Prefix TLV? Or is this field not

Already fixed in -11 version. Need to re-open the IANA actions for the
draft though. 

>is probably worth taking this up during the IANA check.

No - these values do correspond to segment routing. This draft is a
prerequisite that defines the OSPF extension mechanisms and creates the
registry. 

Thanks,
Acee

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 19 Aug 2015 14:31:31 +0000

Hi Acee,
   I checked out the changes in the new version (12) and they look good. 
Thanks a lot for taking care of the changes. Only one pending comment 
from me. I will send in a new review.

> prerequisite that defines the OSPF extension mechanisms and creates the

I leave this to your discretion, but the IANA registry usually points to 
the draft that defined the values and 
draft-ietf-ospf-segment-routing-extensions *does not* seem to be 
defining them.

Just to be very precise these are the values that I am talking about

"
    This specification updates the Opaque Link-State Advertisements (LSA)
    Option Types with the following values:

    o  7 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Prefix
       Opaque LSA

    o  8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque
       LSA
"

and this is the IANA registry in question

http://www.iana.org/assignments/ospf-opaque-types/ospf-opaque-types.xhtml#ospf-opaque-types-2

Cheers
Suresh

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Aug 2015 14:35:54 +0000

Hi Suresh, 

>    o  8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque

Right - at one time these extensions were part of the OSPF SR draft. We
split them out and made them generic. I’ll alert them along with the new
OSPFv2 Prefix TLV Flags registry.

Thanks,
Acee

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Aug 2015 00:08:49 +0300

Suresh, Acee, thank you for your detailed reviews & action to revise based on them.

 I have balloted no-obj.

Jari