Hi Aijun,
[WAJ] In your 109 meeting presentation slides-109-lsr-5-ospf-transport-instance-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fslides-109-lsr-5-ospf-transport-instance-00&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103032356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=QfOxriK5LaSR%2Fj5z1H8pF9R9rtiAHmI3de%2BfL83QkaU%3D&reserved=0>, 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. Just to respond this comment here. The purpose of OSPF transport instance is to carry non-routing information for applications without impacting routing calculation and convergence. When you say “this is the direction”, do you mean using OSPF transport instance to carry application data or to use base OSPF instance? Also how putting such non-routing information in one independent TLV can keep the stability of IGP protocol? Depending on the application, this kind of information may need to be updated very often, for example CPU usage, and this will certainly have some impacts. Especially when there more applications and each of them needs to be updated at different intervals and frequencies. Thanks, Yingzhen From: Lsr <[email protected]> on behalf of Aijun Wang <[email protected]> Date: Tuesday, November 17, 2020 at 11:06 PM To: "'Acee Lindem (acee)'" <[email protected]> Cc: 'lsr' <[email protected]> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt Resent-From: <[email protected]> Resent-Date: Tuesday, November 17, 2020 at 11:06 PM Hi, Acee: From: Acee Lindem (acee) <[email protected]> Sent: Wednesday, November 18, 2020 12:39 PM To: Aijun Wang <[email protected]> Cc: 'lsr' <[email protected]> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt From: Aijun Wang <[email protected]<mailto:[email protected]>> Date: Tuesday, November 17, 2020 at 9:27 PM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: 'lsr' <[email protected]<mailto:[email protected]>> Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt Hi, Acee: -----Original Message----- From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Acee Lindem (acee) Sent: Wednesday, November 18, 2020 2:47 AM To: Aijun Wang <[email protected]<mailto:[email protected]>> Cc: 'lsr' <[email protected]<mailto:[email protected]>> 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. [WAJ] what’s your recommendation then? The router can skip such information when they do SPF calculation, just need only add the information to the attached leaf router when the computation is completed. The LSA update is periodic and event driven. Advertising such information in a controlled manner does not deteriorate the flooding status. 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-06%23section-1&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103012366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FGMZ9tt7BYH1IEsO3zbkxvWJSqPMchOtbLk%2BlaVpctc%3D&reserved=0>. 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? [WAJ] Passive interface be certainly attached the router that advertises the associated stub-link TLV. As I stated previously, passive interfaces are not standardized. [WAJ] if you mentioned just the term, we can change it later. Or if so, what’s other term do you recommend then? 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-06%23section-1&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103012366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FGMZ9tt7BYH1IEsO3zbkxvWJSqPMchOtbLk%2BlaVpctc%3D&reserved=0> and think it is not appropriate to expand it intensely in one LSR draft. I disagree. Precisely define your use case. [WAJ] which part of the introduction section is not clear enough? There are about 3 possible use cases of such information, aren’t they enough? And, we have described one use case in detail in previous version of this draft draft-wang-lsr-passive-interface-attribute-04#section-3<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-04%23section-3&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103022360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Hs5TOmOm%2BxV8hrQA6HFzhUB9KE185Jl9GfNwrJfWg8M%3D&reserved=0>. If necessary, we can add it back again in the next version. This is just one use case, you can also refer to draft-dunbar-lsr-5g-edge-compute-ospf-ext-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext-01&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103022360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=eKg%2FQ3txyEnu91eOjVUsRnLLQOyYlomuDI1s9%2FeMHEE%3D&reserved=0> for the detail of another 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fslides-109-lsr-5-ospf-transport-instance-00&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103032356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=QfOxriK5LaSR%2Fj5z1H8pF9R9rtiAHmI3de%2BfL83QkaU%3D&reserved=0>, 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, "[email protected] on behalf of Aijun Wang<mailto:[email protected]%20on%20behalf%20of%20Aijun%20Wang>" <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> > Sent: Sunday, November 15, 2020 7:44 AM > To: Zhibo Hu <[email protected]<mailto:[email protected]>>; Aijun Wang > <[email protected]<mailto:[email protected]>>; Gyan S. Mishra <[email protected]<mailto:[email protected]>>; > Gyan Mishra <[email protected]<mailto:[email protected]>> > 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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-lsr-passive-interface-attribute-06.t&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103032356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3zW%2B%2F%2FBGjk6HEGGC%2BKVnPD%2Bb%2BsCqNLi%2F4c6O4sLB7EI%3D&reserved=0> > xt > Status: > https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-passive-interface-attribute%2F&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103042350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=JTLyzo58M3OMIveairU%2FaIGAMIE9uFNjxSBl%2FIJ86tg%3D&reserved=0> > Htmlized: > https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribut<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribut&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103042350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=s%2FFUlcuBnoslsi439vzARhB7YbJZ7W9br4vdzKE%2BJ0c%3D&reserved=0> > e > Htmlized: > https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-06<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-06&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103052350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3%2Fbydp44N0xCkRX8%2BziceSKQMWeNK3ESfFtjWKKn1M8%3D&reserved=0> > Diff: > https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-attribute-06<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-wang-lsr-passive-interface-attribute-06&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103052350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=MxqLAxJLXGRMw65Ux0C02T2xZ3YbEJltR%2FQIoWPvoQ8%3D&reserved=0> > > 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C0aefa9b419b340fbde8b08d88b908316%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637412800103062336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=2rsCIRThFJeRUtIQ464b8WWrRZA2p0lzBUD6BT9S7EA%3D&reserved=0>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
