Re: [Lsr] IETF I09 LSR Meeting Minutes(Responses for comments on "passive interface attribute" draft)

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 20 November 2020 03:06 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 6E43A3A171A for <lsr@ietfa.amsl.com>; Thu, 19 Nov 2020 19:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 fpWipau3fO3j for <lsr@ietfa.amsl.com>; Thu, 19 Nov 2020 19:06:06 -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 6CB093A1715 for <lsr@ietf.org>; Thu, 19 Nov 2020 19:06:05 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 6174E4782C; Fri, 20 Nov 2020 11:06:01 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: "'Acee Lindem (acee)'" <acee=40cisco.com@dmarc.ietf.org>, lsr@ietf.org
Date: Fri, 20 Nov 2020 11:06:00 +0800
Message-ID: <013901d6beea$139cdbc0$3ad69340$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01D6BF2D.21C12D30"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Ada+4P4oGFIzbCyvQOeIziNqieJ4RQ==
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTUtCTh1JH0NNQk4fVkpNS05DT0pOTUpOSEhVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MU06KAw6Pz8tGQxJFDorLCIv TU1PCk9VSlVKTUtOQ09KTk1JS05PVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpPTEtONwY+
X-HM-Tid: 0a75e39da7759865kuuu6174e4782c
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/3ncuMMfYoH7L1oejZKA2b8Hal0Y>
Subject: Re: [Lsr] IETF I09 LSR Meeting Minutes(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: Fri, 20 Nov 2020 03:06:10 -0000

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 <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
Sent: Friday, November 20, 2020 6:17 AM
To: 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