[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 [] (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 [] (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 ([] 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 ([]) 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 []) by sj-dkim-4.cisco.com ( 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 []) 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 ([]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:56:52 -0700
Received: from [] ([]) 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  
    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