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

Peter Psenak <ppsenak@cisco.com> Thu, 10 December 2020 08:57 UTC

Return-Path: <ppsenak@cisco.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 997BF3A0B3B for <lsr@ietfa.amsl.com>; Thu, 10 Dec 2020 00:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 3fBeCbPDIpOS for <lsr@ietfa.amsl.com>; Thu, 10 Dec 2020 00:57:44 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610D93A0B37 for <lsr@ietf.org>; Thu, 10 Dec 2020 00:57:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7039; q=dns/txt; s=iport; t=1607590664; x=1608800264; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=zNvGbhzRtkiNCsK90qOS0w6MnSWO4leSRK32bMcQlo8=; b=eMgkA6C0qQ/ZhsoPZQXe3R7nk7HiZyNmEWUaruHqiYXH65vXpPT0uKUd chuqD5rUJk0pHmJ1ZpoO919e4hqRA1TXCqwEynVKvSTKPiY/hz6iitk82 z0KSxfy03+AOwvnN9/y817Cbvm4wVFbFquWhjInItelt2ywmuOQhYRfZU U=;
X-IPAS-Result: =?us-ascii?q?A0BjAQCt4dFflxbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DH1cBIBIuhD+JBId5LQOCcIcokhsLAQEBDxgLDAQBAYRKAoIAJjgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGNgyFcgEBAQQBARsGDwEFNhcEC?= =?us-ascii?q?QIRAwEBAQECAh8EAwICJx8JCAYBDAYCAQGDIgGCVQMuD5FtmxJ2gTKFV4Mug?= =?us-ascii?q?TwGgQ4qhVpOhzaBQT+BESeCcT6CG0IBAQKBOwEBgzeCXwSBVRBMdg0iJFcDC?= =?us-ascii?q?zErGQE0kAynWVeCfoMjkwWFDgUHAx+DJYolhS2PQoYTjWmOAo5OhHuBbSGBW?= =?us-ascii?q?TMaCBsVO4JpUBkNji0OCRSIToVFQAMwAjUCBgEJAQEDCYpWAQE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,407,1599523200"; d="scan'208";a="31792960"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2020 08:57:40 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 0BA8vdhW000647; Thu, 10 Dec 2020 08:57:39 GMT
To: "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, lsr <lsr@ietf.org>
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> <MEYP282MB2022B32F7AC9A761DF4769FFFCCB0@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <2f30d00a-b994-91eb-e447-e81642cb0a66@cisco.com>
Date: Thu, 10 Dec 2020 09:57:39 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <MEYP282MB2022B32F7AC9A761DF4769FFFCCB0@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/yAqqE62UgTMxR3aKFE_7mf77X_M>
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: Thu, 10 Dec 2020 08:57:47 -0000

Zhenqiang,

On 10/12/2020 05:03, li_zhenqiang@hotmail.com wrote:
> Hello Peter,
> 
> follow-up questions with [Zhenqiang].
> 
> FA calculation is done for every MT topology independently.
> For IPv4 it will take all routers participating in MT0 and run the FA
> calculation on top of MT0.
> For IPv6 it will take all routers participating in MT2 and run the FA
> calculation on top of MT2.
> 
> [Zhenqiang] Could you please elaborate this explicitly in the draft? For 
> example, in section 7, replace the setence "IP Flex-Algorithm 
> application only considers participating nodes during the Flex-Algorithm 
> calculation" with "IP Flex-Algorithm application only considers 
> participating nodes within the same MTID during the Flex-Algorithm 
> calculation".

FA does not changing the way SPFs and route calculations are done for 
each MT. We are only adding FA constraints to existing MT calculations.

thanks,
Peter



