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:[email protected]] > Sent: Sunday, October 11, 2020 3:14 AM > To: Ron Bonica <[email protected]> > Cc: Dongjie (Jimmy) <[email protected]>; Peter Psenak > <[email protected]>; Yingzhen Qu <[email protected]>; Gyan > Mishra <[email protected]>; [email protected] > 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 <[email protected]> wrote: > > > > Hi Jimmie, > > > > Inline..... > > > > Ron > > > > > > Juniper Business Use Only > > > > -----Original Message----- > > From: Dongjie (Jimmy) <[email protected]> > > Sent: Friday, October 9, 2020 11:06 PM > > To: Peter Psenak <[email protected]>; Ron Bonica > > <[email protected]>; Yingzhen Qu <[email protected]>; Gyan > > Mishra <[email protected]> > > Cc: [email protected]; Jeff Tantsura <[email protected]> > > 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:[email protected]] On Behalf Of Peter Psenak > >> Sent: Friday, October 9, 2020 11:58 PM > >> To: Dongjie (Jimmy) <[email protected]>; Ron Bonica > >> <[email protected]>; Yingzhen Qu > >> <[email protected]>; Gyan Mishra <[email protected]> > >> Cc: [email protected]; Jeff Tantsura <[email protected]> > >> 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:[email protected]] On Behalf Of Ron Bonica > >>>> Sent: Sunday, October 4, 2020 4:34 AM > >>>> To: Yingzhen Qu <[email protected]>; Peter Psenak > >>>> <[email protected]>; Gyan Mishra <[email protected]> > >>>> Cc: [email protected]; Jeff Tantsura <[email protected]> > >>>> 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 <[email protected]> > >>>> Sent: Saturday, October 3, 2020 2:08 PM > >>>> To: Peter Psenak <[email protected]>; Gyan Mishra > >>>> <[email protected]>; Ron Bonica <[email protected]> > >>>> Cc: [email protected]; Jeff Tantsura <[email protected]> > >>>> 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" <[email protected]> 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" > >>>> <[email protected] on behalf of > >>>> [email protected]> > >>>> 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 > >>>>> [email protected] > >>>>> > >>>> 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 > >>>> [email protected] > >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l > >>>> > sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_ > H > >>>> z218CE8S8XzlIxAA$ > >>> > >>> > >> > >> _______________________________________________ > >> Lsr mailing list > >> [email protected] > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > >> _ > >> > _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz2 > 18C > >> E > >> 8S8XzlIxAA$ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
