Re: [Isis-wg] draft-ietf-isis-auto-conf

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Sat, 25 March 2017 08:11 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38BC126D74; Sat, 25 Mar 2017 01:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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
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 J7PYwHWCzmjp; Sat, 25 Mar 2017 01:11:16 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E44C126B6E; Sat, 25 Mar 2017 01:11:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4406; q=dns/txt; s=iport; t=1490429476; x=1491639076; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2z4V3Jj0LLQnVcb9P2wRnQxbZ1YZCIhNTZ/vCWCcqeo=; b=G6YdHDgb9XJd/uFmA1gPKGwbMku1gmJTj3y/wjBj0VC9M/Ma52SWT865 wOtFC8fqcg1V4V4xJXuoxVK/AC4OP3E8amLFrnTPikumR1hQz7oMoWgDZ 881Bc9r1kpYsmI7FhVjBhtgMlgTJM9sHfk9ZxxCLTm54KsVR698Yk+/nR g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAQC3JdZY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbAeDW4oPkU6IF40zgg6GIgIagw8/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEjEUoHBAIBCBEEAQEDAiMDAgICHxEUAQgIAgQBEgiJZwMNCKsCgiaHN?= =?us-ascii?q?Q2DBwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VDhG+CUYUJgl8FnCE6AY4UhC2?= =?us-ascii?q?ROoptiHcBHzhYLFkVQYRYHYFjdYdKB4EpgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.36,218,1486425600"; d="scan'208";a="224681840"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2017 08:11:14 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2P8BE0Q006217 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 25 Mar 2017 08:11:15 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 25 Mar 2017 03:11:14 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Sat, 25 Mar 2017 03:11:14 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>, "draft-ietf-isis-auto-conf@ietf.org" <draft-ietf-isis-auto-conf@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: draft-ietf-isis-auto-conf
Thread-Index: AQHSpJeBr/WQcNWu4EKcia+cO0QRtaGlMJjw
Date: Sat, 25 Mar 2017 08:11:14 +0000
Message-ID: <5ca27479629540269b82a0daf1421abb@XCH-ALN-001.cisco.com>
References: <abbd4431-aea2-a452-0623-5cb6786c9248@gmail.com>
In-Reply-To: <abbd4431-aea2-a452-0623-5cb6786c9248@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.32.32]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/zJd2fBq90WClsOQDZbEO9KzzInk>
Subject: Re: [Isis-wg] draft-ietf-isis-auto-conf
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Mar 2017 08:11:18 -0000

Alexander -

I am not sure why you did not send your comments to the WG list as well.  I have added the WG alias as this may be of interest to other folks in the WG.
Inline.

> -----Original Message-----
> From: Alexander Okonnikov [mailto:alexander.okonnikov@gmail.com]
> Sent: Friday, March 24, 2017 5:09 AM
> To: draft-ietf-isis-auto-conf@ietf.org
> Subject: draft-ietf-isis-auto-conf
> 
> Hi authors,
> 
> 
> Per procedure of protocol operation in start-up mode, router generates its
> LSP#0. Isn't it better to modify procedure such that start-up router will
> suppress generation of its LSP#0 (and omitting its LSP entry in its CSNP), until
> it will obtain full database, and will check presence of duplicate system ID. If
> duplicate system ID is present in the network (LSP with the same system ID,
> but S-bit clear), start-up router will perform change of its system ID. If its
> system ID is unique, it is advertising its LSP#0 into network. With current
> procedure there is possibility for traffic disruption, when LSP of existing
> router with the same system ID will being replaced by LSP of start-up router
> (the same case when two routers with the same system ID in regular IS-IS
> are present in the network).
> 
[Les:] As we have defined the S-bit(Startup) in the Fingerprint TLV and the tie-breaking rules in case of duplicate system-ids  favor the router NOT in startup mode we accomplish the same thing - and also handle the possible case when two routers who come up at roughly the same time have duplicate system-ids - which would have to be handled even we followed your suggestion as eventually the new routers have to send their first LSP.

> Also, the draft doesn't specify when pseudonode LSP should be generated
> (in case of start-up router is on broadcast link and is chosen to be DIS). Per
> current procedure, start-up router is not generating pseudonode LSP. But, in
> case it is DIS from point of view of other routers on the same LAN, previous
> DIS will purge its pseudonode LSP.
> Each other router will calculate start-up router as a new DIS. It also could be
> cause of disruption (absence of pseudonode LSP from new DIS).
> Hence, proposal is to start-up router to set its LAN priority to lowest value
> (0). The draft also could specify that for routers operating in non-start-up
> mode, LAN priority should not be less than 1. Once start-up router has
> finished its start-up mode, it could increase its LAN priority to
> configured/default value.
> 
[Les:] As per the base protocol (ISO10589) a router cannot declare itself DIS until it has at least one neighbor established on the LAN. As duplicate system-id detection via hellos prevents adjacencies from coming up in the event of a duplicate system-id, normal procedures regarding election of DIS can be safely used. Also the base protocol rules about new DIS pseudo-node LSP generation and purging of the pseudo-node LSPs generated by the old DIS can be safely used. 

Clever implementers find ways to avoid the disruption associated w DIS change when a new router comes up by using "make-before-break" logic.

   Les

> 
> Thank you.
> 
> 
> BR,
> 
> Alexander