[mpls] MPLS ring protection reconsidered ??

Loa Andersson <loa@pi.nu> Mon, 16 March 2015 14:23 UTC

Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8521A87A2 for <mpls@ietfa.amsl.com>; Mon, 16 Mar 2015 07:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 tctzWvVBNI6D for <mpls@ietfa.amsl.com>; Mon, 16 Mar 2015 07:23:33 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DDE1A877B for <mpls@ietf.org>; Mon, 16 Mar 2015 07:23:31 -0700 (PDT)
Received: from [172.20.11.241] (unknown [46.218.58.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 12EE118013C8; Mon, 16 Mar 2015 15:23:30 +0100 (CET)
Message-ID: <5506E75F.4080201@pi.nu>
Date: Mon, 16 Mar 2015 15:23:27 +0100
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "mpls@ietf.org" <mpls@ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/QSzenkvsFp50mZfiJsqMnH4EqXk>
Cc: draft-kompella-mpls-rmr@tools.ietf.org, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org" <draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org>
Subject: [mpls] MPLS ring protection reconsidered ??
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2015 14:23:40 -0000

Folks,

(taking my chair hat off for a while, i.e. this should not be
read as a chair directive, just a bit of mumbling that comes out
thinking about how to progress documents.)

As far back s the 73rd IETF in Minneapolis John and Adrian made
a report on "Requirements for Ring Protectionin MPLS-TP". The
conclusions were that we could do topology specific protection
solutions if the benefits are big enough.

Such solutions need to meet the same requirements as linear
protection and it has to be show that it can't be done by linear
protection only.

At that time we did not see that there were things that would not
be as readily done by the linear protection being specified at that
time.

Today we have to drafts that address ring topologies, one 
draft-kompella-mpls-rmr addresses Resilient MPLS Rings in an MPLS-TE
environment. The other draft-cheng-mpls-tp-shared-ring-protection
addresses protection in an MPLS-TP environment.

Both recognizes that ring topologies are very common and that very
efficient mechanism for keeping traffic flowing in case of failures
are possible to design. Sometime far better than what is the case if
the actual ring topologies are view as a linear topology,

The first document (draft-kompella- ) looks primarily on the operations
within a single ring and how fast and simple mechanisms for protection
can be deployed. A ring topology is a very common deployment scenario.
While, the draft-kompella from a solutions point is somewhat orthogonal
to draft-cheng, it does also discuss the dynamic control plane for mpls
ring, including auto-discovery and signaling. It seems that there are
opportunities for co-operation between the two drafts in this area.

The other (draft-cheng- ) looks at what is called MPLS shared ring, i.e.
a rather high number can shared the same path around the ring, and all
traffic can be protected by a single operation.
Another aspect of the shared tunnel is that if part of the ring
(typically 2 nodes and one link) are part of more than one ring. It
becomes possible to protect against more than one failure.

Maybe it is time to revisit the question and see if we want to adopt
working group documents for the two scenarios outlined above.

/Loa
-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64