Subject: [Idr] Questions on your presentations ...

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Jul 2018 00:52:44 +0200

Hi Jakob,
1. I noticed you are pushing in parallel variable length TLVs in BGP Hellos
.. do you expect this to also take years to implement ? So you are saying
it take too long to write code for variable length TLVs - I assume this
does apply to BGP Hellos TLVs ...
​
2. Why not RTC also based on Standard and Large Communities ? ​

3. +1 to Jeff's & Keyur's comments

4. New additional RTC SAFI for 30 octets XXXL ext communities is ... insane
- not only obvious but then you would need to get complex dealing with
different/opposite filtering results from different RTCs SAFIs.

Cheers,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 19 Jul 2018 19:11:19 -0400

> different/opposite filtering results from different RTCs SAFIs.

I would like to offer a very specific reductio ad absurdum:
I propose that the next version of communities we do, if they must be fixed
length, must be 253 octets of value and 255 bytes of total size.

If we must do fixed, do it and be done for a long while.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Jul 2018 01:20:39 +0200

> If we must do fixed

I do not think we must do fixed. I see no reason to stick with fixed.

Experience has proven that fixed does not work .. we see this clear in the
proposals being submitted and even presented at IDR. Time to learn from
past mistakes.

Thx,
Robert

On Fri, Jul 20, 2018 at 1:11 AM, Jeffrey Haas <[email-masked]> wrote:

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 20 Jul 2018 03:27:18 +0000

Inline.

Regards,
Jakob.

From: [email-masked] <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, July 19, 2018 3:53 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: Questions on your presentations ...

Hi Jakob,
1. I noticed you are pushing in parallel variable length TLVs in BGP Hellos .. do you expect this to also take years to implement ? So you are saying it take too long to write code for variable length TLVs - I assume this does apply to BGP Hellos TLVs ...

[[jheitz]] Community code is not just about writing wire encoding.
It's mostly about writing policy code and handling the myriad of options.
We already have all of that and so does every other vendor.
Reusing all of that with a different length is easy.
Writing code for a different kind of community from scratch or even writing extended communities from scratch is an order of magnitude bigger.

Once you make variable length, there is no end to people inventing stuff to put in it and it will never finish. And then you have to write all the policy code from scratch.
I wrote the large community code by reusing the community code, so I know.

It's got nothing to do with variable length hellos. There's no policy code to write for that. The information to put in there is readily available and needs little code. We might be able to reuse some LDP code, but maybe not much.

​

4. New additional RTC SAFI for 30 octets XXXL ext communities is ... insane - not only obvious but then you would need to get complex dealing with different/opposite filtering results from different RTCs SAFIs.

Cheers,
R.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 20 Jul 2018 03:48:10 +0000

Not at all. Experience has shown that fixed works very well.
Large community went from concept to RFC and code complete with all the routing policy code in 2 years,
because we could reuse the community code.
Variable length communities started in 2002
https://tools.ietf.org/html/draft-lange-flexible-bgp-communities-00
The code will have to be written from scratch.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, July 19, 2018 4:21 PM
To: Jeffrey Haas <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations ...)

Experience has proven that fixed does not work .. we see this clear in the proposals being submitted and even presented at IDR. Time to learn from past mistakes.

Thx,
Robert

On Fri, Jul 20, 2018 at 1:11 AM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

-- Jeff

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

---

From: John Scudder <[email-masked]>
Date: Fri, 20 Jul 2018 03:53:25 +0000

(speaking as an individual WG contributor)

I think it is a big mistake to suggest that the reason flexcomms/wide comms hasn't progressed is that it's variable-length. It's much more ambitious than any of the fixed-length stuff we have, that's a reason. It's recursive, that might be a reason too. But just because it's variable-length? Not buying it.

$0.02,

--John

On Jul 19, 2018, at 11:48 PM, Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:jheitz=[email-masked]>> wrote:

https://tools.ietf.org/html/draft-lange-flexible-bgp-communities-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dlange-2Dflexible-2Dbgp-2Dcommunities-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=RAOaw8LZr1xIkRNXO98NGuA1TlJ3QfiuPz4ecF7I8Wc&e=>

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Thursday, July 19, 2018 4:21 PM
To: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations ...)

Thx,
Robert

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=ANHXDEVazzM11nlzarMDH82yonWcxAhaK1ABXs_A62w&e=>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=ANHXDEVazzM11nlzarMDH82yonWcxAhaK1ABXs_A62w&e=

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 20 Jul 2018 04:04:54 +0000

