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

Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 30 September 2020 02:38 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 557583A0C62 for <lsr@ietfa.amsl.com>; Tue, 29 Sep 2020 19:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 FWN8FtYduj_s for <lsr@ietfa.amsl.com>; Tue, 29 Sep 2020 19:38:52 -0700 (PDT)
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 2B67E3A0B3D for <lsr@ietf.org>; Tue, 29 Sep 2020 19:38:51 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 591664602F; Wed, 30 Sep 2020 10:38:48 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: "'Acee Lindem (acee)'" <acee=40cisco.com@dmarc.ietf.org>, 'Peter Psenak' <ppsenak=40cisco.com@dmarc.ietf.org>, 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: lsr@ietf.org
References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <cdb99646-d157-2990-1e4d-b63f169c61e2@cisco.com> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com>
In-Reply-To: <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com>
Date: Wed, 30 Sep 2020 10:38:48 +0800
Message-ID: <00cb01d696d2$d3abf990$7b03ecb0$@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
Content-Language: zh-cn
Thread-Index: AQIJ+mWorx9ReexromEfqpSgpX3kFwEFLd5+AaLg+ScCZ8Mz1AFBnbZFqOcj2IA=
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZHxhJTB0fQxgfShpJVkpNS0pPSEhOSUNOQ01VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Pkk6Dgw4ED8aCkpNDhYhASJD LwhPCkhVSlVKTUtKT0hITklCSkhMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUNOTko3Bg++
X-HM-Tid: 0a74dce068b09865kuuu591664602f
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/R3CR4bE8GQr23HPofP7APDehI5E>
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: Wed, 30 Sep 2020 02:38:55 -0000

Hi, Acee and Peter:
Passive interface is mainly used at the edge of the network, where the unnumbered interface will not be used. 
And the information to flag the passive interfaces is for positioning the area boundary, not conflict with the abstract capabilities of the area inside.


Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, September 29, 2020 9:16 PM
To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>; Aijun Wang <wangaijun@tsinghua.org.cn>; 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Speaking as WG member:

Hi Aijun, Peter, 
I agree with Peter - one of the main motivations for having areas is to abstract the topology within the area. Now you're trying to supplant this  - one topological detail at a time with ill-conceived IGP features.
Thanks,
Acee

On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" <lsr-bounces@ietf.org on behalf of ppsenak=40cisco.com@dmarc.ietf.org> wrote:

    Hi Aijun,

    On 29/09/2020 11:07, Aijun Wang wrote:
    > Hi, Peter:
    > 
    > Thanks for your comments.
    > 1. For BGP-LS deployment, there normally only be one router that within the
    > IGP domain to report the topology information, this router should know such
    > passive links which exists mainly on other border routers via the IGP
    > protocol. This is main reason to extension the IGP protocol. > 2. For the solution, normally, the link within the IGP connect two 
    ends, but
    > passive interface is special and not fall in this space. We have studied the
    > current TLVs that for link, and find no suitable container to append this
    > information. This is the reason that we select the TLVs that associated with
    > Prefix.

    if the link is unnumbered, your solution does not work. As I said, if 
    you need a knowledge about the link, you can not advertise it as a prefix.

    thanks,
    Peter


    > 
    >>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix LSA", which
    > isolate the prefix information that associated with link into this
    > container, contains the stub link, local interface information etc. Put such
    > attribute along with the prefix is then acceptable?
    > 
    > 
    > Best Regards
    > 
    > Aijun Wang
    > China Telecom
    > 
    > -----Original Message-----
    > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Peter
    > Psenak
    > Sent: Tuesday, September 29, 2020 4:29 PM
    > To: Aijun Wang <wangaj3@chinatelecom.cn>
    > Cc: lsr@ietf.org
    > Subject: Re: [Lsr] FW: New Version Notification for
    > draft-wang-lsr-passive-interface-attribute-04.txt
    > 
    > Hi Aijun,
    > 
    > here's my comments:
    > 
    > The purpose of this draft is to advertise passive links.
    > 
    > 1. I'm not sure the problem needs to be solved by IGPs. I tend to believe
    > ietf-idr-bgpls-inter-as-topology-ext is sufficient.
    > 
    > 2. the solution that you proposed is wrong. You are trying to derive
    > topological data about the passive links from the prefix advertisement.
    > This is semantically incorrect and only works under very specific condition.
    > If you need to advertise a link, advertise it as a "special"
    > link, not as a "special" prefix.
    > 
    > thanks,
    > Peter
    > 
    > On 29/09/2020 03:17, Aijun Wang wrote:
    >> Hi, Peter:
    >>
    >> Would you like to review and give comments on the updates version of this
    > draft?
    >> We have also added the protocol extension proposal for OSPFv3.
    >>
    >> The update version of this draft can refer to
    >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface
    >> -attribute
    >> Thanks in advance.
    >>
    >>
    >> Best Regards
    >>
    >> Aijun Wang
    >> China Telecom
    >>
    >>> -----Original Message-----
    >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
    >>> Sent: Monday, September 28, 2020 3:17 PM
    >>> To: Zhibo Hu <huzhibo@huawei.com>; Gyan Mishra
    >>> <gyan.s.mishra@verizon.com>; Aijun Wang <wangaj3@chinatelecom.cn>;
    >>> Gyan S. Mishra <gyan.s.mishra@verizon.com>
    >>> Subject: New Version Notification for
    >>> draft-wang-lsr-passive-interface-attribute-04.txt
    >>>
    >>>
    >>> A new version of I-D,
    >>> draft-wang-lsr-passive-interface-attribute-04.txt
    >>> has been successfully submitted by Aijun Wang and posted to the IETF
    >>> repository.
    >>>
    >>> Name:		draft-wang-lsr-passive-interface-attribute
    >>> Revision:	04
    >>> Title:		Passive Interface Attribute
    >>> Document date:	2020-09-28
    >>> Group:		Individual Submission
    >>> Pages:		7
    >>> URL:
    >>> https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04.
    >>> txt
    >>> Status:
    >>> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att
    >>> r
    >>> ibute/
    >>> Htmlized:
    >>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac
    >>> e
    >>> -attribut
    >>> e
    >>> Htmlized:
    >>> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut
    >>> e
    >>> -04
    >>> Diff:
    >>> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-at
    >>> t
    >>> ribute-04
    >>>
    >>> Abstract:
    >>>      This document describes the mechanism that can be used to
    >>>      differentiate the passive interfaces from the normal interfaces
    >>>      within ISIS or OSPF domain.
    >>>
    >>>
    >>>
    >>>
    >>> Please note that it may take a couple of minutes from the time of
    >>> submission until the htmlized version and diff are available at
    > tools.ietf.org.
    >>>
    >>> The IETF Secretariat
    >>>
    >>
    >>
    >>
    >>
    > 
    > _______________________________________________
    > Lsr mailing list
    > Lsr@ietf.org
    > https://www.ietf.org/mailman/listinfo/lsr
    > 
    > 
    > 

    _______________________________________________
    Lsr mailing list
    Lsr@ietf.org
    https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr