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

[Alexander Azimov <[e-mail]>]

Colleagues,

I would like to unveil what took us so long to reply.
We have an ongoing discussion about adding a formal description of
Complex/Sibling relations.
With the import and export policy definitions, it can be done rather easy,
it follows the Peer definition that Sriram has already shown:

   Sibling:  May propagate any available route to a Sibling.  May accept
      any available route received from a Sibling.

Sriram's concern was that Sibling has a notation for ASNs belonging to the
same administrative entity (701, 702, 703 belonging to Verizon as an
example), while I believe that the term Sibling isn't bound only for this
kind of peering relation and can safely replace Complex, though improving
the readability of the document.


ср, 5 янв. 2022 г. в 20:12, 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
>


-- 
Best regards,
Alexander Azimov