Re: [Idr] 2 Week WG LC on draft-ietf-idr-rfc7752bis (7/9/2021 to 7/25/2021) - Exended to 7/31/2021

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

Hi Gunter,

Thanks for your review and my apologies for the late response on your email below.

Please check inline below.

From: Van De Velde, Gunter (Nokia - BE/Antwerp) <[e-mail]>
Sent: 02 August 2021 19:17
To: Susan Hares <[e-mail]>; Ketan Talaulikar (ketant) <[e-mail]>
Cc: [e-mail]
Subject: RE: [Idr] 2 Week WG LC on draft-ietf-idr-rfc7752bis (7/9/2021 to 7/25/2021) - Exended to 7/31/2021

[Appologies with this overdue response due to vacation catchups]

This draft is good work and is in good shape to improve the original RFC7752.

Two comments on draft RFC772bis:

Item#1: Chapter 4.2.3.1 OSPF Route Type:
It is specified that this TLV is mandatory. It used to be optional.
But RFC7684 chapter 2.1. specifies that the Route-Type can be unspecified ? How can you convey this info via BGP-LS then?
[KT] You are correct that OSPF Route Type cannot be mandatory for the scenario that you've listed. I will update the text to make it a SHOULD where it is possible to determine the route type and it can be skipped in other situations where this is not possible.

Also what about a Prefix NLRI with a Range TLV (https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-18 chapter 2.3.5<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-18%20chapter%202.3.5>). I think the OSPF Route-Type has no meaning here ?
[KT] It does have a meaning since it indicates the nature of the SRMS advertisement - intra, inter (leaked by ABR into another area) or AS-scoped flooding that may be useful.

Item#2: I am not convinced chapter 4.9 should be part of RFC7752bis. Maybe this should be branched off into separate document addressing LSP sequence number problematics?
[KT] There is no proposal for bringing in LSP sequence numbering into BGP-LS that I am aware of.

We introduce in section 4.9 logic beyond the normalized encoding of the LSDB into BGP-LS to withdraw link-state objects if nodes become unreachable (I guess a fact discovered after doing SPF algorithm?). Would this not cause risk that different BGP-LS originating routers in the IGP area/level advertise different LSDB link-state objects and hence represent different normalized encoded topologies? How would this work in situations where for we have IGP SRv6 TLV extensions in the LSDB? (locators are linked to algorithms and the flex-algo topologies piggybacked upon pruning links from the physical topology? I am not sure what the impact would be due to section 4.9 on the normalized encoding of the SRv6/flex-algo extensions)
[KT] The objective here is to not determine reachability in a specific algorithm or topology. The objective is to determine "base" IGP reachability that helps ensure that the LSA/LSP of that node in the local LSDB is reliable or not - this is same as what IGPs do today - don't use or refer to LSA/LSP information that is originated from a node that is not reachable since it could be stale/wrong.

Thanks,
Ketan

Be well,
G/





From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: Friday, July 23, 2021 7:33 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-rfc7752bis (7/9/2021 to 7/25/2021) - Exended to 7/31/2021

We have not received enough responses
The WG LC for RFC7752bis.  The WG LC is extended to 7/31/2021.

Cheers, Sue

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Friday, July 9, 2021 4:36 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-rfc7752bis (7/9/2021 to 7/25/2021)

3 implementations exist that are aligned to the RFC7752bis:

See the implementation report at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20

Sue

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Friday, July 9, 2021 4:29 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Idr] 2 Week WG LC on draft-ietf-idr-rfc7752bis (7/9/2021 to 7/25/2021)

This begins a 2 week WG LC on draft-ietf-idr-rfc7752bis-07.txt.
(https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/)

This draft is a revision of the RFC7752 on the Distribution of Link-State and Traffic Engineering Information Using BGP (BGP-LS) based on experience over the last 12 years since the 2009 publication of the RFC.

There is a 3rd party IPR statement on this draft.
https://datatracker.ietf.org/ipr/3623/

In your comments, please consider:
1.  Is this draft ready for publication?
2. Does this represent the status of deployed implementations?
3. Are there any critical corrections to RFC7752 which have been left out?
4. What extensions should be left to future BGP-LS drafts?

This draft is being shepherded by all 3 IDR chairs.

Cheerily, Sue