Return-Path: 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 D10C13A69DB for ; Wed, 4 Aug 2010 19:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[AWL=-1.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 7oRGlooBLQV4 for ; Wed, 4 Aug 2010 19:09:29 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id A416A3A6839 for ; Wed, 4 Aug 2010 19:09:29 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o752BFnE000966; Wed, 4 Aug 2010 21:11:17 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.134]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 4 Aug 2010 22:09:56 -0400 From: Autumn Liu To: "liu.guoman@zte.com.cn" Date: Wed, 4 Aug 2010 22:09:55 -0400 Thread-Topic: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert Thread-Index: AcszhroEYX5nMgsKTwi1FE+B6TiOIwAu89XA Message-ID: <60C093A41B5E45409A19D42CF7786DFD51AE694DCF@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD51AE6468AD@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD51AE694DCFEUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 02:09:31 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD51AE694DCFEUSAACMS0703e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTGl1LA0KDQpUaGUgUlJPIGluZm9ybWF0aW9uIGlzIGV4Y2hhbmdlZCBiZWZvcmUgdGhlIGZh aWx1cmUsIGFuZCBpdCBpcyBwZXIgTFNQIGFsb25nIHdpdGggZWFjaCByZWZyZXNoIG1lc3NhZ2Uu DQpQMk1QIExTUCBwcm90ZWN0aW9uIGlzIGludGVyZXN0aW5nIHRvcGljIGFuZCB3ZSBjYW4gZGlz Y3VzcyBmdXJ0aGVyLg0KDQpSZWdhcmRzLA0KQXV0dW1uDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkZyb206IGxpdS5ndW9tYW5AenRlLmNvbS5jbiBbbWFpbHRvOmxpdS5n dW9tYW5AenRlLmNvbS5jbl0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwMywgMjAxMCA4OjM5IFBN DQpUbzogQXV0dW1uIExpdQ0KQ2M6IG1wbHNAaWV0Zi5vcmc7IG1wbHMtYm91bmNlc0BpZXRmLm9y ZzsgU3JpZ2FuZXNoIEtpbmkNClN1YmplY3Q6IFJFOiBbbXBsc10gVXBkYXRlZCBkcmFmdHMgLSBk cmFmdC1raW5pLW1wbHMtcmluZy1mcnItZmFjaWxpdHktYmFja3VwLCBkcmFmdC1raW5pLW1wbHMt ZmFzdC1sc3AtYWxlcnQNCg0KDQpBdXR1bW4NCnRoYW5rIHlvdSBmb3IgZXhwbGFpbmluZy4gYWNj b3JkaW5nIHRvIG15IHVuZGVyc3RhbmRpbmcsIHdoZW4gb25lIGxpbmsgaGF2ZSBmYWlsdXJlLCBQ TFIgbm9kZSB3aWxsIGFwcGVuZCB0byB0aGUgUFJPIG9mIHBlciBMU1Agd2hpY2ggaGF2ZSBiZWVu IGFmZmVjdGVkIGJ5IHRoZSBmYWlsdXJlIGluIHRoZQ0KQkZEIFNlc3Npb24gb2YgYmFja3VwIHR1 bm5lbCwgc28gdGhhdCBQTFItdSB3aWxsIGtub3cgd2hpY2ggTFNQIG5lZWQgdG8gc3dpdGNoIGl0 cyBvd24gZS1iYWNrdXAgdHVubmVsPyBpZiBzbyAsIGFzIFBMUiBtYXkgYmUgTUlQIG9mIHNvbWUg TFNQICwgaG93IGRvIGl0IGtub3cgUFJPIG9mIHBlciBMU1A/DQpjYW4geW91IG5lZWQgdG8gcXVl cnkgdGhlIFBSTyBvZiBwZXIgTFNQIGJ5IGNvbnRyb2wgcGxhbmU/DQppbiBhZGR0aW9uLCBmb3Ig UDJNUCAsIHdoZW4gVS1QTFIgcmVjZWl2ZWQgYWxlcnQgbWVzc2FnZSBmcm9tIFBMUiAsIFUtUExS IHNob3VsZCBtYWtlIHNlcnZpY2UgcGFja2V0IGJyaWRnZSBib3RoIHByaW1hcnkgTFNQIGFuZCBl LWJhY2t1cCB0dW5uZWwgYXQgdGhlIHNhbWUgdGltZS4gaXQgaXMgdmVyeSByYXBpZCBhbmQNCnZh bGlkIHNvbHV0aW9uLiBkbyB5b3UgdGhpbmsgc28/DQppZiB5b3UgY2FuIGJlIGludGVyZXN0ZWQg aW4gdGhlIHAybXAgcHJvdGVjdGlvbiBzb2x1dGlvbiwgd2UgbWF5IGRpc3NjdXNzIGl0IGluIGRl dGFpbCBpbiB0aGUgZm9sbG93aW5nIHRpbWUuDQoNCmJlc3QgcmVnYXJkcw0KbGl1DQoNCg0KDQoN CkF1dHVtbiBMaXUgPGF1dHVtbi5saXVAZXJpY3Nzb24uY29tPg0KDQoyMDEwLTA4LTA0IDEwOjM1 DQoNCsrVvP7Iyw0KImxpdS5ndW9tYW5AenRlLmNvbS5jbiIgPGxpdS5ndW9tYW5AenRlLmNvbS5j bj4sIFNyaWdhbmVzaCBLaW5pIDxzcmlnYW5lc2gua2luaUBlcmljc3Nvbi5jb20+DQqzrcvNDQoi bXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+LCAibXBscy1ib3VuY2VzQGlldGYub3JnIiA8 bXBscy1ib3VuY2VzQGlldGYub3JnPg0K1vfM4g0KUkU6IFttcGxzXSBVcGRhdGVkIGRyYWZ0cyAt IGRyYWZ0LWtpbmktbXBscy1yaW5nLWZyci1mYWNpbGl0eS1iYWNrdXAsIGRyYWZ0LWtpbmktbXBs cy1mYXN0LWxzcC1hbGVydA0KDQoNCg0KDQoNCkxpdSwNCg0KVGhlIHByb3Bvc2VkIFJSTyBzdWJq ZWN0IHRlbGxzIHUtUExSIG9mIHByaW1hcnkgTFNQIHdoaWNoIGJhY2t1cCBpcyBwcm90ZWN0aW5n IGl0LiBXaGVuIHRoZSBhbGVydCBtZXNzYWdlIGlzIHJlY2VpdmVkIG9uIHRoYXQgYmFja3VwLCB0 aGUgdS1QTFIgZmluZHMgb3V0IHRoZSBwcmltYXJ5IExTUCAocHJvdGVjdGVkIGJ5IHRoZSBiYWNr dXApIHRvIHN3aXRjaCB0aGUgdHJhZmZpYyBvbnRvIHRoZSBlLWJhY2t1cC4NCg0KSG9wZSB0aGlz IGdpdmVzIHlvdSB0aGUgY2xlYXIgYW5zd2VyIHRvIHlvdXIgcXVlc3Rpb24uDQoNCkF1dHVtbg0K DQoNCg0KDQoNCg== --_000_60C093A41B5E45409A19D42CF7786DFD51AE694DCFEUSAACMS0703e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Liu,
 
