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

[Shraddha Hegde <[e-mail]>]

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:[e-mail]]
Sent: Thursday, January 25, 2018 9:54 PM
To: Shraddha Hegde <[e-mail]>; The IESG <[e-mail]>
Cc: Acee Lindem <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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 ([e-mail]<mailto:[e-mail]>) wrote:

Shraddha:

Hi!

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

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?

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

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