Subject: [Idr] Robert Wilton's No Objection on draft-ietf-idr-bgp-open-policy-20: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 18 Jan 2022 09:43:32 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-idr-bgp-open-policy-20: No Objection

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

Hi,

Thanks for this document.  I'm no expect on BGP, but I found this document
pretty easy to read and understand.  Not surprisingly, I'm always supportive of
drafts that aim to minimize configuration errors and operational problems.

I have a a few comments though:

(1) Did you consider explicitly defining a code point for the "complex" role? 
Today, because of the desire for backwards compatibility, it is not possible
for a peer to distinguish between the case that (i) no role has been provided
by the peer because it doesn't support roles, and (ii) no role has been
provided by the peer because it thinks that it has a "complex" peering
relationship.  Unless I'm missing something, adding an explicit role for
"complex" would allow the peer to distinguish between these two cases and
potentially capture more errors (e.g., complex role is only valid with peer's
complex role).  In theory, enabling "strict" checking might also be able to
cover this case, it is feels less intuitive (i.e., enable strict, but don't
advertise a role to indicate and enforce a complex relationship).

(2) The obvious OPS/Mgmt AD question: Is the associated configuration for this
feature covered in the IETF BGP YANG module, or extension/augmentation that is
being worked on?  If so, then an informational reference to the configuration
leaves associated with this feature might be helpful to readers, although one
could perhaps argue that this would end up being a forward reference, and any
associated YANG module configuration should have references back to this draft
anyhow.

(3) As a nit, I notice that the sender can only include a single role but the
receiver must tolerate multiple roles if they have the same value.  Perhaps
everything else in BGP is tolerant of receiving malformed packets, and hence
this is done for consistency, but I do wonder whether it isn't better to return
an error to the peer instead.

Regards,
Rob

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Jan 2022 13:12:22 -0500

Rob,

> advertise a role to indicate and enforce a complex relationship).

Note that this point was raised in the following response.
https://mailarchive.ietf.org/arch/msg/idr/EGuoesCexQvbpzOntAS_p7lBGwM/

In the current document, the operator must disable roles in order to do
anything unusual.  

> associated YANG module configuration should have references back to this draft

Speaking as one of the BGP YANG authors, we're only now getting around to
having the module in good enough shape that such augmentations can be
considered.  Until a truly viable 1.0 is ready from the main BGP YANAG
authors, it doesn't make sense to request any YANG work from document
authors working on BGP extensions.

Exactly how we backfill individual extensions into the module will be a
longer discussion to have with our ADs and the IESG as a whole.

-- Jeff

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 18 Jan 2022 18:30:13 +0000

Hi Jeff,

Thanks for the very speedy reply.  Please see inline ...

> -----Original Message-----
> From: Jeffrey Haas <[email-masked]>
> Sent: 18 January 2022 18:12
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; draft-ietf-idr-bgp-open-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-bgp-open-
> policy-20: (with COMMENT)
> 
> Rob,
> 

Thanks for the reference.  Having read the referenced email it wasn't clear to me whether the IDR WG previously actively discussed/considered this and then dismissed this, or whether it never came up in WG discussion and perhaps it should be considered by the WG?

> authors working on BGP extensions.

Your and IDR's efforts at trying to get the BGP YANG model finished are appreciated.

> longer discussion to have with our ADs and the IESG as a whole.

Okay.  I hope that the IDR chairs/ADs are keeping a track of these potential updates to the IDR YANG model so that they don't get lost.  Note, they don't have to go under separate extensions, they could go under a revised version of the BGP model with if-feature statements.  Obviously, the benefit of agreeing the YANG configuration model at the same time as writing the feature is that it is easier to find consensus then trying to subsequently unify 5 vendors different configuration models for this feature.

Regards,
Rob

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 18 Jan 2022 12:32:24 -0600

On January 18, 2022 at 12:43:32 PM, Robert Wilton wrote:

Rob:

Hi!

Thanks for the review.

...
> (3) As a nit, I notice that the sender can only include a single role but
> the receiver must tolerate multiple roles if they have the same value.
> Perhaps everything else in BGP is tolerant of receiving malformed packets,
> and hence this is done for consistency, but I do wonder whether it isn't
> better to return an error to the peer instead.

Clarification: "multiple roles if they have the same value" means
multiple capabilities all indicating the same role...so we're not
really talking about receiving multiple roles (as in multiple
capabilities with different values).

   If an eBGP speaker receives multiple but identical BGP Role
   Capabilities with the same value in each, then the speaker must
   consider it to be a single BGP Role Capability and proceed [RFC5492].

An error is not sent because the behavior is specified in rfc5492
(Capabilities Advertisement):

   BGP speakers SHOULD NOT include more than one instance of a
   capability with the same Capability Code, Capability Length, and
   Capability Value.  Note, however, that processing of multiple
   instances of such capability does not require special handling, as
   additional instances do not change the meaning of the announced
   capability; thus, a BGP speaker MUST be prepared to accept such
   multiple instances.

Alvaro.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Jan 2022 13:45:07 -0500

Rob,

On Tue, Jan 18, 2022 at 06:30:13PM +0000, Rob Wilton (rwilton) wrote:
> Thanks for the reference.  Having read the referenced email it wasn't
> clear to me whether the IDR WG previously actively discussed/considered
> this and then dismissed this, or whether it never came up in WG discussion
> and perhaps it should be considered by the WG?

The history of the "complex" mode is as-labeled: complex.  The presence of
the role in the capability dropped out of the document between the -00 to -01
revision.  The text evolved over the history of the document trying to
figure out what, if anything, was required.

I believe the behavior of the complex role as specified in the current
document is fine.

The point raised in the thread was effectively whether there was operational
benefit to knowing that your peer supported open-policy and simply didn't
have one of the currently defined roles.  Right now, as you note, it's
indistinguishable from not having it available.

The only clear benefit from having some form of such a role is permitting a
BGP implementation to decide it won't peer with something that doesn't
support the feature.

There was no extensive discussion on the point.  Randy Bush dismissed the
thought with his usual charm.

-- Jeff

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Jan 2022 11:35:51 -0800

> figure out what, if anything, was required.
My observation and $0.02 on the underlying issue:
The route-leaks work (collectively) involves both this document (OTC) and
the proposed WKLC for marking/filtering.
Open (and OTC) are single-peer scoped.
The proper handling of "complex" more generally can only be done by
extending the BGP connectivity graph out to where the "complex" situation
is no longer relevant.
(In that regard, it's sort of like in Minesweeper, where the game
auto-clicks on all squares adjacent to any "0" squares and you end up with
a large field of edges.)

In the WKLC situation, the proper handling is/will-be/should-be to maintain
any WKLC marking unchanged across a "complex" peer.
Since the OTC/Open role has only immediately local knowledge on roles, it
is unable to achieve the same logic.

So, whether there is a "complex" OTC code or not wouldn't be able to modify
the behavior, as noted it cold be informative.
Thus, it's (IMHO) mostly moot.

Brian

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 20 Jan 2022 15:49:51 +0300

Robert, thank you for the review.
I also want to thank Alvaro and Jeff how have addressed most of your the
comments.

I will take the part related of Complex role. It's true that we had it in
early versions of the document.
And since the main goal of the document is the route leak detection and
prevention, and Complex wasn't affecting the OTC attribute we decided to
remove it.
Same reason was for removing Internal role from this document.

There might be other Role definitions: Complex/Internal/Collector etc, but
we believe that this should be done in different documents.

вт, 18 янв. 2022 г. в 20:43, Robert Wilton via Datatracker <[email-masked]
>:

> the

-- 
Best regards,
Alexander Azimov