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

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 2 Aug 2021 13:47:01 +0000

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

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

Be well,
G/

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Friday, July 23, 2021 7:33 PM
To: [email-masked]
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:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, July 9, 2021 4:36 PM
To: [email-masked]<mailto:[email-masked]>
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:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, July 9, 2021 4:29 PM
To: [email-masked]<mailto:[email-masked]>
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