The thing is I want to reuse the extended community code as much as possible.
The routing policy code and its associated configuration, show, xml and debug commands is the bulk of it.
The more you deviate, the harder it gets.
Variable length is a big deviation.

Regards,
Jakob.

From: John Scudder <[email-masked]>
Sent: Thursday, July 19, 2018 8:53 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Jeffrey Haas <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations ...)

$0.02,

--John

Regards,
Jakob.

Thx,
Robert

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Jul 2018 10:32:03 +0200

Hi John,

> It's recursive, that might be a reason too.

Where did you get such impression from ? Wide communities (or registered
wide communities specs) are not recursive and no nesting or inheritance was
ever the plan at the community level at least as far as my own intentions
were/are.

If there is some text in the current draft which makes you think so let's
edit it asap.

Many thx,
Robert.

On Fri, Jul 20, 2018 at 5:53 AM, John Scudder <[email-masked]> wrote:

> I think it is a big mistake to suggest that the reason flexcomms/wide
> comms hasn't progressed is that it's variable-length. It's much more
> ambitious than any of the fixed-length stuff we have, that's a reason. It's
> recursive, that might be a reason too. But just because it's
> variable-length? Not buying it.
>
> $0.02,
>
> --John
>
> On Jul 19, 2018, at 11:48 PM, Jakob Heitz (jheitz) <
> jheitz=[email-masked]> wrote:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dlange-2Dflexible-2Dbgp-2Dcommunities-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=RAOaw8LZr1xIkRNXO98NGuA1TlJ3QfiuPz4ecF7I8Wc&e=>
> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, July 19, 2018 4:21 PM
> *To:* Jeffrey Haas <[email-masked]>
> *Cc:* idr wg <[email-masked]>
> *Subject:* Re: [Idr] Fixed sized communities (was Re: Questions on your
> presentations ...)
>
>
> > If we must do fixed
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=ANHXDEVazzM11nlzarMDH82yonWcxAhaK1ABXs_A62w&e=>
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfkt
> xXE0SPGa4SW9Y&s=ANHXDEVazzM11nlzarMDH82yonWcxAhaK1ABXs_A62w&e=
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 20 Jul 2018 06:25:19 -0400

Jakob:

<individual contributor hat on> 

Two groups of people use BGP.  The BGP-LS people who feel adding TLVs and
TLVs of information is acceptable.  

You claim 1 TLVs is "too much" so that we must spin multiple sizes of
communities.    

Hmm. 

<individual contributor hat still on> 

Cheerily, Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, July 20, 2018 12:05 AM
To: John Scudder
Cc: idr wg; Robert Raszuk
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your
presentations ...)

The thing is I want to reuse the extended community code as much as
possible.

The routing policy code and its associated configuration, show, xml and
debug commands is the bulk of it.

Regards,

Jakob.

From: John Scudder <[email-masked]> 
Sent: Thursday, July 19, 2018 8:53 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Jeffrey Haas <[email-masked]>; idr wg
<[email-masked]>
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your
presentations ...)

I think it is a big mistake to suggest that the reason flexcomms/wide comms
hasn't progressed is that it's variable-length. It's much more ambitious
than any of the fixed-length stuff we have, that's a reason. It's recursive,
that might be a reason too. But just because it's variable-length? Not
buying it.

$0.02,

--John

On Jul 19, 2018, at 11:48 PM, Jakob Heitz (jheitz)
<jheitz=[email-masked]> wrote:

Large community went from concept to RFC and code complete with all the
routing policy code in 2 years,

<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_dr
aft-2Dlange-2Dflexible-2Dbgp-2Dcommunities-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scb
fh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZ
MdoxjfktxXE0SPGa4SW9Y&s=RAOaw8LZr1xIkRNXO98NGuA1TlJ3QfiuPz4ecF7I8Wc&e=>
https://tools.ietf.org/html/draft-lange-flexible-bgp-communities-00

Regards,

Jakob.

From: Idr < <mailto:[email-masked]> [email-masked]> On Behalf Of
Robert Raszuk
Sent: Thursday, July 19, 2018 4:21 PM
To: Jeffrey Haas < <mailto:[email-masked]> [email-masked]>
Cc: idr wg < <mailto:[email-masked]> [email-masked]>
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your
presentations ...)

Experience has proven that fixed does not work .. we see this clear in the
proposals being submitted and even presented at IDR. Time to learn from past
mistakes. 

Thx,
Robert

On Fri, Jul 20, 2018 at 1:11 AM, Jeffrey Haas < <mailto:[email-masked]>
[email-masked]> wrote:

-- Jeff

_______________________________________________
Idr mailing list
 <mailto:[email-masked]> [email-masked]
 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_idr&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJ
pw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=ANHXDEVazzM1
1nlzarMDH82yonWcxAhaK1ABXs_A62w&e=>
https://www.ietf..org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
 <mailto:[email-masked]> [email-masked]
 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJ
pw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=ANHXDEVazzM1
1nlzarMDH82yonWcxAhaK1ABXs_A62w&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_li
stinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJp
w7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=ANHXDEVazzM11
nlzarMDH82yonWcxAhaK1ABXs_A62w&e=

---

From: John Scudder <[email-masked]>
Date: Fri, 20 Jul 2018 11:00:27 +0000

On Jul 20, 2018, at 4:32 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Where did you get such impression from ? Wide communities (or registered wide communities specs) are not recursive and no nesting or inheritance was ever the plan at the community level at least as far as my own intentions were/are.

No doubt I've misremembered, I didn't go back to refer to the spec (nor have I now). I'll withdraw that remark and let stand the "variable-length is not actually that hard" comment. :-)

Since I'm taking up the list's time anyway, I'll add that yes, of course variable is slightly harder than fixed-length as Jakob says -- taken in isolation. I'm not at all convinced it's harder than every year or two implementing (specifying, maintaining) yet another slightly different fixed-size variant. (That comment addressed to the original topic and not to you, of course.)

--John

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 20 Jul 2018 13:49:55 +0000

There's also those that write the code and those that don't.
LSVR is going to be a major multi-man-year project. It's more than "just another address family".
There is a ton of issues that OSPF and ISIS handle differently.
LSVR will handle them differently again and will have more issues to handle differently.
The auto-discovery issue is just the start.
Then, implementation is not just protocol definition.
There's config, oper data, Yang, Test automation and the list goes on

A brand new protocol like LSVR does not compare with an increment to extended community code.
Variable length communities requires a rewrite.
My proposal is a major reuse of existing code. Much easier.

Regards,
Jakob.

From: Susan Hares <[email-masked]>
Sent: Friday, July 20, 2018 3:25 AM
To: Jakob Heitz (jheitz) <[email-masked]>; 'John Scudder' <[email-masked]>
Cc: 'idr wg' <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Subject: RE: [Idr] Fixed sized communities (was Re: Questions on your presentations ...)

Jakob:

Two groups of people use BGP.  The BGP-LS people who feel adding TLVs and TLVs of information is acceptable.
You claim 1 TLVs is "too much" so that we must spin multiple sizes of communities.
Hmm.

Cheerily, Sue

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, July 20, 2018 12:05 AM
To: John Scudder
Cc: idr wg; Robert Raszuk
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations ....)

Regards,
Jakob.

From: John Scudder <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 19, 2018 8:53 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Jeffrey Haas <[email-masked]<mailto:[email-masked]>>; idr wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations ....)

$0.02,

--John

https://tools.ietf.org/html/draft-lange-flexible-bgp-communities-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf..org_html_draft-2Dlange-2Dflexible-2Dbgp-2Dcommunities-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=RAOaw8LZr1xIkRNXO98NGuA1TlJ3QfiuPz4ecF7I8Wc&e=>

Regards,
Jakob.

Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations ....)

Thx,
Robert

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf..org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=ANHXDEVazzM11nlzarMDH82yonWcxAhaK1ABXs_A62w&e=>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Jul 2018 15:57:40 +0200

Hi Jakob,

How out of the sudden this thread become LSVR thread ? Sue were merely
pointing out as example BGP-LS TLV based encoding ...

One thing for sure - and you were very honest which is highly appreciated -
with variable length communities some aspects of policy code needs to be
changed. True. And you don't want to do that - also true.

But this is just an opinion in no way I presume stopping IDR to standardize
good thing only due to potential issues with adjusting one BGP
implementation to accommodate it.

Thx,
R.

