Re: [Teas] PRR complement to SR-6Man carryover

[Gyan Mishra <[e-mail]>]

On Fri, May 15, 2020 at 8:49 AM Toerless Eckert <[e-mail]> wrote:

> On Thu, May 14, 2020 at 08:20:49PM -0400, Gyan Mishra wrote:
> > I would say "complement/extend SR and beyond":
> >
> > PPR is intended to create consistent path-steering/traffic-engineering
> (PS/TE)
> > mechanisms across hopefully arbitrary forwarding planes, IPv6, IPv6+SRH,
> > MPLS, IPv4, and maybe even other forwarding planes, L2
> > or future forwarding planes.
> >
> > Gyan> With the PPR graph I am almost seeing similarities with BIER
> BIFT.  I might need some coffee.
>
> BIER/BIER-TE are more like SR in that they use source steering. BIER
> towards
> a list/set of destinations, whereas BIER-TE also via explicit steering
> hops.
> A PPR graph is rather a compression of entries required for per-steering
> hop FIB entries.
>
> Conceptual comparisons should of course be taken with a grain of salt.
> Wings in planes are like wheels in cars ... ;-)


    Gyan> Got it.

>
> [...snip...]
>
> > Gyan> So one of the major gains of SR is being able to do traffic
> coloring with SR TE per vrf flows having different color loose or strict
> paths. That is one of the major benefits of SRs intent based source PE
> node  routing instantiation of flows and not always on state as exists with
> MPLS.
>
> >  So now do you even have to use SR-TE for steering, or do now just
> offload all steering to PPR path/graph loose or strict computations.
>
> Fundamentally, if i have a steering path, i could either instantiate a FIB
> entry
> with a source-routing header insertion on the headend. Or i could
> instantiate a
> FIB entry for the policy on every segment node, and no source-routing
> header is needed.
>
> Depending on many circumstances, only one of the options may be feasible,
> or
> if both are feasible one or the other may have better use-case metrics.
> Eg:
> number of steering hops, number of paths, ability of the desired forwarding
> plane to support source-routing header, requirments to perform
> per-steering-hop
> traffic monitoring, QoS-policies (e.g.:detnet shaping), FRR with policy
> constraints, ...
>
> SR so far has nicely explored the benefits of steering via source routing
> headers,
> but IMHO, that is just one of the two core tool in the box and i think it
> would
> be good to also explore the benefits of using per segment FIB entries for
> steering with our
> evolving preferred control plane protocols (e.g.: IGP/BGP/PCEP, not
> LDP/RSVP-TE).
> Especially given how we know how to build FIB entries across all
> forwarding planes
> without HW changes, whereas we support source steering headers only for
> MPLS and IPv6.
>
> I don't think there is a single "one-size-fits-all" tool.
>


    Gyan> From the context of resolving the SR-TE issues with MSD for both
SRv6 and SR-MPLS, in that context is PPR graph forwarding tree that is
created - so now is the strict path now better optimized and fed back to
SR-TE construct to minimize the number of strict hops required thus
circumventing the MSD issue.  Alternatively as you mentioned with PPR fib
graph available and SR-TE the best optimized path can be chosen similar to
IGP  FIB admin distance or path selection algorithm similar to BGP that
would now pick PPR FIB entry as a better path over SR-TE.  PPR also has its
own TI LFA FRR backup path protection schema that would now be used instead
of the regular TI-LFA for protection.

>
> >  Can PPR be integrated with SR-TE or Flexalgo?
>
> Technically, PPR can definitely be integrated with SR-TE. One could even do
> it transparently: I could build a headend router that learns an SR policy
> via
> PCEP or BGP and instead of creating a FIB entry with a source-routing
> header,
> it triggers PPR path creation resulting in per-segment creation of a FIB
> entry
> for the  SR policy.
>

    Gyan>. Sounds like PPR is very flexible which is great for operators.
I think this answers how PPR would circumvent MSD issues.  So for MSD issue
resolution basically the PCE has both SRH paths as well as the PPR fib
graph and based on which is more optimized will pick to instantiate PPR fib
entry over SRH SID next hop which is now pushed to SR-TE to steer the now
optimized strict path with less hops thus eliminating the MSD issue.

>
> Of course, i wouldn't like to do it transparently this way, because the
> poor
> PCE might have spent huge amounts of CPU time trying to figure out the
> shortest
> possible segment-list to minimize steering header overhead, and that
> effort would have been wasted when using per-segment FIB entries as more
> steering hops do not create more overhead. Just to give an example that the
> choice of different tools usually implies different PCE optimizations.
>
> Whether or not a particular brand of Segment Routing welcomes the
> inclusion of
> path steering through per-segment FIB entries would be a whole other
> stakeholder
> discussion in the IETF. Given how "Traffic Engineering" or "Path Steering"
> seem to be more welcoming/inclusive technology terms, maybe its easier to
> evaluate PPR first in that context without assuminging a particular
> solution
> terminology.


    Gyan> Understood

>
>
> Wrt Flexalgo: Of course, its possible to integrate PPR with Flexalgo, but
> depending
> on the use-case, it may be more attractive to consider PPR also an a
> simpler
> and more flexible alternative to FlexAlgo. But that is more easily done
> through comparison of pro/cons for specific use-cases than in generality.
> I for once long worked on path-diversity-routing for (mostly) multicast
> use-cases in finance/video, and the use of logical topologies for those
> routing policies comes with limitation and complexitites. Other use-cases
> may have
> different evaluation outcomes.


    Gyan> Makes sense as alternative. In the case of integrated.   Since
flex algo  can build cSPF based on latency or other constraints in the
integration option for the cSPF you have both flexalgo and PPR running in
parallel for optimal fib entry for the next hop that SR-TR instantiates ;
 so along a strict path could some hops be PPR strict hops preferred best
path and other hops be let’s say low latency flex algo next hops.  And I
guess both in integrated option could also help circumvent the MSD issue.

>
>
> Cheers
>     Toerless
>
> > > One other question related to PPR I thought it used some of the major
> > > benefits of RSVP TE from a bandwidth management perspective with PCALC
> cSPF
> > > capability to provide bandwidth reservations static or auto bandwidth
> but
> > > now apply to non MPLS both IP and SR data planes.  I was trying to find
> > > that section in any of the PPR drafts but could not find.
> >
> > The drafts do i think not yet necessarily describe all the non-protocol
> > encoding pieces. also maybe better to take offline, or else 6man
> > asks us to go for a TEAS (a bit too much TE for this mailing list i
> fear).
> >
> > Cheers
> >     Toerless
> >
> > > Uma - I know we were supposed to go over PRR in depth and possible use
> > > cases for Verizon but things got hectic with Covid unfortunately.
> Maybe in
> > > the next few weeks or so we can plan a review meeting.
> > >
> > > Kind regards
> > >
> > > Gyan
> > >
> > > On Thu, May 14, 2020 at 7:42 AM Stewart Bryant <
> [e-mail]>
> > > wrote:
> > >
> > > > Yes
> > > >
> > > > PPR and SR (in whichever flavour) complement each other in useful
> ways,
> > > > and both have a place in networks.
> > > >
> > > > Stewart
> >
> >
> > Sent from my iPhone
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]