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

Peter Psenak <ppsenak@cisco.com> Tue, 13 October 2020 11:55 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 9D24D3A0F73 for <lsr@ietfa.amsl.com>; Tue, 13 Oct 2020 04:55:02 -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 cH9LsOwDNPYm for <lsr@ietfa.amsl.com>; Tue, 13 Oct 2020 04:55:00 -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 CD5D63A0F70 for <lsr@ietf.org>; Tue, 13 Oct 2020 04:54:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18740; q=dns/txt; s=iport; t=1602590099; x=1603799699; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wbqTaMGsPEqXLYMBnP8a8SJozgYNmPJi+6sMqjgiSYc=; b=h8+bL6+LCaoe/XarSkzem202KqtLe7ubfPA1LCVcPnv4VN7ZcxZiQOMc grZOB8BdF9jREoPJTCquL+Ao0XjPbaO4xhBD7NwOoYIZdhou4WepsBmUG tLhe2x6qZFUCK9tzwnj9fxG3XOWBlHLCYeGdlUZ73+0c6XoY4vg0ccLD1 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BSBQABlYVf/xbLJq1gHAEBAQEBAQcBARIBAQQEAQFAgU+DGlUBIBIshD2JAodpCCaKEZAsgWkLAQEBDxgLDAQBAYRKAoIDJjgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQIBAQEhDwEFNgkCDAQJAhEEAQEBAgIjAwICIQYfCQgGDQYCAQGDIgGCSwMOIA+MXZsFdoEyhDsBgRiCRA1igUKBDiqHZoVrgUE/gREnDIJdPoIaQgEBAoEoARIBIYMXgmAEkAMrCYJVAaNMOFKCc4MVhW2MXYR/BQcDH4MVgSqIXoUZjweeF4JshB6OU4FrI2dwMxoIGxU7gmkJRxkNgzqKcReDToUUhUQ/AzACATQCBgEJAQEDCY5IAQE
X-IronPort-AV: E=Sophos;i="5.77,370,1596499200"; d="scan'208";a="30315489"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Oct 2020 11:54:55 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 09DBssIv024427; Tue, 13 Oct 2020 11:54:54 GMT
To: Robert Raszuk <robert@raszuk.net>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Ron Bonica <rbonica@juniper.net>, Yingzhen Qu <yingzhen.qu@futurewei.com>, Gyan Mishra <hayabusagsm@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>
References: <160138654056.12980.329207214151594381@ietfa.amsl.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> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> <34c223a132f748e0a802d538ccd073b0@huawei.com> <c7ad92ab-3ac7-afe9-fa2a-221f80468491@cisco.com> <CAOj+MMHMWMT_6WeZdt+8R5Vkg3eh=mpU=GSu-jc-SJ+=zL93Mw@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <7c75f1bf-5255-bd37-895b-e07b803ace6e@cisco.com>
Date: Tue, 13 Oct 2020 13:54:54 +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: <CAOj+MMHMWMT_6WeZdt+8R5Vkg3eh=mpU=GSu-jc-SJ+=zL93Mw@mail.gmail.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.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/nVxHuAaSoXmaxH8PmRCfp832om8>
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: Tue, 13 Oct 2020 11:55:03 -0000

Robert,


On 13/10/2020 13:38, Robert Raszuk wrote:
> Peter,
> 
> If this is per app how are the constraints shared across apps ?

FAD constraints are only used for calculating the flex-algo path.

> 
> See we have single physical resources (for example links) and single 
> interface outbound queues. If I use per app flex-algo and do not have 
> central controller how is this going to work in practice for any network 
> which attempts to use more then one forwarding schema with dynamic 
> constraints ?

flex-algo defines the way to calculate constraint based paths in a 
distributed manner and guarantees the loop free forwarding over such path.

Possible per app and/or per algo resource allocation at each hop is not 
something that flex-algo spec attempts to solve. That does not mean it 
is not possible. I don't see anything in the flex-algo spec that would 
prevent one to do that.

thanks,
Peter

