Re: [OSPF] AD review of draft-ietf-ospf-ospfv3-lsa-extend

["Acee Lindem (acee)" <[e-mail]>]

Hi Alia,

Thanks for your comments. I  believe that the –20 version addresses them. Please  see inline.

From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 19, 2017 at 6:49 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, OSPF WG List <[e-mail]<mailto:[e-mail]>>
Subject: AD review of draft-ietf-ospf-ospfv3-lsa-extend
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, "Goethals, Dirk (Nokia - BE/Antwerp)" <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Fred Baker <[e-mail]<mailto:[e-mail]>>
Resent-Date: Tuesday, December 19, 2017 at 6:49 PM

As is customary, I have done my AD review of draft-ietf-ospf-ospfv3-lsa-extend-19.  First, I would like to thank the authors - Acee, Abhay, Dirk, Veerendranatha, and Fred- and the implementors at Nokia and Huawei (who have enabled us to move forward on this critical document) and the WG.  This draft is very important for adding improved  flexiblity to OSPFv3 for IPv6 compared to what we enjoy for OSPFv2.

I do have some minor concerns and nits - as listed below. I am going to put this document into a 3 week IETF Last Call (given the holiday season) and place it on the telechat for Jan 25, 2018.  Please do respond and update the draft in a timely fashion (given I'm on vacation until 2018).

1)  Given the extensive changes to OSPFv3 and the expectation that implementations of OSPFv3 will support this, the draft should update RFC 5340 (and mention that in the abstract as well).

I have indicated that the draft updates both RFC 5340 and RFC 5838.

2) In Sec 3: it would be helpful to indicate how many levels of nesting of TLVs are supported.  There are clearly TLVs and sub-TLVs.  Can there be sub-sub-TLVs?  Can there be an arbitrarily deep level of sub-TLVs?  Please just clarify - b/c it can affect folks implementations and also assumptions for how to define the various sub-TLVs.

This is really not an issue as demonstrated by the nesting of Sub-TLVs in GMPLS technology specific OSPF TE LSAs. I think it is a mistake that a big deal is made of this in IS-IS. Nevertheless, I have added:

   While this document only describes the usage of TLVs and
   Sub-TLVs, Sub-TLVs may be nested to any level as long as the Sub-TLVs
   are fully specified in the specification for the subsuming Sub-TLV.

3) Sec 3.3: Is there a reason that sub-TLVs aren't listed in the figure?  I see them in the figures for sec 3.2 and 3.4 without explanation.  Consistency would be good. I could picture it being helpful to include, for instance, an SRLG or other information.

The reason that there are no Sub-TLVs described, is that none are allowed for the Attached-Routers TLV. The reasoning for is included in the text.


   There are two reasons for not having a separate TLV or sub-TLV for
   each adjacent neighbor.  The first is to discourage using the E-
   Network-LSA for more than its current role of solely advertising the
   routers attached to a multi-access network.  The router's metric as
   well as the attributes of individual attached routers should be
   advertised in their respective E-Router-LSAs.  The second reason is
   that there is only a single E-Network-LSA per multi-access link with
   the Link State ID set to the Designated Router's Interface ID and,
   consequently, compact encoding has been chosen to decrease the
   likelihood that the size of the E-Network-LSA will require IPv6
   fragmentation when advertised in an OSPFv3 Link State Update packet.


4) Sec 4.1: Please clarify whether an E-Router-LSA is malformed if it does not contain at least one Router-Link TLV.

I have added this.

   Depending on the implementation, it is perfectly valid for an E-
   Router-LSA to not contain any Router-Link TLVs.  However, this would
   imply that the OSPFv3 router doesn't have any active interfaces in
   the corresponding area and such E-Router-LSA would never be flooded
   to other OSPFv3 routers in the area.


5) Sec 4.7: I believe it is possible to have multiple IPv6 link-local addresses. I do see that RFC 5340 restricted OSPFv3 to advertising just one.  Is there a strong reason that if additional are sent  "Instances following the first MUST be ignored." ?  Perhaps this could be a SHOULD - to allow for flexibility?

Ok – I have changed this although I’m not familiar with the use case for multiples.

6) Sec 5: "an LSA MUST be considered malformed if it does not include any required TLV or Sub-TLVs."  should be "...not include all of the required TLVs or sub-TLVs." or the equiv.

I have fixed this.

   Additionally, an LSA MUST be considered malformed if it does not
   include all of the required TLVs and Sub-TLVs.



7) Sec 6.2: "Furthermore, the extended LSAs will only include those TLVs which require further specification for that new functionality.  Hence, this mode of compatibility is know as "sparse-mode"."  How does this interact with the Sec 5 that talks about malformed LSAs?  It seems like either this would be additional Extended LSAs (not defined in this draft) or it would have to include the mandatory information (but not for all links/ routers).

I have clarified this.

   Furthermore, those  extended LSAs will only include the top-level TLVs
   (e.g., Router-Link TLVs or Inter-Area TLVs) which require further specification
    for that  new functionality.  However, if a top-level TLV is advertised, it
   MUST include required Sub-TLVs or it will be considered malformed as
   described in Section 5.


8) Sec 8.2: Is there a reason to not have a sub-TLV range for either Expert Review or FCFS?  There are a lot of values - and this would support experimentation.

Ok – I took these from the unallocated range for both TLVs and Sub-TLVs.

   Types in the range 33024-45055 are to be assigned on a FCFS basis
   subject to IETF expert review.


9) Since this document is adding the "N" flag - an example for the usage would be helpful - and particularly articulating how it is different from the "LA" flag for usage.

I believe this is in section 3.1.1 already:

   The N-bit is set in PrefixOptions for a host address
   (PrefixLength=128) that identifies the advertising router.  While it
   is similar to the LA-bit, there are two differences.  The advertising
   router MAY choose NOT to set the N-bit even when the above conditions
   are met.  If the N-bit is set and the PrefixLength is NOT 128, the
   N-bit MUST be ignored.  Additionally, the N-bit is propagated in the
   PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an
   Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set
   in the PrefixOptions.  Similarly, the N-bit is propagated in the
   PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS-
   External-LSA corresponding to an NSSA route as described in section 3
   of RFC 3101 ([NSSA]).  The N-bit is added to the Inter-Area-Prefix-
   TLV (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area-
   Prefix-TLV (Section 3.7).  The N-bit is useful for applications such
   as identifying the prefixes corresponding to Node Segment Identifiers
   (SIDs) in Segment Routing [SEGMENT-ROUTING].


Nits:

a) Sec 3.1.1:  sentence missing a complete verb  "The N-bit is to the Inter-Area-Prefix-TLV   (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area-
   Prefix-TLV (Section 3.7)"
b) typos: differnt  addtional

Fixed.

Thanks,
Acee


Regards,
Alia