Skip to main content

Quality of Service (QoS) Signaling in a Nested Virtual Private Network
RFC 4923

Revision differences

Document history

Date Rev. By Action
2015-10-14
02 (System) Notify list changed from tsvwg-chairs@ietf.org, fred@cisco.com,pratik.bose@lmco.com to (None)
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Mark Townsley
2007-08-17
02 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-08-17
02 Amy Vezza [Note]: 'RFC 4923' added by Amy Vezza
2007-08-15
02 (System) RFC published
2007-04-04
02 (System) IANA Action state changed to No IC from In Progress
2007-04-04
02 (System) IANA Action state changed to In Progress
2007-04-02
02 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-03-28
02 Amy Vezza IESG state changed to Approved-announcement sent
2007-03-28
02 Amy Vezza IESG has approved the document
2007-03-28
02 Amy Vezza Closed "Approve" ballot
2007-03-28
02 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2007-03-19
02 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Discuss by Mark Townsley
2007-02-06
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-02-06
02 (System) New version available: draft-ietf-tsvwg-vpn-signaled-preemption-02.txt
2007-02-01
02 Jari Arkko
[Ballot comment]
My Discuss was resolved through text that Patrik Bose
sent in an e-mail on Jan 24, 2007. I expect the text
to appear …
[Ballot comment]
My Discuss was resolved through text that Patrik Bose
sent in an e-mail on Jan 24, 2007. I expect the text
to appear in the new revision and leave it to the
responsible AD to ensure this.
2007-02-01
02 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2006-11-08
02 (System) Request for Early review by SECDIR Completed. Reviewer: Tom Yu.
2006-10-13
02 Magnus Westerlund State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Magnus Westerlund
2006-10-12
02 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-10-12
02 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2006-10-12
02 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner
2006-10-11
02 Sam Hartman [Ballot comment]
Mark's discuss completely covers mine so I have removed it.
2006-10-11
02 Sam Hartman [Ballot comment]
Mark's discuss completely overlaps mine so I have removed it.
2006-10-11
02 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2006-10-11
02 Mark Townsley
[Ballot discuss]
I received the following from L3VPN Chair, Ron Bonica. I think that the separation of "nested" networks Ron points to is important. What …
[Ballot discuss]
I received the following from L3VPN Chair, Ron Bonica. I think that the separation of "nested" networks Ron points to is important. What I would like to discuss is whether or not the document goes far enough to point out that, in some VPN envrionments, it is impossible/undesirable to allow signalling between the nested VPNs in order to setup a reservation.

It seems that there might be room to mention L1VPNs as well, as at one level their whole purpose is to signal paths in a nested vpn of sorts using RSVP. This may boil down to some paragraphs on where the special relationships between customers and providers exist in the (G)MPLS world of VPNs vs. the IPsec VPNs that the text seems to focus on.

Ron's text follows:

I have seen this document before and let it go without comment, but now
that I think of it, I do have a couple of questions.

First, I don't see how this proposal fits into the L3VPN framework. Of
the three L3VPN solutions (BGP/MPLS, VR, CE-based) this proposal most
closely resembles a CE-based solution. This is because:

- the "VPN router" is in the customer's administrative domain
- the "VPN router" is in the customer's cryptographic domain
- no SP router carries any customer routing information, not even in a
VRF or Virtual Routing instance.

However, this proposal breaks the CE-based model in one very significant
way: The "VPN router" can create and destroy state on SP routers. It can
do this by using RSVP to signal bandwidth reservations between VPN routers.

This is all well and good so long as the VPN router can be trusted not
to do anything harmful to the SP network. However, L3VPNs are generally
designed so that there is nothing that a customer can do to harm the SP
network. I am a little concerned about exchanging RSVP signaling between
the VPN routers and SP edge router because there is little that the SP
edge can do to protect itself from irresponsible behavior on the part of
the VPN router. So, the L3VPN trust model is kind of turned on its head.

