Re: [Lsr] draft-ietf-lsr-flex-algo

[Gyan Mishra <[e-mail]>]

On Wed, May 20, 2020 at 4:16 AM Peter Psenak <[e-mail]> wrote:

> On 20/05/2020 00:37, Gyan Mishra wrote:
> >
> >
> >
> > On Tue, May 19, 2020 at 3:38 AM Peter Psenak <[e-mail]
> > <mailto:[e-mail]>> 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.


   Gyan> That is what I was expecting. So the flex algo draft talks in the
context of SR-MPLS and SRV6 as those are the two data planes currently
supported.  Any other data planes would require development of a
specification to use flex algo, but more so an industry business need or
gap that is being filled with the development.  SRv6 has more ubiquitous
use cases then SR-MPLS, so both together cover most every use case
requiring steering.  So then is their a need to steer with native IPV4 or
IPV6.

>
>
> >
> > 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)
> >      > <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail]
> >     <mailto:[e-mail]>>> wrote:
> >      >
> >      >     Jeff, I see what you said, thank you for sharing
> information;____
> >      >
> >      >     __ __
> >      >
> >      >     __ __
> >      >
> >      >     __ __
> >      >
> >      >     Cheers!
> >      >
> >      >     ____
> >      >
> >      >     __ __
> >      >
> >      >     Wang Weibin____
> >      >
> >      >     __ __
> >      >
> >      >     *From:* Jeff Tantsura <[e-mail]
> >     <mailto:[e-mail]>
> >      >     <mailto:[e-mail]
> >     <mailto:[e-mail]>>>
> >      >     *Sent:* 2020年5月10日 3:24
> >      >     *To:* Wang, Weibin (NSB - CN/Shanghai)
> >     <[e-mail] <mailto:[e-mail]>
> >      >     <mailto:[e-mail]
> >     <mailto:[e-mail]>>>
> >      >     *Cc:* Ketan Talaulikar (ketant) <[e-mail]
> >     <mailto:[e-mail]>
> >      >     <mailto:[e-mail] <mailto:[e-mail]>>>;
> >     [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      >     *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)
> >      >         <[e-mail]
> >     <mailto:[e-mail]>
> >      >         <mailto:[e-mail]
> >     <mailto:[e-mail]>>> wrote:____
> >      >
> >      >         ____
> >      >
> >      >         Ketan, thank you for clarification.____
> >      >
> >      >         ____
> >      >
> >      >         ____
> >      >
> >      >         ____
> >      >
> >      >         Cheers!____
> >      >
> >      >         ____
> >      >
> >      >         Wang Weibin____
> >      >
> >      >         ____
> >      >
> >      >         *From:* Ketan Talaulikar (ketant) <[e-mail]
> >     <mailto:[e-mail]>
> >      >         <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >         *Sent:* 2020年5月9日 14:52
> >      >         *To:* Wang, Weibin (NSB - CN/Shanghai)
> >      >         <[e-mail]
> >     <mailto:[e-mail]>
> >      >         <mailto:[e-mail]
> >     <mailto:[e-mail]>>>; [e-mail]
> >     <mailto:[e-mail]>
> >      >         <mailto:[e-mail] <mailto:lsr@ietf..org>>
> >      >         *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 <[e-mail]
> >     <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>>
> >      >         *On Behalf Of *Wang, Weibin (NSB - CN/Shanghai)
> >      >         *Sent:* 08 May 2020 19:07
> >      >         *To:* [e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >         *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
> >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      > https://www.ietf.org/mailman/listinfo/lsr____
> >      >
> >      >     _______________________________________________
> >      >     Lsr mailing list
> >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      > https://www.ietf.org/mailman/listinfo/lsr
> >      >
> >      > --
> >      >
> >      > Gyan  Mishra
> >      >
> >      > Network Engineering & Technology
> >      >
> >      > Verizon
> >      >
> >      > Silver Spring, MD 20904
> >      >
> >      > Phone: [phone]
> >      >
> >      > Email: [e-mail]
> >     <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      >
> >      >
> >      >
> >
> > --
> >
> > <http://www.verizon.com/>
> >
> > *Gyan Mishra*
> >
> > /Network Solutions A//rchitect /
> >
> > /M 301 502-1347
> > 13101 Columbia Pike
> > /Silver Spring, MD
> >
> >
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD