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

[Mach Chen <[e-mail]>]

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:[e-mail]] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Saturday, April 21, 2018 1:44 AM
> To: Peter Psenak (ppsenak) <[e-mail]>; Dongjie (Jimmy)
> <[e-mail]>; Acee Lindem (acee) <[e-mail]>; [e-mail]
> 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 <[e-mail]> On Behalf Of Peter Psenak (ppsenak)
> > Sent: Friday, April 20, 2018 2:34 AM
> > To: Dongjie (Jimmy) <[e-mail]>; Acee Lindem (acee)
> > <[e-mail]>; [e-mail]
> > 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:[e-mail]]
> > >> Sent: Friday, April 20, 2018 3:31 PM
> > >> To: Dongjie (Jimmy) <[e-mail]>; Acee Lindem (acee)
> > >> <[e-mail]>; [e-mail]
> > >> 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:[e-mail]]
> > >>>> Sent: Thursday, April 19, 2018 4:28 PM
> > >>>> To: Dongjie (Jimmy) <[e-mail]>; Acee Lindem (acee)
> > >>>> <[e-mail]>; [e-mail]
> > >>>> 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:[e-mail]] *On Behalf Of *Acee
> > >>>>> Lindem
> > >>>>> (acee)
> > >>>>> *Sent:* Tuesday, April 17, 2018 10:44 PM
> > >>>>> *To:* [e-mail]
> > >>>>> *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
> > >>>>> [e-mail]
> > >>>>> https://www.ietf.org/mailman/listinfo/lsr
> > >>>>>
> > >>>
> > >>> .
> > >>>
> > >
> > > .
> > >
> >
> > _______________________________________________
> > Lsr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lsr
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr