Subject: [GROW] BGP Role capability questions (draft-ymbk-idr-bgp-open-policy-03)

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 23 Mar 2017 16:00:53 +0000

This is meant to be friendly feedback/questions on the BGP Role capability proposal.
I think the claim is automation, which I am trying to understand/appreciate.
My difficulty is that BGP Role negotiation does not seem self-sufficient.
It still requires out-of-band (OOB) communication between operators to know 
the peering relationship, ASN, interface IP address, etc.  before BGP OPEN can be sent.
Then only can the operator fill in their BGP Role in the enhanced BGP OPEN message. Right?
So, BGP Role capability only seeks to re-confirm, does not replace the OOB part.

I suppose, if the BGP Role messages contradict with each other 
or with the prior OOB communication, the operators fall back on OOB 
once again to fix the miscommunication.
Further, for a "complex" relationship, the operators must inform 
each other via the OOB communication, the exact sets of prefixes 
for which they have different types of peering roles.
The BGP Role negotiation does not assist in that process. 
The per-prefix role info (for "complex") comes only from the OOB communication.

Considering the above, the following key statements 
in the Abstract (in the bgp-open-policy draft) do not seem entirely correct:

" This document enhances BGP Open to establish agreement
   of the (peer, customer, provider, internal) relationship of two
   neighboring BGP speakers to enforce appropriate configuration on both
   sides.  Propagated routes are then marked with an iOTC attribute
   according to agreed relationship allowing prevention of route leaks."

The enhanced BGP Open (or BGP Role capability) does not help in 
marking iOTC in the "complex" peering case. 
In that case, the OOB communication is all that is there to rely on. 
The proposed BGP Role capability cannot verify/confirm that unless all 
the per-prefix roles are also conveyed in the enhanced BGP Open message. 
But that is not feasible, right? 

The draft also does not cover all the mismatch conditions:
(1) If the BGP role messages contradict each other – do you drop the session?
(2) What is done if BGP role messages do not contradict each other but they 
contradict with the prior OOB communication, etc.?

Thanks!

Sriram