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

Thanks Ron, indeed!  Autocorrect works in mysterious ways  ;-)

Regards,
Jeff

> On Oct 11, 2020, at 09:41, Ron Bonica <rbonica@juniper.net> wrote:
> 
> Jeff,
> 
> I think that you mean the scope is different..... 
> 
>                                     Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Jeff Tantsura <jefftant.ietf@gmail.com> 
> Sent: Saturday, October 10, 2020 3:14 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Peter Psenak <ppsenak@cisco.com>; Yingzhen Qu <yingzhen.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com>; lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> 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 <rbonica@juniper.net> wrote:
>> 
>> Hi Jimmie,
>> 
>> Inline.....
>> 
>>                   Ron
>> 
>> 
>> Juniper Business Use Only
>> 
>> -----Original Message-----
>> From: Dongjie (Jimmy) <jie.dong@huawei.com>
>> Sent: Friday, October 9, 2020 11:06 PM
>> To: Peter Psenak <ppsenak@cisco.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
>> 
>> [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: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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H
>>>>> z218CE8S8XzlIxAA$
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>>> _ 
>>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218C
>>> E
>>> 8S8XzlIxAA$