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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Mon, 27 March 2017 08:33 UTC

Return-Path: <alexander.okonnikov@gmail.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 67F02129467; Mon, 27 Mar 2017 01:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
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: 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 aaOOidgPtC9i; Mon, 27 Mar 2017 01:33:01 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 18825120227; Mon, 27 Mar 2017 01:33:01 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id z15so16411516lfd.1; Mon, 27 Mar 2017 01:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.25.21.74 with SMTP id l71mr10280561lfi.93.1490603579263; Mon, 27 Mar 2017 01:32:59 -0700 (PDT)
Received: from [192.168.1.17] (secretmaker-96.ip.PeterStar.net. [217.195.72.96]) by smtp.gmail.com with ESMTPSA id f72sm1882900lfk.2.2017.03.27.01.32.58 (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)" <ginsberg@cisco.com>, "draft-ietf-isis-auto-conf@ietf.org" <draft-ietf-isis-auto-conf@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
References: <abbd4431-aea2-a452-0623-5cb6786c9248@gmail.com> <5ca27479629540269b82a0daf1421abb@XCH-ALN-001.cisco.com> <fa19698c-a62f-4823-acee-8e2007ba963f@Spark> <9a8cd2b8fe5145c3881c6e4363dc1cb7@XCH-ALN-001.cisco.com>
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-ID: <b964ccca-b3d4-bed0-b570-c4994ea61168@gmail.com>
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: <9a8cd2b8fe5145c3881c6e4363dc1cb7@XCH-ALN-001.cisco.com>
Content-Type: multipart/alternative; boundary="------------EA1EFF063BBD5C1185D2FEFC"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/UoXo4wfZCvOHi7ekqbtUahOh6cE>
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: 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 [mailto:alexander.okonnikov@gmail.com]
> *Sent:* Saturday, March 25, 2017 12:26 PM
> *To:* draft-ietf-isis-auto-conf@ietf.org; isis-wg@ietf.org; 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) 
> <ginsberg@cisco.com <mailto:ginsberg@cisco.com>>, 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 [mailto:alexander.okonnikov@gmail.com]
> Sent: Friday, March 24, 2017 5:09 AM
> To: draft-ietf-isis-auto-conf@ietf.org 
> <mailto: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
>