Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Peter Psenak <ppsenak@cisco.com> Mon, 12 October 2020 08:41 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 C12203A136F for <lsr@ietfa.amsl.com>; Mon, 12 Oct 2020 01:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.814
X-Spam-Level:
X-Spam-Status: No, score=-9.814 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.213, 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 m7fAvyQjr8YF for <lsr@ietfa.amsl.com>; Mon, 12 Oct 2020 01:41:13 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A18B3A1357 for <lsr@ietf.org>; Mon, 12 Oct 2020 01:41:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10391; q=dns/txt; s=iport; t=1602492073; x=1603701673; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yB9siZTDkblQ9YDN5s00a2k4axHe+8c63Mjq9qhZz2A=; b=Y5pSPs5JSiBg7t1aYXaOeuz61MKes2D2Ehxn/e+rI6/VjJlGARVNLgmy 5orIKRj+Wm6tZInoVPgPfjG/TAW+hwvwyUZgbUF1q/s2QOtDSIp4g0ZP4 /uXM3A6M1km4CNZR19AOEJ2CV7/WAzZjCZ/O0qGRxsWG7mJ5iPyVNsEIz Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ArBQCaFYRf/xbLJq1gHAEBAQEBAQcBARIBAQQEAQFAgU+DGlUBIBIshD2JAodqCCaKEZAsgWkLAQEBDxgLDAQBAYRKAoIXJjgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQIBAQEhFTYJAgwECw4DBAEBAQICIwMCAiEGHwkIBgEMBgIBAYMiAYJLAw4gD6YTdoEyhVSCNw1igTwGgQ4qjVGBQT+BEScMgl0+ghpCAQECgSgBEgEhgxeCYASQACsJglWJApsDUoJygxWFbIxdhH8FBwMfgxWKCIUZjwSTIopxgmyScIFrI2dwMxoIGxU7gmlQGQ2OKxeDToUUhUQ/AzACATQCBgoBAQMJjkgBAQ
X-IronPort-AV: E=Sophos;i="5.77,366,1596499200"; d="scan'208";a="30281606"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2020 08:41:09 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 09C8f8fg005187; Mon, 12 Oct 2020 08:41:08 GMT
To: Ron Bonica <rbonica@juniper.net>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>, Gyan Mishra <hayabusagsm@gmail.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>
References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <CAKz0y8w5VOf_=baG6UCP8Q9s=VLM2ghT2jhiF5FZNN4JXB23eA@mail.gmail.com> <DM6PR05MB63485389C261CA2E0C08DE50AE330@DM6PR05MB6348.namprd05.prod.outlook.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <DM6PR05MB63480E863599BBC810BF334AAE300@DM6PR05MB6348.namprd05.prod.outlook.com> <CABNhwV2+jhjAfxq5FzaukdhCOqXvGCkv75xYWcStN=SCrpni4Q@mail.gmail.com> <f4fdff8b-fe11-cb75-3cd7-7766baedf730@cisco.com> <CB2F6A55-B231-4A2D-821C-D3F2ABE6649E@futurewei.com> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <DM6PR05MB6348C6FBFD50C19C06DE719BAE0E0@DM6PR05MB6348.namprd05.prod.outlook.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> <c9b0f0aa-975a-f042-6773-58a603ba5d39@cisco.com> <fe517f068bea428a9a95b3247f20a100@huawei.com> <DM6PR05MB6348BE62F0F0801D4468B296AE090@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <dabc2653-592c-1560-7ff1-add4f9aa3e12@cisco.com>
Date: Mon, 12 Oct 2020 10:41:08 +0200
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: <DM6PR05MB6348BE62F0F0801D4468B296AE090@DM6PR05MB6348.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/y_trGBqZ8rTY-tWOXPBCpBvGc_I>
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
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: Mon, 12 Oct 2020 08:41:23 -0000

Ho Ron,

On 10/10/2020 14:47, Ron Bonica wrote:
> Hi Jimmie,
> 
> Inline.....
> 
>                      Ron
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Dongjie (Jimmy) <jie.dong@huawei.com>
> Sent: Friday, October 9, 2020 11:06 PM
> To: Peter Psenak <ppsenak@cisco.com>; Ron Bonica <rbonica@juniper.net>; Yingzhen Qu <yingzhen.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com>
> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
> Subject: RE: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Peter,
> 
> Thanks for your reply. It aligns with my understanding of FAD, which is just a set of constraints for path computation. Thus one Flex-Algo ID could be used with multiple different data planes. Is this understanding correct?
> 
> [RB] I never thought about this. Is there a use-case? I think that it will work, but I would have to try it before saying for sure.

