Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership
RFC 4972

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: 'Routing extensions for discovery of 
         Multiprotocol (MPLS) Label Switch Router (LSR) Traffic 
         Engineering (TE) mesh membership' to Proposed Standard 

The IESG has approved the following document:

- 'Routing extensions for discovery of Multiprotocol (MPLS) Label Switch 
   Router (LSR) Traffic Engineering (TE) mesh membership '
   <draft-ietf-ccamp-automesh-05.txt> as a Proposed Standard

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

The IESG contact persons are Ross Callon and David Ward.

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

Technical Summary
 
  The set up 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 potentially a large number of TE
  LSPs (on the order of the square of the number 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.

Working Group Summary
 
  No dissent reported. There has been some discussion of the wisdom 
  of putting this information in an IGP (rather than BGP or somewhere
  else) within the routing directorate and a few other relevant folks
  (eg, chairs of IS-IS and/or OSPF WGs). The consensus is clearly to 
  go ahead with this draft as specified. Based on this discussion,  
  appropriate text was added to the document that discusses this 
  issue briefly. The document was last called in the IS-IS and OSPF
  working groups in addition to the CCAMP WG. 

Protocol Quality
 
  Ross Callon has reviewed this for the IESG. According to the PROTO
  writeup there are implementations and at least some deployment. 

IANA Note

  The -03 and -04 versions of the draft contains an updated IANA 
  considerations section which is intended to respond to the IANA   
  questions entered into the tracker on Sept 27, 2006.