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:57 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 1EB7F12008B; Thu, 31 Oct 2019 11:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 loO4Q5L4Ae0R; Thu, 31 Oct 2019 11:57:34 -0700 (PDT)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 9B37112000F; Thu, 31 Oct 2019 11:57:34 -0700 (PDT)
Received: by mail-vk1-xa35.google.com with SMTP id e205so1641680vke.2; Thu, 31 Oct 2019 11:57:34 -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=Reu7C7ej7m6GGhWXqgsrXtHqwVdX8EYNX29zV5V0eqQ=; b=dGnlKI00D+2+Ez4MTm+WZKRRBepr8JwDzqi/VL8m6KGQReIl+4tCzChmXPsikZ3Zza XcWmeUSuCCpCikqwWqN/lt4ct9lF6hEaWXsp8isdtdncg1hvSIFghd8jmnP83R+Hn1mU 68DMg+fc8bCkohU+udM6Bo2u98q6KxAA1vweEAh/Rr18T50wnL6ZN0a/n+6J0ofnazFh EucJvtOIpZw7PlJ/KshsDdtZGf+whgP6GsHgr619y/8drcIQiZ9ud0PVW1Vnh+3mg+xX DDOULwTKIs4WL+1fgEO/7R6vwaUK18FKqIAgW4dYk62GpNHLx8QGo0ESpjze5Q23hC2A KVyA==
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=Reu7C7ej7m6GGhWXqgsrXtHqwVdX8EYNX29zV5V0eqQ=; b=SbfUAX5BfABa9A72eNNRn9I84oPh8IRd065Do3Apd4YsDFFM0BH41IBQynydCmBGJI GabOwC7NHJiFCgJxW8adY+hciNR7x5nrvc6dxfMd7C+Ai5kZbn4jtXaFLyjHh5ack3Az +dMa69mjareChiRjTSdZujcQNtON/S5rngVWTfFqt4qfT6LU1rDHdLIfZGjh1rF/0yDx hMGOrO466Dg/NQft+pbwyg4eXhe7jNjIX2FigyGukut8uAOHmk2fGOsOMM/hhCd9I8KM V9oNpZ07BdNcN/T+RM7xHLt0RoIsNCO6k0vnXI5jk9T5wNHl9YswYx+AyhcbYtu4adRL fGgw==
X-Gm-Message-State: APjAAAUdzzGj//ZZBkBTozF3aJwzELuc6QkU3OHfBf6ER6b8ktZzHtsA Vk6DvJ2WS6NuUIIybX7hVnpqviSyLJE8TvDJyEw=
X-Google-Smtp-Source: APXvYqxoB5/y8oXXxzuykfz2959Wysbcg3P1uarT6AiBxc1ALfwpE0zc9uvmiu+2JZuo36BRzKG32hMbu+jbjpUMrG8=
X-Received: by 2002:a1f:48c5:: with SMTP id v188mr3332788vka.34.1572548253488; Thu, 31 Oct 2019 11:57:33 -0700 (PDT)
MIME-Version: 1.0
References: <157250931972.30364.14155530538589367259@ietfa.amsl.com> <CAG-CQxrxmjF5mPCxcsFu4qs+uxmO8jO4XiUDs6nxDX_7HyfZbQ@mail.gmail.com> <6337DF2C-0AD5-4A16-A3F4-ABF92A325661@cisco.com> <A29B899A-FA18-4B82-8D8D-802C634841E2@cisco.com>
In-Reply-To: <A29B899A-FA18-4B82-8D8D-802C634841E2@cisco.com>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Thu, 31 Oct 2019 11:57:22 -0700
Message-ID: <CAG-CQxovEQYnGqteDBKrAtU7+xJDTaze3FYne4UrB0e3hy+yBg@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Mohit Sethi <mohit.m.sethi@ericsson.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-ospf-ospfv2-hbit.all@ietf.org" <draft-ietf-ospf-ospfv2-hbit.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Padma Pillay-Esnault <padma.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000a9a960596396c87"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/9AiTSvxj-FvjoxGn9SH951kuwAs>
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:57:38 -0000

