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