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

From: Alvaro Retana <[email-masked]>
Date: Wed, 24 Jan 2018 09:56:35 -0800

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/

----------------------------------------------------------------------
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.

(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.

(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!

(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?

(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).

(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?

(7) s/MAX_METRIC/MaxLinkMetric

[1] https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 25 Jan 2018 05:31:11 +0000

Alvaro,

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

Rgds
Shraddha

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]] 
Sent: Wednesday, January 24, 2018 11:27 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Acee Lindem <[email-masked]>; [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

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=

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.

<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=

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 25 Jan 2018 08:28:18 +0000

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.

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?

https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml 

Suggest making the section describing Maximum TE Metric before the current Sec 5 - Elements of procedure so the flow is better for the reader.

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."

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

s/ The TE metric SHOULD be set / The TE metric of the link SHOULD be set

s/ link and set the metric to MaxLinkMetric / link and set its metric to MaxLinkMetric

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.

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?

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.

Thanks,
Ketan

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

Alvaro,

Rgds
Shraddha

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]]
Sent: Wednesday, January 24, 2018 11:27 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Acee Lindem <[email-masked]>; [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

(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?

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 25 Jan 2018 11:23:57 -0500

On January 25, 2018 at 12:31:16 AM, Shraddha Hegde ([email-masked])
wrote:

Shraddha:

Hi!

...

<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?

Maybe it’s just me and I just don’t understand…which is completely
possible.  There are two points:

(1)

It looks like you’re defining a new Graceful-Link-Shutdown TLV for BGP-LS.
This TLV (based on the updated description) has no information in it.  How
does the receiver know which link the sender is referring to?

Note that for the OSPF graceful-link-shutdown sub-TLVs, you are indicating
where to carry them so that there is an obvious indication of which link is
being shutdown.  I would like to see explicitly specified how the receiver
associates this TLV with the appropriate link.  Again, I may be missing the
details.

(2)

The value for the TLV was reserved by IANA in the "BGP-LS NLRI-Types"
registry, not in the "BGP-LS Node Descriptor, Link Descriptor, Prefix
Descriptor, and Attribute TLVs” register, which is where I would have
assumed a modifier to the link would reside.  IOW, according to the
registry you are defining a new NLRI Type, not a new TLV — and, according
to the updated description in the document there’s no information in this
NLRI.

...

(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.

I think that the use of TE is obvious at the point of setting the metric —
IOW, if TE is not used then it doesn’t mater what this document says.  But
if TE is used, then having a MUST makes it clear that MAX-TE-METRIC is the
metric to be used and that there are no other values or circumstances where
a different value should be considered.

Alvaro.

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 31 Jan 2018 03:44:31 +0000

Ketan,

Thanks for comments.
Pls see inline...

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

Hi Shraddha,

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.

<Shraddha>ack

<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.

<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

Thanks,
Ketan

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

Alvaro,

Rgds
Shraddha

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]]
Sent: Wednesday, January 24, 2018 11:27 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Acee Lindem <[email-masked]>; [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

_______________________________________________
OSPF mailing list
[email-masked]
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=

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 31 Jan 2018 04:43:48 +0000

Alvaro,

You are right. The registration happened in the incorrect registry.
I have corrected the problem in -15 version.
Pls see inline.

From: Alvaro Retana [mailto:[email-masked]]
Sent: Thursday, January 25, 2018 9:54 PM
To: Shraddha Hegde <[email-masked]>; The IESG <[email-masked]>
Cc: Acee Lindem <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

On January 25, 2018 at 12:31:16 AM, Shraddha Hegde ([email-masked]<mailto:[email-masked]>) wrote:

Shraddha:

Hi!

...

Maybe it’s just me and I just don’t understand…which is completely possible.  There are two points:

(1)

It looks like you’re defining a new Graceful-Link-Shutdown TLV for BGP-LS.  This TLV (based on the updated description) has no information in it.  How does the receiver know which link the sender is referring to?

Note that for the OSPF graceful-link-shutdown sub-TLVs, you are indicating where to carry them so that there is an obvious indication of which link is being shutdown.  I would like to see explicitly specified how the receiver associates this TLV with the appropriate link.  Again, I may be missing the details.

(2)

The value for the TLV was reserved by IANA in the "BGP-LS NLRI-Types" registry, not in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs” register, which is where I would have assumed a modifier to the link would reside.  IOW, according to the registry you are defining a new NLRI Type, not a new TLV — and, according to the updated description in the document there’s no information in this NLRI.

<Shraddha> The TLV code point registration should be in “BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs” I have corrected this in the document.

Will e-mail to IANA for correction as well.

Does that answer your concerns?

...

I think that the use of TE is obvious at the point of setting the metric — IOW, if TE is not used then it doesn’t mater what this document says.  But if TE is used, then having a MUST makes it clear that MAX-TE-METRIC is the metric to be used and that there are no other values or circumstances where a different value should be considered.

<Shraddha> Mandating TE metric change with a MUST makes it less flexible.

There would not be an option of following this draft for some applications and not following for TE applications. I think that keeping it SHOULD provides that flexibility.

Alvaro.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 31 Jan 2018 04:50:52 +0000

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:[email-masked]] 
Sent: 31 January 2018 09:15
To: Ketan Talaulikar (ketant) <[email-masked]>; Alvaro Retana <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Thursday, January 25, 2018 1:58 PM
To: Shraddha Hegde <[email-masked]>; Alvaro Retana <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

Hi Shraddha,

Related to BGP-LS TLV:

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/ 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

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:[email-masked]] On Behalf Of Shraddha Hegde
Sent: 25 January 2018 11:01
To: Alvaro Retana <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

Alvaro,

Rgds
Shraddha