Subject: [Idr] Growing BGP-LS Attribute

From: Robert Raszuk <[email-masked]>
Date: Sat, 20 Oct 2018 14:10:22 +0200

Hi Ketan,

So today I see bunch of new proposals requesting addition of number of new
TLVs to BGP-LS Attribute.

Some of them will go into attribute along with Node NLRI and some with Link
NLRI.

I think by all means this is the largest single BGP attribute we ever had
and it seems growing daily like a balloon. Most of the TLVs which are
defined contain sub-TLVs which can be filled with data in a non limited by
any spec fashion.

Just few questions:

* What happens when someone injects more then 4K of data into this
attribute today ? What prevents one from doing so ?

* Is attribute discard an acceptable thing for someone who counts of that
information operationally simple due to a bug in a new TLV ?

* So far error handling proposal stopped at the attribute boundary as most
BGP attributes are small, precisely addressing the problem they were
invented to solve. Here we are facing a completely different situation ..

* Is it acceptable to loose all other address family information if BGP-LS
Attribute error or its size impacts the propagation to the extend of
bringing down the session ?

* What is the limiting factor of the BGP-LS churn (due to the nature of
some carried data being quite dynamic) to other address families present
either on sender, receiver or route reflector ?

Below is the current IANA registry with BGP-LS TLV space ... note that it
does not even list sub-TLVs which most if not each of the TLV defines. Do
we really want to grow this single BGP Attribute even more ?

Thx,
R

