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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 Apr 2018 14:44:25 +0000

This begins a two-week adoption poll for the following Flex Algorithm drafts:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

The adoption poll will end at 12:00 AM EST on May 2nd, 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

---

From: Peter Psenak <[email-masked]>
Date: Tue, 17 Apr 2018 16:56:13 +0200

Support as coauthor on both drafts.

thanks,
Peter

On 17/04/18 16:44 , Acee Lindem (acee) wrote:
> 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-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 17 Apr 2018 15:01:34 +0000

Support.

I am open to combining into one draft so long as the authors feel comfortable that they can easily minimize the protocol specific text.

   Les

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Tuesday, April 17, 2018 7:44 AM
To: [email-masked]
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 Apr 2018 15:23:38 +0000

Speaking as WG member, I support draft adoption. It was being presented at 2 IETFs and it is one of the more exciting developments in LSR (I’m sure there are other WGs that are feeling insecure based on the power and flexibility of this enhancement ;^).

Speaking as WG Co-Chair – I think it would be great to combine the drafts. The normative sections on SPF computation are common to both OSPF and IS-IS.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Acee Lindem <[email-masked]>
Date: Tuesday, April 17, 2018 at 10:44 AM
To: "[email-masked]" <[email-masked]>
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

Thanks,
Acee

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 17 Apr 2018 15:29:16 +0000

Support.

Best Regards,
Huaimo
From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, April 17, 2018 11:24 AM
To: [email-masked]
Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Acee Lindem <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 17, 2018 at 10:44 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

Thanks,
Acee

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 17 Apr 2018 15:30:36 +0000

Support .

Sent from my iPhone

On Apr 17, 2018, at 07:44, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Acee

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: <[email-masked]>
Date: Tue, 17 Apr 2018 15:36:42 +0000

+1
(I guess you meant :s/LSR/SR   ;-) )

Thanks
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, April 17, 2018 5:24 PM
To: [email-masked]
Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

Thanks,
Acee

Thanks,
Acee

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 17 Apr 2018 15:51:49 +0000

Support as co-author and also support combining the OSPF and ISIS aspects in a single draft.

Thanks,
Ketan

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: 17 April 2018 20:14
To: [email-masked]
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

Thanks,
Acee

---

From: "Stefano Previdi (IETF)" <[email-masked]>
Date: Tue, 17 Apr 2018 17:18:45 +0000

I support both drafts.

Thanks.

s.

On Tue, Apr 17, 2018, 4:44 PM Acee Lindem (acee) <[email-masked]> wrote:

> The adoption poll will end at 12:00 AM EST on May 2nd, 2018. Please

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 Apr 2018 17:33:01 +0000

No. However, the one that initially came to mind has had ownership discussions with SR…
Thanks,
Acee

From: Bruno Decraene <[email-masked]>
Date: Tuesday, April 17, 2018 at 11:36 AM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

+1

Thanks
--Bruno

Thanks,
Acee

Thanks,
Acee

Thank you.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 18 Apr 2018 13:48:50 +0000

Support.

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Tuesday, April 17, 2018 10:44 AM
To: [email-masked]
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhegdeppsenak-2Disis-2Dsr-2Dflex-2Dalgo_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=Cmz-QHrU8dMez4i9-oDwxP-zeWwOQ20bcqGUiCboSrg&s=6aEhIv5x0kfCWtn_Bp-OWX8cH-GZYQmSXGYAVLqdEsc&e=>
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dppsenak-2Dospf-2Dsr-2Dflex-2Dalgo_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=Cmz-QHrU8dMez4i9-oDwxP-zeWwOQ20bcqGUiCboSrg&s=Y9hxJ4s5HrBWslLFjFeMt3XpZQHG3o-CnpqnNxVzF78&e=>

Thanks,
Acee

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 18 Apr 2018 14:33:44 +0000

Support for both,

Thanks

Regards … Zafar

From: Lsr <[email-masked]> on behalf of "Acee Lindem (acee)" <[email-masked]>
Date: Tuesday, April 17, 2018 at 10:44 AM
To: "[email-masked]" <[email-masked]>
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

Thanks,
Acee

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 19 Apr 2018 07:10:53 +0000

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).

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.

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?

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-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, April 17, 2018 10:44 PM
To: [email-masked]
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 19 Apr 2018 10:27:41 +0200

Hi Dongjie,

please see inline:

On 19/04/18 09:10 , Dongjie (Jimmy) wrote:
> 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. Flex-algo works on top of existing IGP 
topologies.

