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

Hi Ron, 

Please see inline:

> -----Original Message-----
> From: Ron Bonica [mailto:rbonica@juniper.net]
> Sent: Saturday, October 10, 2020 8:48 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Peter Psenak
> <ppsenak@cisco.com>; 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 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.

One possible case is to define one Flex-Algo (say FA-128) with delay metric and no admin-group (color) constraints. Then as Flex-Algo is data plane agnostic, FA-128 could be used to bind to prefix-SIDs, SRv6 locators or IP addresses.

> 
> 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.

Do you mean to use different link colors to identify links with different data plane enabled? I believe it would work, while actually this is using different Flex-Algos (with different color constraints) for different data plane. 

Best regards,
Jie

> 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&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
> > >> 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_H
> z218CE
> > 8S8XzlIxAA$