[Gen-art] Re: Gen-ART review of draft-ietf-tsvwg-vpn-signaled-preemption-01
Fred Baker <fred@cisco.com> Mon, 02 October 2006 18:56 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSyG-00082T-Br; Mon, 02 Oct 2006 14:56:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSyF-00082N-7k for gen-art@ietf.org; Mon, 02 Oct 2006 14:56:55 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUSyD-0001Ey-Jg for gen-art@ietf.org; Mon, 02 Oct 2006 14:56:55 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 02 Oct 2006 11:56:54 -0700
X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="344176754:sNHT73602948"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92IurQF018293; Mon, 2 Oct 2006 11:56:53 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k92Iuqql005017; Mon, 2 Oct 2006 11:56:52 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:56:52 -0700
Received: from [10.32.244.222] ([10.32.244.222]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:56:51 -0700
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40B182D5D@zcarhxm2.corp.nortel.com>
References: <713043CE8B8E1348AF3C546DBE02C1B40B182D5D@zcarhxm2.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <91325D43-C118-4E4C-8930-7CFAAC32A028@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Mon, 02 Oct 2006 11:56:50 -0700
To: Sharon Chisholm <schishol@nortel.com>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 02 Oct 2006 18:56:52.0090 (UTC) FILETIME=[85ABADA0:01C6E654]
DKIM-Signature: a=rsa-sha1; q=dns; l=9649; t=1159815413; x=1160679413; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20<fred@cisco.com> |Subject:Re=3A=20Gen-ART=20review=20of=20draft-ietf-tsvwg-vpn-signaled-preemption -01; X=v=3Dcisco.com=3B=20h=3D0VhT7zLKlbX1P9j3vaQ0ifbOgdQ=3D; b=uxX/rrcj6QjiBsx6m1m6brcv3siugi/waUGboZTbLMJ4SnvE/IIDvQZKw9+ltcTCb6bUqny5 mn+7A2MJazHtGEDYz7J/KyBcEQald/ozXRvZ8GsCvxSwomTTp34RVNo/;
Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
Cc: lars.eggert@netlab.nec.de, magnus.westerlund@ericsson.com, gen-art@ietf.org, jmpolk@cisco.com, pratik.bose@lmco.com
Subject: [Gen-art] Re: Gen-ART review of draft-ietf-tsvwg-vpn-signaled-preemption-01
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
I get the impression that you didn't like the document :-) On Oct 1, 2006, at 6:13 PM, Sharon Chisholm wrote: > As this was a -00 version of the document (then published a few > days ago with minor changes as -01) I was curious as to how much > review it received from the working group. I reviewed the mailing > list and only saw one reply to working group last call on the > document to make some minor updates. It might be worthwhile to > solicit the working group for further review. Note that this lived for a long time as an individual submission before being picked up as a working group item, and the individual submission was in fact discussed both on the working group list and face to face. The working group's specific comments on it were along the lines that some felt the IETF should no longer be working on the Integrated Services Architecture, while others felt that it should be worked on, and in general the ADs wanted to slow roll the thing to make time for NSIS to catch up with RSVP - a matter that the authors considered appealing. This has now sat in the IESG queue for the better part of a year without review, which may also be appealable. > I expect that once some of these scope and organization issues are > addressed, the document will be a bit easier to review to find more > specific problems. We're very willing to work with you on technical and editorial issues. We do hope to achieve closure within our lifetime. > 1. The document doesn't seem to agree on its purpose. In the > abstract it claims "Some networks require communication between an > interior and exterior portion of a VPN, but have sensitivities > about what information is communicated across the boundary. This > note seeks to outline the issues and the nature of the proposed > solutions." But later on the document claims "The key question this > document > explores is "how do reservations, and preemption of reservations, > work in such an environment?", where such an environment is nested > VPNs. The document does seem to talk about both and they seem > related, but still this needs to be clarified. OK, we'll see if can tighten language on the purpose of the document. Bottom line, it is about implementing the Integrated Services architecture as described in RFC 2998 across a type of VPN in which not only the connected enclaves don't share knowledge with the network they run over, but that network doesn't share knowledge with them. Examples might include a military network that runs over a commercial network (yes, that happens), or a civilian first responder call that is crossing a military network (yes, that happens). > 2. The abstract says 'This note seeks to outline the issues and the > nature of the proposed solutions.', it would be good to refer to > what the specific solution are. Given the substance of the document, what would you think the proposed solutions are? We thought that section 2 gave a pretty complete overview, description, and example. Specifically what are you looking for here? > 3. Section 1 is titled 'QoS in a VPN domain', but is actually a > mishmash of topics. It contains a reiteration of the purpose of the > document with respect to interior/exterior, tutorial on a number of > topics, and some clarification of term usage specific to this > document. The title of the section seems a bit off and ... Would it help if we renamed the section "Introduction"? It seems that the idnits tool complains that we don't follow the boilerplate in that regard. > ...the information within the section would be better organized > into the sections I mentioned or some other form to reduce the > feeling of 'here is some information' and 'here is some more > information' that this document has on occasion. Telling me that you want the organization different without telling me in what way isn't all that helpful. Specifically how would you suggest we organize the information to improve your comprehension of it? > 4. Figure 2 is barely a figure and doesn't really demonstrate > communication between the three entities listed. Yes. Something seems to have gotten lost there. > 5. In section 1.1, titled 'Nested VPNs', we get three quarters of > the way through, in the paragraph just before figure 3, before we > finally start talking about nesting VPNs. This comment really throws me. The text starts out with the sentence "One could describe such a network in terms of three network diagrams." We try to show a VPN and then show how VPNs can be nested, and comment that our requirements deal with both structures. In the ASCII version, this is a two pages of text, with the diagram that one wishes was on the second page on a third due to the editing tool. It seems that we're not being allowed to introduce the topic - and I guarantee that if we are not, the discussion of its solution won't make any sense either. > 6. Figure 5 is very ambitious for ASCII art and I don't find it > terribly readable. This figure is then referenced through very long > examples walking through its H5 and R4 type labels. I wonder if > this is a simpler way to convey the same information? It is indeed complex. It is a fairly complex problem. Now, I could if you like break it up the way I broke up section 1.1, which you complained about. We could discuss handling the problem of preemption in a VPN, and then separately discuss nesting the VPNs. Would that help? Would you then complain about that level of complexity? > 7. Is DSCP corollary a well-known term? I googled and didn't find > it used. I also didn't see it defined in the document. I think I meant "DSCP corollary to". The point is that the DSCP should correspond to the reservation and the data it should carry - either be the same DSCP, or use a value that maps to the DSCP, as discussed in the security considerations. If I change that to "corollary to", does that work for you? > 8. In section 2.1, second set of bullets it says "The Preemption > Priority of a tunnel reservation is identical to that of the > individual reservations it aggregates.", which implies that only > reservations of the same priority level can be put into an > association. Is that correct? Yes, that is correct. One could imagine aggregation of reservation precedences as well, but that is a separate discussion - the various precedences are in that case at the same numeric priority. > 9. In section 5, the fourth paragraph does not seem to be > discussing a security consideration. You're talking about this, right? VPN Routers encapsulate encrypted IP packets and prepend an extra header on each packet. These packets, whether used for signaling or data, should be identifiable, at a minimum by the IP addresses and DSCP value. The prepended header, therefore, should contain at a minimum the DSCP value corresponding to the signaled reservation in each packet. This may literally be the same DSCP as is used for the data (forcing control plane traffic to receive the same QoS treatment as its data), or a different DSCP that is routed identically (separating control and data plane traffic QoS but not routing). Specifically, this paragraph was requested by the people who specify the encryptors in question. They view the idea that the encryptor might allow the DSCP through to be a security vulnerability. Russ Housley might be in a position to advise us here. > 10. Section 3 claims that it 'details the data flows within a VPN > Router, in the context of sessions as described in Section 2.', > which isn't that helpful. If we mean some of the nested VPNs > discussed, we should clearly say this rather then using a cryptic > cross references. Again, this was requested by the folks who specify the encryptors in question. They want to be able to identify exactly what information crosses the boundary and what does not. I'm not sure whether you are saying that section 3 isn't helpful to you, or whether you are saying section 2 didn't help. Please say more. > Nits > ---- > > 1. In section 1, first sentence, it says 'guarantee secure > transmission of IP traffic for across public LANs or WANs'. Delete > the 'for' > > 2. Figure 1 is not readable because there is not sufficient space > between it and the preceding text. > > 3. Section 1.3, second paragraph says "Preemption of a reservation > is specified in the context, in [RFC3181]", which perhaps should > read 'this context'. > > 4. In section 2.1, first sentence it says 'A reservation in a nest > VPN'. I believe that should be 'nested'. > > 5. In section 2.1, just before the bullets it says 'If the VPN > Tunnel is an IPSec Security Association between the VPN Routers and > the IP packet is entirely contained within ', which doesn't really > parse. > > 6. In section 3.1.1., it says 'RESV Confirm: This indicates that a > RESV message received as data and forwarded into the enclave, > and is now being confirmed.', which doesn't parse. > > 7. Section 3.2.1 first paragraph talks about 'th cipher', which > should be 'the cipher'. > > 8. Section 5, second paragraph says "One of the reasons cited for > the nesting of VPN routes in Section 1.1 are the different levels > ", when that should be 'is the different levels'. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART LC review of draft-ietf-dhc-dhc… Gray, Eric
- [Gen-art] Re: Gen-ART LC review of draft-ietf-dhc… Jari Arkko
- [Gen-art] re: Gen-ART LC review of draft-ietf-dhc… CTO YAN Renxiang
- [Gen-art] Gen-ART review of draft-ietf-tsvwg-vpn-… Sharon Chisholm
- [Gen-art] Re: Gen-ART review of draft-ietf-tsvwg-… Fred Baker
- [Gen-art] RE: Gen-ART review of draft-ietf-tsvwg-… Sharon Chisholm