Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-open-policy-18

[Alexander Azimov <[e-mail]>]

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 <[e-mail]>:

> 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.

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