Re: [RTG-DIR] [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05

Chongfeng Xie <chongfeng.xie@foxmail.com> Mon, 04 December 2023 02:16 UTC

Return-Path: <chongfeng.xie@foxmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA951C14F5FA; Sun, 3 Dec 2023 18:16:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.17
X-Spam-Level:
X-Spam-Status: No, score=-4.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HELO_DYNAMIC_IPADDR=1.951, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7lElx6N5eKw; Sun, 3 Dec 2023 18:16:20 -0800 (PST)
Received: from out203-205-221-242.mail.qq.com (out203-205-221-242.mail.qq.com [203.205.221.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BBFC14F5FD; Sun, 3 Dec 2023 18:16:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1701656171; bh=9CfNjxiTM9JGPpnko/duTScJt9Zged/4tRtqrnCJcXU=; h=Date:From:To:Cc:Subject:References; b=XYyrZJeMXhcb4tNLktZ0EOQY7NiGqxALSyloDevFRQycVRxxAbykYOYxM4y/VjL+R TqEzas6EuWkFqqin5Kb1R5Pg9eUJ/NoW5hdjzLezhh83W6bfpE2FlYJBNm17gZahKi +hHzcKtgs9Hgxyz6nFqBRXyU6CZBnHV3yt/qzdu4=
Received: from DESKTOP-48H476U ([219.142.69.75]) by newxmesmtplogicsvrsza7-0.qq.com (NewEsmtp) with SMTP id 409238A2; Mon, 04 Dec 2023 10:16:09 +0800
X-QQ-mid: xmsmtpt1701656169t82bmhvub
Message-ID: <tencent_8503D6733898E1C76A56AE16CAE4D75F570A@qq.com>
X-QQ-XMAILINFO: OZZSS56D9fAjudJy9WJeBi8CCbAFI/zflogbQYVSaWJyqxm6pkxc4BP4PRQKU9 Jao+gHtbDdDYqDfg8gmbnd2SIHaUgJk2HeVWlJ2RsFzSOAkrdocPXcB1OprMHimEZSethq6uUw8h 1oMLyeFUJ86zzGCqSU11bGGvVFpwxuNTqhSwiK2/QW4J4QXEh8Lc6SAasagDv+k82hhiP0G0m8HO fHG55yVn56rt6fkUh4wVKTMZaYSBdvxzl33JqQhP2voGmSV1kcO+UZ8H1nYu986sMW+m9px0ck+I VYGHslilLmR/xojAQXVm7DDQPAiJw8Hwse/kTzsKG23h9FC0HfB8vBBhs6EBeJVonpY540VUN+sl d7d3i2NL1w0ZVPZyT1bhIdQLeEaOidO/4gbnLXr2j/kWJAofKjYRRR5Mu43+4vJsWR1bXo3m7Mza 5p3eItjbGz+wa0t7subfJ4yjmBvO3tSFvhObfL0yav/xz13lUfWC7uIi71czlMwTZLxNhJhhh5i0 HdmBD/w97UA5mmi0lgLvgzrJVTy0EYNJnwzCjlMZlUsQ41c2PY983TmS4jiOZieGTxPia5FkhWLk Ih5URpjgjmsaY8XH/CWk5Q6uKTT97+t3QTx65vWk0ju777CW7UCIhoYRGQ0fCm8GBXxch8o58Kce G+CDMFBJArQJVTgnfgTbXM+8f3rxAw/1uG26jo9bWWrCeo95cMS3yrXYQ478i4NNur4Uz6KWWvM0 yvZc8LFjbOUMszlSp3/so9pscMcMNvUAVPXFJ4LC7ZhA3ZEKpbTA14UOCDz90y20/klxphseKz6t 2o9UAihM7zkwOFqW3osCOM/M3GRhEbuY7j8Pl5eEoxJYhfzjE1wXy7zX3QzMX7M+Z8x0o+d09/DI bONLEhGJOhwepeSYGRGUxOT6B/+2+T0ZpxSZRVGBp8PB8WOiJvtKnHKPqlN6KIqxUcL4Q3lpKpN9 GIhp/JpPS80/2KVrTYn8gCOxTEbVqkgdm89cZxr9gQdmzqi+W6Cs8HKysWZLLUd/m54Sm1pSE=
X-QQ-XMRINFO: NyFYKkN4Ny6FSmKK/uo/jdU=
Date: Mon, 04 Dec 2023 10:16:10 +0800
From: Chongfeng Xie <chongfeng.xie@foxmail.com>
To: Daniele Ceccarelli <daniele.ietf@gmail.com>, xiechf <xiechf@chinatelecom.cn>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-lsr-isis-sr-vtn-mt.all" <draft-ietf-lsr-isis-sr-vtn-mt.all@ietf.org>, last-call <last-call@ietf.org>, lsr <lsr@ietf.org>
References: <170083564826.2243.2272186713134973815@ietfa.amsl.com>, <202311290759599391988@chinatelecom.cn>, <CAB01kMjYFKU56FSFrGxqxmndgt2Xq5ucxAa818U279o3e+jpug@mail.gmail.com>
X-Priority: 3
X-GUID: F39082F5-C39E-4C12-92EA-34E642A27D50
X-Has-Attach: no
X-Mailer: Foxmail 7.2.24.96[cn]
Mime-Version: 1.0
X-OQ-MSGID: <202312041016101751032@foxmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart736868228153_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/C7P20p9P76n1LTJyK4dqxlqLe9A>
Subject: Re: [RTG-DIR] [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Dec 2023 02:16:25 -0000

Hi Daniele,
Thank you for your suggestion, we will add some text to explain the comment in the next version.

Best regards
Chongfeng

From: Daniele Ceccarelli
Date: 2023-12-01 23:42
To: Chongfeng Xie
CC: rtg-dir@ietf.org; draft-ietf-lsr-isis-sr-vtn-mt.all; last-call; lsr
Subject: Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
Hi Chongfeng,

Thanks for addressing my comments.
I would just suggest to add some text to the draft to explain the comment below


[Chongfeng] This is discussed in the scalability considerations section of this draft. This mechanism is useful for network scenarios in which the required number of VTN/NRP is small, the advantage is no protocol extension is required (as reflected by the document type). For network scenarios where the number of required VTN/NRP is large, more scalable solution would be needed, which may result in further protocol extensions and enhancements.


BR
Daniele  

On Wed, Nov 29, 2023 at 1:00 AM Chongfeng Xie <xiechf@chinatelecom.cn> wrote:

Hi Daniele,

Thanks a lot for your careful review and comments. Please see my replies inline [Chongfeng]:

-----Original Message-----
From: Daniele Ceccarelli via Datatracker [mailto:noreply@ietf.org]
Sent: Friday, November 24, 2023 10:21 PM
To: rtg-dir@ietf.org
Cc: draft-ietf-lsr-isis-sr-vtn-mt.all@ietf.org; last-call@ietf.org; lsr@ietf.org
Subject: Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05

Reviewer: Daniele Ceccarelli
Review result: Has Issues

- General: The term and concept of Enhanced VPN is being discussed in TEAS as part of the WG last call. I suggest to follow that thread and align the draft with whatever output will be agreed.

[Chongfeng] Yes the terminology in this draft will align with the decision on terminology in in TEAS 

- General: i would suggest to change the title into "Applicability" rather than using. Per my understanding this document describes how to use existing mechanisms to achieve something new (the status is correctly informational)

[Chongfeng] Agree, we can make this change in next revision.

- Abstract: "enhanced isolation". i checked if it was defined in the framework for Enhanced VPNs in TEAS, but i couldn't find a definition there nor in this draft. What does it mean?

[Chongfeng] We will align this description with the enhanced VPN framework draft.

- VTN: is this a new term to identify a set of existing items? E.g. an ACTN VN, NRP, a set of RSVP-TE tunnel, a topology built with flex algo...are they cases of VTN or the VTN is a different thing?

[Chongfeng] According to the recent discussion in TEAS, it is agreed to replace the term VTN with NRP.

- Intro: s/than that can be provided/than the ones that can be provided

[Chongfeng] OK.

- "Another possible approach is to create a set of point-to-point paths, each with a set of network resources reserved along the path, such paths are called Virtual Transport Path (VTP)". In what is this different from an ACTN VN member? See RFC 8453.

[Chongfeng] VN member as defined in RFC 8453 refers to "edge-to-edge link" exposed in the management plane, which is formed as end-to-end tunnels in the underlying networks. The term VTP refers to point-to-point underlay paths with network resource reserved along the path. So VTPs can be considered as one specific type of underlay tunnel with resource reservation. As we will replace VTN with NRP, we will consider whether the term VTP is still needed or not.

- Introduction: "In some network scenarios, the required number of VTNs could be small, and it is assumed that each VTN is associated with an independent topology and has a set of dedicated or shared network resources. This document describes a simplified mechanism to build SR based VTNs in those scenarios." I don't understand, is there the need for a specific mechanisms (different from existing ones) only for particular cases in which the number of VTNs is small (smaller than other scenarios)?

[Chongfeng] This is discussed in the scalability considerations section of this draft. This mechanism is useful for network scenarios in which the required number of VTN/NRP is small, the advantage is no protocol extension is required (as reflected by the document type). For network scenarios where the number of required VTN/NRP is large, more scalable solution would be needed, which may result in further protocol extensions and enhancements.

 Section 3.1 "The usage of other TE attributes in topology-specific TLVs is for further study." The draft is pretty simple and small, can't the usage of other TE attributes be described here as well?

[Chongfeng] Yes the encoding of TE attributes in topology-specific TLVs is simple, while a more important thing is to find valid use case for them. The current VTN/NRP use case only makes use of the bandwidth attribute, other TE attributes are not in the scope. Thus this statement is considered OK for this document.

Best regards
Chongfeng