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 <lsr-bounces@ietf.org> On Behalf Of Peter Psenak (ppsenak)
> Sent: Friday, April 20, 2018 2:34 AM
> 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
> 
> Dongjie,
> 
> On 20/04/18 11:00 , Dongjie (Jimmy) wrote:
> > 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.
> 
> 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: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-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
> >>>>> Lsr@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>>>
> >>>
> >>> .
> >>>
> >
> > .
> >
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr