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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Sat, 25 March 2017 19:28 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 23A1E127071; Sat, 25 Mar 2017 12:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.591
X-Spam-Level:
X-Spam-Status: No, score=-1.591 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, LOCALPART_IN_SUBJECT=1.107, 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 dnvOSgfoLvbo; Sat, 25 Mar 2017 12:28:33 -0700 (PDT)
Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 AAF8F126DEE; Sat, 25 Mar 2017 12:28:31 -0700 (PDT)
Received: by mail-lf0-x241.google.com with SMTP id x137so2497222lff.1; Sat, 25 Mar 2017 12:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=Zn37Ray5Yf6nurssh87gZylw9llskJQmwC/vA9DBrlk=; b=GgqpArZSGIYsee/fqDoas0Bh0aWQjk/7MMgrlD2q9xHibOXxti9XUK+SIsQR/qbZ4C bgSnUEGf/pN5dj6Aaf24tvvuxcATyNicVuWLrAxFSjxVWAVgVvmI47OsE6g/uUadELVO rrd7e6FuM93gWvXSl7DYmL2WOO6/Rnq17hNAQ22QdW90/jVSnc0OPDallR0tCX9hRYmC stsnF277YNcBYzyQZgBnwuVnEKyhd2HEa/H4P3hzoKhrxoZii6YcBY8HH98CB2XSP1J2 xodEd5S1CvYiU6S1PDaTU270jF8vGgJQplU9swij6VcdWCrt81LpOd3byr1Mjt9AaIiU fowg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=Zn37Ray5Yf6nurssh87gZylw9llskJQmwC/vA9DBrlk=; b=siJK6pRt6JTU5YPNr5gd+v8POEzjpoVf+axHl/xCvvC4P4dpNg2BMGZsKRFBHtpwtN ZHkDKe+/JPQvevi+eH/mQ02w37xanXVecfLRT76sKGzQSXHHbZhpwL8viJ7dhelY2wls Ok55QEjJKQwTgwgo+V7f+VB802cYlDAMmgvFQ4F7htOuYiJRqJtkkVqedgi1snAWZGNm MAEbsH6g4shPnTZs0eBndF0BzXTbhGlKqmpey54GBIKI9P1Krg8gmSF+1LunS58fMLg9 QWC5x+ObN+Owxf+IN9xQ6YUCMdN23HUvNWMtV7ut/C7smLQpIpR5rhR3Cks0RLp37ayI y/Jg==
X-Gm-Message-State: AFeK/H2PZZrERsJ90phnOufb6lcYL2Ag7fb6dhVXVrzxsnA8LNm6uJjrxZebkDaSslgM/g==
X-Received: by 10.25.22.214 with SMTP id 83mr7125198lfw.79.1490470109933; Sat, 25 Mar 2017 12:28:29 -0700 (PDT)
Received: from [10.0.1.2] ([109.248.36.241]) by smtp.gmail.com with ESMTPSA id i136sm1043313lfg.61.2017.03.25.12.28.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Mar 2017 12:28:29 -0700 (PDT)
Date: Sat, 25 Mar 2017 22:25:50 +0300
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
To: "=?utf-8?Q?draft-ietf-isis-auto-conf=40ietf.org?=" <draft-ietf-isis-auto-conf@ietf.org>, "=?utf-8?Q?isis-wg=40ietf.org?=" <isis-wg@ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Message-ID: <fa19698c-a62f-4823-acee-8e2007ba963f@Spark>
In-Reply-To: <5ca27479629540269b82a0daf1421abb@XCH-ALN-001.cisco.com>
References: <abbd4431-aea2-a452-0623-5cb6786c9248@gmail.com> <5ca27479629540269b82a0daf1421abb@XCH-ALN-001.cisco.com>
X-Readdle-Message-ID: fa19698c-a62f-4823-acee-8e2007ba963f@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58d6c4dc_6b8b4567_3972"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/OVVuTYhOYZA0ZHQhIH-LgsOKOjk>
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 19:28:36 -0000

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.

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.

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).

Thank you.

Best regards, Alexander Okonnikov

On 25 марта 2017 г., 11:11 +0300, Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>, 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
> > 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
>