Re: [Idr] Growing BGP-LS Attribute

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

Hi Robert,

Please check inline below.

From: Robert Raszuk <[e-mail]>
Sent: 26 October 2018 21:41
To: Ketan Talaulikar (ketant) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Idr] Growing BGP-LS Attribute

Hi Ketan,

The discussion is not turning .. it has always been about questioning principle to use BGP where and when there are better alternatives.

And while I am not against code reuse (same code as BGP) I am highly against two things:

1. Using IGP and TE information propagation together with routing SAFIs in the same process - hence I proposed https://tools.ietf.org/html/draft-raszuk-mi-bgp-00 to at least short term allow to run BGP-LS on *completely* separate and isolated process

[KT] I agree with this and we need to converge on the isolation part. Fully support this.

2. Waisting IDR precious time which if I recall used to stand for Inter-Domain Routing WG and not for Inter-Domain Reporting WG to engage with never ending flood of defining encoding for all IGP and TE and SR and BFD etc... extensions. That's really sick. We only get 2h 3 times a year and it would be huge disservice to BGP to take that time for extending it with new TLVs.
[KT] IIRC there was a proposal to do these incremental IGP matching updates to BGP-LS in LSR and perhaps in the same drafts where the new capability is proposed in the IGPs. It would help get a lot of clarity and help progress the work better. Also reduce drafts ;-) … I would fully support it.

If you like create a new WG dedicated to manage SAFI 71 & 72 making sure it will run in fully separate process from other use reachability propagation use cases of real BGP.
[KT] You mean like BESS?

Thx,
R.

PS. And your comment that sending this to two or three controllers makes it multi-point and and that is "one of the key benefit leveraged from base BGP" is simply amazing :)
[KT] Let me clarify. This is not p2mp like BGP – absolutely no comparison and not in the same league ☺. I wanted to clarify that it is not p2p in most cases as it was made out to be. Also, consider when the provider has multiple ASes then propagation can happen across AS boundaries as well (the multi-domain example that Adrian mentioned) within the same SP domain. So IMO BGP-LS does leverage the BGP machinery and not just using it for p2p transport.

Thanks,
Ketan








On Fri, Oct 26, 2018 at 3:18 PM Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

I think the discussion is again turning from encoding (i.e. handling of growing BGP-LS attribute size) to questioning the role and use of BGP-LS.

I agree with what Adrian has stated (except the part about p2p – it can be used p2mp to feed multiple/redundant controllers and that is one of the key benefit leveraged from base BGP). There is damping at IGP but then also one that can be applied at BGP(-LS) level in the implementations that I know. We could document guidelines for use and applicability.

However, coming to the topic of the BGP-LS attribute. We do need to consider

a)      The 4K limit and therefore perhaps enabling a BGP-LS NLRI to be split across multiple update messages. Similar to how we have LSP fragments in ISIS or multiple instances of the LSA (e.g. RI LSA) in OSPF. This would also enable splitting of information across updates and perhaps segregate information into static or dynamic or based on application.

b)     Another aspect not documented/discussed is filtering out of Attribute TLVs that are not of interest.

Thanks,
Ketan

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: 26 October 2018 20:36
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] Growing BGP-LS Attribute

Adrian,

Is all fine what you are describing. But tell us why it has to be BGP job ?

You already have efficient telemetry streaming out of the router. Why it can not be used as transport for all this information p2p between router and controller ?

Best
R.

On Fri, Oct 26, 2018, 09:59 Adrian Farrel <[e-mail]<mailto:[e-mail]>> wrote:
Sorry for the delay, Robert: travel.

>> IMHO, two fundamental concepts in BGP-LS are summarisation and stability.
>
> I don't see any summarization in the current encoding as most
> if not all of the information being sent is verbatim taken from
> IGP drafts and RFCs.

Encoding does not (and should not) reflect summarization.
Summarization is the process of taking n components and representing them as m (<n) components by;
- omitting
- aggregating
- virtualizing

The summarized things look like links. Some may really be IGP links reported straight through; some might be virtual links. In both cases they use the same encoding: they are presented as links.

Of course, one could use BGP-LS to simply dump the full IGP database, and that is not summarization. I would argue to not use BGP-LS if that is the function you want to deliver.

> Stability is also not there as now we have a lot of dynamic data without
> any new advertise-time thresholds being set - so we are just relying on
> IGP flooding thresholds.

If summarization is in use, then a small change to the IGP database might cause no change to the summarized information.
Furthermore, the summarization algorithm should (IMHO) be damped with some form of thresholding.
And even if you use BGP-LS to simply dump the full IGP database (against my advice :-), you can apply damping.

Most of the use cases I am aware of use BGP-LS to extract a summary of the IGP information for TE purposes. TE is usually a damped process, and operates on summarized information.

Possibly, another use case is "cross-domain reachability". That is also a form of summarization, and is relatively stable in the face of intra-network changes.

In short, there is no strong binding between the IGP and BGP-LS: neither temporal, nor informational. The use of a common encoding does not imply simultaneous or identical data.

BGP-LS is a protocol spec. We could make a good case that there should be more documentation of how/when to use the protocol, but since it is a p2p protocol, I don't think that material belongs in the protocol spec. With this in mind, I helped to write RFC 7926 for a specific TE scenario, and draft-ietf-bess-datacenter-gateway for a reachability/TE use case.

> BGP-LS has just one fundamental convenience - free TCP transport.
> That's it. If our link state protocols would run over TCP from any node
> to controller (well Henk & Gunter  just proposed it for ISIS) or if there
> would be a BMP analogy to IGPs (get full or filtered feed of LSDB or TED
> over TCP) there would be very limited need for BGP-LS.
>
> So today we are just growing single BGP-LS Attribute. Such attribute
> content changes depending if it is part of Node NLRI, Link NLRI or
> Prefix NLRI. Say take LInk NLRI there are TLVs which are static and
> which are dynamic - well there is no way to only send dynamic when
> they change as in BGP subsequent update with the same NLRI is an
> implicit withdraw of the former. So you are forced to repeat everything
> for given link NLRI regardless if even single value changes. You call this
> a "summarization" ?

No, that's not what I call a summarization as I hope I made clear.

> Further imagine controller and operator only needs 10% of the
> information for his specific application. Well hard luck as there is
> no way in general in BGP to ask for a subset of the attribute
> content. Neither RTC nor ORF would be of any use.
>
> What is needed here is an efficient and reliable pub-sub message
> transport - not just load of BGP TCP because it is there. And this
> all applies to trusted or untrusted or hybrid domain types :).

Adrian