Generalized 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-05
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>,
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
Ballot Text
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.