Subject: Re: [Idr] IDR Chairs consensus for draft-ietf-idr-bgp-open-policy

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 2 Mar 2022 01:30:07 +0000

Jeff,

>Open-Policy Authors,
>...
>It is our conclusion that the error handling procedures should revert to the
>original "treat-as-withdraw" behavior that we started this discussion with.
>We'd like to request you to revert your text to treat-as-withdraw.

Thank you. Per your advice, we'll update v-22 and upload v-23. It will replace the two paragraphs related to the OTC length error in v-22 with the paragraph from v-21 with the following editorial change:

OLD text (from v-21):

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

NEW text (to be included in v-23):

   The OTC Attribute is considered malformed if the length value is not 4.
   An UPDATE message with a malformed OTC Attribute SHALL be handled
   using the approach of "treat-as-withdraw" [RFC7606].

>...
>If you believe citing the possible dangers of forwarding loops is necessary,
>please do so by reference to the text in RFC 7606 without attempts to restate it.
>We've found errors tend to creep into specifications when normative text is
>summarized.

We'll add the following new text as the last paragraph in Section 5 (Additional Considerations):

NEW text:

   Section 6 of [RFC7606] mentions the possibility of forwarding loops
   with "treat-as-withdraw" error-handling in iBGP.  With the use of
   this error-handling approach for the OTC Attribute, the possibility
   of forwarding loops in iBGP arises if the following conditions
   concur: (1) the length value in the OTC Attribute is in error (i.e.,
   not 4) and the OTC value also has the same erroneous number of
   octets, (2) the AS in consideration has a partial deployment (some
   routers have not been upgraded to do OTC), and (3) the iBGP topology
   and the data links between routers in the AS do not match (data
   tunneling is not used to avoid the mismatch).  To prevent/
   troubleshoot forwarding loops, the user is referred to the advice
   offered in Section 6 of [RFC7606].

I'll give it a couple of days to see if there are any comments on the wording. Then the upload of v-23 will follow.

Sriram

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 1 Mar 2022 20:38:36 -0500

Sriram: 

Alvaro does not return until next week.   You will not hear from him until
that point. 

Sue 

-----Original Message-----
From: Sriram, Kotikalapudi (Fed) [mailto:[email-masked]] 
Sent: Tuesday, March 1, 2022 8:30 PM
To: Jeff Haas
Cc: Susan Hares; Alvaro Retana; [email-masked];
[email-masked]
Subject: Re: [Idr] IDR Chairs consensus for draft-ietf-idr-bgp-open-policy

Jeff,

>Open-Policy Authors,
>...
>It is our conclusion that the error handling procedures should revert 
>to the original "treat-as-withdraw" behavior that we started this
discussion with.
>We'd like to request you to revert your text to treat-as-withdraw.

Thank you. Per your advice, we'll update v-22 and upload v-23. It will
replace the two paragraphs related to the OTC length error in v-22 with the
paragraph from v-21 with the following editorial change:

OLD text (from v-21):

>...
>If you believe citing the possible dangers of forwarding loops is 
>necessary, please do so by reference to the text in RFC 7606 without
attempts to restate it.
>We've found errors tend to creep into specifications when normative 
>text is summarized.

We'll add the following new text as the last paragraph in Section 5
(Additional Considerations):

NEW text:

I'll give it a couple of days to see if there are any comments on the
wording. Then the upload of v-23 will follow.

Sriram

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 2 Mar 2022 07:28:03 -0500

Sriram,

>    using the approach of "treat-as-withdraw" [RFC7606].

This seems reasonable.

>    offered in Section 6 of [RFC7606].

I'd suggest keeping it simple.  Different suggestion:

"Section 6 of [RFC7606] documents possible negative impacts of
"treat-as-withdraw" behavior.  Such negative impacts may include forwarding
loops or blackholes.  It also discusses debugging considerations related to
this behavior."

Don't try to re-state how we get into the situation or try to constrain
circumstances that you think this may happen.  As an example, any
circumstance where the route gets treat-as-withdraw during iBGP can cause
this issue.  Using some of Bruno's discussion about multiple faults as an
example, if a malformed attribute sneaks past an implementation that does
open-policy on eBGP, the fault exists at that device but the penalty happens
in the rest of the network.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 2 Mar 2022 07:32:09 -0500

