+1
Juniper Business Use Only -----Original Message----- From: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> Sent: Friday, October 9, 2020 11:58 AM To: Dongjie (Jimmy) <jie.d...@huawei.com>; Ron Bonica <rbon...@juniper.net>; Yingzhen Qu <yingzhen...@futurewei.com>; Gyan Mishra <hayabusa...@gmail.com> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.i...@gmail.com> Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt [External Email. Be cautious of content] 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-boun...@ietf.org] On Behalf Of Ron Bonica >> Sent: Sunday, October 4, 2020 4:34 AM >> To: Yingzhen Qu <yingzhen...@futurewei.com>; Peter Psenak >> <ppse...@cisco.com>; Gyan Mishra <hayabusa...@gmail.com> >> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.i...@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...@futurewei.com> >> Sent: Saturday, October 3, 2020 2:08 PM >> To: Peter Psenak <ppse...@cisco.com>; Gyan Mishra >> <hayabusa...@gmail.com>; Ron Bonica <rbon...@juniper.net> >> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.i...@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" <ppse...@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-boun...@ietf.org on behalf of >> ppsenak=40cisco....@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.outloo >> 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/lsr >> __;!!NEt6yMaO-gk!S3DZGr_DbCQIRsnq2hAgAtb2RlxErvd8T0WG7VHv21jDFU_ZFDhw >> h7qVM_VUOLgJ$ > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
