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

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.

On Fri, Aug 2, 2019 at 11:22 AM Nick Hilliard <nick@foobar.org> wrote:

> 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:
> > Perhaps this work should be picked up again.
> >
> > On Sat, Aug 3, 2019 at 00:19 Robert Raszuk <robert@raszuk.net
> > <mailto:robert@raszuk.net>> 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
> >
> >     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.
> >
> >     On Fri, Aug 2, 2019 at 11:09 AM Job Snijders <job@ntt.net
> >     <mailto:job@ntt.net>> 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?
> >
> >         I think there are valid use cases, i think it is worthwhile
> >         exploring how to implement this concept.
> >
> >         Kind regards,
> >
> >         Job
> >         _______________________________________________
> >         Idr mailing list
> >         Idr@ietf.org <mailto:Idr@ietf.org>
> >         https://www.ietf.org/mailman/listinfo/idr
> >
> >
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >
>