Re: [Lsr] Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 09 March 2021 03:58 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 786383A0DD3; Mon, 8 Mar 2021 19:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xwA2iIFlFoma; Mon, 8 Mar 2021 19:58:43 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DBF3A0E08; Mon, 8 Mar 2021 19:58:30 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id AE0F11C0094; Tue, 9 Mar 2021 11:58:03 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: "'Acee Lindem (acee)'" <acee=40cisco.com@dmarc.ietf.org>, draft-dunbar-lsr-5g-edge-compute-ospf-ext@ietf.org
Cc: lsr@ietf.org
References: <47E791C6-FA30-4B65-874C-C1460E3E330B@cisco.com>
In-Reply-To: <47E791C6-FA30-4B65-874C-C1460E3E330B@cisco.com>
Date: Tue, 09 Mar 2021 11:58:03 +0800
Message-ID: <017c01d71498$67b971b0$372c5510$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_017D_01D714DB.75E0D060"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIgTt0kw+SU6FKIl0GDaU+hMYzZI6nokI7w
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTh1LTB8YGR4dSBhPVkpNSk5JTUlJQ0hCT0tVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6P1E6HAw6HT8QPQ4zEkI5EEs4 EEMwCghVSlVKTUpOSU1JSUNPSEJPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpPQ0pONwY+
X-HM-Tid: 0a7815227825d993kuwsae0f11c0094
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/VDkQ1tCmTXpGQMwBgyM8iSLYIKQ>
Subject: Re: [Lsr] Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03
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: Tue, 09 Mar 2021 03:58:46 -0000

Hi, Acee:

 

From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
Sent: Tuesday, March 9, 2021 4:12 AM
To: draft-dunbar-lsr-5g-edge-compute-ospf-ext@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03

 

Speaking as WG member:

 

Hi Linda and Co-authors, 

 

My first major comment is the confusion with the usage of multiple anycast addresses for the same application. Why are you requiring multiple anycast address? It would seem the load balancing over multiple servers can be done at the data center layer. I guess a UE would use the same anycast address for an application based on the initial DNS query? It is very confusing. 

 

My second major comment is that in section 4, you point out that an aggregated metric would solve the problem. However, the purported downside is that all the Application Egress Routers (A-ERs) would need to use the same algorithm to aggregate the various capacity measurements into a single metric. It would seem to be an even larger obstacle for all the OSPF routers in the area to support these new metrics and consistent routing based on those metrics. 

 

Also, some minor comments:

 

1.       Why do you talk about ACLs to determine the anycast addresses? Presumably, you wouldn’t even have these metrics available for other addresses. 

2.       Section 5 still references the misguided draft-wang-lsr-passive-interface-attribute draft. I believe you meant to remove this. 

[WAJ] To transfer the raw information about the server, is the prefix address TLV right container for such information?   There may be other parameters to be associated in future, for example, the bandwidth, the delay, where will you put all these information that can influence the performances of App server?  https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ describes just the general container for such information.

 

There are other nits as well but it doesn’t make sense to spend time on them at this stage. 

 

Thanks,
Acee