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.
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]>> wrote:
Jeff, I see what you said, thank you for sharing information;____
__ __
__ __
__ __
Cheers!
____
__ __
Wang Weibin____
__ __
*From:* Jeff Tantsura <[email protected]
<mailto:[email protected]>>
*Sent:* 2020年5月10日 3:24
*To:* Wang, Weibin (NSB - CN/Shanghai) <[email protected]
<mailto:[email protected]>>
*Cc:* Ketan Talaulikar (ketant) <[email protected]
<mailto:[email protected]>>; [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]>> wrote:____
____
Ketan, thank you for clarification.____
____
____
____
Cheers!____
____
Wang Weibin____
____
*From:* Ketan Talaulikar (ketant) <[email protected]
<mailto:[email protected]>>
*Sent:* 2020年5月9日 14:52
*To:* Wang, Weibin (NSB - CN/Shanghai)
<[email protected]
<mailto:[email protected]>>; [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]>>
*On Behalf Of *Wang, Weibin (NSB - CN/Shanghai)
*Sent:* 08 May 2020 19:07
*To:* [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]>
https://www.ietf.org/mailman/listinfo/lsr____
_______________________________________________
Lsr mailing list
[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]>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
