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. >
- [Lsr] Genart last call review of draft-ietf-ospf-… Mohit Sethi via Datatracker
- Re: [Lsr] Genart last call review of draft-ietf-o… Padma Pillay-Esnault
- Re: [Lsr] Genart last call review of draft-ietf-o… Acee Lindem (acee)
- Re: [Lsr] Genart last call review of draft-ietf-o… Acee Lindem (acee)
- Re: [Lsr] Genart last call review of draft-ietf-o… Padma Pillay-Esnault
- Re: [Lsr] [Gen-art] Genart last call review of dr… Alissa Cooper