Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-open-policy-18

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Gyan,

Thank you. Please see the responses inline.

Gyan> Agreed that is acceptable.  In the description as well maybe listing a
pecking order similar to what is described in Gao-Rexford model style
route preference in the import and export policy verbiage for each role.

[KS/AA]: That is interesting. We did already enhance the Role descriptions as follows to add the import policy verbiage (to the already existing export policy) in Sec. 2 of v-19 to be uploaded:

Old text:

   The following is a list of BGP Roles for eBGP peering and the
   corresponding rules for route propagation:

   Provider:  MAY propagate any available route to a Customer.

   Customer:  MAY propagate any route learned from a Customer, or
      locally originated, to a Provider.  All other routes MUST NOT be
      propagated.

   Route Server (RS):  MAY propagate any available route to a Route
      Server Client (RS-Client).

   RS-Client:  MAY propagate any route learned from a Customer, or
      locally originated, to an RS.  All other routes MUST NOT be
      propagated.

   Peer:  MAY propagate any route learned from a Customer, or locally
      originated, to a Peer.  All other routes MUST NOT be propagated.

New text:

   The following is a list of BGP Roles for eBGP peering and the
   corresponding rules for route propagation and acceptance:

   Provider:  May propagate any available route to a Customer.  May
      accept routes originated by the Customer or its Customers; all
      other routes from the Customer must not be accepted.

   Customer:  May propagate any route learned from a Customer, or
      locally originated, to a Provider; all other routes must not be
      propagated.  May accept any route from the Provider.

   Route Server (RS):  May propagate any available route to a Route
      Server Client (RS-Client).  May accept routes originated by the
      RS-Client or its Customers; all other routes from the RS-Client
      must not be accepted.

   RS-Client:  May propagate any route learned from a Customer, or
      locally originated, to an RS; all other routes must not be
      propagated.  May accept any route received from the RS.

   Peer:  May propagate any route learned from a Customer, or locally
      originated, to a Peer; all other routes must not be propagated.
      May accept routes originated by the Peer or its Customers; all
      other routes from the Peer must not be accepted.

--- end of new text ---
>Also could mention that a good reasons for role capabilities usage by
operators  is to prevent routing policy disputes between peering points
that can result in sub optimal routing instability and feedback loops along
with route leaks mentioned.

[KS/AA]: Maybe adding the following paragraph at the end of Section 3.2 (Role Correctness) would do it?

Besides facilitating a route leak solution, the Role Capability usage by network operators also helps prevent routing policy disputes between peering ASes. This can in turn prevent sub-optimal routing and routing instability.

Not sure if the feedback loop needs to be mentioned. Do you mean a loop in the AS path (normally prevented by checking the presence of the speaker's own AS in the path)?

Sriram / Alexander