Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

Alvaro Retana <aretana.ietf@gmail.com> Thu, 07 November 2019 16:58 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F9A1208A7; Thu, 7 Nov 2019 08:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 PIJQxc40EVFj; Thu, 7 Nov 2019 08:58:33 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 7545112082E; Thu, 7 Nov 2019 08:58:33 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id a11so3863335wra.6; Thu, 07 Nov 2019 08:58:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=BRoOxpxy/RG7FnSNscIprueeNvy0tGd2ok80vQpVh8k=; b=LN//eBw/OuhW7FhZU+mbykZC6AoQtTaMmMQ44KwPcV4+uaUZ2woYp1uMW35hcJunKe Y7R++VAtqF74OykDyYtAA/kB3zOnD+EPYCZ6vK6CtezoVjZppsB3QDJDaInNWG0HO7qY UVJgNGPd4wRV8DMs/F87NJ6VnoNHehb5wkXGkxgJMy5F4C3zhF+BYnlxeZ3JWPal5yuE 56gzeSf4wyX163lRxPS6Cc6pQmLbMeHxtuNUTEbXuS0l/eA3e1r4H39NS39BITbGfjFd hepWsdJDwLP8b84k1khX+irHx9zW8GODe/AArlScWv9YHGZ1WosGebAbvEBei6qyyi1W vm5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=BRoOxpxy/RG7FnSNscIprueeNvy0tGd2ok80vQpVh8k=; b=rHQcDVqhIdF8d1nN6lvaEjMBss+Md4GXlrvsg15cpDpq76J6zkcDRn/Q12dCkTt3gJ S4oUhDJqib6FYZNgwu+mQplg5TVdx3joVwrjMq4WwtI0SHr6AkDvK62DmsbsTnSjA9Id stVeO79HqR/ZuMGKI6nmnX8O7QltOlATGVrTfRdjTXCkDJsI4IC0jId+NjhNkcYNG9Sq D84q2u8aGHur7zbwRt3EuWxAa93Hq1t1t5mP6x1QNaD4UtuU7O1Lrk4invPqBVFZjhIM dv7Zh+lIuexnPsLE0QwS6VrUbDjUeoteGwF3NSy80gx4MdRfNnaLZewEm6P83vafvW22 IJ3g==
X-Gm-Message-State: APjAAAWDAB1RyhGd2t7eNMriAsDhi6is3hLtu+TakLBNtOwMutg/VCKN FeXFipDlJhJOQxH5eTWp2higbuj8qH15mHULdls=
X-Google-Smtp-Source: APXvYqwsYNxj/Rkakxm3tPosOBNP1gv4kK5NQ26lUKbxVOPook77bFSASCJjFnZa5EkmAXNCQZsr1QFQnnzx6cFPi9Y=
X-Received: by 2002:a5d:63d2:: with SMTP id c18mr3919459wrw.365.1573145911910; Thu, 07 Nov 2019 08:58:31 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 7 Nov 2019 08:58:31 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAG-CQxouv9kguDb9Q-vVGRV603nnSSfNCLNLAsLGzTnRA8qMqg@mail.gmail.com>
References: <157255845092.30400.10881471178799546764@ietfa.amsl.com> <CAG-CQxr2OJgHgLZMC0kmK1U6=OhrEggGH0K-zFE9uVXyd9KcqQ@mail.gmail.com> <20191103020302.GZ55993@kduck.mit.edu> <CAG-CQxouv9kguDb9Q-vVGRV603nnSSfNCLNLAsLGzTnRA8qMqg@mail.gmail.com>
MIME-Version: 1.0
Date: Thu, 7 Nov 2019 08:58:30 -0800
Message-ID: <CAMMESsycGJ9Xz_TYfHa673zxV+MM9kp-fHciYkgDJmvfRYtqeA@mail.gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
Cc: Kyle Rose <krose@krose.org>, tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ospf-ospfv2-hbit.all@ietf.org, lsr@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Gl1sVWLOyVoh38mVK-Qw34dB8Xk>
Subject: Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 16:58:36 -0000

On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote:

Padma:

Hi!

See below...

> On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote:
> > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote:
> > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker
> > > wrote:
> > >
> > > > * I'm curious what happens if a router sets the H-bit when it is on the
> > > > only feasible transit path.
> > >
> > > PPE - The router with the H-bit set will not be "on the only feasible
> > > transit path" to other destinations. The H-bit functionality will exclude
> > > the host router from the path calculation in the SPF.
> >
> > I think you are talking about normal operation ("will not be on the only
> > feasible transit path") and Kyle is asking about misconfiguration or
> > similar edge cases.
>
> Thanks for this clarification.
> >
> > Having only read this email thread and not the document itself, I assume
> > that traffic will fail to flow if such a misconfiguration occurred, but it
> > would be good to confirm/refute that.
>
> Yes you are right ... for some cases.
>
> Assuming the router with the H-bit clear is on the only transit path. There
> are several cases see below.
>
> Normal case:
> The router has H-bit set
> (a) All routers in the area support the H-bit then the router is excluded in
> the SPF calculations and traffic will not flow.
> (b) At least one router in the area does not support H-bit then H-bit is not
> active in area. The traffic will flow as per normal OSPF operation.
>
> Misconfiguration case:
> The router has H-bit erroneously set (misconfig)
> (a) All routers in the areas support H-bit then the router is excluded in the
> SPF calculations and traffic will not flow.
> (b) At least one router in the area does not support H-bit then H-bit is not
> active in area. The traffic will flow as per normal OSPF operation.
>
> The Section 8 of the document has a discussion on this.

Yes, there is a discussion in §8, but I think we left out the case
where a rogue router, who is on the only transit path, may set the
H-bit (for no good/valid reason) and effectively partition the
network.  This case is indistinguishable from the normal case where
the operator (still on the only transit path) may consciously decide
to set the H-bit to perform maintenance, for example.

Please add a new bullet to cover this case.

Thanks!

Alvaro.