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

[Toerless Eckert <[e-mail]>]

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 ... ;-)

[...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.

>  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. 

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.

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.

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