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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Robert and Peter,

> -----Original Message-----
> From: Lsr [mailto:[e-mail]] On Behalf Of Peter Psenak
> Sent: Tuesday, October 13, 2020 7:55 PM
> To: Robert Raszuk <[e-mail]>
> Cc: Dongjie (Jimmy) <[e-mail]>; Gyan Mishra
> <[e-mail]>; Ron Bonica <[e-mail]>; [e-mail];
> Jeff Tantsura <[e-mail]>; Yingzhen Qu
> <[e-mail]>
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> Robert,
> 
> 
> On 13/10/2020 13:38, Robert Raszuk wrote:
> > Peter,
> >
> > If this is per app how are the constraints shared across apps ?
> 
> FAD constraints are only used for calculating the flex-algo path.

Agree that FAD just defines the constraints for path computation, and as discussed computation with Flex-Algo constraints needs to be done using nodes which bind the Flex-Algo to the same app/data plane.

> >
> > See we have single physical resources (for example links) and single
> > interface outbound queues. If I use per app flex-algo and do not have
> > central controller how is this going to work in practice for any
> > network which attempts to use more then one forwarding schema with
> > dynamic constraints ?
> 
> flex-algo defines the way to calculate constraint based paths in a distributed
> manner and guarantees the loop free forwarding over such path.
> 
> Possible per app and/or per algo resource allocation at each hop is not
> something that flex-algo spec attempts to solve. That does not mean it is not
> possible. I don't see anything in the flex-algo spec that would prevent one to do
> that.

Yes for that purpose some extensions based on Flex-Algo would be needed.

For per-Algo resource allocation, please refer to draft-zhu-lsr-isis-sr-vtn-flexalgo-01. For per app resource allocation and identification , you may refer to draft-dong-lsr-sr-enhanced-vpn-04. 

Best regards,
Jie

> 
> thanks,
> Peter
> 
> >
> > Many thx,
> > R.
> >
> >
> >
> > On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak
> > <ppsenak=[e-mail]
> > <mailto:[e-mail]>>
> > wrote:
> >
> >     Hi Jimmy,
> >
> >     On 13/10/2020 10:02, Dongjie (Jimmy) wrote:
> >      > Hi Peter,
> >      >
> >      > Thanks for your reply. Please see further inline:
> >      >
> >      >> -----Original Message-----
> >      >> From: Lsr [mailto:[e-mail]
> >     <mailto:[e-mail]>] On Behalf Of Peter Psenak
> >      >> Sent: Monday, October 12, 2020 4:39 PM
> >      >> To: Dongjie (Jimmy) <[e-mail]
> >     <mailto:[e-mail]>>; Ron Bonica
> >      >> <[e-mail] <mailto:[e-mail]>>; Yingzhen Qu
> >     <[e-mail] <mailto:[e-mail]>>;
> Gyan
> >      >> Mishra <[e-mail]
> <mailto:[e-mail]>>
> >      >> Cc: [e-mail] <mailto:[e-mail]>; Jeff Tantsura
> >     <[e-mail] <mailto:[e-mail]>>
> >      >> 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.
> >
> >     it's per app, not per data plane, but yes, that is what the base
> >     flex-algo spec mandates.
> >
> >      >
> >      > 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?
> >
> >     yes, it needs to be advertised per app. We have SR specific algo
> >     participation, we need one for IP as proposed in Ron's draft.
> >
> >     Regarding IPv4 vs IPv6, it's up to the authors whether they want to
> >     make
> >     the participation for IP flex-algo topology specific or topology
> >     independent, both could work.
> >
> >     Here's the text from the base flerx-algo draft:
> >
> >     10.2.  Advertisement of Node Participation for Other Applications
> >
> >          This section describes considerations related to how other
> >          applications can advertise their participation in a specific Flex-
> >          Algorithm.
> >
> >          Application-specific Flex-Algorithm participation
> >     advertisements MAY
> >          be topology specific or MAY be topology independent, depending
> >     on the
> >          application itself.
> >
> >          Application-specific advertisement for Flex-Algorithm
> participation
> >          MUST be defined for each application and is outside of the scope
> of
> >          this document.
> >
> >     thanks,
> >     Peter
> >
> >
> >      >
> >      > Best regards,
> >      > Jie
> >      >
> >      >>
> >      >> thanks,
> >      >> Peter
> >      >>
> >      >>>
> >      >>> Best regards,
> >      >>> Jie
> >      >>>
> >      >>>> -----Original Message-----
> >      >>>> From: Lsr [mailto:[e-mail]
> >     <mailto:[e-mail]>] On Behalf Of Peter Psenak
> >      >>>> Sent: Friday, October 9, 2020 11:58 PM
> >      >>>> To: Dongjie (Jimmy) <[e-mail]
> >     <mailto:[e-mail]>>; Ron Bonica
> >      >>>> <rbonica=[e-mail]
> >     <mailto:[e-mail]>>; Yingzhen Qu
> >      >>>> <[e-mail]
> >     <mailto:[e-mail]>>; Gyan Mishra
> >     <[e-mail] <mailto:[e-mail]>>
> >      >>>> Cc: [e-mail] <mailto:[e-mail]>; Jeff Tantsura
> >     <[e-mail] <mailto:[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]
> >     <mailto:[e-mail]>] On Behalf Of Ron Bonica
> >      >>>>>> Sent: Sunday, October 4, 2020 4:34 AM
> >      >>>>>> To: Yingzhen Qu <[e-mail]
> >     <mailto:[e-mail]>>; Peter Psenak
> >      >>>>>> <[e-mail] <mailto:[e-mail]>>; Gyan
> Mishra
> >     <[e-mail] <mailto:[e-mail]>>
> >      >>>>>> Cc: [e-mail] <mailto:[e-mail]>; Jeff Tantsura
> >     <[e-mail] <mailto:[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.
> >      >>>>>>
> >      >>>>>>                                            Ro
> n
> >      >>>>>>
> >      >>>>>>
> >      >>>>>> Juniper Business Use Only
> >      >>>>>>
> >      >>>>>> -----Original Message-----
> >      >>>>>> From: Yingzhen Qu <[e-mail]
> >     <mailto:[e-mail]>>
> >      >>>>>> Sent: Saturday, October 3, 2020 2:08 PM
> >      >>>>>> To: Peter Psenak <[e-mail]
> >     <mailto:[e-mail]>>; Gyan Mishra
> >      >>>>>> <[e-mail]
> <mailto:[e-mail]>>; Ron
> >     Bonica <[e-mail] <mailto:[e-mail]>>
> >      >>>>>> Cc: [e-mail] <mailto:[e-mail]>; Jeff Tantsura
> >     <[e-mail] <mailto:[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]
> >     <mailto:[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] <mailto:[e-mail]> on
> behalf of
> >      >>>>>> ppsenak=[e-mail]
> >     <mailto:[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] <mailto:[e-mail]>
> >      >>>>>>        >
> >      >>>>>>
> >     https://urldefense.com/v3/__https://nam11.safelinks.protection.outl
> >      >>>>>> oo
> >      >>>>>> k.com/ <http://k.com/>
> >      >>>>>> ?url=https*3A*2F*2Fwww.ietf.org
> >     <http://2Fwww.ietf.org>*2Fmailman*2Flistinfo*2Flsr&amp;data
> >      >>>>>> =
> >      >>>> 0
> >      >>>>>> 2
> >      >>>>>>
> >      >>>>
> >      >> *7C01*7Cyingzhen.qu*40futurewei.com
> >     <http://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] <mailto:[e-mail]>
> >      >>>>>> https://www.ietf.org/mailman/listinfo/lsr
> >      >>>>>
> >      >>>>>
> >      >>>>
> >      >>>> _______________________________________________
> >      >>>> Lsr mailing list
> >      >>>> [e-mail] <mailto:[e-mail]>
> >      >>>> https://www.ietf.org/mailman/listinfo/lsr
> >      >>>
> >      >>>
> >      >>
> >      >> _______________________________________________
> >      >> Lsr mailing list
> >      >> [e-mail] <mailto:[e-mail]>
> >      >> https://www.ietf.org/mailman/listinfo/lsr
> >      >
> >      >
> >
> >     _______________________________________________
> >     Lsr mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/lsr
> >
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr