IETF Logo Mail Archive

[lisp] Comments on https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-10

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 12 August 2021 16:21 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF4B3A1889 for <lisp@ietfa.amsl.com>; Thu, 12 Aug 2021 09:21:42 -0700 (PDT)
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 od5tvrGYFYc7 for <lisp@ietfa.amsl.com>; Thu, 12 Aug 2021 09:21:37 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDA83A187F for <lisp@ietf.org>; Thu, 12 Aug 2021 09:21:36 -0700 (PDT)
Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GlsPK5vwYz6CBTL for <lisp@ietf.org>; Fri, 13 Aug 2021 00:20:53 +0800 (CST)
Received: from msceml702-chm.china.huawei.com (10.219.141.160) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 12 Aug 2021 18:21:32 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 12 Aug 2021 19:21:31 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2176.012; Thu, 12 Aug 2021 19:21:31 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "lisp@ietf.org" <lisp@ietf.org>
Thread-Topic: Comments on https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-10
Thread-Index: AdePlfEkUc6zeCO+Suu8zKwBBcx4Gg==
Date: Thu, 12 Aug 2021 16:21:31 +0000
Message-ID: <13e7e46d97c0401fb818bdf596964902@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.207.211]
Content-Type: multipart/related; boundary="_004_13e7e46d97c0401fb818bdf596964902huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/l5mmiWhcpRmcaCFm4CgfQSj6KJo>
Subject: [lisp] Comments on https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-10
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Aug 2021 16:21:42 -0000

Hi Guru,
I have looked subject and have a few comments:


1.       The draft does mention a few times "without triangle routing in the data path".
But section 7.4: "As a result, packets may be natively forwarded to non-LISP sites by an ITR (the return path will through a PITR, however, since the packet flow will be non-LISP site to LISP site)."
Do I understand right that it is exactly "triangle routing"? Encapsulation in both directions would be needed if you insist on "without triangle routing" or you could delete the requirement.

2.       All discussions are in the style that it is "handover", not "roaming". "Roaming" has been mentioned 28 times in the draft but it is exactly what was *not* implemented.
I mean: what if the next RLOC would be from a completely different administrative domain? What if not just link would be switched but Carrier would be switched?
IMHO: "roaming" is a mandatory case for the word "Mobile" in the title of the draft.
Please, at least rename "roaming" to "handover" till roaming would be proposed. It is better to be accurate with Mobile terminology.

3.       It has been mentioned that there is a requirement for "multi-homing", but it has not been discussed at all later.
IMHO: an additional section is needed to explain how "TCP connections to stay alive while roaming" - probably "multi-homing" should help with this.

[cid:image001.png@01D3A7DF.E7D86320]
Best Regards
Eduard Vasilenko
Senior Architect
Europe Standardization & Industry Development Department
Tel: +7(985) 910-1105, +7(916) 800-5506

v2.23.0 | Report a Bug | By Email