IETF Logo Mail Archive

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

Benjamin Kaduk <kaduk@mit.edu> Sun, 03 November 2019 02:03 UTC

Return-Path: <kaduk@mit.edu>
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 D64FE120077; Sat, 2 Nov 2019 19:03:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 cPMUu65wUmDS; Sat, 2 Nov 2019 19:03:09 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AE4120013; Sat, 2 Nov 2019 19:03:08 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA3232vF024435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 2 Nov 2019 22:03:05 -0400
Date: Sat, 02 Nov 2019 19:03:02 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
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
Message-ID: <20191103020302.GZ55993@kduck.mit.edu>
References: <157255845092.30400.10881471178799546764@ietfa.amsl.com> <CAG-CQxr2OJgHgLZMC0kmK1U6=OhrEggGH0K-zFE9uVXyd9KcqQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAG-CQxr2OJgHgLZMC0kmK1U6=OhrEggGH0K-zFE9uVXyd9KcqQ@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Ae9CoDPYg2dQNt7vVtBh5tRuirY>
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 02:03:11 -0000

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.

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.

Thanks,

Ben

v2.23.0 | Report a Bug | By Email