[Lsr] Responses for comments on "passive interface attribute" draft

["Acee Lindem (acee)" <[e-mail]>]

Speaking as WG member and updating subject:

Hi Aijun,

We’re not going to add stub links back into Router-LSAs under any circumstance since that was an advantage of OSPFv3 over OSPFv2 (refer to section 2.8 of RFC 5340). Additionally, we’re going to be careful as to what information we put into the topological LSAs.

With respect to your specific use case, you haven’t disclosed it other than you’re making some loose inference based on an interface being a passive interface  (which isn’t a standardized IGP concept). Rather, you should precisely design your use case and then we can talk about a solution.

Thanks,
Acee

From: Aijun Wang <[e-mail]>
Date: Thursday, November 19, 2020 at 10:06 PM
To: Acee Lindem <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [Lsr] IETF I09 LSR Meeting Minutes(Responses for comments on "passive interface attribute" draft)

HI, Acee:

Thanks for the minutes, and also thanks for Yingzhen.

Below are the responses for the comments regarding to draft-wang-lsr-passive-interface-attribute-06<https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-06>, please see whether they address your concern or not.
For simplicity, I just summary the key points of the comments.
【Chris】: Why not using the existed TLV to solve the Inter-as use case?
【Reply-from Aijun Wang】: For inter-AS use case, using the existed TLV has the constraints that described in https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/

【Chris】: Why not using prefix attributes to advertise application server’s information?
【Reply-from Aijun Wang】: It is possible to advertise these information together with prefix. But when we want to describe the resources(for example, link bandwidth, link utilization ratio etc.) to the prefix, it is more reasonable to associated them to link attributes.

On summary, considering the above two use case has the common characteristic, that is, the associated link is stub-link, we think that defines the stub-link TLV to contain the these information  is more extensible.

【Acee】: Why not just advertise the link is the inter-AS boundary or other , and doesn’t need to infer this conclusion?
【Reply-from Aijun Wang】: If necessary, we can add one flag field to indicate clearly the sub-type of the stub-link. But currently, they are all passive-interface, has no other distinguished differences.
The usage of such information, or the inferences method, may be different in different scenario. I think the standardization work should defines the fundamental common parts.


Best Regards

Aijun Wang
China Telecom

From: [e-mail] <[e-mail]> On Behalf Of Acee Lindem (acee)
Sent: Friday, November 20, 2020 6:17 AM
To: [e-mail]
Subject: [Lsr] IETF I09 LSR Meeting Minutes

I have uploaded the minutes for the meeting on Monday morning. Thanks much to Yingzhen Qu for taking them. Please send me any additions or corrections to me.

https://datatracker.ietf.org/doc/minutes-109-lsr/

Presenters and draft authors, please note that if more discussion is need on your draft then it is up to you to initiate such discussion.

Thanks,
Acee