Re: [Idr] AD Review of draft-ietf-idr-bgp-gr-notification-13

"John G. Scudder" <jgs@juniper.net> Fri, 06 April 2018 15:16 UTC

Return-Path: <jgs@juniper.net>
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 47D7C1271FD; Fri, 6 Apr 2018 08:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 Nm0s4H-9eIGa; Fri, 6 Apr 2018 08:16:12 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A43120726; Fri, 6 Apr 2018 08:16:12 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w36FAZ3C024618; Fri, 6 Apr 2018 08:16:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=PPS1017; bh=iJc2DbiCsCHsx537C87KcHe4J7qbwG/UMdrza9aCGG8=; b=ZBxN4DNgSSHwpR0Lomyr1uHgOsffvj59Yi1jbx4RW5sUqOrqopVwLU87CAKhzEplLVdh cH1bQ/m6SnOYujK8U3LJLfZwC2gbxqkpmdZWZkBgukv+CfSpbfDm+xnp2lQQ+VpNdPA3 u83oYfrx/8lxWhgdfQwlKLRjzygilGgAEDsI+j/lpfRV4ruY/EbhVzX+WfRpLKq/i38C Q4FwA8HmcPHlGk/B+vS+GPkAwpla6IGCJ3N69Q6wcBapvj7WRVavr2us4bKskFbjzf0p lbhKkUGo/SfwOI2mKUtgMMB33fE0XOJl+piGmZ84fgjGOWFNTVX9BoefjTPJYY5lLaIm IA==
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0b-00273201.pphosted.com with ESMTP id 2h69pn87bg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 Apr 2018 08:16:08 -0700
Received: from [172.29.32.7] (66.129.241.10) by CY1PR0501MB2075.namprd05.prod.outlook.com (2a01:111:e400:c44d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.4; Fri, 6 Apr 2018 15:16:05 +0000
From: "John G. Scudder" <jgs@juniper.net>
Message-Id: <3197C941-3EBD-4BE0-B733-9C72A6B3B5FA@juniper.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_445B8F3B-2BD8-4566-AA5A-9332041E30C0"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 6 Apr 2018 11:15:50 -0400
In-Reply-To: <25077_1523005047_5AC73677_25077_122_1_53C29892C857584299CBF5D05346208A47A006C8@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "draft-ietf-idr-bgp-gr-notification@ietf.org" <draft-ietf-idr-bgp-gr-notification@ietf.org>, "idr@ietf. org" <idr@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>
To: bruno.decraene@orange.com
References: <CAMMESszAe0avmcX0X95uOwRu29cTvbx_t7ewBwU-Hig20SD9pg@mail.gmail.com> <03AE36E3-F18B-4F34-9A6C-242AA1CAB4EC@juniper.net> <25077_1523005047_5AC73677_25077_122_1_53C29892C857584299CBF5D05346208A47A006C8@OPEXCLILM21.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3273)
X-Originating-IP: [66.129.241.10]
X-ClientProxiedBy: MWHPR1001CA0029.namprd10.prod.outlook.com (2603:10b6:301:2a::42) To CY1PR0501MB2075.namprd05.prod.outlook.com (2a01:111:e400:c44d::25)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: f621a05c-13b5-40fc-1317-08d59bd151bc
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY1PR0501MB2075;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2075; 3:2xKQhhgpMz7cl2Lu73kDEylgTrw8gU7K059IhRdgo98BcsCdo5mSh9e9EpuwkmrwoANDUrT/2fssY5djlHAk+SLXvv3DSsLmmrw8wQwGz6JsSPx5wpsadGMmw/7VkX39GX1sLb/msXy3ctr7myuiUuWjZf/UqBkVJ3ygxgwiXEZGnRAxxORVMep76lltwG8GEPBDMBEtFcoYpfRnJ0gNwvQ0zsD3KR8pTvT7XU7KJ7yXmcC34S6JQV5LVrXnZJfb; 25:bUBy/F5Dq3SydiDfeM3Hjdc10yXDvvaIm+rhZ8CBrgjm6h9GP4WSt66ulInZcuSx+e1doO47njSRSzubyl1/c1niyx47jm6RbCRoy2fvY3HUiqqDPakEx3p3vsWj5ZDSLnAB2kOEhOqaP7RxgXk7zmo2tt7OhGET9S9/S7tu/gFJuvQQUhGdxck1aYoKOR7k9vEZX7bc8ljuFikfUmzPWrUedegHhyMjUsEEUfIhiWCawGD2kaznPTf6U1EMB1fvYY7Aths2YwnXtvI3ltnMDVRtzxOPlnDDScYcRBdEk2vFkKAlljLtJJBGWEt9/9ovUbDwPwa8iAPLn9inptKdJA==; 31:hw5om541ep5i6259tLg2lbECBlcm6U7/UFUoQ7q17SLGpXldTQXDi8Il0wzFaJS/G5qSICMKRwk4kQoSKFtBibRer4lf7tE6r3imquMdpe20FT73WDAdsGnCTd+CrSB8ImKU3SlPzeVW7V6Yqd7jjDxcJW5Xwg/tuRT0bCanMeBeCYlCBXgqqADtkh+/k6YK7M9zIks9HPKDY0Uzy6YwKljpSocMupBPbLp150lCdtg=
X-MS-TrafficTypeDiagnostic: CY1PR0501MB2075:
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2075; 20:YVxe9LC9BUEZHD018ARdUA7ml9KzEJo+0euE7uZOvqZChBdzGmGMQje8Alf0EUXT8xMSnKESJocCRJWLhLpkmv62VGqQHYzFVepQ6z5id73DggnmlFMRjKcFO5dEtBSf5odZwYTsj32ZtbRr3pgMOvhxM1bTZluyqTAsoKORnsZJ6vBLogXfZD8ms/xrXFb7f8PJMwN9BCb+Sa4FjFIk3XTz2aubqmOb9BgnQzr2LjaZVzVAl8LRrfSpABnlpRndg9DRAItsDACmjEh0zY1+mAMynjYc/+t3iUTZlJvUJCHz4rBJilGEvopsRwb8nv3tDhPkw6spM+c9tsbJOYB9RIGcsZvwFLbqwAX7zm5Q6M0dAN/Gg4PwbCfzdlGRuQqgtzAJEtsR57ikdNEo/JSrQSlLeBT1aBRxO7tCpdTbTcD7ZZbAy2XktINIbmJvssdb166fwT2xfl7fEKbB2SO/Ff/ZxBXxdUIjqMSZrTPYddLVDeFVn2qV0vMxVTgqByrBrn/QDgbo5yR3uEbBtL8CeZTeVgtVIhcZT0gQvtYT7UtPRlf/F23kCssweqh5rmEGTRcTRhIcp/xxRNTb/dJ7JtK3SM4T+kRNbiLXAp1Vwes=
X-Microsoft-Antispam-PRVS: <CY1PR0501MB2075B3E78016700DD292FBC2AABA0@CY1PR0501MB2075.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(10436049006162)(192374486261705)(85827821059158)(100405760836317)(18271650672692);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:CY1PR0501MB2075; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2075;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2075; 4:l3TBRILkH79j4bXUiBP8H0SZZwXd2nWwtIbytgHx5slO3dOzBQzkEAjJlgZ/5lGbGAEZRmmEClVFcXv0U8et46wz1NM01AgBgLh2tTiREM0ZkCWny2k/kXUe7OHs1oZZw9CEyxyU2pbX1JbYvgzTAixS5zIgf858gXW0c83JrjJF2Yuif2UF981SqYEMz9ALCqJYA/vUuMQuSpb2jSE31Uv9FLma31AYSPCZh0wBih3gwMdy4ZdROT9TaDf0AUCrRmSGr1P7uWOLoqhsz64NJsxmkWeu6SnswSWHJRBpqM08Zx9sd54nRAnft05J4zAXjEPIUYnLSZ/AZM5DdQLbaoQxY6Nxnlj65oOpaLZVPPRYA5mOG4Zgj/PjybYDfhjwmAQhXwa86i6YEMEsroCJZdaPRCX1WVssw+uFZws4oGZMz7sad7tW7k5NJH6U+lOESrzwShzEoN5RNsUVCZQWxA==
X-Forefront-PRVS: 0634F37BFF
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(396003)(346002)(39380400002)(39860400002)(366004)(43544003)(51444003)(189003)(199004)(53936002)(54906003)(6486002)(5660300001)(6306002)(966005)(53946003)(97736004)(478600001)(236005)(105586002)(446003)(2616005)(84326002)(486006)(575784001)(69556001)(956004)(5890100001)(86362001)(66066001)(81156014)(106356001)(81166006)(7736002)(50226002)(8936002)(476003)(16586007)(8676002)(4326008)(33656002)(16526019)(2906002)(25786009)(52116002)(59450400001)(386003)(53546011)(57306001)(16576012)(316002)(3846002)(82746002)(6116002)(83716003)(11346002)(68736007)(6916009)(6246003)(6666003)(39060400002)(36756003)(77096007)(229853002)(606006)(76176011)(186003)(33964004)(26005)(2351001)(2361001)(15650500001)(42262002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2075; H:[172.29.32.7]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB2075; 23:NqUNmOvXX9oqshjfzX6ORWfFBh+cTtU3JnSAuPI?= =?us-ascii?Q?6x4UURXlQfwuqA/niCHrT6FNpvIjm0qQmOgJ+osYONG/DfV3HU8W9U2PD5mO?= =?us-ascii?Q?mQov+0prX+PlBOPSMiAN2vzXVAe/l68TfMg0iTa/axkC3poTW/Cpj25Puqpu?= =?us-ascii?Q?ozLOa0oNuyLfxa0r3YcQp79A7+zdOfNALM0/gNfKY2fim5FAtLNvhh8DqZs4?= =?us-ascii?Q?6Xr5VNbkdgsiY0Xs+mC/BMQX6+Hi+8cjJ/7yQgHJh4W+a1oC0I/GuspZdOsv?= =?us-ascii?Q?qFe+PQ5T8yQW6cBMPLkmS3DbLG0tNQXznYd+bFhubTrb50UlM5qOH+NMZ6K/?= =?us-ascii?Q?yD2cJW3/NQWVNsxgXNqv5WsgGs7v0TAJHyYdW589GkR8gB2SIc3xrlrDvtkh?= =?us-ascii?Q?BMZoOWRSbtKsGngKCZRhSbzxQ+TQWu4frLmA5Ob6XBR+vzCkfl794HTB+7IB?= =?us-ascii?Q?DJpDLIszv/7VB465hyQ9zorfC8VnBx2znCJUwFdJ/kYuVVKuaUrtVqAU6/Ac?= =?us-ascii?Q?jRMdHfz2uYfgfORhkcQMBQR/mdxnSHMbNRCG24IPaVs3OjCbOmeESbU5iLPn?= =?us-ascii?Q?ULIdnSN4vLmHCd+szkSRQnUO4CDdQ6BcO678s1pgvbUe/CnKfQNOrLB8XyQ/?= =?us-ascii?Q?waFynWEHcF9n+bk+zJ/cVGmeLc+kVArMPYRMAsPK9Yjk1/ylyXsCwwub+D+c?= =?us-ascii?Q?8RYU1pZutGAv6PH1qldc+aGE8aGPQ31LJYT3YzwhxXzqegDFPRRdV5RNZ0m0?= =?us-ascii?Q?DgjI9kWdg1tDIpvynnRS6m/0Xs7gOlD3md/WenyEHTbOTWkeguLWlpdl+ldF?= =?us-ascii?Q?dsvyrY1zPYze34AkQh3uATWpAQIM/EY4Hu3dBnI5uXEEZpFQucEzdkjfOp2v?= =?us-ascii?Q?5MmHNDZoyBALtYEzHMcmGT5zKpttxf/X1SRtXBjTUrAgneAjCqv8yy0JUQ/0?= =?us-ascii?Q?O9YyAk/oYiH0bJ4b9x5XOe4LHfwfLUQdKWMyGliQrgYCjZRsybYDNnSXZ00w?= =?us-ascii?Q?cepRt4Nq5hSHy/xsCvO7G7ZoWpFYFQT+dA+VwoYw51ufZgIcIe1/GW7E7bwW?= =?us-ascii?Q?b5T3gKtmWgaJL4nhiXZ0uPDS8jdSrx8TQ5vz4fY5exUT21F+vjgJOmvhlYnP?= =?us-ascii?Q?sRqTnKxXWVOpsrU4B/rtRHkTDA88wv7LorlhwMTobkVM33/C/1iUlB0c7E58?= =?us-ascii?Q?S9XorHWepQwz6AaumtoSzjb/4umejDPpTj0x87dIMsdnl5TjWyqmmub02L8b?= =?us-ascii?Q?UG1AqBZXe9RNhVaiMnkaXYu80hTP1w9hNY5dm72DlX8MExXNMRVeTT1qJw2+?= =?us-ascii?Q?SQqWFVzHQQc7yqcP9JbAFbFmcjPmLH0TNST0WVzbHH0xbJn4F4Az6bCaikHK?= =?us-ascii?Q?cdzbbbY7F3gCubhDtwkKapyvZnxualsPfdvMlqz9Dht9Xdi1pnD8S2STZ5Qe?= =?us-ascii?Q?Vt5O1cB5I8TLJsiRiwz6uhdi7EiQtJYv0++mjOb8jmCRH/O0gN0zqI0b02FV?= =?us-ascii?Q?Ces5z0HwcLEeaR/z9Z7AkbIDdOCQJNO42ebGH3pVk/aQ52J8dqY8XZ/qSEOe?= =?us-ascii?Q?B/mQBqeho8WMfHEKVFtA6kZNQk4e2yvmZFQ9tnkVZvWMbpSmNymOJUOV2ktB?= =?us-ascii?Q?U2lTA9eTvDHw6FHD5X77NrssbXuLOHoKNE3cD6haJzzHl0AXfQIfCzTdDKO6?= =?us-ascii?Q?8zGPs?=
X-Microsoft-Antispam-Message-Info: CWC8u87HYtrFu9f64F2I+UJFKDD+PbnqefBh/5qfnKCQfukYsfUbE6Z3E4LurKY0h9FKopIa6/g40luHThm1BpKiD/pyrdcwq3ztAoFwaLSg7GRPv5nGWhsJGTzfVOtGtKMAiuHG7S+ggm1iSO+quHkcaxgDXPjetV5xl3ZpZCh98Xr+4Rosf61ATtPBCpWH
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2075; 6:W+97tSqZb0ox+pNxy0CAKxTQj2Fb9jj1M377mup3bqQVMgpIndhIlomfZxK8inaGbghjgsG1bEi99L6WaJPkt/AQ7uu9hmWZkFdHOgOc3BWsqNm1QgOacTuV19JipRTlImss/KxL5e0KMGBpKYVxaIFkW1trNoLLiJLA5ohARRDFhK0FDZPQZeU61l20dD99cyui93xDHCUDsk1qfEMXsucxz+OWe58WI2krqP+xWwLmT2cdiySdTNHM+fqUsgEVzIjiTreYw7/nCChpzbMJfCVh5RVkUdJ8gIwD8NrRPWHLKgC7HsIkS66vUtDRJu3/aYnZqo+P6w9PK9Q5FRS18CLqhdbpIL3RPhWRJXbumhDqd9mwHp9+fnB1lDwgVNQE+r+OG6Wory7F4cNz7i7LUqXgKEwD0TlcmdFmaQ0fnlIZ2eJSmDuN/Vqqsq2RMMfm6/bLvCqpLGevvsvuNBwoCA==; 5:s8nFd2v815PYhzPtK3/RxjqmdB/I0lJ1KP6Nxxt2yT0D8PrYgoL3WU5f8ZBUzfHcs3FGF4oXRZxPw2SNooeiGng3Sl3c7tv/K0ucNn+VSX/XtrEmyq2iTczg+fdlZO/052Ky6KNI+Ex6Kbmae8jjx+pnm9XHRWA1NfPYkDbTc+I=; 24:1oUQ8PAsrBKtjjJBvcd25nP3A+MDpBrxafAV9T0/rpjoev2PhvH1VgoaI3H59dqIddAFTBkfkAc2lSA92Lx59GT1DIdIfeBBoLxuhNsnWWc=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2075; 7:hpODHjYF+P2n5TKMztCSXTnDJr9NL/KiEY2RpymG2G+LOZ8kZ5xIYOEnf6f9VkWJtLRQRID0ZqzkpFBqpsMz8cu+KzF0wDY26+bi05x4xsdo+8qaQ3gKaX/pgpnCVtg8AJUqW3oKXvsgIFqXSsrhnREVoUQ6lf3jZuhklskHg10n5reuur3WBXacs8CVHhTglv1cYQVs1kwIv1CW8+htQ/yD5FJmsVw0UFWno3tNViwBwH8nDDNz9oON3jwb1HSg
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2018 15:16:05.3444 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f621a05c-13b5-40fc-1317-08d59bd151bc
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2075
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-06_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804060154
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8NSW8ZGiNBhQUOEeYduLXJcuUr0>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-gr-notification-13
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 06 Apr 2018 15:16:16 -0000

Hi Bruno,

I've just posted a -14 which I believe addresses all comments so far (yours and Alvaro's) other than this one, for which some discussion below.

