Subject: [Idr] New BGP capability to advertise running daemon version

From: Donatas Abraitis <[email-masked]>
Date: Fri, 2 Aug 2019 09:07:43 +0300

Hi there!

I would like to propose a new idea of how to simplify the debugging
process when dealing with lots of different BGP speakers and even more
with different versions.

Basically, the implementation is very trivial, but it would be handy
in cases when you should debug why some functionality does not work
between two or more BGP speakers. Having this in place would speedup
troubleshooting time. Even better if that comes to automation to
gather information around all infrastructure you have.

The implementation and details are posted in this draft:
https://www.ietf.org/id/draft-abraitis-bgp-version-capability-00.txt

Waiting for comments.

Thank you!

-- 
Donatas

---

From: ERCIN TORUN <[email-masked]>
Date: Fri, 2 Aug 2019 06:39:28 +0000

Hello Donatas,

I do think that your suggestion is handy, but from security perspective it is risky if you are enabling such a feature in a non-trust environment. An implementation warning should be added for vendors/code developers not to enable this capability by default. Enabling such a functionality by default might result in your neighbors knowing your BGP implementation & its version, which might contain security risks.

In security section you refer to RFC3552. In section 6.1.1.4 (https://tools.ietf.org/html/rfc3552#section-6.1.1) of mentioned RFC same suggestion exists but only for SMTP.

Regards
Erçin TORUN

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Donatas Abraitis
Sent: Friday, August 2, 2019 9:08 AM
To: [email-masked]
Subject: [Idr] New BGP capability to advertise running daemon version

Hi there!

I would like to propose a new idea of how to simplify the debugging process when dealing with lots of different BGP speakers and even more with different versions.

Basically, the implementation is very trivial, but it would be handy in cases when you should debug why some functionality does not work between two or more BGP speakers. Having this in place would speedup troubleshooting time. Even better if that comes to automation to gather information around all infrastructure you have.

Waiting for comments.

Thank you!

--
Donatas

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

[http://www.turkcell.com.tr/downloads/bireysel/img/Tcelldis.gif] <http://turkcell.li/iyaani>

Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir.

TURKCELL bu mesajin icerdigi bilgilerin doğruluğu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve TURKCELLin goruslerini yansitmayabilir

Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir.

________________________________

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted.

TURKCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of TURKCELL.

This e-mail has been scanned for all known computer viruses.

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 2 Aug 2019 09:56:22 +0300

Hello,

yes, it's risky and shouldn't be toggled by default, but in data
center environments where you have full control, it's very handy. For
instance in FRR has a few modes to operate like traditional and
datacenter. By having datacenter profile enabled, it's safe enough to
have this capability, IMO. Or as you suggested, just an additional
knob for configuring this is considered as well.

-- 
Donatas

---

From: ERCIN TORUN <[email-masked]>
Date: Fri, 2 Aug 2019 07:25:03 +0000

Hello Donatas, 

In FRR, profiles are a way of toggling mechanism but not all vendors implementations works the same way (e.g. toggling capability or its negotiation specifically). Anyway it is just a suggestion, not a crucial point. 

Regards 

-----Original Message-----
From: Donatas Abraitis <[email-masked]> 
Sent: Friday, August 2, 2019 9:56 AM
To: ERCIN TORUN <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] New BGP capability to advertise running daemon version

Hello,

yes, it's risky and shouldn't be toggled by default, but in data center environments where you have full control, it's very handy. For instance in FRR has a few modes to operate like traditional and datacenter. By having datacenter profile enabled, it's safe enough to have this capability, IMO. Or as you suggested, just an additional knob for configuring this is considered as well.

On Fri, Aug 2, 2019 at 9:39 AM ERCIN TORUN <[email-masked]> wrote:
> [http://www.turkcell.com.tr/downloads/bireysel/img/Tcelldis.gif] 
> <https://ddei3-0-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=htt
> p%3a%2f%2fturkcell.li%2fiyaani&umid=4041BB64-8F1C-DC05-87C2-15D2846F2A
> 9C&auth=54639621fcdd7e0f42d2a208112da27408386c06-c873efbf57aaf2ae8cad8
> dceac16346b12df973d>
>
> TURKCELL bu mesajin icerdigi bilgilerin doğruluğu veya eksiksiz oldugu 
> konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin 
> ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve 
> saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca 
> gonderen kisiye aittir ve TURKCELLin goruslerini yansitmayabilir
>

--
Donatas

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 2 Aug 2019 10:27:35 +0300

I got your point, thanks :)

-- 
Donatas

---

From: Job Snijders <[email-masked]>
Date: Fri, 2 Aug 2019 11:07:38 +0200

Dear Donatas,

Welcome to IDR! 

> https://www.ietf.org/id/draft-abraitis-bgp-version-capability-00.txt

I won't comment on the idea itself, but I note the following text in
your document:

    "IANA has assigned capability number 74 for the Version Capability
    described in this document.  This registration is in the BGP
    Capability Codes registry." 

Looking at https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
I see that this is not the case, which means that the draft is
'squatting' on capability number 74, making it harder for anyone in the
future to actually use number 74 when IANA assigns it to someone.

Please update your draft ASAP to read as following:

    "IANA is requested to assign a capability number for the Version
    Capability in this document from the BGP Capabilities Codes
    registry."

The IANA registries are not self-service "pick what you want", but
fortunately most of them allow allocation of code points through a
simple procedure. Please follow the process the group agreed upon.
I recommend reading https://tools.ietf.org/html/rfc7120

It is critical for interopability (not just for this draft, but also
future unrelated BGP drafts) that we ensure codepoints are assigned by
the IANA; in cases where this didn't happen, the codepoints often are
marked as 'deprecated', see https://tools.ietf.org/html/rfc8093 as an
example.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 2 Aug 2019 07:04:23 -0400

Hi Donatas,

In BGP protocol version number indicates the protocol version (ex BGP
version 4) vs specific implementation build. Take Junos or IOS or EOS ...
what is the version you would exchange in your extension ? The entire
operating system ?

Moreover BGP implementation version which you are proposing to add to
capabilities really means not much as even across identical protocol
binaries specific BGP features may be enabled by configuration or may not
resulting in different protocol behavior.

Today you are already exchanging the enabled functionality of the protocol
in BGP capabilities so it is just a matter of better show command to see
across all peers what features are advertised and received by their real
BGP capabilities.

Now if you intend to locate bgp speakers which in some "version" may have
bugs I am afraid much better way would be NMS for that.

Also BGP capabilities are only locally exchanged - so hosts will tell TOR
and that's it. You would still need to log in to 1000s of TORs to check
which OS binary is running there. And when the hosts get's upgraded you
start over.

Much better option in your case - and possibly in other cases - would be
perhaps to define new transitive BGP attribute or BGP wide community which
would advertise [bgp_id + received capabilities + negotiated capabilities]
across your domain.

Then you will be able to use this information in a much more granular way
and consistent across various BGP implementations.

Thx,
R.

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 2 Aug 2019 17:24:54 +0300

Hello guys,

Job, I posted revision 01 with your replaced text.

>In BGP protocol version number indicates the protocol version (ex BGP version 4) vs specific implementation build. Take Junos or IOS or EOS ... what is the version you would exchange in your extension ? The entire  operating system ?

It's not BGP protocol version, it's daemon/firmware version. So in
IOS/EOS/JunOS/etc. it would be like "CISCO 15.0(1)M8" or "JunOS
19.1R1". Device model, we can exchange using LLDP/CDP, but not a
specific version. Thus this would help in cases with lots of
heterogeneous devices.

>Also BGP capabilities are only locally exchanged - so hosts will tell TOR and that's it. You would still need to log in to 1000s of TORs to check which OS binary is running there. And when the hosts get's upgraded you start over.

One simple example is a single ToR device with 300 or 400 VMs under.
Each runs different versions BGP daemons. I noticed that few of 400
peers are down, how would you quickly identify which version or why
they are down? By having version in place it's easy to notice such
things and no need to log into those all 400 hosts in advance.

On Fri, Aug 2, 2019 at 2:04 PM Robert Raszuk <[email-masked]> wrote:
>
> Hi Donatas,
>
> In BGP protocol version number indicates the protocol version (ex BGP version 4) vs specific implementation build. Take Junos or IOS or EOS ... what is the version you would exchange in your extension ? The entire  operating system ?
>
> Moreover BGP implementation version which you are proposing to add to capabilities really means not much as even across identical protocol binaries specific BGP features may be enabled by configuration or may not resulting in different protocol behavior.
>
> Today you are already exchanging the enabled functionality of the protocol in BGP capabilities so it is just a matter of better show command to see across all peers what features are advertised and received by their real BGP capabilities.
>
> Now if you intend to locate bgp speakers which in some "version" may have bugs I am afraid much better way would be NMS for that.
>
> Also BGP capabilities are only locally exchanged - so hosts will tell TOR and that's it. You would still need to log in to 1000s of TORs to check which OS binary is running there. And when the hosts get's upgraded you start over.
>
> Much better option in your case - and possibly in other cases - would be perhaps to define new transitive BGP attribute or BGP wide community which would advertise [bgp_id + received capabilities + negotiated capabilities] across your domain.
>
> Then you will be able to use this information in a much more granular way and consistent across various BGP implementations.
>
> Thx,
> R.
>
>
> On Fri, Aug 2, 2019, 02:09 Donatas Abraitis <[email-masked]> wrote:
>>
>> Hi there!
>>

-- 
Donatas

---

From: Job Snijders <[email-masked]>
Date: Fri, 2 Aug 2019 23:30:20 +0900

> Job, I posted revision 01 with your replaced text.

Thanks!

> specific version. Thus this would help in cases with lots of

Yes, I can see value. However sometimes the BGP session is older than the
software release. There are implementations where the daemon is updated but
the BGP session stays up.

Perhaps exchanging the version - only - when the session is brought up
isn’t sufficient, and moving this into a message type of sorts may make
more sense.

Thoughts?

Kind regards,

Job

---

From: Sandy Breeze <[email-masked]>
Date: Fri, 2 Aug 2019 14:44:07 +0000

Hi Donastas,

>    things and no need to log into those all 400 hosts in advance.

How would you identify versions on those sessions which are down?  Are you assuming the ToR might cache the information after the lifetime of the session?  That’s probably quite implementation specific assumption and I probably wouldn’t bank on it being there.

I can see value though.

Sandy

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 2 Aug 2019 17:44:24 +0300

Basically, you are right, but this kind of capability is valid almost
the same way as other capabilities. Let's take "FQDN Capability". We
can change the hostname, but the session remains up with the old
hostname. Of course, this version capability is designed more for
"modern" datacenter designs "Routing on the host". I doubt if it would
be useful for ISP-like architectures. It's not a single tool to manage
all cases :)

