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

"Acee Lindem (acee)" <> Thu, 14 June 2018 20:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7228B130E8E; Thu, 14 Jun 2018 13:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c7v4qMl6WK6W; Thu, 14 Jun 2018 13:27:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7ADB3130E70; Thu, 14 Jun 2018 13:27:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6376; q=dns/txt; s=iport; t=1529008066; x=1530217666; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3I6sEnKk7BinKGReYEbYyo7qRzLggJ3Jc+/EuccT57c=; b=MSHaBiWVSFSEx837KI/YPfXLHk972cZ4kpZftXu0OVzQDBGCHxxSDoRf orQcXWJgmnksJbKWRIJx3LXt+M/xUNW9cgRRXpRC910Cb6Nw885tIHoZc XC/sN8prlXoTjv+zDQof6PBaUWj35S326/LlOVmGjoAq65TUgaROkkaD/ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.51,224,1526342400"; d="scan'208";a="407279223"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2018 20:27:26 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w5EKRPXo021629 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jun 2018 20:27:26 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Jun 2018 16:27:25 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 14 Jun 2018 16:27:25 -0400
From: "Acee Lindem (acee)" <>
To: Donald Eastlake <>, "Acee Lindem (acee)" <>, Bruno Decraene <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Idr] Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21
Thread-Index: AQHUAz96MVKVTRu+ikqma7S9v0mGCaRe8DyAgAFpUgD//9wnAA==
Date: Thu, 14 Jun 2018 20:27:25 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 20:27:49 -0000

No Mas... Although the use cases for flags relating to these specific TLVs should be few and far between, I anticipate there will be continued FCFS registry attack trepidation. I'll change them to expert review. 

On 6/14/18, 2:36 PM, "Donald Eastlake" <> wrote:

    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