[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
- [mpls] MPLS ring protection reconsidered ?? Loa Andersson
- Re: [mpls] MPLS ring protection reconsidered ?? Andrey Slastenov
- Re: [mpls] MPLS ring protection reconsidered ?? Huub van Helvoort
- Re: [mpls] MPLS ring protection reconsidered ?? Shahram Davari
- Re: [mpls] MPLS ring protection reconsidered ?? Kireeti Kompella
- Re: [mpls] MPLS ring protection reconsidered ?? Shahram Davari
- Re: [mpls] MPLS ring protection reconsidered ?? Dongjie (Jimmy)
- Re: [mpls] MPLS ring protection reconsidered ?? Kireeti Kompella
- Re: [mpls] MPLS ring protection reconsidered ?? weiqiang cheng