Subject: [Idr] Warren Kumari's Yes on draft-ietf-idr-bgp-open-policy-20: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 19 Jan 2022 07:33:59 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-idr-bgp-open-policy-20: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Firstly, thank you for this document -- if deployed, I think it will go a very
long way towards reducing accidental leaks.

I have a few comments, feel free to address or not.

1: It seems like there should also be a code-point for "Complex" - I guess that
something similar could be inferred if this is negotiated and one of the other
codepoints isn't sent, but having it explicit seems cleaner.

2: The document says things like "It **prevents** ASes from creating leaks,..."
and "The purpose of this attribute is to **guarantee** the once a route is
sent, ..." - it feels like this is overselling things. As an example, the OTC
attribute could be stripped (unintentionally or maliciously) and it would be
included in a leak, etc. Again, this is only a comment, but it seems like more
weasel words would make the document stronger.

3: "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" - fine, but it seems
like there should be a bit more than just "considered ineligible", for example,
this should be logged somewhere, or implementations should allow the operator
to do the conceptual equivalent of "show route leaked" or similar....

Again, thank you for a really useful document,

---

From: Alexander Azimov <[email-masked]>
Date: Sat, 22 Jan 2022 13:16:46 +0300

Warren,

Thank you for the review of the draft.
Our responses are marked with [AA/KS]

1: It seems like there should also be a code-point for "Complex" - I guess
that
something similar could be inferred if this is negotiated and one of the
other
codepoints isn't sent, but having it explicit seems cleaner.

[AA/KS] Your comment corresponds with what Robert Wilton asked in his
review. We had Complex in early versions of the document, and decided to
remove it since it isn't affecting the OTC attribute, and thus doesn't
directly affect the process of leak detection and prevention.
Of course there is an opportunity to reconsider this point, but I think
that other Roles (Complex/Internal/Collector etc.) should be considered in
future drafts.

2: The document says things like "It **prevents** ASes from creating
leaks,..."
and "The purpose of this attribute is to **guarantee** the once a route is
sent, ..." - it feels like this is overselling things. As an example, the
OTC
attribute could be stripped (unintentionally or maliciously) and it would be
included in a leak, etc. Again, this is only a comment, but it seems like
more
weasel words would make the document stronger.

[AA/KS] We used ‘enforce’ instead of ‘guarantee’. The updated sentence:

        The purpose of this attribute is to enforce
   that once a route is sent to a Customer, Peer, or RS-Client, it will
   subsequently go only to Customers.

We think the use of ‘prevent’, ’prevention’, etc. is OK.

3: "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" - fine, but it
seems
like there should be a bit more than just "considered ineligible", for
example,
this should be logged somewhere, or implementations should allow the
operator
to do the conceptual equivalent of "show route leaked" or similar....

[AA/KS] OTC based filtering as any other sort of filtering should have some
knobs to view what was filtered.
But this seems to be very dependent on the implementation along with
support for returning the reasons why route is in adj-rib-in but not legal
for best path selection process.

ср, 19 янв. 2022 г. в 18:34, Warren Kumari via Datatracker <[email-masked]
>:

-- 
Best regards,
Alexander Azimov