Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01
Uma Chunduri <umac.ietf@gmail.com> Thu, 30 May 2019 01:56 UTC
Return-Path: <umac.ietf@gmail.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 5C2A41200F4 for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 18:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Np9ViDdJQLEv for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 18:56:15 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDAF120025 for <lsr@ietf.org>; Wed, 29 May 2019 18:56:15 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id g24so1320585vso.8 for <lsr@ietf.org>; Wed, 29 May 2019 18:56:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DbsRFOxeDdSA5nTqQ3h2mzkpsyp71dxqjggFOQxWWOg=; b=LlaR5exGfywqMMUvtqNYoPZbdYDhSvm0KoZpSQ/sdMp6Rp4CfhPqT14WZuMThahxJe MzxYbJo//gxjPu+/roR0ugI06XUZh3EBd912OzEpi04EoO1dUDZ0QqKwwNXM27+QjLcQ kS7vPG1mLujlcfJNA9wbq77cvqtNLPznTaYzrRHoMj29U8IDB7W/ZFQsI+4VVSV3seXJ Y7IWBfX8DNlakvnCFCHi7yE+SQpVuNlqOVufgh6S3jFWkWfYUz8VYyewLcofd609ldxp NRcigxhaHR/QwH0bCBTdibo0wXlq+M6mG9WXg1UbCeiATvyVbkDjY2J2da9amC/wpWo3 Y/jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DbsRFOxeDdSA5nTqQ3h2mzkpsyp71dxqjggFOQxWWOg=; b=RRskkywQuLyjCZvnkfW52n78YGolsjtdnEL+eiKoALRmVFLzIxqjYB2T69JMZ8ob2E DyrYYzzJfu9GM6YON7Sl/Uqbp1uY0QXmrI5OVNRDBHW7YNVHM6WG/oNILkO7yLd81nJ3 ih4zvYbsKAm5bRtMp9ZnxJaX7cwDJ3oo0HcCnMntncqYdhg/7cVbAjM9JHRG6+VEkcW9 ykkR6zxLLf/e8wpYZ8piePDJT/pHbEl9IDbYkyaVx6QM99k9ibeZGLHiCv79k+RcW2bJ eZWV/73QAsvcxVvOs2zgDTMLg/PY4m0u4TxOSVWiInN0iNvcY8UfUpbDfI4LFitgLoDH VkTA==
X-Gm-Message-State: APjAAAWteoQUTB0j18DyJxLO8ZYB98UTSQA9KiNlfhluoDzLZOD5HOe9 h8l+9ACu5xDvaLZRkhT5TAoIY+kUQKRW4Pf06cQ=
X-Google-Smtp-Source: APXvYqyj51sT+cQYZjeEot3Y78dyb0HZ0sCjWBI56r296KmxG4yxPApHsnZWb14W1t9SJM2nfMDbCCJdiTVVYLJ3bvs=
X-Received: by 2002:a67:8c04:: with SMTP id o4mr575632vsd.19.1559181374525; Wed, 29 May 2019 18:56:14 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <BYAPR11MB36385462A64C3EF6F64464D6C11F0@BYAPR11MB3638.namprd11.prod.outlook.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Wed, 29 May 2019 18:56:03 -0700
Message-ID: <CAF18ct6BDdx5+oNLinJjZpAq1u0xta9qyxuZhmtPxQ4SuotDfw@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f817ba058a11335d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/JjHIF1h9vekI3-M63K__XCepluk>
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 01:56:19 -0000
Les, Replies in-line [Uma1]: On Tue, May 28, 2019 at 6:01 PM Les Ginsberg (ginsberg) <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? 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? 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. **J* > > [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! :) *We could have been more prescriptive – similar to > https://tools.ietf.org/html/rfc3623#section-3.2 > <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). *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.
- [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Uma Chunduri
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Les Ginsberg (ginsberg)
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Uma Chunduri
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Les Ginsberg (ginsberg)
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Acee Lindem (acee)
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Uma Chunduri
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Uma Chunduri
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Les Ginsberg (ginsberg)
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Les Ginsberg (ginsberg)
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Uma Chunduri
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Les Ginsberg (ginsberg)
- Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Uma Chunduri