> 
> Many thx,
> R.
> 
> 
> 
> On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak 
> <ppsenak=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>> 
> wrote:
> 
>     Hi Jimmy,
> 
>     On 13/10/2020 10:02, Dongjie (Jimmy) wrote:
>      > Hi Peter,
>      >
>      > Thanks for your reply. Please see further inline:
>      >
>      >> -----Original Message-----
>      >> From: Lsr [mailto:lsr-bounces@ietf.org
>     <mailto:lsr-bounces@ietf.org>] On Behalf Of Peter Psenak
>      >> Sent: Monday, October 12, 2020 4:39 PM
>      >> To: Dongjie (Jimmy) <jie.dong@huawei.com
>     <mailto:jie.dong@huawei.com>>; Ron Bonica
>      >> <rbonica@juniper.net <mailto:rbonica@juniper.net>>; Yingzhen Qu
>     <yingzhen.qu@futurewei.com <mailto:yingzhen.qu@futurewei.com>>; Gyan
>      >> Mishra <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>
>      >> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Jeff Tantsura
>     <jefftant.ietf@gmail.com <mailto:jefftant.ietf@gmail.com>>
>      >> Subject: Re: [Lsr] FW: New Version Notification for
>      >> draft-bonica-lsr-ip-flexalgo-00.txt
>      >>
>      >> Hi Jimmy,
>      >>
>      >> On 10/10/2020 05:05, Dongjie (Jimmy) wrote:
>      >>> 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?
>      >>
>      >> correct.
>      >>
>      >>>
>      >>> 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.
>      >>
>      >> just to use the correct terminology, we should use "participate"
>     instead of
>      >> "support".
>      >
>      > Agree.
>      >
>      >>
>      >>> 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? If so, how could this
>     node know the
>      >> binding of FA to different data planes on other nodes?
>      >>
>      >> again, it is the participation problem.
>      >>
>      >> Nodes that participate in the SR Flex-algo 128 will advertise
>     the participation
>      >> using the SR-Algorithm Sub-TLV. Only these nodes will be used
>     during the SR
>      >> flex-algo computation for algo 128.
>      >>
>      >> Nodes that participate in IP flex-algo 128 will advertise the
>     participation using
>      >> the IGP Algorithm Sub-TLV. Only these nodes will be used during
>     the IP flex-algo
>      >> computation for algo 128.
>      >
>      > Agree that if participation to Flex-Algo is advertised in a data
>     plane specific manner, then path computation with Flex-Algo
>     constraints could be done only using nodes which bind the Flex-Algo
>     to the same data plane.
> 
>     it's per app, not per data plane, but yes, that is what the base
>     flex-algo spec mandates.
> 
>      >
>      > As Robert asked and you confirmed, this implies each data plane
>     needs to be treated as an independent application of Flex-Algo. We
>     have SR-Algorithm sub-TLV and IP Algorithm sub-TLV, while there are
>     actually more data planes to be considered: SR-MPLS, SRv6, IPv4,
>     IPv6, etc., does this mean that Flex-Algo participation needs to be
>     advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. separately?
> 
>     yes, it needs to be advertised per app. We have SR specific algo
>     participation, we need one for IP as proposed in Ron's draft.
> 
>     Regarding IPv4 vs IPv6, it's up to the authors whether they want to
>     make
>     the participation for IP flex-algo topology specific or topology
>     independent, both could work.
> 
>     Here's the text from the base flerx-algo draft:
> 
>     10.2.  Advertisement of Node Participation for Other Applications
> 
>          This section describes considerations related to how other
>          applications can advertise their participation in a specific Flex-
>          Algorithm.
> 
>          Application-specific Flex-Algorithm participation
>     advertisements MAY
>          be topology specific or MAY be topology independent, depending
>     on the
>          application itself.
> 
>          Application-specific advertisement for Flex-Algorithm participation
>          MUST be defined for each application and is outside of the scope of
>          this document.
> 
>     thanks,
>     Peter
> 
> 
>      >
>      > Best regards,
>      > Jie
>      >
>      >>
>      >> thanks,
>      >> Peter
>      >>
>      >>>
>      >>> Best regards,
>      >>> Jie
>      >>>
>      >>>> -----Original Message-----
>      >>>> From: Lsr [mailto:lsr-bounces@ietf.org
>     <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
>     <mailto:jie.dong@huawei.com>>; Ron Bonica
>      >>>> <rbonica=40juniper.net@dmarc.ietf.org
>     <mailto:40juniper.net@dmarc.ietf.org>>; Yingzhen Qu
>      >>>> <yingzhen.qu@futurewei.com
>     <mailto:yingzhen.qu@futurewei.com>>; Gyan Mishra
>     <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>
>      >>>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Jeff Tantsura
>     <jefftant.ietf@gmail.com <mailto: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
>     <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
>     <mailto:yingzhen.qu@futurewei.com>>; Peter Psenak
>      >>>>>> <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>; Gyan Mishra
>     <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>
>      >>>>>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Jeff Tantsura
>     <jefftant.ietf@gmail.com <mailto: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
>     <mailto:yingzhen.qu@futurewei.com>>
>      >>>>>> Sent: Saturday, October 3, 2020 2:08 PM
>      >>>>>> To: Peter Psenak <ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>>; Gyan Mishra
>      >>>>>> <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>; Ron
>     Bonica <rbonica@juniper.net <mailto:rbonica@juniper.net>>
>      >>>>>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Jeff Tantsura
>     <jefftant.ietf@gmail.com <mailto: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
>     <mailto: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 <mailto:lsr-bounces@ietf.org> on behalf of
>      >>>>>> ppsenak=40cisco.com@dmarc.ietf.org
>     <mailto: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 <mailto:Lsr@ietf.org>
>      >>>>>>        >
>      >>>>>>
>     https://urldefense.com/v3/__https://nam11.safelinks.protection.outl
>      >>>>>> oo
>      >>>>>> k.com/ <http://k.com/>
>      >>>>>> ?url=https*3A*2F*2Fwww.ietf.org
>     <http://2Fwww.ietf.org>*2Fmailman*2Flistinfo*2Flsr&amp;data
>      >>>>>> =
>      >>>> 0
>      >>>>>> 2
>      >>>>>>
>      >>>>
>      >> *7C01*7Cyingzhen.qu*40futurewei.com
>     <http://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 <mailto:Lsr@ietf.org>
>      >>>>>> https://www.ietf.org/mailman/listinfo/lsr
>      >>>>>
>      >>>>>
>      >>>>
>      >>>> _______________________________________________
>      >>>> Lsr mailing list
>      >>>> Lsr@ietf.org <mailto:Lsr@ietf.org>
>      >>>> https://www.ietf.org/mailman/listinfo/lsr
>      >>>
>      >>>
>      >>
>      >> _______________________________________________
>      >> Lsr mailing list
>      >> Lsr@ietf.org <mailto:Lsr@ietf.org>
>      >> https://www.ietf.org/mailman/listinfo/lsr
>      >
>      >
> 
>     _______________________________________________
>     Lsr mailing list
>     Lsr@ietf.org <mailto:Lsr@ietf.org>
>     https://www.ietf.org/mailman/listinfo/lsr
>