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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 30 May 2019 05:09 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 9FE831200DB for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 22:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, 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=XDSfWiCA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ip8qA4dI
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 AcJM_32YKHkw for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 22:09:49 -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 9EB81120077 for <lsr@ietf.org>; Wed, 29 May 2019 22:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58990; q=dns/txt; s=iport; t=1559192988; x=1560402588; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gl2Rx7n6y0Npw+/QumAUMPWW+wnMJJ2P0SsFDkT63kI=; b=XDSfWiCAT4CVhtE/ZujmIo2TF+MjtehepazAhx6hpV6cQYWoWGl5alDF fwiw2mLd24qKB+BEzVo88IGosUIz94DWWFRojcFt/eFVMSoKW4y/42CT8 gksUXpM855d83Ni9cSbgpq/iBSP0qwChHV5rbowWDumgLfCNFyoPdy/Gh w=;
IronPort-PHdr: 9a23:fcsGMRSbzZ2RkxFDNyyY7GMqvNpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOiM7Gt9IWUVq13q6KkNSXs35Yg6arw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CiAQBcZO9c/5pdJa1lHAEBAQQBAQcEAQGBVAQBAQsBgQ4vJAUnA2lVIAQLKIQUYoJlA45ygleJQo1rglIDVAkBAQEMAQEjCgIBAYRAAheCXiM3Bg4BAwEBBAEBAgEEbRwMhUoBAQEEEhEKEwEBNwEPAgEIEQQBASEBBgMCAgIfERQJCAIEDgUIEQmCNUyBHU0DHQECDJ4jAoE4iF9xgS+CeQEBBYUIDQuCDwMGgTQBi1MXgUA/gRABRoJMPoIaRwEBAgGBYCQHCYJUMoImiygaCoJGhGWCGoYSjF8sPgkCgg2GOIkChACCH4ptiUqTfYFejSECBAIEBQIOAQEFgWUigVhwFYMngg8MF4NNhRSFP3IBgSiKQASCTgEB
X-IronPort-AV: E=Sophos;i="5.60,529,1549929600"; d="scan'208,217";a="562251618"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 May 2019 05:09:47 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x4U59kLA014283 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 May 2019 05:09:46 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 30 May 2019 00:09:45 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 30 May 2019 01:09:45 -0400
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 30 May 2019 01:09:45 -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=gl2Rx7n6y0Npw+/QumAUMPWW+wnMJJ2P0SsFDkT63kI=; b=ip8qA4dIMtnEO99NgVpLpCfPSokSeHe/owCNBNCDrGwFbwkeR5c2C357IDF0LJZKEqdyTudirXhhONl/P/ONxcnd5dT5jCG/ynk8mtxQdcRb/+camNX/ZznaddAzEMLgXq4byqG2aQpel+G4mJNX5JDRDz+DLzMgr0U+gttRahk=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3749.namprd11.prod.outlook.com (20.178.238.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.16; Thu, 30 May 2019 05:09:44 +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; Thu, 30 May 2019 05:09:44 +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+0IABpdKAgAAv3nA=
Date: Thu, 30 May 2019 05:09:44 +0000
Message-ID: <BYAPR11MB3638E653B6E6BF102D2AB133C1180@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <CAF18ct7jj0sSxs02uAvdHSQcm+iUwYXQpjfXU7g28iBLp9dm5Q@mail.gmail.com> <BYAPR11MB36382E3C1406B04E95813829C1020@BYAPR11MB3638.namprd11.prod.outlook.com> <CAF18ct4f7Rgsk9YXWPRAVf7k-iAfNhvR3FJ_YKykrUUwACh-4w@mail.gmail.com> <BYAPR11MB36385462A64C3EF6F64464D6C11F0@BYAPR11MB3638.namprd11.prod.outlook.com> <CAF18ct6BDdx5+oNLinJjZpAq1u0xta9qyxuZhmtPxQ4SuotDfw@mail.gmail.com>
In-Reply-To: <CAF18ct6BDdx5+oNLinJjZpAq1u0xta9qyxuZhmtPxQ4SuotDfw@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:c0c8:1008::275]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a2a57a65-5b5c-4339-742c-08d6e4bd0759
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB3749;
x-ms-traffictypediagnostic: BYAPR11MB3749:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR11MB37497872211B5A8AD8FB26BCC1180@BYAPR11MB3749.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 00531FAC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(346002)(39860400002)(396003)(189003)(199004)(51444003)(5660300002)(86362001)(7736002)(966005)(2906002)(6116002)(81166006)(478600001)(33656002)(8936002)(8676002)(11346002)(186003)(790700001)(25786009)(46003)(52536014)(554214002)(68736007)(14454004)(81156014)(446003)(53936002)(486006)(4326008)(55016002)(102836004)(6506007)(53546011)(6246003)(14444005)(66574012)(606006)(99286004)(229853002)(64756008)(66446008)(74316002)(66946007)(54896002)(236005)(6436002)(66476007)(66556008)(316002)(73956011)(256004)(7696005)(6916009)(6306002)(76116006)(71200400001)(71190400001)(53946003)(76176011)(9686003)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3749; 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: I4oebWO+sgjiGBvYwh33Lj0LToUHMkgxRbEWSvXTT4PWongce0Ygq4UQl9JaL3OJFSVmjMlF3oM76hOn029xmGNbdhIDPI1NPydJbRUQ8qlaq6rqwEoUYt8YUQIjmHFvmK5rDnZaS+ur/82IMTSAKazyobg/d8YeiNfUvhydR8SUAdYZrGAiWQhfk5ehqB+F3ODwnQDiRfvIAPi9HtAIhnF/wmbMT+DfNkJQ+teeLI94SB7DvI8o9CHOtAVnPA/GzKaIVhsoMd6AgzGUugYBPN+toaFcTxVBNPHoIsEnivKIBfNyVgIrZYlzJzGzmkd1uM3KwY/LBbwMkq9dgo51fjiABWcutV+nFNFd4Afbrdft2hL0UXValQ6hCnV5O3waW5iU/GCsanMB5bow2T1TPQYb2CYJc/Jap3sz1RBls+Y=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3638E653B6E6BF102D2AB133C1180BYAPR11MB3638namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a2a57a65-5b5c-4339-742c-08d6e4bd0759
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2019 05:09:44.0909 (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: BYAPR11MB3749
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/dKz3M244WFGTMrE3s-V7Qy6SvYg>
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: Thu, 30 May 2019 05:09:52 -0000

Uma –

Hopefully we are making progress this time.
Replies inline. Look for [Les2:]

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

Les,

Replies in-line [Uma1]:


On Tue, May 28, 2019 at 6:01 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:
Uma -



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.

[Uma1]: Yes. Who said it's otherwise?
[Les2:]  Well you have repeatedly asked about T3 in the context of  PA – and I have repeatedly said “not relevant”.
But as you indicate you get that, let’s agree to move on.

              You are simply not answering what I was asking.  I have been taking about restarting router when it receives PA with hold time set as specified in 2.2.3 (re-read my original question).
              OK, let me ask this differently:
              You added the first 2 events to the 5306 table in section 3.2 as shown below. But I didn't see "RX PA" event. Perhaps you need to specify what you would do based on the newly added text in 2.2.3.
               Also specify:
               What is the impact on restarting router when the hold time value received in PA and RA are the same/different values?
               Unlike receiving RA would cause T3 to be set to prepare for the worst; describe the actions of a restarting router has to when receiving PA.
               You ought to be doing something with hold time you received with PA, what is it?
[Les2:] OK – now I understand your question.

RA is associated with post-restart activities. The restarting router has rebooted and is attempting to reestablish adjacency/LSPDB synchronization in a modest amount of time – which is constrained by the Remaining Holdtime sent by the helper router along w RA. That is then used by the restarting router to bound T3 because we want to complete LSPDB synchronization before the helper router times out the adjacency.

PA is associated with pre-restart activities. Once received, the restarting router knows that the helper router is aware of the planned restart and the restarting router knows it is safe to actually do the restart. The value of the Remaining Holdtime that came along w the RA is only to be able to confirm/report how long the helper router will allow the restarting router to come back to life. This value can’t be used by the Restarting Router (e.g., IS-IS obviously cannot alter how long it takes for the router to reload) – but it might be useful as a debug mechanism in cases where some flapping occurs associated with the restart.

I think there are a few things that could be clarified in the text:

1)State what I have written above
2)Add Receive PA into the state machine diagram (as you suggested)
3)We failed to mention that when sending the PR the restarting router should set the Remaining Holdtime to a value large enough to allow for the router reload to occur. This will serve as the value the helper router should use to maintain the adjacency in the absence of hellos while the restarting router is reloading

