Re: [mpls] MPLS ring protection reconsidered ??
Kireeti Kompella <kireeti.kompella@gmail.com> Wed, 18 March 2015 01:13 UTC
Return-Path: <kireeti.kompella@gmail.com>
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 022F31A870B for <mpls@ietfa.amsl.com>; Tue, 17 Mar 2015 18:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 c7ica6ghxMMg for <mpls@ietfa.amsl.com>; Tue, 17 Mar 2015 18:13:47 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06521A8704 for <mpls@ietf.org>; Tue, 17 Mar 2015 18:13:46 -0700 (PDT)
Received: by wgbcc7 with SMTP id cc7so22401782wgb.0 for <mpls@ietf.org>; Tue, 17 Mar 2015 18:13:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aiCpbcI0CL4t7piaUJefdbaNas0TZs6PosHpKAgqScE=; b=yzh/lxMR+SB77DvgjI5ZF4BhEK9NDFLiImCinJdWPZSTItblbW+L1f0BzgtAkfbXyW 3rTC/ay1Dc2UDlTOFU0fZIfOLA/pim9Ji5ZhygxP6+c78lNhj2QBKG4oZodPOrl70Gpw BKRm7mSLRZsAv2bQiutWlNMFawJDzG4xAAy9zcQROlrGfw6AE1wqyuC3EE5R0s56tTK2 xQp2xazqp7+xP6QSMKD8FA+XKA1O6lnV/xt0NxAheB0jz1E8tDST+oUdhVMUaLOAZ/vE zKIySIfzmh8A6uYuRH8hUg1+TeKYgg4dFCDMS/nX7pDchFvRc/A6FXB66A+oCETcFeyj V3mw==
X-Received: by 10.194.21.193 with SMTP id x1mr135332924wje.144.1426641225761; Tue, 17 Mar 2015 18:13:45 -0700 (PDT)
Received: from [172.20.4.118] ([46.218.58.213]) by mx.google.com with ESMTPSA id fy2sm873310wic.15.2015.03.17.18.13.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 18:13:43 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Kireeti Kompella <kireeti.kompella@gmail.com>
In-Reply-To: <EB92B50E-8B37-4556-AA6C-4F35755B85AB@broadcom.com>
Date: Wed, 18 Mar 2015 02:13:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B633A6B5-0FDE-4F23-9290-BC3CC5DD409F@gmail.com>
References: <5506E75F.4080201@pi.nu> <EB92B50E-8B37-4556-AA6C-4F35755B85AB@broadcom.com>
To: Shahram Davari <davari@broadcom.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/bhr2GSGC_sCrx-D9wbOxwwsE9s4>
Cc: "draft-kompella-mpls-rmr@tools.ietf.org" <draft-kompella-mpls-rmr@tools.ietf.org>, "draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org" <draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [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: Wed, 18 Mar 2015 01:13:49 -0000
Shahram, On Mar 17, 2015, at 01:14 , Shahram Davari <davari@broadcom.com> wrote: > Hi Loa > > I support merging these two drafts as I mentioned it on the Mic during last IETF. I don’t. Here’s why (in addition to points that others have mentioned): 1) The two drafts have different views of ring LSPs. draft-cheng creates LSPs on rings; RMR creates ring LSPs (LSPs that start and end at the same node). 2) draft-cheng is focused on MPLS-TP; RMR is focused on IP/MPLS & MPLS-TE 3) RMR considers the issue of “bypass links”. 4) RMR, in addition to protection, also aims to significantly reduce the configuration of ring LSPs. Kireeti. > Regards, > Shahram > > >> On Mar 16, 2015, at 10:23 PM, Loa Andersson <loa@pi.nu> wrote: >> >> >> 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 mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls
- [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 ?? weiqiang cheng
- Re: [mpls] MPLS ring protection reconsidered ?? Shahram Davari
- Re: [mpls] MPLS ring protection reconsidered ?? Kireeti Kompella
- Re: [mpls] MPLS ring protection reconsidered ?? Kireeti Kompella
- Re: [mpls] MPLS ring protection reconsidered ?? Dongjie (Jimmy)