The RRO information is exchanged before the fail= ure,=20 and it is per LSP along with each refresh message.
P2MP LSP protection is interesting topic and we = can=20 discuss further.
 
Regards,
Autumn
 

From: liu.guoman@zte.com.cn=20 [mailto:liu.guoman@zte.com.cn]
Sent: Tuesday, August 03, 2010 8:= 39=20 PM
To: Autumn Liu
Cc: mpls@ietf.org; mpls-bounces@ietf.= org;=20 Sriganesh Kini
Subject: RE: [mpls] Updated drafts -=20 draft-kini-mpls-ring-frr-facility-backup,=20 draft-kini-mpls-fast-lsp-alert


Autumn
thank you for explaining. according to my unders= tanding,=20 when one link have failure, PLR node will append to the PRO of per LSP whic= h=20 have been affected by the failure in the
BFD Session of backup tunnel, so that PLR-u will know which LSP ne= ed to=20 switch its own e-backup tunnel? if so , as PLR may be MIP of some LSP , how= do=20 it know PRO of per LSP?
can you= need to=20 query the PRO of per LSP by control plane?
in addtion, for P2MP , when U-PLR received alert message from PLR = , U-PLR=20 should make service packet bridge both primary LSP and e-backup tunnel at t= he=20 same time. it is very rapid and
valid=20 solution. do you think so?
if y= ou can be=20 interested in the p2mp protection solution, we may disscuss it in detail in= the=20 following time.

best regard= s=20
liu




Autumn Liu=20 <autumn.liu@ericsson.com>

2010-08-04 10:35

=CA=D5=BC= =FE=C8=CB
"liu.guoman@zte.com.cn"=20 <liu.guoman@zte.com.cn>, Sriganesh Kini=20 <sriganesh.kini@ericsson.com>=20
=B3=AD=CB= =CD
"mpls@ietf.org"=20 <mpls@ietf.org>, "mpls-bounces@ietf.org"=20 <mpls-bounces@ietf.org>=20
=D6=F7=CC= =E2
RE: [mpls] Updated drafts -= =20 draft-kini-mpls-ring-frr-facility-backup,=20 draft-kini-mpls-fast-lsp-alert





Liu,
&nbs= p;=20
The proposed RRO subject tells= u-PLR of=20 primary LSP which backup is protecting it. When the alert message is receiv= ed on=20 that backup, the u-PLR finds out the primary LSP (protected by the backup) = to=20 switch the traffic onto the e-backup.
 
Hope th= is gives you=20 the clear answer to your question.
 
Autumn<= /FONT>=20
 
  

 
<= /BODY> --_000_60C093A41B5E45409A19D42CF7786DFD51AE694DCFEUSAACMS0703e_--