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

[Peter Psenak <[e-mail]>]

Robert,

On 12/10/2020 13:50, Robert Raszuk wrote:
> Hey Peter,
> 
> To me the application here is "avoid red links" regardless of choice of 
> encap in the data plane.
> 
> Does it really make sense to separate advertisements of SR flex-algo vs 
> IP flex-algo into separate TLVs ?

yes, please look at the base flex-algo spec. Each app must signal 
participation independently, as it may use a completely different data 
plane and one can not assume that all data planes are supported on any 
particular node. Think of BIER, etc. They may want to use flex-algo. I 
can not assume that a node running SR is capable of forwarding BIER packets.


> 
> Along the same linkes even for SR data plane can be SR-MPLS or SRv6. So 
> in the network running all three data planes you will need to compute 
> SPT for each flex-algo three times which may or may not be desired 
> especially if each algorithm would be as simple as to avoid certain link 
> color.
> 
> That goes to the point can dataplanes interwork in flex algo and it 
> seems that currently they can not if section 10.2 is interpreted as 
> application to be a tuple of data plane + topological constraints 
> (instead of only topological constraints).

application is orthogonal to constraints, constraints (e.g. FAD) is app 
independent.

Participation in flex-algo is app specific.

thanks,
Peter


> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> On Mon, Oct 12, 2020 at 10:47 AM Peter Psenak 
> <ppsenak=[e-mail] <mailto:[e-mail]>> 
> wrote:
> 
>     Hi Jimmy.
> 
>     On 12/10/2020 09:12, Dongjie (Jimmy) wrote:
>      > Hi Jeff,
>      >
>      > Thanks for your explanation. I understand that for different data
>     plane the SIDs or IP addresses have different scope, and will not
>     conflict in normal cases.
>      >
>      > My question is more about whether a computation node needs to
>     know and check which data plane is used by the intermediate nodes to
>     bind to the Flex-Algo? In another word, can an SR path computed
>     using Flex-Algo 128 go through an intermediate node which bind
>     Flex-Algo 128 to IP data plane?
> 
>     computation node MUST check the application specific participation in
>     flex-algo and participation advertisement is application specific. SR
>     and IP are different applications from flex-algo perspective.
> 
> 
>     draft-ietf-lsr-flex-algo-12, section 10.2:
> 
> 
>          Application-specific advertisement for Flex-Algorithm participation
>          MUST be defined for each application
> 
>     thanks,
>     Peter
> 
>      >
>      > Best regards,
>      > Jie
>      >
>      >> -----Original Message-----
>      >> From: Jeff Tantsura [mailto:[e-mail]
>     <mailto:[e-mail]>]
>      >> Sent: Sunday, October 11, 2020 3:14 AM
>      >> To: Ron Bonica <[e-mail] <mailto:[e-mail]>>
>      >> Cc: Dongjie (Jimmy) <[e-mail]
>     <mailto:[e-mail]>>; Peter Psenak
>      >> <[e-mail] <mailto:[e-mail]>>; Yingzhen Qu
>     <[e-mail] <mailto:[e-mail]>>; Gyan
>      >> Mishra <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>
>      >> Subject: Re: [Lsr] FW: New Version Notification for
>      >> draft-bonica-lsr-ip-flexalgo-00.txt
>      >>
>      >> 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]
>     <mailto:[e-mail]>> wrote:
>      >>>
>      >>> Hi Jimmie,
>      >>>
>      >>> Inline.....
>      >>>
>      >>>                     Ron
>      >>>
>      >>>
>      >>> Juniper Business Use Only
>      >>>
>      >>> -----Original Message-----
>      >>> From: Dongjie (Jimmy) <[e-mail]
>     <mailto:[e-mail]>>
>      >>> Sent: Friday, October 9, 2020 11:06 PM
>      >>> To: Peter Psenak <[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
>      >>>
>      >>> [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]
>     <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.
>      >>>>>>
>      >>>>>>                                          Ron
>      >>>>>>
>      >>>>>>
>      >>>>>> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>      >>>>>>
>      >> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_
>      >> H
>      >>>>>> z218CE8S8XzlIxAA$
>      >>>>>
>      >>>>>
>      >>>>
>      >>>> _______________________________________________
>      >>>> Lsr mailing list
>      >>>> [e-mail] <mailto:[e-mail]>
>      >>>>
>     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>      >>>> _
>      >>>>
>      >> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz2
>      >> 18C
>      >>>> E
>      >>>> 8S8XzlIxAA$
>      >
>      >
> 
>     _______________________________________________
>     Lsr mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/lsr
>