On Fri, Jul 20, 2018 at 3:49 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Susan Hares <[email-masked]>
> *Sent:* Friday, July 20, 2018 3:25 AM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; 'John Scudder' <
> [email-masked]>
> *Cc:* 'idr wg' <[email-masked]>; 'Robert Raszuk' <[email-masked]>
> *Subject:* RE: [Idr] Fixed sized communities (was Re: Questions on your
> presentations ...)
>
>
>
> Jakob:
>
> You claim 1 TLVs is “too much” so that we must spin multiple sizes of
> communities.
>
> Hmm.
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Jakob Heitz (jheitz)
> *Sent:* Friday, July 20, 2018 12:05 AM
> *To:* John Scudder
> *Cc:* idr wg; Robert Raszuk
> presentations ....)
> *From:* John Scudder <[email-masked]>
> *Sent:* Thursday, July 19, 2018 8:53 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* Robert Raszuk <[email-masked]>; Jeffrey Haas <[email-masked]>;
> idr wg <[email-masked]>
> presentations ....)
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf..org_html_draft-2Dlange-2Dflexible-2Dbgp-2Dcommunities-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=RAOaw8LZr1xIkRNXO98NGuA1TlJ3QfiuPz4ecF7I8Wc&e=>
>
> presentations ....)

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 20 Jul 2018 10:12:15 -0400

Jakob:

<individual hat on> 

My topic was not the auto-discovery issue or LSVR, but the 

amount of BGP-LS TLVs versus concern over 1 TLV header.  

I was simply noting the vastly different level of 

concern over space usage. 

<individual hat off> 

<chair hat on> 

BGP-LS was proposed for today's world.  

LSVR is different than basic BGP-LS.

IETF standardization will require management

information for LSVR.  Please discuss your 

concerns on LSVR with the LSVR chairs or a routing AD.  

Please continue to discuss your concerns about growing "information" on

IDR proposals - including last calls on the BGP-LS TLV or SR BGP-LS 

as part of the review process.  This input is always welcomed. 

<chair hat off> 

Susan Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, July 20, 2018 9:50 AM
To: Susan Hares; 'John Scudder'
Cc: 'idr wg'; 'Robert Raszuk'
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your
presentations ...)

LSVR is going to be a major multi-man-year project. It's more than "just
another address family".

LSVR will handle them differently again and will have more issues to handle
differently.

A brand new protocol like LSVR does not compare with an increment to
extended community code.

Regards,

Jakob.

From: Susan Hares <[email-masked]> 
Sent: Friday, July 20, 2018 3:25 AM
To: Jakob Heitz (jheitz) <[email-masked]>; 'John Scudder'
<[email-masked]>
Cc: 'idr wg' <[email-masked]>; 'Robert Raszuk' <robert@raszuk..net>
Subject: RE: [Idr] Fixed sized communities (was Re: Questions on your
presentations ...)

Jakob:

Two groups of people use BGP.  The BGP-LS people who feel adding TLVs and
TLVs of information is acceptable..  

Hmm. 

Cheerily, Sue 

Regards,

Jakob.

$0.02,

--John

<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf..org_html_d
raft-2Dlange-2Dflexible-2Dbgp-2Dcommunities-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Sc
bfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdC
ZMdoxjfktxXE0SPGa4SW9Y&s=RAOaw8LZr1xIkRNXO98NGuA1TlJ3QfiuPz4ecF7I8Wc&e=>
https://tools.ietf.org/html/draft-lange-flexible-bgp-communities-00

Regards,

Jakob.

 

Thx,
Robert

-- Jeff

https://www.ietf...org/mailman/listinfo/idr

---

From: <[email-masked]>
Date: Fri, 20 Jul 2018 14:15:45 +0000

1) I can see that from an implementer standpoint, in the short term, implementing one fixed length community is easier than a variable length one.

But the bigger picture is the long term work for the whole community.

Hence the point is to compare, in the long run, one variable length community format to N fixed length community formats. And evaluate the costs of specifying, implementing, testing, deploying, debugging, maintaining, operating (N sets of BGP policies)
It's clear that for N=255, one variable community format is better. I can't really imagine the nightmare with N=20.
Currently we have N=3, and two more propositions on the way. So this proposition is N=5 in the very short term.

Finally, IMO, the argument "I'm just asking for one more, it's urgent" has been taken by the BGP large community attribute. Now we need to look at the big long term picture.

2) Even for your own use case, I would argue that a variable length would be a better fit.
>From the abstract:
"   Auto-derived identifiers are used by applications to enable zero
   configuration features.  Such identifiers are often a combination of
   primitive identifiers and are thus longer. "

I think the sentence is missing "and variable in length"

Thanks,
Regards,
--Bruno

Regards,
Jakob.

$0.02,

--John

Regards,
Jakob.

Thx,
Robert