Sriram: 

Jeff is correct about limiting the conditions in section 6.    It is better
to point to the RFC7606 for this mechanism draft.  You will miss some
constraint. 

If you feel people need to have additional warnings, you can write an
informational draft and provide the cases. 

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Wednesday, March 2, 2022 7:28 AM
To: Sriram, Kotikalapudi (Fed)
Cc: Susan Hares; Alvaro Retana; [email-masked];
[email-masked]

Sriram,

This seems reasonable.

attempts to restate it.

-- Jeff

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 2 Mar 2022 14:50:08 +0000

Sue, Jeff:

No problem. Suggestion accepted. Thank you.

The simple wording offered by Jeff is also acceptable to me. 

I can wait till Alvaro is back next week before I upload the new version. 

Sriram 

-----Original Message-----
From: Susan Hares <[email-masked]> 
Sent: Wednesday, March 2, 2022 7:32 AM
To: 'Jeffrey Haas' <[email-masked]>; Sriram, Kotikalapudi (Fed) <[email-masked]>
Cc: 'Alvaro Retana' <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Idr] IDR Chairs consensus for draft-ietf-idr-bgp-open-policy

Sriram: 

Jeff is correct about limiting the conditions in section 6.    It is better
to point to the RFC7606 for this mechanism draft.  You will miss some constraint. 

If you feel people need to have additional warnings, you can write an informational draft and provide the cases. 

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Wednesday, March 2, 2022 7:28 AM
To: Sriram, Kotikalapudi (Fed)
Cc: Susan Hares; Alvaro Retana; [email-masked];
[email-masked]

Sriram,

This seems reasonable.

attempts to restate it.

"Section 6 of [RFC7606] documents possible negative impacts of "treat-as-withdraw" behavior.  Such negative impacts may include forwarding loops or blackholes.  It also discusses debugging considerations related to this behavior."

Don't try to re-state how we get into the situation or try to constrain circumstances that you think this may happen.  As an example, any circumstance where the route gets treat-as-withdraw during iBGP can cause this issue.  Using some of Bruno's discussion about multiple faults as an example, if a malformed attribute sneaks past an implementation that does open-policy on eBGP, the fault exists at that device but the penalty happens in the rest of the network.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 2 Mar 2022 10:05:28 -0500

Sriram: 

May I suggest you upload it this week.  The draft cutoff occurs on Monday.

If Alvaro wants to tweak it, he has the power to get it uploaded during the
blackout period. 

Sue 
Your friendly IDR shepherd 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Sriram, Kotikalapudi
(Fed)
Sent: Wednesday, March 2, 2022 9:50 AM
To: Susan Hares; 'Jeffrey Haas'
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] IDR Chairs consensus for draft-ietf-idr-bgp-open-policy

Sue, Jeff:

Sriram 

-----Original Message-----
From: Susan Hares <[email-masked]>
Sent: Wednesday, March 2, 2022 7:32 AM
To: 'Jeffrey Haas' <[email-masked]>; Sriram, Kotikalapudi (Fed)
<[email-masked]>
Cc: 'Alvaro Retana' <[email-masked]>;
[email-masked]; [email-masked]
Subject: RE: [Idr] IDR Chairs consensus for draft-ietf-idr-bgp-open-policy

Sriram: 

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Wednesday, March 2, 2022 7:28 AM
To: Sriram, Kotikalapudi (Fed)
Cc: Susan Hares; Alvaro Retana; [email-masked];
[email-masked]

Sriram,

This seems reasonable.

attempts to restate it.

-- Jeff

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

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 4 Mar 2022 00:28:59 +0000

Sue,

>May I suggest you upload it this week.  The draft cutoff occurs on Monday.

Done!

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-23

Thank you.

Sriram
--------------------------

-----Original Message-----
From: Susan Hares <[email-masked]> 
Sent: Wednesday, March 2, 2022 10:05 AM

Sriram: 

If Alvaro wants to tweak it, he has the power to get it uploaded during the blackout period. 

Sue