TLV Code Point Description IS-IS TLV/Sub-TLV Reference
0-255 Reserved [RFC7752 <http://www.iana.org/go/rfc7752>]
256 Local Node Descriptors [RFC7752, Section 3.2.1.2
<http://www.iana.org/go/rfc7752>]
257 Remote Node Descriptors [RFC7752, Section 3.2.1.3
<http://www.iana.org/go/rfc7752>]
258 Link Local/Remote Identifiers 22/4 [RFC5307, Section 1.1
<http://www.iana.org/go/rfc5307>]
259 IPv4 interface address 22/6 [RFC5305, Section 3.2
<http://www.iana.org/go/rfc5305>]
260 IPv4 neighbor address 22/8 [RFC5305, Section 3.3
<http://www.iana.org/go/rfc5305>]
261 IPv6 interface address 22/12 [RFC6119, Section 4.2
<http://www.iana.org/go/rfc6119>]
262 IPv6 neighbor address 22/13 [RFC6119, Section 4.3
<http://www.iana.org/go/rfc6119>]
263 Multi-Topology ID [RFC7752, Section 3.2.1.5
<http://www.iana.org/go/rfc7752>]
264 OSPF Route Type [RFC7752, Section 3.2.3 <http://www.iana.org/go/rfc7752>
]
265 IP Reachability Information [RFC7752, Section 3.2.3
<http://www.iana.org/go/rfc7752>]
266 Node MSD (TEMPORARY - registered 2017-11-02, extension registered
2018-09-07, expires 2019-11-02) 242/23 [
draft-ietf-idr-bgp-ls-segment-routing-msd
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-msd>]
267 Link MSD (TEMPORARY - registered 2017-11-02, extension registered
2018-09-07, expires 2019-11-02) (22,23,25,141,222,223)/15 [
draft-ietf-idr-bgp-ls-segment-routing-msd
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-msd>]
268-511 Unassigned
512 Autonomous System [RFC7752, Section 3.2.1.4
<http://www.iana.org/go/rfc7752>]
513 BGP-LS Identifier [RFC7752, Section 3.2.1.4
<http://www.iana.org/go/rfc7752>]
514 OSPF Area-ID [RFC7752, Section 3.2.1.4 <http://www.iana.org/go/rfc7752>]
515 IGP Router-ID [RFC7752, Section 3.2.1.4 <http://www.iana.org/go/rfc7752>
]
516 BGP Router-ID [draft-ietf-idr-bgpls-segment-routing-epe
<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]
517 BGP Confederation Member [draft-ietf-idr-bgpls-segment-routing-epe
<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]
518-1023 Unassigned
1024 Node Flag Bits [RFC7752, Section 3.3.1.1
<http://www.iana.org/go/rfc7752>]
1025 Opaque Node Attribute [RFC7752, Section 3.3.1.5
<http://www.iana.org/go/rfc7752>]
1026 Node Name variable [RFC7752, Section 3.3.1.3
<http://www.iana.org/go/rfc7752>]
1027 IS-IS Area Identifier variable [RFC7752, Section 3.3.1.2
<http://www.iana.org/go/rfc7752>]
1028 IPv4 Router-ID of Local Node 134/--- [RFC5305, Section 4.3
<http://www.iana.org/go/rfc5305>]
1029 IPv6 Router-ID of Local Node 140/--- [RFC6119, Section 4.1
<http://www.iana.org/go/rfc6119>]
1030 IPv4 Router-ID of Remote Node 134/--- [RFC5305, Section 4.3
<http://www.iana.org/go/rfc5305>]
1031 IPv6 Router-ID of Remote Node 140/--- [RFC6119, Section 4.1
<http://www.iana.org/go/rfc6119>]
1032-1033 Unassigned
1034 SR Capabilities [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1035 SR Algorithm [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1036 SR Local Block [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1037 SRMS Preference [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1038-1087 Unassigned
1088 Administrative group (color) 22/3 [RFC5305, Section 3.1
<http://www.iana.org/go/rfc5305>]
1089 Maximum link bandwidth 22/9 [RFC5305, Section 3.4
<http://www.iana.org/go/rfc5305>]
1090 Max. reservable link bandwidth 22/10 [RFC5305, Section 3.5
<http://www.iana.org/go/rfc5305>]
1091 Unreserved bandwidth 22/11 [RFC5305, Section 3.6
<http://www.iana.org/go/rfc5305>]
1092 TE Default Metric 22/18 [RFC7752, Section 3.3.2.3
<http://www.iana.org/go/rfc7752>]
1093 Link Protection Type 22/20 [RFC5307, Section 1.2
<http://www.iana.org/go/rfc5307>]
1094 MPLS Protocol Mask [RFC7752, Section 3.3.2.2
<http://www.iana.org/go/rfc7752>]
1095 IGP Metric [RFC7752, Section 3.3.2.4 <http://www.iana.org/go/rfc7752>]
1096 Shared Risk Link Group [RFC7752, Section 3.3.2.5
<http://www.iana.org/go/rfc7752>]
1097 Opaque Link Attribute [RFC7752, Section 3.3.2.6
<http://www.iana.org/go/rfc7752>]
1098 Link Name [RFC7752, Section 3.3.2.7 <http://www.iana.org/go/rfc7752>]
1099 Adjacency Segment Identifier (Adj-SID) TLV [
draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1100 LAN Adjacency Segment Identifier (Adj-SID) TLV [
draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1101 Peer-Node-SID [draft-ietf-idr-bgpls-segment-routing-epe
<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]
1102 Peer-Adj-SID [draft-ietf-idr-bgpls-segment-routing-epe
<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]
1103 Peer-Set-SID [draft-ietf-idr-bgpls-segment-routing-epe
<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]
1104 Unassigned
1105 RTM Capability 22/40 [RFC8169 <http://www.iana.org/go/rfc8169>]
1106-1113 Unassigned
1114 Unidirectional Link Delay (TEMPORARY - registered 2017-08-18,
extension registered 2018-07-20, expires 2019-08-18) [
draft-ietf-idr-te-pm-bgp <http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]
1115 Min/Max Unidirectional Link Delay (TEMPORARY - registered 2017-08-18,
extension registered 2018-07-20, expires 2019-08-18) [
draft-ietf-idr-te-pm-bgp <http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]
1116 Unidirectional Delay Variation (TEMPORARY - registered 2017-08-18,
extension registered 2018-07-20, expires 2019-08-18) [
draft-ietf-idr-te-pm-bgp <http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]
1117 Unidirectional Packet Loss (TEMPORARY - registered 2017-08-18,
extension registered 2018-07-20, expires 2019-08-18) [
draft-ietf-idr-te-pm-bgp <http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]
1118 Unidirectional Residual Bandwidth (TEMPORARY - registered 2017-08-18,
extension registered 2018-07-20, expires 2019-08-18) [
draft-ietf-idr-te-pm-bgp <http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]
1119 Unidirectional Available Bandwidth (TEMPORARY - registered 2017-08-18,
extension registered 2018-07-20, expires 2019-08-18) [
draft-ietf-idr-te-pm-bgp <http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]
1120 Unidirectional Bandwidth Utilization (TEMPORARY - registered
2017-08-18, extension registered 2018-07-20, expires 2019-08-18) [
draft-ietf-idr-te-pm-bgp <http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]
1121 Graceful-Link-Shutdown TLV [RFC8379 <http://www.iana.org/go/rfc8379>]
1122-1151 Unassigned
1152 IGP Flags [RFC7752, Section 3.3.3.1 <http://www.iana.org/go/rfc7752>]
1153 IGP Route Tag [RFC5130 <http://www.iana.org/go/rfc5130>]
1154 IGP Extended Route Tag [RFC5130 <http://www.iana.org/go/rfc5130>]
1155 Prefix Metric [RFC5305 <http://www.iana.org/go/rfc5305>]
1156 OSPF Forwarding Address [RFC2328 <http://www.iana.org/go/rfc2328>]
1157 Opaque Prefix Attribute [RFC7752, Section 3.3.3.6
<http://www.iana.org/go/rfc7752>]
1158 Prefix SID [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1159 Range [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1160 Unassigned
1161 SID/Label TLV [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1162-1169 Unassigned
1170 IGP Prefix Attributes [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1171 Source Router-ID [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1172 L2 Bundle Member TLV [draft-ietf-idr-bgp-ls-segment-routing-ext
<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]
1173 Extended Administrative Group (TEMPORARY - registered 2018-04-09,
expires 2019-04-09) 22/14 [draft-ietf-idr-eag-distribution
<http://www.iana.org/go/draft-ietf-idr-eag-distribution>][RFC7308
<http://www.iana.org/go/rfc7308>]
1174-65535 Unassigned

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 20 Oct 2018 18:17:27 +0100

Robert sed:

> Do we really want to grow this single BGP Attribute even more ?

Time to remind everyone about Yakov's Shakespeare-over-BGP?

IMHO, two fundamental concepts in BGP-LS are summarisation and stability. If someone wanted to have access to all of the IGP information and be updated every time anything changed, why would they not become a silent partner in the IGP? The thing BGP-LS should buy you is the fact that a BGP implementation is usually quite good at gathering and correlating routing information, and then applying policy to it.

OTOH, it may be that this argument^H^H^H debate was lost some time ago.

But maybe the thing here is for the WG to step back and decide what the point of BGP-LS is, how it should grow, and what controls should be in place.

A topic for the f2f meeting?

Best,
Adrian

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 20 Oct 2018 13:33:09 -0400

Adrian:

IDR will not be having a f2f meeting in IETF 103, but an interim discussion
on 10/26/2018 at 10-12 ET pm.  We will ask this question at the interim.
Please join us for that discussion. 

Cheerily, 
Susan Hares 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, October 20, 2018 1:17 PM
To: [email-masked]
Cc: 'Robert Raszuk'
Subject: Re: [Idr] Growing BGP-LS Attribute

IMHO, two fundamental concepts in BGP-LS are summarisation and stability. If
someone wanted to have access to all of the IGP information and be updated
every time anything changed, why would they not become a silent partner in
the IGP? The thing BGP-LS should buy you is the fact that a BGP
implementation is usually quite good at gathering and correlating routing
information, and then applying policy to it.

But maybe the thing here is for the WG to step back and decide what the
point of BGP-LS is, how it should grow, and what controls should be in
place.

Best,
Adrian

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 20 Oct 2018 19:36:26 +0200

Hi Adrian,

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

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.

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

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 :).

Cheers,
R.

On Sat, Oct 20, 2018 at 7:17 PM Adrian Farrel <[email-masked]> wrote:

> IMHO, two fundamental concepts in BGP-LS are summarisation and stability.
> If someone wanted to have access to all of the IGP information and be
> updated every time anything changed, why would they not become a silent
> partner in the IGP? The thing BGP-LS should buy you is the fact that a BGP

---

From: Randy Bush <[email-masked]>
Date: Sun, 21 Oct 2018 11:33:22 -0700

> I think by all means this is the largest single BGP attribute we ever
> had and it seems growing daily like a balloon. Most of the TLVs which
> are defined contain sub-TLVs which can be filled with data in a non
> limited by any spec fashion.

this is scary.  as adrian says, if you wanna monitor the igp, then do so
directly.  this bgp-ls thing is trying to funnel all of bgp and igps;
but to no clear end.  and, as igps and bgp keep expanding, bgp-ls will
only amplify the problem.  soon we will have bgp-ls doctors.

and i wonder why it does not also funnel dns. :)

randy

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 21 Oct 2018 21:45:12 +0200

> soon we will have bgp-ls doctors.

Honestly having to read through all of the recent bgp-ls proposals and
extensions there is so much confusion there on what goes to NLRI vs BGP-LS
Attribute, what is TLV and when nesting to sub-TLVs makes sense, why do we
send different BGP-LS Attribute depending to which NLRI it accompanies etc
.. that I think BGP-LS doctor(s) are needed not soon but yesterday. And
some of those documents are at the the WG-LC status too ...

Yes interestingly no one cares to touch on few other BGP aspects which may
come into play. Example: Should BGP-LS be eligible to be packed into BMP
(considering recent BMP extension proposals), how the dynamic IGP data be
of any use if some BGP still uses long MRAI timer for subsequent updates on
the same NLRI etc ...

> as adrian says, if you wanna monitor the igp, then do so directly.

Well as you know in practice this is not always an option - in fact this is
almost never an option in production network ... Controllers running on x86
boxes sit far from routers and are never allowed to connect to them
directly. So bringing IGP adjacency between router and such oracle is hard
... even assuming it would be just passive one. That's why TCP is so
attractive since as long as server is reachable the session will be formed
and bits transferred.

---

From: Randy Bush <[email-masked]>
Date: Sun, 21 Oct 2018 12:49:14 -0700

> Well as you know in practice this is not always an option - in fact
> this is almost never an option in production network

while i agree with "not always," i strongly disagree with "almost
never."  my experience is that it usually is an option.  in operation,
the weakness is good igp monitoring software; much suckage, especially
for is-is.

randy

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 22 Oct 2018 07:32:13 +0000

Hi Robert,

Please check inline for response.

From: Robert Raszuk <[email-masked]>
Sent: 20 October 2018 17:40
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]
Subject: Growing BGP-LS Attribute

Hi Ketan,

So today I see bunch of new proposals requesting addition of number of new TLVs to BGP-LS Attribute.

Some of them will go into attribute along with Node NLRI and some with Link NLRI.
[KT] I believe all of them (new proposals you reference above) are going into the BGP-LS Attribute and none into the NLRI descriptors.

I think by all means this is the largest single BGP attribute we ever had and it seems growing daily like a balloon. Most of the TLVs which are defined contain sub-TLVs which can be filled with data in a non limited by any spec fashion.

Just few questions:

* What happens when someone injects more then 4K of data into this attribute today ? What prevents one from doing so ?
[KT] This would result in a packing error for the BGP update message. I do see your point of this not being discussed in RFC7752.

* Is attribute discard an acceptable thing for someone who counts of that information operationally simple due to a bug in a new TLV ?
[KT] Per https://tools.ietf.org/html/rfc7752#section-6.2.2 a malformed TLV would result in Attribute discard. But an unrecognized TLV would not result in this. This could be clarified in base BGP-LS.

* So far error handling proposal stopped at the attribute boundary as most BGP attributes are small, precisely addressing the problem they were invented to solve. Here we are facing a completely different situation ..
[KT] Agree and the nature of semantic or syntactical validation for TLVs within the BGP-LS attribute does need to be specified in base BGP-LS spec.

* Is it acceptable to loose all other address family information if BGP-LS Attribute error or its size impacts the propagation to the extend of bringing down the session ?
[KT] This would indeed be the case if session isolation were not being used.

* What is the limiting factor of the BGP-LS churn (due to the nature of some carried data being quite dynamic) to other address families present either on sender, receiver or route reflector ?
[KT] Besides the need for session isolation, RFC7752 also talks about knobs for rate-limiting in https://tools.ietf.org/html/rfc7752#section-6.2.3. This would be in addition to whatever is present/available in say IGP to throttle churn at that protocol level.

Below is the current IANA registry with BGP-LS TLV space ... note that it does not even list sub-TLVs which most if not each of the TLV defines. Do we really want to grow this single BGP Attribute even more ?
[KT] Most TLVs do not have sub-TLVs but some do and for sure, as we extend BGP-LS we can expect sub-TLVs and nesting. We can discuss/debate whether introducing more BGP Attributes would help. Another option would be to discuss if we need to introduce the concept of splitting information across multiple NLRIs to advertise different “fragments” of say a node/link where by the corresponding state may not only grow beyond the 4K limit but also more likely may be used to segregate TLVs based on application and update frequency (or other such criteria).

Thanks,
Ketan

Thx,
R
TLV Code Point [https://www.iana.org/assignments/_support/sort_none.gif]

Description [https://www.iana.org/assignments/_support/sort_none.gif]

IS-IS TLV/Sub-TLV [https://www.iana.org/assignments/_support/sort_none.gif]

Reference [https://www.iana.org/assignments/_support/sort_none.gif]

0-255

Reserved

[RFC7752<http://www.iana.org/go/rfc7752>]

256

Local Node Descriptors

[RFC7752, Section 3.2.1.2<http://www.iana.org/go/rfc7752>]

257

Remote Node Descriptors

[RFC7752, Section 3.2.1.3<http://www.iana.org/go/rfc7752>]

258

Link Local/Remote Identifiers

22/4

[RFC5307, Section 1.1<http://www.iana.org/go/rfc5307>]

259

IPv4 interface address

22/6

[RFC5305, Section 3.2<http://www.iana.org/go/rfc5305>]

260

IPv4 neighbor address

22/8

[RFC5305, Section 3.3<http://www.iana.org/go/rfc5305>]

261

IPv6 interface address

22/12

[RFC6119, Section 4.2<http://www.iana.org/go/rfc6119>]

262

IPv6 neighbor address

22/13

[RFC6119, Section 4.3<http://www.iana.org/go/rfc6119>]

263

Multi-Topology ID

[RFC7752, Section 3.2.1.5<http://www.iana.org/go/rfc7752>]

264

OSPF Route Type

[RFC7752, Section 3.2.3<http://www.iana.org/go/rfc7752>]

265

IP Reachability Information

[RFC7752, Section 3.2.3<http://www.iana.org/go/rfc7752>]

266

Node MSD (TEMPORARY - registered 2017-11-02, extension registered 2018-09-07, expires 2019-11-02)

242/23

[draft-ietf-idr-bgp-ls-segment-routing-msd<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-msd>]

267

Link MSD (TEMPORARY - registered 2017-11-02, extension registered 2018-09-07, expires 2019-11-02)

(22,23,25,141,222,223)/15

[draft-ietf-idr-bgp-ls-segment-routing-msd<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-msd>]

268-511

Unassigned

512

Autonomous System

[RFC7752, Section 3.2.1.4<http://www.iana.org/go/rfc7752>]

513

BGP-LS Identifier

[RFC7752, Section 3.2.1.4<http://www.iana.org/go/rfc7752>]

514

OSPF Area-ID

[RFC7752, Section 3.2.1.4<http://www.iana.org/go/rfc7752>]

515

IGP Router-ID

[RFC7752, Section 3.2.1.4<http://www.iana.org/go/rfc7752>]

516

BGP Router-ID

[draft-ietf-idr-bgpls-segment-routing-epe<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]

517

BGP Confederation Member

[draft-ietf-idr-bgpls-segment-routing-epe<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]

518-1023

Unassigned

1024

Node Flag Bits

[RFC7752, Section 3.3.1.1<http://www.iana.org/go/rfc7752>]

1025

Opaque Node Attribute

[RFC7752, Section 3.3.1.5<http://www.iana.org/go/rfc7752>]

1026

Node Name

variable

[RFC7752, Section 3.3.1.3<http://www.iana.org/go/rfc7752>]

1027

IS-IS Area Identifier

variable

[RFC7752, Section 3.3.1.2<http://www.iana.org/go/rfc7752>]

1028

IPv4 Router-ID of Local Node

134/---

[RFC5305, Section 4.3<http://www.iana.org/go/rfc5305>]

1029

IPv6 Router-ID of Local Node

140/---

[RFC6119, Section 4.1<http://www.iana.org/go/rfc6119>]

1030

IPv4 Router-ID of Remote Node

134/---

[RFC5305, Section 4.3<http://www.iana.org/go/rfc5305>]

1031

IPv6 Router-ID of Remote Node

140/---

[RFC6119, Section 4.1<http://www.iana.org/go/rfc6119>]

1032-1033

Unassigned

1034

SR Capabilities

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1035

SR Algorithm

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1036

SR Local Block

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1037

SRMS Preference

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1038-1087

Unassigned

1088

Administrative group (color)

22/3

[RFC5305, Section 3.1<http://www.iana.org/go/rfc5305>]

1089

Maximum link bandwidth

22/9

[RFC5305, Section 3.4<http://www.iana.org/go/rfc5305>]

1090

Max. reservable link bandwidth

22/10

[RFC5305, Section 3.5<http://www.iana.org/go/rfc5305>]

1091

Unreserved bandwidth

22/11

[RFC5305, Section 3.6<http://www.iana.org/go/rfc5305>]

1092

TE Default Metric

22/18

[RFC7752, Section 3.3.2.3<http://www.iana.org/go/rfc7752>]

1093

Link Protection Type

22/20

[RFC5307, Section 1.2<http://www.iana.org/go/rfc5307>]

1094

MPLS Protocol Mask

[RFC7752, Section 3.3.2.2<http://www.iana.org/go/rfc7752>]

1095

IGP Metric

[RFC7752, Section 3.3.2.4<http://www.iana.org/go/rfc7752>]

1096

Shared Risk Link Group

[RFC7752, Section 3.3.2.5<http://www.iana.org/go/rfc7752>]

1097

Opaque Link Attribute

[RFC7752, Section 3.3.2.6<http://www.iana.org/go/rfc7752>]

1098

Link Name

[RFC7752, Section 3.3.2.7<http://www.iana.org/go/rfc7752>]

1099

Adjacency Segment Identifier (Adj-SID) TLV

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1100

LAN Adjacency Segment Identifier (Adj-SID) TLV

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1101

Peer-Node-SID

[draft-ietf-idr-bgpls-segment-routing-epe<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]

1102

Peer-Adj-SID

[draft-ietf-idr-bgpls-segment-routing-epe<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]

1103

Peer-Set-SID

[draft-ietf-idr-bgpls-segment-routing-epe<http://www.iana.org/go/draft-ietf-idr-bgpls-segment-routing-epe>]

1104

Unassigned

1105

RTM Capability

22/40

[RFC8169<http://www.iana.org/go/rfc8169>]

1106-1113

Unassigned

1114

Unidirectional Link Delay (TEMPORARY - registered 2017-08-18, extension registered 2018-07-20, expires 2019-08-18)

[draft-ietf-idr-te-pm-bgp<http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]

1115

Min/Max Unidirectional Link Delay (TEMPORARY - registered 2017-08-18, extension registered 2018-07-20, expires 2019-08-18)

[draft-ietf-idr-te-pm-bgp<http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]

1116

Unidirectional Delay Variation (TEMPORARY - registered 2017-08-18, extension registered 2018-07-20, expires 2019-08-18)

[draft-ietf-idr-te-pm-bgp<http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]

1117

Unidirectional Packet Loss (TEMPORARY - registered 2017-08-18, extension registered 2018-07-20, expires 2019-08-18)

[draft-ietf-idr-te-pm-bgp<http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]

1118

Unidirectional Residual Bandwidth (TEMPORARY - registered 2017-08-18, extension registered 2018-07-20, expires 2019-08-18)

[draft-ietf-idr-te-pm-bgp<http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]

1119

Unidirectional Available Bandwidth (TEMPORARY - registered 2017-08-18, extension registered 2018-07-20, expires 2019-08-18)

[draft-ietf-idr-te-pm-bgp<http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]

1120

Unidirectional Bandwidth Utilization (TEMPORARY - registered 2017-08-18, extension registered 2018-07-20, expires 2019-08-18)

[draft-ietf-idr-te-pm-bgp<http://www.iana.org/go/draft-ietf-idr-te-pm-bgp>]

1121

Graceful-Link-Shutdown TLV

[RFC8379<http://www.iana.org/go/rfc8379>]

1122-1151

Unassigned

1152

IGP Flags

[RFC7752, Section 3.3.3.1<http://www.iana.org/go/rfc7752>]

1153

IGP Route Tag

[RFC5130<http://www.iana.org/go/rfc5130>]

1154

IGP Extended Route Tag

[RFC5130<http://www.iana.org/go/rfc5130>]

1155

Prefix Metric

[RFC5305<http://www.iana.org/go/rfc5305>]

1156

OSPF Forwarding Address

[RFC2328<http://www.iana.org/go/rfc2328>]

1157

Opaque Prefix Attribute

[RFC7752, Section 3.3.3.6<http://www.iana.org/go/rfc7752>]

1158

Prefix SID

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1159

Range

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1160

Unassigned

1161

SID/Label TLV

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1162-1169

Unassigned

1170

IGP Prefix Attributes

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1171

Source Router-ID

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1172

L2 Bundle Member TLV

[draft-ietf-idr-bgp-ls-segment-routing-ext<http://www.iana.org/go/draft-ietf-idr-bgp-ls-segment-routing-ext>]

1173

Extended Administrative Group (TEMPORARY - registered 2018-04-09, expires 2019-04-09)

22/14

[draft-ietf-idr-eag-distribution<http://www.iana.org/go/draft-ietf-idr-eag-distribution>][RFC7308<http://www.iana.org/go/rfc7308>]

1174-65535

Unassigned

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Oct 2018 08:58:55 +0100

Sorry for the delay, Robert: travel.

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Oct 2018 14:36:13 +0200

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 <[email-masked]> wrote:

> 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.
>
> If summarization is in use, then a small change to the IGP database might
> cause no change to the summarized information.
> 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.
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 26 Oct 2018 13:18:54 +0000

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 <[email-masked]>
Sent: 26 October 2018 20:36
To: [email-masked]
Cc: [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>
Subject: Re: [Idr] Growing BGP-LS Attribute

Adrian,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Sorry for the delay, Robert: travel.

Adrian

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Oct 2018 15:40:56 +0200

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

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.

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.

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

On Fri, Oct 26, 2018 at 3:18 PM Ketan Talaulikar (ketant) <[email-masked]>
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.
>
>
>
> 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.
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* 26 October 2018 20:36
> *To:* [email-masked]
> *Cc:* [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>
> *Subject:* Re: [Idr] Growing BGP-LS Attribute
>
>
>
> Adrian,
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 26 Oct 2018 13:55:08 +0000

Hi Robert,

Please check inline below.

From: Robert Raszuk <[email-masked]>
Sent: 26 October 2018 21:41
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Thanks,
Ketan

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

Adrian,

Best
R.

Adrian

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 26 Oct 2018 14:00:33 +0000

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, October 22, 2018 3:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Growing BGP-LS Attribute

> soon we will have bgp-ls doctors.

Honestly having to read through all of the recent bgp-ls proposals and extensions there is so much confusion there on what goes to NLRI vs BGP-LS Attribute, what is TLV and when nesting to sub-TLVs makes sense, why do we send different BGP-LS Attribute depending to which NLRI it accompanies etc .. that I think BGP-LS doctor(s) are needed not soon but yesterday. And some of those documents are at the the WG-LC status too ...

Yes interestingly no one cares to touch on few other BGP aspects which may come into play. Example: Should BGP-LS be eligible to be packed into BMP (considering recent BMP extension proposals), how the dynamic IGP data be of any use if some BGP still uses long MRAI timer for subsequent updates on the same NLRI etc ...
[Shunwan]
I think the idea of using BMP is feasible.
The BMP Loc-RIB draft (https://tools.ietf.org/wg/grow/draft-ietf-grow-bmp-local-rib/) already mentions this if I understand it correctly.
It says:
"
   o  Requires additional BGP peering to collect the received updates
      when peering may have not even been required in the first place.
      For example, VRF's with no peers, redistributed bgp-ls with no
      peers, segment routing egress peer engineering where no peers have
      link-state address family enabled.

"
Thanks,
Shunwan

> as adrian says, if you wanna monitor the igp, then do so directly.

Well as you know in practice this is not always an option - in fact this is almost never an option in production network ... Controllers running on x86 boxes sit far from routers and are never allowed to connect to them directly. So bringing IGP adjacency between router and such oracle is hard ... even assuming it would be just passive one. That's why TCP is so attractive since as long as server is reachable the session will be formed and bits transferred..

randy