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

[Uma Chunduri <[e-mail]>]

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.


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

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



[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

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


[Uma]:  Yes, you can do that.


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.


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




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


>
>