From: Aijun Wang <wangai...@tsinghua.org.cn> Date: Tuesday, November 17, 2020 at 9:27 PM To: Acee Lindem <a...@cisco.com> Cc: 'lsr' <lsr@ietf.org> Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt
Hi, Acee: -----Original Message----- From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) Sent: Wednesday, November 18, 2020 2:47 AM To: Aijun Wang <wang...@chinatelecom.cn> Cc: 'lsr' <lsr@ietf.org> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt Speaking as WG member and longtime steward of the IGPs: Hi Aijun, My opinion is that we should not overload the base IGP topology advertisements with everyone's favorite obscure use case. Hence, I think it would be a big mistake to add this stub link TLV to the base LSAs. [WAJ] Putting the information in other regular TLVs, or putting them in LSA of one independent IGP instance(as you proposed in 109 meeting) will be more expensive. Do you agree this statement? No – bloating the primary LSAs with non-routing information will be more expensive due to the dynamics of LSA origination and route computation. Rather, exactly what problem are you trying to solve? Previously, you were trying to associate the passive interface attribute with a prefix and making some inference related to an inter-AS boundary (this was not entirely clear). What problem are you trying to solve? Precisely, what do you want the controller to learn (i.e., address or interface index) and what is it going to do with it. [WAJ] Passive Interfaces are already deployed within the network in many places, as stated in the draft-wang-lsr-passive-interface-attribute-06#section-1<https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-06#section-1>. What we want to know, is the position of passive interface. Previously, we want piggyback such information within its associated prefix, but after discussion on the mail list, define one new TLV to contain it and other future information may be more acceptable and extensible. And how do identify and even define the position of the passive interface? As I stated previously, passive interfaces are not standardized. Knowing these information, the controller can learn the inter-as links via some methods that we have discussed in another thread, can know the boundary of network, can learn the link characteristic that associated with server etc. We have also mentioned it in the draft-wang-lsr-passive-interface-attribute-06#section-1<https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-06#section-1> and think it is not appropriate to expand it intensely in one LSR draft. I disagree. Precisely define your use case. Please don't try and solve the CFN problem as the requirements are not clear (anycast, unicast, impact on routing, scope, etc). [WAJ] In your 109 meeting presentation slides-109-lsr-5-ospf-transport-instance-00<https://datatracker.ietf.org/meeting/109/materials/slides-109-lsr-5-ospf-transport-instance-00>, you mentioned also the similar information that should be transferred via the OSPF protocol. I think this is the direction and we can prepare for it in advance. Putting such non-routing information in one independent TLV can certainly keep the stability of IGP protocol. This was just an example of something that could be offloaded to a separate instance in the slides. It is not a specification. Thanks, Acee Thanks, Acee On 11/17/20, 1:08 AM, "wang...@chinatelecom.cn on behalf of Aijun Wang<mailto:wang...@chinatelecom.cn%20on%20behalf%20of%20Aijun%20Wang>" <wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>> wrote: Hi, Acee: As discussed on the list and during the 109 meeting, we have updated the draft to reflect the comments from the LSR community. Please see whether you have still other concerns or not and if there is no further comments on this direction, can we begin the WG adoption call then? Thanks you and Peter for your intense discussions for this draft. Thanks in advance. Best Regards Aijun Wang China Telecom > -----Original Message----- > From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> > Sent: Sunday, November 15, 2020 7:44 AM > To: Zhibo Hu <huzh...@huawei.com<mailto:huzh...@huawei.com>>; Aijun Wang > <wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>; Gyan S. Mishra <gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>>; > Gyan Mishra <gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>> > Subject: New Version Notification for > draft-wang-lsr-passive-interface-attribute-06.txt > > > A new version of I-D, draft-wang-lsr-passive-interface-attribute-06.txt > has been successfully submitted by Aijun Wang and posted to the IETF > repository. > > Name: draft-wang-lsr-passive-interface-attribute > Revision: 06 > Title: Passive Interface Attribute > Document date: 2020-11-15 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-wang-lsr-passive-interface-attribute-06.t > xt > Status: > https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/ > 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-06 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-attribute-06 > > 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<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