-- Jeff

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 20 Jul 2018 15:03:28 +0000

I'm going for bang for the buck.
There is not enough bang for the buck in variable length communities.
I cannot see variable length communities ever being developed.
We will keep squeezing the existing communities and when someone really needs an attribute that won't fit into one or a set of communities, they will develop a new attribute.

Regards,
Jakob.

From: [email-masked] <[email-masked]>
Sent: Friday, July 20, 2018 7:16 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: idr wg <[email-masked]>; Robert Raszuk <[email-masked]>; John Scudder <[email-masked]>
Subject: RE: [Idr] Fixed sized communities (was Re: Questions on your presentations ...)

2) Even for your own use case, I would argue that a variable length would be a better fit..

Thanks,
Regards,
--Bruno

Regards,
Jakob.

$0.02,

--John

Regards,
Jakob.

Thx,
Robert

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf...org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=ANHXDEVazzM11nlzarMDH82yonWcxAhaK1ABXs_A62w&e=>

Thank you.

---

From: <[email-masked]>
Date: Fri, 20 Jul 2018 15:29:36 +0000

That's the same argument: you are seeking local optimization based on your position in the ecosystem.
But there are other positions.
Thanks for acknowledging that your plan is to continue requesting additional fixed length community attributes forever.

Regards,
--Bruno

From: Jakob Heitz (jheitz) [mailto:[email-masked]]
Sent: Friday, July 20, 2018 11:03 AM
To: DECRAENE Bruno IMT/OLN
Cc: idr wg; Robert Raszuk; John Scudder
Subject: RE: [Idr] Fixed sized communities (was Re: Questions on your presentations ...)

Regards,
Jakob.

Thanks,
Regards,
--Bruno

Regards,
Jakob.

$0.02,

--John

Regards,
Jakob.

Thx,
Robert

-- Jeff

Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 20 Jul 2018 12:03:28 -0400

> Thanks for acknowledging that your plan is to continue requesting additional fixed length community attributes forever.

Indeed.

Contents of xxc draft:
type:subtype:v6:6
type:subtype:v4:18
type:subtype:as4:18
type:evpn subtype 4:as4:esi (10):MBZ(8)
type:evpn subtype 5:as4:esi (10):evi-rt (4): MBZ(4)
type:evpn subtype 6:as4:A+space(1):D-ID(1):service-id(16) (zero filled)

If the goal was the first three generics were intended to have similar
local-admin lengths, 6 would be the size instead of 6,18,18. (Large
community argument: uniformity.)

The evpn objects outright say they're reserving/wasting space.

I already get nag mail from operators about "how many of X can I put in the
packet".  I'd really like to keep things compact.

-- Jeff

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 20 Jul 2018 16:05:55 +0000

(Changed the subjust line)..

BGP-LS was proposed for today’s world.

Perhaps. But Given the growing usage of  more and more (streaming or not) telemetry data from every node in a pseudo real-time manner (using pick your favorite transport machinery - gRPC/Gpb, restconf/xml/yang, SNMP...etc), it is worth asking ourselves, whether BGP(-LS) is still the right vehicle for conveying IGP (and more) related info.

Cheers,
Rajiv

On Jul 20, 2018, at 10:13 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Jakob:
<individual hat on>

<chair hat on>
BGP-LS was proposed for today’s world.

Please continue to discuss your concerns about growing “information” on
IDR proposals – including last calls on the BGP-LS TLV or SR BGP-LS
as part of the review process.  This input is always welcomed.
<chair hat off>

Susan Hares

Regards,
Jakob.

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 20, 2018 3:25 AM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; 'John Scudder' <[email-masked]<mailto:[email-masked]>>
Cc: 'idr wg' <[email-masked]<mailto:[email-masked]>>; 'Robert Raszuk' <robert@raszuk..net>
Subject: RE: [Idr] Fixed sized communities (was Re: Questions on your presentations ....)

Jakob:

Two groups of people use BGP.  The BGP-LS people who feel adding TLVs and TLVs of information is acceptable..
You claim 1 TLVs is “too much” so that we must spin multiple sizes of communities.
Hmm.

Cheerily, Sue

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, July 20, 2018 12:05 AM
To: John Scudder
Cc: idr wg; Robert Raszuk
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations .....)

Regards,
Jakob.

Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations .....)

$0.02,

--John

