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.sri...@nist.gov>: > 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
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art