Re: [spring] Reply: Draft for Node protection of intermediate nodes in SR Paths

Shraddha Hegde <shraddha@juniper.net> Wed, 04 December 2019 14:06 UTC

Return-Path: <shraddha@juniper.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5073120839; Wed, 4 Dec 2019 06:06:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=eyRIYn8a; dkim=pass (1024-bit key) header.d=juniper.net header.b=TAOW3wxY
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 ybUzx86hsAPI; Wed, 4 Dec 2019 06:06:33 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 92952120813; Wed, 4 Dec 2019 06:06:33 -0800 (PST)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB4E1uwi006219; Wed, 4 Dec 2019 06:06:02 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=qOU2QX+Za2hWkZpvnJ/2Ka1KZQooRK0zd8FvGLGajBI=; b=eyRIYn8anejFM23Zg16e22EFZIcMQRbTrA6iFAuUCi4+5ZI/274xKKSiDdaphPY4C85s 6mEuRwf0bhX8pVfUaocvMgA3GQ9W6lY7mMScj+c2yxK0+81IqfsVBv+2HLipdylMjqcd +fJmgi3YlTxaBNAyK/zIiM3rhtf6BHSR1UJwg06wXU1F2yPfr6AK+LOtRJMK9+Mm8Nn4 l0uDliTsDFdEpdyayi0ssyc/ege8c/oXS37w5XaEv3gnSbEtQSMSf7NJi+Hoh3TbKJp9 AvBuPBCrs4aLeuktOrTGLNGKa7mu2i8syW6bvTSxUJThbCFWk9gw538yALEstn0f/1YK kA==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2102.outbound.protection.outlook.com [104.47.70.102]) by mx0b-00273201.pphosted.com with ESMTP id 2wny939cm2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Dec 2019 06:06:01 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IDIGLLttgwF4TVkE/fNJfJvQG4fJkOe9p0cNK1ZAj5VozY5VVBzXXvbW47isItp8qwp1qkxdxLEJ6zFjye5HB81GfdeHKevaQX/9uyvb+KWdOJQ56+SkfGx48mQS1SKbYkWeBomYdDXoQLnOD651nPWs1h1hSQyWKFosZsB/zCKsilZPXwarVo5wU8VQtmoW0X31chIGAy1zvA4nPFYmPYOTn9JTiLNkyxJAaM4ynFKihxRAaiyfEV+OiVR+hh/hrSsWdz06sSYZT6EQFhY3XZDJZwHpk1c88xRHgP/unFDcDDxQjX0O/RN/lj6teHKM62Nyve49HJUhcYV9W91q4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qOU2QX+Za2hWkZpvnJ/2Ka1KZQooRK0zd8FvGLGajBI=; b=DXQwNJqIOiMX0DeaHn6u3MGuDyj+iJxV8WXMI5uTGTo0jSdToWMzuiByPrwkv6Rs7wBF1nTfLSGZoOzL2MnFMudlOqK3AwQBscCTfZdUiDcfIhMslyYZjlqYop00nln7CcBUhopkDzop8oS5fL+oiWizht5JcpYr190ReHHIQCqFrHTvB/neqTWjRFfq82VMfN7pm4Bvi9IGnELSAv7XCg1axDigFFp7Fi9P4r2/ZAPgnxDmYkz4fH7n9lpInpt0WsQWKAKD8aelPx+omT/8zW/kLEjnm0CTpErdQu2Sbm0JGXnRrFoR8Kz/8gEwmLfta9xOhWpMw/v7FTo8DNONow==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qOU2QX+Za2hWkZpvnJ/2Ka1KZQooRK0zd8FvGLGajBI=; b=TAOW3wxYXVzeT6WfvJixmQDp2n/tOm4V6v9xHMdDBLKrhJroXJwt3NsFYEGM2sIhVAAp09tv5Px/JzsgL0yd9b2VN53zgK3nulbqVSVwLo2B6sLMVrKKTjBJtPjDb/anqjZTh8W9ou84vfxTOG12HNbATWmXkHACSPXX0qY/46k=
Received: from BYAPR05MB3943.namprd05.prod.outlook.com (52.135.197.146) by BYAPR05MB5941.namprd05.prod.outlook.com (20.178.51.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.3; Wed, 4 Dec 2019 14:05:58 +0000
Received: from BYAPR05MB3943.namprd05.prod.outlook.com ([fe80::d6c:bedb:6c67:8a26]) by BYAPR05MB3943.namprd05.prod.outlook.com ([fe80::d6c:bedb:6c67:8a26%6]) with mapi id 15.20.2516.003; Wed, 4 Dec 2019 14:05:58 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: Huzhibo <huzhibo@huawei.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: Reply: Draft for Node protection of intermediate nodes in SR Paths
Thread-Index: AdWhj5C+rGLfLm+dT2qnxncpj2IKRAHOjtvgAAT4uDAAc4alkA==
Date: Wed, 04 Dec 2019 14:05:58 +0000
Message-ID: <BYAPR05MB3943C640287EB92876531878D55D0@BYAPR05MB3943.namprd05.prod.outlook.com>
References: <06CF729DA0D6854E8C1E5121AC3330DFAF479346@dggemm529-mbs.china.huawei.com> <BYAPR05MB394396D8745D6606C327F79CD5430@BYAPR05MB3943.namprd05.prod.outlook.com> <06CF729DA0D6854E8C1E5121AC3330DFAF48FD73@dggemm509-mbx.china.huawei.com>
In-Reply-To: <06CF729DA0D6854E8C1E5121AC3330DFAF48FD73@dggemm509-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ActionId=3ca7a547-6378-46db-b8ab-00006cf8a8da; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ContentBits=0; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Method=Standard; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Name=Juniper Business Use Only; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SetDate=2019-12-04T14:04:48Z; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [122.171.224.167]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c1873ec2-a07e-4791-b28b-08d778c31695
x-ms-traffictypediagnostic: BYAPR05MB5941:
x-microsoft-antispam-prvs: <BYAPR05MB5941D3DB3664B0FBBEFB8BB0D55D0@BYAPR05MB5941.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0241D5F98C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(396003)(136003)(39860400002)(189003)(199004)(14454004)(6436002)(71190400001)(71200400001)(966005)(11346002)(52536014)(54896002)(6306002)(229853002)(81156014)(478600001)(9686003)(81166006)(26005)(5660300002)(7736002)(102836004)(74316002)(25786009)(8676002)(2201001)(186003)(14444005)(6246003)(86362001)(66556008)(66476007)(64756008)(2906002)(66446008)(66576008)(53546011)(6506007)(66946007)(8936002)(76116006)(316002)(110136005)(76176011)(790700001)(55016002)(3846002)(7696005)(99286004)(6116002)(33656002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5941; H:BYAPR05MB3943.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EkSsFFqV/1u1Vi5p+OekQJZuB5YDW58b93nwHrLmggR3kTSjxMZ+78mQfX3v2979xH349XG2sowUKDGKeVdfgEQHDQWeCc6tfE2gaZpYZV8hfM4tjZ/YTup44GBe94Tli9CvvgVug/aMJs5COLiHcXun4XR4dKwetx2vNVUqXFFhyDy0jjccvbams9cVLtBw4P4NXTPrZiB1Btwz5OMebkCq8syelHWdmJmcVcosCohiQDPO5gO+VFEF+vhJJ3/p0bQN03Sv20uZkn9TokOU8iqAqk1MNVhJyqzUXGjBxxKdZRQUIgFXSfYpx9E9oibbB+1Ep7tEeQD/nu31gxQNHLNzzk6e8lmk/DlsZlE0j61FUQ26RmhpMv3hFN0TxdKZvt9w1i43NnsxHUZbTrsoKJ5sIqb6YV0309NKQ5vv03+d6Owj0yjWbKU6pkM305TDyoOl14d6I/5KKlwkX9vGWJE83wKYQFOV+6gW/Yxe7NA=
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_005_BYAPR05MB3943C640287EB92876531878D55D0BYAPR05MB3943namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: c1873ec2-a07e-4791-b28b-08d778c31695
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2019 14:05:58.5361 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QfKThIRcM95b4wmZl8zftqVFtliJoRTBWLYhFQQUvi3gHBLPlY7DmKzW6qkF9Zqtq+cdHaolHK12RYgAwP/12Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5941
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-04_03:2019-12-04,2019-12-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 spamscore=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 phishscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912040116
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/nFX7EhoiQkF9nCXR4ix2qZ4m4ZE>
Subject: Re: [spring] Reply: Draft for Node protection of intermediate nodes in SR Paths
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2019 14:06:38 -0000

Huzhibo,

This is an interesting problem and thanks for bringing it up on the list.

In your topology, if B is implementing micro-loop avoidance,
then when B detects the failure of a remote node (ie. D becomes unreachable in the topology),
B may already be in one of the states below.


  1.  B has programmed pre-failure SPF path to D
  2.  B had previously detected link failure C->D and had programmed a micro-loop avoidance path for the failure
  3.  B had previously detected link failure D->E and had programmed micro-loop avoidance path for this failure



After B learns that D is  unreachable,  B could take one of the below actions:

  1.  Remove the forwarding entry for D, causing traffic for D to black-hole
  2.  If B had already programmed a micro-loop avoidance path to D,

leave the forwarding plane with this path

  1.  If B had programmed a pre-failure SPF path leave the forwarding plane with this path
  2.  Program a micro-loop avoiding path to the nearest neighbor of D


The micro-loop avoidance path need not always be a stack of adjacency sids. It is possible to
apply label stack compression and reduce the size of the label stack, so it is very much implementation dependent.
Implementations can choose to apply any of the above options.


Rgds
Shraddha

From: Huzhibo <huzhibo@huawei.com>
Sent: Monday, December 2, 2019 1:31 PM
To: Shraddha Hegde <shraddha@juniper.net>; rtgwg@ietf.org; spring@ietf.org
Subject: RE: Reply: Draft for Node protection of intermediate nodes in SR Paths

Hi Shraddha:

     Thanks for your reply, But I ca n’t fully agree it. If micro-loop avoidance is used to solve the problem. Let us consider the following scenario.
[cid:image002.png@01D5AADA.099C2C40]
Node B will send a packet with segmentlist<D,H>,When Node D is failure,Node B feel the link C->D failure first.
For Sid D, Node B converges to a new path using micro-loop avoidance.( In fact, since keep forwarding plane will not react to subsequent topology changes, you must use strict explicit paths, Otherwise, we have to solve another problem, such as calculating the Micro-microloop path for a node that has been deleted in the network).Packet will forwarding to Node E via micro-loop avoidance path,and Node E perform TE Node protection,Forward to Node H. If the topology of the micro-loop avoidance path changes again (have other redundant paths), the forwarding path will become even more unexpected. So there are at least three problems:
1:Traffic will be detoured until TE Path converges,However, in the controller calculation path scenario, TE Path convergence may take a long time.
2:    keep forwarding plane makes the network no longer have the ability to converge, unable to converge on new topological changes
3:   It need lots of label stack.

And for anycast solution,It has the Similar problem. Traffic will have long-time detours. Also deployment is too complicated.
[cid:image003.png@01D5AADA.099C2C40]

Thank you
Zhibo

From: Shraddha Hegde [mailto:shraddha@juniper.net]
Sent: Monday, December 02, 2019 12:50 PM
To: Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: Reply: Draft for Node protection of intermediate nodes in SR Paths

Hi Huzhibo,

Thanks for review and comments.

The FIB inconsistency and resulting micro-loops in IGP convergence are solved using micro-loop avoidance techniques.
The micro-loop avoidance techniques will be applied to all IGP prefixes when any change is detected.
When a node/prefix becomes unreachable, this draft recommends not to delete the state from FIB.
You bring up a good point whether micro-loop avoidance path should be applied to  this prefix or not.
I think it should. I’ll add text to clarify interaction with the micro-loop avoidance.

>And then,You say you can providing node-protection via anycast.I don`t how do you that, Any node of TE may be faulty. Do you want to
> configure the same Anycast address on the entire network?

Protection with anycast sids is explained in sec 2.2.
You do not need same anycast sid for all devices.
For ex: The nodes can be paired together and assigned one anycast SID for each pair.
Hope that clarifies.

Rgds
Shraddha

From: Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com>>
Sent: Saturday, November 23, 2019 5:20 AM
To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: Reply: Draft for Node protection of intermediate nodes in SR Paths

Hi Shraddha:

   You say can keep forwarding plane longer. I don't know which stage of the forwarding state you are maintaining. The IGP determines the node fault by sensing multiple link faults. Because the nodes are aware of the link faults in different order, the state before the forwarding entry is deleted may be looped. Do you want to keep a loop state?

  And then,You say you can providing node-protection via anycast.I don`t how do you that, Any node of TE may be faulty. Do you want to configure the same Anycast address on the entire network?

Thank you
Zhibo

发件人: rtgwg [mailto:rtgwg-bounces@ietf.org] 代表 Shraddha Hegde
发送时间: 2019年11月22日 11:38
收件人: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
主题: Draft for Node protection of intermediate nodes in SR Paths

WG,

This is the draft I pointed out that talks about solutions for providing node-protection.
It covers Anycast case as well as keeping forwarding plane longer.
https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05__;!8WoA6RjC81c!Sb-7-2B3wu3-xnhl0t1lBXUS5SiG8RhD7hocKD88lSzJhxFE03vkai9wCaS_n0Ei$>

Review and comments solicited.

Rgds
Shraddha