Protocol Action: 'MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators' to Proposed Standard (draft-ietf-mpls-tp-psc-itu-04.txt)

The IESG <iesg-secretary@ietf.org> Mon, 31 March 2014 18:21 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2C31A6F65; Mon, 31 Mar 2014 11:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3keSifiT1Rg5; Mon, 31 Mar 2014 11:21:54 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 623BB1A6F78; Mon, 31 Mar 2014 11:21:48 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators' to Proposed Standard (draft-ietf-mpls-tp-psc-itu-04.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140331182148.14076.91543.idtracker@ietfa.amsl.com>
Date: Mon, 31 Mar 2014 11:21:48 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/y9WYu2QoBx6b141NjSrk0PytIP4
Cc: mpls mailing list <mpls@ietf.org>, mpls chair <mpls-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2014 18:21:56 -0000

The IESG has approved the following document:
- 'MPLS Transport Profile (MPLS-TP) Linear Protection to Match the
   Operational Expectations of SDH, OTN and Ethernet Transport Network
   Operators'
  (draft-ietf-mpls-tp-psc-itu-04.txt) as Proposed Standard

This document is the product of the Multiprotocol Label Switching Working
Group.

The IESG contact persons are Adrian Farrel and Alia Atlas.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/




Technical Summary

  This document describes alternate mechanisms to perform some of the
  MPLS-TP  linear protection sub-functions defined in RFC 6378. It also defines
  some additional mechanisms.   The purpose of these mechanisms is to closely
  model the behavior of linear protection seen in other transport networks.

  This document also introduces capabilities and modes for linear protection.  
  A capability is an individual behavior, and a mode is a particular combination 
  of capabilities.  Two modes are defined PSC mode and  APS mode.

  The document describes the behavior of the PSC protocol including
  when all the capabilities of the APS mode are enabled. The document
  describes priority logic and the protocol state machine.

  The document updates RFC 6378 in that the capability advertisement
  method defined here is an addition to that document.

Working Group Summary

  This document has a rather long history. It is intended to match the 
  operational practices and methods that have been used by transport 
  network operators prior to the introduction of MPLS. When RFC 6378 was
  progressed it was decided that backwards compatibility with deployed MPLS 
  networks was the priority. 

  Later the discussion on meeting the requirements from transport network
  operators re-emerged and it was decided that the solution should be based
  on RFC 6378. To that end RFC 6378 had to be slightly extended and
  modified. There were 5 capabilities missing in RFC 6378, these were the
  extensions.  There were also cases where relative priority between different
  actions need to be changed, these were the modifications.

  The first approach were to write a single document for each capability (at the
  time it was thought that the capabilities might be activated independently), 
  The discussion in the working group however converged on putting all the
  capabilities in one document.

  The first MPLS Review Team review and the discussion in the working clearly
  indicated a wish to make the merged document a working group document, so
  the chairs initiated a second MPLS Review Team review and took the 
  decision to make it a working group document without running the normal WG
  adoption poll, instead evaluating the discussion on the mailing and their own
  review.  
. 
  The document has, nevertheless been well discussed within the working group.

  After that the document became a working group document there has been a
  good and open discussion on the mailing.

  It is the Shepherds opinion that the document is ready for publication.
      
Document Quality

  An implementation poll has been sent to the working group mailing
  list and the write-up will be updated if and when the information is available.

  There are strong indications of vendor interest.

  There is a long list of important reviewers, especially the MPLS Review Team
  reviewers that contributed the arguments that resulted in the current document
  structure and that also did a careful technical review.

Personnel

  Loa Andersson is the document shepherd
  Adrian Farrel is the responsible AD