New Liaison Statement, "New RFCs Published as of 1st August 2007"

[Adrian Farrel (IETF CCAMP WG) <adrian@olddog.co.uk>]

Title: New RFCs Published as of 1st August 2007
Submission Date: 2007-08-02
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=352 

From: Adrian Farrel(IETF CCAMP WG) <adrian@olddog.co.uk>
To: ITU-T SG15(Greg Jones <greg.jones@itu.int>)
Cc: Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com>
Kam Lam <hklam@alcatel-lucent.com>
Scott Bradner <sob@harvard.edu>
Ross Callon <rcallon@juniper.net>
Dave Ward <dward@cisco.com>
Deborah Brungard <dbrungard@att.com>
CCAMP Mailing List <ccamp@ops.ietf.org>
Reponse Contact: Adrian Farrel <adrian@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
Technical Contact: Adrian Farrel <adrian@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
Purpose: For information 
Body: The CCAMP working group of the IETF would like to inform you of
the publication of several new RFCs (Request for Comment) that may
be relevant to your work.

RFC 4872
Title
   RSVP-TE Extensions in Support of End-to-End
   Generalized Multi-Protocol Label Switching (GMPLS)
   Recovery
Abstract
   This document describes protocol-specific procedures and extensions
   for Generalized Multi-Protocol Label Switching (GMPLS) Resource
   ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to
   support end-to-end Label Switched Path (LSP) recovery that denotes
   protection and restoration.  A generic functional description of
   GMPLS recovery can be found in a companion document, RFC 4426.

RFC 4873
Title
   GMPLS Segment Recovery
Abstract
   This document describes protocol specific procedures for GMPLS
   (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
   ReserVation Protocol - Traffic Engineering) signaling extensions to
   support label switched path (LSP) segment protection and restoration.
   These extensions are intended to complement and be consistent with
   the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).
   Implications and interactions with fast reroute are also addressed.
   This document also updates the handling of NOTIFY_REQUEST objects.

RFC 4874
Title
   Exclude Routes - Extension to Resource ReserVation Protocol-
   Traffic Engineering (RSVP-TE)
Abstract
   This document specifies ways to communicate route exclusions during
   path setup using Resource ReserVation Protocol-Traffic Engineering
   (RSVP-TE).

   The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
   Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
   Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
   abstract nodes and resources to be explicitly included in a path
   setup, but not to be explicitly excluded.

   In some networks where precise explicit paths are not computed at the
   head end, it may be useful to specify and signal abstract nodes and
   resources that are to be explicitly excluded from routes.  These
   exclusions may apply to the whole path, or to parts of a path between
   two abstract nodes specified in an explicit path.  How Shared Risk
   Link Groups (SRLGs) can be excluded is also specified in this
   document.

RFC 4875
Title
   Extensions to Resource Reservation Protocol - Traffic 
   Engineering (RSVP-TE) for Point-to-Multipoint TE Label 
   Switched Paths (LSPs)
Abstract
   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.  Specification of how such applications will use a P2MP TE
   LSP is outside the scope of this document.

RFC 4920
Title
   Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
Abstract
   In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date.  This means
   that Multiprotocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
   requests may be blocked by links or nodes without sufficient
   resources.  Crankback is a scheme whereby setup failure information
   is returned from the point of failure to allow new setup attempts to
   be made avoiding the blocked resources.  Crankback can also be
   applied to LSP recovery to indicate the location of the failed link
   or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
   RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in
   "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
   Functional Description", RFC 3473.  These extensions mean that the
   LSP setup request can be retried on an alternate path that detours
   around blocked links or nodes.  This offers significant improvements
   in the successful setup and recovery ratios for LSPs, especially in
   situations where a large number of setup requests are triggered at
   the same time.

RFC 4972
Title
   Routing Extensions for Discovery of Multiprotocol (MPLS) Label 
   Switch Router (LSR) Traffic Engineering (TE) Mesh Membership
Abstract
   The setup of a full mesh of Multi-Protocol Label Switching (MPLS)
   Traffic Engineering (TE) Label Switched Paths (LSP) among a set of
   Label Switch Routers (LSR) is a common deployment scenario of MPLS
   Traffic Engineering either for bandwidth optimization, bandwidth
   guarantees or fast rerouting with MPLS Fast Reroute.  Such deployment
   may require the configuration of a potentially large number of TE
   LSPs (on the order of the square of the number of LSRs).  This document
   specifies Interior Gateway Protocol (IGP) routing extensions for
   Intermediate System-to-Intermediate System (IS-IS) and Open Shortest
   Path First (OSPF) so as to provide an automatic discovery of the set
   of LSRs members of a mesh in order to automate the creation of such
   mesh of TE LSPs.


All IETF RFCs can be downloaded for free from
http://www.ietf.org/rfc.html

The current work plan and progress status of the CCAMP working group
can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html

As always, the CCAMP working group welcomes questions and discussion
about all of its work from individuals or organisations.

The CCAMP mailing list is open to anyone. Details of subscription can
be found on the CCAMP charter page.

Best regards,
Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group
Attachment(s):
     PDF of original LS (https://datatracker.ietf.org/documents/LIAISON/file460.pdf)