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

[Toerless Eckert <[e-mail]>]

On Fri, May 15, 2020 at 09:53:12AM -0400, Gyan Mishra wrote:
>     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.

There may be a bit too much compression of concepts for me to be sure i
can decompress all of it. It sounds right, but maybe should go offline
over the points individually. I think everything is true if we do
path calculalations from a single point of truth centrally/decentralized,
if we try to do things distributed in the IGP, it nicely becomes more
autonomous, but we run up against a lot more complexities to achieve more
advanced steering/TE goals...

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

Yes, you could have a PCE run comparison header vs per-hop FIP entries
and see which one optimizes better, but i think you would very likely
for most use-cases to find easier upfront decision critera to avoid that
need. Feature / forwarding-plane support comparison will easily make
one option look more attractive than the other.

>     Gyan> Makes sense as alternative. In the case of integrated.   Since
> flex algo  can build cSPF based on latency or other constraints

I think its more precise to say that flexalgo can use latency as a metric
for SPF, and given how flexalgo is for link-state routing protocols,
a PCE can of course build cSPF on top.

Are you aware of actual deployments where latency is used as a metric
with just the IGP metrics (flexalgo or else) ? I am asking because
i would think that instead of leveraging the IGP, more complex
path policies are AFIK much more ikely only to be embedded today in
PCEs themselves.

Cheers
    Torless

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

-- 
---
[e-mail]