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

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 4 Feb 2022 05:21:33 +0000

Bruno, Ben, and all:

Based on the various inputs (John, you, others)…
please take a look at this new proposed wording for the draft. Does this work for you?

Old text:

   If an UPDATE is received with an OTC Attribute with a length
   different from 4 octets, then the UPDATE SHALL be considered
   malformed.  If malformed, the UPDATE message SHALL be handled using
   the approach of "treat-as-withdraw" [RFC7606].

Proposed new text:

   If an eBGP speaker receives an UPDATE with an OTC Attribute with a
   length different from 4 octets, then the UPDATE SHALL be considered
   malformed.  If malformed, the UPDATE message SHALL be handled using
   the approach of "treat-as-withdraw" [RFC7606].

   If an UPDATE with an OTC Attribute is received in iBGP, then a
   check on the OTC Attribute length MUST NOT be performed.  In
   other words, the Attribute or UPDATE SHALL NOT be considered
   malformed based on the specified length.  (Note: This avoids treat-
   as-withdraw error handling and prevents the possibility of long-lived
   forwarding loops (Section 6 in [RFC7606]) in iBGP.  It also avoids
   Attribute discard and hence route leak detection capability is not
   compromised in case the route is propagated to eBGP neighbors.  It
   accommodates the possibility that a length error detection may not be
   due to an actual error; instead, it may be due to an implementation
   error in the receiving iBGP router.)

Thanks.
Sriram

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 4 Feb 2022 04:45:05 -0800

Sriram:

Hi!

Just a couple of notes:

- "check on the OTC Attribute length MUST NOT be performed”   I think that
what you really want to say is what you mention in the next sentence: "SHALL
NOT be considered malformed based on the specified length”.   The point is
that we do want the iBGP speaker to check the length, we just don’t want it
to take an action if it’s not 4.   IOW, the “MUST NOT” part is not needed.

Also, these two requirements contradict themselves:  don’t check, and don’t
do anything (if the check didn’t result in what is expected).  Either you
require that the check is not done, or the check is done and the
requirement is not to take an action.

- “It accommodates the possibility...an implementation error in the
receiving iBGP router.”

This reads as if you’re making exceptions in case there’s a bug.  Please
take this last sentence out; I think the rest of the explanation is
enough.  Also, there’s no need for the parenthesis.

Thanks!

Alvaro.

On February 4, 2022 at 12:22:09 AM, Sriram, Kotikalapudi (Fed) (
kotikalapudi.sriram=[email-masked]) wrote:

Bruno, Ben, and all:

Based on the various inputs (John, you, others)…
please take a look at this new proposed wording for the draft. Does this
work for you?

Old text:

Proposed new text:

Thanks.
Sriram

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

---

From: <[email-masked]>
Date: Fri, 4 Feb 2022 15:33:33 +0000

Sriram,

Thanks.
This works for me as this solve the iBGP inconsistency issue.

On a side note, I'm still missing the benefit of checking the attribute length on eBGP (and even checking the AS number) but I can live with that behavior.

--Bruno

Orange Restricted
From: Alvaro Retana <[email-masked]>
Sent: Friday, February 4, 2022 1:45 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; Ben Maddison <[email-masked]>; Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked]>
Cc: Susan Hares <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] draft-ietf-idr-bgp-open-policy-20 - error handling

Sriram:

Hi!

Just a couple of notes:

- "check on the OTC Attribute length MUST NOT be performed"   I think that what you really want to say is what you mention in the next sentence: "SHALL NOT be considered malformed based on the specified length".   The point is that we do want the iBGP speaker to check the length, we just don't want it to take an action if it's not 4.   IOW, the "MUST NOT" part is not needed.

Also, these two requirements contradict themselves:  don't check, and don't do anything (if the check didn't result in what is expected).  Either you require that the check is not done, or the check is done and the requirement is not to take an action.

- "It accommodates the possibility...an implementation error in the receiving iBGP router."

This reads as if you're making exceptions in case there's a bug.  Please take this last sentence out; I think the rest of the explanation is enough.  Also, there's no need for the parenthesis.

Thanks!

Alvaro.

On February 4, 2022 at 12:22:09 AM, Sriram, Kotikalapudi (Fed) (kotikalapudi.sriram=[email-masked]<mailto:kotikalapudi.sriram=[email-masked]>) wrote:
Bruno, Ben, and all:

Based on the various inputs (John, you, others)...
please take a look at this new proposed wording for the draft. Does this work for you?

Old text:

Proposed new text:

Thanks.
Sriram

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

_________________________________________________________________________________________________________________________

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: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 4 Feb 2022 19:30:41 +0000

Hi Alvaro,

Thank you. The revised paragraph with your suggestions incorporated reads as follows:

   If an UPDATE with an OTC Attribute is received in iBGP, then the
   Attribute or UPDATE SHALL NOT be considered malformed based on the
   specified length.  This avoids treat-as-withdraw error handling and
   prevents the possibility of long-lived forwarding loops in iBGP
   (Section 6 in [RFC7606]).  It also avoids Attribute discard and hence
   route leak detection capability is not compromised in case the route
   is propagated to eBGP neighbors.

Sriram

From: Alvaro Retana <[email-masked]>
Sent: Friday, February 4, 2022 7:45 AM
To: [email-masked]; Ben Maddison <[email-masked]>; Sriram, Kotikalapudi (Fed) <[email-masked]>
Cc: Susan Hares <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] draft-ietf-idr-bgp-open-policy-20 - error handling

Sriram:

Hi!

Just a couple of notes:

Thanks!

Alvaro.

Old text:

Proposed new text:

Thanks.
Sriram