Alvaro,
Since I was pushing adding the ingress rules into the peering relation definition I will try to answer your comments.
чт, 6 янв. 2022 г. в 00:33, Alvaro Retana <aretana.ietf@xxxxxxxxx>:
On January 5, 2022 at 12:12:14 PM, Sriram, Kotikalapudi wrote:
Sriram:
Hi!
> [KS/AA]: That is interesting. We did already enhance the Role descriptions
> [KS/AA]: as follows to add the import policy verbiage (to the already
> [KS/AA]: existing export policy) in Sec. 2 of v-19 to be uploaded:
Route leaks are created by the (incorrect) advertisement of routes.
Defining egress rules is then in line with the subject of this
document.
It's true. But the incorrect or absent ingress rules are responsible for route leak propagation.
The OTC tries to address both problems: prevent networks from leaking prefixes and stop route leak propagation if it happens.
OTOH, ingress rules are not. Also, the ingress behavior is tied in
the draft to the OTC attribute (and not directly to the role).
Here we try to define peering relations. These definitions are not strictly bound to OTC mechanics, and IMO it doesn't bring any contradiction.
Today the ingress policy by Providers and Peers is done by generating prefix lists from AS-SETs. In an ideal situation, it should be equal to customer cone which is prefixes originated by Customer and its Customers.
The result is that the updated text is not consistent with the
behavior already defined elsewhere. For example, using the Provider
role:
> Old text:
...
> Provider: MAY propagate any available route to a Customer.
>
...
> New text:
...
> 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.
[Besides loosing the normative language...]
A strict interpretation of the text (routes originated by a Customer
can be accepted) is in contradiction with this text in §4:
1. If a route with the OTC Attribute is received from a Customer or
RS-Client, then it is a route leak and MUST be considered
ineligible (see Section 1.1).
Note that this text doesn't talk about the origin, but it qualifies
the policy based on the OTC attribute.
The definition of peering relations is followed by the next phrase:
A BGP speaker may apply policy to reduce what is announced, and a
recipient may apply policy to reduce the set of routes they accept.
So, the Provider/Peer may accept routes from the customer cone of Customer/Peer respectively.
If OTC is set, it signals that the route was leaked, such routes MUST be rejected, even if coming from the customer cone.
Have I missed your point?
All this is to say that the expected ingress behavior, which depends
on the OTC attribute, is already defined elsewhere and there's no need
to change the role definition.
These edits emerged when I tried to formally define Complex/Sibling relations. The sole propagation rule isn't enough to distinguish it from other types of peering relations.
New text (full version):
Provider: May propagate any available route to a Customer. May
accept routes originated by Customer or its Customers; all other
routes from 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 available route received from a
Provider.
Route Server (RS): May propagate any available route to a Route
Server Client (RS-Client). May accept routes originated by RS-
Client or its Customers; all other routes from 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 available route received from 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 Peer or its Customers; all other
routes from Peer must not be accepted.
Sibling: May propagate any available route to a Sibling. May accept
any available route received from a Sibling.
accept routes originated by Customer or its Customers; all other
routes from 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 available route received from a
Provider.
Route Server (RS): May propagate any available route to a Route
Server Client (RS-Client). May accept routes originated by RS-
Client or its Customers; all other routes from 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 available route received from 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 Peer or its Customers; all other
routes from Peer must not be accepted.
Sibling: May propagate any available route to a Sibling. May accept
any available route received from a Sibling.
If you suggest that the formal definition of Sibling relations doesn't improve the readability I will revert these changes and keep propagation rules only.
Best regards,
Alexander Azimov
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
