Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model
RFC 4208

Approval announcement
Draft of message to be sent after approval:

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>, 
    ccamp mailing list <ccamp@ops.ietf.org>, 
    ccamp chair <ccamp-chairs@tools.ietf.org>
Subject: Protocol Action: 'Generalize Multiprotocol Label 
         Switching(GMPLS) User-Network Interface (UNI): Resource 
         ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for 
         the Overlay Model' to Proposed Standard 

The IESG has approved the following document:

- 'Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface 
   (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 
   Support for the Overlay Model '
   <draft-ietf-ccamp-gmpls-overlay-06.txt> as a Proposed Standard

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Alex Zinin and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-06.txt

Technical Summary
 
   Generalized Multiprotocol Label Switching (GMPLS) defines both
   routing and signaling protocols for the creation of Label Switched
   Paths (LSPs) in various switching technologies. These protocols can
   be used to support a number of deployment scenarios. This memo
   addresses the application of GMPLS to the overlay model.
 
Working Group Summary
 
   The WG had a consensus on advancing this document.
 
Protocol Quality
 
   Dimitri Papadimitriou reviewed this document for the RTG-DIR, and
   Alex Zinin reviewed this document for the IESG.

RFC Editor Note:

Section 8. Security Considerations

OLD:
   This draft imposes no new security risks over [RFC3473]. In fact it
   represents a lower trust model between the core and edge-nodes as the
   core is permitted to hide its topology from the edge-nodes. The core
   is also permitted to restrict the actions of edge-nodes by filtering
   out specific RSVP objects.

NEW:
   The trust model between the core and edge-nodes is different
   than the one described in [RFC3473], as the core is permitted to
   hide its topology from the edge-nodes, and the core is permitted
   to restrict the actions of edge-nodes by filtering out specific
   RSVP objects.


IANA Note:

 This document requires no IANA action.