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

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sat, 5 Feb 2022 17:08:05 +0000

Hi Bruno,

Thank you. Responses are inline.

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

The basic principles of the procedure need to be understood. If your Peer (lateral peer) is compliant, then they may send you their originated or customer's routes and must attach OTC with a value equal to their (the Peer's) ASN. So, if the OTC you receive from a Peer has the Peer's ASN, then the UPDATE is valid. Whether Peer is compliant or not, if you receive an UPDATE from them that has an OTC value different from the Peer's ASN, then they are propagating a route received from their Provider or Peer and it is a route leak.

>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

Please see the response above. BGP Role Capability has played its part already in confirming the peering relationship (Section 3) and is used here (Section 4) in the background for knowledge about the peering relationship with the remote AS, but not explicitly needed in the procedures described in Section 4.

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

Please see the responses above.

>----
>§3.2
>"The locally configured BGP Role is used for the procedures described in Section 4https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-21#section-4-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 4https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-21#section-4."
>
>This looks like a duplicate to me. (plus lightly inconsistent).

I kind of see what you mean about a slight repetition. Somewhat intentional. I prefer to leave it as is.

>§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 [RFC5492https://datatracker.ietf.org/doc/html/rfc5492]."
>
>Presumably :s/must/MUST

You're right. Fixed.

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

I would leave the order as it is. The order does not make a material difference.

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

Step 1 is slightly reworded per your suggestion for clarity as follows:
OLD text:
   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.

NEW text:
   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 when advertising the route, an OTC Attribute MUST be added
       with a value equal to the AS number of the local AS.

>§4
>
>"The procedures specified in this document are NOT RECOMMENDED to be
>   used between autonomous systems in an AS Confederation [RFC5065https://datatracker.ietf.org/doc/html/rfc5065]."
>
>What "procedures" are you referring to precisely? The ones for the OPEN, the OTC handling of both?

Wording enhancement has been made for clarity:
OLD text:
   The procedures specified in this document are NOT RECOMMENDED to be
   used between autonomous systems in an AS Confederation [RFC5065].
NEW text:
   The BGP Role negotiation and OTC Attribute based procedures specified
   in this document are NOT RECOMMENDED to be used between autonomous
   systems in an AS Confederation [RFC5065].

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

'MUST' is the correct usage in describing the procedures. We are saying that they are not applicable for Confederations.

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

There is no updating. There is only a step of adding OTC on ingress if it is not present on the received route.

>§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)

Do you wish you clarify further what you are asking about? Suggest how you would word it?

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

Please see the explanation of the procedure above. The local AS simply checks if the ASN in the OTC from a Peer (lateral peer) is the Peer's ASN or some other value. This is done to detect a route leak and applies only in the case of a Peer.

Sriram / Alexander

---

From: <[email-masked]>
Date: Mon, 7 Feb 2022 14:03:06 +0000

Hi Sriram,

Thanks for your responses. Please see inline [Bruno]

Orange Restricted
From: Sriram, Kotikalapudi (Fed) <[email-masked]>

Hi Bruno,

[Bruno] Ah... I finally found the reason for our/my misunderstanding. I understood "Peer" as "peer". While the former is "Peer-role" and the later is RFC4271's peer (the remote end of the BGP session). With that in mind, I agree with the text in the draft. However, in this specific sentence, I would suggest to help the reader see the difference. E.g. :s/received from a Peer/received from a Peer role.  (subject to English language correctness). I would even suggest to replace all "Peer" by "Peer role" as even if we are not responsible for the term to be already overloaded, we are responsible for the text of this RFC-to-be too be clear and non-ambiguous.

You're right. Fixed.

NEW text:

[Bruno] I would suggest to refer to IANA names or numbers for the AFI and SAFI. .e.g :s/ unicast IPv4 and IPv6 address families/SAFI 1 (unicast) and AFI 1(IPv4) or 2(IPv6).
More specifically I'm questioning the applicability (by default) to SAFI 4 (which is also IP unicast): in general SAFI 4 is used for Infrastructure MPLS route which is not subject to the Gao-Rexford model. However, when 6PE is used (RFC4798) such routes are Internet ones and hence subject to the Gao-Rexford model. All in all, I would suggest to keep SAFI 4 not applicable by default (in particular because I would expect 6PE to be a transient solution)

[Bruno] I'm not sure to see what you are trying to say with the quoted sentence. It looks to me that checking the AS number and making the route eligible in response is a "special handling of incorrect AS numbers in the OTC attribute". But no big deal, as it's a non-normative sentence. (On a side note, may be "AS numbers" should be singular in "AS numbers in the OTC Attribute" but I'll leave the English language to you.

Thank you,
Bruno

Thanks

Sriram / Alexander

_________________________________________________________________________________________________________________________

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.

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 7 Feb 2022 08:22:11 -0800

On February 5, 2022 at 12:08:08 PM, Sriram, Kotikalapudi wrote:

Sriram:

Hi!

...
> > consider it to be a single BGP Role Capability and proceed [RFC5492]."
> >
> >Presumably :s/must/MUST
>
> You’re right. Fixed.

rfc5492 already requires the behavior, so there's no need to specify
it here again.  IOW, the behavior is as already specified.

   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.

Perhaps: s/then the speaker must consider it to be a single BGP Role
Capability and proceed [RFC5492]./then the speaker considers
them...proceeds [RFC5492].

Thanks!

Alvaro.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 7 Feb 2022 20:50:30 +0000

Hi Alvaro,

>rfc5492 already requires the behavior, so there's no need to specify it here again.  IOW, the behavior is as already specified.

Thanks for reminding me about it. I guess that was the reason we were using a lower case ‘must’.  So yes, now the following substitution is made in the draft following your suggestion:

s/then the speaker must consider it to be a single BGP Role Capability and proceed [RFC5492]./then the speaker considers them to be a single BGP Role Capability and proceeds [RFC5492]./

Sriram

-----Original Message-----
From: Alvaro Retana <[email-masked]>
Sent: Monday, February 7, 2022 11:22 AM
To: [email-masked]; Sriram, Kotikalapudi (Fed) <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: draft-ietf-idr-bgp-open-policy

Sriram:

Hi!

...
> >consider it to be a single BGP Role Capability and proceed [RFC5492]."

rfc5492 already requires the behavior, so there's no need to specify it here again.  IOW, the behavior is as already specified.

Perhaps: s/then the speaker must consider it to be a single BGP Role Capability and proceed [RFC5492]./then the speaker considers them...proceeds [RFC5492].

Thanks!

Alvaro.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 8 Feb 2022 14:28:15 +0000

Hi Bruno,

Responses marked with [KS:] below.

>[Bruno] Ah... I finally found the reason for our/my misunderstanding. I understood "Peer" as "peer". While the former is "Peer-role" and the later is RFC4271's peer (the remote end of the BGP sessio…

[KS:] Provider, Customer, Peer, etc. are clearly defined in Section 2.1 (Terminology). But still, the following change has been made in the paragraph before the list of procedures. We now include a backward reference to Section 2.1.

OLD text:
.... 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.

NEW text:
.... The purpose of this attribute is to enforce that
   once a route is sent to a Customer, Peer, or RS-Client (see
   definitions in Section 2.1), it will subsequently go only to
   Customers.

> [Bruno] I would suggest to refer to IANA names or numbers for the AFI and SAFI. .e.g :s/ unicast IPv4 and IPv6 address families/SAFI 1 (unicast) and AFI 1(IPv4) or 2(IPv6). More specifically I'm questioning the applicability (by default) to SAFI 4 (which is also IP unicast): in general SAFI 4 is used for Infrastructure MPLS route which is not subject to the Gao-Rexford model. However, when 6PE is used (RFC4798) such routes are Internet ones and hence subject to the Gao-Rexford model. All in all, I would suggest to keep SAFI 4 not applicable by default (in particular because I would expect 6PE to be a transient solution)

[KS:] The following change has been made:

OLD text:
   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.

NEW text:
   The described ingress and egress procedures are applicable only for
   the address families AFI 1 (IPv4) and AFI 2 (IPv6) with SAFI 1
   (unicast) in both cases and MUST NOT be applied to other address
   families by default.

> [Bruno] I'm not sure to see what you are trying to say with the quoted sentence. It looks to me that checking the AS number and making the route eligible in response is a "special handling of incor…

[KS:] The following change has been made:

OLD text:
.... Further, this document does not specify any
   special handling of incorrect AS numbers in the OTC Attribute.

NEW text:
.... Further, this document does not specify any
   special handling of an incorrect AS number in the OTC Attribute.

Thank you.

Sriram

---

From: <[email-masked]>
Date: Wed, 9 Feb 2022 10:55:46 +0000

Hi Sriram,

Thanks.
Looks good. I point inline [Bruno2]

Orange Restricted
From: Sriram, Kotikalapudi (Fed) <[email-masked]>
Sent: Tuesday, February 8, 2022 3:28 PM

Hi Bruno,

OLD text:

NEW text:

[Bruno2] I still believe that in the specification "Peer" and "peer" are too close to avoid ambiguities and possible bugs.

I would suggest to:

-        Either change the name of the Role "Peer" to "Lateral Peer" (which is already part of its official naming. So the change would be :s/Peer (i.e., Lateral Peer) /Lateral Peer )

-       or to add that "Peer" refers to the role (:s/is received from a Peer/is received from a Remote AS Role Peer)

Thanks,

Regards,

--Bruno

OLD text:

NEW text:

OLD text:

NEW text:

Thank you.

Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 10 Feb 2022 01:25:25 +0000

Hi Bruno,

This seems good?

2.  If a route with the OTC Attribute is received from a Peer (i.e.,
       remote AS with a Peer Role) 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.

Sriram

From: [email-masked] <[email-masked]>
Sent: Wednesday, February 9, 2022 5:56 AM
To: Sriram, Kotikalapudi (Fed) <[email-masked]>; [email-masked]; [email-masked]; Susan Hares <[email-masked]>
Cc: 'Alvaro Retana' <[email-masked]>
Subject: RE: draft-ietf-idr-bgp-open-policy

Hi Sriram,

Thanks.

Orange Restricted
From: Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 8, 2022 3:28 PM

Hi Bruno,

OLD text:

NEW text:

I would suggest to:

Thanks,

Regards,

--Bruno

OLD text:

NEW text:

OLD text:

NEW text:

Thank you.

Sriram

Thank you.

---

From: <[email-masked]>
Date: Thu, 10 Feb 2022 20:07:16 +0000

Hi Sriram,

Please see inline [Bruno3]

Orange Restricted
From: Sriram, Kotikalapudi (Fed) <[email-masked]>
Sent: Thursday, February 10, 2022 2:25 AM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]; [email-masked]; Susan Hares <[email-masked]>
Cc: 'Alvaro Retana' <[email-masked]>
Subject: RE: draft-ietf-idr-bgp-open-policy

Hi Bruno,

This seems good?

[Bruno3] Looks good to me.

Thank you
--Bruno

Sriram

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 9, 2022 5:56 AM
To: Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: 'Alvaro Retana' <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-ietf-idr-bgp-open-policy

Hi Sriram,

Thanks.

Orange Restricted

Hi Bruno,

OLD text:

NEW text:

I would suggest to:

Thanks,

Regards,

--Bruno

OLD text:

NEW text:

OLD text:

NEW text:

Thank you.

Sriram

Thank you.