Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
Hi Acee, Jia, Yes, version -06 had the changes to align with the TEAS terminology. Best regards Chongfeng chongfeng@foxmail.com From: Acee Lindem Date: 2024-01-24 03:16 To: Hejia (Jia) CC: Chongfeng Xie; Routing Directorate; 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, Jia, I believe that version -06 had the changes to align with the TEAS terminology - correct? This review is closed. Thanks, Acee > On Dec 14, 2023, at 2:29 AM, Hejia (Jia) > wrote: > > Hi Chongfeng, > Thanks for your reply. Your reply looks reasonable. > B.R. > Jia > 发件人: Chongfeng Xie [mailto:chongfeng@foxmail.com] > 发送时间: 2023年12月12日 13:14 > 收件人: Hejia (Jia) ; rtg-...@ietf.org > 抄送: draft-ietf-lsr-isis-sr-vtn-mt.all > ; last-call ; > lsr > 主题: Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05 >Hi Jia, > Thanks for the review comments. > I see your major comment is about the terminology alignment, as replied to > Daniele, we will follow the decision in TEAS to update the terminologies in > next revision. > Please see some replies to the minor issues inline: > From: He Jia via Datatracker > Date: 2023-12-11 16:09 > To: rtg-...@ietf.org > CC: draft-ietf-lsr-isis-sr-vtn-mt.all; last-call; lsr > Subject: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05 > Reviewer: He Jia > Review result: Not Ready > Hello, > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing > ADs. > For more information about the Routing Directorate, please see > https://wiki.ietf.org/en/group/rtg/RtgDir > Although these comments are primarily for the use of the Routing ADs, it > would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > Document: draft-ietf-lsr-isis-sr-vtn-mt-05 > Reviewer: Jia He > Review Date: December 10, 2023 > IETF LC End Date: date-if-known > Intended Status: Informational > Summary: > I have read the review comments from Daniele about the concept of enhanced > VPN, > and the relationship with other existing terms. I agree with his suggestion to > follow the discussion and align the draft with the output. In addition, some > minor issues and also nits are found out as follows and should be considered > prior to publication. > Minor Issues: > 1、In Section 1, it is said "Segment Identifiers (SIDs) can be used to > represent > both the topological instructions and the set of network resources allocated > by > network nodes to a VTN." Is it "allocated by network nodes" or "allocated to > network nodes"? If it is "network resources allocated by network nodes", why > not "allocated by centralized controllers" as well? If it is "network > resources > allocated to network nodes" which are assocated with a VTN, why not " > allocated > to network links" as well? Is there any special consideration by saying > "network nodes" only here? > [Chongfeng]： The description is a little bit confusing, actually it should > be "network resources of the network nodes and links which are allocated to a > VTN/NRP". We will update it in next revision. > 2、In Section 4, "For SRv6 data plane, the SRv6 SIDs associated with the > same > VTN can be used together to build SRv6 paths with the topological and resource > constraints of the VTN taken into consideration." Is "SRv6 Locator" missing? > [Chongfeng] SRv6 Locator is the covering prefix part of the SRv6 SIDs. In > SRv6 segment list, the SRv6 SIDs are used to indicate the forwarding path and > the set of resources used for packet processing. So the description is > correct. > Nits: > 1、Section 2, TLV 223 (MT IS Neighbor Attribute) is defined in RFC 5311, which > is not referenced in the draft. 2、Section 1, Paragraph 3, last sentence, > s/...need to be distributed using control plane/...need to be distributed > using > a control plane 3、Section 2, Paragraph 1, last sentecne, s/MT-ID could be used > as the identifier of VTN in control plane./MT-ID could be used as the > identifier of VTN in the control plane. 4、Section 2, "IS-IS Multi-Topology > [RFC5120]" and "IS-IS Multi-Topology Routing (MTR) [RFC5120]" are both used in > the draft. It is suggested to keep
Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
Hi Acee, Jia, Yes, version -06 had the changes to align with the TEAS terminology. Best regards Chongfeng chongfeng@foxmail.com From: Acee Lindem Date: 2024-01-24 03:16 To: Hejia (Jia) CC: Chongfeng Xie; Routing Directorate; 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, Jia, I believe that version -06 had the changes to align with the TEAS terminology - correct? This review is closed. Thanks, Acee > On Dec 14, 2023, at 2:29 AM, Hejia (Jia) > wrote: > > Hi Chongfeng, > Thanks for your reply. Your reply looks reasonable. > B.R. > Jia > 发件人: Chongfeng Xie [mailto:chongfeng@foxmail.com] > 发送时间: 2023年12月12日 13:14 > 收件人: Hejia (Jia) ; rtg-...@ietf.org > 抄送: draft-ietf-lsr-isis-sr-vtn-mt.all > ; last-call ; > lsr > 主题: Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05 >Hi Jia, > Thanks for the review comments. > I see your major comment is about the terminology alignment, as replied to > Daniele, we will follow the decision in TEAS to update the terminologies in > next revision. > Please see some replies to the minor issues inline: > From: He Jia via Datatracker > Date: 2023-12-11 16:09 > To: rtg-...@ietf.org > CC: draft-ietf-lsr-isis-sr-vtn-mt.all; last-call; lsr > Subject: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05 > Reviewer: He Jia > Review result: Not Ready > Hello, > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing > ADs. > For more information about the Routing Directorate, please see > https://wiki.ietf.org/en/group/rtg/RtgDir > Although these comments are primarily for the use of the Routing ADs, it > would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > Document: draft-ietf-lsr-isis-sr-vtn-mt-05 > Reviewer: Jia He > Review Date: December 10, 2023 > IETF LC End Date: date-if-known > Intended Status: Informational > Summary: > I have read the review comments from Daniele about the concept of enhanced > VPN, > and the relationship with other existing terms. I agree with his suggestion to > follow the discussion and align the draft with the output. In addition, some > minor issues and also nits are found out as follows and should be considered > prior to publication. > Minor Issues: > 1、In Section 1, it is said "Segment Identifiers (SIDs) can be used to > represent > both the topological instructions and the set of network resources allocated > by > network nodes to a VTN." Is it "allocated by network nodes" or "allocated to > network nodes"? If it is "network resources allocated by network nodes", why > not "allocated by centralized controllers" as well? If it is "network > resources > allocated to network nodes" which are assocated with a VTN, why not " > allocated > to network links" as well? Is there any special consideration by saying > "network nodes" only here? > [Chongfeng]： The description is a little bit confusing, actually it should > be "network resources of the network nodes and links which are allocated to a > VTN/NRP". We will update it in next revision. > 2、In Section 4, "For SRv6 data plane, the SRv6 SIDs associated with the > same > VTN can be used together to build SRv6 paths with the topological and resource > constraints of the VTN taken into consideration." Is "SRv6 Locator" missing? > [Chongfeng] SRv6 Locator is the covering prefix part of the SRv6 SIDs. In > SRv6 segment list, the SRv6 SIDs are used to indicate the forwarding path and > the set of resources used for packet processing. So the description is > correct. > Nits: > 1、Section 2, TLV 223 (MT IS Neighbor Attribute) is defined in RFC 5311, which > is not referenced in the draft. 2、Section 1, Paragraph 3, last sentence, > s/...need to be distributed using control plane/...need to be distributed > using > a control plane 3、Section 2, Paragraph 1, last sentecne, s/MT-ID could be used > as the identifier of VTN in control plane./MT-ID could be used as the > identifier of VTN in the control plane. 4、Section 2, "IS-IS Multi-Topology > [RFC5120]" and "IS-IS Multi-Topology Routing (MTR) [RFC5120]" are both used in > the draft. It is suggested to keep
Re: [Lsr] I-D Action: draft-ietf-lsr-isis-sr-vtn-mt-07.txt
Hi WG, We just posted a new revision of draft-ietf-lsr-isis-sr-vtn-mt to address all the review comments received during WG last call. The major changes are: - Incorporated the shepherd review comments from Acee. - Modified/added descriptive text to solve Xuesong’s review comments. - Removed the title of subsection 3.1, as it is the only subsection under section 3. - Removed the reference to draft-dong-lsr-sr-enhanced-vpn. - Other editorial changes. Thanks. Best regards Chongfeng From: internet-dra...@ietf.org Date: 2024-01-23 16:18 To: i-d-annou...@ietf.org CC: lsr@ietf.org Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-sr-vtn-mt-07.txt Internet-Draft draft-ietf-lsr-isis-sr-vtn-mt-07.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP) Authors: Chongfeng Xie Chenhao Ma Jie Dong Zhenbin Li Name:draft-ietf-lsr-isis-sr-vtn-mt-07.txt Pages: 9 Dates: 2024-01-23 Abstract: Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to build the SR-based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-sr-vtn-mt/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-sr-vtn-mt-07 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-sr-vtn-mt-07 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Hi Xuesong, Thanks for your support and review comments. We are working on a new revision which will take your comments into consideration. As for your suggestion to add reference to the more scalable solution, according to the comments from Acee, we would not mention the specific solution in this draft, but we have referred to the NRP scalability document for more information on the scalability discussion. Hope that would be OK to you. Best regards, Chongfeng From: Gengxuesong (Geng Xuesong) Date: 2024-01-11 18:37 To: Acee Lindem; Lsr Subject: RE: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Hi WG, I support the publication of this document. I think this is a reasonable method of network slicing implementation which could reuse the existing mechanism. Some editing comments for authors' reference. Best Xuesong -- 1. Introduction ... This document describes a simplified mechanism to build SR based NRPs in those scenarios. The resource-aware segments can be used with this approach to provide resource guaranteed SR based NRPs, while the normal SR segments may also be used to provide SR based NRPs with shared network resources in the forwarding plane. The proposed approach is to use IS-IS Multi-Topology [RFC5120] with segment routing [RFC8667] to define the independent network topology of each NRP. The network resources and other TE attributes of an NRP can be advertised using IS-IS MT with the Traffic Engineering (TE) extensions defined in [RFC5305] and [RFC8570]. [Xuesong] I recommend to swap the position of these two sentences. It will be easier for readers' understanding: show what is the proposal firstly and then describe this could be used with resource-aware segments to provide resource guaranteed SR based NRPs 2. Advertisement of Topology Attribute for SR based NRP [Xuesong] It will be helpful if there is a summary about what Topology Attribute for SR based NRP is requested before introducing what could be reused in different existing RFCs. 3. Advertisement of Resource Attribute for SR based NRP In order to perform constraint based path computation for each NRP on the network controller or on the ingress nodes, the network resource attributes and other attributes associated with each NRP need to be advertised. [Xuesong] It could be considered to add some explanation for whether this is just for this proposal or also could be used to other resource guaranteed SR based NRPs 5. Scalability Considerations The mechanism described in this document is considered useful for network scenarios in which the required number of NRP is small, as no control protocol extension is required. For network scenarios where the number of required NRP is large, more scalable solution would be needed, which may require further protocol extensions and enhancements. [Xuesong] This is helpful to add some reference for example of more scalable solutions. > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem > Sent: Tuesday, January 9, 2024 6:50 AM > To: Lsr > Subject: [Lsr] Working Group Last Call for "Applicability of IS-IS > Multi-Topology > (MT) for Segment Routing based Network Resource Partition (NRP)" - > draft-ietf-lsr-isis-sr-vtn-mt-06 > > This begins a two week LSR Working Group last call for the “Applicability of > IS-IS > Multi-Topology (MT) for Segment Routing based Network Resource Partition > (NRP)”. Please express your support or objection prior to Tuesday, January > 23rd, > 2024. > > Thanks, > Acee > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [spring] Shepherd's Review of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Hi Acee, Many thanks for your review and suggestions. I agree with them and will update the draft accordingly. Please see some further replies inline [Chongfeng]: From: spring On Behalf Of Acee Lindem Sent: Saturday, January 20, 2024 2:42 AM To: Lsr ; t...@ietf.org; spr...@ietf.org Subject: [spring] Shepherd's Review of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Speaking as WG Member and Document Shepherd: I have reviewed the document and have three comments. 1. The document can go forward implying that draft-dong-lsr-sr-enhanced-vpn-10 is the accepted solution for supporting higher scale of NRPs. While the reference is informative, the text implies this. I’d remove the reference altogether and this is reflected in my comments. [Chongfeng]: This is OK, we will follow this change in next revision. 2. To support NRPs in IS-IS, three pieces are required - IS-IS SR (MPLS and SRv6), IS-IS Multi-topology, and the SR resource-aware segment. The latter is not being progressed in SPRING yet. If it is not accepted, the draft will be stranded on awaiting publication. I’ve added the SPRING WG to the to list. [Chongfeng] Understood. Resource-aware segments is a WG document and IMO it has been stable for a while, hopefully it will progress quickly in SPRING. 3. There is design principle phrasing in draft-ietf-teas-nrp-scalability-03 which discourage the usage of “any” IGP-based solution (as Les commented). If you read the entire document, this is not the case and I’d suggest these principles be qualified to match the intent. Since there are common authors on both documents, I’d hope this could be accomplished. [Chongfeng] I will leave this to the co-author of the nrp-scalability draft to comment, personally I agree with your reading of that document. See the attached diff for editorial comments and addressing #1. [Chongfeng] Thanks a lot for providing the diff. Speaking as LSR WG Co-chair: Of these comments, #1 is easy to remedy and #3 is on the other TEAS document. IMO, #2 remains the only potential blocker to moving forward with publication. I’d solicit others opinions on this point. While draft-ietf-spring-resource-aware-segments-08 simply defines the semantics for resource-aware segments, it is not certain that it will go forward and it seems to be critical to draft-ietf-lsr-isis-sr-vtn-mt. [Chongfeng] Understood. It would be efficient if both documents could move forward in parallel. Thanks, Acee Best regards Chongfeng > On Jan 8, 2024, at 5:50 PM, Acee Lindem wrote: > > This begins a two week LSR Working Group last call for the “Applicability of > IS-IS Multi-Topology (MT) for Segment Routing based Network Resource > Partition (NRP)”. Please express your support or objection prior to Tuesday, > January 23rd, 2024. > > Thanks, > Acee ___ spring mailing list spr...@ietf.org https://www.ietf.org/mailman/listinfo/spring ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Hi Hent, Thank you for your comments. I would like to provide feedback based on the scenario and type of this document. The approach in this document is aimed at network scenarios where the required number of NRPs is not too high. As an operator, we believe such scenario would be typical for many deployment of NRP, so we propose it. It utilizes existing technology and information without the need for extensions to control protocols, which is its advantage, isn't it? In this scenario, the approach has no issue of not-scaling, nor is half-baked. As an operator, we think this approach is practical and effective. Based on this consideration, the type of this document is informative. You mentioned that TEAS may come up with some new solutions for larger scale NRPs, but this attempt requires new protocol extensions and some time in terms of standards and deployment. Come back to the scenario above, the solution proposed in my draft already meet the practical requirements, so we should document this solution for those who need it. I hope my explanation can clarify your concerns. Thank you! Best regards Chongfeng From: Henk Smit Date: 2024-01-12 20:31 To: Chongfeng Xie; Les Ginsberg (ginsberg); jmh; Acee Lindem; TEAS WG; lsr Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 From the draft: === > The mechanism described in this document is considered useful for network > scenarios in which > the required number of NRP is small, as no control protocol extension is > required. For network > scenarios where the number of required NRP is large, more scalable solution > would be needed, > which may require further protocol extensions and enhancements. So the proposed draft is about a solution that doesn't scale (well). And then later, we might get another solution that does scale (better). Then we'll end up with two solutions for one problem. One bad solution, and one (hopefully) better solution. If that is the case, then I suggest we wait a bit, and see what else the TEAS workgroup comes up with. I rather have one good solution than two half-baked. Or even one good and one half-baked. Less is more. henk. On 01/11/2024 4:40 AM CET Chongfeng Xie wrote: Hi Les, Thanks for your comments. This is an informational document which describes the applicability of existing IS-IS MT mechanisms for building SR based NRPs. All the normative references are either RFCs or stable WG documents. It is true that some informative references are individual documents, while they just provide additional information related to this topic, thus would not impact the stability and maturity of the proposed mechanism. The text you quoted from draft-ietf-teas-nrp-scalability are about the considerations when the number of NRP increases, how to minimize the impact to the routing protocols (e.g. IGP). While as described in the scalability considerations section of this document, the benefit and limitation of using this mechanism for NRP are analyzed, and it also sets the target scenarios of this mechanism: “The mechanism described in this document is considered useful for network scenarios in which the required number of NRP is small” Thus it is clear that this solution is not recommended for network scenarios where the number of required NRP is large. Please note section 3 of draft-ietf-teas-nrp-scalability also mentioned that: “The result of this is that different operators can choose to deploy things at different scales.” And “In particular, we should be open to the use of approaches that do not require control plane extensions and that can be applied to deployments with limited scope.” According to the above text, we believe the mechanism described in this document complies to the design principles discussed in draft-ietf-teas-nrp-scalability and provides a valid solution for building NRPs in a limited scope. Hope this solves your concerns about the maturity and scalability of this mechanism. Best regards, Chongfeng From: Les Ginsberg \(ginsberg\) Date: 2024-01-11 08:21 To: Joel Halpern; Acee Lindem; t...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 (NOTE: I am replying to Joel’s post rather than the original last call email because I share some of Joel’s concerns – though my opinion on the merits of the draft is very different. Also, I want to be sure the TEAS WG gets to see this email.) I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt. It is certainly true, as Joel points out, that this draft refer
Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Hi Les, Thanks for your comments. This is an informational document which describes the applicability of existing IS-IS MT mechanisms for building SR based NRPs. All the normative references are either RFCs or stable WG documents. It is true that some informative references are individual documents, while they just provide additional information related to this topic, thus would not impact the stability and maturity of the proposed mechanism. The text you quoted from draft-ietf-teas-nrp-scalability are about the considerations when the number of NRP increases, how to minimize the impact to the routing protocols (e.g. IGP). While as described in the scalability considerations section of this document, the benefit and limitation of using this mechanism for NRP are analyzed, and it also sets the target scenarios of this mechanism: “The mechanism described in this document is considered useful for network scenarios in which the required number of NRP is small” Thus it is clear that this solution is not recommended for network scenarios where the number of required NRP is large. Please note section 3 of draft-ietf-teas-nrp-scalability also mentioned that: “The result of this is that different operators can choose to deploy things at different scales.” And “In particular, we should be open to the use of approaches that do not require control plane extensions and that can be applied to deployments with limited scope.” According to the above text, we believe the mechanism described in this document complies to the design principles discussed in draft-ietf-teas-nrp-scalability and provides a valid solution for building NRPs in a limited scope. Hope this solves your concerns about the maturity and scalability of this mechanism. Best regards, Chongfeng From: Les Ginsberg \(ginsberg\) Date: 2024-01-11 08:21 To: Joel Halpern; Acee Lindem; t...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 (NOTE: I am replying to Joel’s post rather than the original last call email because I share some of Joel’s concerns – though my opinion on the merits of the draft is very different. Also, I want to be sure the TEAS WG gets to see this email.) I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt. It is certainly true, as Joel points out, that this draft references many drafts which are not yet RFCs – and in some cases are not even WG documents. Therefore, it is definitely premature to last call this draft. I also want to point out that the direction TEAS WG has moved to recommends that routing protocols NOT be used as a means of supporting NRP. https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl states: “…it is desirable for NRPs to have no more than small impact (zero being preferred) on the IGP information that is propagated today, and to not required additional SPF computations beyond those that are already required.” https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl states: “The routing protocols (IGP or BGP) do not need to be involved in any of these points, and it is important to isolate them from these aspects in order that there is no impact on scaling or stability.” Another draft which is referenced is https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ - which is not a WG document and – based on the recommendations in draft-ietf-teas-nrp-scalability – I would argue that the IGPs should NOT be extended as proposed in this draft. So if a WG adoption call were to initiated for draft-dong-lsr-sr-enhanced-vpn, I would oppose it. This then puts draft-ietf-lsr-isis-sr-vtn-mt in the position of publishing information about a solution which the IETF is discouraging. I do not know why the IETF would want to do this. If, despite all of the above, at some point it is judged not premature to publish this draft, I think the draft should at least include statements indicating that this approach is not a recommended deployment solution. Les From: Lsr On Behalf Of Joel Halpern Sent: Wednesday, January 10, 2024 3:22 PM To: Acee Lindem ; t...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Given that the documents that provide the basic definitions needed for this are still active Internet Drafts, it seems premature to last call this document. As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, which defines the terms needed to understand this draft, is an Informative reference. Yours, Joel PS: I considered not writing this email, as it seems
Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Hi Joel, Thanks for your comments. It is good to know you also think using MT to support NRP is a good idea. Regarding the timing of the last call, the enhanced VPN framework draft has finished the WG LC in TEAS WG, and this document has been stable for quite a while, thus it seems now is the right time to last call this document in LSR WG. As for the reference to draft-ietf-teas-ietf-network-slices, I agree after the terminology alignment it is better to be listed as normative reference. We can make this change in next revision. Best regards, Chongfeng From: Joel Halpern Date: 2024-01-11 07:22 To: Acee Lindem; teas; lsr Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Given that the documents that provide the basic definitions needed for this are still active Internet Drafts, it seems premature to last call this document. As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, which defines the terms needed to understand this draft, is an Informative reference. Yours, Joel PS: I considered not writing this email, as it seems quite reasonable to use MT to support what I expect NRPs to be. So in principle I think the document is a good idea. On 1/10/2024 6:12 PM, Acee Lindem wrote: Note that we are last calling this informational document relating to IS-IS deployment of NRPs using multi-topology. If you have comments, please send them to the LSR list. Thanks, Acee Begin forwarded message: From: Acee Lindem Subject: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Date: January 8, 2024 at 5:50:21 PM EST To: Lsr This begins a two week LSR Working Group last call for the “Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)”. Please express your support or objection prior to Tuesday, January 23rd, 2024. Thanks, Acee ___ Teas mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/teas ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IPR Poll for WG Last Call of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)"
Hi folks, As a co-author, Hi folks, I am unaware of any IPR to this draft. Best regards Chongfeng From: Acee Lindem Date: 2024-01-09 06:43 To: draft-ietf-lsr-isis-sr-vtn-mt CC: Lsr Subject: [Lsr] IPR Poll for WG Last Call of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" Co-Authors, Are you aware of any IPR that applies to draft-ietf-lsr-isis-sr-vtn-mt-06. If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the LSR WG mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the LSR WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not been disclosed in conformance with IETF rules. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-isis-sr-vtn-mt-06.txt
Hi folks， We have submitted a new version of draft-ietf-lsr-isis-sr-vtn-mt, this update resolves the RTG-DIR review comments from Deniele and Jia: 1.The terminology is aligned with those in TEAS WG 2. Further explanation about the target scenario of this solution. 3. All nits are fixed. With this, we believe all the comments received on this document have resolved, and this version is ready for WG LC. Best regards Chongfeng Xie From: internet-dra...@ietf.org Date: 2023-12-29 19:15 To: i-d-annou...@ietf.org CC: lsr@ietf.org Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-sr-vtn-mt-06.txt Internet-Draft draft-ietf-lsr-isis-sr-vtn-mt-06.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP) Authors: Chongfeng Xie Chenhao Ma Jie Dong Zhenbin Li Name:draft-ietf-lsr-isis-sr-vtn-mt-06.txt Pages: 9 Dates: 2023-12-29 Abstract: Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to build the SR based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-sr-vtn-mt/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-sr-vtn-mt-06 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-sr-vtn-mt-06 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
Hi Jia, Thanks for the review comments. I see your major comment is about the terminology alignment, as replied to Daniele, we will follow the decision in TEAS to update the terminologies in next revision. Please see some replies to the minor issues inline: From: He Jia via Datatracker Date: 2023-12-11 16:09 To: rtg-...@ietf.org CC: draft-ietf-lsr-isis-sr-vtn-mt.all; last-call; lsr Subject: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05 Reviewer: He Jia Review result: Not Ready Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-lsr-isis-sr-vtn-mt-05 Reviewer: Jia He Review Date: December 10, 2023 IETF LC End Date: date-if-known Intended Status: Informational Summary: I have read the review comments from Daniele about the concept of enhanced VPN, and the relationship with other existing terms. I agree with his suggestion to follow the discussion and align the draft with the output. In addition, some minor issues and also nits are found out as follows and should be considered prior to publication. Minor Issues: 1、In Section 1, it is said "Segment Identifiers (SIDs) can be used to represent both the topological instructions and the set of network resources allocated by network nodes to a VTN." Is it "allocated by network nodes" or "allocated to network nodes"? If it is "network resources allocated by network nodes", why not "allocated by centralized controllers" as well? If it is "network resources allocated to network nodes" which are assocated with a VTN, why not " allocated to network links" as well? Is there any special consideration by saying "network nodes" only here? [Chongfeng]： The description is a little bit confusing, actually it should be "network resources of the network nodes and links which are allocated to a VTN/NRP". We will update it in next revision. 2、In Section 4, "For SRv6 data plane, the SRv6 SIDs associated with the same VTN can be used together to build SRv6 paths with the topological and resource constraints of the VTN taken into consideration." Is "SRv6 Locator" missing? [Chongfeng] SRv6 Locator is the covering prefix part of the SRv6 SIDs. In SRv6 segment list, the SRv6 SIDs are used to indicate the forwarding path and the set of resources used for packet processing. So the description is correct. Nits: 1、Section 2, TLV 223 (MT IS Neighbor Attribute) is defined in RFC 5311, which is not referenced in the draft. 2、Section 1, Paragraph 3, last sentence, s/...need to be distributed using control plane/...need to be distributed using a control plane 3、Section 2, Paragraph 1, last sentecne, s/MT-ID could be used as the identifier of VTN in control plane./MT-ID could be used as the identifier of VTN in the control plane. 4、Section 2, "IS-IS Multi-Topology [RFC5120]" and "IS-IS Multi-Topology Routing (MTR) [RFC5120]" are both used in the draft. It is suggested to keep consistent throughout the draft. [Chongfeng] Thanks for catching the nits, we will resolve them in next revision. Best regards, Chongfeng ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
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-...@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 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:nore...@ietf.org] Sent: Friday, November 24, 2023 10:21 PM To: rtg-...@ietf.org Cc: draft-ietf-lsr-isis-sr-vtn-mt@ietf.org; last-c...@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
Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
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:nore...@ietf.org] Sent: Friday, November 24, 2023 10:21 PM To: rtg-...@ietf.org Cc: draft-ietf-lsr-isis-sr-vtn-mt@ietf.org; last-c...@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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi， all I have read the draf and support its adoption. Chongfeng > 2022年1月4日 下午2:58，Christian Hopps 写道： > > Hi Folks, > > This begins a 2 week WG Adoption Call for the following draft: > > https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/ > > Please indicate your support or objections by January 18th, 2022. > > Authors, please respond to the list indicating whether you are aware of any > IPR that applies to these drafts. > > Thanks, > Chris. > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
Hi，all， I support the adoption of these 2 drafts. Chongfeng > > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps > Sent: Thursday, July 22, 2021 6:48 PM > To: lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org > Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts > > > Hi Folks, > > This begins a 3 week WG Adoption Call for the following related YANG drafts: > > https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ > https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ > > Please indicate your support or objections by August 12th, 2021 > > Authors, please respond to the list indicating whether you are aware of any > IPR that applies to these drafts. > > Thanks, > Chris. > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Hi, Acee, Thank you for your comments. I agree with your consideration about using mature and deployed control plane technologies, and this document does not introduce any new IS-IS encodings. While the resource-aware segments has the same format as the legacy SR segments, the difference is in the semantics. Thus the same control plane mechanism in this draft could be used with either the legacy SR SIDs or the resource-aware SIDs. Using it with legacy SR SIDs could also help to compute SR paths in a VTN taking its topology and resources as constraints. When used with the resource-aware SIDs, it can further provide VTNs with guaranteed resources. We could add some text about this to the draft if you think this is helpful. Best regards Chongfeng 发件人： Acee Lindem \(acee\) 发送时间： 2021-03-30 03:32 收件人： Chongfeng Xie; Dongjie (Jimmy); Acee Lindem (acee); lsr@ietf.org 主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi Chongfeng, Given that the main argument for using MT to realize VTNs in the control plane is that it is a mature and deployed technology, requiring resource-aware segments, a new and evolving technology, defeats the purpose. Thanks, Acee From: Chongfeng Xie Date: Monday, March 29, 2021 at 8:58 AM To: Acee Lindem , "chongfeng.xie" , Jie Dong , "Acee Lindem (acee)" , "lsr@ietf.org" Subject: Re: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi, Acee, Thanks for your comments. This document can be used with resource-aware segments to provide VTNs with guaranteed resources, while I agree it may also be used with legacy SR technologies. This could be clarified in next version. Regards Chongfeng 发件人： Acee Lindem (acee) 发送时间： 2021-03-27 18:31 收件人： Chongfeng Xie; Dongjie (Jimmy); Acee Lindem (acee); lsr@ietf.org 主题： Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Speaking as WG member: Hi Chongfeng, Another thing, if one is trying to support a VTN with legacy technologies, it would be good to decouple it from the SR resource-aware segments. Thanks, Acee From: Chongfeng Xie Date: Friday, March 26, 2021 at 11:15 PM To: Acee Lindem , Jie Dong , "chongfeng.xie" , "Acee Lindem (acee)" , "lsr@ietf.org" Subject: Re: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi, Acee, Thanks for your understanding about the deployment considerations and the value of reusing existing technologies when possible. We have submitted the draft as draft-ietf-lsr-isis-sr-vtn-mt-00 with only the change in the title and date. And we will expand section 5 and add references to relevant TEAS documents in next revision. Chongfeng 发件人： Acee Lindem (acee) 发送时间： 2021-03-26 23:30 收件人： Dongjie (Jimmy); Chongfeng Xie; Acee Lindem (acee); lsr@ietf.org 主题： Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi Jie, Chongfeng, I’ve read draft-ietf-teas-enhanced-vpn and I agree that the combination of MT and SR could be used to meet a given SLO. Given that I work with products and customers, I also know there can be a significant time lag for qualification and deployment of a software version. In lieu of resource-aware segments, you could even use an existing technology like VLANs with appropriate QoS guarantees. Hence, I can see the value of using existing technologies. Please go ahead and republish draft-xie-lsr-sr-vtn-mt as draft-ietf-lsr-sr-vtn-mt-00.txt. Section 5 can be expanded in subsequent revisions with appropriate references to TEAS documents. Thanks, Acee From: Lsr on behalf of Jie Dong Date: Friday, March 26, 2021 at 10:39 AM To: Chongfeng Xie , "Acee Lindem (acee)" , "lsr@ietf.org" Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi Acee, I agree with what Chongfeng said about VTN. It refers to a virtual underlay network with specific topology and resource attributes, and the topology of VTNs can be specified using multi-topology. It is important to understand the difference between a VTN and a logical network topology. As for the deployment choice and scalability, draft-dong-teas-enhanced-vpn-vtn-scalability gives some detailed analysis. In summary, it says in different network scenarios and phases, the required number of VTNs could be different, thus several options may be provided to meet different requirements, with dif
Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Hi, Acee, Thanks for your comments. This document can be used with resource-aware segments to provide VTNs with guaranteed resources, while I agree it may also be used with legacy SR technologies. This could be clarified in next version. Regards Chongfeng 发件人： Acee Lindem (acee) 发送时间： 2021-03-27 18:31 收件人： Chongfeng Xie; Dongjie (Jimmy); Acee Lindem (acee); lsr@ietf.org 主题： Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Speaking as WG member: Hi Chongfeng, Another thing, if one is trying to support a VTN with legacy technologies, it would be good to decouple it from the SR resource-aware segments. Thanks, Acee From: Chongfeng Xie Date: Friday, March 26, 2021 at 11:15 PM To: Acee Lindem , Jie Dong , "chongfeng.xie" , "Acee Lindem (acee)" , "lsr@ietf.org" Subject: Re: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi, Acee, Thanks for your understanding about the deployment considerations and the value of reusing existing technologies when possible. We have submitted the draft as draft-ietf-lsr-isis-sr-vtn-mt-00 with only the change in the title and date. And we will expand section 5 and add references to relevant TEAS documents in next revision. Chongfeng 发件人： Acee Lindem (acee) 发送时间： 2021-03-26 23:30 收件人： Dongjie (Jimmy); Chongfeng Xie; Acee Lindem (acee); lsr@ietf.org 主题： Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi Jie, Chongfeng, I’ve read draft-ietf-teas-enhanced-vpn and I agree that the combination of MT and SR could be used to meet a given SLO. Given that I work with products and customers, I also know there can be a significant time lag for qualification and deployment of a software version. In lieu of resource-aware segments, you could even use an existing technology like VLANs with appropriate QoS guarantees. Hence, I can see the value of using existing technologies. Please go ahead and republish draft-xie-lsr-sr-vtn-mt as draft-ietf-lsr-sr-vtn-mt-00.txt. Section 5 can be expanded in subsequent revisions with appropriate references to TEAS documents. Thanks, Acee From: Lsr on behalf of Jie Dong Date: Friday, March 26, 2021 at 10:39 AM To: Chongfeng Xie , "Acee Lindem (acee)" , "lsr@ietf.org" Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi Acee, I agree with what Chongfeng said about VTN. It refers to a virtual underlay network with specific topology and resource attributes, and the topology of VTNs can be specified using multi-topology. It is important to understand the difference between a VTN and a logical network topology. As for the deployment choice and scalability, draft-dong-teas-enhanced-vpn-vtn-scalability gives some detailed analysis. In summary, it says in different network scenarios and phases, the required number of VTNs could be different, thus several options may be provided to meet different requirements, with different cost and time to market. Best regards, Jie From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie Sent: Friday, March 26, 2021 2:14 PM To: Acee Lindem (acee) ; lsr@ietf.org Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi，Acee， Regarding to the issues put forward in your mail, I'd like to provide some comments as below, Q1：I’d like to know of the WG members who supported it, would you really want to market it as a VTN solution? [CF]：VTN is defined in draft-ietf-teas-enhanced-vpn, and also used in other documents. It is a technical term to refer to virtual underlay networks with specific topology and resource attributes. This document provides an MT based mechanism to build VTNs. If for marketing, perhaps it would be better called "network slicing":-) Q2：Those of you who operate networks, would you actually consider deploying it? [CF]：As an operator we will consider the scenarios and the requirements to pick the most suitable solution, IMO this is a good candidate for scenarios where the required number of VTN is not very large, and as it requires no new encodings, it could be ready for shipment soon. we plans to use this approach in some of our network deployment. Q3：In any case, section 5 needs to be expanded on the scalability and where using MTs to support VTNs would make sense and where it wouldn’t. [CF]：OK. The current section 5 already has some text to cover this, and it can be expanded further to clarify. Best regards Chongfeng
Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Hi, Acee, Thanks for your understanding about the deployment considerations and the value of reusing existing technologies when possible. We have submitted the draft as draft-ietf-lsr-isis-sr-vtn-mt-00 with only the change in the title and date. And we will expand section 5 and add references to relevant TEAS documents in next revision. Chongfeng 发件人： Acee Lindem (acee) 发送时间： 2021-03-26 23:30 收件人： Dongjie (Jimmy); Chongfeng Xie; Acee Lindem (acee); lsr@ietf.org 主题： Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi Jie, Chongfeng, I’ve read draft-ietf-teas-enhanced-vpn and I agree that the combination of MT and SR could be used to meet a given SLO. Given that I work with products and customers, I also know there can be a significant time lag for qualification and deployment of a software version. In lieu of resource-aware segments, you could even use an existing technology like VLANs with appropriate QoS guarantees. Hence, I can see the value of using existing technologies. Please go ahead and republish draft-xie-lsr-sr-vtn-mt as draft-ietf-lsr-sr-vtn-mt-00.txt. Section 5 can be expanded in subsequent revisions with appropriate references to TEAS documents. Thanks, Acee From: Lsr on behalf of Jie Dong Date: Friday, March 26, 2021 at 10:39 AM To: Chongfeng Xie , "Acee Lindem (acee)" , "lsr@ietf.org" Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi Acee, I agree with what Chongfeng said about VTN. It refers to a virtual underlay network with specific topology and resource attributes, and the topology of VTNs can be specified using multi-topology. It is important to understand the difference between a VTN and a logical network topology. As for the deployment choice and scalability, draft-dong-teas-enhanced-vpn-vtn-scalability gives some detailed analysis. In summary, it says in different network scenarios and phases, the required number of VTNs could be different, thus several options may be provided to meet different requirements, with different cost and time to market. Best regards, Jie From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie Sent: Friday, March 26, 2021 2:14 PM To: Acee Lindem (acee) ; lsr@ietf.org Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi，Acee， Regarding to the issues put forward in your mail, I'd like to provide some comments as below, Q1：I’d like to know of the WG members who supported it, would you really want to market it as a VTN solution? [CF]：VTN is defined in draft-ietf-teas-enhanced-vpn, and also used in other documents. It is a technical term to refer to virtual underlay networks with specific topology and resource attributes. This document provides an MT based mechanism to build VTNs. If for marketing, perhaps it would be better called "network slicing":-) Q2：Those of you who operate networks, would you actually consider deploying it? [CF]：As an operator we will consider the scenarios and the requirements to pick the most suitable solution, IMO this is a good candidate for scenarios where the required number of VTN is not very large, and as it requires no new encodings, it could be ready for shipment soon. we plans to use this approach in some of our network deployment. Q3：In any case, section 5 needs to be expanded on the scalability and where using MTs to support VTNs would make sense and where it wouldn’t. [CF]：OK. The current section 5 already has some text to cover this, and it can be expanded further to clarify. Best regards Chongfeng 发件人： Acee Lindem \(acee\) 发送时间： 2021-03-26 02:20 收件人： lsr@ietf.org 主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Speaking as WG chair: There has been considerable support for this document. However, there has also been objections to the document. The objections are either that there is nothing to standardize given that all pieces exist and that the MT isn’t a viable option for VTNs since it isn’t scalable. Since most of the draft’s support is from “friends and family”, I’d like to know of the WG members who supported it, would you really want to market it as a VTN solution? Those of you who operate networks, would you actually consider deploying it? In any case, section 5 needs to be expanded on the scalability and where using MTs to support VTNs would make sense and where it wouldn’t. Thanks, Acee From: Lsr on behalf of "Acee Lindem (acee)" Date: Tuesday, March 2, 2021 at 6:28 PM To: "lsr@ietf.org" Subject: [Lsr] WG
Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Hi，Acee， Regarding to the issues put forward in your mail, I'd like to provide some comments as below, Q1：I’d like to know of the WG members who supported it, would you really want to market it as a VTN solution? [CF]：VTN is defined in draft-ietf-teas-enhanced-vpn, and also used in other documents. It is a technical term to refer to virtual underlay networks with specific topology and resource attributes. This document provides an MT based mechanism to build VTNs. If for marketing, perhaps it would be better called "network slicing":-) Q2：Those of you who operate networks, would you actually consider deploying it? [CF]：As an operator we will consider the scenarios and the requirements to pick the most suitable solution, IMO this is a good candidate for scenarios where the required number of VTN is not very large, and as it requires no new encodings, it could be ready for shipment soon. we plans to use this approach in some of our network deployment. Q3：In any case, section 5 needs to be expanded on the scalability and where using MTs to support VTNs would make sense and where it wouldn’t. [CF]：OK. The current section 5 already has some text to cover this, and it can be expanded further to clarify. Best regards Chongfeng 发件人： Acee Lindem \(acee\) 发送时间： 2021-03-26 02:20 收件人： lsr@ietf.org 主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Speaking as WG chair: There has been considerable support for this document. However, there has also been objections to the document. The objections are either that there is nothing to standardize given that all pieces exist and that the MT isn’t a viable option for VTNs since it isn’t scalable. Since most of the draft’s support is from “friends and family”, I’d like to know of the WG members who supported it, would you really want to market it as a VTN solution? Those of you who operate networks, would you actually consider deploying it? In any case, section 5 needs to be expanded on the scalability and where using MTs to support VTNs would make sense and where it wouldn’t. Thanks, Acee From: Lsr on behalf of "Acee Lindem (acee)" Date: Tuesday, March 2, 2021 at 6:28 PM To: "lsr@ietf.org" Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 This information draft describes how MT could be used for VTN segmentation. The authors have asked for WG adoption. This begins a three week LSR Working Group Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next week. Please register your support or objection on this list prior to the end of the adoption poll on 3/24/2020. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Hi， Les, Thanks for the review of this document. As the current document type is informational, it does not introduce new TLV to IS-IS. While it describes the mechanisms of using existing TLVs to distribute the information of SR based VTNs, which can have customized topology and a set of dedicated network resources. It also describes the forwarding behaviors based on the SIDs and the resources allocated to each VTN. IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple logical topologies and perform independent path computation for each topology. RFC 5120 mentions that the TE attributes TLVs can be inherited by the MT TLVs “if traffic engineering or some other applications are being applied per topology level later”. While it does not specify what the topology-specific TE attributes mean, and how traffic in different topologies are forwarded on a shared outgoing interface. These are described in section 3 and section 4 of this document. RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs and Locators are not specified, especially when the SIDs are associated with different set of network resources. Section 5 gives the analysis about the scalability of this mechanism, and talks about a case where two VTNs have the same logical topology, but with different set of resources. IMO the value of this document is that it provides an option to build SR VTNs with no IS-IS protocol extensions, which could be useful for some network scenarios. Best regards, Chongfeng chongfeng@foxmail.com 发件人： Les Ginsberg \(ginsberg\) 发送时间： 2021-03-04 11:52 收件人： Acee Lindem (acee); lsr@ietf.org 主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 I oppose WG adoption for this draft. I note that the authors – following significant comments received on V0 - have removed much of the material that was considered confusing and/or inappropriate – notably discussion of L2 bundle link members. I also note the draft has moved from Standards track to Informational track. Let’s consider what content remains (ignoring boilerplate sections): Section 2 notes that MT TLVs (RFC 5120) can support: o Topology specific SR-MPLS SIDs (defined in RFC 8667) o Topology specific SRv6 Locators and SIDs (defined in draft-ietf-lsr-isis-srv6-extensions) Section 3 notes that MT TLVs can also support link attribute advertisements (defined in RFC 5305 and RFC 8570) Also note that the IANA registries: https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 and https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237 also clearly document what is discussed in Sections 2 and 3. Section 4 notes that topology specific forwarding entries can be installed in the forwarding plane based on topology specific routing calculations – something which was discussed in RFC 5120. Section 5 notes that two different MTIDs could operate on the same physical topology - something clearly discussed in RFC 5120. All of this adds nothing new to our understanding of the protocol. The only “new” content is the statement that VTNs could map to MTIDs. But the substance of VTN and how it might be used is better discussed in a number of other drafts including: draft-ietf-spring-sr-for-enhanced-vpn draft-ietf-teas-enhanced-vpn draft-dong-lsr-sr-enhanced-vpn The last draft is most notable because it proposes new IGP protocol encodings in support of VTN. Whether the encodings in that draft are accepted as currently defined or evolve to something different – it would be the authoritative draft on VTN IGP extensions. The end result is that there is no meaningful content in draft-xie-lsr-isis-sr-vtn-mt. What it states is either already stated in existing RFCs or will be stated authoritatively in whatever draft-dong-lsr-sr-enhanced-vpn evolves to (if indeed this work on VTNs is adopted by the WG). Let’s please not waste WG time on this draft. Les From: Lsr On Behalf Of Acee Lindem (acee) Sent: Tuesday, March 02, 2021 3:28 PM To: lsr@ietf.org Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 This information draft describes how MT could be used for VTN segmentation. The authors have asked for WG adoption. This begins a three week LSR Working Group Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next week. Please register your support or objection on this list prior to the end of the adoption poll on
Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Hi, Qin, Thanks a lot for your support. Please see some replies inline: Chongfeng chongfeng@foxmail.com 发件人： Qin Wu 发送时间： 2021-03-03 14:50 收件人： Acee Lindem (acee); lsr@ietf.org 主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 Hi, I have read this draft and It is well written and I support adoption of this work. Here are a few comments and suggestions: 1. What is VTN resource, how do we define network resource, is the resource a. the label that is switched on the path of the LSP, b. is the resource physical resource assigned to LSP?c. Is the resource a measure of the capacity of a link that is dedicated for use by the traffic on the LSP.d. Is the resource referred to node or link in the network topology?Would it be great to provide VTN resource definition in the terminology section,[Chongfeng] The resource in this context is the forwarding resources (e.g. bandwidth and the associated buffer/queuing and scheduling resources). For detailed description about the resources allocated to VTN, please refer to draft-ietf-spring-resource-aware-segments and draft-ietf-spring-sr-for-enhanced-vpn. In addition, I also recommend you to reference RFC8413 for resource definition. [Chongfeng] Thanks for the pointer, we will take a look at it.2. Section 2 said:“The MT-specific Link or Prefix TLVs are defined by adding additional two bytes, which includes 12-bit MT-ID field in front of the ISN TLV and IP or IPv6 Reachability TLVs.” Does this require protocol extension? Are these two bytes reserved fields? Where MT-ID is defined? In which RFC? Also ISN TLV, IP/Ipv6 Reachablity TLV, where these TLVS are defined? Please provide references. [Chongfeng] As this is an informational draft, there is no new TLV defined. The MT-ID based TLVs are defined in RFC 5120. The ISN TLV and the IP Reachablity TLV is defined in RFC 5305, are the IPv6 Reachablity is defined in RFC 5308. We could add some references and pointers to make it clearer. -Qin Wu 发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee) 发送时间: 2021年3月3日 7:28 收件人: lsr@ietf.org 主题: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 This information draft describes how MT could be used for VTN segmentation. The authors have asked for WG adoption. This begins a three week LSR Working Group Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next week. Please register your support or objection on this list prior to the end of the adoption poll on 3/24/2020. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IPR Poll for "Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network" - draft-xie-lsr-isis-sr-vtn-mt-03
Hi, folks, I'm not aware of any IPR associated with this document. Thanks! Chongfeng Xie From: Acee Lindem \(acee\) Date: 2021-03-03 07:35 To: draft-xie-lsr-isis-sr-vrn...@ietf.org CC: lsr@ietf.org Subject: [Lsr] IPR Poll for "Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network" - draft-xie-lsr-isis-sr-vtn-mt-03 Authors, Are you aware of any other IPR that applies to draft-xie-lsr-issi-sr-vtn-mt? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the LSR WG mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the LSR WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Note that no IPRs have been declared - https://datatracker.ietf.org/ipr/search/?submit=draft=draft-xie-lsr-isis-sr-vtn-mt Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