https://tools.ietf.org/html/draft-lange-flexible-bgp-communities-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf...org_html_draft-2Dlange-2Dflexible-2Dbgp-2Dcommunities-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=2hIY6rLbAvAIj9fLY9vdCZMdoxjfktxXE0SPGa4SW9Y&s=RAOaw8LZr1xIkRNXO98NGuA1TlJ3QfiuPz4ecF7I8Wc&e=>

Regards,
Jakob.

Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations .....)

Thx,
Robert

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 20 Jul 2018 12:16:06 -0400

> Perhaps. But Given the growing usage of  more and more (streaming or not) telemetry data from every node in a pseudo real-time manner (using pick your favorite transport machinery - gRPC/Gpb, restc…

One portion of BGP-LS was to be used by other routing mechanisms for
spanning IGP domains.  Putting your question a different way, "do I want to
use grpc to consume routing state necessary for multi IGP domain work?"

Not really.

I'm quite supportive of other access mechanisms for that data once you have
it.  grpc, yang/i2rs.

-- Jeff

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 20 Jul 2018 17:02:06 +0000

+ 1

Both have their own value suitable for different use-cases.

Thanks,
Ketan

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Jeffrey Haas
Sent: 20 July 2018 12:16
To: Rajiv Asati (rajiva) <rajiva=[email-masked]>
Cc: Jakob Heitz (jheitz) <jheitz=[email-masked]>; Robert Raszuk <[email-masked]>; Susan Hares <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] BGP-LS vs gRPC/gpb or...

> Perhaps. But Given the growing usage of  more and more (streaming or not) telemetry data from every node in a pseudo real-time manner (using pick your favorite transport machinery - gRPC/Gpb, restc…

One portion of BGP-LS was to be used by other routing mechanisms for spanning IGP domains.  Putting your question a different way, "do I want to use grpc to consume routing state necessary for multi IGP domain work?"

Not really.

I'm quite supportive of other access mechanisms for that data once you have it.  grpc, yang/i2rs.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Jul 2018 13:50:55 -0400

> There is not enough bang for the buck in variable length communities.

bang for whose buck?  maybe ask an operator or ten.

ranndy

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 20 Jul 2018 18:06:40 +0000

We went 16 years trying to make a variable length community and in all that time nobody found a compelling enough case to make it actually happen.

Regards,
Jakob.

-----Original Message-----
From: Randy Bush <[email-masked]> 
Sent: Friday, July 20, 2018 10:51 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]; idr wg <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: Re: [Idr] Fixed sized communities (was Re: Questions on your presentations ...)

ranndy

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 20 Jul 2018 14:44:26 -0400

+1

Not to forget operational side of things, BGP infra (RR's, etc) is already been deployed and in operations, which significantly reduces cost of introduction.

Using BGP for resource allocation and feedback is much more complicated topic, there's a reason we have got configuration/applied/operational states in configuration and management space, introducing of similar states in BGP would be.... I'm yet to come up with a name :)

When it comes to streaming, especially when there's a constant stream of data/updates - gRPC looks like a very good choice 

Cheers,
Jeff

On 7/20/18, 12:16, "Idr on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    
    Not really.

    -- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 20 Jul 2018 20:01:09 +0000

BGP-LS is available. Model based Telemetry is available.
SNMP is really bad, because it is pull based.

Regards,
Jakob.

-----Original Message-----
From: Jeff Tantsura <[email-masked]> 
Sent: Friday, July 20, 2018 11:44 AM
To: Jeffrey Haas <[email-masked]>; Rajiv Asati (rajiva) <[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; Robert Raszuk <[email-masked]>; Susan Hares <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] BGP-LS vs gRPC/gpb or...

+1

Cheers,
Jeff

    
    
    Not really.

    -- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Jul 2018 22:36:33 +0200

So what is missing in telemetry streaming ?

Why can't we push LSDB and all zoo of extensions to go out via such
streaming instead of via BGP-LS ?

The Interdomain aspect is highly questionable ...

1. You do not exchange your LSDB with strangers
2. If your neighboring AS in yours or your friends streaming to them from
aggregation points seems pretty safe too.

Maybe is time to deprecate BGP-LS ?

Best,
R.

On Fri, Jul 20, 2018 at 10:01 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> Cc: Jakob Heitz (jheitz) <[email-masked]>; Robert Raszuk <
> [email-masked]>; Susan Hares <[email-masked]>; idr wg <[email-masked]>
> Not to forget operational side of things, BGP infra (RR's, etc) is already
> been deployed and in operations, which significantly reduces cost of
> introduction.
>
> Using BGP for resource allocation and feedback is much more complicated
> topic, there's a reason we have got configuration/applied/operational
> states in configuration and management space, introducing of similar states
> in BGP would be.... I'm yet to come up with a name :)
>
> When it comes to streaming, especially when there's a constant stream of
> data/updates - gRPC looks like a very good choice
>
> Cheers,
> Jeff
>
>     > Perhaps. But Given the growing usage of  more and more (streaming or
> not) telemetry data from every node in a pseudo real-time manner (using
> pick your favorite transport machinery - gRPC/Gpb, restconf/xml/yang,
> SNMP...etc), it is worth asking ourselves, whether BGP(-LS) is still the
> right vehicle for conveying IGP (and more) related info.
>     >
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Jul 2018 17:12:34 -0400

> SNMP is really bad, because it is pull based.

it may be horrible, but your customers have very large infrastructure to
pull, digest, and manange those data.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Jul 2018 17:14:40 -0400

> Maybe is time to deprecate BGP-LS ?

gawd no!  we would have to invent another layer to use to generate 432
interent-drafts  </snark>

randy

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 20 Jul 2018 17:39:53 -0400

IAB was quite clear on the direction wrt network management.

Regards,
Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 21 Jul 2018 00:24:01 +0200

Jeff,

Could you share:

* What is the IAB's definition of network management - does monitoring IGP
which now has fallen under BGP-LS is in scope of it ?

* Is there any pointer to document on what is IAB's quite clear position on
the above ?

Thx,
R.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 20 Jul 2018 18:02:14 -0700

Apologies for the top-reply; I'll try to keep things as brief as possible.

A lot can be learned from the transition from 16-bit ASNs to 32-bit ASNs.
(It "helped" in that circumstance that it was absolutely necessary, and
drove implementation/adoption.)

What is there to learn? AS4 vs AS2 required backward compatibility, while
avoiding downgrading all AS4 speakers, and breaking AS4 loop detection. The
compatibility mechanism will continue to be required until the last
AS2-only speaker is eliminated from the Internet.

Moving to variable-length communities, of any sort, will similarly require
compatibility modes, in exactly the same way, for exactly the same duration.

What this means to me is the following:

   1. Until wide (near-universal) implementation, and wide (significant)
   deployment of variable-length community speakers, there will continue to be
   an absolute requirement that new community types be added the current way
   (fixed-length).
   2. Anyone who feels the long-term move to variable-length communities,
   is urged to standardize, and/or implement, and/or deploy, variable-length
   communities.
   3. The market necessarily will dictate when (if ever) it is appropriate
   to switch new communities to variable-length implementations only.
   4. Until that happens, under no circumstances is it going to be
   acceptable from the operator community, to block the standardization,
   implementation, and operation, of fixed-size communities.
   5. If variable-length happens, there will still be a need for legacy
   support for already-deployed fixed-size, until sufficient "critical mass"
   is reached, meaning there may be a (long) period of compatibility mode
   between variable-length speakers where they pass both variable-length and
   legacy fixed-length communities for exactly the same community types.
   6. (It may be worth looking into the DNS community vs email community,
   and the TXT vs SPF debacle to comprehend both the "camps" mentality, and
   the danger of trying to use a unified field and overloading it to death.
   For those interested in sausage making and its outcomes, just look at the
   TXT records for any domain name, for how messy things can get.)
   7. Most of the concern on total size of communities due to multiple
   types being used simultaneously, is probably misplaced, IMHO, as it is very
   likely that only a subset of community types are ever appropriate to use on
   a given update message. Someone with a need for "large" pretty much, by
   definition, won't be using "standard" for all of their updates to all peers
   (including "large" speakers), with the possible exception of WKC that don't
   yet have "large" counterparts. Ditto IPv6 vs IPv4, and the need for an IPv8
   type is probably a long way off.
   8. The point of this is, there is no need to block either group's
   efforts. Indeed, both camps should (must) continue, until both have working
   deployed implementations. I'm happy to explain privately to anyone who
   doesn't agree or understand, and I think we may have reached the dead-horse
   flogging point.

I hope this is a positive contribution, and apologies if this wasn't as
brief as it should have been.

Brian

On Fri, Jul 20, 2018 at 9:03 AM Jeffrey Haas <[email-masked]> wrote:

> > Thanks for acknowledging that your plan is to continue requesting
> additional fixed length community attributes forever.
>
> Indeed.
>
> Contents of xxc draft:
> type:subtype:v6:6
> type:subtype:v4:18
> type:subtype:as4:18

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 21 Jul 2018 01:24:51 +0000

And they open large horrible bugs against it, which is why telemetry was invented. 

Regards,
Jakob.

---

From: Gert Doering <[email-masked]>
Date: Sat, 21 Jul 2018 22:56:35 +0200

Hi,

> And they open large horrible bugs against it, which is why telemetry was invented. 

And these large horrible bugs disappear over night by wrapping existing
information in a new encoding and a new transport?

Impressive :)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 22 Jul 2018 02:00:45 +0000

