Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis-02
"Acee Lindem (acee)" <acee@cisco.com> Fri, 02 August 2019 16:06 UTC
Return-Path: <acee@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96601201CB; Fri, 2 Aug 2019 09:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.257
X-Spam-Level:
X-Spam-Status: No, score=-13.257 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=idMHrZT8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dMh6cDI+
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 ylkCuZWQuOop; Fri, 2 Aug 2019 09:05:55 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6354E120103; Fri, 2 Aug 2019 09:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=134425; q=dns/txt; s=iport; t=1564761955; x=1565971555; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5jveF6OQe7nkOeNBc0rpMmUYLM1aN+0h5Jbnz6ubBuM=; b=idMHrZT8hsGCaZYV/PPUrMLW4B+U+WYjNju8Ubn28q7kTKqRhh0mMKNX 7cYnd1QLonvuhrMYRuas5mgVKPJ+7ytxgZxv7Sn5ZZSih1F3Zc8meql+T T3VrtAJfQBHGDStWFvEFYYcFwpQNR0X7nzquqwVl7B8PG9ZAwZJu8DUQi Q=;
IronPort-PHdr: 9a23:KgwVQhx8mbNzaa/XCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YRGN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A+GsHbIQKUhYEjcsMmAl1CcWIBGXwLeXhaGoxG8ERHFI=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CrAAASXkRd/51dJa1mGgEBAQEBAgEBAQEHAgEBAQGBZ4EWLyQFJwNtVSAECyqEHoNHA4srgjYlgwCGVY4CgUKBEANUCQEBAQwBARsSAgEBgSoBgxQCFyiCICM4EwEDAQEEAQECAQZthR4MhUoBAQEBAxIIAQgdAQEFBAEtAQ8CAQgOAwIBAQIhAQkCAgIfBA0dCAIEAQ0FIoI1SwGBHU0DHQECom0CgTiIYHGBMoJ6AQEFLlEBhAMNC4ITCYE0gVqINoFTF4F/gRABJwwTgkw+ghqBciABLgkGgmUygiaMDgIWAgqCVYUEgi6GBz+NYUAJAoIai1GEVYN3G4IvhyoFjkiNRYE0hiKBeIJmizkCBAIEBQIOAQEFgT0qIUSBFHAVZQGCQQmBQHkMF4EDAQKCSIpTcgEBAQGBJYpfBCaCKAEB
X-IronPort-AV: E=Sophos;i="5.64,338,1559520000"; d="scan'208,217";a="608544404"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Aug 2019 16:05:53 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x72G5r2R017460 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Aug 2019 16:05:53 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 2 Aug 2019 11:05:52 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 2 Aug 2019 11:05:52 -0500
Received: from NAM02-SN1-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.1473.3 via Frontend Transport; Fri, 2 Aug 2019 11:05:52 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J1DAV7rax7ZBznOhj5WbspNdsJG/TyHyDkmYzWKcAxB2AruNYiKvrzf8F7n/rWWL2ZguW4n0S/vcIbGoF1P5IU7Mk1YtvTme20/FQ0CH7vwzPZxK9LzffW1W6/H+CZ4N8OeFUmOaB3pp9DwjrHORrE6TMMO52j1mo9gp0/3aS1yTUJmZnrJkfOL+GdIhlRdkDJGh+m5QpFCbn/fjn4Uu8WkPfdNlFtcTUQ69KHKAZSPP1p8cl2R2fw5afiwVZWor8Cgs4zf9QKfGoReBYFYX4XmcveMgzULxtnazoduBcDXwPUFPX/IqFGcVKNrpmrHuGZa9ZNVF1iO95f2MSVTC3g==
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=5jveF6OQe7nkOeNBc0rpMmUYLM1aN+0h5Jbnz6ubBuM=; b=ZfMuDrA5wzCdGPdOTd39Fb80XziXwsW+0NGe8FH8hVZyXNq25tPQyA3aE4Jgt1hzUuwnsHVX4yVmQk9K2HChIHs10cQsi3FtuRwRj89NlONpeqoR2hES7HRUdA5UkJAUkXGXQlkVBDdn8nws7LpR5FOOlRNzaL06xZP5fe7Rf2Aw98whKEkfxaj1Jbc7uSdtQ3Nr4P77WOg7q0vBGcujrksEqHCD4+qjROA7U7/WCXA7EJPCZwN+sN/SzGX8MtzD04G4cWtXHLqF107nyjPsUfUTNFfPktw+pJyOPS6PtGtlR0y1MFY+KiDEOF9a61jgnePea6XWiM9OINuuoEHakQ==
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=5jveF6OQe7nkOeNBc0rpMmUYLM1aN+0h5Jbnz6ubBuM=; b=dMh6cDI+HynehDs8vWYz++tBziCGYEeApCjBy3vJgGossA2VSKpJmF95bKdubQhM6ceXAePDUEd5N9p7g2zdSCIDWnq6ca3t9uuo89hXMFCQBBaJPVXjwUrN+25/1dtzfMiWkDusGD0gQ4gNSdXvTXo4WZcR0njGFnD3A42ZSvU=
Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB4448.namprd11.prod.outlook.com (52.135.39.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.14; Fri, 2 Aug 2019 16:05:50 +0000
Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0%3]) with mapi id 15.20.2136.010; Fri, 2 Aug 2019 16:05:50 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-lsr-isis-rfc5306bis@ietf.org" <draft-ietf-lsr-isis-rfc5306bis@ietf.org>
CC: "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, Uma Chunduri <umac.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis-02
Thread-Index: AQHVSUrslUkXmsWrK0aNc/yn6CTKWqbnwqmA
Date: Fri, 02 Aug 2019 16:05:50 +0000
Message-ID: <9B3FEAB8-A438-4203-87CF-C317B4D17118@cisco.com>
References: <CAMMESswNLuG1FxSPhtL7eR7MveAHMWvmC0zLaL2iHsVVyVe6Bw@mail.gmail.com>
In-Reply-To: <CAMMESswNLuG1FxSPhtL7eR7MveAHMWvmC0zLaL2iHsVVyVe6Bw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [2001:420:c0c4:1008::186]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5cb171f8-d1b0-4faa-daca-08d7176349d5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4448;
x-ms-traffictypediagnostic: MN2PR11MB4448:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MN2PR11MB4448EB2AF315591AFF134B19C2D90@MN2PR11MB4448.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 011787B9DD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6019001)(4636009)(39860400002)(136003)(396003)(366004)(346002)(376002)(269900001)(85664002)(199004)(189003)(14444005)(256004)(81166006)(186003)(102836004)(7736002)(71190400001)(110136005)(11346002)(66476007)(54906003)(6246003)(316002)(71200400001)(446003)(486006)(46003)(8936002)(66556008)(2501003)(36756003)(53946003)(236005)(81156014)(64756008)(476003)(53936002)(76116006)(8676002)(6306002)(4326008)(9326002)(68736007)(6512007)(54896002)(6486002)(53546011)(229853002)(66946007)(66574012)(33656002)(6116002)(2616005)(478600001)(30864003)(86362001)(6436002)(66446008)(606006)(6506007)(25786009)(5660300002)(14454004)(99286004)(2906002)(76176011)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4448; H:MN2PR11MB4221.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ugAbFflEi2/T4FAvei5C3CMF0GXOgD4nu9JtEE4Cx9A2+MDWAlNFGUKG60zDylpYnFbCvOQ9sgzFXTwptDPKRe/aNGo+cHzZAIPF6mBvY8UXrUbvVxs+sRGWRgBo8UGmZJIs66i7m34/DsECSt6K/H1zKOb9HB2XijyA70GCEiajm6kayouJx1wK7wFtxmCBu56mGQ4ts0wuvsHYV/xPY7qma2V0ypnuFTN4SxfXcLbuEsBbee04tWGevO3KQsclXlZ8mQz1WXM1c9IpVeTfLcrqV7abOS3t/3HynNp8b6JYLr6lysCdRv7UHOVYG4Ms+PyEyKv1io1WVN/8GlzbYJkSOL4n0p5mMWUlB1xu0e2xIbO5wYJ8/YzAxK2Sgr3bQyM0jLJ9GoQhTKKwLKro0Tp7zGCgwQ6ZVRrP1HccRcA=
Content-Type: multipart/alternative; boundary="_000_9B3FEAB8A438420387CFC317B4D17118ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5cb171f8-d1b0-4faa-daca-08d7176349d5
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2019 16:05:50.2018 (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: acee@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4448
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Iz6D6rQUXtPdkDfBt49vvhYWdlM>
Subject: Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis-02
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2019 16:06:02 -0000
Hi Alavaro, From: Lsr <lsr-bounces@ietf.org> on behalf of Alvaro Retana <aretana.ietf@gmail.com> Date: Friday, August 2, 2019 at 11:57 AM To: "draft-ietf-lsr-isis-rfc5306bis@ietf.org" <draft-ietf-lsr-isis-rfc5306bis@ietf.org> Cc: "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, Uma Chunduri <umac.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org> Subject: [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis-02 Dear authors: I just finished reading this document. Thank you for your work on it. Why was it decided to create a bis document and not just an Update to rfc5306? Either way works for me, I'm just curious. While this is complicates the document review process and is, in general, more IETF work, the outcome of having a single document specifying IS-IS Graceful Restart (GR) behavior is preferred. Thanks, Acee Knowing that the change in this document, with respect to rfc5306, is new functionality, I tried very hard to not make comments about the unchanged text, I really did. However, there are a couple of significant items that I *have* to comment on (please see in-line)...mostly related to lack of clarity, or opportunities that we should take to improve. In general, I think the text could use a bit more clarity, but I won't insist on it to avoid further changes. The result of the elimination of §2 (Conventions Used in This Document) is that explanations of what restart/restarting and start/starting mean were removed. I think those helped frame the expectations of the operation. In the current document, there is no formal definition of those terms. I strongly believe that the text should be restored, perhaps at the end of the Overview. I will wait until the major items (in-line) are addressed before I start the IETF Last Call. Thanks!! Alvaro. [Line numbers from idnits.] ... 11 Abstract ... 18 This document additionally describes a mechansim for a router to 19 signal its neighbors that it is preparing to initiate a restart while 20 maintaining forwarding plane state. This allows the neighbors to 21 maintain their adjacencies until the router has restarted, but also 22 allows the neighbors to bring the adjacencies down in the event of 23 other topology changes. [nit] s/mechansim/mechanism ... 100 1. Overview ... 158 It is assumed that the three-way handshake [RFC5303] is being used on 159 Point-to-Point circuits. [major] If only assumed, will the mechanism work if 3-way handshake is not used? Why it is not mandated? 161 2. Approach 163 2.1. Timers ... 171 An instance of the timer T1 is maintained per interface, and 172 indicates the time after which an unacknowledged (re)start attempt 173 will be repeated. A typical value might be 3 seconds. [minor] s/A typical value might be 3 seconds./A typical value is 3 seconds. 175 An instance of the timer T2 is maintained for each LSP database 176 (LSPDB) present in the system, i.e., for a Level 1/2 system, there 177 will be an instance of the timer T2 for Level 1 and an instance for 178 Level 2. This is the maximum time that the system will wait for 179 LSPDB synchronization. A typical value might be 60 seconds. [minor] s/A typical value might be 60 seconds./A typical value is 60 seconds. 181 A single instance of the timer T3 is maintained for the entire 182 system. It indicates the time after which the router will declare 183 that it has failed to achieve database synchronization (by setting 184 the overload bit in its own LSP). This is initialized to 65535 185 seconds, but is set to the minimum of the remaining times of received 186 IS-IS Hellos (IIHs) containing a restart TLV with the Restart 187 Acknowledgement (RA) set and an indication that the neighbor has an 188 adjacency in the "UP" state to the restarting router. [nit] I think a comma would help in differentiating the two things in the last sentence: s/and/, and [major] Maybe it's just me, but I don't know what the "the remaining times of....an indication that the neighbor has an adjacency in the "UP" state to the restarting router" is. Please clarify. 190 NOTE: The timer T3 is only used by a restarting router. 192 2.2. Restart TLV .... 200 Type 211 202 Length: Number of octets in the Value field (1 to (3 + ID Length)) 203 Value [minor] s/Length:...(1 to (3 + ID Length))/Length:...(1 or (3 + ID Length)) [nit] Add a line before "Value". 205 No. of octets 206 +-----------------------+ 207 | Flags | 1 208 +-----------------------+ 209 | Remaining Time | 2 210 +-----------------------+ 211 | Restarting Neighbor ID| ID Length 212 +-----------------------+ 214 Flags (1 octet) 216 0 1 2 3 4 5 6 7 217 +--+--+--+--+--+--+--+--+ 218 |Reserved|PA|PR|SA|RA|RR| 219 +--+--+--+--+--+--+--+--+ [minor] Do you intend for IANA to assign the remaining bits? 221 RR - Restart Request 222 RA - Restart Acknowledgement 223 SA - Suppress adjacency advertisement 224 PR - Restart is planned 225 PA - Planned restart acknowledgement [major] The functionality in this document (old and new) depends on a single bit being set. What should a receiver do if more than one bit is set? Are there valid combinations of multiple bits? 227 (Note: Remaining fields are ) [nit] Leftover text... ... 245 Note: Implementations based on earlier drafts of RFC 5306 246 may not include this field in the TLV when the RA bit is set. 247 In this case, a router that is expecting an RA on a LAN circuit 248 SHOULD assume that the acknowledgement is directed at the local 249 system. [major] I think it is time we stop catering to old/non-compliant implementations. The last time that a draft didn't include the System ID was draft-ietf-isis-restart-03 in March 2003: more than 15 years ago!! ... 360 2.2.3. Use of PR and PA Bits ... 376 a. if this is the first IIH with the PR bit set that this system has 377 received associated with this adjacency, then the adjacency is 378 marked as being in "Planned Restart state" and the adjacency 379 holding time is refreshed -- otherwise, the holding time is not 380 refreshed. The holding time SHOULD be set to the "remaining 381 time" specified in the received IIH with PR set.. The "remaining 382 time" transmitted according to (b) below MUST reflect the actual 383 time after which the adjacency will now expire. Receipt of a 384 normal IIH with the PR bit reset will clear the "Planned Restart 385 mode" state and cause the receiving router to set the adjacency 386 hold time to the locally configured value. This procedure allows 387 the router planning a restart to cause the neighbor to maintain 388 the adjacency long enough for restart to successfully complete. 389 Whether or not an adjacency is marked as being in "Planned 390 Restart mode" has no effect on adjacency state transitions. [minor] Is it "Planned Restart state" or "Planned Restart mode" state? 392 b. immediately (i.e., without waiting for any currently running 393 timer interval to expire, but with a small random delay of a few 394 tens of milliseconds on LANs to avoid "storms") transmit over the 395 corresponding interface an IIH including the restart TLV with the 396 PR bit clear and the PA bit set. The "Remaining Time" MUST be 397 set to the current time (in seconds) before the holding timer on 398 this adjacency is due to expire. If the corresponding interface 399 is a LAN interface, then the Restarting Neighbor System ID SHOULD 400 be set to the System ID of the router from which the IIH with the 401 PR bit set was received. This is required to correctly associate 402 the acknowledgement and holding time in the case where multiple 403 systems on a LAN are planning a restart at approximately the same 404 time. [major] "System ID SHOULD be set to the System ID of the router from which the...PR bit set was received. This is required to correctly associate the acknowledgement...where multiple systems on a LAN are planning a restart at approximately the same time." IOW, if the System ID is not set correctly, then the sender of the IIH+PR won't necessarily know the reply is to it... When is it ok to not set the System ID that way? IOW, why is MUST not used? [BTW, I know this is the same text as in 2.2.1...this comment applies there too.] ... 428 While the adjacency is in planned restart state the following actions 429 MAY be taken: [major] The steps below are optional (MAY)....that is ok. (a) talks about a compromised ability to flood updates on a LAN is adjacencies are not reset, which sound very serious to me. What are the considerations for an implementation/deployment to decide using these optional actions? Should they be used on LANs, but not necessarily in other link types (just as an example)? [minor] The actions below are independent of each other, right? It may be worth mentioning that. 431 a. If additional topology changes occur, the adjacency which is in 432 planned restart state MAY be brought down even though the hold 433 time has not yet expired. Given that the neighbor which has 434 signaled a planned restart is not expected to update its 435 forwarding plane in response to signaling of the topology changes 436 (since it is restarting) traffic which transits that node is at 437 risk of being improperly forwarded. On a LAN circuit, if the 438 router in planned restart state is the DIS at any supported 439 level, the adjacency(ies) SHOULD be brought down whenever any LSP 440 update is either generated or received so as to trigger a new DIS 441 election. Failure to do so will compromise the reliability of 442 the Update Process on that circuit. What other criteria are used 443 to determine what topology changes will trigger bringing the 444 adjacency down is a local implementation decision. [nit] s/received so as to/received, so as to [major] "adjacency(ies) SHOULD be brought down...Failure to do so will compromise the reliability of the Update Process on that circuit." When is it ok to not bring these adjacencies down? If the operator already decided to deploy these optional steps, why wouldn't the adjacencies be always brought down? IOW, why is MUST not used? 446 b. If a BFD session to the neighbor which signals a planned restart 447 is in the UP state and subsequently goes DOWN, the event MAY be 448 ignored since it is possible this is an expected side effect of 449 the restart. Use of the Control Plane Independent state as 450 signalled in BFD control packets [RFC5880] SHOULD be considered 451 in the decision to ignore a BFD Session DOWN event [nit] Move the reference to rfc5880 to the first mention of BFD. [nit] s/Session DOWN event/Session DOWN event. ... 467 2.3.1. Adjacency Reacquisition during Restart 469 The restarting router explicitly notifies its neighbor that the 470 adjacency is being reacquired, and hence that it SHOULD NOT 471 reinitialize the adjacency. This is achieved by setting the RR bit 472 in the restart TLV. When the neighbor of a restarting router 473 receives an IIH with the restart TLV having the RR bit set, if there 474 exists on this interface an adjacency in state "UP" with the same 475 System ID, and in the case of a LAN circuit, with the same source LAN 476 address, then the procedures described in Section 3.2.1 are followed. [minor] s/3.2.1/2.2.1 ... 492 On a LAN circuit, the LAN-ID assigned to the circuit SHOULD be the 493 same as that used prior to the restart. In particular, for any 494 circuits for which the restarting router was previously DIS, the use 495 of a different LAN-ID would necessitate the generation of a new set 496 of pseudonode LSPs, and corresponding changes in all the LSPs 497 referencing them from other routers on the LAN. By preserving the 498 LAN-ID across the restart, this churn can be prevented. To enable a 499 restarting router to learn the LAN-ID used prior to restart, the LAN- 500 ID specified in an IIH with RR set MUST be ignored. [major] "the LAN-ID assigned to the circuit SHOULD be the same as that used prior to the restart...churn can be prevented." Are there cases when (without knowledge of other changes) the LAN-ID would be better off being something else? IOW, why would a MUST not fit here? ... 516 On a Point-to-Point link, receipt of an IIH not containing the 517 restart TLV is also treated as an acknowledgement, since it indicates 518 that the neighbor is not restart capable. However, since no CSNP is 519 guaranteed to be received over this interface, the timer T1 is 520 cancelled immediately without waiting for a complete set of CSNPs. 521 Synchronization may therefore be deemed complete even though there 522 are some LSPs which are held (only) by this neighbor (see 523 Section 3.4). In this case, we also want to be certain that the 524 neighbor will reinitialize the adjacency in order to guarantee that 525 the SRMflags have been set on its database, thus ensuring eventual 526 LSPDB synchronization. This is guaranteed to happen except in the 527 case where the Adjacency Three-Way State in the received IIH is "UP" 528 and the Neighbor Extended Local Circuit ID matches the extended local 529 circuit ID assigned by the restarting router. In this case, the 530 restarting router MUST force the adjacency to reinitialize by setting 531 the local Adjacency Three-Way State to "DOWN" and sending a normal 532 IIH. [minor] s/3.4/2.4 ... 567 If an interface is active, but does not have any neighboring router 568 reachable over that interface, the timer T1 would never be cancelled, 569 and according to Section 3..4.1.1, the SPF would never be run. 570 Therefore, timer T1 is cancelled after some predetermined number of 571 expirations (which MAY be 1). [minor] s/3.4.1.1/2.4.1.1<http://3.4.1.1/2.4.1.1> 573 2.3.2. Adjacency Acquisition during Start ... 592 Upon receipt of an IIH with the SA bit set, the behavior described in 593 Section 3.2.2 is followed. [minor] s/3.2.2/2.2.2 ... 642 When the T2 timer(s) are cancelled or expire, transmission of 643 "normal" IIHs (with RR, RA, and SA bits clear) will begin. [minor] A "normal" IIH is mentioned before, but this is the first time that it is described ("with RR, RA, and SA bits clear"). Shouldn't this definition be expanded to include the PR/PA bits? Also, it would be nice if the term was defined earlier in the text: move the parenthesis to the first mention. ... 659 2.4. Database Synchronization ... 670 When (re)starting, a router starts an instance of timer T2 for each 671 LSPDB as described in Section 3.3..1 or Section 3.3.2. In addition to 672 normal processing of the CSNPs, the set of LSPIDs contained in the 673 first complete set of CSNPs received over each interface is recorded, 674 together with their remaining lifetime. In the case of a LAN 675 interface, a complete set of CSNPs MUST consist of CSNPs received 676 from neighbors that are not restarting. If there are multiple 677 interfaces on the (re)starting router, the recorded set of LSPIDs is 678 the union of those received over each interface. LSPs with a 679 remaining lifetime of zero are NOT so recorded. [minor] s/Section 3.3.1 or Section 3.3.2/Section 2.3.1 or Section 2.3.2 ... 710 2.4.1.1. Restarting ... 766 Once the other level's SPF has run and any inter-level propagation 767 has been resolved, the router's own LSPs can be generated and 768 flooded. Any own LSPs that were previously ignored, but that are not 769 part of the current set of own LSPs (including pseudonodes), MUST 770 then be purged. Note that it is possible that a Designated Router 771 change may have taken place, and consequently the router SHOULD purge 772 those pseudonode LSPs that it previously owned, but that are now no 773 longer part of its set of pseudonode LSPs. [major] This is a Normative conflict: "...(including pseudonodes), MUST then be purged....the router SHOULD purge those pseudonode LSPs" How is it possible to always (MUST) purge the LSPs, but not always (SHOULD)? Perhaps s/SHOULD/MUST ... 793 2.4..1.2. Starting ... 815 To avoid the possible formation of temporary blackholes, the starting 816 router sets the SA bit in the restart TLV (as described in 817 Section 3.3.2) in all IIHs that it sends. [minor] s/3.3.2/2.3.2 ... 967 4. IANA Considerations 969 This document defines the following IS-IS TLV that is listed in the 970 IS-IS TLV codepoint registry: 972 Type Description IIH LSP SNP 973 ---- ----------------------------------- --- --- --- 974 211 Restart TLV y n n [major] You're missing the Purge column. [major] This section should also ask IANA to change the reference from rfc5306 to this document. 976 5. Security Considerations ... 1000 If an SA bit is set in a false IIH, this could cause suppression of 1001 the advertisement of an IS neighbor, which could either continue for 1002 an indefinite period or occur intermittently with the result being a 1003 possible loss of reachability to some destinations in the network 1004 and/or increased frequency of LSP flooding and SPF calculation. [major] Please add similar considerations as above for the new bits.
- [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Acee Lindem (acee)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Alvaro Retana