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

Padma Pillay-Esnault <padma.ietf@gmail.com> Wed, 25 September 2019 21:02 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 C1AF512022C for <lsr@ietfa.amsl.com>; Wed, 25 Sep 2019 14:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 UNbQYS8BWTBA for <lsr@ietfa.amsl.com>; Wed, 25 Sep 2019 14:02:33 -0700 (PDT)
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 B5248120018 for <lsr@ietf.org>; Wed, 25 Sep 2019 14:02:32 -0700 (PDT)
Received: by mail-ua1-x932.google.com with SMTP id q11so60107uao.1 for <lsr@ietf.org>; Wed, 25 Sep 2019 14:02:32 -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=mvNgG2BkEKCD0LD9lH3UpBwNxh+SYI2htffCWNd0Z4o=; b=dlSiG5hycF52kGy9o8I6a8eSUzhli881U5YZa3IsNIeYLUQaUyq62bWkgINXLiC6HT g977oCJZIuONOP7zkIo76x5CF50f8Wxas+ETZLAi/1rnGSAjV8s9aCTCqS5ue/1BT33w KbKz2urqZtwP4uTS/O8lfwHYYTHpw/j++cyYXBLTeYV2m303/4GKiFxSRc4cdO5Tz+Dd vvU4waaToZCdpjhykUdbbPLIjRoTUxaXlVtzadQoYw+eNDVE3YJWulDgO/nvmONhS1QY A+yJUx3T8+EY4eXF60Hxr5e8nr+UPizITPWtHK85j+zXYyzW5C/YAc0lgZqjfcMH8nGr FHmQ==
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=mvNgG2BkEKCD0LD9lH3UpBwNxh+SYI2htffCWNd0Z4o=; b=mOzeHMzqYNBxpZnzFStCAYQQL4v+g66oqtmSDN4VOr2iFCcHA0BRuCpVjJLfqCtEv4 hc6AMHYZhP6JwfXiqS4bDsE5htdBRWQKe4o5eX/dmASO37m25aoWC/9XbPrV8lteTQ7o 3nIsZUk/XyoAmUmMe8q6LMhzINZbkyszF4+bKb7aJWt1MZCaNVbtnocj/YhG0/iHsVB0 9AizbIJ83GCuvAk33fzcCX1GuLdp4wCEojATqSHTAeiWYxUO6Gx4AmjcWDN/lwb2bvWz qIERqGN8VB5duPpyylgHJ64ovB83LMPP68+B4GwFJysUi4mEJZVuj+a9ILGnt2D8z8vD cPSg==
X-Gm-Message-State: APjAAAXna7BAnVV7kMCL/eJaBfJEYsXbjkzMCnBZm9Z0L1Q/HJE+UGCo 2weC/z836Ei8+w3dilPgp5wVfIVl2BeIv9hLkkw=
X-Google-Smtp-Source: APXvYqyFJXenILHeIG321ipoMBDs9ku3iIxZRtgSre14VcmOOpR3CX0HbotuNOQcC1CxUuARD9Ajk/0yPabNU/FaIEo=
X-Received: by 2002:ab0:48c4:: with SMTP id y4mr297774uac.14.1569445351633; Wed, 25 Sep 2019 14:02:31 -0700 (PDT)
MIME-Version: 1.0
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> <CAMMESsxh8Rpu2YBYb7XT=TprPV616my-+qc8FDvgf2fdNUpwYg@mail.gmail.com>
In-Reply-To: <CAMMESsxh8Rpu2YBYb7XT=TprPV616my-+qc8FDvgf2fdNUpwYg@mail.gmail.com>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Wed, 25 Sep 2019 14:02:20 -0700
Message-ID: <CAG-CQxpORxZAqzNYm48CfWidZ6Rnw6+3OuL=JZSpo37cFXrexg@mail.gmail.com>
To: Alvaro Retana <aretana.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="000000000000adb4b8059366f845"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/eqzW7aOfK7mRTdLBKeV3rwSvFJ4>
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 21:02:35 -0000

I looked at the suggested change and I have no objections removing the term
"permanent".

Will make all changes in the next version.

Thanks
Padma

On Wed, Sep 25, 2019 at 12:06 PM Alvaro Retana <aretana.ietf@gmail.com>;
wrote:

> 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.
>