Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt

Alvaro Retana <aretana.ietf@gmail.com> Wed, 25 September 2019 19:07 UTC

Return-Path: <aretana.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 A350E120840 for <lsr@ietfa.amsl.com>; Wed, 25 Sep 2019 12:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 dpH8YRXU-qPc for <lsr@ietfa.amsl.com>; Wed, 25 Sep 2019 12:07:04 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 9CEBB120871 for <lsr@ietf.org>; Wed, 25 Sep 2019 12:07:00 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id a15so4113486edt.6 for <lsr@ietf.org>; Wed, 25 Sep 2019 12:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=oiAPjRLx9GG8RMV71fafkPOFWTnbvuOZOTC98VLE9Cw=; b=vEDfLwT5uw6ycqgkqPKPeFcJExp6c6sd6KaMGvq7Bh574fqLqXF0Jpo8+ByNT62yHL lbGcqh4BWACyyWCz21d4EzxSYFC2Q8EvkGee5yz7Mh+hWkkjwCzTgvClxwNuvayDCC5p 5fK1G/fHANWSZkpICHja1IOX5j+BOy8jXUHVPNSO/BQp22XbzAXmbxzp458nA2e4RJaN zdK9CTocLMpPKJIgo/svbxVOFXLsE+QhMJCiuUcjV1KbUlL09GfoHelSh257Ge+yTZTn Gj83L/Bxs4skazCUvXckheUalrid35VaAJ0OO1cgkWGdZ6emOEDDrhM7iJEGaPlQtzzX 5J+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=oiAPjRLx9GG8RMV71fafkPOFWTnbvuOZOTC98VLE9Cw=; b=Z3nV+g/hyr87lwBMNyghOPhYKb97V28HrBZR/0POe2thoFC1eP/XMqj7wV39DYWXpb fT0IJgUjqQZ0dDnVrI/4+xXeDV3hEGgy+0r2e33TTtfx5iCN2HYqO1pCA611C6kCzhPP 189fmwtUUZIu7OHQDJxvL83Hi6bClNJkzoMwSIMVRD+7MUgbh16m3U5Q0QqdXH94P1Ub In5ChtOrM7YrZe/AUAPKRD42nuheTItJ2ZWrpiBZEl5ZygD8VfMSpSfZ+xCWR2thFA3y pbdzWGwjoWz3NWg2B/ICN1HU0l14mbwOa3/nztIqmsNU1LCCK+lj/DzbIxJDpwjczVZl RmVg==
X-Gm-Message-State: APjAAAXG9eaATXnv/EITvw937F5gR6OAEzyQTE1hz5p1A6CxEOz+TLfN H7pnJhMR0CgUGirTmI3ynQKJ5oxlPVDAwvlW7gQ=
X-Google-Smtp-Source: APXvYqz4frv3hpf9hdk5YrrSej3urQvukT9FAR7CLBGrgu5HJ+zE88VIPvgOnG5CLAGyh5bsWe1OXlhhQw7r4UYnMJI=
X-Received: by 2002:a17:906:80c3:: with SMTP id a3mr682924ejx.271.1569438419123; Wed, 25 Sep 2019 12:06:59 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Sep 2019 12:06:58 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAG-CQxoFpe2px8t02P=x+RiKx3Rnmuan_hqRucertpzivcO0PA@mail.gmail.com>
References: <156843700176.32063.1393096099535829916.idtracker@ietfa.amsl.com> <CAG-CQxo9kMWMXxiDDa4ZSm7ADVS+aPLzRuehDBf1W4jYjGxx2w@mail.gmail.com> <CAMMESsyqP4w3m6E_CFXfRvAO99ihXJuEzTL+3b3fT=s051LqAw@mail.gmail.com> <CAG-CQxoFpe2px8t02P=x+RiKx3Rnmuan_hqRucertpzivcO0PA@mail.gmail.com>
MIME-Version: 1.0
Date: Wed, 25 Sep 2019 12:06:58 -0700
Message-ID: <CAMMESsxh8Rpu2YBYb7XT=TprPV616my-+qc8FDvgf2fdNUpwYg@mail.gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
Cc: "Manish Bhardwaj (manbhard)" <manbhard@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, Keyur Patel <keyur@arrcus.com>, "lsr@ietf.org" <lsr@ietf.org>, "Serpil Bayraktar (serpil)" <serpil@cisco.com>, Yingzhen Qu <yingzhen.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007801880593655b8b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LDLyRlwuO_snHGO6qcaZUuxBVGw>
Subject: Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt
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: Wed, 25 Sep 2019 19:07:06 -0000

On September 23, 2019 at 3:29:55 PM, Padma Pillay-Esnault (
padma.ietf@gmail.com) wrote:

Padma:

Hi!

(1) §3 (last paragraph) introduces different behavior for permanently vs
> temporarily acting as a host.  From the point of view of the H-bit, what is
> the difference?  It seems to me that in both cases the H-bit would be set:
> the router would be acting as a host NOW.  How long it keeps the H-bit set
> seems to be the distinction between permanent and temporary...but the
> behavior should not change because of that.  IOW, the specification of what
> happens when the H-bit is set should be singular -- you may be able to
> soften some of the MUSTs (to SHOULD) if the exceptions are justified other
> than using time.
>
> PPE > I agree that the the specification should be singular.


I propose this change
OLD:
Therefore, non-local IPv4 prefixes, e.g., those
   exported from other routing protocols, MUST NOT be advertised in AS-
   external-LSAs for routers acting permanently as a host.

NEW:
Therefore, non-local IPv4 prefixes, e.g., those
   exported from other routing protocols, SHOULD NOT be advertised in AS-
   external-LSAs for routers acting permanently as a host.

The last sentence below the MUST is correct to correctly repel.
Current : In addition to the procedure described above, temporary host
routers advertising type
2-metric External LSAs MUST set the metrics to LSInfinity to repel
traffic.(see Section 6 of this document).

The proposed changes didn’t eliminate the duality between permanent and
temporary.  We need to eliminate that!  Said another way: how would the
router know the difference in behavior between a permanent setting and a
temporary one?  What is the time limit between temporary/permanent?  …

NEW (suggestion)>

   When the H-bit is set the host router cannot act as an AS Boundary
Router

   (ASBR).  Indeed, ASBR are transit routers to prefixes that are typically

   imported through redistribution of prefixes from other routing
protocols.

   Therefore, non-local IPv4 prefixes, e.g., those imported from other
routing

   protocols, SHOULD NOT be advertised in AS-external-LSAs if the H-bit is

   set.  Some use cases, such as an overloaded router or a router being

   gracefully isolated, may benefit from continued advertisement of
non-local

   prefixes. In these cases, the type 2-metric in AS-external-LSAs MUST be
set

   to LSInfinity to repel traffic.(see Section 6 of this document).


I’ll start the IETF Last Call when -10 is submitted.

Thanks!

Alvaro.