Draft liaison 2 : Notification of new RFCs
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 26 July 2007 20:38 UTC
Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEA6V-00027s-Og for ccamp-archive@ietf.org; Thu, 26 Jul 2007 16:38:35 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEA6V-0000Cl-0f for ccamp-archive@ietf.org; Thu, 26 Jul 2007 16:38:35 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1IE9wI-0005is-8A for ccamp-data@psg.com; Thu, 26 Jul 2007 20:28:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8
Received: from [62.128.193.155] (helo=mta5.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1IE9w6-0005ht-Hn for ccamp@ops.ietf.org; Thu, 26 Jul 2007 20:27:56 +0000
Received: from mta5.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id l6QKRhg9009941; Thu, 26 Jul 2007 21:27:43 +0100
Received: from your029b8cecfe ([130.129.83.239]) (authenticated bits=0) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id l6QKRe0x009877; Thu, 26 Jul 2007 21:27:42 +0100
Message-ID: <191601c7cfc3$6a5fe3f0$0300a8c0@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: ccamp@ops.ietf.org
Cc: Ross Callon <rcallon@juniper.net>, Scott Bradner <sob@harvard.edu>
Subject: Draft liaison 2 : Notification of new RFCs
Date: Thu, 26 Jul 2007 21:20:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Hi, I think this is pretty non-controversial. Any comments? Adrian ======= To: ITU-T SG15 From: IETF CCAMP For Information The CCAMP working group of the IETF would like to inform you of the publication of three 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. 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
- Draft liaison 2 : Notification of new RFCs Adrian Farrel
- Re: Draft liaison 2 : Notification of new RFCs tom.petch
- Re: Draft liaison 2 : Notification of new RFCs Adrian Farrel