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:aretana.i...@gmail.com] Sent: Thursday, January 25, 2018 9:54 PM To: Shraddha Hegde <shrad...@juniper.net>; The IESG <i...@ietf.org> Cc: Acee Lindem <a...@cisco.com>; draft-ietf-ospf-link-overl...@ietf.org; ospf-cha...@ietf.org; ospf@ietf.org 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 (shrad...@juniper.net<mailto:shrad...@juniper.net>) 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.
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
