Re: [Lsr] LSR meeting comment on draft-acee-lsr-ospf-transport-instance
Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 10 March 2021 09: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 894E63A1FBB for <lsr@ietfa.amsl.com>; Wed, 10 Mar 2021 01:06:18 -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=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 KfMy4C8QtHHD for <lsr@ietfa.amsl.com>; Wed, 10 Mar 2021 01:06:16 -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 A50C83A1FB8 for <lsr@ietf.org>; Wed, 10 Mar 2021 01:06:12 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id A5E5F1C0196; Wed, 10 Mar 2021 17:06:08 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Uma Chunduri' <umac.ietf@gmail.com>, lsr@ietf.org
References: <CAF18ct5-up=PDMfMyRk_-yV9bMQEgOjvma+9q+X19uyOCC0atw@mail.gmail.com>
In-Reply-To: <CAF18ct5-up=PDMfMyRk_-yV9bMQEgOjvma+9q+X19uyOCC0atw@mail.gmail.com>
Date: Wed, 10 Mar 2021 17:06:07 +0800
Message-ID: <009501d7158c$9b9e8160$d2db8420$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0096_01D715CF.A9C2F9E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLd4bhNPq/SZrGB5D1+Jmzx6A2IyahvVHzQ
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGkwaGB8eGk1DHhhLVkpNSk5ITUxKTUNDTUlVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hOT1VLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MUk6MBw5SD8OAwweLjBJFTgo C0hPCwtVSlVKTUpOSE1MSk1CSUxNVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpKQ01MNwY+
X-HM-Tid: 0a781b62e2ecd993kuwsa5e5f1c0196
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/WKiGwWlqhj5x-Omn6W37fExHcXc>
Subject: Re: [Lsr] LSR meeting comment on draft-acee-lsr-ospf-transport-instance
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: Wed, 10 Mar 2021 09:06:19 -0000
Hi, Authors: I think other use case, such as 3.2 and 3.3 can also be solved by other means. Following the direction of using different routing instances to transfer such information is not one feasible way. Best Regards Aijun Wang China Telecom From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Uma Chunduri Sent: Tuesday, March 9, 2021 4:48 AM To: lsr@ietf.org Subject: [Lsr] LSR meeting comment on draft-acee-lsr-ospf-transport-instance Dear Authors, Just want to quickly clarify my comment today on this draft. We know there was a significant discussion many years ago when similar work was done during RFC 6822 (ISIS-MI) and RFC 6823 (GenInfo). The usefulness of this is evident with the more recent publication https://datatracker.ietf.org/doc/rfc8202/. I am certainly not in the group and would not question 'why' this is needed in OSPF. However, section 3.1 use cases are difficult to understand and quite frankly either through the reference (ETSI-WP28-MEC) or the cases listed. As long as there is overlay in those networks (with the 3GPP preferred option expanded rapidly for multiple interfaces beyond N9, F1, W1 etc after REL16+) the usefulness of this core network and application info into the underlay and routing layer is limited and even more so for UEs. So please either expand the use case (sec 3.1) to see how this is applicable or leave it out for future scenarios. -- Uma C.
- [Lsr] LSR meeting comment on draft-acee-lsr-ospf-… Uma Chunduri
- Re: [Lsr] LSR meeting comment on draft-acee-lsr-o… Aijun Wang