Hi Uma,
On 17/07/18 08:56 , Uma Chunduri wrote:
Hi Ketan,
In-line [Uma]:
--
Uma C.
-----Original Message-----
From: Ketan Talaulikar (ketant) [mailto:[email protected]]
Sent: Tuesday, July 17, 2018 7:13 AM
To: Uma Chunduri <[email protected]>; [email protected]
Cc: [email protected]
Subject: Concerns with draft-chunduri-lsr-isis-preferred-path-routing
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.
[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.
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
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
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