Yes.

SNMP is pull based. That means the management system has to ask for the routing table.
The router sends the whole table, even if nothing or very little has changed.
A huge waste of resources. It makes things horribly slow.
SNMP is udp based, so packets drop.
In many cases, the OID structure of SNMP is a transpose of the way the data is stored
in the router, making data retrieval very inefficient.
SNMP has no ability to snapshot a set of data: each item is independent of the next. Statistics change as they are being sent. One statistic will be inconsistent with the next one, because it was sampled at a different time.

Streaming telemetry has choices of transport and push/pull.
The best way is push mode and a tcp based transport, like GRPC.
Routes are only sent when they change. Unchanged data is not sent.

Frequently changing statistics may be better retrieved using the pull model.

Regards,
Jakob.

-----Original Message-----
From: Gert Doering <[email-masked]> 
Sent: Saturday, July 21, 2018 1:57 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Randy Bush <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] BGP-LS vs gRPC/gpb or...

Hi,

Impressive :)

Gert Doering
        -- NetMaster

---

From: Rob Shakir <[email-masked]>
Date: Sat, 28 Jul 2018 20:10:42 -0700

(Full disclosure: I have spent a lot of time on gRPC-based streaming
telemetry and have deployed it at scale.)

SNMP is clearly broken for this application, we need event-based push for
changes to a subset of the data set for any kind of efficiency. The scale
of periodically streaming BGP-RIB contents is too much for most systems,
let alone needing to do it with client-initiated polling.

Streaming telemetry absolutely needs reliable delivery for event-based
delivery, otherwise there is a significant concern around loss of events.
My colleague Carl Lebsack and I spoke at NANOG around our work on ST,
further details: slides
<https://pc.nanog.org/static/published/meetings/NANOG73/1677/20180625_Shakir_Snmp_Is_Dead_v1.pdf>,
video <https://youtu.be/McNm_WfQTHw>. There are a number of reasons that
the implementation of ST can be more robust than SNMP -- particularly,
these are focused around giving the device (target) more control over how
it generates and sends data.

Personally, I do not really buy the "BGP has a lower operational overhead
for deployment" point. Yes, it is more familiar, but the BGP-LS collector
is unlikely to be a familiar vendor device in any operational environment
(otherwise, how do I pull this data into another system?). This means that
there is still overhead of deploying a new BGPd somewhere off-device that
needs to be dealt with, and the configuration thereof. In my experience,
this overhead is significantly greater than "do I need to understand
another transport?". As I recall, there were few operational voices in IDR
at the time of BGP-LS saying this... it seems to me that we might have been
swayed more by the fact that the folks involved in that discussion had BGP
code written :-)

I continue to think that overloading BGP to carry this information wasn't
the right choice for the problem space discussed, and am unclear that we
made a good architectural decision for the "distributing IGP information
across multiple areas" case Jeff mentions above. There are still (to me)
significant robustness and fate-sharing concerns that make BGP-LS
undesirable for deployment (I raised these at the time of adoption
<https://www.ietf.org/mail-archive/web/idr/current/msg06565.html>, and
AFAICS nothing has really changed since).

I would encourage moving towards a single channel for network telemetry -
including BGP-LS - being the right way forward. Particularly, given that we
do not need protocol action and drafts to be published to put that data
there. Right now, we've just created an industry in BGP-LS-support-for-foo
drafts in IDR based on each doc in LSR.

Just my $0.02, £0.02, and €0.02,
r.

On Sat, 21 Jul 2018 at 19:01 Jakob Heitz (jheitz) <jheitz=
[email-masked]> wrote:

> SNMP has no ability to snapshot a set of data: each item is independent of
> the next. Statistics change as they are being sent. One statistic will be
> inconsistent with the next one, because it was sampled at a different time.
>
> Tel: +49 (0)89/32356-444 <+49%2089%2032356444>         USt-IdNr.:
> DE813185279
>