> 
> [Zhenqiang]Since paths for IP flex-algo are calculated within specific 
> MT, I think one new top-level TLV for ISIS is enough to advertise prefix 
> reachability associated with a Flex-Algorithm, that is the one defined 
> in section 6.1. MTID can be used to indicate it is for IPv4 or IPv6.
> 
> Best Regards,
> Zhenqiang Li
> ------------------------------------------------------------------------
> li_zhenqiang@hotmail.com
> 
>     *From:* Peter Psenak <mailto:ppsenak=40cisco.com@dmarc.ietf.org>
>     *Date:* 2020-12-09 21:05
>     *To:* Dongjie (Jimmy) <mailto:jie.dong@huawei.com>; Acee Lindem
>     (acee) <mailto:acee=40cisco.com@dmarc.ietf.org>; lsr
>     <mailto: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 09/12/2020 13:52, Dongjie (Jimmy) wrote:
>      > Hi Peter,
>      >
>      >> -----Original Message-----
>      >> From: Peter Psenak [mailto:ppsenak@cisco.com]
>      >> Sent: Wednesday, December 9, 2020 6:45 PM
>      >> To: Dongjie (Jimmy) <jie.dong@huawei.com>om>; Acee Lindem (acee)
>      >> <acee=40cisco.com@dmarc.ietf.org>rg>; 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
>      >>
>      >> Jimmy,
>      >>
>      >> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
>      >>> Hi authors,
>      >>>
>      >>> Here is one comment following the previous discussion on the
>     mail list
>      >>> and the IETF meeting.
>      >>>
>      >>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
>      >>> participation information, there is no separate TLV for IPv4 or
>     IPv6
>      >>> Flex-Algo participation.
>      >>
>      >> the draft clearly says:
>      >>
>      >>      "The IP Flex-Algorithm participation advertised in ISIS IP
>     Algorithm
>      >>      Sub-TLV is topology independent."
>      >
>      > This does not answer my question.
>      >
>      > Section 7 gives the rules of IP Flex-Algo Path calculation:
>      >
>      > " IP Flex-Algorithm application only considers participating
>     nodes during the Flex-Algorithm calculation.  When computing paths
>     for a given Flex-Algorithm, all nodes that do not advertise
>     participation for IP Flex-Algorithm, as described in Section 5, MUST
>     be pruned from the topology."
>      >
>      >>From IP Algorithm TLV, one cannot tell whether a node
>     participates in Flex-Algo 128 for IPv4, IPv6 or both. This would
>     cause the problem described below: >
>      > When one node uses IP Flex-Algo participation to compute a path
>     for an IPv6 address advertised with Flex-Algo 128, it will not prune
>     the nodes which participate in Flex-Algo 128 for IPv4 only from the
>     topology. Thus IPv6 packets following that path may get dropped on
>     nodes which participates in Flex-Algo 128 for IPv4 only.
>     FA calculation is done for every MT topology independently.
>     For IPv4 it will take all routers participating in MT0 and run the FA
>     calculation on top of MT0.
>     For IPv6 it will take all routers participating in MT2 and run the FA
>     calculation on top of MT2.
>      >
>      >>
>      >>> If some nodes participate in IPv4 Flex-Algo 128, and some of these
>      >>> nodes participate in IPv6 Flex-Algo 128, how to ensure that the
>     path
>      >>> computed for IPv6 Flex-Algo will not use the nodes which only
>      >>> participate in IPv4 Flex-Algo 128?
>      >>
>      >> there is no such thing as "IPv4 Flex-Algo 128" or "IPv6
>     Flex-Algo 128".
>      >> There is only algo 128.
>      >
>      > Agree that Flex-Algo 128 is application or data plane agnostic,
>     and as we discussed the same Flex-Algo can be used with both IPv4
>     and IPv6 (maybe also for SR-MPLS, SRv6). These terms are used as
>     shorthand of "Flex-Algo 128 used with IPv4 or IPv6"
>      >
>      >> You are mixing data plane support with algo participation.
>      >
>      > I understand Flex-Algo definition is application agnostic, and
>     Flex-Algo participation is application specific, it is just not
>     clear to me whether IPv4 and IPv6 can be treated as one application.
>     yes they can.
>      >
>      >> If you want an algo to only include nodes that supports specific
>     data plane,
>      >> you would need to define a specific algo for it.
>      >
>      > This IMO contradicts with the base concept: Flex-Algo definition
>     is application (or data plane) agnostic.
>     not really, see above.
>     thanks,
>     Peter
>      >
>      > Best regards,
>      > Jie
>      >
>      >>
>      >> thanks,
>      >> Peter
>      >>
>      >>
>      >>>
>      >>> Best regards,
>      >>>
>      >>> Jie
>      >>>
>      >>> *From:*Lsr [mailto:lsr-bounces@ietf.org] *On Behalf Of *Acee Lindem
>      >>> (acee)
>      >>> *Sent:* Wednesday, December 2, 2020 5:13 AM
>      >>> *To:* lsr <lsr@ietf.org>
>      >>> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>      >>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>      >>>
>      >>> This IP Flex Algorithm draft generated quite a bit of discussion on
>      >>> use cases and deployment prior to IETF 109 and there was generally
>      >>> support for WG adoption. This begins a two week WG adoption call.
>      >>> Please indicate your support or objection to WG adoption on
>     this list
>      >>> prior to
>      >>> 12:00 AM UTC on December 16^th , 2020. Also, review comments are
>      >>> certainly welcome.
>      >>>
>      >>> Thanks,
>      >>>
>      >>> Acee
>      >>>
>      >
>      >
>      >
>     _______________________________________________
>     Lsr mailing list
>     Lsr@ietf.org
>     https://www.ietf.org/mailman/listinfo/lsr
>