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

[Peter Psenak <[e-mail]>]

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