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 |