Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-general-constraints-ospf-te

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Feb 2015 21:53:48 -0000

Authors!

I have done my usual AD review of this document to prepare it for
IETF last call and IESG evaluation. It's in good shape and my comments
below are nearly completely editorial.

Please have a look and let me know if you disagree. Otherwise, post a
new revision and I'll take the document forward.

Thanks for the work,
Adrian

---

You need to split the Authors' Addresses sections into:
- Authors' Addresses reflecting those on the front page
- Contributors containing all the others

---

Section 1 has:

   The top-level TLV can take one of three values (1)
   Router Address [RFC3630], (2) Link [RFC3630], (3) Node Attribute
   defined in Section 2.

Shouldn't this be:

   The top-level TLV can take one of three values (1)
   Router Address [RFC3630], (2) Link [RFC3630], (3) Node Attribute 
   [RFC5786].

---

We need to do some work on the IANA stuff.

In Section 2, please replace

OLD
   Per [GEN-Encode], we have identified the following new Sub-TLVs to
   the Node Attribute TLV as defined in [RFC5786]. Detailed description
   for each newly defined Sub-TLV is provided in subsequent sections:

      Sub-TLV Type      Length         Name

      14 (Suggested)    variable       Connectivity Matrix
NEW
   Per [GEN-Encode], this document defines the Connectivity Matrix Sub-
   TLV of the Node Attribute TLV defined in [RFC5786].  The new Sub-TLV
   has Type TBD1 (to be assigned by IANA).
END

In Section 3, please replace

OLD
   Per [GEN-Encode], we add the following additional link sub-TLVs to
   the link TLV in this document.

      Sub-TLV Type      Length         Name

      26 (suggested)    variable       Port Label Restrictions
NEW
   Per [GEN-Encode], this document defines the Port Label Restrictions 
   Sub-TLV of the Link TLV defined in [RFC3630].   The new Sub-TLV has
   Type TBD2 (to be assigned by IANA).
END

In Section 7.1, please replace

OLD
   This document defines a new sub-TLV of the Node Attribute TLV (Value
   5). The assignment of the following new type in the "Types for sub-
   TLVs of TE Node Attribute TLV" portion of the "Open Shortest Path
   First (OSPF) Traffic Engineering TLVs" registry is needed:

   This document introduces the following sub-TLVs of Node Attribute
   TLV (Value 5):

      Type                                      sub-TLV

      14 (suggested, to be assigned by IANA)    Connectivity Matrix
NEW
   IANA maintains the "Open Shortest Path First (OSPF) Traffic
   Engineering TLVs" registry with a sub-registry called "Types for sub-
   TLVs of TE Node Attribute TLV".  IANA is requested to assign a new 
   code point as follows:

      Type   |  Sub-TLV                      |  Reference
      -------+-------------------------------+------------
      TBD1   |  Connectivity Matrix sub-TLV  |  [This.I-D]

END

In Section 7.2, please replace

OLD
   This document defines a new sub-TLV of the TE Link TLV (Value 2).
   The assignment of the following new type in the "Types for sub-TLVs
   of TE Link TLV" portion of the "Open Shortest Path First (OSPF)
   Traffic Engineering TLVs" registry is needed:

      Type                                      sub-TLV

      26 (suggested, to be assigned by IANA)    Port Label Restrictions
NEW
   IANA maintains the "Open Shortest Path First (OSPF) Traffic
   Engineering TLVs" registry with a sub-registry called "Types for sub-
   TLVs of TE Link TLV".  IANA is requested to assign a new code point
   as follows:

      Type   |  Sub-TLV                          |  Reference
      -------+-----------------------------------+------------
      TBD2   |  Port Label Restrictions sub-TLV  |  [This.I-D]
END

---

I think Section 6 should also reference 5250 since Opaque LSAs are,
themselves, an attack vector.

---

Did you consider including a short manageability section?

Are there any existing management tools that are impacted by the new
sub-TLVs?

What might a user expect to configure related to these sub-TLVs?

What might a user expect to be able to read from a device?

---

From: Leeyoung <[email-masked]>
Date: Tue, 10 Feb 2015 16:22:23 +0000

Hi Adrian,

Here's my comment, please see inline.  

Thanks.
Young

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, February 09, 2015 3:54 PM
To: [email-masked]
Cc: Alvaro Retana; [email-masked]; [email-masked]
Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-general-constraints-ospf-te

Authors!

Thanks for the work,
Adrian

---

YOUNG>> OK. 
---

Section 1 has:

Shouldn't this be:

YOUNG>> OK.
---

OLD

      Sub-TLV Type      Length         Name

OLD

      Sub-TLV Type      Length         Name

OLD

      Type                                      sub-TLV

END

OLD

      Type                                      sub-TLV

YOUNG>> OK. Thanks. 
---

YOUNG>> OK. 
---

YOUNG>> No, as you see the content. Do you have any suggestion in mind? 

YOUNG>> I don't think so. 

YOUNG>> These questions sound like either a mib or yang question. I think the TLVs defined in this document can be configured/read by EMS or NMS or other system. 
Shall a companion document (mib or yang, which by the way I am working on WSON Yang model on these TLVs included) if you will address these questions? 
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp