Re: [Idr] Review of draft-abraitis-bgp-version-capability-07

["RFC ISE (Adrian Farrel)" <[e-mail]>]

Hello Robert,

>> The IESG will consider this document on Sep/10
>
> May I ask why are we skipping normal process to go via IDR with this
> draft ?

It's a valid question.

After several attempts, the IDR WG was not apparently willing to adopt
this idea. The chairs confirmed this, and the author brought the work to
the Independent Stream.

Note that on 20191121 I sent mail to IDR ("Cross-check wrt
draft-abraitis-bgp-version-capability") to give a heads-up on this plan.

> Also looking at latest published version why status of this doc is
> "Informational" if essentially this is a protocol extension?

The Independent Stream is not capable of producing Standards Track RFCs.
This "protocol extension" using a FCFS code point is, therefore,
documented in an Informational RFC to describe what has been implemented
and how to use/interoperate with it.

> Last - if this is to be enabled only for iBGP does this mean that we
> are endorsing networks which do not know in their NMS what version of
> operating systems is deployed on a given network element?

I don't think that "we" are endorsing anything. This document is stating
what has been implemented.

We could discuss adding text to say that "In many networks, it might be
expected that the NMS would have full knowledge of the deployed operating
system versions on each router in the network. This mechanism provides a
way to verify that information and operate in the absence of a coordinated
NMS." I'm not sure how helpful such text would be.

> And for
> manual CLI based iBGP session troubleshooting how does it help to know
> the version of route reflector if problem with received UPDATES or
> WITHDRAWS can be generated one iBGP hop behind it?

I'll leave Donatas to answer that one.

Best,
Adrian
-- 
Adrian Farrel (ISE),
[e-mail]