Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Huaimo Chen <huaimo.chen@huawei.com> Wed, 18 December 2013 20:21 UTC

Return-Path: <huaimo.chen@huawei.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 813251AE252 for <mpls@ietfa.amsl.com>; Wed, 18 Dec 2013 12:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level:
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 J0oiOtEQ0Hht for <mpls@ietfa.amsl.com>; Wed, 18 Dec 2013 12:21:44 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB991AE269 for <mpls@ietf.org>; Wed, 18 Dec 2013 12:21:25 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBO59231; Wed, 18 Dec 2013 20:21:23 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 20:20:50 +0000
Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 20:21:22 +0000
Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.165]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 12:21:06 -0800
From: Huaimo Chen <huaimo.chen@huawei.com>
To: Yimin Shen <yshen@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection
Thread-Index: AQHO9zz2D8OUboE/BU63IW10jjHvHppYmeWwgAHOdjA=
Date: Wed, 18 Dec 2013 20:21:05 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D445C206DB@sjceml501-mbs.china.huawei.com>
References: <CAH==cJxdfio1r_v67YDURKOMM=PUufiUW0Sb6Vp_=La8hNzP8w@mail.gmail.com> <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <CAH==cJwFX=z8Gt2_OdsHpXH7H6334c8L0DAsGz9OUExYTvZTdg@mail.gmail.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <CAH==cJzv1boeOVq6=k_xHSKjkm966eum87QKK1n87Lpjd6LDAA@mail.gmail.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> <3e2e8b8ddcb54bfc9f1de747bc51efa1@BY2PR05MB728.namprd05.prod.outlook.com>
In-Reply-To: <3e2e8b8ddcb54bfc9f1de747bc51efa1@BY2PR05MB728.namprd05.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.244.77]
Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C206DBsjceml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Raveendra Torvi <rtorvi@juniper.net>
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection
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 Dec 2013 20:21:46 -0000

Hi Yimin,

Thank you for your comments!
My answers/explanations are inline below.

Best Regards,
Huaimo
From: Yimin Shen [mailto:yshen@juniper.net]
Sent: Tuesday, December 17, 2013 11:54 AM
To: Huaimo Chen; mpls@ietf.org
Cc: Raveendra Torvi
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi Huaimo,

In the traditional RSVP FRR (RFC 4090), an ingress router requests link protection, node protection and/or bandwidth protection by setting some flags in the Path message, and it's the decision of a transit router whether to actually set up FRR, based on its capability, local policy and local topology.

In this draft, the model seems completely ingress-driven. The ingress not only requests FRR, but also pushes an explicit bypass route to the PLR to force to set it up. So I have a doubt whether this is always desirable and possible? IMO, we may not assume that the ingress router can always  have the visibility of the topology of entire network (including the location of protected node, PLR and protector) and the knowledge of local policies of each PLR. For example, there are cases where a P2MP LSP needs to traverse multiple domains, some kind of topology abstraction/hiding is required between domains, and loose hop expansion has to be performed at domain boundaries.

Huaimo: An explicit bypass or backup route is not required. It is optional. The ingress router does not have  to put any explicit bypass or backup route into a Path message to be sent to the PLR.  We will revise the draft accordingly.

Thanks,

/Yimin


From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Huaimo Chen
Sent: Thursday, December 12, 2013 8:21 AM
To: mpls@ietf.org<mailto:mpls@ietf.org>
Cc: Raveendra Torvi
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

draft-chen-mpls-p2mp-egress-protection was reviewed by the MPLS Review team prior to being polled for WG adoption. The authors have updated the draft according to the comments. We have had responses from some of the reviewers that they are comfortable with how the comments have been addressed. We would like to have the same response from the other two reviewers.

Best Regards,
Huaimo