IETF Logo Mail Archive

RE: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

Huzhibo <huzhibo@huawei.com> Thu, 23 November 2017 13:15 UTC

Return-Path: <huzhibo@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EEF128B4E for <rtgwg@ietfa.amsl.com>; Thu, 23 Nov 2017 05:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zFGPUcao2GW6 for <rtgwg@ietfa.amsl.com>; Thu, 23 Nov 2017 05:15:55 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE17C12426E for <rtgwg@ietf.org>; Thu, 23 Nov 2017 05:15:54 -0800 (PST)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9CAB5B831920B for <rtgwg@ietf.org>; Thu, 23 Nov 2017 13:15:51 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 23 Nov 2017 13:15:52 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Thu, 23 Nov 2017 21:15:46 +0800
From: Huzhibo <huzhibo@huawei.com>
To: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>, "sasha@axerra.com" <sasha@axerra.com>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: RE: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)
Thread-Topic: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)
Thread-Index: AdNkXR1Rmxh9aprlSA6OxqNUFFEo/A==
Date: Thu, 23 Nov 2017 13:15:45 +0000
Message-ID: <06CF729DA0D6854E8C1E5121AC3330DF9E062994@NKGEML515-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.219.232]
Content-Type: multipart/alternative; boundary="_000_06CF729DA0D6854E8C1E5121AC3330DF9E062994NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/33wHpY0MZLl5vebRlEIN3UXlGBE>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Nov 2017 13:15:57 -0000

Because the normal FRR can not protect the designated node of SR-TE, a method is provided to perform the label POP action by the penultimate hop of the specified node replacing the specified node and forward it to the node corresponding to the next label. However, Here are some questions we can discuss, if it is a loose path, SR-TE designated node failure, the packet can not be forwarded to the penultimate hop of the specified node.

发件人: rtgwg [mailto:rtgwg-bounces@ietf.org] 代表 Muthu Arul Mozhi Perumal
发送时间: 2017年11月23日 21:04
收件人: sasha@axerra.com
抄送: rtgwg@ietf.org
主题: Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

My understanding is that draft wants to provide a solution for the problem where the active segment is a prefix/adjacency segment of the neighbor and the neighbor fails. A solution to this is possible only at a node that is enforcing the SR policy (consisting of the segment list). For a transit node, its data plane would have to peek into the label stack and determine the type of the segment/label following the active segment and act accordingly, which is not inline with the SR architecture which requires SR to work 'as is' on traditional MPLS data plane

​Muthu​

On Wed, Nov 22, 2017 at 8:22 PM, Alexander Vainshtein <vinesasha@yahoo.com<mailto:vinesasha@yahoo.com>> wrote:
Muthu and all,
I do not see how the draft in quesrion us related to "SR Policy".

From my POV its scope is a SR LSP comprised of multiple Node SIDs within a single IGP domain, and it provides local fast protection against failure of a node that terminates one of the segments comprising this LSP. Pritection action is performed by the penultimate node.

My 2c.
Sent from Yahoo Mail on Android<https://overview.mail.yahoo.com/mobile/?.src=Android>

On Wed, Nov 22, 2017 at 3:27, Muthu Arul Mozhi Perumal
<muthu.arul@gmail.com<mailto:muthu.arul@gmail.com>> wrote:
Section 5.3 of draft-bashandy-rtgwg-segment-routing-ti-lfa describes protecting SR policy midpoints against node failure for the case where the active segment is the prefix or adjacency segment of a neighbor.

I believe the steps described in the procedure is applicable only for a node steering packets into the SR policy. This could be an ingress PE steering IP packets into a SR-TE tunnel or an intermediate node steering labeled packets received with a BSID into a SR-TE tunnel identified by that BSID.

A transit node that has no idea about the SR policy itself is not expected to perform the procedure described in that section.

Is my understanding correct?

Regards,
Muthu
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg

v2.23.0 | Report a Bug | By Email