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

From: Peter Psenak <[email-masked]>
Date: Tue, 29 Sep 2020 10:28:51 +0200

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: [email-masked] [mailto:[email-masked]]
>> Sent: Monday, September 28, 2020 3:17 PM
>> To: Zhibo Hu <[email-masked]>; Gyan Mishra
>> <[email-masked]>; Aijun Wang <[email-masked]>;
>> Gyan S. Mishra <[email-masked]>
>> 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-attr
>> ibute/
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface
>> -attribut
>> e
>> Htmlized:
>> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute
>> -04
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-att
>> 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
>>
> 
> 
> 
>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 29 Sep 2020 17:07:26 +0800

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.

>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: [email-masked] [mailto:[email-masked]] On Behalf Of Peter
Psenak
Sent: Tuesday, September 29, 2020 4:29 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for
draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun,

here's my comments:

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:
> The update version of this draft can refer to  
> -attribute

_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: Peter Psenak <[email-masked]>
Date: Tue, 29 Sep 2020 11:15:26 +0200

Hi Aijun,

On 29/09/2020 11:07, Aijun Wang wrote:
> protocol. This is main reason to extension the IGP protocol. > 2. For the solution, normally, the link within the IGP connect two 
ends, but
> information. This is the reason that we select the TLVs that associated with

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: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 29 Sep 2020 13:16:28 +0000

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" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

    Hi Aijun,

    ends, but

    thanks,
    Peter

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 30 Sep 2020 10:38:48 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, September 29, 2020 9:16 PM
To: Peter Psenak <ppsenak=[email-masked]>; Aijun Wang <[email-masked]>; 'Aijun Wang' <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Speaking as WG member:

Hi Aijun, Peter, 

    Hi Aijun,

    ends, but

    thanks,
    Peter

---

From: Peter Psenak <[email-masked]>
Date: Wed, 30 Sep 2020 10:22:40 +0200

Hi Aijun,

we have made a similar discussion in the context of the Appendix A of 
draft-ietf-lsr-ospf-prefix-originator. I have made it very clear that 
using IP reachability advertisement to derive any topological data is 
incorrect and broken. Same applies here. I'm not going to change my opinion.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 30 Sep 2020 11:47:17 +0000

Hi Aijun, 
Other than your ill-conceived topology discovery heuristic, what other possible reason would there be for associating the passive attribute with a prefix? 
Thanks,
Acee

On 9/29/20, 10:39 PM, "Aijun Wang" <[email-masked]> wrote:

    Hi, Acee and Peter:

    Best Regards

    Aijun Wang
    China Telecom

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
    Sent: Tuesday, September 29, 2020 9:16 PM
    To: Peter Psenak <ppsenak=[email-masked]>; Aijun Wang <[email-masked]>; 'Aijun Wang' <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

    Speaking as WG member:

    Hi Aijun, Peter, 

        Hi Aijun,

        ends, but

        thanks,
        Peter