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

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

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC4C3A1193 for <lsr@ietfa.amsl.com>; Sun, 22 Nov 2020 18:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.018
X-Spam-Level:
X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSeUT0B0BjZd for <lsr@ietfa.amsl.com>; Sun, 22 Nov 2020 18:16:35 -0800 (PST)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D8D3A1190 for <lsr@ietf.org>; Sun, 22 Nov 2020 18:16:33 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id E506C464FA; Mon, 23 Nov 2020 10:16:29 +0800 (CST)
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"
X-Mailer: Microsoft Outlook 16.0
Content-Language: zh-cn
Thread-Index: AQKq2FPt3V92fdCk9g2m1GkCJjgB1agsyK2g
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTUIdTB9MH09MGktNVkpNS01LQkxMQktKSklVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MEk6KBw*ED8eEQE2PDctLT08 MDowFChVSlVKTUtNS0JMTEJLTUlCVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUlNTEJDNwY+
X-HM-Tid: 0a75f2e3643a9865kuuue506c464fa
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LppwUNb_ngr8m4awaprvSHGFfhg>
Subject: Re: [Lsr] Responses for comments on "passive interface attribute" draft
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Nov 2020 02:16:38 -0000

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