[Teas] PRR complement to SR-6Man carryover

[Gyan Mishra <[e-mail]>]

in-line 

Overall I am very intrigued by what PPR is able to deliver as well as solve shortcomings of SR making both SR-MPLS and SRv6 a more viable proposition for operators. Definitely worthwhile to setup a call to go over the PPR proposal.  I was supposed to get together with Uma but hopefully now we can schedule.


Thanks, Gyan,

I don't dare to compare to Roberts draft, so just re. PPR inline.

On Thu, May 14, 2020 at 11:16:06AM -0400, Gyan Mishra wrote:
> Robert & Uma
> 
> As a compare and contrast of both of your control plane based steering
> proposals at a high level teas-is-te is really made to work completely
> independent of SR where PPR is truly meant  as complement to SR.
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.

I am not quite sure where e.g.: "no-SR" MPLS/IPv6 stops and where SR
exactly starts.  To me, PPR-IDs could be seen as a form of SIDs, in which
case it might be "extend SR", other may not agree, in which case it might
be "complement SR". Hopefully thats just a terminology question, maybe more
useful to first discuss functionality and then do terminology.

Gyan>Sounds good.

> Your steering is based on IGP extensions creating routing paths with a new
> concept of PPR path objects similar to RSVP TE ERO (Explicit Route Object)
> and RRO(Record Route object) used for FRR n:1 facility protection.

Not only paths but also graph object to be able to efficiently signal
and establish more efficient path steering with fewer than eg: O(N^2)
state/identifiers (which had been one of the issues when RSVP-TE was
used for SP-core capacity optimization).

Gyan> Understood with P2P links in RSVP you end with 2x link attributes in teds database, so with PPR more optimized with much less identifiers.

> PPR sounds like a much needed complement to SR both SR-MPLS and SRv6 due to
> MSD(maximum sid depth) issues incurred with SR-TE binding sid when adj sid
> strict paths are used instead of loose prefix sid resulting in a much
> larger data structure SID depth, resulting in MTU issues with very long
> strict paths.

PPR can be used with loose and strict semantic. The use-cases requiring
strict semantic such as path-diversity/high-resilience where certainly
starting points / motivators. MSD being a key issue, but i think not the
only one.

Gyan> I am interested to see what other SR issues are solved with PPR.  I have more questions on this topic which we can cover on a call.

> Most SR deployments both SRv6 and SR-MPLS it using SR-TE at all it is
> recommended to use centralized model with PCEP controller instantiation of
> the intent based routing traffic steering.
>
> However, is it true that if PPR is used that the use or SR-TE can become
> more viable with both SRv6 and SR-MPLS in distributed manual or hybrid
> model can overcome MSD issues?

Yes, PPR path calculation can be done centralized or decentralized.

I would explicitly avoid the term distributed for PPR, because to me,
distributed is the classical routing protocol model as we use it 
in IGP/BGP: There is no single-source of truth for a path but it
is calculated in a collaborative, coordinated "distributed" fashion.

Gyan> Understood 

In PPR, there is a single-source-of-truth for each path/graph.
But there does not need to be a single-source-of-truth for all paths/graphs.
Every PE for example can calculate and PPR originate paths/graphs for
itself, much like the original model we had with RSVP-TE headend-LSR.

PPR paths/graphs overcome the MSD issue, independent who calculates them,
centralized or decentralied/distributed.

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.  Can PPR be integrated with SR-TE or Flexalgo?

> 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