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

[Alvaro Retana <[e-mail]>]

On January 5, 2022 at 5:35:31 PM, Alexander Azimov wrote:


Alexander:


...
> > > [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 absent case has already been addressed by rfc8212.

We can only hope when related to incorrect policies: the operator can
also misconfigure the roles and render OTC useless. :-(


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

Yes.

The text already talks about the possibility to have stricter policies.

Without that context (stricter-than-what-the-OTC-related-policy) then
the new text is left to be "May accept routes originated by the
Customer or its Customers" which is not true because of the MUST later
on.

IOW, the extra text is complicating the interpretation of the roles.



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

As I said in my other message, I think that adding Sibling is unnecessary.


Thanks!

Alvaro.