Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Shraddha,

Thanks for addressing most of the comments and please see a couple of responses in-line below for the outstanding ones.

Thanks,
Ketan

-----Original Message-----
From: Shraddha Hegde [mailto:[e-mail]] 
Sent: 31 January 2018 09:15
To: Ketan Talaulikar (ketant) <[e-mail]>; Alvaro Retana <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

Ketan,

Thanks for comments.
Pls see inline...

-----Original Message-----
From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
Sent: Thursday, January 25, 2018 1:58 PM
To: Shraddha Hegde <[e-mail]>; Alvaro Retana <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

Hi Shraddha,

A few comments and observations in the ver 14 and apologies for not providing some of them earlier, but I had a closer review after looking at Alvaro's comments and many improvements have happened recently.

Related to BGP-LS TLV:
For sec 4.5 - please mention the type here since the IANA section would get taken off by RFC editor. While you do refer to RFC7752 sec 3.1 for the TLV - I think it would be more reader friendly to describe the TLV and the code point in this section inline like the OSPF TLVs.
<Shraddha> OK updated in new version

For sec 10, the BGP-LS registry being referred to is wrong and it should be " BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" and the suggested codepoint is already taken so I would suggest to request for 1121. I believe this was pointed out during the early allocation call but seems like it got missed out so could you please correct/update?
<Shraddha>ok. updated latest version.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_bgp-2Dls-2Dparameters_bgp-2Dls-2Dparameters.xhtml&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=XBYEEARnw7lDAsfkNEsBkAkyVwYGvQ-2jj6E-wcs7TM&s=EL7ViyIcLwxx16_SC9EcrtseFsVFllPPOAYXwlPcUGk&e= 

Suggest making the section describing Maximum TE Metric before the current Sec 5 - Elements of procedure so the flow is better for the reader.
<Shraddha> We will use 0xffffffff so the definition is going away in new version.

Sec 5.1 

Instead of using SHOULD for TE metric, it would be better to qualify as " When TE is enabled, the TE metric of the link MUST be set to MAX-TE-METRIC (0xfffffffe) and the node MUST re-originate the corresponding TE Link Opaque LSAs."
<Shraddha> I think there should be an option of not following procedures defined in this document if traffic engineering applications don't need it (changing reverse side metric). I can't think of a usecase right now but I think this flexibility is needed.
[KT] This document brought in a key difference from the previous (i.e. RFC6987 & RFC5817) in that when OSPF (in general IGPs) signal a link graceful shutdown/maintenance then it applies not just to the native IGP SPF but also other applications that run on top of it and rely for topology and flooding info - mainly TE. When the link (or even a node) is going to be brought down for graceful shutdown/maintenance then I don't see how it is still going to be OK for TE to use it. In any case, perhaps SHOULD is a strong enough statement but IMHO MUST would be more appropriate.


s/ MAX-TE-METRIC (0xfffffffe).//

s/ The TE metric SHOULD be set / The TE metric of the link SHOULD be set <Shraddha>ack

s/ link and set the metric to MaxLinkMetric / link and set its metric to MaxLinkMetric <Shraddha> ack

s/ The TE metric SHOULD be set to MAX-TE-METRIC (0xfffffffe) and the TE opaque LSA for the link SHOULD be re-originated with new value./ Similarly, when TE is enabled, the remote node MUST set the TE metric for the link to MAX-TE-METRIC (0xfffffffe) and MUST re-originate the TE Link Opaque LSA for the link with new value.
<Shraddha> ack except the MUST.

A couple of sentences describing the different LSAs that come into play for OSPFv3 would be helpful in this section as well. Just as done in sec 3. The thing is that the OSPFv3 LSAs and especially it's equivalent TE LSAs are different. In fact RFC5329 is not being referred to as NORMATIVE and so does that imply we don't want to do similar action with TE metric in case of OSPFv3?. So it would be good to specify or clarify that part. Perhaps in general at start of sec 5 so the text in the rest of sub-sections are link-type specifics and generic to OSPF without naming any LSAs there?

<Shraddha> refered RFC 5329 in section 5

Sec 5.4 Unnumbered interfaces
IMHO this text is very similar to Sec 4.7 which talks about how to identify parallel links. Perhaps sec 5.4 should become Sec 4.8 since what is does is explain how the correlation of links is done for unnumbered links. Alternately, this explanation can be put under Sec 4.3 where the Local/Remote ID TLV is specified since this mechanism is going to be common for other use-case of this general purpose TLV.
<Shraddha> I think this section is needed as the previous section on Remote IPv4 address does not talk about unnumbered interfaces
[KT] Agree that the text is definitely needed and I was only suggesting that it might be better placed as sec 4.8 or embedded in 4.3. This is perhaps more of an editorial nit than substance so I leave it to you.

Thanks,
Ketan

-----Original Message-----
From: OSPF [mailto:[e-mail]] On Behalf Of Shraddha Hegde
Sent: 25 January 2018 11:01
To: Alvaro Retana <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

Alvaro,

Thanks for the review and comments.
Pls see inline..

Rgds
Shraddha

-----Original Message-----
From: Alvaro Retana [mailto:[e-mail]]
Sent: Wednesday, January 24, 2018 11:27 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; Acee Lindem <[e-mail]>; [e-mail]; [e-mail]
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
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ospf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=XBYEEARnw7lDAsfkNEsBkAkyVwYGvQ-2jj6E-wcs7TM&s=PPl7yuaLBDWiLIXIYDjuIwUa4QpdQ7_8aa7hVGcds6A&e=