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

Uma Chunduri <umac.ietf@gmail.com> Wed, 29 May 2019 00:09 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 3D11C12018C for <lsr@ietfa.amsl.com>; Tue, 28 May 2019 17:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 RuwARRu_LbBS for <lsr@ietfa.amsl.com>; Tue, 28 May 2019 17:09:10 -0700 (PDT)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 F05C5120152 for <lsr@ietf.org>; Tue, 28 May 2019 17:09:09 -0700 (PDT)
Received: by mail-vs1-xe2e.google.com with SMTP id m1so532164vsr.6 for <lsr@ietf.org>; Tue, 28 May 2019 17:09:09 -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=l6ZQNmzzJTy8IBqVen1pH2cR2ar34uR7/NezQGgC4iw=; b=K8zDMyC8R5KOxrbTystonmKmgDAPj65rGauBCOMkBHC9jIOxVqFSq0RUv2P9roSW4d CBBdd+bSR8NTYlOtcIpkOt2sn9i1h7PDvd/VCrOd8H+1NgBiXSo4DFj7I/tX76VKg1pr nZ/c/YgaUlc2s9yEGlHZQJaEEExNvOW1nhdKNMWDVjADnet3xx3Bt4vo1vfNfijzNG7P PKcnNtWxSwI/zR5TsoNuDorwgen/tPgBaQK7K8XfnxgqSv9HA1QBwsOMr4CM0PxyYXqS ZnhHiZD0r6W4VRUAUzuGNLgdF1NsdNiwtckSpL8EFWsESmyIVSYwjmZAYa+fNG2pEq0c cxOg==
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=l6ZQNmzzJTy8IBqVen1pH2cR2ar34uR7/NezQGgC4iw=; b=E5Q546aIzq2Uaot11bO8Uh/oC6b7JaJWH/Pp65TpWWWM1E4oXnI1GLueLqxF0KTROt KZA7YPiS67DMNoMiZ89UQMvlTvKzV0+IOb5frZbE88UTphtN9je0seim5Gquqlcg9CXO BtfFx7UngvemLa/OkNvSh0lUUa2KsZ2oGkqjt7xTCZ7cr/RRx00I29y1ji3F91amlVVn F/dXSVRNdWVL0zTYJX1P5fDXwFCPYjv5JTNryaC05yOsKrYc2ZkoQIPFw7XoG5KZGR3Q ZcbLIU3SpiXq9idEqDx6uzwJny/1Tva4GWAWZqIJOJo2oLP8Ks4UorPPTrlvBn1TvntZ u4hw==
X-Gm-Message-State: APjAAAX4fJDqe/GQY4UJBj4RB3p5HQ517W/KvICf+oeKZE/R1BZJ6mHf YIa1AM0yykdcOzDFWv50ZRpPArSRw2G4bC+yXx8=
X-Google-Smtp-Source: APXvYqxE7OG2gEutiKTnGXxSCROp1igoWjSMXkVZSSRlAxyZihohHGvgHmAQYjecSHOoc43dVdBIJx0EReUq7Sgd9cE=
X-Received: by 2002:a67:2c4d:: with SMTP id s74mr54527652vss.235.1559088549033; Tue, 28 May 2019 17:09:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAF18ct7jj0sSxs02uAvdHSQcm+iUwYXQpjfXU7g28iBLp9dm5Q@mail.gmail.com> <BYAPR11MB36382E3C1406B04E95813829C1020@BYAPR11MB3638.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB36382E3C1406B04E95813829C1020@BYAPR11MB3638.namprd11.prod.outlook.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Tue, 28 May 2019 17:08:45 -0700
Message-ID: <CAF18ct4f7Rgsk9YXWPRAVf7k-iAfNhvR3FJ_YKykrUUwACh-4w@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000237b730589fb9724"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/jpmocnx--tRyxciDf6f-dlOMSIQ>
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 00:09:18 -0000

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:] 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?

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.