Subject: Re: [Idr] Section 4.7 of RFC#7752 bis

From: Balaji Rajagopalan <[email-masked]>
Date: Tue, 5 Nov 2019 08:32:33 +0000

Hi Ketan,

[Continuing the discussion that started during last call, but changed the subject, since last call has ended]

Thanks for your consideration.

If deployment experience has pointed to the necessity for more textual clarity on issues arising from lack of flooding, I agree with you that additional text would be helpful.

BTW, I’m not calling for rendering the proposed solution illegitimate. Rather, I was suggesting that the solution was legitimate even with RFC#7752. IOW, RFC#7752 already supports a wide range of behaviours of the originator, including the proposed solution.

Likewise, I’m also not aware of anything that would render illegal the use of ADD-PATH, regardless of inclusion or omission of the proposed solution.

Thus, both the solutions were legal with RFC#7752, and would remain so even with the proposed text.

What the proposed text DOES change is that it now makes it mandatory for the originator to withdraw links from unreachable nodes. I  still disagree with the mandatory aspect of the proposed solution.

While there may be consumers that benefit from the proposed behaviour of the originator, the originator cannot assume that no consumer application would be interested in the entries that it’s going to drop. I can imagine applications, such as visualization tools or cross-consistency topology checkers, that might want to receive these entries. These applications were realizable in RFC#7752, but the restrictive behaviour of the proposed solution makes it impossible for a consumer to know exactly what an originator is holding, even if it’s prepared to deal with dead nodes, or does not care about such situations.

IOW, the proposed text mandates a solution that was already legal as per RFC#7752, but forecloses formerly legal behaviours that might be useful. I don’t see any strong reason to presume the uselessness of the dropped entries, when the alternative of making it optional supports both behaviours.

So, my suggestion would be the following:

  *   Clearly describe the problem, as the current draft does
  *   Describe both the solutions (ADD-PATH & the current text), and make them both optional behaviours available to an originator

Such an approach would provide textual clarity on the tools available to solve the problem, without foreclosing behaviours that may be useful.

--
Balaji Rajagopalan

Hi Balaji,

Thanks for your review and your comments in improving this document.

The fact that apart from a few folks who have been involved in the development and deployment of BGP-LS, this problem was not evident to most people (until they actually hit those issues) warrants the inclusion of the text in the bis draft. I don’t  think the text you propose describes this problem scenario and it’s solution.

During the IETF at Montreal we spent a lot of time on this aspect and even presented the two options for handling the problem identified in this section. There was a lot of support for keeping things simple as described in the current version of the bis draft.

That said, we can poll again on the WG alias post adoption to take further inputs/suggestions from members on this aspect.

Thanks,
Ketan

From: Balaji Rajagopalan <[email-masked]>
Date: Monday, 19 August 2019 at 10:32 PM
To: 'Susan Hares' <[email-masked]>
Cc: 'idr wg' <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

Hi Sue & Authors,

As an implementor of RFC 7752, I support adoption of this draft as a WG document.

I have a comment on section 4.7, though.

Section 4.7 mandates withdrawal of link-state objects advertised by unreachable nodes. I’d suggest making this an optional behaviour of the originator. Originator not presuming consumer’s disinterest in certain entries would permit a wider range of applications.

If there is agreement that section 4.7 can be optional:

I don’t believe that the contents of section 4.7 merit a dedicated section. The last paragraph of section 1, reproduced below, offers plenty of leeway for an originator to choose what gets advertised. If this text is thought to be inadequate, an additional line or two in section 1 would suffice, IMHO.

“
A BGP speaker may apply configurable policy to the information that
   it distributes.  Thus, it may distribute the real physical topology
   from the LSDB or the TED.  Alternatively, it may create an abstracted
   topology, where virtual, aggregated nodes are connected by virtual
   paths.  Aggregated nodes can be created, for example, out of multiple
   routers in a Point of Presence (POP).  Abstracted topology can also
   be a mix of physical and virtual nodes and physical and virtual
   links.  Furthermore, the BGP speaker can apply policy to determine
   when information is updated to the consumer so that there is a
   reduction of information flow from the network to the consumers.
   Mechanisms through which topologies can be aggregated or virtualized
   are outside the scope of this document
“

--
Balaji Rajagopalan

From: Idr <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Organisation: Old Dog Consulting
Reply to: "[email-masked]" <[email-masked]>
Date: Friday, 16 August 2019 at 6:07 PM
To: 'Susan Hares' <[email-masked]>
Cc: 'idr wg' <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

Hi Sue,

I’m a co-author on this draft.

I agree that an update to 7752 is needed. Sort of regret that we didn’t get this right first time. On the other hand, turning the handle and getting an RFC out was the right thing to do 3.5 years ago, and revising our work is a good demonstration that it is implemented and relevant.

So yes, I support adoption and hope we can spend as long as it takes getting this polished.

