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

[Jeffrey Haas <[e-mail]>]

Sriram,

On Wed, Mar 02, 2022 at 01:30:07AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> 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].

This seems reasonable.

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