On Thu, Oct 31, 2019 at 11:54 AM Acee Lindem (acee) <acee@cisco.com>; wrote:

> See one inline.
>
>
>
> *From: *Acee Lindem <acee@cisco.com>;
> *Date: *Thursday, October 31, 2019 at 2:39 PM
> *To: *Padma Pillay-Esnault <padma.ietf@gmail.com>;, Mohit Sethi <
> mohit.m.sethi@ericsson.com>;
> *Cc: *"gen-art@ietf.org"; <gen-art@ietf.org>;, "last-call@ietf.org"; <
> last-call@ietf.org>;, "draft-ietf-ospf-ospfv2-hbit.all@ietf.org"; <
> draft-ietf-ospf-ospfv2-hbit.all@ietf.org>;, "lsr@ietf.org"; <lsr@ietf.org>;
> *Subject: *Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
> *Resent-From: *<alias-bounces@ietf.org>;
> *Resent-To: *Keyur Patel <keyur@arrcus.com>;, <padma.ietf@gmail.com>;, <
> manbhard@cisco.com>;, <serpil@cisco.com>;, Yingzhen Qu <
> yingzhen.ietf@gmail.com>;, Christian Hopps <chopps@chopps.org>;, Acee
> Lindem <acee@cisco.com>;, Martin Vigoureux <martin.vigoureux@nokia.com>;,
> Deborah Brungard <db3546@att.com>;, Alvaro Retana <aretana.ietf@gmail.com>;,
> Yingzhen Qu <yingzhen.ietf@gmail.com>;
> *Resent-Date: *Thursday, October 31, 2019 at 2:39 PM
>
>
>
> HI Padma, Mohit,
>
>
>
> *From: *Padma Pillay-Esnault <padma.ietf@gmail.com>;
> *Date: *Thursday, October 31, 2019 at 2:17 PM
> *To: *Mohit Sethi <mohit.m.sethi@ericsson.com>;
> *Cc: *"gen-art@ietf.org"; <gen-art@ietf.org>;, "last-call@ietf.org"; <
> last-call@ietf.org>;, "draft-ietf-ospf-ospfv2-hbit.all@ietf.org"; <
> draft-ietf-ospf-ospfv2-hbit.all@ietf.org>;, "lsr@ietf.org"; <lsr@ietf.org>;,
> Padma Pillay-Esnault <padma.ietf@gmail.com>;
> *Subject: *Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
> *Resent-From: *<alias-bounces@ietf.org>;
> *Resent-To: *Keyur Patel <keyur@arrcus.com>;, <padma.ietf@gmail.com>;, <
> manbhard@cisco.com>;, <serpil@cisco.com>;, Yingzhen Qu <
> yingzhen.ietf@gmail.com>;, Christian Hopps <chopps@chopps.org>;, Acee
> Lindem <acee@cisco.com>;, Martin Vigoureux <martin.vigoureux@nokia.com>;,
> Deborah Brungard <db3546@att.com>;, Alvaro Retana <aretana.ietf@gmail.com>;,
> Yingzhen Qu <yingzhen.ietf@gmail.com>;
> *Resent-Date: *Thursday, October 31, 2019 at 2:17 PM
>
>
>
> 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.
>
>
>
> This sounds fine to me. However, I was surprised that this was apparent
> from the original abstract and first paragraph of the introduction.
>
>
>
> I meant “not apparent”…
>
>
>
> Acee
>


Also felt that this was apparent but do not mind adding this small change
if it is helpful.

Padma

>
> 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.
>
>
>
> A little more background for Mohit… OSPFv3 followed OSPFv2 by about 5+
> years and preventing transit traffic was recognized as a requirement. In
> OSPFv3 (RFC 5340), the corollary function is provided by the R-bit which
> must be set in order for a Router’s Router-LSA to be used in path
> computations for transit traffic. We would have liked to have used the same
> R-bit in OSPFv2 but it would not have been backward compatible since you
> can’t mandate that a bit be set for an existing LSA to be used. Hence, the
> OSPFv2 H-bit is the corollary of the OSPFv3 R-bit.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
> 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.
>