Re: [mpls] [mpls-tp] 答复: Re: Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert
"Eric Osborne (eosborne)" <eosborne@cisco.com> Fri, 13 August 2010 10:20 UTC
Return-Path: <eosborne@cisco.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB6C3A6819; Fri, 13 Aug 2010 03:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.651
X-Spam-Level:
X-Spam-Status: No, score=-6.651 tagged_above=-999 required=5 tests=[AWL=-3.947, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI0zFX496b-X; Fri, 13 Aug 2010 03:20:12 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2018A3A696B; Fri, 13 Aug 2010 03:20:12 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPK4ZEytJV2b/2dsb2JhbACDFZ0kcZ90iUwIkXCBIoMhdwSELYgX
X-IronPort-AV: E=Sophos;i="4.55,362,1278288000"; d="scan'208";a="147298602"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 13 Aug 2010 10:20:48 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o7DAKmdu019808; Fri, 13 Aug 2010 10:20:48 GMT
Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 05:20:47 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Aug 2010 05:20:46 -0500
Message-ID: <D29E470202D67745B61059870F433B540278F0F1@XMB-RCD-202.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls] 答复: Re: Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert
Thread-Index: Acs6rN33zx3FBNEVQ/2KohRdHFK9PwAAZuZOAAht6fA=
From: "Eric Osborne (eosborne)" <eosborne@cisco.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, dai.xuehui@zte.com.cn
X-OriginalArrivalTime: 13 Aug 2010 10:20:47.0891 (UTC) FILETIME=[326F1E30:01CB3AD1]
Cc: mpls@ietf.org, Shell Nakash <Shell.Nakash@ecitele.com>, Alexander Kugel <Alexander.Kugel@ecitele.com>, MPLS TP <mpls-tp@ietf.org>, Mishael Wexler <Mishael.Wexler@ecitele.com>, Srinivas Goli <Srinivas.Goli@ecitele.com>
Subject: Re: [mpls] [mpls-tp] 答复: Re: Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 13 Aug 2010 10:20:17 -0000
You can't (easily) directly port FRR over to TP since FRR is unidirectional and TP has this bidirectional requirement, but you solve that with a protection state coordination protocol, a la draft-weingarten-mpls-tp-linear-protection. Once you have that, you can get pretty close to what people think of as FRR in MPLS-TP. Of course, since FRR stands for 'fast reRoute' and we're not supposed to talk about routing in TP networks, we end up calling it something else like 1:n Linear Protection. :) eric > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Alexander Vainshtein > Sent: Friday, August 13, 2010 2:11 AM > To: dai.xuehui@zte.com.cn > Cc: mpls@ietf.org; Shell Nakash; Alexander Kugel; MPLS TP; Mishael Wexler; > Srinivas Goli > Subject: Re: [mpls-tp] [mpls] 答复: Re: Updated drafts - draft-kini-mpls-ring- > frr-facility-backup, draft-kini-mpls-fast-lsp-alert > > Xuehui, and all, > > As a matter of fact, FRR is a pure data plane mechanism that can be > decoupled from the control plane. > (Of course it means that your bypass tunnels have to be constructed by the > management plane, but this is nothing to prevent this). As a consequence, > FRR is fully acceptable in MPLS-TP. > > My 2 c, > Sasha > > ________________________________ > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > dai.xuehui@zte.com.cn [dai.xuehui@zte.com.cn] > Sent: Friday, August 13, 2010 8:33 AM > To: Autumn Liu > Cc: liu.guoman@zte.com.cn; mpls-bounces@ietf.org; mpls@ietf.org > Subject: [mpls] 答复: Re: Updated drafts - draft-kini-mpls-ring-frr-facility- > backup, draft-kini-mpls-fast-lsp-alert > > > > Hi all, > > From my understanding, FRR mechanism is based on RSVP-TE protocol, since > , if the proposed method be used in MPLS-TP ,this can only be used when > there is a control plane. > > and in the example below, e-backup tunnel L10-L1-L2-L3-L4-L5-L6 can only > protect LSP1: L10-L9-L8-L7-L6; and for LSP2:: L10-L1-L2-L3-L4, there should be > another e-backup tunnel . and > > through the association between the primary LSP and bypass tunnel ( by RRO > object ), once an alert message received from this bypass tunnel , the node > can judge which primary LSP needs to be protected. > > is my understanding right? > > Best regards, > > -xuehui > > > > > Autumn Liu <autumn.liu@ericsson.com> > 发件人: mpls-bounces@ietf.org > > 2010-08-05 06:08 > > 收件人 > "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> > 抄送 > "mpls@ietf.org" <mpls@ietf.org> > 主题 > Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini- > mpls-fast-lsp-alert > > > > > > > Hi Liu, > > In your example, the bypass tunnel only protects the first primary LSP (L10- > L9-L8-L7-L6). The proposed RRO object will be included for this primary LSP > only. As a result, the alert message will only trigger this primary to switch > over to the e-backup. > > Regards, > Autumn > > > ________________________________ > > From: liu.guoman@zte.com.cn [mailto:liu.guoman@zte.com.cn] > Sent: Tuesday, August 03, 2010 12:38 AM > To: Autumn Liu > Cc: Greg Mirsky; Julien Meuric; mpls@ietf.org; mpls-bounces@ietf.org > Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, > draft-kini-mpls-fast-lsp-alert > > > hi,Autumn > here I only ask a question for this E-FRR solution. > for example as the following: > +-------L1--------L2---------L3--------L4-------+ > | | > L10 L5 > | | > +-------L9--------L8---------L7--------L6-------+ > we suppose there are two working LSP , One LSP: L10-L9-L8-L7-L6, > another LSP: L10-L1-L2-L3-L4. > now if the failure happened between L8 and L7. according to your solution. > L8 and L7 would send fast alert message to each node of bypass Tunnel > : L8-L9-L10-L1-L2-L3-L4-L5-L6-L7; > when node L10 received fast alert message from L8 or L7, for working LSP: > L10-L9-L8-L7-L6, will swich into e-backup tunnel: L10-L1-L2-L3-L4-L5-L6; > while for another LSP: L10-L1-L2-L3-L4 , how do it know the failure don't > affect the working LSP and can't need to switch into e-backup tunnel? > whether there is include LSP ID information which will be affected by > the failure in the fast alert message packet? or the solution will adapt > new method to judge which LSP will be affected by the failure? > > maybe my understanding be wrong? > > best regards > liu > > > > > > > > > > Autumn Liu <autumn.liu@ericsson.com> > 发件人: mpls-bounces@ietf.org > > 2010-07-28 06:35 > > > > 收件人 > Greg Mirsky <gregimirsky@gmail.com>, Julien Meuric > <julien.meuric@orange-ftgroup.com> > 抄送 > "mpls@ietf.org" <mpls@ietf.org> > 主题 > Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, > draft-kini-mpls-fast-lsp-alert > > > > > > > > > Hi Greg and Julien > > Thanks for pointing this out. The draft can be applied to the case when > segment protection is utilized as defined in 4873. We will update the draft > accordingly. > > Regards, > Autumn > > > > > ________________________________ > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: Monday, July 26, 2010 1:37 PM > To: Autumn Liu > Cc: mpls@ietf.org > Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, > draft-kini-mpls-fast-lsp-alert > > Dear Autumn, > thank you for adding specific case to our discussion. In my view protecting > segment L10-L1-L2-L3-L4-L5 (e-backup tunnel) is shared by all backup tunnels > that traverse the ring through nodes L10-L9-L8-L7-L6-L5. This e-backup tunnel > is the e-backup tunnels for all working sections/segments (in case of link and > node protection) of an LSP L10-...-L8-..-L5. I'd re-state my question to authors > whether they've considered re-using RSVP-TE objects and subobjects > defined in RFC 4873. If mechanisms and objects defined in RFC 4873 not > sufficient, why RFC 4873 not referenced in the draft Efficient Facility Backup > FRR. > > Regards, > Greg > > On Mon, Jul 26, 2010 at 12:16 PM, Autumn Liu <autumn.liu@ericsson.com > <mailto:autumn.liu@ericsson.com> > wrote: > Hi Greg, > > +-------L1--------L2---------L3--------L4-------+ > | | > L10 L5 > | | > +-------L9--------L8---------L7--------L6-------+ > > Not all PLRs. Using the diagram in draft as an example. > Bypass 1 (to protect link between L8 and L7) : L8-L9-L10-L1-L2-L3-L4-L5-L6-L7 > Bypass 2 (to protect node failure on L8) : L9-L10-L1-L2-L3-L4-L5-L6-L7 > > e-backup tunnel L10-L1-L2-L3-L4-L5 can be used instead for both cases > without getting traffic u-turned. > > Regards, > Autumn > > > > > ________________________________ > > From: Greg Mirsky [mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com> ] > Sent: Monday, July 26, 2010 12:03 PM > To: Autumn Liu > Cc: Julien Meuric; Sriganesh Kini; mpls@ietf.org <mailto:mpls@ietf.org> > > Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, > draft-kini-mpls-fast-lsp-alert > > Dear Autumn, > I'm quite surprised to read your reply to Julien. My understanding of your > proposal is that all PLRs share the same u-PLR for given ring segment of LSP. > Please correct me if my understanding is different from authors intention. > I'd like to add to Julien's comment that RFC 4873 seems relevant to your > solution as well as RFC 4872. And I'd ask the same question as Julien in regard > to not referencing RFC 4873. > > Regards, > Greg > > On Mon, Jul 26, 2010 at 11:30 AM, Autumn Liu <autumn.liu@ericsson.com > <mailto:autumn.liu@ericsson.com> > wrote: > Hi Julien, > > draft-kini-mpls-ring-frr-facility-backup describes a mechanism to let the > primary LSP be aware of what the bypass LSP for corresponding protected > facility. If my understanding is correct, the association mechanism defined in > 4872 is used to associate the primary and backup LSPs. This is not good > enough for the problem the draft is trying to address since each link/node > along the primary LSP may have different bypass LSPs. > > Regards, > Autumn > > > -----Original Message----- > From: mpls-bounces@ietf.org <mailto:mpls-bounces@ietf.org> > [mailto:mpls-bounces@ietf.org <mailto:mpls-bounces@ietf.org> ] On Behalf > Of Julien Meuric > Sent: Monday, July 26, 2010 10:40 AM > To: Sriganesh Kini > Cc: mpls@ietf.org <mailto:mpls@ietf.org> > Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, > draft-kini-mpls-fast-lsp-alert > > Hi Sriganesh. > > The mechanism described in draft-kini-mpls-ring-frr-facility-backup > reminds me of end to end recovery (or more specifically end to end > protection), as enabled by RFC 4872. That is all the more similar because the > association mechanism is already defined in there, with a dedicated RSVP-TE > object. RFC 4872 is Standard Track: is there any rational for not considering it? > > Regards, > > Julien > > > Le 26/07/2010 18:59, Sriganesh Kini a écrit : > > FYI - These updated version of these drafts were presented today at > > IETF78. > > http://tools.ietf.org/html/draft-kini-mpls-ring-frr-facility-backup-01 > <http://tools.ietf.org/html/draft-kini-mpls-ring-frr-facility-backup-01> > > http://tools.ietf.org/html/draft-kini-mpls-fast-lsp-alert-01 > <http://tools.ietf.org/html/draft-kini-mpls-fast-lsp-alert-01> > > Thanks > > > > - Sri > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org <mailto:mpls@ietf.org> > > https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org <mailto:mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls> > _______________________________________________ > mpls mailing list > mpls@ietf.org <mailto:mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. If > you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >
- Re: [mpls] [mpls-tp] 答复: Re: Updated drafts - dra… Eric Osborne (eosborne)
- Re: [mpls] [mpls-tp] 答复: Re: Updated drafts - dra… Alexander Vainshtein