Hi Jimmy,

On 14/10/2020 10:38, Dongjie (Jimmy) wrote:
Hi Peter,

-----Original Message-----
From: Peter Psenak [mailto:[email protected]]
Sent: Tuesday, October 13, 2020 4:53 PM
To: Dongjie (Jimmy) <[email protected]>; Ron Bonica
<[email protected]>; Yingzhen Qu <[email protected]>; Gyan
Mishra <[email protected]>
Cc: [email protected]; Jeff Tantsura <[email protected]>
Subject: Re: [Lsr] FW: New Version Notification for
draft-bonica-lsr-ip-flexalgo-00.txt

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.

OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 
considered the same or different apps?

these are considered as single app, and share the same participation signaling. Please note that SRv6 support is signaled independently of FA participation.


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.

If the participation is topology specific, do you mean IPv4 and IPv6 could be 
distinguished by advertising Flex-Algo participation with different Topology 
IDs (MT-ID)? This way, is the topology ID actually used as the address family 
distinguisher?

Yes, one can signal participation for each topology and each MT topology is associated with one or AF. But let not speculate here and let authors decide.

thanks,
Peter


Best regards,
Jie

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]] On Behalf Of Peter Psenak
Sent: Friday, October 9, 2020 11:58 PM
To: Dongjie (Jimmy) <[email protected]>; Ron Bonica
<[email protected]>; Yingzhen Qu
<[email protected]>; Gyan Mishra <[email protected]>
Cc: [email protected]; Jeff Tantsura <[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]] On Behalf Of Ron Bonica
Sent: Sunday, October 4, 2020 4:34 AM
To: Yingzhen Qu <[email protected]>; Peter Psenak
<[email protected]>; Gyan Mishra <[email protected]>
Cc: [email protected]; Jeff Tantsura <[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]>
Sent: Saturday, October 3, 2020 2:08 PM
To: Peter Psenak <[email protected]>; Gyan Mishra
<[email protected]>; Ron Bonica <[email protected]>
Cc: [email protected]; Jeff Tantsura <[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]> 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] on behalf of
[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]
        >
https://urldefense.com/v3/__https://nam11.safelinks.protection.ou
tl
oo
k.com/
?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&amp;da
ta
=
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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr



_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr



_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr






_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to