Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Mon, 04 May 2020 18:10 UTC

Return-Path: <rajiva@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D1D3A0F1A; Mon, 4 May 2020 11:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PFEniSGc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rlAqjnDw
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbPbXFL78SOK; Mon, 4 May 2020 11:10:17 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408CE3A0F13; Mon, 4 May 2020 11:10:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14604; q=dns/txt; s=iport; t=1588615815; x=1589825415; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ACAPFKdwoAu06dvYyoLgqKhLHmWlPq2xqwK4uVO8T84=; b=PFEniSGcVMa00DRYHRs08xPktt7m28OqsZxRICerxRRWxYy2ChJbQNKd RNRPwMZREsP02tzLIwhEl23G7qwqaf5KpapSo5BtmIqEAQcSTmhx3CWBF mTyhubx3sL1yl6v78O80t4uuU/KBcBCmTle16R6t7KSVbqKPdt+L+8rEs k=;
IronPort-PHdr: =?us-ascii?q?9a23=3AeSKaUhU6GUG4/QYCj0B3oGmXVQ7V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuf1BguvS9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAABdWbBe/4kNJK1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBNgMBAQELAYFTUQVuWC8qCoQZg0YDjUeBAYh4jjy?= =?us-ascii?q?BQoEQA1QLAQEBDAEBJQgCBAEBhEQCF4IdJDcGDgIDAQELAQEFAQEBAgEFBG2?= =?us-ascii?q?FVgyFcQEBAQECARIREQwBATcBCwQCAQgOAwMBAgMCJgICAh8RFQgIAgQBDQU?= =?us-ascii?q?UDoMEAYJLAw4gAQ4DqAMCgTmIYXaBMoMAAQEFgTIBE0GDQw0Lgg4DBoEOKgG?= =?us-ascii?q?CYoNMhHaBHxqBQT+BESccghg1PoIeSQIDAYEng0wzgi2RSZEGjwkzSgqCSIg?= =?us-ascii?q?YizSESh2CW4hhkWSQF4FYh3yCRpECAgQCBAUCDgEBBYFoI0OBE3AVOyoBggo?= =?us-ascii?q?BM1AYDZBCDBeDT4UUhUJ0NwIGAQcBAQMJfI8HLYEGAYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.73,352,1583193600"; d="scan'208";a="754201031"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 May 2020 18:10:12 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 044IAChg009466 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2020 18:10:12 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 May 2020 13:10:12 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 May 2020 13:10:12 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 4 May 2020 13:10:12 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lBjgKyKjUgLOb71kVpCh3Eb0tC53NRLBl5R1U9qpGQZx6B+FvRgzxR4ujg65swjUEGSTTpU/2naZvqKuHCUc+SDbUGm0FtOe6beOF2WikZx2UJ7FPJOY+oJDW5WEqwzSUnRWuCs6pvJyYTpRDVj0W4Icu403VwQTj/Ey3u5Lo3U9CP8nliIxYqhs5GV9UaI/j+DNS/daSa9fznMTxv4E/jG9BUGDDdg4CQXgtzV9cWM+64jFufPWbN4l8qAuePdCfkvPJPKka5zS6Hd36F0hlZAtn4E8gNBnTE8vrU/4EoholkCHlDNfG4e5iSuQ+vEl9sYJ0YaT4QaZOqsGeteF6Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ACAPFKdwoAu06dvYyoLgqKhLHmWlPq2xqwK4uVO8T84=; b=jFmejOS2cwuRIB+qxUw+Yicwi23qiww6UUdIBPupHklGrZffTzxrB+Jn9w0mBshI17w1RekHdsIooBmfLLmDAdllM/y5s8KxsYMgyYd7XE+hOxTtkVV5hPpncOJMcJzCg7NXgPqpqbhSWGjByNmGU+M1jxMJRQJjqWgxVGMs3NNksRa9YjkI0BDUh1/V8Eg72dTU1+B/uwE+Znp9nnS+wBD2j8yBF4ffN9aTNTInZQMN4hFsYeEPbd/fHbQ2P3xK6Gif+ngRzsN663pXXBWLREYKUPOCyuV2LWstaxIJbY1cHzVtuxCi8sNmWL5M1H2quOFTJvjwyBaklHyIA63A7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ACAPFKdwoAu06dvYyoLgqKhLHmWlPq2xqwK4uVO8T84=; b=rlAqjnDw/35Ee6aE7CIR7SZ3z2kArPfgQz4OpbUxhKiIPhZ4MB0Vcuhen92WR/2RihwBGqc7p6qPElIbaAAUNDK4En6USbOx5/Uq/1kVrNbWjaIa8CYZfWFBL+6b09gmXjifoAbUXbqitUjZkOool29t0buue+MSTVFHOHWOLt8=
Received: from BN6PR1101MB2337.namprd11.prod.outlook.com (2603:10b6:404:92::23) by BN6PR1101MB2273.namprd11.prod.outlook.com (2603:10b6:405:53::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Mon, 4 May 2020 18:10:11 +0000
Received: from BN6PR1101MB2337.namprd11.prod.outlook.com ([fe80::5b5:bbfa:fb33:639d]) by BN6PR1101MB2337.namprd11.prod.outlook.com ([fe80::5b5:bbfa:fb33:639d%6]) with mapi id 15.20.2958.029; Mon, 4 May 2020 18:10:11 +0000
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>
CC: Susan Hares <shares@ndzh.com>, "draft-ietf-idr-bgp-bestpath-selection-criteria@ietf.org" <draft-ietf-idr-bgp-bestpath-selection-criteria@ietf.org>
Thread-Topic: AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12
Thread-Index: AQHVPNx/JPS52x+mAEmNVNu2mvOPqqfj4TAAgLXgiAA=
Date: Mon, 4 May 2020 18:10:10 +0000
Message-ID: <49B487FD-EF5A-42AA-9A50-2D03BBCA0796@cisco.com>
References: <CAMMESsz1R9u4fJUkFr0wxd8OF3u==PvPkr+6t7sXHNGaPR2-tQ@mail.gmail.com> <CAMMESsxbetZAWvSSaYU3DS0W_CASzP7YeCnEpFyoURfd1uZRgg@mail.gmail.com>
In-Reply-To: <CAMMESsxbetZAWvSSaYU3DS0W_CASzP7YeCnEpFyoURfd1uZRgg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.51.227]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2e78a451-943d-4f2c-3ff1-08d7f05662d0
x-ms-traffictypediagnostic: BN6PR1101MB2273:
x-microsoft-antispam-prvs: <BN6PR1101MB2273730F688E6B6F4B0CE03DC7A60@BN6PR1101MB2273.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03932714EB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yE/kSHyJ/c9FU+CzIUwZeX/341vCSyOoBZgSIZarrupPqXZJoNNh4qGrn+blLn/j7TMWuLM+mBX7gOtHG1CgOuqlAMiIqWfx4pUPTKChKSoSLI09srDMiNAmmjHFQ86FFW69vgzUIUb1eIOvHFyI85gkIpDFLnWit7avXp4X5wuShttcfulqbOUqofA1FVIZjvvBRbWELFk6maViWq7UCcDv9sKaHRydB+NdYm8NNCPouOB1bhEqslb+EtmLFJBQYhvb0S9dE6F2dijkE6F7/QRGpjXXymPEpk5HvqdtEFriXwxotZJq0+1e6KOpAAlxY5uZYfHKtvVj+/LtABuGofxINPbR7ti2ZtF78bdOlpgFuQWWYbY87ZNKVBsrQR9tx9mVWNPw782OURFFsKq3Ds6SaE/jnODbp8pS5alxsK+DA9u+y+dXAkB7lHEHS0qSAmF7J7gP0OLIkkFXoM7Ohx12uASoReDoQmTJlsG8G1cYTiJg1J4UTHfomaNcelWzx7Z+eREgIe5J+Cf7w+gU4olpwBn+IoHllhHtGWd6ltey+P+eFliLlLHmrlTKQJf8
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR1101MB2337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(376002)(396003)(366004)(136003)(2616005)(966005)(36756003)(4326008)(71200400001)(54906003)(8936002)(110136005)(8676002)(316002)(2906002)(86362001)(76116006)(66476007)(66446008)(186003)(33656002)(26005)(5660300002)(66556008)(53546011)(91956017)(6506007)(6486002)(66946007)(6512007)(478600001)(64756008)(560514002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Zca2UdCitWdTlkwGlxTHdDuzvpzlTuN2pYuYARM0GlPF0Eyu1bn+5uzAQtyQtM3XXa2C3isff8AdcRAv0sVTPG0U2v+8TXrCP0z3zq0yRJNcFMduYib+mGgmz65zwh8QLYYlUSe9QQIPVFv+9fidu8WyfsiJ4h0Tn/7i4RNg7UdHW30M701Zs/fuwYROVzGB+SjJB8ogoM32hKaH1ahpwLKPujjPXMQNwunkYSWA3L/xw/UGzdF5bbBvhhlpOxtdKG+ZkjJd9GZH14bXmVA2KcBZnqGh3VPvmz/mIQENEFj/zzFAKFaUrqZ2yyvN8Gx/Bse0lEsdbDPWo6QIxha0Trpb8gn+Idmh6ykjgId57bgOR9zz/6M4ePiNRPCxQQNzcEeYXrmcaNISwbavxwztiOpymD70vyWX5qHW8Pj4ykD07gULOrLteZJXNNor3quQOogAsfVggMal4o5zdzMwKNgRnZNDFl2ZYPP59t9uggjP9Xu+G3q4CGKnLRx+8mlwL0ssPCFy9DkpalhgEVlkJ7GDWRneiPRZPEKz49QCVv7LH9cBcrjLIhhET41eBXWYjWdAfE5+yZTWpzRfFRDEqhRcsmneTijJiZ03s8GyLVD18/vwFNWOcxJUzWBfqngNZuxfl7Ybv9imr7v/hp3EfH9aAIITtmXNKQMociraXcX8Z2Jh5ZMMMAfIWy77uVZb9cJ0qwLzCjkJxNpE/egaySPLOg0YYAzfeg2JjUJXMOzVLHGE2Q7HKa8zWawD/T6cfpJDXq2jfrv8YBvyqxjKABXfLhF5o60PT9DQcEfUcGI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <61A4F075344D41478A999FA45A952ADC@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e78a451-943d-4f2c-3ff1-08d7f05662d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 18:10:11.0124 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nVErdzxu2jhQK93PoyvnHwFux2au6msjWiCw0zUeCM/4v3YyBHR9959lzkVgEzWmW4RZfZgJgq9kwJAKU/2r0Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2273
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8APwLP-Fedyc1I9HUaCpbNQ5no4>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2020 18:10:20 -0000

Thanks, Alvaro. While it would have been preferred to keep the (NH selection / verification) logic independent, it seems that there may perhaps be the following 2 means to solidify the logic -
 
 a- Tunnel Encapsulation Attribute (updating rfc5512)
 b- Cost Community
 
It seems that (a) is somewhat more progressive than (b), and clearly conveys the encap preference that can be leveraged. Thoughts?

If agreed, then section 3 could be updated to reflect something akin to the following -

//
1)	Next-hop resolution SHOULD check for NLRI’s next-hop address in a routing/forwarding database related to a particular data plane protocol, if it is signaled by BGP Tunnel encapsulation attribute [T-ENCAP]. If the check does NOT succeed, then NLRI path can be marked as 'next-hop route inaccessible'.

