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

Hi Peter, 

Thanks for your reply. Please see further inline:

> -----Original Message-----
> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
> Sent: Monday, October 12, 2020 4:39 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.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
> 
> 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-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://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