[Gen-art] RE: Gen-ART review of draft-ietf-tsvwg-vpn-signaled-preemption-01

["Sharon Chisholm" <[e-mail]>]

hi 

<Fred>
I get the impression that you didn't like the document :-)
</Fred>

I wouldn't go that far. It's just that I felt I kept getting lost in it.
There seemed to be a lot of good information, I think it just needs to
be reworked a bit.

<Fred>
> 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).

</Fred>


That would be very helpful. This description is also more helpful then
what is currently in the draft. Deciding a single statement of problem
and propagating it through the document would be helpful. Is the
interior/exterior the problem focus, the nesting of VPNs or both in
combination, for example.

<Fred>
> 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?
</Fred>

Is there a succinct way of summarizing the 'specific solution'?

<Fred>
> 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?
</Fred>

Actually, I did make a suggestion. I suggested organizing things as
problem statement, background information and terminology. Calling the
entire thing Introduction sounds good.

<Fred>
> 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.
</Fred>

My point was, aside from the first sentence that says 'such' a network
(and you should clarify what 'such' a network is since this is
potentially ambiguous given this is a new section), the next page or so
goes on to describe the steps performed by a (non-nested) VPN router.

<Fred>
> 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?
</Fred>

My complaint with section 1 wasn't that it was broken down into
sections, it that it could be better organized. I don't know what the
best way to help figure 5 would be. If it is describing two different
concepts it might be helpful to represent it separately. Or perhaps
since each enclave seems to have the same thing in it, we could hide
those details in the figure. The contents of an enclave could be shown
in a separate picture. And that way, there might be room to refer
instead to Router 1, Router 2, Host 1, Host 2, VPN 1, VPN 2 in the
figure as well as in the text. I think that would be an improvement.

<Fred>
> 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?
</Fred>

Well, you wouldn't then we introducing a new term, so that solves the
issue but the way you explained it here is much more understandable.

<Fred>
> 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.
</Fred>

So, this is intended to be identifying requirements to prevent a
specific security vulnerability? Some discussion on the security
vulnerability would help put it in context. Otherwise it reads like a
bit of oddly placed tutorial.

<Fred>
> 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.
</Fred>

The criticism is that the introduction to section 3 does not introduce
section 3 terribly well.  


Sharon

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art