Hi peter:
If you think that IP and SR are two applications, which
application-specific link attributes should IP flexalgo use?
Thanks
Zhibo
-----Original Message-----
From: Peter Psenak [mailto:[email protected]]
Sent: Friday, December 11, 2020 6:11 PM
To: Huzhibo <[email protected]>; Dongjie (Jimmy) <[email protected]>; Acee
Lindem (acee) <[email protected]>; lsr <[email protected]>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Zhibo,
On 11/12/2020 11:06, Huzhibo wrote:
> Hi peter:
>
> As you said, IGP does not distinguish between IP and SR when calculating
> Algo 0. Why does Flexalgo distinguish between IP and SR Flexalgo? I think
> you're trying to explain these differences in a ambivalent way.
because FA has the concept of application and participation. That is however
not equal to dataplane type.
thanks,
Peter
>
>
> Thanks
> Zhibo
> -----Original Message-----
> From: Peter Psenak [mailto:[email protected]]
> Sent: Friday, December 11, 2020 5:59 PM
> To: Huzhibo <[email protected]>; Dongjie (Jimmy)
> <[email protected]>; Acee Lindem (acee) <[email protected]>; lsr
> <[email protected]>
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>
> Zhibo,
>
> On 11/12/2020 10:39, Huzhibo wrote:
>> Hi Peter:
>>
>> Following this approach, IP and SR Flex-Algo can also be
>> distinguished by using different FA IDs, thus there is no need to
>> treat them as separate applications, and the existing SR FAD TLV can
>> be reused? > My suggestion is to have a clear and consistent rule in
>> FA
> participation, either defining application-specific FA partifcipation for
> each data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any
> applications and simply use different FA IDs to distinguish them.
>
> you are mixing data plane consistency with FA participation. Data plane
> consistency is NOT done in IGPs for regular algo 0 calculation either.
> If you add non MPLS capable router in a middle of your MPLS network your data
> path is broken and IGPs are not going to help you to find an alternate path
> avoiding non MPLS capable router. I see no reason to do anything extra in FA
> case to avoid it.
>
> We have defined SR and IP as different applications for FA for good reason.
> Participation for IP and SR is signaled independently. I see no reason to do
> the same for every possible data plane - FA is not a data plane consistency
> check tool - same way as regular IGPs are not the one for algo 0.
>
> thanks,
> Peter
>
>
>>
>> Thanks
>> ZHibo
>> -----Original Message-----
>> From: Lsr [mailto:[email protected]] On Behalf Of Peter Psenak
>> Sent: Friday, December 11, 2020 5:13 PM
>> To: Dongjie (Jimmy) <[email protected]>; Acee Lindem (acee)
>> <[email protected]>; lsr <[email protected]>
>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>
>> Hi Jimmy,
>>
>> On 11/12/2020 09:17, Dongjie (Jimmy) wrote:
>>> Hi Peter,
>>>
>>>> -----Original Message-----
>>>> From: Peter Psenak [mailto:[email protected]]
>>>> Sent: Thursday, December 10, 2020 9:22 PM
>>>> To: Dongjie (Jimmy) <[email protected]>; Acee Lindem (acee)
>>>> <[email protected]>; lsr <[email protected]>
>>>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>>>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>>>
>>>> Hi Jimmy,
>>>>
>>>> On 10/12/2020 13:02, Dongjie (Jimmy) wrote:
>>>>> In Flex-Algo draft, it says:
>>>>>
>>>>> "Application-specific Flex-Algorithm participation advertisements
>>>>> MAY be
>>>> topology specific or MAY be topology independent, depending on the
>>>> application itself."
>>>>>
>>>>> The preassumption of current IP Flex-Algo participation is that
>>>>> one node
>>>> always participate in a Flex-Algo for both IPv4 and IPv6, and for
>>>> all the topologies it joins.
>>>>>
>>>>> I'm not saying this does not work, just want to understand the
>>>>> reason of this
>>>> design, and whether some flexibility (e.g. AF specific or topology
>>>> specific) would be useful in some cases.
>>>>>
>>>>
>>>> this was the choice of authors, because there does not seem to be a
>>>> string reason to do it per topology.
>>>>
>>>>
>>>>> BTW, a similar case is about SR-MPLS and SRv6 being treated as a
>>>>> single
>>>> application. Below is the discussion quoted from a previous mail on this
>>>> list:
>>>>>
>>>>> [Jie] OK. While the meaning of "app" here maybe a little
>>>>> vague, are
>>>> SR-MPLS and SRv6 considered the same or different apps?
>>>>>
>>>>> [Peter] These are considered as single app, and share the
>>>>> same
>>>> participation signaling. Please note that SRv6 support is signaled
>>>> independently of FA participation.
>>>>>
>>>>> Does this imply that for Flex-Algo path computation with SRv6, in
>>>>> addition to
>>>> the Flex-Algo participation information, the SRv6 support
>>>> information of nodes also needs to be considered, so that nodes
>>>> participate in this Flex-Algo but do not support SRv6 will be pruned from
>>>> the topology?
>>>>
>>>> no.
>>>
>>> Let me elaborate with an example:
>>>
>>> 20 20
>>> A------B-------C
>>> 10 | 10 | /
>>> | | / 10
>>> D------E --*
>>> 10
>>>
>>> (The metrics on the links are delay metric)
>>>
>>> - Flex-Algo 128 is defined to use delay metric for computation. This FAD is
>>> application independent, thus can be used by all applications.
>>>
>>> - All of the nodes (A, B, C, D, E) participate in FA 128.
>>>
>>> - Node A, B, C, D support both SR-MPLS and SRv6.
>>>
>>> - Node E support SR-MPLS only, it may support IPv6.
>>>
>>> Then node A computes the path to node C with FA 128. According to the
>>> computation rules of FA 128, the path would be A-D-E-C. This path can be
>>> used to send SR-MPLS packet to node C.
>>>
>>> But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the
>>> destination address, when the packet arrives at E, it will be dropped,
>>> because node E does not have the forwarding entry for C's SRv6 SID in FA
>>> 128.
>>>
>>> Do you think this is a problem?
>>>
>>> IMO this problem is due to the FA calculation is based on the combination
>>> of the constraints in FA definition, and the nodes' FA participation (which
>>> is app specific), while since SR-MPLS and SRv6 are treated as one single
>>> application, the difference in supporting SR-MPLS or SRv6 is not considered
>>> in FA calculation. This is why I asked whether the SRv6 support information
>>> also need be considered in FA calculation.
>>>
>>> To solve this problem, there are several options:
>>>
>>> Option 1: Define two different Flex-Algos for delay metric computation, one
>>> for SR-MPLS, the other one for SRv6. But this makes the FAD application
>>> dependent.
>>
>> Option 1 is the right one, given the way things are defined. And honestly I
>> do not see a need to change it.
>>
>>
>>> Option 2: Include the SR-MPLS or SRv6 information in Flex-Algo
>>> participation, i.e. make SR-MPLS and SRv6 separate applications.
>>
>> Theoretically you can make SR MPLS and SRv6 a different applications
>> using FA. Given the SR nature of both we intentionally kept them as a
>> single app from FA perspective.
>>
>>> Option 3: Also consider the SRv6 (or SR-MPLS) capability information in FA
>>> calculation.
>>
>> no. This is not being done for algo 0 either and it has nothing to do
>> with FA.
>>
>> thanks,
>> Peter
>>
>>
>>>
>>> Or do you have other options in mind?
>>>
>>> Best regards,
>>> Jie
>>>
>>>> thanks,
>>>> Peter
>>>>
>>>>
>>>>> If so, IMO this needs to be specified in the Flex-Algo draft. If
>>>>> not, please
>>>> clarify how to prune the nodes which participate in the same
>>>> Flex-Algo for SR-MPLS only? Thanks.
>>>>>
>>>>> Best regards,
>>>>> Jie
>>>
>>>
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>
>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
