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 >
- Re: [Isis-wg] draft-ietf-isis-auto-conf Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-ietf-isis-auto-conf Alexander Okonnikov
- Re: [Isis-wg] draft-ietf-isis-auto-conf Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-ietf-isis-auto-conf Alexander Okonnikov