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

tony.li@tony.li Fri, 10 January 2020 03:59 UTC

Return-Path: <tony1athome@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 87ECB120154 for <lsr@ietfa.amsl.com>; Thu, 9 Jan 2020 19:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9zAW8sCdNI_B for <lsr@ietfa.amsl.com>; Thu, 9 Jan 2020 19:59:45 -0800 (PST)
Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 D99881200E7 for <lsr@ietf.org>; Thu, 9 Jan 2020 19:59:44 -0800 (PST)
Received: by mail-pg1-x544.google.com with SMTP id k3so349772pgc.3 for <lsr@ietf.org>; Thu, 09 Jan 2020 19:59:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ReTfKxmHz1NdeQXb6Wz371PtmBWwEMhAlVWPoUpENlQ=; b=PmavfPPmK2J4rTvdvE399l91FSDDMsZqxqXZIPES7sHmcBfxECpW9O7y+4uklVgcTv QkeO37FeCSAVwJE6UxzQ6E7eHwni3T1htZn8hFcF2tl4RJbRzKsSSqW4QHBGTMQA4+kj W3LAjAMVE+EH+uYTislxVp7kkP6mv4Zv0+qmYle5Nz4Sz1jYUR8XddAg2hZYBeAPvptH enGqM9Q17/RL+bYGJS6KtBXG07wNZ75FlMQk8kBnRb5YvBvT90NUwoPrYwQBk4oEym6W Ik0HYMIKmJx0r7c8GdMJru5oIbnbOzBLoWRd/vK9KWsilrj9Uo5K699Y30RuYYV1BNJ1 O2NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ReTfKxmHz1NdeQXb6Wz371PtmBWwEMhAlVWPoUpENlQ=; b=djIAyCax3i01ynFG0oj6ixpC+1zIKhgJHGpbHvNVWuInk9aQEva/77MgnFNBqMU1nC Fal/942Y0gNr8zz8K7NkDXKgi6Pu4S9VEepJHhnLeRQS17G1bYyVE03692fHLKiDKfqR TsyOOIREgzSLmDEUH3QRKMvxU7yfJIpZv1OYtlOsCHi3JEdFtVjBz0Wb2PG/9GI5znCe JeEC0eKUw42ndpd83vRfxanhq+3titRc76A8wqTkLCaDpoXXyIKNik4kE3tBKzcIsrbl WfIDOtIOctSd8uHrMPBRp/MZk8lfwQfH4eGtnnl8hkS/5BO1UKYXToU7pwXROMBAf5Cg DnUQ==
X-Gm-Message-State: APjAAAUD0EUs/yi1MErj1mMHvbGn3UOoifFRVQYKX5oiWok6fkFAiK91 iN/4xZaXxBLrjzVGTwOE+q8=
X-Google-Smtp-Source: APXvYqzN9pKc1D6pksiHMp0BUHgsnwnQ6enyPQXdTqjwIVW9mtglVV//YPFKvZEr3Ts+hFikJrGkVw==
X-Received: by 2002:a63:1a1c:: with SMTP id a28mr1836519pga.374.1578628784336; Thu, 09 Jan 2020 19:59:44 -0800 (PST)
Received: from [192.168.4.24] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id i8sm603290pfa.109.2020.01.09.19.59.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 19:59:43 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <BCA056AC-76B2-45B6-9FD0-61A5EBFC740C@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D566FC87-D454-40B2-B83C-042B7A199623"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 09 Jan 2020 19:59:41 -0800
In-Reply-To: <006901d5c75c$c24ad360$46e07a20$@org.cn>
Cc: Robert Raszuk <robert@raszuk.net>, Les Ginsberg <ginsberg@cisco.com>, lsr@ietf.org
To: Aijun Wang <wangaijun@tsinghua.org.cn>
References: <CAOj+MMHAbGo+0qd+xwTmymx4MYXGWmHe0p+d2ychQLQWUZ78wA@mail.gmail.com> <FC0F3982-2182-4CFB-8D60-A702C72BB87F@tsinghua.org.cn> <006901d5c75c$c24ad360$46e07a20$@org.cn>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/FPpkIFsjEZs733RxnSnzFn3swac>
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 03:59:48 -0000

