Hi Peter, Thanks for your reply. Please see further inline:
> -----Original Message----- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak > Sent: Monday, October 12, 2020 4:39 PM > 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 > > 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. 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? Best regards, Jie > > thanks, > Peter > > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak > >> Sent: Friday, October 9, 2020 11:58 PM > >> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Ron Bonica > >> <rbonica=40juniper....@dmarc.ietf.org>; 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 > >> > >> 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.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://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 _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
