On 20/05/2020 00:37, Gyan Mishra wrote:
On Tue, May 19, 2020 at 3:38 AM Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
Gyan,
On 19/05/2020 03:52, Gyan Mishra wrote:
>
> Flex algo is usually mentioned in the context of SR-TE to help
reduced
> SRH size to circumvent MSD issues for both SRV6 and SR-MPLS,
though segment list reduction may be seen as one of the benefits of the
flex-algo, it is certainly not the primary motivation behind it. The
primary motivation of flex-algo is to provide dynamic any to any
constrained based routing.
> however can
> the 0-127 flex algo extensions since it’s an IGP extension used
in any
> pure IP network independent of SR flavors SR-MPLS or SRv6.
SR/SRv6 is used as a dataplane. Any data plane can be used, if it
provides a way to route an algo specific traffic.
Gyan> Please clarify. I would think that since the flex algo
capability is part of the IGP independent of the data plane is what you
are saying, so any data plane can use the feature.
not really. You need to have a way to forward traffic for different
algos over different paths.
So you are saying even if it can that their maybe a data plane specific
algo awareness to be able to use or route the algo specific traffic. So
for example can native IPv4 or IPv6 date plane can it without any
specific algo awareness can it utilitize flex algo constraint based
steering.
if you have IP prefix P1 and you want to be able to send the traffic to
it via 3 different paths via native IPv4 network how would you do that?
Also others mentioned is their special hooks or programming
required to make it work with RSVP-TE or PPR.
I let RSVP experts to find a way how to use the flex-algo paths. I'm
sure there are ways to do so :)
thanks,
Peter
>
> Also can flex algo be used in conjunction with RSVP-TE or
PPR(preferred
> path routing).
same answer as above.
thanks,
Peter
>
> Kind regards
>
> Gyan
>
> On Sat, May 9, 2020 at 9:25 PM Wang, Weibin (NSB - CN/Shanghai)
> <[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
>
> Jeff, I see what you said, thank you for sharing information;____
>
> __ __
>
> __ __
>
> __ __
>
> Cheers!
>
> ____
>
> __ __
>
> Wang Weibin____
>
> __ __
>
> *From:* Jeff Tantsura <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> *Sent:* 2020年5月10日 3:24
> *To:* Wang, Weibin (NSB - CN/Shanghai)
<[email protected] <mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> *Cc:* Ketan Talaulikar (ketant) <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>;
[email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo____
>
> __ __
>
> Weibin,____
>
> __ __
>
> One could have an algo with MSD/ERLD as optimizations constrains,
> would be quite similar to colored links. Note - ERLD has
implemented
> node capabilities only, so all links on a node will have to be
> pruned.____
>
> The tradeoffs are - having centralized controller with global
view
> computing a path that meets the constraints(classical BGP-LS
+ PCEP
> scenario) vs building a dynamic topology of connected nodes that
> meet a set of constrains, in first case, change in
> topology/capabilities would cause path
recalculation/reoptimization
> on the PCE while in the second - IGP would recompute the topology
> locally.____
>
> __ __
>
> Regards,____
>
> Jeff____
>
>
>
> ____
>
> On May 9, 2020, at 01:27, Wang, Weibin (NSB - CN/Shanghai)
> <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>> wrote:____
>
> ____
>
> Ketan, thank you for clarification.____
>
> ____
>
> ____
>
> ____
>
> Cheers!____
>
> ____
>
> Wang Weibin____
>
> ____
>
> *From:* Ketan Talaulikar (ketant) <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> *Sent:* 2020年5月9日 14:52
> *To:* Wang, Weibin (NSB - CN/Shanghai)
> <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>; [email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> *Subject:* RE: draft-ietf-lsr-flex-algo____
>
> ____
>
> Hi Wang,____
>
> ____
>
> You are correct. Though I wouldn’t call it a goal but
rather a
> benefit/advantage – same applies to SR-MPLS where the label
> stack can be reduced.____
>
> ____
>
> Thanks,____
>
> Ketan____
>
> ____
>
> *From:* Lsr <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> *On Behalf Of *Wang, Weibin (NSB - CN/Shanghai)
> *Sent:* 08 May 2020 19:07
> *To:* [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> *Subject:* [Lsr] draft-ietf-lsr-flex-algo____
>
> ____
>
> Hi authors:____
>
> ____
>
> After reading through this draft lsr-flex-algo, I want to
know
> whether there is a potential goal of this draft to reduce the
> SRH size with enabling flex-algo with admin group in SRv6
> deployment, because without flex-algo we have to have a
big SRH
> size when the SRH include more SRv6 SIDs, if we enable
flex-algo
> under special topology and link constraint condition, in
theory
> we can even construct a end to end SR path/tunnel
without SRH,
> but it still meet TE requirement. So my question is
whether the
> flex-algo can be used as tool to reduce SRH size?____
>
> ____
>
> ____
>
> ____
>
> /Cheers !/____
>
> **____
>
> *WANG Weibin*____
>
> _______________________________________________
> Lsr mailing list
> [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> https://www.ietf.org/mailman/listinfo/lsr____
>
> _______________________________________________
> Lsr mailing list
> [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> Gyan Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
>
>
>
--
<http://www.verizon.com/>
*Gyan Mishra*
/Network Solutions A//rchitect /
/M 301 502-1347
13101 Columbia Pike
/Silver Spring, MD
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
