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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
