Alvaro, Thanks for the review and comments. Pls see inline..
Rgds Shraddha -----Original Message----- From: Alvaro Retana [mailto:aretana.i...@gmail.com] Sent: Wednesday, January 24, 2018 11:27 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-ospf-link-overl...@ietf.org; Acee Lindem <a...@cisco.com>; ospf-cha...@ietf.org; ospf@ietf.org Subject: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-ospf-link-overload-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=2yotvig0Pod2iYz1kE1G9Yj72-TdzzWuw-Wi17D6TfU&s=8uPkIAPxrIiuVMLudgaSbVjvc-3iZNkLaXrmc6GJpZM&e= for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dospf-2Dlink-2Doverload_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=2yotvig0Pod2iYz1kE1G9Yj72-TdzzWuw-Wi17D6TfU&s=5Dmkf-qOIfCiHPCyuj-sVNDcS904luv_ECpSb3D5HVM&e= ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I debated about filing my first comment as a DISCUSS [1], but decided against it because it should be very easy to solve. The rest are non-blocking comments. (1) The following should be Normative references: rfc2119 and rfc6987 -- this last one because MaxLinkMetric (which is defined there) is extensively used (as a MUST) throughout the document. <Shraddha> OK (2) Section 3. (Flooding Scope) provides information about the flooding scope, but only references for OSPFv2. It would be nice if the references for OSPFv3 were included there as well. <Shraddha> OK (3) Section 4.5. mentions that a "new TLV called Graceful-Link-Shutdown is defined" for BGP-LS, but there are no details on the format, etc. The IANA Considerations section suggests a value, not for a TLV but for an NLRI Type! <Shraddha> OK. Refered section 3.1 of RFC 7752 and described the contents of the TLV IANA section seems ok to me. Could you be more specific what needs to change? BGP-LS Link NLRI Registry [RFC7752] >>>>>>>Registry i)Graceful-Link-Shutdown TLV - Suggested 1101 >>>>>>>TLV type (4) Section 5: "The node that has the link to be taken out of service SHOULD advertise the Graceful-Link-Shutdown sub-TLV..." When would the node not advertise the sub-TLV? IOW, why is "MUST" not used? <Shraddha> Thanks for pointing out. Changed to MUST. (5) In 5.1: "MAX-TE-METRIC is a constant defined by this draft and set to 0xfffffffe." Assuming that the intent is to define a new architectural constant... I would rather see this constant defined separately (in it's own section/sub-section with a formal definition) instead of "in passing" while describing how to use it (a la MaxLinkMetric in rfc6987). <Shraddha> OK (6) 5.1 says that the metrics "MUST be set to MaxLinkMetric...and SHOULD be set to MAX-TE-METRIC". Why is there a difference? <Shraddha> TE is an optional feature so MAX-TE-METRIC needs to be set only when TE is enabled on the node. (7) s/MAX_METRIC/MaxLinkMetric <Shraddha> ok. [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=2yotvig0Pod2iYz1kE1G9Yj72-TdzzWuw-Wi17D6TfU&s=8uPkIAPxrIiuVMLudgaSbVjvc-3iZNkLaXrmc6GJpZM&e= _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
