Subject: [Idr] draft-ietf-idr-bgp-open-policy

From: <[email-masked]>
Date: Mon, 31 Jan 2022 12:24:10 +0000

Hi authors, Sue, WG,

I've quickly reviewed the draft.
Although my comments are late, and most possibly I've missed something, I believe one (§4 OTC handling, below) is significant and would need to be corrected.

§4

"The Only to Customer (OTC) Attribute is an optional transitive path attribute »

So far, so good.

"   The following ingress procedure applies to the processing of the OTC

   Attribute on route receipt:
[...]

   2.  If a route with the OTC Attribute is received from a Peer and the

       Attribute has a value that is not equal to the remote (i.e.,

       Peer's) AS number, then it is a route leak and MUST be considered

       ineligible. »

You can't punish your neighbor for not correctly processing an optional transitive attribute that it does not support.
Proposed change
OLD:
   2.  If a route with the OTC Attribute is received from a Peer and

NEW:
   2.  If a route with the OTC Attribute is received from a Peer from which the BGP Role Capability has been successfully exchanged in the OPEN messages and

Then, for my own understanding, why do you say that if the AS number does not match, _then_ this is a route leak? To me this reflect a bug situation rather than a route leak.
On the same line, what the functional benefit of this AS value in the OTC?

----
§3.2

"The locally configured BGP Role is used for the procedures described in Section 4<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-21#section-4>. »

[...]

"   The BGP Role value for the local AS (in conjunction with the OTC

   Attribute in the received UPDATE message) is used in the route leak

   prevention and detection procedures described in Section 4<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-21#section-4>."

This looks like a duplicate to me. (plus lightly inconsistent).
--

§3.2

"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<https://datatracker.ietf.org/doc/html/rfc5492>]."

Presumably :s/must/MUST
---
§4

"1.  If a route is to be advertised to a Customer, Peer, or RS-Client

       (when the sender is an RS), and the OTC Attribute is not present,

       then an OTC Attribute MUST be added with a value equal to the AS

       number of the local AS.

2.  If a route already contains the OTC Attribute, it MUST NOT be

       propagated to Providers, Peers, or RS(s)."

-       Minor: I would have a preference to swap the numbers ("1" and "2") as one could argue that after step one, the route has the OTC attribute and hence would be filtered.

-       For step 1, I'd like the sentence to explicitly clarify that the OTC is added only on the eBGP advertised routes. (not on the route in the loc-RIB)
e.g.

OLD: If a route is to be advertised to

Proposed NEW: When route is advertised to

---

§4

"The procedures specified in this document are NOT RECOMMENDED to be

   used between autonomous systems in an AS Confederation [RFC5065<https://datatracker.ietf.org/doc/html/rfc5065>]."

What "procedures" are you referring to precisely? The ones for the OPEN, the OTC handling of both?

Plus all procedures defined in this document are specified as "MUST". I don't feel that "NOT RECOMMENDED" is meant to override a MUST, so may be the "MUST" procedure need to be updated to be changed to a SHOULD or to exclude the confederation case.

---

§4

"Once the OTC Attribute has been set, it MUST be preserved unchanged"

This does not seem consistent with other text in the document requiring to updating the AS number inside the OTC attribute.

---

§4

"The described ingress and egress procedures are applicable only for

   unicast IPv4 and IPv6 address families and MUST NOT be applied to

   other address families by default."

Given the strong "MUST NOT", could you please clarify the AFI/SAFI that you are referring to? (given wording does not match the SAFI names and seem subject to interpretation (e.g. 1 / 4 is IPv4, is unicast so it's not crystal clear whether it is in scope or not)

---

§5

"Further, this document does not specify any

   special handling of incorrect AS numbers in the OTC Attribute."

I believe it does (partially) as it enforce the correctness of the AS number received from an eBGP peer.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.