>
> 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.

>
> 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.

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-masked]] *On Behalf Of *Acee Lindem (acee)
> *Sent:* Tuesday, April 17, 2018 10:44 PM
> *To:* [email-masked]
> *Subject:* [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 20 Apr 2018 03:04:57 +0000

Hi Peter,

Thanks for the prompt response. Please see inline:

> -----Original Message-----
> From: Peter Psenak [mailto:[email-masked]]
> Sent: Thursday, April 19, 2018 4:28 PM
> To: Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee)
> <[email-masked]>; [email-masked]
> > 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.
> >
> > 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? In the latter case, it seems you would create sub-topologies on top of a sub-topology (MTR) of the default 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? 

> > topology independent", while in some places Flex Algo is described as
> > a "light weight alternative" to MTR.
> 

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.

> > 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. 

Best regards,
Jie

---

From: Peter Psenak <[email-masked]>
Date: Fri, 20 Apr 2018 09:31:05 +0200

Hi Dongjie,

please see inline:

On 20/04/18 05:04 , Dongjie (Jimmy) wrote:
> 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.

> 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.

> 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…

then please talk to the authors of that draft.

> 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.

thanks,
Peter

> .

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 20 Apr 2018 09:00:16 +0000

Hi Peter, 

Please see inline:

> Sent: Friday, April 20, 2018 3:31 PM
> >>> SR algorithm as defined in
> >>> draft-ietf-isis-segment-routing-extensions
> >> 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.
> >
> > 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.
> >>
> > 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.
> 

OK. It seems some sync up is needed to have consistent understanding of what flex-algo means.

> >>> 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.
> 

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
> >>>
> >>> This begins a two-week adoption poll for the following Flex
> >>> Algorithm
> >>> drafts:
> >>>
> >>> 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
> >>>
> >>>
> >>>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 20 Apr 2018 11:33:51 +0200

Dongjie,

> 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.

> 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.

> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 20 Apr 2018 10:57:33 +0000

Hi Jie, Peter, 

Another difference with Multiple Topology Router (MTR) is that it implies the abstraction of a RIB per topology so you could have multiple routes to the same prefix dependent on criteria other than longest prefix matching (e.g., ingress interface). The authors can correct me if I'm wrong, but I don't believe Flex Algorithm requires this abstraction. 

Thanks,
Acee

On 4/20/18, 5:33 AM, "Peter Psenak (ppsenak)" <[email-masked]> wrote:

    Dongjie,

    

    
    
    regards,
    Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 20 Apr 2018 17:44:16 +0000

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

> From: Lsr <[email-masked]> On Behalf Of Peter Psenak (ppsenak)
> Sent: Friday, April 20, 2018 2:34 AM
> >>>>> In the Flex Algo drafts, the definition of algorithm is extended
> >>>>> to include topological constraints and the metric type used in
> >> 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.
> >>>
> >> 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.
> >>>
> >>> In the latter case, it seems you would create sub-topologies on top
> >>> of a sub-topology (MTR) of the default 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.
> >
> again, you are mixing "set of constraints" with a "topology", these are two
> different things.
> 
> >
> >> what we propose is simple - compute multiple constrained based paths
> >> on top of a given topology.
> >>
> > 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.
> >>>>
> >> 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.
> >>
> >>>>> It would be necessary if the relationship between Flex-Algo and
> >>>>> MTR can be further clarified. Whether the two mechanisms are
> >>>>> *From:*Lsr [mailto:[email-masked]] *On Behalf Of *Acee
> >>>>> Lindem
> >>>>> (acee)
> >>>>> https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-a
> >>>>> lg
> >>>>> o/
> >>>>>
> >>>>> 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
> >>>>>
> >>>>>
> >>>>>

---

From: Mach Chen <[email-masked]>
Date: Sat, 21 Apr 2018 02:42:03 +0000

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 

