Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 20 April 2018 03:05 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59977126D0C for <lsr@ietfa.amsl.com>; Thu, 19 Apr 2018 20:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 iTYJHlKxdj7y for <lsr@ietfa.amsl.com>; Thu, 19 Apr 2018 20:05:05 -0700 (PDT)
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 BE36B126C89 for <lsr@ietf.org>; Thu, 19 Apr 2018 20:05:05 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C8070B6298F31 for <lsr@ietf.org>; Fri, 20 Apr 2018 04:05:01 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 20 Apr 2018 04:05:03 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Fri, 20 Apr 2018 11:04:58 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Peter Psenak <ppsenak@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
Thread-Index: AQHT1lqU9EG8NacYPUeDduC3/EAVyaQHqLKA//+VDYCAAayAEA==
Date: Fri, 20 Apr 2018 03:04:57 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927983F01BE@NKGEML515-MBX.china.huawei.com>
References: <5B8EB88E-9C54-47FA-BF8A-EEB952F6C0BF@cisco.com> <76CD132C3ADEF848BD84D028D243C927983EA0E3@NKGEML515-MBX.china.huawei.com> <5AD852FD.9080301@cisco.com>
In-Reply-To: <5AD852FD.9080301@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.151.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/rSIto7P5-p-LkpxRIp5U_xz1wrQ>
Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2018 03:05:08 -0000

Hi Peter,

Thanks for the prompt response. Please see inline:

> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Thursday, April 19, 2018 4:28 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Acee Lindem (acee)
> <acee@cisco.com>; lsr@ietf.org
> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
> 
> Hi Dongjie,
> 
> please see inline:
> 
> On 19/04/18 09:10 , Dongjie (Jimmy) wrote:
> > Hi,
> >
> > Here are some comments on the Flex Algo drafts.
> >
> > SR algorithm as defined in draft-ietf-isis-segment-routing-extensions
> > is about the algorithm used for path calculation, such as SPF, strict SPF, etc.
> >
> > In the Flex Algo drafts, the definition of algorithm is extended to
> > include topological constraints and the metric type used in
> > calculation, which makes its functionality analogous to multi-topology routing
> (MTR).
> 
> not really. MTR is defined on a per link basis and each MTR participation needs
> to be advertised on a per link basis. There is no such concept in flex-algo draft.

Both mechanisms have the capability to define a specific sub-topology in the network, that's why I say they are analogous in functionality. Flex-algo uses link affinity to describe the constraints of the corresponding topology, which is also a link attribute and needs to be configured on a per-link basis. 

The difference is in topology advertisement. In MTR a consistent topology is constructed by each node advertising its own adjacent links in the topology. While in flex-algo, the whole topology is advertised as part of the algorithm definition by each node, and priority based selection is used to reach a consistent view by all nodes. 

> Flex-algo works on top of existing IGP topologies.
	
Do you mean flex-algo can work on top of the default IGP topology, and can also work on top of multiple IGP topologies created with MTR? In the latter case, it seems you would create sub-topologies on top of a sub-topology (MTR) of the default topology, which sounds quite complicated. Maybe another way is to use MTR to create the sub-topology needed, and define the metric type and computation algorithm using a particular flex-algo? 

> > Section 4.1 of the Flex Algo drafts says "Flex-Algorithm definition is
> > topology independent", while in some places Flex Algo is described as
> > a "light weight alternative" to MTR.
> 
> there is no mention of MTR in the document.

I was referring to another relevant draft: draft-wijnands-mpls-mldp-multi-topology-00. Sorry for the confusion caused. It seems that draft considered MTR and flex-algo as comparable candidates for creating sub-topology.

> > It would be necessary if the relationship between Flex-Algo and MTR
> > can be further clarified. Whether the two mechanisms are complementary
> > to each other, or Flex-Algo will be used to replace MTR?
> 
> they are orthogonal.

If as you said they are orthogonal, it would be better to avoid overlapping functionalities in topology definition and creation. 

Best regards,
Jie


> thanks,
> Peter
> 
> >
> > And if it is claimed that Flex-Algo is light weight than MTR, it would
> > be helpful to give a thorough comparison of the two mechanisms somewhere.
> >
> > Best regards,
> >
> > Jie
> >
> > *From:*Lsr [mailto:lsr-bounces@ietf.org] *On Behalf Of *Acee Lindem
> > (acee)
> > *Sent:* Tuesday, April 17, 2018 10:44 PM
> > *To:* lsr@ietf.org
> > *Subject:* [Lsr] LSR Working Group Adoption Poll for Flex Algorithm
> > Drafts
> >
> > This begins a two-week adoption poll for the following Flex Algorithm
> > drafts:
> >
> > https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
> >
> > https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/
> >
> > The adoption poll will end at 12:00 AM EST on May 2^nd , 2018. Please
> > indicate your support of opposition of the drafts.
> >
> > Additionally, the authors are amenable to combining the drafts into a
> > single draft. If you have an opinion, please state that as well.
> >
> > Thanks,
> >
> > Acee
> >
> >
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> >