Re: Draft liaison 2 : Notification of new RFCs

["Adrian Farrel" <[e-mail]>]

Picky, picky, picky.

;-)

Adrian
----- Original Message ----- 
From: "tom.petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Tuesday, July 31, 2007 8:56 AM
Subject: Re: Draft liaison 2 : Notification of new RFCs


> ----- Original Message ----- 
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Cc: "Ross Callon" <[e-mail]>; "Scott Bradner" <[e-mail]>
> Sent: Thursday, July 26, 2007 10:20 PM
> Subject: Draft liaison 2 : Notification of new RFCs
>
>
>>
>> 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
>
> Three new RFC. Now let me see, that would be
>
> RFC4872 one
> RFC4873 two
> RFC4874 two point five
> RFC4875 two point seven five
> RFC4920 three
>
> Yup, that is three new RFC:-)
>
> Tom Petch
>
>> 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
>