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

Padma Pillay-Esnault <padma.ietf@gmail.com> Thu, 31 October 2019 18:17 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 6551512008B; Thu, 31 Oct 2019 11:17:32 -0700 (PDT)
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 dosU6QMdBaeL; Thu, 31 Oct 2019 11:17:29 -0700 (PDT)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 92F0412006A; Thu, 31 Oct 2019 11:17:29 -0700 (PDT)
Received: by mail-ua1-x933.google.com with SMTP id q16so2179016uao.1; Thu, 31 Oct 2019 11:17:29 -0700 (PDT)
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=PrwTV4jzQMpc4PZkE3SbGQeSieKnK6YofyKZUbVU3Yg=; b=lACgiwuNbkjx+YF24CXfvwHDOe/fhXJqvbxXVLWJoJjn9OvWGmQvLrjvq6Sv3iWXE3 V/Sx6xNRg8LYu1KESZgiFrIcPeWWHTni13DD+UgKCq8k6ZLDX/kMoKFlGNoSWhVdAZJy sddprypjpj9siPTUK+5MQvEAx2geYEeJDOtvokFtqidkNj2zRzkLRRaHB9cvWVBUI32K TlZrzukni6b25LST72m8oAbeIbJ59/OUoVAqMpDwIPqVr9VVVd4Dp6xw2rsQw15RVwqd DX0noT5QeQ34+AISSNVz01kBrjwAHsIl1KCqMWCKWPrZfb49DnC88+vBhXhDVlIzEbQN DV6Q==
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=PrwTV4jzQMpc4PZkE3SbGQeSieKnK6YofyKZUbVU3Yg=; b=FJUPNeCTN0dOKruGfNqXWDWtajU5j0Vr4keWfFFHdf7TcnC+tC/cyKbuEcKkE14NiU M7ZRN/GE3WAGDnExOHwptwAXjK7qKy2MWCiWhIWoikVY1EQjNoELrr/2y4RXxjOwH3CA 6VOByw6guVJUy3ondVnbowDZFP3uJPa1W6pnn5brxZngnN9auEpFZ81y/fjQf9LEaOFS KYETAVPC5f++meTIp+DoHEiagm0lSCYvf47T4NWZQSfgFjkC4KNON+ArCkaCyOukPXyA cQvOpKA/WMn6eRfMued4BdkfoZz6GW/V5D2Mu8OlwuiUGEe8I9kMC/UNI0LYaNyauMLZ FFoA==
X-Gm-Message-State: APjAAAXSVb8Gqml7024h2l6SxJeHqnK82yZqZFCA2x+QQSXP4MyXqhLj nbqx3U3IHEniPEGMB8sj9top6wFok6sz5YChyRY=
X-Google-Smtp-Source: APXvYqyANc6/AI5+DIkQcwOJe6kokTcQV4wccYyozZcML4DOGYzXUXpgzNIwdfCaa7Z9E2d7jKiL6Xk3+xGaSsAfSI8=
X-Received: by 2002:ab0:7058:: with SMTP id v24mr3435343ual.83.1572545848477; Thu, 31 Oct 2019 11:17:28 -0700 (PDT)
MIME-Version: 1.0
References: <157250931972.30364.14155530538589367259@ietfa.amsl.com>
In-Reply-To: <157250931972.30364.14155530538589367259@ietfa.amsl.com>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Thu, 31 Oct 2019 11:17:17 -0700
Message-ID: <CAG-CQxrxmjF5mPCxcsFu4qs+uxmO8jO4XiUDs6nxDX_7HyfZbQ@mail.gmail.com>
To: Mohit Sethi <mohit.m.sethi@ericsson.com>
Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-ospf-ospfv2-hbit.all@ietf.org, lsr@ietf.org, Padma Pillay-Esnault <padma.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b10bab059638dc5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/FkjkzbB5gU2a8zbKKK7Ld1kUrH0>
Subject: Re: [Lsr] Genart 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, 31 Oct 2019 18:17:32 -0000

Dear Mohit

Thank you for your review.

Please see below PPE for responses and suggestion.

Padma

On Thu, Oct 31, 2019 at 1:08 AM Mohit Sethi via Datatracker <
noreply@ietf.org>; wrote:

> Reviewer: Mohit Sethi
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
>
> Document: draft-ietf-ospf-ospfv2-hbit-10
> Reviewer: Mohit Sethi
> Review Date: 2019-10-31
> IETF LC End Date: 2019-11-07
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
> This document uses a bit in the link state advertisement (LSA) sent from
> routers to indicate that they are hosts which will not forward transit
> traffic.
> The document is READY for publication.
>
> Major issues:
>
> Minor issues:
> I think the document would benefit from some more discussion on what
> happens if
> a router that is repelling traffic is on the only path to some
> destinations?

PPE:
The router with the H-bit set will not be "on the only path" to other
destinations, rather it would look that there is no path for transit
traffic to other routers.

CURRENT:
This document describes the Host-bit (H-bit) functionality that prevents
other OSPFv2 routers from using the host router for transit traffic in
OSPFv2 routing domains.

SUGGESTED NEW:
This document describes the Host-bit (H-bit) functionality that prevents
other OSPFv2 routers from using the host router by excluding it in path
calculations for transit traffic in OSPFv2 routing domains.

Does this address your comment?

How is this handled?


PPE:
The changes in the SPF calculation in Section 4 ensure that the router with
the H-bit set is excluded for the
path calculations for transit traffic.


> Is it fair to say that H-bit is only a best effort way of
> repelling traffic and does not guarantee that the transit traffic is
> actually
> interrupted?
>
>
PPE:
No that would not be correct.
The above describes the best effort that exists today with use of metrics
and this is the gap that H-bit is addressing.
With the H-bit functionality, the host router will not attract the transit
traffic as it is excluded from route calculations other than its host
destination(s).
Indeed, other OSPFv2 routers in the domain should not forward any transit
traffic to it as the host router will not appear on the path at all.



> Any reason that this is only done for OSPFv2 and not v3? Are there ways of
> achieving this functionality (of repelling transit traffic) already in v3?
>
>
PPE:
No needed in OSPFv3 as it has a similar mechanism in the standard already.

Nits/editorial comments:
> - Please expand acronyms like NSSA and LSAs on first usage.
>
PPE: Fixed

OLD:
In addition, this document updates RFC 6987 to advertise type-2 External
   and NSSA LSAs with a high cost in order to repel traffic effectively.

NEW:

In addition, this document updates RFC 6987 to advertise type-2 External
   and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a
   high cost in order to repel traffic effectively.

- Abstract has stray " symbol.

PPE:  Fixed

OLD:
This document defines a bit (Host-bit) that enables a router to advertise
that it is a non-transit router."

NEW:
This document defines a bit (Host-bit) that enables a router to advertise
that it is a non-transit router.


>
> -  The list in the acknowledgements section could benefit from an Oxford
> comma:
> Abhay Roy, David Ward, Burjiz Pithawala, and Michael Barnes for their
> comments.
>
> PPE: Fixed

OLD:
Abhay Roy, David Ward, Burjiz Pithawala and Michael Barnes for their
comments.

NEW:
Abhay Roy, David Ward,  Burjiz Pithawala, and Michael Barnes for their
comments.