The second thing that bothers me has to do with the level of aggregation
between the plain-text and cipher-text network. There is a trade-off
between efficient use of bandwidth and security. In order to use
bandwidth efficiently, the aggregate reservation must closely track the
sum of end-to-end reservations. However, if you do this, you allow
traffic analysis in the cipher-text network. (For example, an enemy
monitoring the cipher-text network might know whenever the volume of
urgent calls increases.)

                                  Ron
2006-10-11
02 Mark Townsley [Ballot Position Update] New position, Discuss, has been recorded by Mark Townsley
2006-10-11
02 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2006-10-11
02 Cullen Jennings
[Ballot comment]
It might be worth mentioning in the security section about how this leaks information about priorities levels and the cases where it would …
[Ballot comment]
It might be worth mentioning in the security section about how this leaks information about priorities levels and the cases where it would be inappropriate to use it.
2006-10-11
02 Sam Hartman
[Ballot discuss]
This document requires that a security association contain traffic of
only one priority/precedence (I've lost track of what term means what).
That is …
[Ballot discuss]
This document requires that a security association contain traffic of
only one priority/precedence (I've lost track of what term means what).
That is a new change and there does not seem to be sufficient
consensus to make that change.

Instead, I propose that this document say that in order to get the
benefits proposed by this mechanism, only one priority of traffic can
be carried over a SA, but clearly indicate that the standards allow an
implementation to make other tradeoffs.
2006-10-11
02 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2006-10-09
02 Brian Carpenter [Ballot comment]
I'd be pleased to see an update responding to the points raised
in the Gen-ART review by Sharon Chisholm:
http://www1.ietf.org/mail-archive/web/gen-art/current/msg01336.html
2006-10-09
02 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter
2006-09-29
02 Sam Hartman
[Ballot discuss]
Hi.  I believe it is inappropriate to consider this document before
draft-ietf-tsvwg-rsvp-ipsec comes to the IESG.  As I understand it,
the ability to …
[Ballot discuss]
Hi.  I believe it is inappropriate to consider this document before
draft-ietf-tsvwg-rsvp-ipsec comes to the IESG.  As I understand it,
the ability to have two reservations between the same
source-destination pair at the same DSCP value is new in that draft.
That seems rather central to the ability to have different aggregate
reservations for each precedence level.

I guess this also means that this document is the first time we've
discussed how to handle the preemption issue with the security/IPSec
community.  I suspect you will get some pushback to language in this
document.

I'm working on getting that review, but I expect the discussion to get
all tangled in draft-ietf-tsvwg-rsvp-ipsec, so another reason I don't
think we can consider one without the other.
2006-09-29
02 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Discuss from No Objection by Sam Hartman
2006-09-29
02 (System) Removed from agenda for telechat - 2006-09-28
2006-09-28
02 Mark Townsley State Changes to IESG Evaluation - Defer from IESG Evaluation by Mark Townsley
2006-09-27
02 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2006-09-27
02 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2006-09-27
02 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2006-09-27
02 Jari Arkko
[Ballot discuss]
> This means that the
> Guard must somehow receive and respond to, on behalf of the VPN
> Router, messages that are …
[Ballot discuss]
> This means that the
> Guard must somehow receive and respond to, on behalf of the VPN
> Router, messages that are not directed to it.  There are several
> possible solutions:
>
> o  The two devices could use a common MAC and IP address, so that
>    traffic destined to one is also received by the other

This appears problematic, e.g., I do not understand
how it would work with IPv6 and DAD.

I do realize that the authors are stating earlier
that there are several problems with these approaches.
Nevertheless, the listing of such solutions without
actually describing the problems appears potentially
dangerous. Since the authors recommend another alternative
anyway, I wonder if the list could be changed to
simply talk about the problems and then recommend
the other solution that is currently recommended.

(And I'm not quite sure why this document needs
to discuss the separation to begin with. This
seems to be an implementation issue.)
2006-09-27
02 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2006-09-27
02 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2006-09-27
01 (System) New version available: draft-ietf-tsvwg-vpn-signaled-preemption-01.txt
2006-09-27
02 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-09-26
02 Lars Eggert
[Ballot comment]
Section 1., paragraph 10:
>    interface; a priority scheduler always chooses a datagram from the
>    highest priority class (queue) that …
[Ballot comment]
Section 1., paragraph 10:
>    interface; a priority scheduler always chooses a datagram from the
>    highest priority class (queue) that is occupied, shielding one class
>    of traffic from jitter by passing jitter it would otherwise have
>    experienced to another class.

  "from most of the jitter" - because packet transmission is not
  preemtable, priority inversion through head-of-line blocking by
  lower-priority packets can occur

Further editing nits mailed to the authors, chairs and shepherds.
2006-09-26
02 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2006-09-25
02 Magnus Westerlund State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Magnus Westerlund
2006-09-25
02 Magnus Westerlund Placed on agenda for telechat - 2006-09-28 by Magnus Westerlund
2006-09-25
02 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2006-09-25
02 Magnus Westerlund Ballot has been issued by Magnus Westerlund
2006-09-25
02 Magnus Westerlund Created "Approve" ballot
2006-09-21
02 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-09-15
02 Yoshiko Fong IANA Last Call Comments:

As described in the IANA Considerations section, we understand
this document to have no IANA Actions.
2006-09-07
02 Amy Vezza Last call sent
2006-09-07
02 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-09-07
02 Magnus Westerlund State Change Notice email list have been change to tsvwg-chairs@tools.ietf.org, fred@cisco.com,pratik.bose@lmco.com from tsvwg-chairs@tools.ietf.org
2006-09-07
02 Magnus Westerlund State Changes to Last Call Requested from Publication Requested by Magnus Westerlund
2006-09-07
02 Magnus Westerlund Last Call was requested by Magnus Westerlund
2006-09-07
02 (System) Ballot writeup text was added
2006-09-07
02 (System) Last call text was added
2006-09-07
02 (System) Ballot approval text was added
2006-07-21
02 Lars Eggert Magnus is AD for this one.
2006-07-21
02 Lars Eggert Shepherding AD has been changed to Magnus Westerlund from Lars Eggert
2006-07-21
02 Dinara Suleymanova
PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready …
PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Yes, Shepherd is James Polk (jmpolk@cisco.com), TSVWG co-chair

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Yes. no concerns

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There was solid consensus. It has been reviewed by a number of people.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).

No, there are no threats of an appeal or extreme discontent wrt this
document's progression.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes, this document has a single extra space character as its only
nit. This will be fixed, but should not impede the review progress in the
short term.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publication). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

