Draft: draft-ietf-tsvwg-vpn-signaled-preemption-01 Reviewer: Sharon Chisholm Review Date: Sunday 10/1/2006 8:13 PM CST IETF LC Date: 9/21/2006 Summary: This draft is not quite ready for publication. Comments: --------- 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. 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. 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. 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. 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 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. 4. Figure 2 is barely a figure and doesn't really demonstrate communication between the three entities listed. 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. 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? 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. 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? 9. In section 5, the fourth paragraph does not seem to be discussing a security consideration. 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. 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'.