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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F38BC126D74; Sat, 25 Mar 2017 01:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J7PYwHWCzmjp; Sat, 25 Mar 2017 01:11:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E44C126B6E; Sat, 25 Mar 2017 01:11:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.36,218,1486425600"; d="scan'208";a="224681840"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2017 08:11:14 +0000
Received: from ( []) by (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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 25 Mar 2017 03:11:14 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Sat, 25 Mar 2017 03:11:14 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Alexander Okonnikov <>, "" <>, "" <>
Thread-Topic: draft-ietf-isis-auto-conf
Thread-Index: AQHSpJeBr/WQcNWu4EKcia+cO0QRtaGlMJjw
Date: Sat, 25 Mar 2017 08:11:14 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] draft-ietf-isis-auto-conf
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.

> -----Original Message-----
> From: Alexander Okonnikov []
> Sent: Friday, March 24, 2017 5:09 AM
> To:
> 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.


> Thank you.
> BR,
> Alexander