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?

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? 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-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.outloo
> >> 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://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

Reply via email to