Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis-02
Alvaro Retana <aretana.ietf@gmail.com> Tue, 13 August 2019 18:48 UTC
Return-Path: <aretana.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 E64981201B7; Tue, 13 Aug 2019 11:48:05 -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, UNPARSEABLE_RELAY=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 G4SR_M48ylz8; Tue, 13 Aug 2019 11:48:03 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 1279112018B; Tue, 13 Aug 2019 11:48:03 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id s15so2846993edx.0; Tue, 13 Aug 2019 11:48:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ajmzCcnUMXy+NffKdIH6M4R15ykSo57yNPETIHkP55U=; b=uZz9LgkOJt39Uvnyj/EHxInit5JwJuo9T3oN2GpnTTwh+MeHwt4YZGf31jNYMYn1nP K+IMjZR/S92SBr5J97D8Id0gvMg4gW6kY22B+Ad7DgKtAOHmpVMFpj4DTHCk9KEyQGOH IoNeYest7ODRuIJHKKsrnDItdU6UXSK9TumF1ZbWLcXyvhRTp0HntqDvN8kFelSxw/ll 6hU0aJdbtyYoIlg01AX8g/NUUm6MkyXW5dUn2jpWhKD+zp+ArSM9aDauZ8btWlXU+gJT ryH+IwKvA+BspisFFpf4O5sFHA7zm0RDQEzD2IeRxCo835Ro6G/WAy/mhK/zvjxEPCzV rLpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ajmzCcnUMXy+NffKdIH6M4R15ykSo57yNPETIHkP55U=; b=SmZNtZez5OgJaF3HgPWJG9vmFwbDzdS8NdxNOECNIHan0K9CyTMv3nKjuneKnDADso nDzxBLTIBP04sZh62txoIiIPtT3qNugx9zWmwroGHPLRjMB9/5e4gA6Flp5hUqD5wYy2 0utp9DvLC10hI4bJbEqNwcjGTuhOW2Lh0HzS0J8NSXQV3N1SZ7JuJsfCyBwSkI4FaHvA wnz8dlMzDrOpbLYoJqt/4kW5qZ9t8ydIvhDmW4bP4PHG9PecR3aEezyDH9ThymH00rWf ryJ9iH9gHAxgj0CgZAsaswtZI5Noz90NPC/i9WJXqvBZtd/gg979Mi7HYVc1DwIobYsn kpng==
X-Gm-Message-State: APjAAAVHkl4HGZ3Ju1x8nVG5EeuLD8rHy6B8d3d+46K2u0wQZHoezrxW kYsXKV1drJiELOwrXPcrE2uxsVXdy9aufJFKUXUvLuju
X-Google-Smtp-Source: APXvYqxwr2CtAgkm05PPcGWoE4CmH+JEhUkM9LAGtn24w4bI/B4BIP5BbKi+p9lYMV/50EoDt5oSEhRJoIOrxhNwqpY=
X-Received: by 2002:a50:c90d:: with SMTP id o13mr4746014edh.148.1565722081614; Tue, 13 Aug 2019 11:48:01 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 13 Aug 2019 11:48:00 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <BYAPR11MB363852870CD71C1E69A9F7EEC1D20@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <CAMMESswNLuG1FxSPhtL7eR7MveAHMWvmC0zLaL2iHsVVyVe6Bw@mail.gmail.com> <BYAPR11MB3638E77F6217B4FDE4BEC0E7C1D90@BYAPR11MB3638.namprd11.prod.outlook.com> <BYAPR11MB3638DAA7DF68C7133DAE529FC1D10@BYAPR11MB3638.namprd11.prod.outlook.com> <CAMMESszKYRu3-Pcx+HZQ3CanHCWENyCtR6o=+i=JgXHFFdryNA@mail.gmail.com> <BYAPR11MB363852870CD71C1E69A9F7EEC1D20@BYAPR11MB3638.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Tue, 13 Aug 2019 11:48:00 -0700
Message-ID: <CAMMESsy38LtvekFaJp4q913ZKXDDT2Rk5G6wVxFFM6ydsuQSew@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "draft-ietf-lsr-isis-rfc5306bis@ietf.org" <draft-ietf-lsr-isis-rfc5306bis@ietf.org>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, Uma Chunduri <umac.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007ddf1b05900414f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/zFkMb7Q-JfdVgt-c837OoDbeVeQ>
Subject: Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis-02
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: Tue, 13 Aug 2019 18:48:06 -0000
On August 13, 2019 at 11:46:10 AM, Les Ginsberg (ginsberg) ( ginsberg@cisco.com) wrote: Hi! ... 245 Note: Implementations based on earlier drafts of RFC 5306 246 may not include this field in the TLV when the RA bit is set. 247 In this case, a router that is expecting an RA on a LAN circuit 248 SHOULD assume that the acknowledgement is directed at the local 249 system. [major] I think it is time we stop catering to old/non-compliant implementations. The last time that a draft didn't include the System ID was draft-ietf-isis-restart-03 in March 2003: more than 15 years ago!! [Les:] While I am in sympathy with your position, the existing RFC has allowed implementations based on early versions of the draft to exist and defined how to interoperate with them. It is therefore conceivable that an implementor simply never chose to update their implementation since they never had an interoperability problem reported. I do not see the value in removing this interoperability. The lack of this support would only be meaningful in the event multiple systems on the same LAN were restarting at the same time – which of course is possible but not probable. I will continue to listen if you REALLY feel strongly about this, but in the spirit of “being generous in what you receive” I left this unchanged. We should have caught and eliminated the problem when rfc3874 was published. <sigh> BTW, the text above should mention rfc3874 and not rfc5306. *[Les:] Well, I did ask where you were when RFC 3847 (not 3874 as I mistakenly mentioned) was approved. **😊* <rant> IMO, catering to non-standard implementations in a formal specification devalues the standards process: if the purpose is to create interoperable implementations, but we’re still going to bend over backwards to allow non-compliant implementations (with the product of the WG, the consensus, etc.), then why are we going through the pain of agreeing on and standardizing anything? We might as well just let anyone implement anything…or never change the original draft if specifications already exist… </rant> In this case, making the System ID optional, and explaining how/when it should be used (as you did above), would fix the issue and bring non-compliant implementations into the fold. IOW, I think we would all be happy if the wording changed from “allow non-compliant implementations” to “this field is optional”…for example: OLD> Required when the RA or PA bit is set. Otherwise this field SHOULD be omitted when sent and MUST be ignored when received. NEW> This field is required when the PA bit is set, and MAY be present when the RA bit is set. Specifically, it is used when multiple systems on the same LAN are restarting {more details}. If the RA or PA bit is not set, this field SHOULD be omitted when sent and MUST be ignored when received. *[Les:] There is no reason to extend this option to PA bit. Legacy issues – if they exist at all - only exist in regards to RA. How about if I rewrite the text with something like this?* *“Very early draft versions of the restart functionality did not include the Restarting Neighbor System ID in the TLV. RFC 5306 allowed for the possibility of interoperating with these legacy implementations by* *stating that a router that is expecting an RA on a LAN circuit SHOULD assume that the acknowledgement is directed at the local system if the TLV is received with RA set and Restarting Neighbor System ID is not present.* *It is an implementation choice whether to continue to accept (on a LAN) a TLV with RA set and Restarting Neighbor System ID absent. Note that the omission of the Restarting Neighbor System ID only introduces ambiguity in the case where there are multiple systems on a LAN* *simultaneously performing restart.”* *??* Yes, that looks good…just to be extra picky about the rfc2119 keywords: s/SHOULD/should It is not Normative in this document. I’ll go ahead and start the IETF LC. You can submit this change now, or as other LC comments come in. Thanks!! Alvaro.
- [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Acee Lindem (acee)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc530… Alvaro Retana