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

Peter Psenak <ppsenak@cisco.com> Thu, 05 November 2020 08:26 UTC

Return-Path: <ppsenak@cisco.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 0F28A3A0CED for <lsr@ietfa.amsl.com>; Thu, 5 Nov 2020 00:26:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.848
X-Spam-Level:
X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 wKm-TwylYjkW for <lsr@ietfa.amsl.com>; Thu, 5 Nov 2020 00:25:57 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAC83A0C8B for <lsr@ietf.org>; Thu, 5 Nov 2020 00:25:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3263; q=dns/txt; s=iport; t=1604564757; x=1605774357; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=i9W2MQDtXYsewCrOBl6WbFDz3EQ9Bd12MgVNXeGA9RM=; b=PUy6llNq0uVzhAGOtmmVKwglWlUIA7Fi0c17iYlmfr1810Fpbczv+zAy N74zcy3oIc0wP/sSmjj0mvaWQiUFUmIKB3M0H3b9wcsoVOu9xR8sbL+au ByhdD0LKj4X4WSQfAgix3Lato2Lqbg/oIfMQ4dJ5ML/V8jPcltRNZD/JD U=;
X-IronPort-AV: E=Sophos;i="5.77,453,1596499200"; d="scan'208";a="28445581"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Nov 2020 08:25:55 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 0A58Ps4t028926; Thu, 5 Nov 2020 08:25:55 GMT
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "'Acee Lindem (acee)'" <acee@cisco.com>, 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: 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> <015801d6b311$2b1990c0$814cb240$@tsinghua.org.cn>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <f73698ae-77ed-f082-6b90-b9b250b3f4b5@cisco.com>
Date: Thu, 05 Nov 2020 09:25:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <015801d6b311$2b1990c0$814cb240$@tsinghua.org.cn>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/RDiXXSOR6hr4ytEdryrcGfuhIzM>
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 08:26:02 -0000

Hi Aijun,

please look at rfc5316, ISIS already have a way to advertise inter-AS 
link without forming an adjacency.

thanks,
Peter

On 05/11/2020 02:15, Aijun Wang wrote:
> 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:
>          >
> 
> 
> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
>