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

From: Gyan Mishra <[email-masked]>
Date: Thu, 14 May 2020 20:20:49 -0400

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 <[email-masked]>
> 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

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 15 May 2020 14:49:27 +0200

> 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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 May 2020 09:53:12 -0400

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

    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.

> it triggers PPR path creation resulting in per-segment creation of a FIB

    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.

    Gyan> Understood

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

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 15 May 2020 19:44:18 +0200

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

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

> 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
> path and other hops be let???s say low latency flex algo next hops.  And I

-- 
---
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Sun, 17 May 2020 20:46:35 -0700

Hi Gyan,

Thanks for your interest on this topic and bringing this out from 6man
discussions.

I am not sure even this is the right group for discussion as you raised
many topics below. But I will address other points any ways here.  I will

focus mostly on those, which were not fully covered by Toerless's response.

I would also summarize few  points here:

- PPR is a control plane mechanism (underlying IGP) for path steering. So,
naturally this is applicable to any underlying data plane i.e.,
Native-IPv6 (no extension headers), Native IPv4, SR-MPLS, SRv6 or in some
L2 networks.

- PPR is backward compatible with SR data planes and if used it brings
immediate relief for Strict path or "intent based paths", you indicated.
Path steering or routing on preferred path happens based on PPR-ID (PPR FWD
Identifier) as opposed individual SR SIDs. So you don't have to worry about
MSD issues.

- PPR Graph (one type is MP2P as defined
https://tools.ietf.org/html/draft-ce-lsr-ppr-graph-01), not only reduces
the number of total FIB entries required but paths can be better
managed from all ingress PEs to egress PE.

- Any controller plane mechanism like PCEP or BGP or netconf can provide
path steering too for native IPs, but you have to introduce per path touch
points at each segment. Remember, you also have to factor local nexthop
changes and fast-reroutes. Yes, these can be addressed through any
controller based approach but you need to spend additional RTTs and updated
all effected path for every change.

- If you care for RSVP-TE and ready to run additional control protocol in
the network, you can also use that for native IP (I saw extensions in TEAS
earlier).

There are strengths  in each case obviously, and it depends on what you
want and where you want certain features.

See in-line [Uma]:

--
Uma C.

> circumventing the MSD issue.

[Uma]: That's right. That is one use of PPR with SR data planes. Additional
no harm tool for operators in SR deployments. To roll this out you only

needs control plane upgrade (underlying IGP used).

Alternatively as you mentioned with PPR fib

> would now pick PPR FIB entry as a better path over SR-TE.

[Uma]:  Yes, you can do that.

PPR also has its

> of the regular TI-LFA for protection.

[Uma]: This is a bigger topic. But I will keep it brief.  You have two
benefits of using IGP calculated NH for PPR-ID (as opposed to controller
based
approaches) .

a) The first one if using locally computed LFA/RLFAs at PLR, activated when
link or node failure detected. And automatically using the IGP
re-convergence  for calculating the nexthops  without having to involving
the controller.

b)  Now, there is a specific advantage to use "TE aware backup paths" with
PPR graphs. More details here -
https://tools.ietf.org/html/draft-bryant-rtgwg-plfa-00 (presented in
RTGWG). This is useful when SLA guarantees are needed for few 5G cases.