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

[Chongfeng Xie <[e-mail]>]

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: [e-mail]; 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 <[e-mail]> 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:[e-mail]]
Sent: Friday, November 24, 2023 10:21 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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