> From: Lsr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Saturday, April 21, 2018 1:44 AM
> To: Peter Psenak (ppsenak) <[email-masked]>; Dongjie (Jimmy)
> <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
> 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.
> 
> Today, topologies are most commonly used to define a set of nodes/links which
> support a particular functionality (e.g., IPv4, IPv6, multicast).
> 
> 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.
> 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
> 
> 
> > >>>>> is about the algorithm used for path calculation, such as SPF,
> > >>>>> strict SPF,
> > etc.
> > >>>>>
> > >>> In the latter case, it seems you would create sub-topologies on
> > >>> top of a sub-topology (MTR) of the default topology,
> > >>
> > > MTR is also used to compute constrained based path:) The constraint
> > > is
> > described as a sub-topology.
> >
> > again, you are mixing "set of constraints" with a "topology", these
> > >> 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.
> > >
> > 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
> >
> > >
> > >>>
> > > OK. It seems some sync up is needed to have consistent understanding
> > > of
> > what flex-algo means.
> > >
> > >>>
> > >>>>> complementary to each other, or Flex-Algo will be used to
> > >>>>> replace
> > MTR?
> > >>>>
> > >>>> they are orthogonal.
> > >>>
> > > Right, in order to make them orthogonal, overlapping (if any) should
> > > be
> > resolved.
> > >
> > > Best regards,
> > > Jie
> > >
> > >>
> > >> thanks,
> > >> Peter
> > >>
> > >>>
> > >>> Best regards,
> > >>> Jie
> > >>>
> > >>>
> > >>>> thanks,
> > >>>> Peter
> > >>>>
> > >>>>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 21 Apr 2018 03:26:53 +0000

Hi Peter, 

Please see inline:

> Sent: Friday, April 20, 2018 5:34 PM

As I mentioned in previous mail, there are two steps: 

1. Define a particular topology or topological constraints.
2. Perform path computation using specific metric type and computation algorithm (currently SPF).

IMO these two steps can be orthogonal to each other. The topology can be defined using either MTR or link affinities. IMO they provide the same functionality with similar cost. Note that using affinity does not mean less configuration workload, as affinity also needs to be configured on each link. If you want to define a particular topology (topological constraint), you probably need to introduce new affinities and configure them on the links you want to include.

To me it makes more sense to decouple step 1 and step2, and only use flex-algo to cover the step 2. For example, flex-algo 1 can be defined as "using SPF computation with latency metric". This way, this flex-algo can be reused in different topologies. Also multiple flex-algos can be used in one topology. So it would be more flexible than binding a flex-algo with particular topological constraints.

> again, you are mixing "set of constraints" with a "topology", these are two

As I mentioned above, what I mean is 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.

> > 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.
> 

That's why in the beginning I want to confirm whether flex-algo can be used with MT. 

But within an MT, I'm not sure whether topological constraint should be further specified using the mechanism defined in flex-algo. Maybe only use flex-algo to define the metric type and computation algorithm used in this MT?

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 21 Apr 2018 03:42:46 +0000

Hi Acee, 

Thanks for your comments. 

I guess you are referring to a particular usage of MTR, when multiple topologies have different routes to the same prefix, with IP forwarding some additional mechanism is needed to match the traffic to particular topology. This can be solved with SR forwarding (using per-topology SID).

Flex-algo also allows multiple routes to the same prefix, and uses different prefix-SIDs in the SR forwarding. 

Best regards,
Jie

> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: Friday, April 20, 2018 6:58 PM
> <[email-masked]>; [email-masked]
> Another difference with Multiple Topology Router (MTR) is that it implies the
> abstraction of a RIB per topology so you could have multiple routes to the same
> prefix dependent on criteria other than longest prefix matching (e.g., ingress
> interface). The authors can correct me if I'm wrong, but I don't believe Flex
> Algorithm requires this abstraction.
> 
> Thanks,
> Acee
> 
> 
> such
> algorithm
> constrained
>     > With flex-algo, you need to define the algorithm first, then the
> constrained path can be computed according to the algorithm.
>     >
> many
> caused. It
> of what flex-algo means.
> MTR

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 21 Apr 2018 08:03:56 +0000

Hi Les, 

Thanks for your comments and analysis. Please see my replies inline:

> From: Les Ginsberg (ginsberg) [mailto:[email-masked]]

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. 

> 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. 

> 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.

> 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.

> 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.

> 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

> > > sub-

---

From: Peter Psenak <[email-masked]>
Date: Sun, 22 Apr 2018 21:26:32 +0200

Hi Jie,

> That's why in the beginning I want to confirm whether flex-algo can be used with MT.

yes, it can be used with MT.

> But within an MT, I'm not sure whether topological constraint should be further specified using the mechanism defined in flex-algo. Maybe only use flex-algo to define the metric type and computatio…

in your mind you are still mixing the topology with constraints. We do 
not want to use MT to define constraints. We want to use flex-algo to 
represents the constraints.

thanks,
Peter