On Fri, Aug 2, 2019 at 5:30 PM Job Snijders <[email-masked]> wrote:
>
> On Fri, Aug 2, 2019 at 23:25 Donatas Abraitis <[email-masked]> wrote:
>>
>> Hello guys,
>>
> Yes, I can see value. However sometimes the BGP session is older than the software release. There are implementations where the daemon is updated but the BGP session stays up.
>
> Perhaps exchanging the version - only - when the session is brought up isn’t sufficient, and moving this into a message type of sorts may make more sense.
>
> Thoughts?
>
> Kind regards,
>
> Job

-- 
Donatas

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 2 Aug 2019 17:56:55 +0300

Hello Sandy,

>How would you identify versions on those sessions which are down?  Are you assuming the ToR might cache the information after the lifetime of the session?  That’s probably quite implementation speci…

Good point. This can be reflected in logs or can be stored in peer's
cache (but I'm not sure the latter is the right solution). Another use
case would be like checking why some routes are not announced from
random hosts? Even more, bundling this information together with FQDN
capability would open a bigger picture of what's going on in your
network.

--
Donatas

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 2 Aug 2019 11:02:51 -0400

Donatas,

> knob for configuring this is considered as well.

Others have mentioned the security considerations.  I'd be a bit concerned
that such a thing really was "off by default".

Beyond that, items put into capabilities right now are intended to impact
operational behaviors.  This doesn't feel like the best fit for me.

If I could be talked into wanting this at all, I suspect I might be more
supportive of having this be an optional parameter rather than a capability.

-- Jeff

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 2 Aug 2019 18:07:20 +0300

Hello Jeffrey,

yep, I don't see any reasons why to not add this as "off by default".
I think it's fine while it can be controlled on demand.

-- 
Donatas

---

From: Job Snijders <[email-masked]>
Date: Sat, 3 Aug 2019 00:09:22 +0900

Right now operators use the peer’s MAC address and certain TCP behaviorism
(nmap -O) to attempt to conclude what the remote side might be in case of
issues.

I see value in having this on by default. Security through obscurity isn’t
the best defense anyway. I’m assuming a degree of trust exists anyway, why
else set up a BGP session in the first place?

I think there are valid use cases, i think it is worthwhile exploring how
to implement this concept.

Kind regards,

Job

---

From: Gert Doering <[email-masked]>
Date: Fri, 2 Aug 2019 17:14:55 +0200

Hi,

On Fri, Aug 02, 2019 at 05:24:54PM +0300, Donatas Abraitis wrote:
> Device model, we can exchange using LLDP/CDP, but not a specific version. 

Don't tell that to my gear...

Cisco#sh cdp nei det
...
Version :
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9-M), Version 15.1(2)SY11

Cisco#sh lldp nei det
...
System Description: 
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.0(2)SE9, RELEASE SOFTWARE (fc1)

seem to be exchanging software versions in quite some detail.

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: Robert Raszuk <[email-masked]>
Date: Fri, 2 Aug 2019 11:19:35 -0400

Hi,

Just to refresh memory there is an active WG document precisely describing
how to carry such information between BGP peers. It is called BGP
Operational Message

https://tools.ietf.org/html/draft-ietf-idr-operational-message-00

The ADVISE TLV there section 3.4.1 and 4 are proposed with the very same
intention as this discussion is targeting.

Due to no customer push vendors have not implemented it yet. So the draft
is just hanging waiting for implementations.

I think if there is some new interest please consider to review the linked
WG doc and possibly augment it with missing elements.

Use of BGP capabilities in current state of implementation of bgp dynamic
capabilities is really not the right messaging vehicle here.

Thx,
R.

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 2 Aug 2019 18:20:21 +0300

Hi Gert,

good :) Then capability might work only where LLDP/CDP is not enabled.

-- 
Donatas

---

From: Job Snijders <[email-masked]>
Date: Sat, 3 Aug 2019 00:21:01 +0900

Perhaps this work should be picked up again.

On Sat, Aug 3, 2019 at 00:19 Robert Raszuk <[email-masked]> wrote:

>> Right now operators use the peer’s MAC address and certain TCP
>> behaviorism (nmap -O) to attempt to conclude what the remote side might be
>> in case of issues.
>>
>> I see value in having this on by default. Security through obscurity
>> isn’t the best defense anyway. I’m assuming a degree of trust exists
>> anyway, why else set up a BGP session in the first place?
>>

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 2 Aug 2019 16:22:07 +0100

I'd be very much in favour of seeing draft-ietf-idr-operational-message 
being pushed towards publication.

Nick

Job Snijders wrote on 02/08/2019 16:21:
> On Sat, Aug 3, 2019 at 00:19 Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     Just to refresh memory there is an active WG document precisely
>     describing how to carry such information between BGP peers. It is
>     called BGP Operational Message
> 
>     The ADVISE TLV there section 3.4.1 and 4 are proposed with the very
>     same intention as this discussion is targeting.
> 
>     Due to no customer push vendors have not implemented it yet. So the
>     draft is just hanging waiting for implementations.
> 
>     I think if there is some new interest please consider to review the
>     linked WG doc and possibly augment it with missing elements.
> 
>     Use of BGP capabilities in current state of implementation of bgp
>     dynamic capabilities is really not the right messaging vehicle here.
> 
>     Thx,
>     R.
> 
>     On Fri, Aug 2, 2019 at 11:09 AM Job Snijders <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         behaviorism (nmap -O) to attempt to conclude what the remote
>         side might be in case of issues.
> 
>         I see value in having this on by default. Security through
>         obscurity isn’t the best defense anyway. I’m assuming a degree
>         of trust exists anyway, why else set up a BGP session in the
>         first place?
> 
>         I think there are valid use cases, i think it is worthwhile
>         exploring how to implement this concept.
> 
>         Kind regards,
> 
>         Job
>         [email-masked] <mailto:[email-masked]>

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 2 Aug 2019 18:27:28 +0300

https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
sounds interesting to me as well. It can be used to implement IRC over
BGP :)

-- 
Donatas

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 2 Aug 2019 11:29:44 -0400

Hey Nick & Job,

Extremely happy to see your support here.

Draft wise I think we still have sources :) But what really got this work
stuck is implementations.

Perhaps if we could make FRR and BIRD to implement it we could test it and
ask for WGLC.

Of course if there is seriou sinterest we should also ask for IANA
allocations too. I think both Rob & David would be happy to see this moving
forward too :)

Thx a lot,
R.

---

From: Job Snijders <[email-masked]>
Date: Sat, 3 Aug 2019 00:36:24 +0900

Dear robert,

> allocations too. I think both Rob & David would be happy to see this moving

In order to move this forward, I think it would be good to split the draft
out into the framework and then separately document the features. This
allows the work to progress (in part), even when we encounter controversy.

Cutting this up in smaller chunks will increase the likelihood of reaching
the finish line.

It also would make RFP / feature requesting + vendor management easier if
we make sure all the documents in their entirety represent coherent
building blocks.

I’m happy to work on such a proposal with you.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 2 Aug 2019 11:49:53 -0400

Dear Job,

The current version of the document is already a very limited subset of
functionality mainly focusing on defining new BGP message after we took two
documents (BGP Advisory and BGP Diagnostics Messages) and merged them into
one document.

Quote from section 10:

   This memo is based on existing works [I-D.ietf-idr-advisory] and
   [I-D.raszuk-bgp-diagnostic-message] which describe a number of
   operational message types documented here.

If one would define just new BGP Operational Message alone then the
question will come up to provide the use cases. So here we are defining the
former with few optional use cases which was operationally found to be of
some use.

Of course this is no longer individual draft but belongs to WG so what WG
decides to do with it (if anything) is fine. Is core of your suggestion
that it is much easier to push N TLVs each in separate draft via IDR or
GROW rather then keep them in one consistent document - assuming that some
of them are just optional TLVs ?

Thx,
R.

On Fri, Aug 2, 2019 at 11:36 AM Job Snijders <[email-masked]> wrote:

>> Perhaps if we could make FRR and BIRD to implement it we could test it
>> and ask for WGLC.
>>

---

From: Job Snijders <[email-masked]>
Date: Sat, 3 Aug 2019 01:02:34 +0900

On Sat, Aug 3, 2019 at 00:50 Robert Raszuk <[email-masked]> wrote:

> of them are just optional TLVs?
>

Yes, that is the essence of my suggestion. I suspect it’ll be much easier
to get implementations, show interopability, and facilitate discussing
requirements with vendors if the document is chopped up.

As you pointed out the draft in its current form didn’t manage to advance
due lack of implementations, and I agree with your assessment. The current
draft is a tall order to ask from any implementer.

We can make a proposal and see if we can succeed this time around.

Kind regards,

Job

---

From: John Scudder <[email-masked]>
Date: Fri, 2 Aug 2019 17:35:40 +0000

(As a WG member)

If the conversation is moving on to resuscitating Operational Message, that’s fine, please disregard the below. Otherwise, a few remarks regarding the specific approach of using a Capability to send this info.

On Aug 2, 2019, at 10:30 AM, Job Snijders <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps exchanging the version - only - when the session is brought up isn’t sufficient, and moving this into a message type of sorts may make more sense.

I believe there is a move afoot to dust off and renovate dynamic capability. If that moves forward this might be a good candidate.

On Aug 2, 2019, at 11:02 AM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Beyond that, items put into capabilities right now are intended to impact
operational behaviors.  This doesn't feel like the best fit for me.

