Re: [Lsr] Methods to label the passive interfaces within ISIS

Robert Raszuk <robert@raszuk.net> Fri, 10 January 2020 12:27 UTC

Return-Path: <robert@raszuk.net>
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 1068612006F for <lsr@ietfa.amsl.com>; Fri, 10 Jan 2020 04:27:12 -0800 (PST)
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, 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=raszuk.net
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 ZN1hmMI1UYsI for <lsr@ietfa.amsl.com>; Fri, 10 Jan 2020 04:27:10 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 E88E012006E for <lsr@ietf.org>; Fri, 10 Jan 2020 04:27:09 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id k40so1711297qtk.8 for <lsr@ietf.org>; Fri, 10 Jan 2020 04:27:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t8iGunmCJaDj2Ogz0cKveWuEbry8zofin+T3a3c4d44=; b=PFF6mAq2up7yVH1+ZwIQ3XQrHdBKKCZUAe6GjKPdfU5/TMT2X+6Xb1gDEZmuzq1Rd+ cjblEzh59XfOOZYeI1RzUsL1inBsKFX/bEzoFMe1C4/Rj56AzAUUI7cc/ht2p4fQDJw9 +50i+qtEHcuBC8h8MaIEhqcmrage1gge/ubRalvJCpD7w3YOXRBEmL3PnO2WR8EGyeL0 1n/0R5dIEHzrhwI4DbOyYobF5+ehBbrC33X5o4T72LNgtbotfHgbfzHq4Ox0hPxkjKZ3 JCt9lPOkP+duc44nMJpWq5jw4EmYYbkbnuHK5ACB2Nze+rFOjxqsMqAPs2mAuM9YUvCT x/xw==
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=t8iGunmCJaDj2Ogz0cKveWuEbry8zofin+T3a3c4d44=; b=R10DFRfFc2v/mUEsVLzRrNFJNCTAfPTRwtDrwsAw2BnegyEx015MisHw655G25c4Pg pbKk3jSA5a+7Y029yU5rSHzE2ey3Z+9rCJ20aOrCVdqIyCvVT28Ac1pkBhN8++sC5i+e NSf+HtmxTK/mkf3AaJuu+E6D+pCV0w6Ft+wEM8ODzoGQUUjhFpWU27e5bRR6Ob+waje3 9OxF3cOAk5QwTZS30Lx5GJlIrI2Kuj+2Mhd6UHCNQWK/lB4gxu0YngRW6nxP/VmabMC3 WUBGYP7n7KDaSXh3vDh3txEYxbQvqVdO0c598dH6GIXDL7qhL+Syy7RIfEuu+fkCkLSx IzWg==
X-Gm-Message-State: APjAAAW1nd1ZP3UF3WUuTrodxk6vhlEGafTxaiuxPRs7vpBzZAx6EarH zsmRgXV7n9oQ0TWi0q65gljY/kc2m7x4aZ9hYFVGJA==
X-Google-Smtp-Source: APXvYqxaus0V7K7BTLDdgRDbbtnnmgLkNfxMAPyQuZlDekwXSOG3KoNpb3Fib9yLZO3heFgm++giM0YTfGuO4yKSChk=
X-Received: by 2002:ac8:7a70:: with SMTP id w16mr2147843qtt.154.1578659227674; Fri, 10 Jan 2020 04:27:07 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMHAbGo+0qd+xwTmymx4MYXGWmHe0p+d2ychQLQWUZ78wA@mail.gmail.com> <FC0F3982-2182-4CFB-8D60-A702C72BB87F@tsinghua.org.cn> <006901d5c75c$c24ad360$46e07a20$@org.cn> <BCA056AC-76B2-45B6-9FD0-61A5EBFC740C@tony.li> <00bb01d5c785$483d91b0$d8b8b510$@org.cn> <32D6BF50-90F8-40C1-81B3-4DA6646F3F6E@tony.li>
In-Reply-To: <32D6BF50-90F8-40C1-81B3-4DA6646F3F6E@tony.li>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 10 Jan 2020 13:26:55 +0100
Message-ID: <CAOj+MMEX7fTkodiUeVHK5LNNRsSyk++UYWM_wYZEdm6H0tnFpw@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, Les Ginsberg <ginsberg@cisco.com>, lsr@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007cbd96059bc83e5b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PPRUvjdRtUJNQ93DEHjxQVWWHog>
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS
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: Fri, 10 Jan 2020 12:27:12 -0000

Hi Tony,

I agree with you that essentially this is a link property (hence my earlier
hint towards 5029) so it makes it at least two of us recommending direction
towards 5029 now ;)

While we are at this perhaps it would be also useful to be able to
differentiate reachability on stub links vs virtual local interfaces. Today
in some implementations they are advertised after marking them as passive
int.

Thx
R.


On Fri, Jan 10, 2020, 08:26 <tony.li@tony.li> wrote:

>
> Hi Aijun,
>
>
> For the link attributes that defined in RFC5029, as that stated in
> https://tools.ietf.org/html/rfc5029#section-2, this sub-TLV is included
> in the TLV 22(Extended IS Reachability).
> As I read the IANA code point
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> , it notes this sub-TLV can be included in all of these TLVs
> (22,23,25,141,222,223).
>
> But, when the interface is configured as passive/stub, it seems that the
> above TLVs will not be advertised, because there is no IS neighbor on this
> passive link.
>
>
>
> Fair point. Given that there is an IP address and prefix on that link, it
> would be very reasonable to advertise the Extended IP Reachability TLV
> (135). We would then need to make the link attributes sub-TLV applicable to
> this TLV (and it’s MT brother).
>
>
> TLV 141 “Inter-AS reachability information” seems be one appropriate TLV
> to include this sub-TLV, but it requires the IS-IS TE deployment, and is
> not suitable for describing the passive/stub link on edge router.
>
> In summary, it seems put this attribute into the “Prefix Attribute Flags”
> sub-TLV which can be included in TLV 135,235,236 and 237 (Extended IP
> reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) is
> more applicable?
>
>
>
> It would seem to me that what you’re describing is an attribute of a link,
> not of a prefix, thus I would favor it remaining a link attribute.
>
> But that’s just me.  :-)
>
> Tony
>
>