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

["Acee Lindem (acee)" <[e-mail]>]

Hi Aijun,

From: Aijun Wang <[e-mail]>
Date: Friday, October 9, 2020 at 9:58 PM
To: Acee Lindem <[e-mail]>, "Peter Psenak (ppsenak)" <[e-mail]>, 'Aijun Wang' <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi, Acee:

From: [e-mail] [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)
Sent: Saturday, October 10, 2020 3:48 AM
To: Aijun Wang <[e-mail]>; Peter Psenak (ppsenak) <[e-mail]>; 'Aijun Wang' <[e-mail]>
Cc: [e-mail]
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Speaking as WG member:

Hi Aijun,

From: Aijun Wang <[e-mail]<mailto:[e-mail]>>
Date: Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, "Peter Psenak (ppsenak)" <[e-mail]<mailto:[e-mail]>>, 'Aijun Wang' <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt


Hi, Acee:

Sorry for the previous pruned mail. Let's reply you again along your original question.

Please see inline.[WAJ]



-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>; Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; 'Aijun Wang' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt



Hi Aijun,

Other than your ill-conceived topology discovery heuristic

[WAJ] The topology discovery heuristic is not suitable for the corner use case when the unnumbered interface is used, as explained in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appendix-B.  If you don’t agree, would you like to illustrate other non-applicable scenarios?



Right – and nobody other than yourself believes the IGPs should be modified to expose the abstracted topology of an area outside that area.

[WAJ]  The modification doesn’t change the way and complexity of route calculation within IGP. It just piggyback some extra information, the bulk of the reconstruction work is done by the controller.  Such extra information can also have other usage, as described in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#section-1

And, the proposal described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-04 is different with the problem you concerned.  It has no relation with the abstracted topology of an area.  Maybe you are confused by these two drafts?



It is a similar problem. You are still trying to overload the prefix advertisements with a link attribute (passive interface) so that it can be conveyed outside the domain. We certainly wouldn’t waste a limited prefix flag on this parochial application.





You can solve the problem with BGP-LS session(s) between the router with a BGP-LS session to the controller and a router in each area w/o  a router with a BGP-LS session to the controller.

[WAJ] This is possible, but not efficient. For operation, we must also consider the configuration/administration overhead.  BGP-LS is designed mainly for the northbound protocol, not east-west protocol.



what other possible reason would there be for associating the passive attribute with a prefix?

[WAJ] To know the boundary of the IGP domain. After knowing the boundary, the controller can safely apply and check the network security policy, the inbound traffic control policy etc.



It really isn’t relevant, but I have to ask…. How does the presence of a prefix associated with a passive interface allow you to make this deduction?

[WAJ] Passive interfaces are deployed mainly at the boundary of IGP domain.  Is there any other exception?

While passive interfaces are not standardized, there is nothing that limits their usage to an IGP boundary. They can and are deployed on any interface where adjacencies are not to be formed (e.g., a stub subnet containing hosts).



Thanks,
Acee



Thanks,

Acee



Thanks,

Acee



On 9/29/20, 10:39 PM, "Aijun Wang" <[e-mail]<mailto:[e-mail]>> wrote:



    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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)

    Sent: Tuesday, September 29, 2020 9:16 PM

    To: Peter Psenak <ppsenak=[e-mail]<mailto:ppsenak=[e-mail]>>; Aijun Wang <[e-mail]<mailto:[e-mail]>>; 'Aijun Wang' <[e-mail]<mailto:[e-mail]>>

    Cc: [e-mail]<mailto:[e-mail]>

    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" <[e-mail] on behalf of ppsenak=[e-mail]<mailto:[e-mail]%20on%20behalf%20of%20ppsenak=[e-mail]>> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Peter

        > Psenak

        > Sent: Tuesday, September 29, 2020 4:29 PM

        > To: Aijun Wang <[e-mail]<mailto:[e-mail]>>

        > Cc: [e-mail]<mailto:[e-mail]>

        > 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]

        >>> Sent: Monday, September 28, 2020 3:17 PM

        >>> To: Zhibo Hu <[e-mail]<mailto:[e-mail]>>; Gyan Mishra

        >>> <[e-mail]<mailto:[e-mail]>>; Aijun Wang <[e-mail]<mailto:[e-mail]>>;

        >>> Gyan S. Mishra <[e-mail]<mailto:[e-mail]>>

        >>> 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

        > [e-mail]<mailto:[e-mail]>

        > https://www.ietf.org/mailman/listinfo/lsr

        >

        >

        >



        _______________________________________________

        Lsr mailing list

        [e-mail]<mailto:[e-mail]>

        https://www.ietf.org/mailman/listinfo/lsr



    _______________________________________________

    Lsr mailing list

    [e-mail]<mailto:[e-mail]>

    https://www.ietf.org/mailman/listinfo/lsr





_______________________________________________

Lsr mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/lsr