[spring] A review of draft-ietf-spring-sr-for-enhanced-vpn-01
Adrian Farrel <adrian@olddog.co.uk> Sat, 15 January 2022 18:15 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948633A07AE; Sat, 15 Jan 2022 10:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysNcmq2tIOGa; Sat, 15 Jan 2022 10:15:41 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 5C9DA3A07A7; Sat, 15 Jan 2022 10:15:36 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 20FIFXnc023140; Sat, 15 Jan 2022 18:15:33 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EF5E94604F; Sat, 15 Jan 2022 18:15:32 +0000 (GMT)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E35164604D; Sat, 15 Jan 2022 18:15:32 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS; Sat, 15 Jan 2022 18:15:32 +0000 (GMT)
Received: from LAPTOPK7AS653V ([85.255.233.123]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 20FIFVWl001320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Jan 2022 18:15:32 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-ietf-spring-sr-for-enhanced-vpn@ietf.org
Cc: spring@ietf.org
Date: Sat, 15 Jan 2022 18:15:30 -0000
Organization: Old Dog Consulting
Message-ID: <06a001d80a3b$e1fa38d0$a5eeaa70$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdgKO3a4+ueVtZxEQAexHZexsLc3iw==
Content-Language: en-gb
X-Originating-IP: 85.255.233.123
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26656.002
X-TM-AS-Result: No-0.657-10.0-31-10
X-imss-scan-details: No-0.657-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26656.002
X-TMASE-Result: 10-0.657500-10.000000
X-TMASE-MatchedRID: R5cdTmiG0o8/9d9Rtcc0QzjNGpWCIvfTqb3/o5s+OcMHWPn2mj7oRN8U r8Hk1+7a7hJbQ3pAbgaV1/iPj7Iy00legzLj1vIWNOnZ6jz9oVtBmlBF/IJ0fAd2elVmK++c3oG eBw3XOVWbyKWXBgEA4HMyio8/2B1+AM0/G7XUdeNcrmR4Jr5uaAEoHzC4m9uQ3unRG7yMq8V6ll TJDoR4NbYHv3Kw6s49l5ukUxTLW19p0Nopn/8qrTA2Ejh8jKICDvc/j9oMIgXSrtxzDP2xm0fl+ H4+MqTJOBe3XpveKA2RtvxxSNJ73Z/JE/eOMuX3PE3khmVvHO717lqbebntfSYq0O5mGXOYz99N OQMbCs8GhhMMyHWKgVD4fyqUQ16zPFrxOr//W2JZLa7VkT00QL4X/8yfdrbDYUdWP7oX6sggAmL aXureW/QThr4atQHD4OGrT54epfpS0bd+i8J5ed5x7RpGJf1aIiTd2l7lf6H/64I/Z3Fs/Slcg6 zmOeBGJm+8ekE+O73PeYhxtHrwv2Iv/Cz20pJpJ0TU9RBbrDAOHw/yNOkRgey3wTqVVwoKEWHM6 yWcJIC/aXVGyObOnwD/B4zy9bUYqFzfBlbyBr4c9jA4mLo8uQ9AUR5Kh8c7EoJn5DrIHypTfVTR gF5agravLUkomRf9c/efRu6bt5oOunQLDaXUBOPEkNSS7Y825bMmdOYs/G8+n5lKDOavuauvFAA i8j/44gWKKozI0pGWNrS+2ymUOBS3XHz43NeO7LuOEAY9BqRgFto/VVnNJY728shq0PfIG/ef1o ISWpDOFizXgkVNd997X7i0lCj8zV5vC0iR7XieAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg/cUt5lc1lLgkU6UkIr/V+0fDJEoDuGx1n80k9oxQcUPgC9EaG6NtvKi/GYGUi/oDRM8n6xm hkM+7oo9/u4mWSJ+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/eGPP0XIfG-PvV6A7brTsB2OE4PU>
Subject: [spring] A review of draft-ietf-spring-sr-for-enhanced-vpn-01
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jan 2022 18:15:47 -0000
Hi, I've been on a roll reading and reviewing network slicing and enhanced VPN drafts, so I thought I'd get round to this one. A bit surprised to find it has expired - you probably want to post something to keep it alive. Seems most drafts I review these days I end up writing a comments that goes... Before this document gets published as an RFC you will need to cut down the names on the front page to 5 or fewer. It is usually easiest to do this early and in your own time rather than being forced to do it or having the document held up while you sort it out. Otherwise, this draft seems fairly much ready, and only blocked on the completion of the normative references (see note below). I wonder, however, whether some of the informative references are a little immature (early individual drafts) to serve as example/possible protocol solutions. Here are a few points for you to consider. Thanks, Adrian == Minor Points == I have some scaling concerns about the mechanism defined here. If you imagine running 1000 VTNs in the network, and if each link is advertising a SID, wouldn't you end up needing to advertise 1000 SIDs for each link? This is made clear in 2.1 For one IGP link, multiple Adj-SIDs are allocated, each of which is associated with a VTN that link participates in, and represents a subset of the link resources allocated to the VTN. For one IGP node, multiple prefix-SIDs are allocated, each of which is associated with a VTN which the node participates in, and identifies the set of network resources allocated to the VTN on network nodes which participate in the VTN. While section 2.4 makes a stab at identifying the scaling concerns, it seems to miss the main point that the IGP may be quite fragile as the number of VTNs increases. Note that similar issues came up in IGP-TE work. The solution there was to advertise just once for the link, but to list the TE attributes on the advertisement. I think you could do the same here so that a link would be a simple advertisement with a list of adjacency SIDs (resource aware SIDs) subtended. Of course, you have to handle the addition and removal of VTNs (or variations in the allocated bandwidth), but this seems easy enough to manage. Curiously, section 4 appears to make a positive thing of the fact that there are scalability concerns. Continuing to contrast SR per topology state with pre-SR topology per path state is beginning to look a little thin at this point since the link in the VNT is exactly the path in the pre-SR topology. You only difference at this stage is the signaling state, and control plane signaling is not a requirement in a non-SR system. Since (I think) you don't want to get distracted in this work into a re-initiation of the arguments about SR or no SR, I suggest that you should be more careful with the wording in the third bullet of section 4. (The final sentence of section 4 contrasting the resource aggregation in this case with that in RSVP-TE and claiming that resource allocation is easier and more flexible that with RSVP-TE is really likely to cause a fight. It is simply unnecessary to say this in this document. Stop trying to make marketing statements in Internet-Drafts and just define the technology!) I think that the scaling concerns in the current draft merit a mention in Section 7 since the whole system may be destabilised by an attack (or accident) that causes a large number of VTNs to be configured. This can be mitigated by placing thresholds (for alarms or cut-off) in the configuration process. --- I think that I-D.ietf-spring-resource-aware-segments and I-D.ietf-teas-enhanced-vpn are used in a way that makes them normative references. == Nits == Throughout s/(e.g./(e.g.,/ --- Abstract s/which has/which have/ --- 1. Just to future-proof yourself... s/proposes to extend SR/extends SR/ --- 1. s/which has customized/which have customized/ --- 3. The detailed control plane mechanisms and possible extensions are described in separate documents and are out of the scope of this document. Which separate documents? --- You have an upper case "SHOULD" in section 3.3. Since you don't have the BCP 14 boilerplate, I suspect you mean this to be lower case. --- OLD 3.5. VTN Visibility to Customer NEW 3.5. VTN Visibility to Customers END --- 3.5 s/requirement, VTN/requirement, VTNs/ --- OLD 4. Characteristics of SR based VTN NEW 4. Characteristics of SR based VTNs END --- In several places (and notably section 4) you say... The proposed mechanism... You need to be more assertive if this is to be an RFC (that is not Experimental). You are "describing" a mechanism not "proposing" it. --- 4. Each customer is only aware of the topology and attributes of his own VTN Please consider using the gender-neutral "their" in place of "his" --- 4. s/provides an practical/provides a practical/ --- OLD 5. Service Assurance of VTN NEW 5. Service Assurance for VTNs END --- 5. In order to provide assurance for services provisioned in the SR based VTNs, it is necessary to instrument the network at multiple levels, e.g. in both the underlay network level and the VTN level. The operator or the customer may also monitor and measure the performance of the services carried by the VTN. In principle these can be achieved using existing or in development techniques in IETF. The detailed mechanisms are out of the scope of this document. Assuming that VTNs without service assurance are undesirable, and reading "it is necessary to instrument", I think this paragraph rather fails to deliver... "You can probably use some mechanisms defined elsewhere or maybe being defined, but we are not going to tell you about them." Can you at least give some "such as" references? --- 5. s/degradation happens in/degradation in/
- [spring] A review of draft-ietf-spring-sr-for-enh… Adrian Farrel
- Re: [spring] A review of draft-ietf-spring-sr-for… Dongjie (Jimmy)