Re: [RTG-DIR] [Idr] Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21

Donald Eastlake <> Thu, 14 June 2018 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30AC4130E7E; Thu, 14 Jun 2018 11:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Urhur1nrHAfn; Thu, 14 Jun 2018 11:35:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 116D4130E1D; Thu, 14 Jun 2018 11:35:59 -0700 (PDT)
Received: by with SMTP id u4-v6so9633367itg.0; Thu, 14 Jun 2018 11:35:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JCQvtRNZT/dpN1hqLPrmBktOdRsMcJdNJ/8XuPGNsT0=; b=YVePtZWxcxoW6ifjsEXNxgX2Viq/e5c3HKNUVh5CLCdBo8ebqv1hrgJlxYmT2jUyJa Pi4mPmsPsmatAJINRc4ouqgDcZXno3GZp0NsaWdEjKLlDjzbG5MxfUH0AaKCA9Tgv97a Hustbvv3mzqmYCoCBt50hLOvZWaPoCYRGoruhYXy+IYpj4yG2ezlWTztMmX5k/G7ZzEg t2z2i43NRFRitvuIT4DU14njM9kGDyBJZZSxfcWD7jEC9xsnUH/EK3n9frqUbbzqeY7I 0xuquciLnJAZw6+kOfBGedrStu11OmjEgjR1HuGBK5p+i3TEgfiQlZdi+KGscg3/1iOJ TwPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JCQvtRNZT/dpN1hqLPrmBktOdRsMcJdNJ/8XuPGNsT0=; b=NJhBR8q7Nk8lUd6Jx27qzKU/ivM3LLIY8siqQWuG3x0vLG1QauHInNmEY8aviwpLOj K7DBp5FfLDLu2RgAcg5JGZ4lGTJGOx6tbc9G2v0x5jpx5YI/f7B/7qm9qUTHDcSAweZL HO2nuwcD7fCsrCXeaAXNP7bqRjySyj+a90L5lUs3P8CBLdyroaZ8ejPn0p+T1uh3IhWu BMTH0iQ+Utceqf3sR4G9TsvMt0A0v86aGIqm6yKwxG2stCH+7aoIkJiYUj30gHaSOW/4 AwGP8KFuLOPYLMNdRT/5rgNLjQz/tVaaBciPXjK4/dQ7KRLgT4RjaJB/pTL056YzroHs FTZA==
X-Gm-Message-State: APt69E106JWEeb6bt99klWG41MPlMU6zdK7TM9s/lCnfmYvO+20Ft47i m6Jro7cJK+IdMyZRKJlZNKhekyeUw73IVUgYzv0=
X-Google-Smtp-Source: ADUXVKIn0mdQQ0N/lxiiOnGTLkDrT6ITSHwCYQwFnbsmXva5ixe+fX6h4PnzUU1ebjvu7rP68WeLxCrKFRtz3Eo0H0A=
X-Received: by 2002:a24:284a:: with SMTP id h71-v6mr3258974ith.105.1529001358325; Thu, 14 Jun 2018 11:35:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 11:35:42 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Thu, 14 Jun 2018 14:35:42 -0400
Message-ID: <>
To: "Acee Lindem (acee)" <>, Bruno Decraene <>
Cc: "" <>, "" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [RTG-DIR] [Idr] Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Jun 2018 18:36:03 -0000


See below

On Wed, Jun 13, 2018 at 9:02 PM, Acee Lindem (acee)
<> wrote:
> Hi Bruno,
> Thanks for your review - you’ve raised some heretofore undetected ambiguities that need to be rectified. I've taken most of your comments. I plan to publish an update including all the comments that I've incorporated (tonight or tomorrow morning).
> See replies inline.
> On 6/13/18, 1:53 PM, "Bruno Decraene" <> wrote:
>     Reviewer: Bruno Decraene
>     Review result: Has Nits
>     ...
>     ==========================
>     Major Issues:
>     § IANA consideration
>        "This document also requests creation of the "BGP Prefix-SID Label-
>        Index TLV Flags" registry under the "Border Gateway Protocol (BGP)
>        Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid.
>        Initially, this 16 bit flags registry will be empty.  Flag bits will
>        be allocated First Come First Served (FCFS) consistent with the BGP-
>        SID TLV Types registry."
>     IMHO a registry of only 16 possible entries seems very small for a FCFS policy.
>     Anyone would be able to deplete it in minutes. (cf RFC 8126 "It is also
>     important to understand that First Come First Served really has no
>     filtering."). Is this really the intention of the WG? (Actually I'm wondering
>     what would be the monetary value of such a flag on the black market... If zero,
>     this means that the flag are useless. If non-zero, the benefit may be worth the
>     trouble)
>     Same comment for the "BGP Prefix-SID Originator SRGB TLV Flags" registry.
> I don't believe we need to consider attacks on the FCFS registries. You've got to believe that IANA will only consider legitimate requests. If not, it seems the whole concept of FCFS is flawed.

While I greatly respect IANA and the quality of service they provide,
the main idea of the transition of authority for protocol parameters
from John Postel ( aka "King John") to IANA was to make the IANA task
as objective and clerical as possible, deferring all required
judgements to experts or standards actions or whatever as specified in
the registry in question. The theory that "IANA will only consider
legitimate requests" implies, unless "legitimate request" is
specifically defined in this draft (which pretty much negates FCFS),
judgements that IANA is not contracted for and not supposed to be

I have a lot of sympathy for the view that the concept of FCFS is
flawed and should almost always be Expert Review instead. But, there
are some cases of essentially infinite values available (e.g., a
multi-precision integer parameters or lengthy string values). And, in
any case, where a registry has tens of thousands of values that are
usually allocated one or a few at a time, there is one saving
paragraph in RFC 8126 as follows:

   IANA always has the discretion to ask the IESG for advice or
   intervention when they feel it is needed, such as in cases where
   policies or procedures are unclear to them, where they encounter
   issues or questions they are unable to resolve, or where registration
   requests or patterns of requests appear to be unusual or abusive.

But I think it is unwise to depend on this. Note that IANA has NO
authority to refuse a registration for FCFS, they could only delay
responding and refer it to the IESG if they happen to notice it as
being suspicious. And I don't know if there has ever been a case where
IANA has done this. As it says in RFC 8126:

   It is also important to understand that First Come First Served
   really has no filtering.  Essentially, any well-formed request is

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

>     ...
> Thanks,
> Acee