FAQ on draft-frs-bgp-operational-message-00 :


Q: What is your motivation behind this?

A: From the perspective of error handling we were seeing optional 
transitive attributes causing NOTIFICATION messages to be sent leading 
to remote session teardown. This prompted the creation of drafts such 
as draft-chen-ebgp-error-handling-00 and 
draft-ietf-idr-optional-transitive-03 which dealt with the problem but 
didn't provide any back-signalling,

Draft-shakir-idr-ops-reqs-for-bgp-error-handling-00 talks about such 
signalling but has no defined standards which we believe are useful 
enough to do this kind of signalling inter-domain.
At the same time, in an attempt to provide diagnostic facilities 
between neighbors, draft-raszuk-bgp-diagnostic-message-00 was 
published. 

In addition to this, internet operators were looking for a 
way to get human attention to issues they had with eBGP peering 
sessions with other operators, this led to the creation (and adoption) 
of draft-ietf-idr-advisory-00.

The authors of this draft believe that, should there be a need to 
introduce non-routing (i.e administrative) messages into the BGP, that 
these be kept to a minimum, this draft is essentially a merge of the 
most essential pieces of both the Advisory and Diagnostic drafts in 
order to present a single, unified framework for exchanging these 
non-fatal administrative requests across an existing session.

Q: Why is your focus on in-band signalling techniques?

A: The draft as it currently stands is rooted in the realm of using 
in-band signalling, with no preference for single or multi-session. The 
authors believe that being in-band provides a solid means of 
authentication (as the neighbor is a known, configured peer) and 
facilitation (you have an existing session (or multiple as in 
multisession)). 


Q: How do you think this will affect performance (i.e convergence)?

A: Spending time receiving, transmitting, formatting and parsing these 
messages whilst interleaved with critical routing updates is obviously 
a concern. In the draft states: "an implementation MUST NOT allow the 
handling of OPERATIONAL messages to negatively impact any other 
functions on a router such as regular BGP message handling or other 
routing protocols." (section 7) and provides implementors with a number 
of means of achieving this, including:

1. Rate-limiting, (with associated control codes to negotiate mutually 
acceptable rate limiting parameters and signal rate-limited conditions).

2. The ability to not respond to a request based on local policy (along 
with appropriate control codes to signal this back if need be).

3. The ability to not respond to a request based on local resources 
(along with appropriate control codes to signal this back if need be).

4. The ability to not respond at all.

Techniques such as making use of a connection within a multi-session 
environment (with which to transmit these messages over, perhaps 
ensuring that this session is handled by some redundant processing 
capability if need be) are fully available to implementations, should 
they wish to offload some functionality from the socket / process.


Q: Why the mix of human readable and machine readable data types?

A: Not much of the draft calls for human readable information to be 
transmitted and received, except for the operator-to-operator messages 
carried by the ADVISE types (which was the core of the Advisory draft), 
making the rest of these types (which are mainly for diagnostic 
purposes) suitable for machines to read allows such feats as rescuing 
malformed updates and logging them, along with their associated NLRI 
(as opposed to what happens now the session is closed by a NOTIFICATION 
and your implementation might oblige and give you a partial hex dump of 
the last thing it saw, in your logs).


Q. Is this for eBGP, iBGP or both?

A: It is considered that there is no restriction as to whether this 
mechanism is deployed on eBGP or iBGP. However, clearly some of the 
functions are likely to be of more utility across administrative 
boundaries, where access does not exist to both BGP speakers on a 
session. Within iBGP, types such as lists of prefixes that have been 
identified in a malformed UPDATE are likely to be of significant 
benefit in diagnosing intra-domain issues. The authors intent is not to 
restrict such a mechanism, and instead provide key operational 
functionality across BGP deployments.

Q: What security implications arise, what did you need to think about?

A: Mainly, see the performance question above. In addition to this, 
there exists the ability to query both the size of (and data within) 
the neighbor's entire BGP LOC RIB, something which the authors suspect 
will not be popular between internet operators. The draft makes 
recommendations that this ability be provided as a knob, in the default 
OFF position such that queries for the BGP LOC RIB are not answered by 
default (i.e unless the operator configures this). Such queries could 
be useful in the context of provider and customer (PE and CE) where the 
CE router is fully managed by the provider who, internally segments 
their organisation into "People who can access the PE" and "People that 
can access the CE". In these situations, knowing if the cause of the 
Adj-Rib-Out towards the PE being empty is caused by policy or outage 
can be advantageous and immensely time saving.


Q: What about BMP, don't you see an overlap here?

A: Not at all. The scope of BMP is, at present, quite different from 
OPERATIONAL. BMP is not an in-band protocol (even if it can be 
bootstrapped by BGP) and is currently designed to be utilised an 
intra-domain fashion. BMP also provides a greater superset of 
diagnostic capability than OPERATIONAL (but can do so because the 
overhead budgeting is not as constrained). The authors all think BMP is 
a fascinating technology with great potential to operators and will be 
closely following it.

Q: What errata has been found in -00 since publishing?

A: The following errata has been found in -00:

- Section 1, "can be assumed to either be authenticated" should read 
"can be assumed to be authenticated"

- Section 7, "information requested by SSR" should read "information 
requested by SSQ"


Q: What happens next?

A: We hope to collect as much feedback from the community as possible 
and aim to present on the topic in Quebec. See you there!