Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Huzhibo <huzhibo@huawei.com> Fri, 11 December 2020 10:07 UTC

Return-Path: <huzhibo@huawei.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1C63A08BD for <lsr@ietfa.amsl.com>; Fri, 11 Dec 2020 02:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v0sp2uH_dG7 for <lsr@ietfa.amsl.com>; Fri, 11 Dec 2020 02:07:04 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA363A0896 for <lsr@ietf.org>; Fri, 11 Dec 2020 02:07:04 -0800 (PST)
Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Csmby2nCFz67PK9 for <lsr@ietf.org>; Fri, 11 Dec 2020 18:04:46 +0800 (CST)
Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Fri, 11 Dec 2020 11:06:54 +0100
Received: from dggema769-chm.china.huawei.com (10.1.198.211) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 11 Dec 2020 18:06:52 +0800
Received: from dggema769-chm.china.huawei.com ([10.9.128.71]) by dggema769-chm.china.huawei.com ([10.9.128.71]) with mapi id 15.01.1913.007; Fri, 11 Dec 2020 18:06:52 +0800
From: Huzhibo <huzhibo@huawei.com>
To: Peter Psenak <ppsenak@cisco.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Acee Lindem (acee)" <acee@cisco.com>, lsr <lsr@ietf.org>
Thread-Topic: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Thread-Index: AQHWyCa69SgvuXvqQUSruOMjcUOnRanukOqg//+JYYCAAJ+NMP//h7yAgACWrCCAALhHgIAAjD2w//+7mIAANZ9iQP//n+8A//91SPCAAJdkgP//d9fQ
Date: Fri, 11 Dec 2020 10:06:52 +0000
Message-ID: <1cfa751cd9cf4ef291eb1fc2a40e437d@huawei.com>
References: <777B2AC4-CACF-4AB0-BFC7-B0CFFA881EEB@cisco.com> <169b063524dc4420b37016d2428fc85c@huawei.com> <29d3d16a-237d-e657-e84c-c74a1e5a841f@cisco.com> <c779c9da19264b718effd3d0442c8616@huawei.com> <8024148b-df7d-d79f-26b6-c64b9113cd9e@cisco.com> <64d017200b9f449fb5866729c71af221@huawei.com> <ee59964d-1e9d-233a-254e-37f6141a9add@cisco.com> <db0277d7891a45d6917e84a219b880a3@huawei.com> <c4d73cb1-8262-ee4e-5a7c-6a960b312b9f@cisco.com> <0d0797da3c8648d0bb3fcf7dcb9b8034@huawei.com> <45fe9e1f-1e7d-afc7-daf2-d9b386b01fb3@cisco.com> <38ccd154ad694230a9b36d7cf5c05ad4@huawei.com> <f9ce2ae4-745f-d134-642a-877496bae714@cisco.com>
In-Reply-To: <f9ce2ae4-745f-d134-642a-877496bae714@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.201.204]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/NcqTg1IkMRoQBOK3_1LgpiYWA4s>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2020 10:07:06 -0000

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.


Thanks
Zhibo
-----Original Message-----
From: Peter Psenak [mailto:ppsenak@cisco.com] 
Sent: Friday, December 11, 2020 5:59 PM
To: Huzhibo <huzhibo@huawei.com>; Dongjie (Jimmy) <jie.dong@huawei.com>; Acee Lindem (acee) <acee@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-bounces@ietf.org] On Behalf Of Peter Psenak
> Sent: Friday, December 11, 2020 5:13 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Acee Lindem (acee) 
> <acee=40cisco.com@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:ppsenak@cisco.com]
>>> Sent: Thursday, December 10, 2020 9:22 PM
>>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Acee Lindem (acee) 
>>> <acee=40cisco.com@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
> 
>