RE: Comments on draft-li-rtgwg-enhanced-ti-lfa

"Chengli (Cheng Li)" <c.l@huawei.com> Wed, 09 December 2020 09:55 UTC

From: "Chengli (Cheng Li)" <c.l@huawei.com>
To: Shraddha Hegde <shraddha@juniper.net>, "draft-li-rtgwg-enhanced-ti-lfa@ietf.org" <draft-li-rtgwg-enhanced-ti-lfa@ietf.org>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: RE: Comments on draft-li-rtgwg-enhanced-ti-lfa
Thread-Topic: Comments on draft-li-rtgwg-enhanced-ti-lfa
Thread-Index: AdbMbu7a39xOfGpdTGKBJIQnV9rZNAAx17Lg
Date: Wed, 09 Dec 2020 09:54:40 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB02D2D149@dggeml529-mbx.china.huawei.com>
References: <CY4PR05MB357650525E127E39957F08D1D5CE0@CY4PR05MB3576.namprd05.prod.outlook.com>
In-Reply-To: <CY4PR05MB357650525E127E39957F08D1D5CE0@CY4PR05MB3576.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02D2D149dggeml529mbxchi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/RJ2q-QopoFkB3Ikc2GhrVIv7zRE>
Precedence: list

Hi Shraddha,

Many thanks for your comments! Please see my reply inline.

Thanks,
Cheng

From: Shraddha Hegde [mailto:shraddha@juniper.net]
Sent: Monday, December 7, 2020 5:18 PM
To: draft-li-rtgwg-enhanced-ti-lfa@ietf.org
Cc: rtgwg@ietf.org
Subject: Comments on draft-li-rtgwg-enhanced-ti-lfa

Authors,

Few comments below.

  1.  Abstract

TI-LFA backup path computation is always to the destination so it is less likely that a

Node that cannot be bypassed gets skipped due to TI-LFA.

The node that must be visited might get skipped due to node protection procedures that require

Next label lookup. I suggest to update the abstract as below

[Cheng] Great! Many thanks!

“
   Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims
   at providing protection of node and adjacency segments within the
   Segment Routing (SR) framework.  A key aspect of TI-LFA is the FRR
   path selection approach establishing protection over the expected
   post-convergence paths from the point of local repair.Node protection
   procedures for adjacency SIDs and immediate nexthop prefix-sids
   require the next label lookup bypassing the immediate node.
   The SIDs in the label stack may represent service instructions which
Should not be bypassed. This draft describes a mechanism to advertise
   SIDs that cannot be bypassed”

2.Introduction

“traffic engineer” Change to Traffic Engineering”

[Cheng] Ack

3.Overview of Enhanced TI-LFA

When the SR-TE path is being built, the node-sids/service sids

Used to build the path MUST use SIDs with no-bypass flag set.

The TI-LFA repair-list building procedure need not change.

It will continue to use SIDs with N bit set.

When the SR-Te label stack is built with “no bypass” SIDs,

The PLR will drop the traffic and not do any node protection procedure for the

The “no-bypass” SIDs

[Cheng] Yes， Ack.

4. Do we really need a “no bypass” flag for adj-sids?

We have the B flag which can be used

[Cheng] Good question. Does the B flag in End.X equal to No-bypass flag? When an End.X SID has a back-up SID, then what is the back-up SID? Another End.X SID originated by the same node? Or another Node SID of the node pointed by the End.X SID?  We may need to make this clear.

5. no-bypass flag in SRH

It is not clear why this is require.

The NB flag in SRV6 SIDs isn’t good enough?

Also the NB flag is generally applicable to a specific SID

And should not be a global packet level flag.

[Cheng] Personally, the NB flag in SID is good enough for me, while a flag in SRH is an optional choice as well, and it is an very easy solution. We may need this, because flag in the SID CAN NOT work if the TI-LFA computation is based on locator/prefix instead of SIDs.

Rgds

Shraddha

Juniper Business Use Only

Comments on draft-li-rtgwg-enhanced-ti-lfa Shraddha Hegde
RE: Comments on draft-li-rtgwg-enhanced-ti-lfa Chengli (Cheng Li)