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

Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 23 November 2020 02:16 UTC

From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: "'Acee Lindem (acee)'" <acee=40cisco.com@dmarc.ietf.org>, lsr@ietf.org
References: <B0990E97-A2C3-476E-B4B1-F09D29233322@cisco.com>
In-Reply-To: <B0990E97-A2C3-476E-B4B1-F09D29233322@cisco.com>
Date: Mon, 23 Nov 2020 10:16:29 +0800
Message-ID: <027a01d6c13e$a77c90a0$f675b1e0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_027B_01D6C181.B5A28FC0"
Content-Language: zh-cn
Thread-Index: AQKq2FPt3V92fdCk9g2m1GkCJjgB1agsyK2g
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LppwUNb_ngr8m4awaprvSHGFfhg>
Subject: Re: [Lsr] Responses for comments on "passive interface attribute" draft
Precedence: list

Hi, Acee:

 

Stub-link is actually the special part of the IGP topology information. It must be taken into consideration when we done inter-as work, for example, inter-as topology retrieval, or inter-as TE etc.

Current solutions for such scenarios require tedious configuration on each boundary interface. 

With the help of central controller and the information that provided by the stub-link, it is easy to reconstruct the inter-as topology, steering the traffic to the right boundary interface. The routers within the IGP domain can also select the right nexthop to arrive the server that attached to the stub-link.

We have ignored the usage of the stub-link for long time, is it the time to shine it then?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
Sent: Friday, November 20, 2020 3:36 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn>; lsr@ietf.org
Subject: [Lsr] Responses for comments on "passive interface attribute" draft

 

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 <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> >
Date: Thursday, November 19, 2020 at 10:06 PM
To: Acee Lindem <acee@cisco.com <mailto:acee@cisco.com> >, "lsr@ietf.org <mailto:lsr@ietf.org> " <lsr@ietf.org <mailto:lsr@ietf.org> >
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: lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>  <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> > On Behalf Of Acee Lindem (acee)
Sent: Friday, November 20, 2020 6:17 AM
To: lsr@ietf.org <mailto:lsr@ietf.org> 
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

[Lsr] Responses for comments on "passive interfac… Acee Lindem (acee)
Re: [Lsr] Responses for comments on "passive inte… Aijun Wang