> On Apr 6, 2018, at 4:57 AM, bruno.decraene@orange.com wrote:
> 
> Hi John,
>  
> Sorry to turn this thread into a general call for comment while the document is post WGLC…

Better now than when it gets to IETF Last Call.
 
> When:
> 1)     a BGP session is established (OPEN1)
> 2)     then GR or draft-ietf-idr-bgp-gr-notification triggers a new BGP open (OPEN2)
> 3)     this BGP OPEN2 triggers a Notification OPEN Message Error
> 4)     draft-ietf-idr-bgp-gr-notification is used to handle this Notification using GR
>  
> It’s not crystal clear to me whether the BGP speakers should behave (in term of OPEN capability/parameters) as per OPEN1 or as per OPEN2.
> Indeed, OPEN2 is the latest but was erroneous and explicitly refused.
> Then again, the answer may be subcode specific… (with “Unacceptable Hold Time” it’s unlikely to accept the (Hold Time) parameter(s) from OPEN2).

I think if the OPEN2 still exchanges the "N" bit it's already sufficiently specified, or maybe the point is moot. 

OTOH if OPEN2 doesn't exchange the "N" bit (either because it removes the GR capability entirely or because it removes the bit) then maybe there is some clarification required. Unfortunately RFC 5492 doesn't seem to say when a capability is said to have been successfully exchanged, probably because at time of writing (or at least at time of writing the predecessor) the idea of keeping around previous-session state didn't exist. 