Thanks,
Adrian

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: 08 August 2019 20:31
To: 'idr wg' <[email-masked]>
Subject: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

This begins a 2 week adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22/2019]

In your comments please indicate “support” or “no support”.

The chair and AD feel that a revision to RFC7752 is needed
to specify additional error handling.  Please consider
if this draft is a good place to start for this revision.

Cheerily, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 8 Nov 2019 10:55:15 +0000

Hi Balaji,

Please check inline below.

From: Balaji Rajagopalan <[email-masked]>
Sent: 05 November 2019 14:03
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: 'idr wg' <[email-masked]>
Subject: Re: Section 4.7 of RFC#7752 bis

Hi Ketan,

What the proposed text DOES change is that it now makes it mandatory for the originator to withdraw links from unreachable nodes. I  still disagree with the mandatory aspect of the proposed solution.
[KT] I believe we can change the MUST to SHOULD here since as you mention below, there may be use-cases where this mechanism would not be preferred.

  *   Clearly describe the problem, as the current draft does
  *   Describe both the solutions (ADD-PATH & the current text), and make them both optional behaviours available to an originator
[KT] Could you propose the text to describe the ADD-PATH solution? We can get the WG feedback for its inclusion as another alternative in the document.

Thanks,
Ketan

--
Balaji Rajagopalan

Hi Balaji,

Thanks,
Ketan

From: Balaji Rajagopalan <[email-masked]<mailto:[email-masked]>>
Date: Monday, 19 August 2019 at 10:32 PM
To: 'Susan Hares' <[email-masked]<mailto:[email-masked]>>
Cc: 'idr wg' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

Hi Sue & Authors,

“

--
Balaji Rajagopalan

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Organisation: Old Dog Consulting
Reply to: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, 16 August 2019 at 6:07 PM
To: 'Susan Hares' <[email-masked]<mailto:[email-masked]>>
Cc: 'idr wg' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

Hi Sue,

Thanks,
Adrian

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: 08 August 2019 20:31
To: 'idr wg' <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

Cheerily, Susan Hares

---

From: Balaji Rajagopalan <[email-masked]>
Date: Fri, 15 Nov 2019 03:57:30 +0000

Hi Ketan,

>>Clearly describe the problem, as the current draft does
>>Describe both the solutions (ADD-PATH & the current text), and make them both optional behaviours available to an originator

Please see below suggested replacement text for the last paragraph of section 4.7. Please feel free to massage the text.

A BGP-LS Producer has two ways to cope with the above problem:

  *   Do not advertise the links of unreachable nodes
  *   Advertise the links from both the partitions using ADD-PATH, so the consumer has enough information to identify the stale entries.

--
Balaji Rajagopalan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 15 Nov 2019 05:58:28 +0000

Hi Balaji,

I have personally no issue changing the MUST to SHOULD in the following text so that using the solution you propose for the very specific use-case that you have in mind is possible without being non-compliant to the specification.

   A BGP-LS Producer MUST withdraw all link-state objects advertised by
   it in BGP when the node that originated its corresponding LSP/LSAs is
   determined to have become unreachable in the IGP and it MUST re-
   advertise those link-state objects only after that node becomes
   reachable again in the IGP domain.

Would that completely address your concerns?

However, if you also wish to add this other option then we ought to at least explain that mechanism properly to enable review by the WG. When you say “advertise the links from both the partitions using ADD-PATH”, it is not really intuitive for reader of the document to understand this and its implications in the BGP-LS context.

In Montreal, I put together some slides<https://datatracker.ietf.org/meeting/105/materials/slides-105-idr-sessa-draft-ketant-idr-rfc7752bis-01> with your help to try and explain your proposal (solution B) and still it was difficult for many experts in the room to understand the need and motivation for it – the minutes<https://datatracker.ietf.org/meeting/105/materials/minutes-105-idr-01.htm> and the recording<https://www.youtube.com/watch?v=7tgD-hPPIhI> are available to refresh our collective memory.

In full disclosure, I personally find your proposed solution B very complex with little or no benefit – even though, IIRC, I did not express that opinion during the session in order to not influence. I do agree though that you should have the flexibility to implement your solution for the use-cases you have in mind while the draft tries to capture the simpler and consensus solution for most of the broad use-cases.

So if you wish to still put forward your alternate mechanism, then please provide a good text that enables review by the WG. However, if you are happy with just the above text change that I’ve proposed then we are good and this can be posted in the next update for the draft.

Thanks,
Ketan

Sent: 15 November 2019 09:28

Hi Ketan,

--
Balaji Rajagopalan

---

From: Balaji Rajagopalan <[email-masked]>
Date: Wed, 27 Nov 2019 09:00:45 +0000

Hi Ketan,

Sorry for the delayed response.

Yes, I’m okay with a ‘SHOULD’ in place of ‘MUST’. I had a brief chat with John Scudder, and he reminded me that a ‘SHOULD’ condition must be accompanied by text that clearly explains under what conditions an implementation is not required to follow the ‘SHOULD’ condition.

