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

Chongfeng Xie <> Wed, 29 November 2023 00:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B272C14CE42; Tue, 28 Nov 2023 16:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.831
X-Spam-Status: No, score=0.831 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_MSPIKE_H3=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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aykfN_9AvKb9; Tue, 28 Nov 2023 16:51:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 164EAC151548; Tue, 28 Nov 2023 16:51:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s201512; t=1701219083; bh=Wibtkkkwftr3BR/gIoPorX3JgAcXJ850Xw6ugysG3Jw=; h=Date:From:To:Cc:Subject:References; b=Yt6VQkJWKZzWNAoj/34uzYIHxctX+aBOen9on9KgA04FNz+UMfGsv/XspV5UBQySc ckBJ4Wvxmn6bn1s97a3nyt5uDAcUi6WX6PqPZ2dcfZM8Qs3FpwQDnU0EnN0V4xi9Po kRbJiRYLxiZPTTsljzlpuvkX9nRUTJ7to9msBR+8=
Received: from DESKTOP-48H476U ([]) by (NewEsmtp) with SMTP id CD4A7EE4; Wed, 29 Nov 2023 08:51:20 +0800
X-QQ-mid: xmsmtpt1701219080tg1o9128i
Message-ID: <>
X-QQ-XMAILINFO: NkHKfw09D6j80f0HIM8VhhHlS2W5xeiUEmEFYH4QqCImTkvw6QYecvrEyXsqto YFwc2ycdD9SlL6SItgcFnjPzVdpAgHDiG6AOEiJVG4wnruBU3lCId+ow2i/bZtrO351Fv1Iaczb5 YiC898QESLAUuXdPgOcbMTCmyLDqk15GFbAgLeAT7fRwq1J2V1X3N8s4AG2dN3XkA+to8mKWrWml sTsgg9F4vYjIKRrF1twKE1wzooYbNbquTn71P+X8ny3jPV33S4ht7o4hQCcOUKYH6w5Kz0+O8tkz 3lCO0AjgtJ7eS7kHOgYwF00XvYcDZbCjIpABLCc7Ao6G/m8anwsj2jT4M4nyp3vsDiPCXn0K3OJ7 0DCrk5Nu0WzKK+26DaeqNSZsP3nKQNFnFPuQyIVvAVvpy/sP6OWNHnUuw75r57SMB35QiYMLHbn3 1btPaMrjF+G2qVyzNZX5XttErEZxlLmaWgUEDwbumDDDMRt1yCclbxRimzwrbMZ1WM/uqEPUHh0d GqvNJ0gYVQ/iIfhpbb0bJMJ5VaZtFkoE0KAmJx7wYG6Zm0kdZ3Y8hbPxHQgrrexzyCDmR0/zjeTJ +hvpDTN1LmNy/r4kn82SyTGsCbgUmjKuj+fSWpmUmyevdPDij6KQKUoVu+3AtDryIo9JHCJPHKsE 1HKmtKQaXo3KWYJHsOV8bTKlUIQaNwEXwrXZyDXLv/riZGV+7v1E6Q1dtj0xjAjYGjvJYzjfcabF olzZSSiaS+gPHDXSXPVCOh5k6DiuvFnMh7wW++IJ0PnBvUkyS3/ZCD2IrxZNy62WHT1SRoGZE4iV USes7Hd3X6lareZrmY2AD+jZTAs9jNBA1xky6TYnvG2iLMBiC6AQNRLY/Gs8IyA1KODQ78epKy4Q hCYMQoAtvz5DubFb9brQn6pD2u6+KMCFqnpp4fXWnCmI7X5KAPX3up1gXISxp9wL4snSV4ZSLiLI rPetrXl/DnLNVX5l6fqDf7IpncTxFFbzLjER+t0pRmMNsp9aXhCB3G8t1Ex5ek
Date: Wed, 29 Nov 2023 08:51:23 +0800
From: Chongfeng Xie <>
To: Daniele Ceccarelli <>, "" <>
Cc: "draft-ietf-lsr-isis-sr-vtn-mt.all" <>, last-call <>, lsr <>, xiechf <>
References: <>
X-Priority: 3
X-GUID: 63C657E1-12B7-4EFC-B6A1-5D0A24ED65BE
X-Has-Attach: no
X-Mailer: Foxmail[cn]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_001_NextPart138663777635_=----"
Archived-At: <>
Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Nov 2023 00:51:36 -0000

Hi Daniele,

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

-----Original Message-----
From: Daniele Ceccarelli via Datatracker []
Sent: Friday, November 24, 2023 10:21 PM
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