IETF Logo Mail Archive

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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 20 April 2018 09:00 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 0BB71126D3F for <lsr@ietfa.amsl.com>; Fri, 20 Apr 2018 02:00:36 -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 G5hnIwacHdKk for <lsr@ietfa.amsl.com>; Fri, 20 Apr 2018 02:00:32 -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 838E2126B6D for <lsr@ietf.org>; Fri, 20 Apr 2018 02:00:32 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 10C47F33ED6B6 for <lsr@ietf.org>; Fri, 20 Apr 2018 10:00:29 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 20 Apr 2018 10:00:30 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Fri, 20 Apr 2018 17:00:17 +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//+VDYCAAayAEP//1gSAgACXe1A=
Date: Fri, 20 Apr 2018 09:00:16 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927983F0926@NKGEML515-MBX.china.huawei.com>
References: <5B8EB88E-9C54-47FA-BF8A-EEB952F6C0BF@cisco.com> <76CD132C3ADEF848BD84D028D243C927983EA0E3@NKGEML515-MBX.china.huawei.com> <5AD852FD.9080301@cisco.com> <76CD132C3ADEF848BD84D028D243C927983F01BE@NKGEML515-MBX.china.huawei.com> <5AD99739.3050000@cisco.com>
In-Reply-To: <5AD99739.3050000@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/L8LD4u3X6XXlo7uGVLkabtprgWg>
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 09:00:36 -0000

Hi Peter, 

Please see inline:

> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Friday, April 20, 2018 3:31 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 20/04/18 05:04 , Dongjie (Jimmy) wrote:
> > 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?
> 
> yes
> 
> > In the latter case, it seems you would create sub-topologies on top of
> > a sub-topology (MTR) of the default topology,
> 
> no. We don't create any topologies with flex-algo. We compute constrained
> based paths.

MTR is also used to compute constrained based path:) The constraint is described as a sub-topology.

With flex-algo, you need to define the algorithm first, then the constrained path can be computed according to the algorithm. 

According to your presentation in IETF101, a flex-algo specifies: 

  a) Set of constraints - e.g affinity exclude-any, include-any, include-all
  b) Metric type - IGP metric, Delay (RFC7810), TE metric (RFC5305), ...
  c) Algorithm type - SPF, ...

As I see a) defines a constrained topology, or a sub-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?
> 
> what we propose is simple - compute multiple constrained based paths on top
> of a given topology.
> 
> What you propose is indeed complicated - create as many topologies as many
> constrained based paths you need. That solution does not scale.

Not exactly. Multiple constrained paths can be created in the same sub-topology. You don't need as many topologies as the number of paths. 

> >
> >>> 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.
> 
> then please talk to the authors of that draft.

OK. It seems some sync up is needed to have consistent understanding of what flex-algo means.

> >
> >>> 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.
> 
> orthogonal does not mean overlapping.

Right, in order to make them orthogonal, overlapping (if any) should be resolved. 

Best regards,
Jie

> 
> thanks,
> Peter
> 
> >
> > 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-alg
> >>> o/
> >>>
> >>> 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
> >>>
> >
> > .
> >

v2.23.0 | Report a Bug | By Email