References split. There are 3 normative references that are Internet
Drafts. Since this document's submission in Feb 06, two of these within
this ID have become RFCs (RFC 4495 and RFC 4542), and the other is should
progress at the same time through IESG review and the RFC-Editor
(draft-ietf-tsvwg-rsvp-ipsec-01.txt). as a dependent reference.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

More and more networks wish to guarantee secure transmission of IP traffic
for across public LANs or WANs and therefore use Virtual Private
Networks. 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 document seeks to outline the
issues and the nature of the proposed solutions. The outline of the QoS
solution for real-time traffic has been described at a high level in RFC
4542
.

The thrust of this document involves VPNs that use encryption in some form,
such as IPsec. As a result, this document will discuss the VPN Router
supporting "plaintext" and "ciphertext" interfaces. However, the concept
extends readily to any form of aggregation, including the concept proposed
in [RFC3175] of the IP traffic entering and leaving a network at identified
points, and the use of other kinds of tunnels including GRE, IP/IP, MPLS,
and so on.

* Working Group Summary

There is strong consensus in the WG to publish this document. It has been
reviewed by several people prior to and in the WG last call. Comments
raised have been addressed.

* Protocol Quality

This document does not propose any protocol extension.

This document has been well reviewed in the WG and comments raised have
been addressed.
2006-07-21
02 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-02-28
00 (System) New version available: draft-ietf-tsvwg-vpn-signaled-preemption-00.txt