Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
RFC 4875

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: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    mpls mailing list <mpls@lists.ietf.org>, 
    mpls chair <mpls-chairs@tools.ietf.org>
Subject: Protocol Action: 'Extensions to RSVP-TE for 
         Point-to-Multipoint TE LSPs' to Proposed Standard 

The IESG has approved the following document:

- 'Extensions to RSVP-TE for Point-to-Multipoint TE LSPs '
   <draft-ietf-mpls-rsvp-te-p2mp-08.txt> as a Proposed Standard

This document is the product of the Multiprotocol Label Switching Working 
Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-08.txt

Ballot Text

Technical Summary
 
  This document describes extensions to Resource Reservation 
  Protocol - Traffic Engineering (RSVP-TE) for the set up of
  Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched
  Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and 
  Generalized MPLS (GMPLS) networks.  The solution relies on RSVP-TE 
  without requiring a multicast routing protocol in the Service
  Provider core. Protocol elements and procedures for this solution
  are described.

  There can be various applications for P2MP TE LSPs such as IP
  multicast and multicast over VPNs.  Specification of how such
  applications will use a P2MP TE LSP is outside the scope of this
  document.
 
Working Group Summary
 
  The WG chairs report that this document has a very strong support in
  the working group. The work in this draft has also been done based on
  requirements from the GMPLS p2mp TE. The draft also has a strong
  support in the ccamp working group.
 
Protocol Quality
 
  Ross Callon has reviewed this for the IESG. There is at least one
  implementation, and the protocol has been deployed in more than one
  network.

RFC Editor Note