Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 05 November 2020 01:15 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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 870433A121F for <lsr@ietfa.amsl.com>; Wed, 4 Nov 2020 17:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 oQ23O_jYpJvR for <lsr@ietfa.amsl.com>; Wed, 4 Nov 2020 17:15:42 -0800 (PST)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483D43A1214 for <lsr@ietf.org>; Wed, 4 Nov 2020 17:15:41 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id A923447459; Thu, 5 Nov 2020 09:15:37 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: "'Acee Lindem (acee)'" <acee@cisco.com>, 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: "'Peter Psenak (ppsenak)'" <ppsenak@cisco.com>, lsr@ietf.org
References: <32E90101-724C-4B38-8F11-7CF552B4F926@chinatelecom.cn> <33AEF7BB-F6C4-430F-966D-1AC5CE3266B4@cisco.com> <B3702D84-1E7A-4C32-8B87-D70252A8DAF4@cisco.com>
In-Reply-To: <B3702D84-1E7A-4C32-8B87-D70252A8DAF4@cisco.com>
Date: Thu, 05 Nov 2020 09:15:36 +0800
Message-ID: <015801d6b311$2b1990c0$814cb240$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHBcZKtnN6H519STWFh4ttSE8lVhAKe8FwxAOQmWlmpxyRHUA==
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGkNPGEMdQ0lJTk0ZVkpNS09OSENCSExCSEJVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hPQ1VLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NjY6Ezo6NT8pSh8SIj4QFEwP MTcKFC5VSlVKTUtPTkhDQkhDSENMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQU9PT0o3Bg++
X-HM-Tid: 0a7595f931f49865kuuua923447459
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/dAMptYff4eE4SEUdka4aLQo01fg>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.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: Thu, 05 Nov 2020 01:15:46 -0000

Hi, Acee:

Thanks for this comments.
The consideration for the position of flagging the passive interface have been stated in the updated 05 version https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-05#section-3, as the followings:

   ISIS [RFC5029] defines the Link-Attributes Sub-TLV to carry the link
   attribute information, but this Sub-TLV can only be carried within
   the TLV 22, which is used to described the attached neighbor.  For
   passive interface, there is no ISIS neighbor, then it is not
   appropriate to use this Sub-TLV to indicate the passive attribute of
   the interface.

   OSPFv2[RFC2328] defines link type field within Router LSA, the type 3
   for connections to a stub network can be used to identified the
   passive interface.  But in OSPFv3 [RFC5340], type 3 within the
   Router-LSA has been reserved.  The information that associated with
   stub network has been put in the Intra-Area-Prefix-LSAs.

What about your opinions regarding to the above statements? Currently, we think putting the flag within the prefix attribute that associated the passive interface is appropriate.
If we can find other appropriate/acceptable place to hold this information, we can also update the draft later accordingly.


Best Regards

Aijun Wang
China Telecom


-----Original Message-----
From: Acee Lindem (acee) [mailto:acee@cisco.com] 
Sent: Thursday, November 5, 2020 4:11 AM
To: Aijun Wang <wangaj3@chinatelecom.cn>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>; Peter Psenak (ppsenak) <ppsenak@cisco.com>; lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun,
You still didn't answer the question as to why you didn't rework this draft for passive interface to be an interface attribute rather than a prefix attribute? 
Thanks,
Acee

On 10/1/20, 6:13 AM, "Acee Lindem (acee)" <acee@cisco.com> wrote:

    Hi Aijun, 
    You didn't answer my question and pruned my message. Other than your attempt to expose the topology of areas outside the area, there is no other reason to associate the passive interface attribute with a prefix. We seem to be in a circular discussion.... 
    Acee

    On 9/30/20, 10:43 PM, "wangaj3@chinatelecom.cn on behalf of Aijun Wang" <wangaj3@chinatelecom.cn> wrote:

        Hi, Acee:
        Except the corner cases of unnumbered interface, would you like to illustrate other scenarios that the process does not apply?
        As mentioned in last mail, knowing the passive interfaces can assist the nodes or controller know the boundaries of the network.

        Aijun Wang
        China Telecom

        > On Sep 30, 2020, at 19:47, Acee Lindem (acee) <acee@cisco.com> wrote:
        >