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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 14 October 2020 08:39 UTC

Return-Path: <jie.dong@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 347323A145A for <lsr@ietfa.amsl.com>; Wed, 14 Oct 2020 01:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 mbPF-rZylH29 for <lsr@ietfa.amsl.com>; Wed, 14 Oct 2020 01:38:57 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6634A3A141B for <lsr@ietf.org>; Wed, 14 Oct 2020 01:38:57 -0700 (PDT)
Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 59DBAD3577F284931D0C; Wed, 14 Oct 2020 09:38:51 +0100 (IST)
Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 14 Oct 2020 09:38:50 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 14 Oct 2020 16:38:48 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Wed, 14 Oct 2020 16:38:47 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
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" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>
Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAESbICAACKHAIAA7E2AgADTYwCAAWy/gIAAAz6AgAA7sgCAAOLhAIAAi8SAgAAopgCAA1loEIAFx4OAgAExPQCAAwtCgIACAvgg//+TI4CAAfmEMA==
Date: Wed, 14 Oct 2020 08:38:47 +0000
Message-ID: <5d9887519bbc429fb0bf9886b35ccefd@huawei.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> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> <34c223a132f748e0a802d538ccd073b0@huawei.com> <c7ad92ab-3ac7-afe9-fa2a-221f80468491@cisco.com>
In-Reply-To: <c7ad92ab-3ac7-afe9-fa2a-221f80468491@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.143]
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/3FuJ2QRTAW50GcYzDP1imOe9wtU>
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: Wed, 14 Oct 2020 08:39:07 -0000

Hi Peter, 

> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Tuesday, October 13, 2020 4:53 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.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
> 
> >>> 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.

OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 considered the same or different apps? 

> 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.

If the participation is topology specific, do you mean IPv4 and IPv6 could be distinguished by advertising Flex-Algo participation with different Topology IDs (MT-ID)? This way, is the topology ID actually used as the address family distinguisher?

Best regards,
Jie

> 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] 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.ou
> >>>>>> tl
> >>>>>> oo
> >>>>>> k.com/
> >>>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&amp;da
> >>>>>> ta
> >>>>>> =
> >>>> 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://www.ietf.org/mailman/listinfo/lsr
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >
> >