Hi Jie,
On 21/04/18 05:26 , Dongjie (Jimmy) wrote:
Hi Peter,
Please see inline:
-----Original Message-----
From: Peter Psenak [mailto:[email protected]]
Sent: Friday, April 20, 2018 5:34 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
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.
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.
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.
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.
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.
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 computation algorithm used in this MT?
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
Best regards,
Jie
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
