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

From: Alvaro Retana <[email-masked]>
Date: Thu, 1 Feb 2018 14:17:18 -0800

On January 30, 2018 at 11:43:53 PM, Shraddha Hegde ([email-masked])
wrote:

...

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

That addresses the concern #2 above.  I still don’t see anywhere how the
receiver associates this (empty) TLV with the right link.

Alvaro.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Feb 2018 22:42:44 +0000

Hi Alvaro,

From: Alvaro Retana <[email-masked]>
Date: Thursday, February 1, 2018 at 5:17 PM
To: Shraddha Hegde <[email-masked]>, The IESG <[email-masked]>
Cc: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, OSPF WG List <[email-masked]>
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

On January 30, 2018 at 11:43:53 PM, Shraddha Hegde ([email-masked]<mailto:[email-masked]>) wrote:

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

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?

It is a  BGP-LS link attribute so the link is identified in the link identifiers in the corresponding NLRI. This wasn’t apparent until the IANA description was fixed.

Thanks,

Acee

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.

That addresses the concern #2 above.  I still don’t see anywhere how the receiver associates this (empty) TLV with the right link.

Alvaro.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Feb 2018 22:43:31 +0000

P.S. BGP-LS Link Attributes should not be confused with BGP attributes…
Thanks
Acee s

From: Acee Lindem <[email-masked]>
Date: Thursday, February 1, 2018 at 5:42 PM
To: Alvaro Retana <[email-masked]>, Shraddha Hegde <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, OSPF WG List <[email-masked]>
Subject: Re: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

Hi Alvaro,

...

(1)

Thanks,

Acee

(2)

Alvaro.