yes, this works fine.

> 
> If so, my question is about the scenario below:
> 
> A group of nodes in a network support FA-128, a sub-group of them bind FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When one node compute an SR path to a destination, can it compute the path to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA-128 to IP address?
> 
> [RB] I don't think so. However, you could achieve the same outcome using link colors.


please see my response to the Jimmy.

thanks,
Peter


> 
> If so, how could this node know the binding of FA to different data planes on other nodes?
> 
> Best regards,
> Jie
> 
>> -----Original Message-----
>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
>> Sent: Friday, October 9, 2020 11:58 PM
>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Ron Bonica
>> <rbonica=40juniper.net@dmarc.ietf.org>; Yingzhen Qu
>> <yingzhen.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com>
>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>> Subject: Re: [Lsr] FW: New Version Notification for
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> Hi Jimmy,
>>
>>
>>    On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
>>> Hi Ron,
>>>
>>> Thanks for explaining the difference between IP Flex-Algo and SR
>>> Flex-algo. As
>> you said, the major difference is the data plane.
>>>
>>> If my understanding is correct, for one Flex-Algo to be used
>>> correctly, the set
>> of nodes need to apply consistent constraints in computation, and bind
>> the FAD to the same data plane.
>>>
>>> Is it possible that different nodes may use the same Flex-Algo with
>>> different
>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure
>> IP etc., or each Flex-Algo is always associated with only one data
>> plane? In the former case, should the flex-algo definition also
>> indicate the data plane(s) to be used with the flex-algo?
>>
>> let me respond to this query, as this is not specific to Ron's draft.
>>
>> FAD is data plane agnostic and is used by all of them.
>>
>> thanks,
>> Peter
>>
>>>
>>> Best regards,
>>> Jie
>>>
>>>> -----Original Message-----
>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica
>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>> To: Yingzhen Qu <yingzhen.qu@futurewei.com>; Peter Psenak
>>>> <ppsenak@cisco.com>; Gyan Mishra <hayabusagsm@gmail.com>
>>>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>> Subject: Re: [Lsr] FW: New Version Notification for
>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>
>>>> Hi Yingzhen,
>>>>
>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the
>>>> following
>> respects:
>>>>
>>>> - Links have IGP metrics, TE metrics, delay metrics and
>>>> administrative colors
>>>> - FADs define Flexible Algorithms
>>>>
>>>> More specifically, the FAD:
>>>>
>>>> - Indicates which metric type the Flexible Algorithm uses
>>>> - Specifies constraints in terms of link colors that are included
>>>> or excluded from the Flexible Algorithm.
>>>>
>>>> The significant difference between IP Flexible Algorithms and SR
>>>> Flexible Algorithms is:
>>>>
>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses.
>>>>
>>>> So, IP Flexible Algorithms can be deployed in any IP network, even
>>>> in the absence of SR.
>>>>
>>>>                                           Ron
>>>>
>>>>
>>>> Juniper Business Use Only
>>>>
>>>> -----Original Message-----
>>>> From: Yingzhen Qu <yingzhen.qu@futurewei.com>
>>>> Sent: Saturday, October 3, 2020 2:08 PM
>>>> To: Peter Psenak <ppsenak@cisco.com>; Gyan Mishra
>>>> <hayabusagsm@gmail.com>; Ron Bonica <rbonica@juniper.net>
>>>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>> Subject: Re: [Lsr] FW: New Version Notification for
>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>
>>>> [External Email. Be cautious of content]
>>>>
>>>>
>>>> Hi Peter,
>>>>
>>>> Using flex-algo, a SRv6 locator can be associated with a single
>>>> algo, which means an IPv6 or IPv4 address can also be associated
>>>> with a single algo. So my understanding is Ron's proposal is making
>>>> the
>> configuration of flex-algo easier?
>>>> Instead of using the exclude or include list you can configure a
>>>> loopback address to a flex-algo directly?
>>>>
>>>> Thanks,
>>>> Yingzhen
>>>>
>>>> On 10/3/20, 2:47 AM, "Peter Psenak" <ppsenak@cisco.com> wrote:
>>>>
>>>>       Hi Yingzhen,
>>>>
>>>>       On 02/10/2020 22:15, Yingzhen Qu wrote:
>>>>       > Hi Peter,
>>>>       >
>>>>       > My understanding of flex-algo is that for traffic destined
>>>> to a prefix on a particular algo, it can only be routed on routers
>>>> belong to that algo, which also means only routers in that algo
>>>> calculates how to reach that prefix and install it into the routing
>>>> table. It seems to me that using flex-algo (section 12 of the
>>>> draft) it's possible to have a loopback address associated with
>>>> only one algo, please correct me if I'm missing or misunderstood something.
>>>>
>>>>       you are right. That is exactly what is being done for flex-algo with
>>>>       SRv6 - locator is associated with a single algo only. The proposal uses
>>>>       the same concept.
>>>>
>>>>       thanks,
>>>>       Peter
>>>>
>>>>       >
>>>>       > Thanks,
>>>>       > Yingzhen
>>>>       >
>>>>       > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"
>>>> <lsr-bounces@ietf.org on behalf of
>>>> ppsenak=40cisco.com@dmarc.ietf.org>
>>>> wrote:
>>>>       >
>>>>       >      Gyan,
>>>>       >
>>>>       >      On 02/10/2020 18:30, Gyan Mishra wrote:
>>>>       >      > All,
>>>>       >      >
>>>>       >      > With SRv6 and IP based flex algo a generic question as it
>> applies
>>>> to
>>>>       >      > both. Is it possible to have within a single IGP domain
>> different
>>>> sets
>>>>       >      > of nodes or segments of the network running different
>>>> algorithms.
>>>>       >
>>>>       >      absolutely.
>>>>       >
>>>>       >      > From
>>>>       >      > both drafts it sounds like all nodes have to agree on same
>>>> algorithm
>>>>       >      > similar to concept of metric and reference bandwidth all
>> have to
>>>> have
>>>>       >      > the same style metric and play to the same sheet of music.
>>>>       >
>>>>       >      all participating nodes need to agree on the definition of the
>>>> flex-algo
>>>>       >      and advertise the participation. That's it.
>>>>       >
>>>>       >      > If there was
>>>>       >      > a way to use multiple algorithms simultaneously based on
>> SFC
>>>> or services
>>>>       >      > and instantiation of specific algorithm based on service to
>> be
>>>>       >      > rendered.  Doing so without causing a routing loop or sub
>>>> optimal
>>>>       >      > routing.
>>>>       >
>>>>       >      you can certainly use multiple algorithms simultaneously and
>> use
>>>> algo
>>>>       >      specific paths to forward specific traffic over it. How that is
>> done
>>>>       >      from the forwarding perspective depends in which
>> forwarding
>>>> plane you
>>>>       >      use. Flex-algo control plane is independent of the forwarding
>>>> plane.
>>>>       >
>>>>       >
>>>>       >      >I thought with flex algo that there exists a feature that on
>>>>       >      > each hop there is a way to specify which algo to use hop by
>> hop
>>>> similar
>>>>       >      > to a hop by hop policy based routing.
>>>>       >
>>>>       >      no, there is no hop-by-hop classification, that is problematic
>> and
>>>> does
>>>>       >      not scale for high speeds. Classification is done at the
>> ingress only.
>>>>       >
>>>>       >      thanks,
>>>>       >      Peter
>>>>       >
>>>>       >      >
>>>>       >
>>>>       >      _______________________________________________
>>>>       >      Lsr mailing list
>>>>       >      Lsr@ietf.org
>>>>       >
>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl
>>>> oo
>>>> k.com/
>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&amp;data
>>>> =
>> 0
>>>> 2
>>>>
>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781
>>>>
>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986
>>>>
>> 5126&amp;sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D
>>>>
>> &amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR
>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$
>>>>       >
>>>>       >
>>>>       >
>>>>
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> Lsr@ietf.org
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H
>>>> z218CE8S8XzlIxAA$
>>>
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218CE
>> 8S8XzlIxAA$
> 
>