Hi Les, Thanks for your comments and analysis. Please see my replies inline:
> -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > Sent: Saturday, April 21, 2018 1:44 AM > To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Dongjie (Jimmy) > <jie.d...@huawei.com>; Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org > 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. I'm not saying algorithm and topology are interchangeable. Just want to clarify their relationship, especially the topology related part. Currently the flex-algo represents the combination of several things：topology constraint, metric type and computation algorithm. Because topology can be defined in multiple ways, I'm wondering whether flex-algo should be topology independent, i.e. just cover the metric type and algorithm. > 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. Some comparison of the two mechanisms would be needed before we can say flex-algo is more lightweight than multi-topology. With flex-algo, the topology is defined by excluding or including a set of affinities. Note that using affinity does not mean less configuration workload, as affinities also need to be configured on each link. Affinity was originally used to specify the constraints on a particular path, using affinity to specify a constraint topology is more complicated and would require more efforts in affinity planning and configuration. For example, if you want to define a particular topology which cannot be described with existing affinities, you need to introduce new affinities and configure them on each link you want to include/exclude. > 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). Defining topologies with different functionalities is one of the use cases of multi-topology. One can also define multiple topologies of IPv4. > 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. In this example, one topology which only includes the blue links needs to be defined. No matter you use it for unicast or multicast traffic, the topology would be the same. There is no additional topology needed with MT. With MTR, you need to enable MT-blue on each link you want to use. With affinity, you need to configure each link you want to include with blue color. Either the MT or the affinity information needs to be advertised in IGP. The deployment cost would be similar when you taking the affinity configuration and advertisement into account. > Much much easier to simply advertise support for a given algorithm and use it > on the topology(s) where you have a use case. Advertising the support for a given algorithm is just a subset of the deployment cost of flex-algo. The affinity planning and configuration also needs to be considered. > 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. Agree that the metric type and computation algorithm as defined in flex-algo are useful constraints and complementary to MT, while the affinity based topology constraints can also be specified using MT. Maybe it is better to separate the "topological constraints" and the "algorithm constraints". The former can be done in multiple ways and requires distributed configuration, while the latter is more like a centralized definition. Best regards, Jie > > HTH > > Les > > > > -----Original Message----- > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Peter Psenak (ppsenak) > > Sent: Friday, April 20, 2018 2:34 AM > > To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee) > > <a...@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:ppse...@cisco.com] > > >> Sent: Friday, April 20, 2018 3:31 PM > > >> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee) > > >> <a...@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:ppse...@cisco.com] > > >>>> Sent: Thursday, April 19, 2018 4:28 PM > > >>>> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee) > > >>>> <a...@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-boun...@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 _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
