IETF Logo Mail Archive

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

Padma Pillay-Esnault <padma.ietf@gmail.com> Sun, 03 November 2019 19:28 UTC

Return-Path: <padma.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 B1FFF120086; Sun, 3 Nov 2019 11:28:26 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 NBYoZC2JIUWq; Sun, 3 Nov 2019 11:28:24 -0800 (PST)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 03D24120052; Sun, 3 Nov 2019 11:28:24 -0800 (PST)
Received: by mail-vs1-xe29.google.com with SMTP id v10so9655976vsc.7; Sun, 03 Nov 2019 11:28:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/WqS/9/5kL8xkE7k5Du2+OG4I7qlnI4vnmN9AVK6qCU=; b=IlARF3cjjXBSvqkQpKdugKY+zrp/eiS4nj4sqYUv8Q7WJR+xSBARbz0s1/rJRlshgE m9Uz1uRWjdVEfh0tdtgRkw423s6eFuYAJlk40/4XYtEQxfBcul8P+PuqYzRPoa4EM1bE lMOvutYbU/O7kNx4fGH9Oq4scHEx9BjQUEwPoV9hP3X5u/Ie5z7jxB3na5JfU6f384vS +nta8v1h4SLTOm7Nf/MMmj/R1jAolOYKvkbmKy1Eed9wdaGUueEAQtIae9zjXLFarwN4 Xrp2i+dc2WrwdH+tFxF2hRDgckmcozetfEO3khgcj36J9YQ4lYGxVz4BCSgl0wnZVn1l uDbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/WqS/9/5kL8xkE7k5Du2+OG4I7qlnI4vnmN9AVK6qCU=; b=NJP7Kwgs4NBtVfDRHcLt+b6HRDgmyjdf+l4JQnfWYcqtVgdIjMMkuzF01RHcalsCng IgkkntUzEOyxhTGur4sK5SZXEnVJ7MWdYzjCKweyntqNFqiizznYwLy3cSFWpsU0NV6I ZIzPZqLnZGB7Wmf9A0e2Wh3IVw2VCyuL7sdOsj4Nug6rn3F3UD4cebajLs1qRQvlzsOs T4iEAKuWlxBIGq9mNPew24PjNcG3qaHSSP7LA4uPmMS2hlPscmgmsr4erb1DU/Q2RVQX RwmUI8UHqjDen4o+Qd3tI0O+JPqiiafgBH94l6HoyQc9UMiNknU947hMLLlVjAmA7tqG hYMQ==
X-Gm-Message-State: APjAAAW8xnre9pBQKF7PEoZR9VyY1G2NLEH3UhSI+UG4ocRNSog2AfYc dj1dh1wT4u6ecFF14zZD+ucP0bU1kwheTW8BpPA=
X-Google-Smtp-Source: APXvYqz0KaOeyoWLgmhDe7iGl2/n55FL7mZhqZzjuSxsRozaaxHc8xGz4d/9QTXbABL2C2KhmQrfQfhkkaVY5vSOb6Y=
X-Received: by 2002:a67:b917:: with SMTP id q23mr3379716vsn.205.1572809302926; Sun, 03 Nov 2019 11:28:22 -0800 (PST)
MIME-Version: 1.0
References: <157255845092.30400.10881471178799546764@ietfa.amsl.com> <CAG-CQxr2OJgHgLZMC0kmK1U6=OhrEggGH0K-zFE9uVXyd9KcqQ@mail.gmail.com> <20191103020302.GZ55993@kduck.mit.edu>
In-Reply-To: <20191103020302.GZ55993@kduck.mit.edu>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Sun, 03 Nov 2019 11:28:11 -0800
Message-ID: <CAG-CQxouv9kguDb9Q-vVGRV603nnSSfNCLNLAsLGzTnRA8qMqg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Kyle Rose <krose@krose.org>, lsr@ietf.org, tsv-art@ietf.org, draft-ietf-ospf-ospfv2-hbit.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cce8dd059676338c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/qKPSA_1R1rUySpZTDanYUBZuJ68>
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: Sun, 03 Nov 2019 19:28:27 -0000

Hi Ben

On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> Hi Padma,
>
> On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote:
> > Hi Kyle
> >
> > Thank you for your review
> >
> > Please see below PPE
> >
> > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker <
> noreply@ietf.org>
> > 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.

Hope that this addresses your comment.

Thanks
Padma

>
> Thanks,
>
> Ben
>

v2.23.0 | Report a Bug | By Email