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 protected] on behalf of [email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of Peter > Psenak > Sent: Tuesday, September 29, 2020 4:29 PM > To: Aijun Wang <[email protected]> > Cc: [email protected] > 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: [email protected] [mailto:[email protected]] >>> Sent: Monday, September 28, 2020 3:17 PM >>> To: Zhibo Hu <[email protected]>; Gyan Mishra >>> <[email protected]>; Aijun Wang <[email protected]>; >>> Gyan S. Mishra <[email protected]> >>> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