It is also possible for a policy to override the default behavior. Such a policy may be applied either per next-hop or per AFI/SAFI or both, however, it is deemed out-of-scope for this document.  

This check is about confirming the availability of valid entry for the next-hop address in the forwarding database related to the data plane protocol.


2)	The next-hop resolution MAY check for the entire path to the next-hop being functional or not, in a database related to a particular data plane protocol, if it is signaled by BGP Tunnel encapsulation attribute [T-ENCAP]. If the check does NOT succeed, then NLRI path can be marked as 'next-hop path inaccessible'.

Selection of a particular mechanism and data plane protocol are a matter of a policy and is outside the scope of this document. If policy is not supplied, then the default behavior is to not perform this check.

This check is about confirming the availability of valid entry for the next-hop address in the forwarding database related to the data plane protocol.
//

Would appreciate any feedback you may have.

-- 
Cheers,
Rajiv Asati
vCTO/Distinguished Engineer, CX CTO Office

-----Original Message-----
From: Alvaro Retana <aretana.ietf@gmail.com>
Date: Thursday, January 9, 2020 at 3:44 PM
To: "idr-chairs@ietf.org" <idr-chairs@ietf.org>rg>, "idr@ietf.org" <idr@ietf.org>
Cc: Susan Hares <shares@ndzh.com>om>, "draft-ietf-idr-bgp-bestpath-selection-criteria@ietf.org" <draft-ietf-idr-bgp-bestpath-selection-criteria@ietf.org>
Subject: Re: AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12
Resent-From: <alias-bounces@ietf.org>
Resent-To: Rajiv Asati <rajiva@cisco.com>
Resent-Date: Thursday, January 9, 2020 at 3:43 PM

    Dear Chairs/WG:


    Happy New Year!

    I am returning this document to the WG for further discussion.

    Rajiv, Sue and I had a very fruitful conversation while in Singapore
    at the last IETF.  We agree on the technical issues, but (as explained
    in my review -- I left the header below [*]) my concerns go beyond the
    content and into the Status of the document and the general interest
    from the WG in this work.

    Sue/John:  I need you to explicitly collect feedback from the WG and
    reevaluate support for the document's content and status.
    Specifically, we need a *discussion* about the first two points
    mentioned below.

    Thank you!!

    Alvaro.


    [*] The full review is here:
    https://mailarchive.ietf.org/arch/msg/idr/85qTCgN4k6oAbSlKmpyi8stxZz0


    On July 17, 2019 at 4:15:57 PM, Alvaro Retana wrote:

    > Rajiv:
    >
    > Hi! How are you? I just finished reading this document.
    >
    > First of all, thank you for your patience and perseverance in sticking with
    > this document for so long!
    >
    > Having said that, I have significant issues with the document. I have
    > specific in-line comments below, but I want to highlight some of the bigger
    > issues now -- please note that while you are the Author, the issues called
    > out here are directed at the WG/Chairs/Shepherd as well.
    >
    > (1) What is the Update to rfc4271?
    >
    > The document presents two amendments to the Route Resolvability Condition
    > (§9.1.2.1/rfc4271). The first one is straight forward and obvious: resolve
    > the next-hop using the correct Routing Table.
    >
    > The second one is to check the "path availability" to the next-hop. While a
    > good thing to do, and optional, it introduces in the BGP Decision Process
    > unspecified functionality that depends on external mechanisms...which, in my
    > opinion, should be used to maintain the Routing Table and not be specifically
    > a part of BGP.
    >
    > Both the policy to drive Amendment 1 and the expectations of the check in
    > Amendment 2 are not specified and declared out of scope. IOW, the
    > specification is to do something that is not specified. Back to my question:
    > what is the Update to rfc4271?
    >
    > I didn't find a discussion on the list about the Update: either about
    > formally Updating rfc4271, *or* what the Update would be. I did find a note
    > [1] that says "our AD requested we move the document from Informational to
    > Standards track, and add 'Updates: RFC 4271'"...but there was no discussion;
    > in fact, no reply at all.
    >
    > [Disclaimer: I was not the AD in 2011.]
    >
    > Related to this point, and specifically to the "path availability"
    > functionality... In the Implementation Report [2], one of the implementers
    > reports support for "path availability check in several variations, but not
    > all. For example, BFD may be used to protect MPLS generated nexthops for LDP
    > and RSVP. For IP nexthops distributed via an IGP, the IGP may be protected
    > using BFD." Because the "path availability" functionality is not specified in
    > this document, then I'm not sure whether either of these satisfies this
    > document...but both mechanisms described are about protecting the next-hops
    > (and presumably triggering FRR, for example), and not specifically about
    > providing BGP with an indication of availability to forward traffic (which is
    > my interpretation of "path availability").
    >
    > To be clear: I mention this text from the Implementation Report not to
    > criticize the implementation...but to support the points that (1) the
    > specification in this document is incomplete, and (2) that the OAM mechanisms
    > should be used to maintain the Routing Table (and not just interact directly
    > with BGP). IOW, I believe that the implementation is doing the right
    > thing...but that is not what is described in the document.
    >
    > [See more related comments in §3, after Amendment 2.]
    >
    >
    > (2) WG Discussion (...or lack of...)
    >
    > As I mentioned above, there was no discussion of the Update in the WG. In
    > fact, the only significant discussion was during adoption [3] -- at that
    > point the draft was Informational and it didn't Update anything.
    >
    > The WGLCs [4][5] show only 1 comment, and no other explicit show of support.
    > Not even the usual "support...+1...+1...".
    >
    > I went back and looked at the minutes from IETF 73 [6], which is where the
    > draft was presented for the first time, but there was no feedback there.
    >
    > draft-asati-bgp-mpls-blackhole-avoidance, which was presented at IETF 68, was
    > the precursor of this document. The minutes from that meeting [7] show not a
    > lot of excitement and minor support for perhaps an Informational one-page
    > document saying "please be careful about selecting a next hop".
    >
    > One last note on this point. The Shepherd's writeup [8] reads:
    >
    >    (9) How solid is the WG consensus behind this document? Does it
    >    represent the strong concurrence of a few individuals, with others
    >    being silent, or does the WG as a whole understand and agree with it?
    >
    >    Solid in 2009. As time goes on waiting for implementation reports,
    >    the memory of those days weakens. However, since 2 major vendors
    >    have implemented and deployed this RFC - the solid WG
    >    support from 2009 has been validated.
    >
    > The draft was adopted with rough consensus [3], so I don't interpret
    > implementations in this case as strong validation mainly because I don't see
    > a clear specification.
    >
    > All this leads me to ask: Is this work (many years later!) still something
    > the WG wants to progress? Or has it been taken over by events? Is the
    > document in it's current form what the WG thought it was adopting?
    >
    > I am looking for discussion and specific opinions (not +1s!). I would be very
    > happy if someone pointed me to discussions I missed in my search.
    >
    >
    > (3) Terminology
    >
    > In general, I think that most idr participants would clearly understand the
    > terminology used in this document. However, the audience is wider than that,
    > and the terminology used doesn't correspond to that in other work.
    >
    > For example, the first sentence in the Abstract reads:
    >
    >    BGP specification (RFC4271) prescribes 'BGP next-hop reachability'
    >    as one of the key 'Route Resolvability Condition' that must be
    >    satisfied before the BGP bestpath candidate selection.
    >
    > rfc4271 doesn't talk anywhere about reachability or a bestpath.
    >
    > Please be consistent with the terminology in other RFCs, specially rfc4271.
    > Introducing new terms is fine, if they are needed and properly explained.
    >
    >
    > Given the points above, I am inclined to return this document to the WG for
    > further discussion. I really don't want to do that given its long history, so
    > perhaps we can use some time next week in Montreal to talk face-to-face.
    >
    > Thanks!
    >
    > Alvaro.
    >
    >
    > [1] https://mailarchive.ietf.org/arch/msg/idr/jWNhfTvHbaY3rEk5nTYahS5w6_Q
    > [2] https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria
    > [3] https://mailarchive.ietf.org/arch/msg/idr/Yr9u6V2HKrHEuQLtFw7aDstMPzg
    > [4] https://mailarchive.ietf.org/arch/msg/idr/kiTwL6ApC_k9QFrfhaMA_qC8BcA
    > [5] https://mailarchive.ietf.org/arch/msg/idr/OqsCexPPmtvKjHNJzf4EcpwPhtQ
    > [6] https://mailarchive.ietf.org/arch/msg/idr/OVg6Cfr3EUwIRcQS6cIkwq_dUtI
    > [7] https://mailarchive.ietf.org/arch/msg/idr/lezFHSGaOzvL2h16M883beeHcjI
    > [8] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bestpath-selection-criteria/shepherdwriteup/