IETF Logo Mail Archive

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

Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 13 January 2020 18:32 UTC

Return-Path: <jefftant.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 47B5A12096D for <lsr@ietfa.amsl.com>; Mon, 13 Jan 2020 10:32:29 -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, 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 ir61RZC_PSTo for <lsr@ietfa.amsl.com>; Mon, 13 Jan 2020 10:32:24 -0800 (PST)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 137FA120946 for <lsr@ietf.org>; Mon, 13 Jan 2020 10:32:24 -0800 (PST)
Received: by mail-pf1-x430.google.com with SMTP id x184so5277395pfb.3 for <lsr@ietf.org>; Mon, 13 Jan 2020 10:32:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=itqjY0ItqxYZg4WS1LH+80T40DubQ3xJRKWSCtUogfY=; b=rKAZeoHqW66EWzH6uTSVliEdSjG84iOK7Q0ZryI695pGQ14uDpAq5wl0IspeBM5smN 8CMlpns2fcQTZiSXXFKTn7Yij3+INIEqYQQMFmJxMcW06pRgdwE+tN9GtsdRLeaCxYaX 1fpbj1ObxJojONsjvxPRocVHUtyUCE/OxMdgrwR5nrCy+CWBDhH7USzq752GSTFt0Oi4 +oRipjJqzifIOZ9/L0l77eknElPuHZaQCSayLYoK1ftun1MZBvzLQhNabdSy63z0jZx0 tY/oX5VzPnkvzWwZoerm0FDruulI5C52mT4vFx/Uj0Y5dxNSyNORaOHWSn0lMZLZNzwR 6cCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=itqjY0ItqxYZg4WS1LH+80T40DubQ3xJRKWSCtUogfY=; b=OiZUuaIlYkLfxd2Ysct74a/e4efSzsmJY8y7/39Nwb/ymo38QAgmlYjB36QGM68lgL 2dm1fm7OLcvk5GkeV6nUae7ZbWB7uExhUGPFwLXKSjRTVJlgvugcNZ5EXLDgnINjFipa Byp36QBdse54IrcmcAqkWUIMFnVE9yCpAeT5wyGpQMnUgkmgCgVc9J2WSR0i5yHTmHtK 0oUKGGgnd3PYAMi0qrTl9vf9FGXeE8Dup0pIivVb9LqSVhccUgRLxfOa/a6cSuTcxcJU NaNITA+wGm3ejE7fkxn63+x1GUk95DnqmtEi+jR4vfVOIfZ+HRNLCh6dAiWITq9NNbxK HJVg==
X-Gm-Message-State: APjAAAU/NqsTVaRX0BsKJTX9MsTLrBqtQGWCtYj2ensug1HhPiXBov57 cRZHi+Tq5Eg0tIl379oWcdg=
X-Google-Smtp-Source: APXvYqwElS7sWj1TERRiAH9FDpf0xhIz0YwvjTRQ8GoUnA5tcJSaQRS3I9BkaFBuervRssO8d9Y4EA==
X-Received: by 2002:a63:114a:: with SMTP id 10mr22156533pgr.250.1578940343546; Mon, 13 Jan 2020 10:32:23 -0800 (PST)
Received: from [192.168.1.42] ([50.235.77.202]) by smtp.gmail.com with ESMTPSA id h3sm15235143pfr.15.2020.01.13.10.32.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jan 2020 10:32:22 -0800 (PST)
Date: Mon, 13 Jan 2020 10:32:14 -0800
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "tony.li@tony.li" <tony.li@tony.li>, Aijun Wang <wangaijun@tsinghua.org.cn>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Message-ID: <52685ed7-f7e8-4828-82b1-234f78a8fc39@Spark>
In-Reply-To: <MWHPR11MB1616037BD1F2307A5B874FEBC1350@MWHPR11MB1616.namprd11.prod.outlook.com>
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> <00eb01d5c9ec$ea8112d0$bf833870$@org.cn> <6951B8C6-905C-4AC8-B46E-8A708A6AEFE0@tony.li> <442C5535-E3C6-493F-A2F2-A9E9A4749C33@cisco.com> <MWHPR11MB1616037BD1F2307A5B874FEBC1350@MWHPR11MB1616.namprd11.prod.outlook.com>
X-Readdle-Message-ID: 52685ed7-f7e8-4828-82b1-234f78a8fc39@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5e1cb7b3_28677b7c_496"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/L0Kw4ezsQIZWZys-zqALJfWeoCI>
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: Mon, 13 Jan 2020 18:32:29 -0000

Agree with Acee and Les

Cheers,
Jeff
On Jan 13, 2020, 9:29 AM -0800, Les Ginsberg (ginsberg) <ginsberg@cisco.com>, wrote:
> I agree with Acee that there is no requirement to identify an interface as passive – or (as suggested in this thread) as loopback or tunnel or stub…
>
> Before debating the best encoding for information, it would be sensible to define the use case/requirements.
> Simply having an advertisement that identifies an interface type isn’t sufficient to do anything useful IMO.
>
>    Les
>
> From: Acee Lindem (acee) <acee@cisco.com>
> Sent: Monday, January 13, 2020 8:03 AM
> To: tony.li@tony.li; Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Robert Raszuk <robert@raszuk.net>; lsr@ietf.org
> Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS
>
> Hi Aijun,
> I guess the external use case for this is advertisement in BGP-LS for Network Management purposes?? There really isn’t IS-IS requirement to know whether or not an interface is a passive interface.
> Thanks,
> Acee
>
> From: Lsr <lsr-bounces@ietf.org> on behalf of Tony Li <tony.li@tony.li>
> Date: Monday, January 13, 2020 at 11:00 AM
> To: Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Robert Raszuk <robert@raszuk.net>, "lsr@ietf.org" <lsr@ietf.org>
> Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS
>
>
> Hi Anjun,
>
>
> > Is it reasonable to put the link attribute information into the “IP Reachability TLV”?
> > IMHO, such stub link is not the normal links within IGP domain.  Label the related prefix is coming from the passive/stub link seems also acceptable?
>
>
> Well, a passive interface is really configured so that you advertise the interface’s prefix.  Attaching the data that you want to the associated data seems reasonable to me.
>
> There’s no good IS Neighbor advertisement to attach the sub-TLV to because there is no neighbor.
>
> Tony
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email