Thx,
R.
On Mon, Oct 12, 2020 at 10:47 AM Peter Psenak
<ppsenak=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org>>
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:jefftant.i...@gmail.com
<mailto:jefftant.i...@gmail.com>]
>> Sent: Sunday, October 11, 2020 3:14 AM
>> To: Ron Bonica <rbon...@juniper.net <mailto:rbon...@juniper.net>>
>> Cc: Dongjie (Jimmy) <jie.d...@huawei.com
<mailto:jie.d...@huawei.com>>; Peter Psenak
>> <ppse...@cisco.com <mailto:ppse...@cisco.com>>; Yingzhen Qu
<yingzhen...@futurewei.com <mailto:yingzhen...@futurewei.com>>; Gyan
>> Mishra <hayabusa...@gmail.com <mailto:hayabusa...@gmail.com>>;
lsr@ietf.org <mailto:lsr@ietf.org>
>> 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 <rbon...@juniper.net
<mailto:rbon...@juniper.net>> wrote:
>>>
>>> Hi Jimmie,
>>>
>>> Inline.....
>>>
>>> Ron
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> -----Original Message-----
>>> From: Dongjie (Jimmy) <jie.d...@huawei.com
<mailto:jie.d...@huawei.com>>
>>> Sent: Friday, October 9, 2020 11:06 PM
>>> To: Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>>; Ron Bonica
>>> <rbon...@juniper.net <mailto:rbon...@juniper.net>>; Yingzhen Qu
<yingzhen...@futurewei.com <mailto:yingzhen...@futurewei.com>>; Gyan
>>> Mishra <hayabusa...@gmail.com <mailto:hayabusa...@gmail.com>>
>>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Jeff Tantsura
<jefftant.i...@gmail.com <mailto:jefftant.i...@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-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>] On Behalf Of Peter Psenak
>>>> Sent: Friday, October 9, 2020 11:58 PM
>>>> To: Dongjie (Jimmy) <jie.d...@huawei.com
<mailto:jie.d...@huawei.com>>; Ron Bonica
>>>> <rbonica=40juniper....@dmarc.ietf.org
<mailto:40juniper....@dmarc.ietf.org>>; Yingzhen Qu
>>>> <yingzhen...@futurewei.com
<mailto:yingzhen...@futurewei.com>>; Gyan Mishra
<hayabusa...@gmail.com <mailto:hayabusa...@gmail.com>>
>>>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Jeff Tantsura
<jefftant.i...@gmail.com <mailto:jefftant.i...@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-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>] On Behalf Of Ron Bonica
>>>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>>>> To: Yingzhen Qu <yingzhen...@futurewei.com
<mailto:yingzhen...@futurewei.com>>; Peter Psenak
>>>>>> <ppse...@cisco.com <mailto:ppse...@cisco.com>>; Gyan Mishra
<hayabusa...@gmail.com <mailto:hayabusa...@gmail.com>>
>>>>>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Jeff Tantsura
<jefftant.i...@gmail.com <mailto:jefftant.i...@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...@futurewei.com
<mailto:yingzhen...@futurewei.com>>
>>>>>> Sent: Saturday, October 3, 2020 2:08 PM
>>>>>> To: Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>>; Gyan Mishra
>>>>>> <hayabusa...@gmail.com <mailto:hayabusa...@gmail.com>>; Ron
Bonica <rbon...@juniper.net <mailto:rbon...@juniper.net>>
>>>>>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Jeff Tantsura
<jefftant.i...@gmail.com <mailto:jefftant.i...@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" <ppse...@cisco.com
<mailto:ppse...@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-boun...@ietf.org <mailto:lsr-boun...@ietf.org> on behalf of
>>>>>> ppsenak=40cisco....@dmarc.ietf.org
<mailto:40cisco....@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 <mailto:Lsr@ietf.org>
>>>>>>>
>>>>>>
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&data
>>>>>> =
>>>> 0
>>>>>> 2
>>>>>>
>>>>
>> *7C01*7Cyingzhen.qu*40futurewei.com
<http://40futurewei.com>*7Cfe03124c6e414e067c2008d86781
>>>>>>
>>>>
>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986
>>>>>>
>>>>
>> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D
>>>>>>
>>>>
>>
&reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR
>>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Lsr mailing list
>>>>>> Lsr@ietf.org <mailto: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 <mailto:Lsr@ietf.org>
>>>>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>>>> _
>>>>
>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz2
>> 18C
>>>> E
>>>> 8S8XzlIxAA$
>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
