Subject: [spring] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 17 Jul 2018 11:13:27 +0000

Hi Uma,

I would like share more context on the concerns that I raised on this proposal in LSR WG yesterday where we could not complete our discussion on the mike due to time constraints.

IGPs were originally invented for topology computation and then route programming based on the SPT computed. We've extended IGPs to carry/flood information and this includes information that were meant for various applications. IGPs always do distribute topology computation - that is the core principle.

The PPR proposal takes IGPs into the area of flooding p2p paths and then setting up forwarding state along the path - essentially introducing path provisioning capabilities into it. Essentially adding a new functionality that is NOT distributed topology computation.

For clarity, I could summarize the PPR as follows (please correct if wrong):
- Someone (head-end or controller) computes a SR Path which is expressed as a SID List (it's a list of EROs just like in RSVP-TE - loose or strict)
- The head-end floods this SR Path (and its EROs) into the IGP domain so all routers in the area get the P2P paths computed by all head-ends
- Each router then must look at every such SR Path flooded by every router and examine if it is part of the ERO list; if so then it needs to program the forwarding state for that PPR id (aka label)
- The headend can then just look at this like a "tunnel" and do something like IGP shortcut to the destination behind it

This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p path state pervasively. Consider the kind of flooding scale and challenges when all these SR Paths go to every router irrespective of whether they need/use it. Then on top of that, we are proposing IGPs to program a local cross-connect if they are on that SR Path.

My question is, why not just use RSVP-TE in this case? RSVP-TE does signalling but it does it only on the nodes that matter for a specific LSP. 

This is called SR but it introduces a forwarding state on each of the hops (i.e. the PPR label cross-connect) - something different from SR architecture. Including SPRING group as well for the review of this proposed SR solution.

Seems like a mishmash of SR and RSVP-TE to me and I am concerned about where this takes IGPs.

Thanks,
Ketan

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 17 Jul 2018 12:56:59 +0000

Hi Ketan,

In-line [Uma]:
--
Uma C.

-----Original Message-----
From: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2018 7:13 AM
To: Uma Chunduri <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Hi Uma,

This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p path state pervasively. Consider the kind of flooding scale and challenges when all these SR Paths go to every router irrespective of whether they need/use it. Then on top of that, we are proposing IGPs to program a local cross-connect if they are on that SR Path. My question is, why not just use RSVP-TE in this case? RSVP-TE does signalling but it does it only on the nodes that matter for a specific LSP. 

[Uma]:  This helps in deployments, who is seeking source routing paradigm, but SID stack on the packet is unsustainable. This statement is applicable for both MPLS and IPv6 case. 
                 Coming to the EROs in IGP - it was there in SR drafts, including as working group draft for 3 years.  But what completely lacked was how to use those. There are significant differences in the format and importantly usage to solve various issues including hardware 
                Compatibilities of various line cards (and hence available paths), MTU and line rate issues. I don't think you can use RSVP-TE to solve these SR issues.

This is called SR but it introduces a forwarding state on each of the hops (i.e. the PPR label cross-connect) - something different from SR architecture. 

[Uma]:  You already introduced per path state in various cases (binding sids to local policy, flex-algo).  This has been discussed lately as part of re-chartering discussion. 
                 This thread discusses that in detail and I fully concur what Dave said here https://www.ietf.org/mail-archive/web/spring/current/msg03794.html

---

From: Peter Psenak <[email-masked]>
Date: Tue, 17 Jul 2018 09:33:52 -0400

Hi Uma,

> In-line [Uma]:

flex-algo is NOT a per path state. It's a regular prefix-SID, which is 
bound to a prefix only.

The problem with your proposal is that you flood all paths to all 
routers in the area and ask every router to evaluate all of them and see 
which of them may apply. This scale poorly.

thanks,
Peter

> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> .
>

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 17 Jul 2018 13:43:10 +0000

Hi Peter,

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2018 9:34 AM
To: Uma Chunduri <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

	> flex-algo is NOT a per path state. It's a regular prefix-SID, which is bound to a prefix only.

Not quite. I will come back to this bit later.

	>The problem with your proposal is that you flood all paths to all routers in the area and ask every router to evaluate all of them and see which of them may apply. This scale poorly.

Please see Section 6, in 01 version.

--
Uma C.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 17 Jul 2018 14:55:22 +0000

Hi Uma,

Please check inline below.

Thanks,
Ketan

-----Original Message-----
From: Uma Chunduri <[email-masked]> 
Sent: 17 July 2018 08:57
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Hi Ketan,

In-line [Uma]:
--
Uma C.

-----Original Message-----
From: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2018 7:13 AM
To: Uma Chunduri <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Hi Uma,

[Uma]:  This helps in deployments, who is seeking source routing paradigm, but SID stack on the packet is unsustainable. This statement is applicable for both MPLS and IPv6 case. 
[KT] Could we look at why the SID stack is getting "unsustainable" in the first place?

                 Coming to the EROs in IGP - it was there in SR drafts, including as working group draft for 3 years.  But what completely lacked was how to use those.
[KT] Right and I never thought/realized that this was the purpose of those EROs. I repeat the scale challenge and that you are proposing to re-purpose IGPs for programming MPLS cross-connects for hop-by-hop LSP setup. This is my concern.

 There are significant differences in the format and importantly usage to solve various issues including hardware 
                Compatibilities of various line cards (and hence available paths), MTU and line rate issues. I don't think you can use RSVP-TE to solve these SR issues.

[Uma]:  You already introduced per path state in various cases (binding sids to local policy, flex-algo).  This has been discussed lately as part of re-chartering discussion. 
                 This thread discusses that in detail and I fully concur what Dave said here https://www.ietf.org/mail-archive/web/spring/current/msg03794.html 
[KT] Dave's argument was in multicast context while he was giving the p2p example perhaps as a worst case theoretical example. IMHO we should not look at such worst case scenarios. To me, this is a hybrid proposal to bring a hop by hop path (which is why the SID stack is so huge) like in RSVP-TE into an SR network and then try to figure out a way to do this in IGPs. You can feel free to disagree :-)

Thanks,
Ketan

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 17 Jul 2018 17:37:27 +0000

Uma -

I share the concerns expressed by Ketan and Peter.

Although I will certainly consider the additional response you seem to have hinted at in your reply to Peter, it seems to me that Section 6 of your draft acknowledges that there is a scaling problem - and then references what seems to be a non-existent draft (I could not find "draft-ce-ppr-graph-00" ???) as a proposed solution.

In any further response you make it would be good if you did indicate whether you agree PPR has a scaling issue - and given the contents of Section 6 of your draft - also discuss why we should consider PPR + some additional scaling enhancements when we already have at least one solution which does scale linearly.

Thanx.

    Les

> From: Lsr <[email-masked]> On Behalf Of Uma Chunduri
> Sent: Tuesday, July 17, 2018 6:43 AM
> To: Peter Psenak (ppsenak) <[email-masked]>; Ketan Talaulikar (ketant)
> <[email-masked]>; [email-masked]
> Cc: [email-masked]
> 	>The problem with your proposal is that you flood all paths to all routers
> in the area and ask every router to evaluate all of them and see which of them
> may apply. This scale poorly.
>

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 17 Jul 2018 14:40:06 -0400

> [Uma]:  This helps in deployments, who is seeking source
routing paradigm, but SID stack on the packet is unsustainable. This
statement is applicable for both MPLS and IPv6 case.

                >[KT] Could we look at why the SID stack is getting
"unsustainable" in the first place?

I am not sure what you want to look - plz don't ask topology of a
particular deployment and how the SRH/SR-MPLS path is crafted?

Please see the generic example and some of the references in the draft.  You
have to tell me the issues summarized for various deployments (including
brownfield scenarios) are not an issue.

If this is not an issue there is no need for MSD capability either and all
the hoops to discover this capability and work around. I don't think you  can
definitely say, you can limit X SR SIDs in SRH and Y labels etc..

                 >[KT] Dave's argument was in multicast context while he
was giving the p2p example perhaps as a worst case theoretical example.
IMHO we should not look at such worst case scenarios.

                 >To me, this is a hybrid proposal to bring a hop by hop
path (which is why the SID stack is so huge) like in RSVP-TE into an SR
network and then try to figure out a way to do this in IGPs. You can feel
free to disagree :-)

