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

Alexander Okonnikov <> Mon, 27 March 2017 08:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67F02129467; Mon, 27 Mar 2017 01:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aaOOidgPtC9i; Mon, 27 Mar 2017 01:33:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18825120227; Mon, 27 Mar 2017 01:33:01 -0700 (PDT)
Received: by with SMTP id z15so16411516lfd.1; Mon, 27 Mar 2017 01:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=zHns9P5TYU1xK5Yhcx6qjiJd6pstartONdHLnKRqHL0=; b=Oupd0VFFzkYVXC01RfKaPxyGwUlhxTL3kKy0FidgT1SQIT4kBI4saopL50ZbnLUckK Qdtsabx8FzRsB1N+CvTKw1B1Jy+LK0xZTd/zASX9lftGMas3DydgCNrAVqi/pr3iywC1 RJgmmb9LnMw+9dm/ziQLiEjkciNwqUI47c/n8U9vaFSSv/9tQBP6kZBETc1G69j+j7xS zd5LJe2dkGNH9TO6l3ZToGuPt3TmRtD9u35kFNi6OhBpzh8xjCjISfHpivQo/xUpDFKL /K7IW95o73mzJJQRbH02EugkCgAr1FnvnCA9mrpmkDtS9rxSFaf2oKQrJ77tw/KXs5Gn kv1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=zHns9P5TYU1xK5Yhcx6qjiJd6pstartONdHLnKRqHL0=; b=SoLxb0O/He8XaWzOO4I1rHAedje0MUtaL277LJpIG522TaZsQMOmRo8oZwnZ6lFXKH lGgNAzn7b+M58B9ZslNgVB8EdaZKHWTRvpUUQldSNYTEhQEF5YTwF8wZDBmFSc1hyBeE xn3syzP1jXbu/xJk5TF2WAeWhPEMi3ElIPvZkQOI1MlokCL7P2UNAiTEkNJLr/gLBI+H //CxozxGhA9DyONux95cmsxab0HhDTIecTLr9qxVf60lfXjGHMMH6CQg/AD/BjMHjebL NmRNcn8aNjPD3yHPdgx9H1zC5OqNuN9A+dmXhoilhjde2PB8XPGuK+XYoPqx0SRR+XVR yQ0A==
X-Gm-Message-State: AFeK/H2gh3S2ioIuGY6gLLlUmhTadrkI1VGMGJd04sjE8ZcyDhz0VLYNYAVJXSmVc5XQig==
X-Received: by with SMTP id l71mr10280561lfi.93.1490603579263; Mon, 27 Mar 2017 01:32:59 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f72sm1882900lfk.2.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 01:32:58 -0700 (PDT)
To: "Les Ginsberg (ginsberg)" <>, "" <>, "" <>
References: <> <> <fa19698c-a62f-4823-acee-8e2007ba963f@Spark> <>
From: Alexander Okonnikov <>
Message-ID: <>
Date: Mon, 27 Mar 2017 11:32:57 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------EA1EFF063BBD5C1185D2FEFC"
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: Mon, 27 Mar 2017 08:33:04 -0000

Les, many thanks for explanation!

26.03.2017 05:10, Les Ginsberg (ginsberg) пишет:
> Alexander -
> *From:*Alexander Okonnikov []
> *Sent:* Saturday, March 25, 2017 12:26 PM
> *To:*;; Les 
> Ginsberg (ginsberg)
> *Subject:* RE: draft-ietf-isis-auto-conf
> Hi Les,
> My point was to make start-up procedure less disruptive, not a 
> replacement of current one.
> Let's consider two cases:
> 1) Two routers in the network with the same System ID, one is in 
> start-up mode:
> IS in start-up mode can establish adjacencies, but it doesn't 
> advertise its LSP#0 (and doesn't enlist it in its CSNP) until start-up 
> mode timer will be expired or until IS will determine that its System 
> ID is unique. After establishing adjacencies it receives CSNPs from 
> its neighbors. Even if it sees LSP description for its own System ID, 
> it still requests this LSP (rather than generates its new with higher 
> seq num). On receipt of this LSP it further analyses Fingerprint 
> value. If it is the same as its own, then there are two cases: 
> "bening" and "pathological" ones, as specified in draft. In this case 
> we follow DD-LSP procedure, specified in 3.4.6. If Fingerprint value 
> is not the same, start-up router regenerates its System ID and 
> restarts IS-IS process. It allows us to don't make disruption by 
> injecting LSP of start-up router into network and thus replacing LSP 
> of another (already working) router with the same System ID.
> */[Les:] Under current draft, the router in startup mode (call it S) 
> only generates LSP #0 and is forbidden from including IS Neighbors  or 
> IP/IPv6 Reachability. Sequence # is 1./*
> */The router NOT in startup mode (call it N) is guaranteed to have LSP 
> #0  with at least sequence #2 since once it exited Startup mode it 
> added neighbors/prefix reachability. This means the injection of 
> S-00.00(Seq #1) will NOT produce any disruption since the existing LSP 
> N-00.00(Seq # > 1) will be seen by all routers as newer./*
> *//*
> */When N-00.00(Seq # > 1)  is flooded to S, S will realize there is 
> duplicate system-id and will restart with a new system-id./*
> */No disruption to the network has occurred./*
> 2) Two routers in the network with the same System ID, both are in 
> start-up mode:
> In this case, after expiring start-up mode timer, both routers are 
> advertising their LSPs #0 into network. In this case procedure from 
> 3.4.4 is performed (both S-bits are clear), if LSPs were advertised at 
> almost the same time.
> */[Les:] There is no advantage to delaying the sending of LSP #0. In 
> fact there is an advantage to sending it immediately since the two 
> routers will discover more quickly that there is a duplicate./*
> Regarding DIS on broadcast links: it is not clear from text that 
> pseudonode LSP could be generated (along with LSP #0) in case start-up 
> router is to be elected as DIS. Text says that only LSP #0 (without IS 
> Neighbors) could be generated in start-up mode. In this case election 
> of start-up router as DIS will break forwarding between routers in its 
> LAN. But, even if procedure for generating pseudonode LSP is used from 
> 10589 without modifications, it also could be disruptive, in case of 
> duplicate System IDs in the network (not in the same LAN). Keeping in 
> mind that Ethernet links will be used with high probability, there is 
> chance that pseudonode LSP of start-up router will replace pseudonode 
> LSP of existing router with the same System ID (provided that latter 
> was elected as DIS as well, and both use the same LAN ID).
> */[Les:] Prudent implementations – even in the absence of auto-config 
> - delay DIS election on a LAN for a time so that they do not assume 
> that role prematurely i.e. before they have brought up adjacencies 
> with all the systems on the LAN. /*
> */The non-DIS systems cannot safely assume the node they have elected 
> as DIS has actually assumed that role until they get both a LAN IIH 
> with a non-zero LANID and a matching pseudo-node LSP. Purging of the 
> old pseudo-node LSPs should not occur until after the new pseudo-node 
> LSPs have been propagated.  If systems do not do these things then a 
> DIS change will be disruptive even in the absence of duplicate 
> system-ids. Therefore I do not see that any special behaviors are 
> required for auto-config./*
> *//*
> */During this delay there is ample time to discover the existence of 
> duplicate IDs./*
> *//*
> */Les/*
> *//*
> Thank you.
> Best regards, Alexander Okonnikov
> On 25 марта 2017 г., 11:11 +0300, Les Ginsberg (ginsberg) 
> < <>>, wrote:
> 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 []
> 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.
> Les
> Thank you.
> BR,
> Alexander