Hi Peter, Please see inline:
> -----Original Message----- > From: Peter Psenak [mailto:[email protected]] > Sent: Friday, April 20, 2018 3:31 PM > To: Dongjie (Jimmy) <[email protected]>; Acee Lindem (acee) > <[email protected]>; [email protected] > 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:[email protected]] > >> Sent: Thursday, April 19, 2018 4:28 PM > >> To: Dongjie (Jimmy) <[email protected]>; Acee Lindem (acee) > >> <[email protected]>; [email protected] > >> 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:[email protected]] *On Behalf Of *Acee Lindem > >>> (acee) > >>> *Sent:* Tuesday, April 17, 2018 10:44 PM > >>> *To:* [email protected] > >>> *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 > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/lsr > >>> > > > > . > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
