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

From: "Aijun Wang" <[email-masked]>
Date: Tue, 17 Nov 2020 14:07:44 +0800

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-masked] <[email-masked]>
> Sent: Sunday, November 15, 2020 7:44 AM
> To: Zhibo Hu <[email-masked]>; Aijun Wang
> <[email-masked]>; Gyan S. Mishra <[email-masked]>;
> Gyan Mishra <[email-masked]>
> 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
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 Nov 2020 18:46:36 +0000

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. 

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.

Please don't try and solve the CFN problem as the requirements are not clear (anycast, unicast, impact on routing, scope, etc). 

Thanks,
Acee

On 11/17/20, 1:08 AM, "[email-masked] on behalf of Aijun Wang" <[email-masked]> wrote:

    Hi, Acee:

    Thanks in advance.

    Best Regards

    Aijun Wang
    China Telecom

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 18 Nov 2020 10:26:36 +0800

Hi, Acee:

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang <[email-masked]>
Cc: 'lsr' <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi Aijun, 

[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?

[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.

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.

[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. 

Thanks,

Acee

On 11/17/20, 1:08 AM, " <mailto:[email-masked]%20on%20behalf%20of%20Aijun%20Wang> [email-masked] on behalf of Aijun Wang" < <mailto:[email-masked]> [email-masked]> wrote:

    Hi, Acee:

    Thanks in advance.

    Best Regards

    Aijun Wang

    China Telecom

    > From:  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> [email-masked]>

    > To: Zhibo Hu < <mailto:[email-masked]> [email-masked]>; Aijun Wang

    > < <mailto:[email-masked]> [email-masked]>; Gyan S. Mishra < <mailto:[email-masked]> [email-masked]>;

    > Gyan Mishra < <mailto:[email-masked]> [email-masked]>

    >  <https://www.ietf.org/archive/id/draft-wang-lsr-passive-interface-attribute-06.t> https://www.ietf.org/archive/id/draft-wang-lsr-passive-interface-attribute-06.t

    >  <https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/

    >  <https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribut> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribut

    >  <https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-06> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-06

    >  <https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-attribute-06> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-attribute-06

 

_______________________________________________

Lsr mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 18 Nov 2020 04:39:02 +0000

From: Aijun Wang <[email-masked]>
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem <[email-masked]>
Cc: 'lsr' <[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi, Acee:

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang <[email-masked]>
Cc: 'lsr' <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi Aijun,

No – bloating the primary LSAs with non-routing information will be more expensive due to the dynamics of LSA origination and route computation.

[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.

[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, "[email-masked] on behalf of Aijun Wang<mailto:[email-masked]%20on%20behalf%20of%20Aijun%20Wang>" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi, Acee:

    Thanks in advance.

    Best Regards

    Aijun Wang

    China Telecom

    > From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

    > To: Zhibo Hu <[email-masked]<mailto:[email-masked]>>; Aijun Wang

    > <[email-masked]<mailto:[email-masked]>>; Gyan S. Mishra <[email-masked]<mailto:[email-masked]>>;

    > Gyan Mishra <[email-masked]<mailto:[email-masked]>>

Lsr mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/lsr

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 18 Nov 2020 15:05:52 +0800

Hi, Acee:

From: Acee Lindem (acee) <[email-masked]> 
Sent: Wednesday, November 18, 2020 12:39 PM
To: Aijun Wang <[email-masked]>
Cc: 'lsr' <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

From: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >
Cc: 'lsr' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi, Acee:

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: 'lsr' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi Aijun, 

[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. 

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?

[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://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-04#section-3> . 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://tools.ietf.org/html/draft-dunbar-lsr-5g-edge-compute-ospf-ext-01>  for the detail of another use case.  

Thanks,

Acee

Thanks,

Acee

    Hi, Acee:

    Thanks in advance.

    Best Regards

    Aijun Wang

    China Telecom

 

Lsr mailing list

---

From: Yingzhen Qu <[email-masked]>
Date: Wed, 18 Nov 2020 12:57:24 +0000

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-masked]> on behalf of Aijun Wang <[email-masked]>
Date: Tuesday, November 17, 2020 at 11:06 PM
To: "'Acee Lindem (acee)'" <[email-masked]>
Cc: 'lsr' <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt
Resent-From: <[email-masked]>
Resent-Date: Tuesday, November 17, 2020 at 11:06 PM

Hi, Acee:

From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: 'lsr' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi, Acee:

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: 'lsr' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi Aijun,

[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.

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.

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.

[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.

Thanks,

Acee

Thanks,

Acee

    Hi, Acee:

    Thanks in advance.

    Best Regards

    Aijun Wang

    China Telecom

    > 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>

    > 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>

    > 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>

    > 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>

    > 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>

Lsr mailing list

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>

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 19 Nov 2020 10:27:37 +0800

Hi, Yingzhen:

Please see whether the replies below inline can solve your concerns or not.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Yingzhen Qu
Sent: Wednesday, November 18, 2020 8:57 PM
To: Aijun Wang <[email-masked]>; 'Acee Lindem (acee)' <[email-masked]>
Cc: 'lsr' <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

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? 

[WAJ] use base OSPF instance is better. I think the reason to advertise the server info via IGP protocol is to let the router select the right path to server. 

Also how putting such non-routing information in one independent TLV can keep the stability of IGP protocol?

[WAJ] The router can easily recognize such info when it do SPF calculation, skip some steps(for example, topology calculation) then.

And, considering the interface that connects the server to the router is always passive, would you like to put these info into Stub-Link TLV that defined in the passive interface draft?

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.

[WAJ] They should all meet the minimum threshold, as also mentioned in Acee’s presentation file.

Thanks,

Yingzhen

From: Lsr <[email-masked] <mailto:[email-masked]> > on behalf of Aijun Wang <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, November 17, 2020 at 11:06 PM
To: "'Acee Lindem (acee)'" <[email-masked] <mailto:[email-masked]> >
Cc: 'lsr' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt
Resent-From: <[email-masked] <mailto:[email-masked]> >
Resent-Date: Tuesday, November 17, 2020 at 11:06 PM

Hi, Acee:

From: Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, November 18, 2020 12:39 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: 'lsr' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi, Acee:

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: 'lsr' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi Aijun, 

[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.

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.

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.  

[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. 

Thanks,

Acee

Thanks,

Acee

    Hi, Acee:

    Thanks in advance.

    Best Regards

    Aijun Wang

    China Telecom

    >  <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> https://www.ietf.org/archive/id/draft-wang-lsr-passive-interface-attribute-06.t

    >  <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> 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%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> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribut

    >  <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> https://tools.ietf.org/html/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> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-attribute-06

 

Lsr mailing list

 <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> https://www.ietf.org/mailman/listinfo/lsr

---

From: Yingzhen Qu <[email-masked]>
Date: Thu, 19 Nov 2020 08:46:09 +0000

Hi Aijun,

Please see my response below inline.

Thanks,
Yingzhen

From: Aijun Wang <[email-masked]>
Date: Wednesday, November 18, 2020 at 6:27 PM
To: Yingzhen Qu <[email-masked]>, "'Acee Lindem (acee)'" <[email-masked]>
Cc: 'lsr' <[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi, Yingzhen:

Best Regards

Aijun Wang
China Telecom

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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658792571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0zEyN2fX7sFk9H1yDe06BiCmZEQigkS2tlEDAtsC7qU%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.

[Yingzhen]: The path calculation to servers is done in the base instance. Transport instance doesn’t do or impact base instance path calculation.

[Yingzhen]: It’s not only about route computing, you will need to flood all the application information.

[Yingzhen]: We considered scalability issues and ways for mitigation, but I don’t think it was discussed it in your draft. Please let me know if I missed it. Also it’s not a good idea to mix flooding application information together with routing information.

Thanks,
Yingzhen

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Aijun Wang <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 17, 2020 at 11:06 PM
To: "'Acee Lindem (acee)'" <[email-masked]<mailto:[email-masked]>>
Cc: 'lsr' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, November 17, 2020 at 11:06 PM

Hi, Acee:

From: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 18, 2020 12:39 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: 'lsr' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi, Acee:

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: 'lsr' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi Aijun,

[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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658802564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=u1jp2Gh5FGvRsX5jpe%2FM3EAHAKB0oBtNUs4aVkR2XZI%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.

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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658812565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hwjvgwEZGe4vUDzWpxPPGRnzPbXsdcAZQMkwWrUovhk%3D&reserved=0> and think it is not appropriate to expand it intensely in one LSR draft.

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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658812565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7YmBswqHw%2FzTz949jph256KuSHKdRsos8d62roKxKDg%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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658822554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Go9uiHra7uSKQwbgQzMxBxq8WWQjs4%2BKZhpZrVy0ZPw%3D&reserved=0> for the detail of another use case.

[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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658832547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=XQXZVRYKVrYH2YeQs6zCX9hh7JgrksqZtIviIAgJPlk%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.

Thanks,

Acee

Thanks,

Acee

    Hi, Acee:

    Thanks in advance.

    Best Regards

    Aijun Wang

    China Telecom

    > 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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658832547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=YUL4xSfvMCJS0FOsw3YYynM1oLvKmWTbWWdKIn6JwE0%3D&reserved=0>

    > 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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658842542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=afbZUDIeGJwmmQ1qXOv5RG5pODeZNmV2o3al0p3%2Fx9Y%3D&reserved=0>

    > 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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658852535%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hoabrzbGGOqcAMaP5zMMZSzV%2Fs1tnio3EKwUzxiLo%2FE%3D&reserved=0>

    > 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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658852535%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=wog8EmavtkQ3xnqQbrWoGx9w9%2Bl%2FoHr%2F%2BuQLUoWSvxs%3D&reserved=0>

    > 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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658862529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7tA7h3gr%2FZ7%2BugZW4YunhBwDjhxQ6IuJL7AZZBI1wjU%3D&reserved=0>

Lsr mailing list

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%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658872532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=pGBx5p%2BUvwW6WHEgEsmQSVV%2BGmIXTkeNQzZf4DFidrQ%3D&reserved=0>