Hi Les, Jie and others, I think both Flex Algo and MTR are useful and have their own use cases. And actually Flex Algo and MTR could be complementary each other.
As Les said, flex-algorithm calculates paths on a specific topology (default, blue, green...). So, it implies that the precondition is that there should be a topology. The topology can be the default IGP topology, or a customized topology created by MTR or flex-algorithm. There may be different understandings about the topology creation, but it's not that important, IMHO. To "create/form" the topology, both MTR and flex-algorithm need to do some planning and configurations. Best regards, Mach > -----Original Message----- > From: Lsr [mailto:[email protected]] On Behalf Of Les Ginsberg (ginsberg) > Sent: Saturday, April 21, 2018 1:44 AM > To: Peter Psenak (ppsenak) <[email protected]>; Dongjie (Jimmy) > <[email protected]>; Acee Lindem (acee) <[email protected]>; [email protected] > Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts > > Jie - > > I strongly agree with Peter here. > > It is "tempting" to think of algorithm/topology as interchangeable - but I > think it > is wrong to do so. > It is true that some things achievable via flex-algo could be achieved using a > separate topology - but at a much higher deployment cost and with > considerably less flexibility. > > The "right way" to think of flex-algo is as a constraint based SPF applied to > a > given topology. > > Today, topologies are most commonly used to define a set of nodes/links which > support a particular functionality (e.g., IPv4, IPv6, multicast). > > To take a simple example, if a given flex-algorithm is defined to prefer > "blue" > links one could: > > 1)Calculate shortest path using only blue links on a unicast topology. Result > would be used to forward a certain class of unicast traffic. > > 2)Calculate shortest path using only blue links on a multicast topology. > Result > would be used to build an RPF tree for some subset of multicast traffic. > > Could you do this purely with MT? Yes - but it would require introducing two > new topologies (blue unicast, blue multicast), advertising additional topology > specific support per adjacency, and configuring additional topology support > per > link on every router in the network which participates in the new topologies. > And if you wanted to prefer green links for another use case, you would then > have to introduce two more topologies. > Much much easier to simply advertise support for a given algorithm and use it > on the topology(s) where you have a use case. > > And this example is a very simple one. Flex-algo supports multiple constraints > besides affinity - so the scalability of using a separate topology for each > set of > constraints is extremely poor. > > HTH > > Les > > > > -----Original Message----- > > From: Lsr <[email protected]> On Behalf Of Peter Psenak (ppsenak) > > Sent: Friday, April 20, 2018 2:34 AM > > To: Dongjie (Jimmy) <[email protected]>; Acee Lindem (acee) > > <[email protected]>; [email protected] > > Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm > > Drafts > > > > Dongjie, > > > > On 20/04/18 11:00 , Dongjie (Jimmy) wrote: > > > 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. > > > > you are mixing two different things - topology and path computations, > > these are two different things. > > > > > > > > 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. > > > > again, you are mixing "set of constraints" with a "topology", these > > are two different things. > > > > > > > >>> 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. > > > > if you calculate multiple constrained paths on a single MT, you need > > to agree what the constraints are for each calculation and that is > > what the flex-algo draft is doing. > > > > regards, > > Peter > > > > > > > >>> > > >>>>> 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 > > >>>>> -a > > >>>>> lg > > >>>>> 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 > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