Hi Aijun,

Thank you for your draft.

First off, a ‘passive interface’ is a particular user interface phrase used by one very particular vendor.  It’s not a particularly accurate description, either. For example, a ‘passive’ interface implies that it might
accept protocol packets, but would not be active and send things on that interface.  That might have been meaningful in the distance vector days, but we’re decades past that now. The ’stub link’ designation 
sounds more accurate.

But that’s just naming.

As to mechanism, it seems to me that we already have the mechanisms that you want. Specifically, RFC 5029 already gives us a way of capturing link attributes. It would seem to me that all you need is a code point from that registry and you’d be done.  I’d recommend you direct your draft in that direction.

Regards,
Tony




> On Jan 9, 2020, at 6:22 PM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
> 
> Hi, Les, Robert and other experts within LSR:
>  
> We have submitted the draft that related to the passive interface attribute, please review it at  https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00 <https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00>
>  
> If you are interested, we are also welcome you as the co-author to put forward it together.
> Any comments are welcome.
>  
> Thanks in advance.
>  
>  
> Best Regards.
>  
> Aijun Wang
> China Telecom
>  
> 发件人: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] 代表 Aijun Wang
> 发送时间: 2020年1月7日 18:57
> 收件人: Robert Raszuk
> 抄送: Les Ginsberg (ginsberg); lsr@ietf.org
> 主题: Re: [Lsr] Methods to label the passive interfaces within ISIS
>  
> Hi, Robert:
> There are situations that we want to distinguish the passive interfaces from the normal interfaces. I will try to write one draft in recent days to describe it and for further discussion.
>  
> Thanks in advance.
> 
> Aijun Wang
> China Telecom
> 
> 
> On Jan 7, 2020, at 18:14, Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> wrote:
> 
>> 
>> Hi Aijun,
>>  
>> Right .. I took your email as an attempt/request to actually advertise passive links in the first place. 
>>  
>> May we know what difference does it make to you if reachable prefix is part of an active vs passive interface from IGP point of view ? 
>>  
>> Thx,
>> R.
>>  
>>  
>> On Tue, Jan 7, 2020 at 2:08 AM Aijun Wang <wangaijun@tsinghua.org..cn <mailto:wangaijun@tsinghua.org.cn>> wrote:
>>> Hi, Robert:
>>>  
>>> Thanks for your information.
>>> TLV-22 is used to describe the IS neighbor and the link between them. As for the passive interfaces, there may be no neighbor. 
>>> It seems the sub-TLV within this TLV is not the appropriate place to put this information?
>>>  
>>> P.S. I changed the thread to reflect the conversion topic.
>>>  
>>> Best Regards.
>>>  
>>> Aijun Wang
>>> China Telecom
>>>  
>>> 发件人: lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> [mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>] 代表 Robert Raszuk
>>> 发送时间: 2020年1月6日 18:58
>>> 收件人: Aijun Wang
>>> 抄送: Les Ginsberg (ginsberg); lsr@ietf.org <mailto:lsr@ietf.org>
>>> 主题: Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?
>>>  
>>> Aijun,
>>>  
>>>> We just want to distinguish the passive interfaces from other normal interfaces within ISIS domain.  It seems that the “Attribute Flags” that described in https://tools.ietf.org/html/rfc7794#section-2.1 <https://tools.ietf.org/html/rfc7794#section-2.1> is the most appropriate place to extend to carry such information.
>>>  
>>> Really ?
>>>  
>>> IMO much better place is to define new sub-TLV of TLV-22 and mark it there as passive link.
>>>  
>>> Ref: https://tools..ietf.org/html/rfc5029 <https://tools.ietf.org/html/rfc5029>
>>>  
>>> Now more interesting perhaps is to find out how ISIS is supposed to react to such information. Or is the intention to carry it just as an opaque info say for show commands use only ? 
>>>  
>>> Thx,
>>> R.
>>>  
>> 
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org <mailto:Lsr@ietf.org>
>> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>_______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr