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
