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

[Ron Bonica <[e-mail]>]

+1


Juniper Business Use Only

-----Original Message-----
From: Peter Psenak <ppsenak=[e-mail]> 
Sent: Friday, October 9, 2020 11:58 AM
To: Dongjie (Jimmy) <[e-mail]>; Ron Bonica <[e-mail]>; Yingzhen Qu <[e-mail]>; Gyan Mishra <[e-mail]>
Cc: [e-mail]; Jeff Tantsura <[e-mail]>
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]


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]] On Behalf Of Ron Bonica
>> Sent: Sunday, October 4, 2020 4:34 AM
>> To: Yingzhen Qu <[e-mail]>; Peter Psenak 
>> <[e-mail]>; Gyan Mishra <[e-mail]>
>> Cc: [e-mail]; Jeff Tantsura <[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]>
>> Sent: Saturday, October 3, 2020 2:08 PM
>> To: Peter Psenak <[e-mail]>; Gyan Mishra 
>> <[e-mail]>; Ron Bonica <[e-mail]>
>> Cc: [e-mail]; Jeff Tantsura <[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]> 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] on behalf of 
>> ppsenak=[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]
>>      >
>> 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
>> [e-mail]
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>> __;!!NEt6yMaO-gk!S3DZGr_DbCQIRsnq2hAgAtb2RlxErvd8T0WG7VHv21jDFU_ZFDhw
>> h7qVM_VUOLgJ$
>
>