Re: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

Donald Eastlake <> Wed, 28 July 2021 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10E173A212C for <>; Wed, 28 Jul 2021 14:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 7PHpFCeSTHSy for <>; Wed, 28 Jul 2021 14:21:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78BD43A2135 for <>; Wed, 28 Jul 2021 14:21:53 -0700 (PDT)
Received: by with SMTP id j18so699998ile.8 for <>; Wed, 28 Jul 2021 14:21:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w4tftIUZEvwoeG2Ylf8RI0w1z2o1sdxntbzTIc5naLc=; b=A60gZPVXufi3+SAxvAFqYaKaBwUg2R6nvjWeidIKwX9LbK+s+je9Z51gMiT6j6BUAi xmIH2Fh1+hws+IsvXeN/2obwG7U2Lyvg1Cd31KgicX8DdMMa5Zleo+NKFLhBWXpumuLu f+iJZ3N5YdJg4JvjyqF6yjOY09K8SPAzlO8NqLPn1I9n4ws3D8di0NBpHt3VFnuq25dU loKRXCqxNfS8U84mwIwxeuaKngf4Pmjt0ZlqSiNuqsWfIIiv9YO+JLTfbXbjC8kmXGKC HJ39RFqK3SU4nxjfcdIrboBrnsNoe4or8GoqsMVT4R2u5EnEuhS/ZZfGrEtVSyRWHNmz UioQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w4tftIUZEvwoeG2Ylf8RI0w1z2o1sdxntbzTIc5naLc=; b=Cd9kbZNy6O/u1UjlRRtpd/6LjIJtMYXlsIF3JxfaO+MZ5cbz2hIz9PjphhYB4bwuPi bNybVNjnNctU46gCrsMYRpTaZn7f4AsTzTzRUJ1ceDLqlbH7KHW72jc01T+5+f4v8n1R fo+/f0fmAUD/MEX2em8ZvM81Cwv8zQGALS9Hb6D41c64wPoJNXmRnFXWh/LD+NTMIgEi fviMBcx+78VcwNGEF1TAXzFujbhx70Zw0i1vsOsFgf3Yjs4+APqjgzhkFXhfmcVLAx/I 9qw8Zblu0e1s/RTPcGmbeX8vmY/dX/Jwx3rIbfqwpmC4a3VcYASj4ZvtYRaCpCaSMd8r gF6Q==
X-Gm-Message-State: AOAM530o/nKjSp7V/A8QzFxtAibGuww/eWKAKjwjy/gD3/5qAKOHZrDz CClvRqAirPdXxcKGA+ADR0VynglyPSppxccLcKm7kCLnb6k=
X-Google-Smtp-Source: ABdhPJzzA+bnixCtnoc0GNCO9nz+vQ9Sp+G90qxQeFGQIe7ZUnL3Vf46EHo+eoM+26ueQktWkEeP/0Z1GxmuTJG8sKI=
X-Received: by 2002:a05:6e02:1154:: with SMTP id o20mr1230446ill.168.1627507310357; Wed, 28 Jul 2021 14:21:50 -0700 (PDT)
MIME-Version: 1.0
References: <025001d77fe7$64d93b50$2e8bb1f0$>
In-Reply-To: <025001d77fe7$64d93b50$2e8bb1f0$>
From: Donald Eastlake <>
Date: Wed, 28 Jul 2021 17:21:39 -0400
Message-ID: <>
To: Susan Hares <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)
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, 28 Jul 2021 21:21:58 -0000

I support this draft and believe it is useful. However, I think the
wording in the specification of the IP prefix sub-TLV needs to be
clarified. See below for my comments on that wording and on a few
other minor points.

Section 4.1:

On the Distinguisher, to avoid ambiguity on what lower/smaller and
higher/larger mean I suggest
"4 octet value" -> "4 octet unsigned integer that"


Section 4.2.1:

I found the specification of the IP prefix sub-TLV confusing. The
document says that the "Mask" field is "1 octet for mask length". That
combined with the first example makes it reasonably clear that the
M-Type=0 is an exact match on the "Mask" number of prefix bits in the
IP address given in the sub-TLV with the IP address being tested.
Assuming my interpretation is correct and following the usual IETF
convention, where unused fields are sent as zero and ignored on
receipt, my first suggested changes are as follows:
   M-Type:  4 bits for match types, four of which are defined:

      M-Type = 0:  Exact match.
   M-Type:  4-bit field specifying match type. The following four
values are defined:

      M-Type = 0:  Exact match with the Mask length IP address prefix.
GeMask and LeMask MUST be sent as zero and ignored on receipt.
   Mask:  1 octet for the mask length.
   Mask:  1 octet for the IP address prefix length.

M-Type=1 is considerably more confusing. We now have, I assume, two
prefix lengths: Mask and GeMask. And we have two IP addresses, the
sub-TLV IP address and the IP address being tested. I cannot figure
out from the draft which mask is applied to which IP address and
exactly what "greater than" comparison is being made. The terse
example does not help me. The same comments apply to M-Type=2.
M-Type=3 is even more complex; there are 3 masks, two IP addresses,
and, presumably, two comparisons... I think the text here should be
made clearer and more explicit

Section 9.1:

Delete all occurrences of the word "new". Drafts should use the
wording desired in the final RFC. These values are not "new" anymore.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA

On Fri, Jul 23, 2021 at 1:23 PM Susan Hares <> wrote:
> This begins a 2 week WG last call on draft-ietf-idr-rpd-11.txt.
> There is one missing IPR statement from Liang Ou.
> Liang should send the IPR statements in response to this WG LC.
> The implementation report is at:
> The two implementations are different implementations from Huawei.
> This document describes BGP Extensions for Routing
>    Policy Distribution (BGP RPD) to support this.
> Please consider in your review of this draft:
> 1) if this draft is ready for deployment,
> 2) if the BGP extensions for routing policy distribution
> Help deployments of BGP in the Internet.
> Cheerily, Susan Hares
> _______________________________________________
> Idr mailing list