IETF Logo Mail Archive

Re: [Lsr] Éric Vyncke's Discuss on draft-ietf-ospf-ospfv2-hbit-11: (with DISCUSS and COMMENT)

Padma Pillay-Esnault <padma.ietf@gmail.com> Mon, 02 December 2019 20:44 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 A14D412084B; Mon, 2 Dec 2019 12:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, 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 7PrinEV7qUF3; Mon, 2 Dec 2019 12:44:32 -0800 (PST)
Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 07B80120059; Mon, 2 Dec 2019 12:44:31 -0800 (PST)
Received: by mail-vk1-xa31.google.com with SMTP id i18so402370vkk.7; Mon, 02 Dec 2019 12:44:31 -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=O0Kyn0vyQxidP8gYdPFQxeNq+HPOK2Sfla/81Bfg3QQ=; b=kKY3rLlc/6quttTjHv6V+cPQK4YJEV+OiP4OQXa37lJ4ZmhiCFcBQr62BrtC7UMEUg v3NwGNLn/IWczjRfHX2ppG0Tb/dwK0Q50VUtmDWJ42d73bpfNdoiU7QVCDmERt+rUEYD QKm/uLQDKMZTFzK5tedsiX9zuw+S8pzEdlhBHY9RCXqQwVNPg+EKPxEjF4bNRJyQ5j7R enYmt4jC04YIJXp3oVoxgnP6u5QtAYasHyCgjWHsB2juchrJMuL8/a7VQ0XMii+2u/nb /S7RH7Emq+WYWXIIr2WcTkhkMk+8n0K0aOn1zlDs9dg1+oFNZ+k3yhJqgSTuVr6xMf11 5MRg==
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=O0Kyn0vyQxidP8gYdPFQxeNq+HPOK2Sfla/81Bfg3QQ=; b=RZwlrMzlhvq568lLOUbnMwrAOlvSkQpEv8WBES1kmk/hvL4JW8fxPT9pRPvlJdQT84 aPtPJtKkWzZRWGi81TxyFi8Xyj/r13Df/ObQg9fH44z5ppmKEUq2eQsATXy5J137DM2w HeQLyZ0gc+wr/E4Rbvfo3sUucN0XiN0M7FJ6z3kL34sMOWbjbK4KBE5MoR9r0dAHzxVK r3JgU2hw0PYlTlYIRe/ZdBEc4fMznOPw+YEGBNhlziM5OGWG1UuIWv8ug4gXI+n0IBIm 2BjAHpUJMvZseV55H3IxPVpn/WV7TbQNK0TiiRi4IKoS/XQzkFmQQrYD7S/KLe/ttK1t rWcA==
X-Gm-Message-State: APjAAAXnzm5/I35zPkZB0CElkVnrloo9G2faJNRdCl5GVN67zmMyG3V2 2CQEhwSPJko77bBUVWAI4RQlBmNeuDLFOl5EvNY=
X-Google-Smtp-Source: APXvYqx3ttKjxQj/FsFfKadVurMRW5ZKO98tw3zKSNg78D9NpgqlEa1uXLZHMj8chwFY6uTW+92Z20KPudZoR72aN2s=
X-Received: by 2002:a1f:e243:: with SMTP id z64mr1084672vkg.56.1575319470921; Mon, 02 Dec 2019 12:44:30 -0800 (PST)
MIME-Version: 1.0
References: <157513086016.14490.11992325783200183386.idtracker@ietfa.amsl.com> <CAMMESswJdLAraYvqXHyh3uAyPAH3nYs_eBYMq2gOCiZSsgNiCw@mail.gmail.com> <A17640D1-92F2-4F0A-B6C0-1C4762CD627C@cisco.com>
In-Reply-To: <A17640D1-92F2-4F0A-B6C0-1C4762CD627C@cisco.com>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Mon, 02 Dec 2019 12:44:20 -0800
Message-ID: <CAG-CQxqeJe1COhZN88y5_870=hnh_BNHcOr83ta2JuTkeObBqA@mail.gmail.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, Éric Vyncke via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, Yingzhen Qu <yingzhen.ietf@gmail.com>, "draft-ietf-ospf-ospfv2-hbit@ietf.org" <draft-ietf-ospf-ospfv2-hbit@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000078dfae0598bea58e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/9Vv1jg1bcYO1_zsLCByGMqNoUyQ>
Subject: Re: [Lsr] Éric Vyncke's Discuss on draft-ietf-ospf-ospfv2-hbit-11: (with DISCUSS and COMMENT)
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: Mon, 02 Dec 2019 20:44:37 -0000

Hello Eric

On Mon, Dec 2, 2019 at 12:31 PM Eric Vyncke (evyncke) <evyncke@cisco.com>
wrote:

> Alvaro
>
> I do not mind too much the transient inconsistencies but more about longer
> term inconsistencies (1) hence my question about simulations / tests in the
> absence of mathematical proof.
>
The R-bit has always been in OSPFv3 (AFAIK), so, OSPFv3 does not have the
> same issue.
>
> -éric
>
> (1) having some routers being H-bit aware and other routers not processing
> the H-bit could probably introduce long term inconsistencies and loops.
>
>
As described in section 5
"All routers supporting H-Bit MUST check all the RI LSAs of nodes in the
area before actively running the modified SPF to account for the H-bit in
order to verify that all routers are in routing capability. If any router
does not advertise the Host Router Support capability then the SPF
Modifications (Section 4) MUST NOT be used in the area."

The H-bit aware routers will revert to normal operation if they detect
routers not processing the H-bit. Therefore, if ever there is a discrepancy
it not cause long term inconsistencies nor loops. In effect, H-bit
processing is either done by all or no one in the area.

Let me know if this answers your question.
Padma



> On 02/12/2019, 17:59, "iesg on behalf of Alvaro Retana" <
> iesg-bounces@ietf.org on behalf of aretana.ietf@gmail.com> wrote:
>
>     On November 30, 2019 at 11:21:01 AM, Éric Vyncke wrote:
>
>     Eric:
>
>     Hi!
>
>     > == DISCUSS ==
>     >
>     > -- Section 5 --
>     > The risk of having inconsistent view of the topology with H-bit
> aware and
>     > unaware routers seems possible to me (albeit perhaps only
> transient). Has
>     > this feature been tested / simulated in large scale networks?
>
>     Yes, as with other operations in a network (reconvergence, for
>     example), there is a risk of transient inconsistency.  §5 already
>     makes recommendations to mitigate transient states.  What explicitly
>     are you looking for to address your DISCUSS?
>
>     I'll let the authors reply about tests/simulations.
>
>     Thanks!
>
>     Alvaro.
>
>
>
>

v2.23.0 | Report a Bug | By Email