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
