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

Alvaro Retana <> Mon, 28 September 2020 19:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79CAD3A137A; Mon, 28 Sep 2020 12:16:11 -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 lIaPLKZneUJl; Mon, 28 Sep 2020 12:16:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69E3D3A137B; Mon, 28 Sep 2020 12:16:09 -0700 (PDT)
Received: by with SMTP id l17so2877483edq.12; Mon, 28 Sep 2020 12:16:09 -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=Yd7u2+clfGu14kLc8SaJJ9KL306/VzCgC25Oo5OaROk=; b=rouc84iibvo7pMe0eGDuBQYIxs4Snxk1qSYthZ5J0RdC0W/GeRYnqYqnJ0xBD+2K9V HCSCIEQSDDxgjFbqIijjwr9pzXGiLkpfTaSmEyC6P/X1iyuf7lXvIlUjV5JFshWpQ3CH K0GRv/XjOlx4JyzlnkH9rhYkiG1aRkecQ7BRIyyAlxfDm+bziDibRHaBCDXq06M590mD ZOwSkk1KC5fzw3ttQXEFrvczX+dchy7qCpGe/6Z/J7aTAQk0RpMc9VCwFmtnDTnXmsDQ 0YaKWUegHxe8l87mqbx6Km0tpn8A5C8db1SEMz85XzEtTyA7s29np85n1p5gdEQVQASy Q2zQ==
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=Yd7u2+clfGu14kLc8SaJJ9KL306/VzCgC25Oo5OaROk=; b=S3tgC/7Zlu6Ldys/bD2gAX4IV7Fa4It9KLBaRZpNPtqNSR4FOcgTAYqrVctC75EFNc VZ/ozMaIfS4anKBFixjWeCneJhmMb97ChSQmwmgqwn+NzwjOdgr1evpNBPGek8UA/hDX x8ZT8ec1pK9AkLXj8NX5YsTExdL0Thn7sCHrT1RdFh2oW0mRoDtw1GLd+jg4mvtIpF57 L6XlbPWrFbrU5cvmgWtNidjG8kOIEo0PEmC94/V+yji7QMOr64ZvykMDfZzktOlVBz4S 0ZWA1q5td1lrvW9b7jqlEyqNEwpB3JvsJwCosDtrRulnl5/al1iR+xpgdtvq5pQ74mkI 04xA==
X-Gm-Message-State: AOAM530VbADr0vBlkYFw1fvCIT0cOuWUSaJKLTTQmK/NCziheRdGA8ub Wvz0WBrcgSZzvX8qrsVohyVq83ZB6KNYZAKFKHQ=
X-Google-Smtp-Source: ABdhPJxMce0f4Qq5zPebifREu3t94PTEdZRYkFXPys9LgMmeP2ogWaCz6aB7bzgENAjjlrpY4PhRMDh2WVddvweSh08=
X-Received: by 2002:aa7:cd5a:: with SMTP id v26mr3390637edw.38.1601320567945; Mon, 28 Sep 2020 12:16:07 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 28 Sep 2020 12:16:06 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <22341_1601052988_5F6E213C_22341_268_1_53C29892C857584299CBF5D05346208A48F82C17@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <3366_1601300732_5F71E8FC_3366_6_3_53C29892C857584299CBF5D05346208A48F86028@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <>
MIME-Version: 1.0
Date: Mon, 28 Sep 2020 12:16:06 -0700
Message-ID: <>
To: "" <>, John Scudder <>, Jeffrey Haas <>
Cc: Hares Susan <>, "idr@ietf. org" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000009fbdab05b0647f7e"
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: Mon, 28 Sep 2020 19:16:12 -0000

[Explicitly adding Jeff to the To list.]


During my AD review there was a discussion on the list about this point,
and whether we could avoid resetting the session.  Jeff presented some
examples and, I think, made a very convincing case of why we really can’t:
even if we can look at the length, we would still be guessing.

I think this is one of the messages:

Jeff: if you get a chance, please chime in.



On September 28, 2020 at 2:16:38 PM, John Scudder ( wrote:

I think that is the right thing, too: FS uses T,V and not T,L,V for its
component types, the lengths are implicit. So, if my parser encounters an
unknown type code it is impossible for me to know how to skip over that
type code. At that point, parsing breaks down.
[Bruno] I had in mind the higher level of hierarchy:

   The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
   one or more 2-tuples of the form <length, NLRI value>.  It consists
   of a 1- or 2-octet length field followed by a variable-length NLRI
   value.  The length is expressed in octets.

                     |    length (0xnn or 0xfnnn)    |
                     |    NLRI value   (variable)    |

                Figure 1: Flow Specification NLRI for IPv4

At this level, assuming that the NLRI value is found semantically
incorrect, it seems to me that one could:
-          Skip this NLRI (thanks to the ‘length’ field) and continue with
the next NLRI
-          Read the ‘NLRI value’ as an opaque data, and treat this NLRI as
withdraw. (In the context of the discussion, this NLRI would never had been
accepted, so ‘treat-as-withdraw’  could even be replaced with ‘ignore’. But
I’m _*not*_ calling for this).
Hence it seems to me that treat-as-withdraw is technically possible.

Fair enough. It’s a little unfortunate that the draft contains this
ambiguity; in retrospect it would have been better to be explicit about the
error-handling strategy chosen rather than simply referencing RFC 7606.
Whether or not we want to respin the draft in order to clarify it, is a
question for the WG. If we were to make a change, it could potentially be
the addition of this sentence, in Section 10:

   Error handling according to [RFC7606
<>] and [RFC4760
<>] applies to this

   specification. *Notably, an NLRI that is found to be semantically*

   *incorrect (for example due to an unknown component type) MUST be*

   *handled using the “treat-as-withdraw” strategy (which in this case,*

   *it** must be noted, works out to be the same as skipping over the NLRI)**.	*