Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
"Dongjie (Jimmy)" <jie.dong@huawei.com> Mon, 12 October 2020 07:12 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 0D7263A12D4 for <lsr@ietfa.amsl.com>; Mon, 12 Oct 2020 00:12:38 -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 DzQFrV6OYsaF for <lsr@ietfa.amsl.com>; Mon, 12 Oct 2020 00:12:35 -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 F32EC3A0F36 for <lsr@ietf.org>; Mon, 12 Oct 2020 00:12:34 -0700 (PDT)
Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A7FBD23621993CC7B519; Mon, 12 Oct 2020 08:12:33 +0100 (IST)
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Mon, 12 Oct 2020 08:12:32 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 12 Oct 2020 15:12:30 +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; Mon, 12 Oct 2020 15:12:30 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>, Ron Bonica <rbonica@juniper.net>
CC: Peter Psenak <ppsenak@cisco.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>, Gyan Mishra <hayabusagsm@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAESbICAACKHAIAA7E2AgADTYwCAAWy/gIAAAz6AgAA7sgCAAOLhAIAAi8SAgAAopgCAA1loEIAFx4OAgAExPQCAACwOgIAAa8sAgALb+jA=
Date: Mon, 12 Oct 2020 07:12:30 +0000
Message-ID: <b2c60ea9979e49f58b4543b59bc9884d@huawei.com>
References: <DM6PR05MB6348BE62F0F0801D4468B296AE090@DM6PR05MB6348.namprd05.prod.outlook.com> <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.com>
In-Reply-To: <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.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/85edpXrg_s67RbZlJ8_rtUrhX7Q>
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 07:12:38 -0000
Hi Jeff, Thanks for your explanation. I understand that for different data plane the SIDs or IP addresses have different scope, and will not conflict in normal cases. My question is more about whether a computation node needs to know and check which data plane is used by the intermediate nodes to bind to the Flex-Algo? In another word, can an SR path computed using Flex-Algo 128 go through an intermediate node which bind Flex-Algo 128 to IP data plane? Best regards, Jie > -----Original Message----- > From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com] > Sent: Sunday, October 11, 2020 3:14 AM > To: Ron Bonica <rbonica@juniper.net> > Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Peter Psenak > <ppsenak@cisco.com>; Yingzhen Qu <yingzhen.qu@futurewei.com>; Gyan > Mishra <hayabusagsm@gmail.com>; lsr@ietf.org > Subject: Re: [Lsr] FW: New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt > > Jie, > > The scoop is different, for SR data plane entry uniqueness is in context of SR > domain (SID = value + context), while for IP it is global to the routing domain, > FIB entry is a destination, nothing more. > > Regards, > Jeff > > > On Oct 10, 2020, at 05:47, Ron Bonica <rbonica@juniper.net> 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. > > > > 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. > > > > 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&data > >>>> = > >> 0 > >>>> 2 > >>>> > >> > *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 > >>>> > >> > 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >>>> > >> > 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >>>> > >> > &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_Hz2 > 18C > >> E > >> 8S8XzlIxAA$
- [Lsr] FW: New Version Notification for draft-boni… Ron Bonica
- Re: [Lsr] New Version Notification for draft-boni… tony.li
- Re: [Lsr] New Version Notification for draft-boni… Jia Chen
- Re: [Lsr] New Version Notification for draft-boni… Huzhibo
- Re: [Lsr] New Version Notification for draft-boni… Joel M. Halpern
- Re: [Lsr] New Version Notification for draft-boni… Huzhibo
- Re: [Lsr] New Version Notification for draft-boni… Robert Raszuk
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Muthu Arul Mozhi Perumal
- Re: [Lsr] New Version Notification for draft-boni… Robert Raszuk
- Re: [Lsr] New Version Notification for draft-boni… Dongjie (Jimmy)
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] New Version Notification for draft-boni… Robert Raszuk
- Re: [Lsr] New Version Notification for draft-boni… Les Ginsberg (ginsberg)
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… Ron Bonica
- Re: [Lsr] New Version Notification for draft-boni… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Acee Lindem (acee)
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Yingzhen Qu
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Robert Raszuk
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Yingzhen Qu
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo-01 Huaimo Chen
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- [Lsr] 回复: draft-zhu-lsr-isis-sr-vtn-flexalgo-01 zhuyq8
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Acee Lindem (acee)
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Robert Raszuk
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Robert Raszuk
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… bruno.decraene
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… bruno.decraene
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… bruno.decraene
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak