Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 29 May 2019 01:01 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 026061200F1 for <lsr@ietfa.amsl.com>; Tue, 28 May 2019 18:01:40 -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, HTML_MESSAGE=0.001, 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=f+nBBOty; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Q0TzjkNW
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 Hb4Y_2F1391U for <lsr@ietfa.amsl.com>; Tue, 28 May 2019 18:01:37 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B001201A1 for <lsr@ietf.org>; Tue, 28 May 2019 18:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22638; q=dns/txt; s=iport; t=1559091696; x=1560301296; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Lp1jr232PIbktiBsTIrQpQOwsa7WP0/llLliV8DVvsE=; b=f+nBBOtyKZ3exYJAsifxihIh//REunxe15kkUOEwT4F2BRJkHUv9hfNH vxYL7S6VCH+koMjHHdI7Q8xOfK+iIOfGnqQ4fl7bvI/2BF/cuWNzdWl9D 0zU4Ph9/xu15fnuAYHqs4R5zD/yD2N/CxhLg2ms1vUfN36Xz+o6X+sg1k M=;
IronPort-PHdr: 9a23:awfHhBVWvWnnHEsUZiWqaMENmhDV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtank1HcJZXlJ/8FmwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CiAADF2O1c/5FdJa1lHAEBAQQBAQcEAQGBUwUBAQsBgQ4vUANpVSAECyiEE4NHA45/gleJQYkahFCBLoEkA1QJAQEBDAEBIwoCAQGEQAIXgkwjNgcOAQMBAQQBAQIBBG0cDIVKAQEBAQMSEQoTAQEwBwEPAgEIEQQBASsCAgIfER0IAgQOBQgagwGBHU0DHQECDJ4dAoE4iF9xgS+CeQEBBYULDQuCDwMGgTQBi1IXgUA/gRFGgkw+ghpHAQECAYFgK4JdMoImi3qCEoRjiCWMWiw9CQKCDYY0iH2Df5ZJk3CBWo0cAgQCBAUCDgEBBYFWDCWBV3AVgyeCD4NwhRSFP3IBgSiOBQEB
X-IronPort-AV: E=Sophos;i="5.60,525,1549929600"; d="scan'208,217";a="561472346"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2019 01:01:33 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x4T11XUf029089 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 May 2019 01:01:34 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 May 2019 20:01:32 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 May 2019 20:01:32 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 28 May 2019 21:01:32 -0400
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=Lp1jr232PIbktiBsTIrQpQOwsa7WP0/llLliV8DVvsE=; b=Q0TzjkNW7O2jLlreDtk2yBUsUOswVLY53dO0LLjq04dHoiav4vcTwuNa0GVLEQUxtOZ1a8WR5Z916SOCvIrHhp6Jy24TLdUUTdWXD9dZ8NMfzJBT6NDRWUtH+PwUy8CUOThveQ6+RTAeq1QxOwuY3cuV/jOspCpnns6Lxs3Vdzo=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2853.namprd11.prod.outlook.com (52.135.228.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.18; Wed, 29 May 2019 01:01:30 +0000
Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::ace2:8693:202d:5a30]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::ace2:8693:202d:5a30%7]) with mapi id 15.20.1922.021; Wed, 29 May 2019 01:01:30 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Uma Chunduri <umac.ietf@gmail.com>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01
Thread-Index: AQHVElkN3wUOP6FDGEK2SYOIeSpqpqZ6sCXggAaQhYCAAAp+0A==
Date: Wed, 29 May 2019 01:01:30 +0000
Message-ID: <BYAPR11MB36385462A64C3EF6F64464D6C11F0@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <CAF18ct7jj0sSxs02uAvdHSQcm+iUwYXQpjfXU7g28iBLp9dm5Q@mail.gmail.com> <BYAPR11MB36382E3C1406B04E95813829C1020@BYAPR11MB3638.namprd11.prod.outlook.com> <CAF18ct4f7Rgsk9YXWPRAVf7k-iAfNhvR3FJ_YKykrUUwACh-4w@mail.gmail.com>
In-Reply-To: <CAF18ct4f7Rgsk9YXWPRAVf7k-iAfNhvR3FJ_YKykrUUwACh-4w@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=ginsberg@cisco.com;
x-originating-ip: [2001:420:30d:1254:2416:2744:2e8f:3ad0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6b1363bf-ef9d-43b8-6f5f-08d6e3d12fb6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2853;
x-ms-traffictypediagnostic: BYAPR11MB2853:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR11MB28535BCEB82BE0EFF0010330C11F0@BYAPR11MB2853.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0052308DC6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(346002)(39860400002)(376002)(189003)(199004)(51444003)(478600001)(99286004)(14454004)(8936002)(6916009)(76176011)(6506007)(966005)(53546011)(8676002)(7696005)(71200400001)(71190400001)(102836004)(81166006)(53936002)(81156014)(186003)(55016002)(6436002)(9686003)(236005)(14444005)(256004)(229853002)(6306002)(54896002)(476003)(790700001)(52536014)(76116006)(25786009)(68736007)(2906002)(33656002)(66446008)(66946007)(606006)(11346002)(46003)(486006)(6246003)(446003)(86362001)(4326008)(6116002)(66574012)(316002)(7736002)(74316002)(66556008)(64756008)(73956011)(66476007)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2853; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: ImhpPHppR5HHvPSNBBUkPZGHzGN4EBCqLQNgv1kICkPO/HEys4EMadL/IFhlqscjp1Afd97lABb7bNR2DjBciFo9Otb4mR5NEMPNfSiq+Y85vJ5hHiAR0n5t3dREeiqL0qYcZp2Gdp9x88dRLYl//0mETQtppHzDCjdZHVphcZq5/rEIdTyIkHsTppKhU9AdeeNBJpLRWh2YCr+EVOYUqENVfR9hdDNlSt8eioq0e2P7RFGjblkxJe0RGFebsbdnGr3D/RJjtzv4p1SSyPS7pANYXA1Bk0IwVPKiBDDNLG1cLDEPHlzB43YpDUlKkY1rMshY80ZjjqFc//+wlsUfEa+79rBG/yUCmTc4BiHtQDy6L/EcLnn8Kw9ajchJFQtxyRM0pD5PE+qf6DibSgHGyXScg8nSS3yH2QLoBpBm1SM=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB36385462A64C3EF6F64464D6C11F0BYAPR11MB3638namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b1363bf-ef9d-43b8-6f5f-08d6e3d12fb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2019 01:01:30.5950 (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: ginsberg@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2853
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/MZwFth059bMXo_AQalZrAafWWjc>
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01
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: Wed, 29 May 2019 01:01:46 -0000

Uma -

From: Uma Chunduri <umac.ietf@gmail.com>
Sent: Tuesday, May 28, 2019 5:09 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Les,


[Les:] The timers (T1, T2, T3) are NOT relevant to PR/PA.
PR is sent BEFORE a router does a restart to alert the neighbors that the signaling router’s control plane is going away for a time.
RR/RA are associated with what happens AFTER the router has restarted and now wants to reacquire adjacencies/LSDB.

Thx. Yes, I got that.


I do not know what text in the draft suggests to you that there is any relation between PR/PA and RR/RA.


Newly added Section 2.2.3 a says this:

       The "remaining time" transmitted according to (b)
       below MUST reflect the actual time after which the adjacency will
       now expire.

The above is same for section 2.2.1 a, which talks about RR and RA.
This is the reason, I asked, what is the implication of same timer value here for PR/PA.
For example, what are the implications of this new timer times out before the value specified in RA (as PR is obviously initiated before) ? Also see my original question.


[Les:] Tx timers do NOT apply to the neighbors of the restarting router – and they are the only routers whose control plane is alive while the restarting router is reloading.

No offense intended – but your question is bizarre – I really don’t understand what logic leads you to ask it. ☺

[Les:] What constitutes a topology change significant enough to trigger bringing down the adjacency is an implementation decision.
Definition of the conditions is NOT an interoperability issue and therefore does not fall within the scope of the draft.



I would have agreed with the above statement if this is the guidance for the restarting router. Here the topology change is detected by the neighboring router (see your text below)  and you do want a consistent behavior from neighboring node from any vendor.  No?
[Les:] The neighbor is free at any time to declare adjacency to the restarting as down. Obviously, if it does so, this will affect forwarding in the network. Whether the neighbor is making the “optimal choice” based on the topology change is an implementation decision and it is up to the customers to judge whether they are happy w the implementation choice or not. It does not affect interoperability.

We could have been more prescriptive – similar to https://tools.ietf.org/html/rfc3623#section-3.2 – but I think that is sub-optimal. It is possible for a topology change to occur which does not affect forwarding via the restarting node – in which case it isn’t helpful to bring the adjacency down.
Rather than try to detail all possible cases, we have left it as an implementation decision as to how “smart” an implementation wants to be. Given that the neighbor will send an updated LSP of its own reflecting the down adjacency in such a case, the rest of the network will know that there is no longer a path via the restarting router.

It simply isn’t necessary to mandate a behavior.

   Les



Section 2.2.3
"  While a control plane restart is in progress it is expected that the
   restarting router will be unable to respond to topology changes.  It
   is therefore useful to signal a planned restart (if the forwarding
   plane on the restarting router is maintained) so that the neighbors
   of the restarting router can determine whether it is safe to maintain
   the adjacency if other topology changes occur prior to the completion
   of the restart. "


--
Uma C.