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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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) <kotikalapudi.sriram@xxxxxxxx>:

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
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux