Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Alvaro Retana <> Wed, 23 September 2020 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BF8D3A151E; Wed, 23 Sep 2020 14:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OMS69KmUt_Kl; Wed, 23 Sep 2020 14:37:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 168DC3A151C; Wed, 23 Sep 2020 14:37:08 -0700 (PDT)
Received: by with SMTP id r7so1581035ejs.11; Wed, 23 Sep 2020 14:37:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=UxokFefXKmEUC4SID92QmWC6uSCspps5/vqiWyzDIU4=; b=FtauTv60/TSNiKdThO6ZNRyGoLbaamoIWWoCnl3SEX8VrPhg9Hg8+9wyl/KFI3jR4z B3jnAPsGrztdSsQiEw9Cn+4nQzJxWkw3kZi2Rq42WlCbriGytGuXpVyHvmQ7sakUFfo9 bX5sXNmWtLTy10aowkY9DW6Vz4U+gYCr0+wcVQDa9C0CKlSA3dsEi3k0tTr1tVtgVSCc 9zepR4x68p0GqIHlejWfxe37fxu1DlVsPzirdzjtoi9IM0aF8BRvperwBFyJvikg6WXd iY74ITJE1Wx2gEZYS4o1fEoKL01HWhrhAJySNyClqDaXbpwihuBOqPChs6iiCypvWhf2 jghA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=UxokFefXKmEUC4SID92QmWC6uSCspps5/vqiWyzDIU4=; b=BJXXjZ+b030VWd/g7K52KplacIGhn4a+MpVhh0Iy0CjtgVqAI7ApqTY/8tMKgQzejx emoAEMRKZfTr9+zwCIfuPjrnMdOdPLiqc2QKSwLHZq7ZomQ+DtaLuPIlPFqMYVQGjNoP hTuwDd8oLNJCDx8ciqQyMQccSmmRt9r7z/2d56X/BCZLsB+lI7/td65IMTXPqq3FBtzM lB0ZpRBRqnyhWUG9JZsmPs8ZrTV7Gq+7JaITH4KdM2p4JJxX1SvXTQr7nIsIRQlV1dKm bJkVBCg9wo36R5wWVNiqoZ8Yc6A5I46fmqZSl11x+/negrpKX2JkvnyDn4qQuSlkvzgz fmmw==
X-Gm-Message-State: AOAM532N6Ay83NuU9PqsGGfbVZxCicK7x62KPpcCV9Nkly8gexof6hi4 iSJuUVClpOnwBFs1oXcsDxejxNpYnL1VdvA7eJom3iCd
X-Google-Smtp-Source: ABdhPJwuTtMB7/J2LzVLNjMMuHCf1pxTwdlQEhnJ6H3wGbLmAqjTgFkww1OetNOlx13vIhdGd35Y+gSgSD8em2kiHUE=
X-Received: by 2002:a17:906:c0c4:: with SMTP id bn4mr1575182ejb.27.1600897026576; Wed, 23 Sep 2020 14:37:06 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 23 Sep 2020 17:37:06 -0400
From: Alvaro Retana <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Date: Wed, 23 Sep 2020 17:37:06 -0400
Message-ID: <>
To: John Scudder <>, "idr@ietf. org" <>
Cc: "Dongjie (Jimmy)" <>, Hares Susan <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000097572305b001e21c"
Archived-At: <>
Subject: Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Sep 2020 21:37:10 -0000



Personal opinion:  I believe that the “specified here” part (meaning this
document) is already covering the unknown case.  However, I have no
objections to adding the phrase in.



On September 23, 2020 at 5:14:50 PM, John Scudder ( wrote:

Hi All,

I’m a little concerned about a change I failed to notice earlier in
5575bis. Version 17 had this paragraph in Section 4.2:

   All combinations of component types within a single NLRI are allowed,
   even if the combination makes no sense from a semantical perspective.
   *If a given component type within a prefix in unknown, the prefix in*
   *question cannot be used for traffic filtering* purposes by the
   receiver.  Since a Flow Specification has the semantics of a logical
   AND of all components, if a component is FALSE, by definition it
   cannot be applied.  However, for the purposes of BGP route
   propagation, this prefix should still be transmitted since BGP route
   distribution is independent on NLRI semantics.

Version 18 removed the paragraph. I believe it was removed because of good
and reasonable concerns about the “prefix should still be transmitted”
part. But, it appears we threw out the baby with the bathwater: the final
version of the draft has nothing that corresponds to the underlined part.
It is underspecified with respect to what should be done with unknown
component types. The closest it comes is this paragraph in Section 4.2 of
version 26:

   A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10
is performed.

But I think this falls well short of being either clear or unambiguous,
because what does “as specified here” mean exactly?

I’d like to open a discussion of whether the WG agrees that this is a bug
and if so, whether it’s concerning enough to request a last-minute patch to
the document, which is currently with the RFC Editor, so it’s almost an
RFC. I think the least intrusive fix would be to insert the clause
“including an NLRI that contains an unknown component type”, as in:

   A NLRI value not encoded as specified here,

   including an NLRI that contains an unknown component type,

   is considered
   malformed and error handling according to Section 10
is performed.

Just as a side note, “error handling according to Section 10” points us to
RFCs 7606 and 4760, which end up telling us to reset the session if the
NLRI is malformed.

Until we get a chance to discuss this, I’ve sent a note to the RFC Editor
asking them to hold publication.



P.S.: The version 26 text also has a proofreading error, “specified
specified”. But I assume the RFC Editor would fix that anyway.