FQDN has been mentioned a few times (and looks to have been the model for this draft). On the other hand, the working group decided to pass on FQDN; it’s not a working group draft much less an RFC. If the WG were to adopt the present draft, I think it would be a fair to question if FQDN should be reconsidered and if not, why not, and if FQDN were to be reconsidered I think it would be fair to ask if both should be bundled together, especially since both are just unstructured text.

The problem with that suggestion is that the defined behavior for receiving an optional parameter you don’t recognize is to reset the session. I presume you would not suggest that it’s desirable for an unrecognized version string to cause a session to not come up. Years ago we did recognize this issue and introduced a way to send parameters that if unrecognized are just ignored instead of causing a reset. We called those parameters “capabilities”. :-/

—John

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 7 Aug 2019 11:34:05 -0400

Job and Robert: 

If you wish to pick draft-ietf-idr-opertional-messages-00.txt , just resubmit with a new version.  

If you have 2 implementations, we can push this quickly toward publication. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Friday, August 2, 2019 11:21 AM
To: Robert Raszuk
Cc: [email-masked]
Subject: Re: [Idr] New BGP capability to advertise running daemon version

Hi,

Just to refresh memory there is an active WG document precisely describing how to carry such information between BGP peers. It is called BGP Operational Message

The ADVISE TLV there section 3.4.1 and 4 are proposed with the very same intention as this discussion is targeting. 

Due to no customer push vendors have not implemented it yet. So the draft is just hanging waiting for implementations.  

I think if there is some new interest please consider to review the linked WG doc and possibly augment it with missing elements. 

Use of BGP capabilities in current state of implementation of bgp dynamic capabilities is really not the right messaging vehicle here. 

Thx,

R.

Right now operators use the peer’s MAC address and certain TCP behaviorism (nmap -O) to attempt to conclude what the remote side might be in case of issues. 

I see value in having this on by default. Security through obscurity isn’t the best defense anyway. I’m assuming a degree of trust exists anyway, why else set up a BGP session in the first place?

I think there are valid use cases, i think it is worthwhile exploring how to implement this concept.

Kind regards,

Job

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 7 Aug 2019 11:34:52 -0400

Robert:

The TLVs on an IDR message will need to be done in IDR. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, August 2, 2019 11:50 AM
To: Job Snijders
Cc: Rob Shakir; [email-masked]; [email-masked]
Subject: Re: [Idr] New BGP capability to advertise running daemon version

Dear Job,

The current version of the document is already a very limited subset of functionality mainly focusing on defining new BGP message after we took two documents (BGP Advisory and BGP Diagnostics Messages) and merged them into one document. 

Quote from section 10:

If one would define just new BGP Operational Message alone then the question will come up to provide the use cases. So here we are defining the former with few optional use cases which was operationally found to be of some use. 

Of course this is no longer individual draft but belongs to WG so what WG decides to do with it (if anything) is fine. Is core of your suggestion that it is much easier to push N TLVs each in separate draft via IDR or GROW rather then keep them in one consistent document - assuming that some of them are just optional TLVs ?

Thx,
R.

Dear robert,

Draft wise I think we still have sources :) But what really got this work stuck is implementations. 

Perhaps if we could make FRR and BIRD to implement it we could test it and ask for WGLC. 

Of course if there is seriou sinterest we should also ask for IANA allocations too. I think both Rob & David would be happy to see this moving forward too :) 

In order to move this forward, I think it would be good to split the draft out into the framework and then separately document the features. This allows the work to progress (in part), even when we encounter controversy.

Cutting this up in smaller chunks will increase the likelihood of reaching the finish line.

It also would make RFP / feature requesting + vendor management easier if we make sure all the documents in their entirety represent coherent building blocks.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Aug 2019 11:27:59 -0400

> The problem with that suggestion is that the defined behavior for receiving an optional parameter you don’t recognize is to reset the session. I presume you would not suggest that it’s desirable fo…

Just to close the thread here, I agree with your argument and withdraw my
suggestion.  "Optional" is perhaps not the best name for the 4271 feature at
this point given its resistance to using it for future extensions.

It does leave me feeling like it may be easier to just rename capabilities
as "BGP Open TLVs" and be done with it. :-)

-- Jeff (maybe for BGP-5)