Tentatively, my answer is to say "a capability is only considered to have been exchanged when the session carrying it transitions to ESTABLISHED state". In the situation under discussion, that wouldn't happen, so gr-notification type semantics would continue to remain in effect.

--John

>  
> Thanks,
> --Bruno
>  
> From: Idr [mailto:idr-bounces@ietf.org <mailto:idr-bounces@ietf.org>] On Behalf Of John G. Scudder
> Sent: Tuesday, April 03, 2018 10:03 PM
> To: Alvaro Retana; idr@ietf. org
> Cc: idr-chairs@ietf.org <mailto:idr-chairs@ietf.org>; draft-ietf-idr-bgp-gr-notification@ietf.org <mailto:draft-ietf-idr-bgp-gr-notification@ietf.org>
> Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-gr-notification-13
>  
> Hi WG,
>  
> As co-chair, I want to point out that the AD asked the WG for comments ("I want to ask the WG to consider..."). Since Alvaro asked more than three months ago and nobody answered, maybe nobody has anything to say -- as he points out ("[After I wrote the text above…] I found that some of the points have been discussed on the list already"), this topic was beaten to death in March 2017 (https://www.ietf.org/mail-archive/web/idr/current/msg17679.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_idr_current_msg17679.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=7AX9lsHCz9FSlFK6feRmlnAwToPRMqMdbsjdQNxre98&s=Eb2l4KGMYRyULZHgUquSdC0EFBsq78qFVgQH_0svDSU&e=> and the following thread, specifically in the context of session culling which Alvaro brings up). Also, for reference the original WGLC all the way back in May 2014 is here: https://www.ietf.org/mail-archive/web/idr/current/msg13202.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_idr_current_msg13202.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=7AX9lsHCz9FSlFK6feRmlnAwToPRMqMdbsjdQNxre98&s=Cj0Pme9WuS9-M7h-jLQRDlyUlQT70fb2qCojXaqenYQ&e=>.
>  
> However, maybe some people have just missed Alvaro's request, so if you have comments you want considered, please send them by April 10. I will follow up myself (with cu-author hat).
>  
> Thanks,
>  
> --John
>  
> On Dec 7, 2017, at 4:11 PM, Alvaro Retana <aretana.ietf@gmail.com <mailto:aretana.ietf@gmail.com>> wrote:
>  
> Dear authors:
>  
> I just finished reading this document — I have some comments, please see the list below.
>  
> I understand the intent of this document: instead of resetting a BGP session when a NOTIFICATION is received, use Graceful Restart; if the session is going to *really* be reset, then use the new Hard Reset sub-code.  That makes sense to me…but, is that the only code/sub-code for which it makes sense to do a hard reset?  The NOTIFICATION has always had the “stigma” of being something bad, so much that we (idr/IETF) have even worked on ways to reduce its use (rfc7606, for example).  I want to ask the WG to consider whether other code/sub-code NOTIFICATION combinations should also result in a hard reset.  I think there are several cases, for example:
>  
> (1) rfc4486 (Subcodes for BGP Cease Notification Message) defines “Administrative Shutdown” ("a BGP speaker decides to administratively shut down its peering with a neighbor”).  It seems to me that the sender of this NOTIFICATION would not want to "follow the rules for the Receiving Speaker” (as specified in Section 4).
>  
> (2) rfc4486 also defines "Administrative Reset” ("a BGP speaker decides to administratively reset the peering with a neighbor”); no more details are provided, but that sounds like a hard reset to me.
>  
> (3) …there’s probably others...
>  
> Having said all that, I note that Section 3.1. (Sending a Hard Reset) specifies the “encapsulation” (for lack of a better word) of the real reason for the Hard Reset.  If the consensus is to go forward with that, and not call out other exceptions, then I think that the text in 3.1 should expand more on the encapsulation operation and the rationale for doing it this way, and the document should also address other recent work that recommends the use of Administrative Shutdown, for example draft-ietf-grow-bgp-session-culling (a BCP currently in the RFC Editor’s Queue).
>  
> [After I wrote the text above…] I found that some of the points have been discussed on the list already — please include some of that discussion/analysis in the document.
>  
>  
> I’ll wait until the issue above and ones marked Major (below) are addressed before starting the IETF LC.
>  
> Thanks!
>  
> Alvaro.
>  
>  
>  
> Major:
>  
> M1. Unfortunately, rfc4724 failed to setup a registry for the Restat Flags (or the Flags for Address Family), which means that anyone is able to use the bits in there (assuming the receiver looks at them, of course).  Given that there are only a few bits, and to prevent conflicts, I would really like to see a registry set up.  This document is already tagged to Update rfc4724, so it seems like a good place to establish the registries.  [If for some reason you rather not include that information here, then we can take care of it elsewhere.  IOW, this request is not a requirement.]
>  
>  
> M2. Section 4.1. (Rules for the Receiving Speaker) has me a little confused.  Are the proposed changes contingent to setting the N bit?  The text starts by saying: "As part of this extension, routes from the peer previously marked as stale MUST NOT be deleted, until and unless the optional timer…expires…”…does that mean that the timer is no longer optional?   Then you also say: “...if the Graceful Notification ("N") bit is not set in the newly received Graceful Restart Capability, no new actions are triggered on the Receiving Speaker -- in particular, a clear "N” bit does not trigger deletion of stale routes.”  If I understand rfc4724 correctly, stale routes could be deleted — the text indicates changes in the behavior even if the N bit is not set, right?  If you are Updating this section of rfc4724, what would make it crystal clear is an “OLD/NEW” notation of the text (as in, this is the OLD text…and this is the NEW text…).
>  
>  
> M3. Security Considerations:  Maybe not a security issue, but something to think about.  Section 4.1 says that “routes...previously marked as stale MUST NOT be deleted, until and unless the optional timer...expires, or unless a Hard Reset is performed.  This supersedes the “consecutive restarts” requirement…”.  Not deleting the stale routes and not making the timer mandatory could result in stale routes that live forever if an attacker manages to create consecutive restarts (by simply sending NOTIFICATIONS before EoR) — stale routes are ok in the short term, but may point in the wrong direction eventually.  Is this an issue?  I think that it would be mitigated if the timer was made mandatory (with a nice default).
>  
>  
>  
> Minor:
>  
> P1. Section 4: “...receive and send BGP NOTIFICATION messages in Graceful mode...” What is “Graceful mode”?
>  
>  
>  
> Nits: 
>  
> N1. In Section 2, please indicate that the first figure corresponds to the GR Capability from rfc4724.
>  
> N2. s/subcode is defined known as/subcode is defined as
>  
> N3. s/Graceful Notification flag/Graceful Notification bit   (For consistency)
>  
> N4. The operation is obviously per-AF; maybe it’s worth saying that somewhere just for completeness.
>  
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.