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:ppse...@cisco.com] 
Sent: Friday, December 11, 2020 6:11 PM
To: Huzhibo <huzh...@huawei.com>; Dongjie (Jimmy) <jie.d...@huawei.com>; Acee 
Lindem (acee) <a...@cisco.com>; lsr <lsr@ietf.org>
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:ppse...@cisco.com]
> Sent: Friday, December 11, 2020 5:59 PM
> To: Huzhibo <huzh...@huawei.com>; Dongjie (Jimmy) 
> <jie.d...@huawei.com>; Acee Lindem (acee) <a...@cisco.com>; lsr 
> <lsr@ietf.org>
> 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:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Friday, December 11, 2020 5:13 PM
>> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee) 
>> <acee=40cisco....@dmarc.ietf.org>; lsr <lsr@ietf.org>
>> 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:ppse...@cisco.com]
>>>> Sent: Thursday, December 10, 2020 9:22 PM
>>>> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee) 
>>>> <acee=40cisco....@dmarc.ietf.org>; lsr <lsr@ietf.org>
>>>> 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
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>
> 
> 
> 

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to