This is not the worst case scenario (I just referred to the thread overall
and discussion of adding a FIB entry is considered OK and being argued it
is not OK stating that as considered as  "state" - I feel at some level we
are confusing with this and the soft state and refresh required thereof );
it could be the base scenario, depending on the deployment.

--

Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 17 Jul 2018 14:43:38 -0400

Les -

in-line

..

>
> Although I will certainly consider the additional response you seem to
> have hinted at in your reply to Peter, it seems to me that Section 6 of
> your draft acknowledges that there is a scaling problem

[Uma]:  What it says is there is no scale issue in certain deployments
where only limited number of pats are required (examples given).  In that
case you don't need any *further extensions* as referred.
              As we noted this is fully backward compatible for SR-MPLS and
SRH data planes and one can go ahead and use it one can't find a path and
SID depth is an issue (in terms of  any of these, HW compatibility, Line
rate, header tax or MTU).

> - and then references what seems to be a non-existent draft (I could not
> find "draft-ce-ppr-graph-00" ???) as a proposed solution.
>

[Uma]: This will be posted soon, few things are being worked out. This
helps in certain cases (you will see soon), where you want to scale
optimized paths.

>
> In any further response you make it would be good if you did indicate
> whether you agree PPR has a scaling issue -

[Uma]: Plz see above..

---

From: Peter Psenak <[email-masked]>
Date: Wed, 18 Jul 2018 11:23:34 -0400

Hi Uma,

> Not quite. I will come back to this bit later.

please do so, as I don't know what do you mean by "Not quite".

> Please see Section 6, in 01 version.

the section 6 points to a solution that does not exist as of yet. I can 
only comment once it is available, but the fact that you need an extra 
hooks to address the scalability just confirms the limited scaling 
property of the basic proposal.

thanks,
Peter