Skip to main content

Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)
draft-kumaki-murai-l3vpn-rsvp-te-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Support for RSVP-TE in L3VPNs' to Experimental RFC (draft-kumaki-murai-l3vpn-rsvp-te-09.txt)

The IESG has approved the following document:
- 'Support for RSVP-TE in L3VPNs'
  (draft-kumaki-murai-l3vpn-rsvp-te-09.txt) as Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/


Ballot Text

Technical Summary

IP Virtual Private Networks (VPNs) provide connectivity between sites
across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS
and a single provider edge (PE) node may provide access to multiple
customer sites belonging to different VPNs.

The VPNs may support a number of customer services including RSVP and
RSVP-TE traffic. This document describes how to support RSVP-TE
between customer sites when a single PE supports multiple VPNs and
labels are not used to identify VPNs between PEs.

Working Group Summary

The Working Group did not adopt the work, even though prior requirements
exist within another working group document (RFC5824). However the working
group chars felt the work had merit and good support from its co-authors
therefore the document might be progressed as experimental and AD sponsored. 

Document Quality

The authors mentioned that extensions defined in the document have been
implemented and tested. Although I do think the document would benefit from
a thorough review and I would be willing to do this. The document is
Experimental therefore there are no IANA requests. No MIB currently exists
to manage or report the status of these new protocol mechanisms.  

Personnel

Daniel King is the Document Shepard.
Stewart Bryant  is the Responsible Area Director.'


RFC Editor Note