John & I came up with the following amended text for review:

There are two strategies that can be used to solve the above problem: producer-controlled & consumer-controlled.

  1.  A BGP-LS Producer SHOULD withdraw all link-state objects advertised by it in BGP when the node that originated its corresponding LSP/LSAs is determined to have become unreachable in the IGP, unless the Consumer is interested in receiving all the entries. If the Producer does so, it MUST re-advertise those link-state objects only after that node becomes reachable again in the IGP domain.
  2.  A BGP-LS Consumer MAY filter stale entries of unreachable nodes by treating each Producer’s view of the topology as a separate partition. In order to perform this step, the consumer needs to have visibility into each Producer’s entries.

When Route Reflector (RR) is in use, as depicted in the diagram, the route selection procedure in the RR may conceal all but one entry.  This is similar to other issues that  arise when route reflection is used, and the other well-known solutions to  such problems MAY be applied instead of option-1. The route reflector can refrain from hiding data, by using add-path [ref] to advertise all the routes. The consumer would have to use ‘Originator ID’ attribute to identify the Producer.

Another option is to operationally refrain from  using route reflection for this application: if the consumer in the above example peered directly with R2 and R3, the consumer would have full access to each partition’s view.

--
Balaji Rajagopalan

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Friday, 15 November 2019 at 11:28 AM
To: Balaji Rajagopalan <[email-masked]>
Cc: 'idr wg' <[email-masked]>
Subject: RE: Section 4.7 of RFC#7752 bis

Hi Balaji,

In Montreal, I put together some slides<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/105/materials/slides-105-idr-sessa-draft-ketant-idr-rfc7752bis-01__;!8WoA6RjC81c!Rxubt6nAMCIrzyBGtaPm7pq6fSdGiKyGY8o6Tr99-My6SdHIZyvv7Fwa1G29-ov9$> with your help to try and explain your proposal (solution B) and still it was difficult for many experts in the room to understand the need and motivation for it – the minutes<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/105/materials/minutes-105-idr-01.htm__;!8WoA6RjC81c!Rxubt6nAMCIrzyBGtaPm7pq6fSdGiKyGY8o6Tr99-My6SdHIZyvv7Fwa1ERc30cG$> and the recording<https://urldefense.com/v3/__https:/www.youtube.com/watch?v=7tgD-hPPIhI__;!8WoA6RjC81c!Rxubt6nAMCIrzyBGtaPm7pq6fSdGiKyGY8o6Tr99-My6SdHIZyvv7Fwa1B2kSs6p$> are available to refresh our collective memory.

Thanks,
Ketan

Hi Ketan,

--
Balaji Rajagopalan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 29 Nov 2019 05:43:44 +0000

Hi Balaji,

Sent: 27 November 2019 14:31

Hi Ketan,

[KT] Agree.

  1.  A BGP-LS Producer SHOULD withdraw all link-state objects advertised by it in BGP when the node that originated its corresponding LSP/LSAs is determined to have become unreachable in the IGP, unless the Consumer is interested in receiving all the entries. If the Producer does so, it MUST re-advertise those link-state objects only after that node becomes reachable again in the IGP domain.
[KT] We can wordsmith this but I agree.

  1.  A BGP-LS Consumer MAY filter stale entries of unreachable nodes by treating each Producer’s view of the topology as a separate partition.
[KT] This is not sufficient and actually the consumer would have to run SPT computation using each Producer’s view to determine the nodes that are unreachable in its view? If your implementation is actually doing this, then it helps if you could clarify.
In order to perform this step, the consumer needs to have visibility into each Producer’s entries.

When Route Reflector (RR) is in use, as depicted in the diagram, the route selection procedure in the RR may conceal all but one entry.  This is similar to other issues that  arise when route reflection is used, and the other well-known solutions to  such problems MAY be applied instead of option-1.
[KT] Could you please clarify what “other well-known solutions” are being referred to apart from add-path here? If the solution is add-path then I would skip the above sentence or merge it with the next one.
The route reflector can refrain from hiding data, by using add-path [ref] to advertise all the routes. The consumer would have to use ‘Originator ID’ attribute to identify the Producer.

Another option is to operationally refrain from  using route reflection for this application: if the consumer in the above example peered directly with R2 and R3, the consumer would have full access to each partition’s view.
[KT] We can wordsmith this but I think it makes sense to have this as an option for the 2nd approach.

Thanks,
Ketan

--
Balaji Rajagopalan

From: "Ketan Talaulikar (ketant)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, 15 November 2019 at 11:28 AM
To: Balaji Rajagopalan <[email-masked]<mailto:[email-masked]>>
Cc: 'idr wg' <[email-masked]<mailto:[email-masked]>>
Subject: RE: Section 4.7 of RFC#7752 bis

Hi Balaji,

Thanks,
Ketan

To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>

Hi Ketan,

--
Balaji Rajagopalan