I will spin a new version with those changes.

                        3.2.  Restarting Router

  Event      | Restarting         | ADJ Seen  | ADJ Seen  | SPF Wait
             |                    |    RA     |   CSNP    |
 ===================================================================
  Restart    | Send PR            |           |           |
    planned  |                    |           |           |
 ------------+--------------------+-----------+-----------+------------
  Planned    | Send PR clr        |           |           |
   restart   |                    |           |           |
    canceled |                    |           |           |
 ------------+--------------------+-----------+-----------+------------
  Router     | Send IIH/RR        |           |           |
   restarts  | ADJ Init           |           |           |
             | Start T1,T2,T3     |           |           |
 ------------+--------------------+-----------+-----------+------------
  RX RR      | Send RA            |           |           |
 ------------+--------------------+-----------+-----------+------------
  RX RA      | Adjust T3          |           | Cancel T1 |
             | Goto ADJ Seen RA   |           | Adjust T3 |
 ----------- +--------------------+-----------+-----------+------------



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


[Uma1]: You said an obvious statement above that "Tx timers do not apply to neighbors of the restarting routers.." while I am asking about restarting router who received PA with holding timer value set.  No offence intended, but it's the bizarre response I never expected from you! :)

[Les2:] Apologies, but I really was struggling to understand where you were coming from. Thanx for persevering.  I think we have fairly traded “bizarre”. Let’s be at peace now. ☺

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.

[Uma1]: Precisely. This is what I am looking for and I am not sure why describing this won't help to have a consistent behavior  on neighboring node implementing this feature..  You gave a very good example where it is described (no sub-optimal).

[Les2:] I would really rather not be prescriptive here. I don’t think it helps – and now that Acee has indicated most implementations ignore the prescriptive text present in RFC3623, I am encouraged that we have taken the right approach in leaving this up to the implementation. I think we will have to agree to disagree on this.

   Les

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.

[Uma1]: There is no rocket  science here; any implementation should avoid bringing down the ADJ for unrelated topology changes in a remote place which has no bearing or involvement of the restating router. For the record, IMO this need to be  clarified (but that's up to you if you choose not to specify and keep this for only smart implementations!).


Cheers!
--
Uma C.