On 08/12/2016 01:00, Robert Raszuk wrote:
Dear Stewart,
On Wed, Dec 7, 2016 at 12:03 PM, Stewart Bryant
<[email protected] <mailto:[email protected]>> wrote:
Using a RSVP-TE tunnel to provide an LDP FRR solution is well
known and deployed.
I was not particularly advocating this, indeed as you know I have spent
many years looking at alternatives. Perhaps I misread the draft, we are
discussing, but I read the draft and saw the presentation at IETF97 and
the draft seems to be proposing this very idea. I was trying to give it
its proper context.
That said, it maybe that by using an appropriate mix of modern
distributed and centralized path computation the deployment issues that
concern you become addressed.
That may or may not be the case. Yes we (well some of us) have been
involved for decades in making those solutions to somehow work in a
very very limited real production scale (if at all). One hop LSPs for
FRR have been sporadically deployed in very few cases. Yet the
overhead associated with such endeavor is significant especially in
OPEX cost and training of internal teams to maintain it.
Those who just focus on vendor's world may not always realize this.
What works on the ppt, rfc or patent turns often very costly in real
deployments.
RSVP-TE extensions or LDP are both redundant and frankly unnecessary
protocols and the sooner we get rid of those the better. They bring no
value and to all of us who have been involved in defining and
deploying those this should be of no surprise. It is only those who
has been heavily infected by various marketing forces think overwise.
That is a much wider discussion.
My reading of your statement is that you are proposing the deprecation
of RSVP-TE and LDP. If that is case, then that is a much wider and
deeper discussion for the MPLS WG.
Therefor I do object using terms of "well known or deployed" as any
form of judgement of new work in any form. Even so without real data
on how well know or wide deployed that would be. And even if it is
deployed in few places this is no reason not to recommend improvements
even if those would result in innovative proposals.
Indeed, there are many innovations that can be applied to FRR. My point
to the authors was to look at the work that has been published in the
IETF and build on it.
As to your comments on speed and compute costs let's do realize that
what have been a factor 5 or 10 years ago where everything needed to
run on weak REs today computation is done outside of network elements.
And while we are not there in mass scale the number of modern vendors
which I am testing do have very significant innovations in control
plane computing paradigms .. something which we never imagined x years
back.
I seem to remember proposing splitting compute from routers in the
generation being designed 17 years ago and using best in class computing
systems rather than compute power that would fit on a blade. The idea
was not acceptable then. Every idea has to live in it's own time.
However going forward what is needed is a mixture of both distributed,
autonomous operation and remote compute operation, and I don't think it
is yet clear what the structure of the design needs to look like.
Yes your point may very well be valid that we will still find nits to
work and fix down the road, but those again are not in any rationale
sense to stop the work or adjust it to status quo. It is like you
would still prefer to cross Atlantic using Titanic as opposed to kill
380 or 787s just because it is no a ship.
I am not saying that. I think you need to re-read what I have written.
Bottom line .. I highly support TI-LFA even if for some vendors it
means departure from their years of selling RSVP/LDP mantra.
I am not arguing against TI-LFA in this thread, although I do have
concerns about some aspects of that work, which I am sure we will
discuss at some point.
An approach that I think might be reasonable, and I get the impression
that this is where the authors are headed, is to look at how to do node
repairs in a repair technology independent way. Whether one implements
the repair by a explicit hard path, or a soft path, and how you set up
that path is independent of this calculation. However I would hope that
the draft would build upon what we have already published rather than
start from scratch.
- Stewart
Yours,
Robert.
The specific case of node protection is
called out in Figure 3 of RFC4090. I am surprised that the
complete solution is not documented, but if that is the case
it should be, with proper attribution.
Getting the next next hop label set is problematic, the standard
solution
needing a targetted LDP session to each NNH. There was a proposal
to address this proposed draft-shen-mpls-ldp-nnhop-label-02 which
is worth examining.
The method of finding the next next hop is well documented
for example in RFC6981 and these should be referenced at least in the
development phase of this work to allow cross checking.
"The discovery of the next next-hop (depending
on an implementation) may not involve any additional SPF, above and
beyond what would be needed by ISIS/OSPF anyway, as the next next-
hop, just like the next-hop, is a by-product of SPF computation."
That is what I thought when I started work on IPFRR, but it is
very much
dependent on the speed and memory optimizations used and because this
information is not needed for normal operation it is often discarded.
" If
for a given <LSP, PLR, N> triplet the node protected by the PLR
is an
Area Border Router (ABR), then the PLR and the next next-hop
may end
up in different IGP areas (this could happen when an LSP traversing
the PLR and the protected node does not terminate in the same IGP
area as the PLR). In this situation the PLR may not be able to
determine the next next-hop from either its Traffic Engineering
database or Link State database, and thus may not be able to
use the
next next-hop as the MPT. In this scenario the PLR uses an
"alternative" ABR as the MPT, where an alternative ABR is
defined as
follows. For a given LSP that traverses the PLR and the (protected)
ABR, an alternative ABR is defined as any ABR that advertises into
PLR's own IGP area reachability to the FEC associated with the LSP.
Note that even if a PLR protects an ABR, for some of the LSPs
traversing the PLR and the ABR, the next next-hops may be in
the same
IGP area as the PLR, in which case these next next-hops act as MPTs
for these LSPs. Note that even if the protected node is not an ABR,
if an LSP traversing the PLR and the protected node does not
terminate in the same IGP area as the PLR, then for this LSP
the PLR
MAY use an alternative ABR (as defined above), rather than the next
next-hop as the MPT. "
In a general solution, I would like to see this written so that it is
OSPF/ISIS agnostic.
This an example of the general case of multi-homed prefixes.
Addressing
MHP requires that egress be forced to prevent packet looping.
"4. Constructing Bypass LSPs"
There is quite a lot of work on the calculation of node avoiding paths
that you should look at, for example RFC6981 to verify that nothing
has been forgotten.
" 5. Obtaining Label Mapping from MPT"
Again it is worth looking at existing work in this space.
"6. Forwarding Considerations
When a PLR detects failure of the protected node then rather than
swapping an incoming label with a label that the PLR received from
the protected node, the PLR swap the incoming label with the label
that the PLR receives from the MPT, and then pushes the label
associated with the bypass LSP to that MPT. To minimize micro-loop
during the IGP global convergence PLR may continue to use the
bypass
LSP during network convergence by adding small delay before
switching
to a new path."
It is nowhere as simple as that. Again there is a lot of writing
on the
subject. For example RFC5715.
Sure you need to keep the repair path in place and using an RSVP-TE
tunnel means that you will not suffer the problem of microlooping
along
that tunnel. What you need to be clear about is that you are not
protecting against any other microloop, for example between hop
PLR-1 and PLR-2.
- Stewart
_______________________________________________
mpls mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mpls
<https://www.ietf.org/mailman/listinfo/mpls>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
