Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-lsr-isis-rfc5306bis-07: (with DISCUSS and COMMENT)

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 19 September 2019 21:39 UTC

Return-Path: <ginsberg@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 97DE2120152; Thu, 19 Sep 2019 14:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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=NDpxO8yQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ustlaZab
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 7WBVTCM5bXY5; Thu, 19 Sep 2019 14:39:26 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A331200C5; Thu, 19 Sep 2019 14:39:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11380; q=dns/txt; s=iport; t=1568929166; x=1570138766; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2Q4OV9IwuIZTL3Xq/ccBkE+RRQ+qcFx5ACwVj8W2qI8=; b=NDpxO8yQ0jBLn6IJgORrSrOrZEqNVnuq6qbGt8klPpbs/amE9UbKHQLg 3zhChlf9uCubh29dfIKsaREBLwD2ZVcqa70WLQ+GJwl3zM1cuLpCDVTlW UPQv+5sdBvB4OIb3ShKfiI8VXeBL+H2s07dsru+MxgR98rYm6fKDo8VXw k=;
IronPort-PHdr: =?us-ascii?q?9a23=3AbMVxORCCGXoBiHoK60tfUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuI//sdCY3BstqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAQA/9YNd/5tdJa1mDg0BAQEBAwE?= =?us-ascii?q?BAQcDAQEBgWeBRSknA21WIAQLKoQig0cDin2CXH6IaI4NgUKBEANUCQEBAQw?= =?us-ascii?q?BASMKAgEBhD8CF4JsIzgTAgMJAQEEAQEBAgEFBG2FLQyFSgEBAQMBEhERDAE?= =?us-ascii?q?BNwEEBwQCAQgRBAEBAwImAgICHxEVCAgCBAENBQgagwGBagMODwECDKFRAoE?= =?us-ascii?q?4iGFzgTKCfQEBBYFHQYJ+DQuCFwMGgQwojAkYgUA/gRFGghc1PoIaRwIBAgG?= =?us-ascii?q?BKgESASEVgnQygiaMUSSCLjWOTY13LUEKgiKHBYUUhG8EhBeCNodLjyKOFog?= =?us-ascii?q?RggiOeAIEAgQFAg4BAQWBaSFEI1gRCHAVgydQEBSBTjhvAQKCSIUUhQQ7cwG?= =?us-ascii?q?BKIx5BAsXgi4BAQ?=
X-IronPort-AV: E=Sophos;i="5.64,526,1559520000"; d="scan'208";a="633976693"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Sep 2019 21:39:24 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x8JLdPcR004076 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Sep 2019 21:39:25 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Sep 2019 16:39:24 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Sep 2019 16:39:23 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 19 Sep 2019 16:39:23 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QbhyreEK4U8OaLVHHbccUUJdj0Sqbv8prRJh/ovUiK0xKht9GQMU/v1XOXXY3Eo8FjtlkcQ/jYTjh0XTleHnmV6TJ+QtqnXOEzGSFteAaNUht7ufht5QDpVZTDOMmSRuJFLMmC4/0DjYTijK1GDiwcHHJ67ygZ3faUAz3pnrQJeMtZDG95Nxyd9yNrGtSGQbDOqOKX92SSX5A4G5mTmsdPlaXiMz800V1k6uIpgA+Yu+ui3Kc/nz05wn1QhZFlwh50m1uHTYXokT04wRcUXowO6zFq6dNV/OYiEG8RcHsWwjfmqdLQb8e1nVNEqGyfdDfkke56zKw7+DG0GqFkgc3w==
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=2Q4OV9IwuIZTL3Xq/ccBkE+RRQ+qcFx5ACwVj8W2qI8=; b=GEjjkVnO6uF31aLnGYRIjcY+6o0/wz/cn9ZgeWPdP9E57fgc2aFAsiPs0gqywfr4c8W8BPyZd8vw1RKPXoJV/MOKySqRw9AQ/g/CXnx0aY3moeaw9Qy3QSJoFI/V1aqdmx7RbI5+srsCt9zZDBvjZHI0hCmBtyJCAxPuj81Mrxy2ZjrycT7u0EILO61NYtNNj6pOB5tZYb4Tnjj8ktT+xl1JvWNsUO1Ig/S3tJUoWFLqvvF9RAtEI4EDwC/RdD3MSf79doQ5msPJWryDTREA0iWkNBXjlsvvnLYXOpiVJvGo19BsJLkCd37QMBzpyV199krt7O2d4DRtM7HA0UaADQ==
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=2Q4OV9IwuIZTL3Xq/ccBkE+RRQ+qcFx5ACwVj8W2qI8=; b=ustlaZabIuk4kzZloIPIcoY2ULYKJAPWLh+xKIbrM6XWqJqUhLDHLDSlNpbG9MSvCLwtPCdfYqv3zXRLHpFGXnuIM2OXz03r38zHBsksNgX5XxFoeyvKwDPZ6MD5DhX5hI/7QIp4NtIE/DZVFwWkTTVo5VL1gz7ReSRryxRl758=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3254.namprd11.prod.outlook.com (20.177.184.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Thu, 19 Sep 2019 21:39:22 +0000
Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::f4d7:dd49:e1da:4474]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::f4d7:dd49:e1da:4474%5]) with mapi id 15.20.2263.023; Thu, 19 Sep 2019 21:39:22 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-lsr-isis-rfc5306bis@ietf.org" <draft-ietf-lsr-isis-rfc5306bis@ietf.org>, Uma Chunduri <umac.ietf@gmail.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "uma.chunduri@huawei.com" <uma.chunduri@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-lsr-isis-rfc5306bis-07: (with DISCUSS and COMMENT)
Thread-Index: AQHVbrdurivznWnWbUK2YUU+1zCfraczhQ6A
Date: Thu, 19 Sep 2019 21:39:22 +0000
Message-ID: <BYAPR11MB36381855CE71F8FF2E3BCB6BC1890@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <156887619712.4539.18342580285245294855.idtracker@ietfa.amsl.com>
In-Reply-To: <156887619712.4539.18342580285245294855.idtracker@ietfa.amsl.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=ginsberg@cisco.com;
x-originating-ip: [2001:420:30d:1254:151f:64d5:a25b:d9c6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 03041c11-8daf-49a3-c2c1-08d73d49d594
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3254;
x-ms-traffictypediagnostic: BYAPR11MB3254:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR11MB3254DE1870027D3A09829857C1890@BYAPR11MB3254.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 016572D96D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(376002)(366004)(39860400002)(199004)(13464003)(189003)(46003)(110136005)(2906002)(478600001)(25786009)(54906003)(6116002)(81166006)(81156014)(6506007)(53546011)(71190400001)(99286004)(71200400001)(66446008)(64756008)(66556008)(66476007)(186003)(66946007)(76116006)(76176011)(52536014)(8936002)(102836004)(7696005)(66574012)(8676002)(966005)(229853002)(14444005)(86362001)(33656002)(486006)(6246003)(305945005)(256004)(6436002)(5660300002)(4326008)(7736002)(74316002)(14454004)(9686003)(11346002)(446003)(55016002)(476003)(316002)(2171002)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3254; H:BYAPR11MB3638.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: 9T1xrE2bCMG5qOiCfcQ/xxYFtwH5m92jDYEBZgoNjdEBxhILelvs7FsRJT09liN5MwC6cYNG25mzbz4QsdN92fwHZPj/u9s9LDi0WFx3pD0hBE7+ecrWOG/Z25+jzaSKWWMd3aJ+QRLHkEX3ev7YT8rb3Iwlgj1ol/S9LzDuVhpTguEQan7yiFj9Pi9+8Sg/CDpJ0PeaOEOyDVUSROVfKgceGP8tpC50yw6mXfOnyLEGJgveKlccTCQCeAV+EI5Ptd7XJnIr923oWxhZ/VMNaAO1zPz/Tt8hdj+VAW4HlsdFFJvpiBJG8NJeACK2W+zEf+7EczfkfPW5x6lvyOaWVDkm5cz5tbIY1oIGzTHkp7sN8BBzmN7/iQRBj5HXFpXN2gS3XfHKq1R7NRweZZpsbo/GEIIMuk6QZ6ehweNyLeY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 03041c11-8daf-49a3-c2c1-08d73d49d594
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 21:39:22.0728 (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: KuFmuDEBGicSRsO0Ni7gWlvy3cEQt4mlF5E7FtNRtlvy1QJ2zFb4IeITwKpQBDjBuf9NfS4Zoevx6XWCNFQksA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3254
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/T86XHxaVgB_fUY-BxYQmNF98YJM>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-lsr-isis-rfc5306bis-07: (with DISCUSS and COMMENT)
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: Thu, 19 Sep 2019 21:39:30 -0000

Ben -

Thanx for the detailed review.
I have posted V8 of the draft in response to your comments.

More inline.

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <noreply@ietf.org>;
> Sent: Wednesday, September 18, 2019 11:57 PM
> To: The IESG <iesg@ietf.org>;
> Cc: draft-ietf-lsr-isis-rfc5306bis@ietf.org; Uma Chunduri
> <umac.ietf@gmail.com>;; aretana.ietf@gmail.com; lsr-chairs@ietf.org;
> uma.chunduri@huawei.com; lsr@ietf.org
> Subject: Benjamin Kaduk's Discuss on draft-ietf-lsr-isis-rfc5306bis-07: (with
> DISCUSS and COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lsr-isis-rfc5306bis-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 3.2 notes that "the presence of [the Restart] TLV indicates that
> the sender supports the functionality defined in this document".  But,
> while that was true for RFC 5306, I don't see how it can be true for the
> extended functionality that's new in this document.  It seems on first
> look that the need for a PR to be acknowledged by a PA means that the
> routers in question will be able to properly determine full feature
> support at runtime, in which case this is essentially an editorial
> issue, but I would like to make sure it's received enough thought, so am
> raising it as a Discuss point to get the needed discussion.
> (We will still need to change this text to reflect reality, though.)
> It's also unclear to me if we need to give more description of the
> behavior when a router planning to restart does not receive (all) the
> necessary PAs -- does it cancel the planned restart?  Fall back to the
> regular RR usage?
> 

[Les:] I have revised the text to indicate that the absence of the TLV implies that none of the functionality defined in the document is supported. 
The requirement to always include the TLV (if supported of course) exists because the absence of the TLV is used by the receiver to immediately conclude that none of the functionality is supported.
In all cases where the TLV is present, there are timers/retries specified when waiting for a response flag so that the (re)starting router will not wait forever.

> It looks like there's an internal inconsistency between Section 3.2
> ("[w]hen transmitting a TLV multiple flags MUST NOT be set.") and
> Section 3.3.2 ("the IIH is retransmitted with both RR and SA bits set").
>  

[Les:] Yes - good catch. The text about legal combinations was recently added - but I overlooked the one case where multiple flags may be set. The text has been revised.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Abstract
> 
> Four paragraphs is perhaps pushing it a bit, for RFC style.  It might
> also be nice to avoid starting two sentences with "This document
> additionally describes", e.g., as Barry suggests.
> 

[Les:] Apologies, but I am choosing to leave the text as is.

> It also seems a little mismatched to me to differentiate between
> "restart while maintaining forwarding plane state" and "restarting",
> since in Section 2 we make the convention that "restarting" means that
> forwarding state is maintained definitionally.
> 

[Les:] It does not seem appropriate to have the abstract depend on definitions which are found in the body of the document - hence the explicit mention of forwarding state in the abstract.

> Section 1
> 
>    In the case of a restarting router process, the first of these is
>    highly undesirable, but the second is essential in order to ensure
>    synchronization of the LSP database.
> 
> Is the convention introduced in section 2 about preserving forarding
> state intended to apply here?
> 

[Les:] Yes.

> Section 3.2.3
> 
>    Neighbors of the router which has signaled planned restart SHOULD
>    maintain the adjacency in a planned restart state until it receives
>    an IIH with the RR bit set, receives an IIH with both PR and RR bits
>    clear, or the adjacency holding time expires - whichever occurs
>    first.
> 
> When might a router want to ignore the SHOULD (and how so)?
> 

[Les:] This is at the discretion of the implementors/deployment. 
There are many choices/variables here. For example, if there are a robust # of alternate paths it might not be of much benefit to maintain the adjacency across the planned restart.
The document is only defining a mechanism which allows for the opportunity to maintain the adjacency.
I would expect that in most cases the request to maintain the adjacency will be honored (hence SHOULD) but if a customer wants to disable this I think this is also fine.

>    c.  on a Point-to-Point circuit, transmission of LSPs, CSNPs, and
>        PSNPs MAY be suppressed.  It is expected that the PDUs will not
>        be received.
> 
> Are there any security considerations here (e.g., a spoofed PR flag
> would cause suppression of updates and potentially DoS)?
> 

[Les:] Security consideration are discussed in Section 6 - more on that below.
The point being made here is that since the control plane of the restarting router is offline for an extended period sending LSPs etc. is of no use - there is nobody home to process them.

> Section 4.1
> 
> I'm a little surprised to see "RX PA" under the "Running Router" table,
> since I thought the "running" categorization was supposed to imply that
> it was not going to restart (which would be a "restarting router").  If
> the categorizations are exclusive, then receiving PA would be an error
> condition.
> 

[Les:] Another good catch. I have moved this to the Restarting Router table.

> Section 6
> 
> I think we should go a bit further about the false-IIH with PR bit set,
> since there is not a protocol mechanism to apply any sanity check to the
> hold time that the recipient is obligated to apply (overriding local
> policy).  Such spoofed values could be unreasonably large, and it may be
> prudent to have a policy filter that rejects implausible values.
> Even if such a policy is present, it seems that a series of spoofed IIHs
> with PR set could force an adjacency to be maintained (absent topology
> changes), by cancelling the PR-bit and then sending a new PR-bit in
> quick succession.
> 

[Les:] The draft currently says:

"If the PR bit is set in a false IIH, neighbors who receive such an
   IIH could modify the holding time of an existing adjacency
   inappropriately."

I believe that covers all of your points above.

> Relatedly, Section 3.2.1's description of the RR/RA bits notes that:
>       "This procedure allows the restarting router to cause the neighbor
>        to maintain the adjacency long enough for restart to successfully
>        complete, while also preventing repetitive restarts from
>        maintaining an adjacency indefinitely."
> It doesn't seem that this property (preventing repetitive restarts from
> maintaining an adjacency indefinitely) still holds for PR/PA with a
> neighbor router that is (mis)behaving in a certain way.  Explicitly
> noting this disparity seems reasonable to me.
> 

[Les:] If a router sends PR and then does not actually restart, the correct behavior on the neighbor is covered in Section 3.2.3:

"Neighbors of the router which has signaled planned restart SHOULD
   maintain the adjacency in a planned restart state until it receives
   an IIH with the RR bit set, receives an IIH with both PR and RR bits
   clear, or the adjacency holding time expires - whichever occurs
   first."

   Les