Subject: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-bgp-open-policy-19: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 18 Jan 2022 01:41:58 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-idr-bgp-open-policy-19: 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:
----------------------------------------------------------------------

Thank you for the work put into this document. The technique could indeed be
useful, let's simply hope that not only the well-configured BGP speakers will
use it ;-)

Please find below some non-blocking minor COMMENT points (no need to reply).

Special thanks to Susan Hares for the shepherd's write-up including the section
about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

Is RFC 7908 really a normative reference ?

-- Section 3.1 --
"An eBGP speaker MUST NOT advertise multiple versions of the BGP Role
Capability" Should there be a description of what to do when a eBGP speaker
receives multiple conflicting roles on a session ? Or hint to section 3.2 for
more details ?

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Jan 2022 11:06:56 +0100

> receives multiple conflicting roles on a session ? Or hint to section 3.2

Hi Eric & Authors,

Based on your above comment/question I have a clarification question to
this as well.

If the new proposed capability is per session how would the draft cover the
case where
on a single session for IPv4/IPv6 unicast two ASNs are *Peers* while say
for SAFI 128 one
ASN is a *Customer* of the other ASN ?

I understand that the document focuses just on IP Unicast peering and it
says
"The main focus/applicability is the Internet (IPv4 and IPv6 unicast route
advertisements)."
but perhaps the case where peering relation may be different for different
services carried
in BGP should be at least discussed if not addressed.

Also could there be the case that for IPv4 one is Transit and for IPv6 is a
Peer based on the
amount of the exchanged traffic ?

The simplest way to solve nicely all of the above would be to add AFI/SAFI
ID to the capability
and allow to list more then one such tuple during BGP OPEN exchange.

Many thx,
Robert

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 18 Jan 2022 03:42:31 -0800

On January 18, 2022 at 4:41:59 AM, Éric Vyncke wrote:

Éric:

Hi!

Thanks for the review!

...
> Is RFC 7908 really a normative reference ?

Yes, I believe so: it is where the concept of route leaks is
explained, which is what this document is addressing.  Ben suggested
adding a couple more references to it (in other parts of the text) to
reinforce its importance.

> receives multiple conflicting roles on a session ? Or hint to section 3.2 for

§3.2 does (in the second-to-last paragraph) specify what to do.

I don't see a problem with adding a forward reference.

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 18 Jan 2022 04:23:05 -0800

On January 18, 2022 at 5:07:09 AM, Robert Raszuk wrote:

Robert:

Hi!

...
> case where on a single session for IPv4/IPv6 unicast two ASNs are Peers
> while say for SAFI 128 one ASN is a Customer of the other ASN ?
...
> services carried in BGP should be at least discussed if not addressed.

This type of case is what the document calls a "complex" relationship:

   If the local AS has more than one peering role with the remote AS
   such peering relation is called Complex.  An example is when the
   peering relationship is Provider-to-Customer for some prefixes while
   it is Peer-to-Peer for other prefixes [Gao].

   ...

   Roles MUST NOT be configured on an eBGP session with a Complex
   peering relationship.  If multiple eBGP sessions can segregate the
   Complex peering relationship into eBGP sessions with normal peering
   relationships, BGP Roles SHOULD be used on each of the resulting eBGP
   sessions.

...
> ID to the capability and allow to list more then one such tuple during BGP
> OPEN exchange.

Sure, that could be a way to deal with complex relationships.  A new
capability would be needed.  Given where we are with this document
(past IETF LC, implementations, etc.), the would would need to be done
elsewhere.

Thanks!

Alvaro.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 21 Jan 2022 00:58:48 +0000

Hi Eric,
Thank you for your comments.

>Is RFC 7908 really a normative reference?
Yes. We now refer to it two more times later in the document. Please see my response to Benjamin.

>-- Section 3.1 --
>"An eBGP speaker MUST NOT advertise multiple versions of the BGP Role Capability" Should there be a description of what to do when a eBGP speaker receives multiple conflicting roles on a session ? Or hint to section 3.2 for more details?
We made this change providing the forward reference:
   An eBGP speaker MUST NOT advertise multiple versions of the BGP Role Capability.  The
   error handling when multiple BGP Role Capabilities are received is described in Section 3.2.

Regards,
Sriram

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 21 Jan 2022 07:01:51 +0000

Hello Sriram

Thank you for your reply. I agree with the two changes addressing my previous non-blocking COMMENT issues.

Regards

-éric

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Friday, 21 January 2022 at 01:59
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-idr-bgp-open-policy-19: (with COMMENT)

Hi Eric,

Regards,
Sriram