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

[Jeff Tantsura <[e-mail]>]

Gyan,

In simple terms - destination lookup would yield a SID (stack) for SR or next-hop/adj for IP. For SR, no transport device in between should try to derive/evaluate context (source based routing - once you are in the tunnel), in IP case - every device will evaluate (per hop routing) the destination. As long as the destination lookup result is unambiguous, any combination of algo's could be used.

In SR easy days we (large radio vendor :)) were considering using a set of loopbacks per virtual topology as a poor-man’s slicing in MBH, where PCE would perform “slicing” and FEC2tunnel mapping over flat routing domain, perceived too complex ended up with some other ways of mapping.
Flex algo provides an easier (because distributed + additional meta-data, algo = context) way of light virtualization as compared to MT and/or fully centralized solutions.

Wrt SRv6 vs IPv6 (algo is irrelevant here), I’d assume there’s no conflict, however would leave to the implementors to comment.

Cheers,
Jeff

P.S. Acee - nothing gets me more excited than algo 201 with chocolate over it ;-)
On Oct 11, 2020, 11:21 AM -0700, Gyan Mishra <[e-mail]>, wrote:
>
> Jeff
>
> So basically as SR Flex Algo uses SR data plane (SID ,context) uniqueness for SR-MPLS label uniqueness and SRv6 Locator uniqueness as compare to IP Flex Algo IP Data plane is destination prefix based.
>
> So you could literally have both IP flex algo and SR flex also data plane as mutually exclusive data plane work in parallel as two ships in the night.
>
> SRv6 uses Longest prefix match and in SRv6-BE w/o SRH which would be destination based IP and SRv6-BE in parallel to IP Flex algo would not work as they would collide on the IPv6 data plane.
>
> Kind Regards
>
> Gyan
>
> > On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura <[e-mail]> wrote:
> > > Thanks Ron, indeed!  Autocorrect works in mysterious ways  ;-)
> > >
> > > Regards,
> > > Jeff
> > >
> > > > On Oct 11, 2020, at 09:41, Ron Bonica <[e-mail]> wrote:
> > > >
> > > > Jeff,
> > > >
> > > > I think that you mean the scope is different.....
> > > >
> > > >                                     Ron
> > > >
> > > >
> > > >
> > > > Juniper Business Use Only
> > > >
> > > > -----Original Message-----
> > > > From: Jeff Tantsura <[e-mail]>
> > > > Sent: Saturday, October 10, 2020 3:14 PM
> > > > To: Ron Bonica <[e-mail]>
> > > > Cc: Dongjie (Jimmy) <[e-mail]>; Peter Psenak <[e-mail]>; Yingzhen Qu <[e-mail]>; Gyan Mishra <[e-mail]>; [e-mail]
> > > > Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> > > >
> > > > [External Email. Be cautious of content]
> > > >
> > > >
> > > > 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 <[e-mail]> wrote:
> > > >>
> > > >> Hi Jimmie,
> > > >>
> > > >> Inline.....
> > > >>
> > > >>                   Ron
> > > >>
> > > >>
> > > >> Juniper Business Use Only
> > > >>
> > > >> -----Original Message-----
> > > >> From: Dongjie (Jimmy) <[e-mail]>
> > > >> Sent: Friday, October 9, 2020 11:06 PM
> > > >> To: Peter Psenak <[e-mail]>; Ron Bonica
> > > >> <[e-mail]>; Yingzhen Qu <[e-mail]>; Gyan
> > > >> Mishra <[e-mail]>
> > > >> Cc: [e-mail]; Jeff Tantsura <[e-mail]>
> > > >> 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:[e-mail]] On Behalf Of Peter Psenak
> > > >>> Sent: Friday, October 9, 2020 11:58 PM
> > > >>> To: Dongjie (Jimmy) <[e-mail]>; Ron Bonica
> > > >>> <rbonica=[e-mail]>; Yingzhen Qu
> > > >>> <[e-mail]>; Gyan Mishra <[e-mail]>
> > > >>> Cc: [e-mail]; Jeff Tantsura <[e-mail]>
> > > >>> 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:[e-mail]] On Behalf Of Ron Bonica
> > > >>>>> Sent: Sunday, October 4, 2020 4:34 AM
> > > >>>>> To: Yingzhen Qu <[e-mail]>; Peter Psenak
> > > >>>>> <[e-mail]>; Gyan Mishra <[e-mail]>
> > > >>>>> Cc: [e-mail]; Jeff Tantsura <[e-mail]>
> > > >>>>> 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 <[e-mail]>
> > > >>>>> Sent: Saturday, October 3, 2020 2:08 PM
> > > >>>>> To: Peter Psenak <[e-mail]>; Gyan Mishra
> > > >>>>> <[e-mail]>; Ron Bonica <[e-mail]>
> > > >>>>> Cc: [e-mail]; Jeff Tantsura <[e-mail]>
> > > >>>>> 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" <[e-mail]> 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"
> > > >>>>> <[e-mail] on behalf of
> > > >>>>> ppsenak=[e-mail]>
> > > >>>>> 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
> > > >>>>>>    [e-mail]
> > > >>>>>>
> > > >>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl
> > > >>>>> oo
> > > >>>>> k.com/
> > > >>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&amp;data
> > > >>>>> =
> > > >>> 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
> > > >>>>> [e-mail]
> > > >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
> > > >>>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H
> > > >>>>> z218CE8S8XzlIxAA$
> > > >>>>
> > > >>>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> Lsr mailing list
> > > >>> [e-mail]
> > > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
> > > >>> _
> > > >>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218C
> > > >>> E
> > > >>> 8S8XzlIxAA$
> --
>
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>