Many thx,
R.
On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak
<[email protected] <mailto:[email protected]>>
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:[email protected]
<mailto:[email protected]>] On Behalf Of Peter Psenak
>> Sent: Monday, October 12, 2020 4:39 PM
>> To: Dongjie (Jimmy) <[email protected]
<mailto:[email protected]>>; Ron Bonica
>> <[email protected] <mailto:[email protected]>>; Yingzhen Qu
<[email protected] <mailto:[email protected]>>; Gyan
>> Mishra <[email protected] <mailto:[email protected]>>
>> Cc: [email protected] <mailto:[email protected]>; Jeff Tantsura
<[email protected] <mailto:[email protected]>>
>> 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:[email protected]
<mailto:[email protected]>] On Behalf Of Peter Psenak
>>>> Sent: Friday, October 9, 2020 11:58 PM
>>>> To: Dongjie (Jimmy) <[email protected]
<mailto:[email protected]>>; Ron Bonica
>>>> <[email protected]
<mailto:[email protected]>>; Yingzhen Qu
>>>> <[email protected]
<mailto:[email protected]>>; Gyan Mishra
<[email protected] <mailto:[email protected]>>
>>>> Cc: [email protected] <mailto:[email protected]>; Jeff Tantsura
<[email protected] <mailto:[email protected]>>
>>>> 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:[email protected]
<mailto:[email protected]>] On Behalf Of Ron Bonica
>>>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>>>> To: Yingzhen Qu <[email protected]
<mailto:[email protected]>>; Peter Psenak
>>>>>> <[email protected] <mailto:[email protected]>>; Gyan Mishra
<[email protected] <mailto:[email protected]>>
>>>>>> Cc: [email protected] <mailto:[email protected]>; Jeff Tantsura
<[email protected] <mailto:[email protected]>>
>>>>>> 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 <[email protected]
<mailto:[email protected]>>
>>>>>> Sent: Saturday, October 3, 2020 2:08 PM
>>>>>> To: Peter Psenak <[email protected]
<mailto:[email protected]>>; Gyan Mishra
>>>>>> <[email protected] <mailto:[email protected]>>; Ron
Bonica <[email protected] <mailto:[email protected]>>
>>>>>> Cc: [email protected] <mailto:[email protected]>; Jeff Tantsura
<[email protected] <mailto:[email protected]>>
>>>>>> 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" <[email protected]
<mailto:[email protected]>> 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"
>>>>>> <[email protected] <mailto:[email protected]> on behalf of
>>>>>> [email protected]
<mailto:[email protected]>>
>>>>>> 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
>>>>>> > [email protected] <mailto:[email protected]>
>>>>>> >
>>>>>>
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
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/lsr
>
>
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
