Fortunately, the authors of Remote LFA Draft do not have to resolve
these issues on their own, since we already defined them in our
relevant papers.
In order to not to read our full papers and searching the answers, I
copied here the relevant parts:
*Link-protecting rLFA condition:*
For source /s/, destination /d/, and next-hop /e/, some node /n/ /!=
s,d/ is a link-protecting remote LFA for the /s-d/ pair if and only if
/dist(s, n) < dist(s, e) + dist(e, n)/ (1)
/dist(n, d) < dist(n, s) + dist(s, d)/ (2)
In these equations, one can easily see, that (1) defines the P-space,
while (2) is the condition of Q-space. Furthermore, with these
formalized conditions, one can easily observe, that (2) is actually
the basic loop-free criterion of pure LFA.
*Link-protecting rLFA condition with extended P-space:*
For source /s/, destination /d/, and next-hop /e/, some node /n !=
s,d/ is an extended link-protecting remote LFA for the /s-d/ pair if
and only if
/?v ? neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)///
/dist(n, d) < dist(n, s) + dist(s, d) . /
*Node-protecting rLFA condition:*
For source /s/, destination /d/, and next-hop /e/, some /n != s,d/ is
a node-protecting remote LFA for the /s-d/ pair if and only if
/dist(s,n) < dist(s,e) + dist(e,n)/// (3)
/dist(n,d) < dist(n,e) + dist(e,d) / (4)
As it was in the case of link protection, here, (3) defines the
P-space, while (4) characterize the Q-space.
Here, two important observations can be made, which are the followings:
- P-space does not depend on the protection scheme (i.e., link or
node protection)
- (4) again is the basic node-protecting loop-free criterion of pure
LFA.
*Node-protecting rLFA condition with extended P-space:*
For source /s/, destination /d/, and next-hop /e/, some node /n !=
s,d/ is an extended node-protecting remote LFA for the /s-d/ pair if
and only if
/?v ? neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)/
/dist(n, d) < dist(n, e) + dist(e, d) ./
Despite the fact that we only considered unit cost networks, the
formal definitions above are *true for any arbitrary weighted network.*
I have to emphasize and thank the authors that in the second version
of the rLFA draft, it became more clear how MPLS LDP label stack can
provide the necessary "tunneling" for reaching remote LFA staging
points, which answered me a lot of questions.
However, there is something in which I still not sure. As far as I
know(, from the draft), reaching PQ-nodes in MPLS/LDP enabled
network, two labels are necessary for the source node to avoid the
failed component. An outer label, which is the label of S's neighbor
for sending traffic to the PQ-node, while the inner label is the PQ
node's label for reaching the destination.
Best regards,
Levente Csikor
Ph.D. Student
MTA-BME Future Internet Research Group
High Speed Networks Laboratory
Dept. of Telecommunications and Media Informatics
Budapest University of Technology and Economics,
Hungary.
[1] L. Csikor, G. Retvari, "IP Fast Reroute with Remote Loop-Free
Alternates: the Unit Link Cost Case", In: Proceeding of RNDM 2012 4th
International Workshop on Reliable Networks Design and Modeling,
pp:16-22. 2012.
[2] L. Csikor, G. Retvari, "On Providing Fast Protection with Remote
Loop-Free Alternates: Analyzing and Optimizing Unit Cost Networks",
submitted to Telecommunications Systems Journal, 2012.
P.S.: I already tried to contact one of the authors directly (by
email), but no answers were received. That's why I send this message
to the list. I have never post any message to these mailing lists and
I hope I did not spamming it.
On 06/25/2013 06:53 PM, Acee Lindem wrote:
Hi Stewart,
See inline.
On 6/20/13 6:59 AM, "Stewart Bryant"<[email protected]> wrote:
I write this email as duty editor of draft-ietf-rtgwg-remote-lfa
I recently updated this draft and think that it is ready for WGLC.
When the WG adopted the draft Alia made a number of comments which
I address below:
AA> First, if the intent is to restrict this mechanism to ONLY link
AA> protection, that belongs at a minimum prominently in the abstract and
AA> introduction. It is currently first mentioned only in Section 3.
This has been addressed.
AA> Second, the algorithm description Sec 4.2.1 and Sec 4.2.2 needs
AA> significant expansion into a more formal algorithm description, such
AA> as is in the LFA spec, RFC 5286. A brief description of the
AA> computational complexity would be useful, but the critical part is
AA> having it specified clearly.
Mike and I have included some cost metric explanations which I think
is adequate for ensuring the expected behavior. I am not convinced
that the level of formalism in RFC5286 is required. The requirement
is that an implementation will function correctly, neither breaking
the network, nor surprising the operator.
I have to say that I agree with Alia here. I've read the document several
times and what you have in sections 4.2.1-4.2.3 is a heuristic for
determining a single remote LFA for a specific failure (S-E failure in
figure 1) rather than any kind of general case algorithm.
Thanks,
Acee
AA> Third, in Sec 4.2.3, there is no preferred or even specified method
AA> for selecting among the different PQ options that might be available.
AA> Such a method should be specified; as the draft says, there is an
AA> advantage from the network management perspective to consistency. It
AA> is also required to have agreement on the output of analysis to
AA> compare/contrast methods.
We have added some text
AA> Fourth, one issue described in RFC 5286 is what happens when a worse
AA> failure occurs than the LFA was computed to handle - i.e. if a node
AA> failure happens instead of a link failure. In that case, traffic
AA> looping can occur. With Remote LFA, I believe that the same issue can
AA> exist - but made even worse because there is no effort to look for
AA> node-protecting Remote LFAs. This concern needs some description in
AA> the draft. Additionally, the equivalent of the Downstream Paths
AA> condition should be specified, if possible, that allows such traffic
AA> looping to be avoided. Finally, since the argument for Remote LFA is
AA> the improved coverage over LFAs, I would like to see the coverage
AA> analysis based on simulation to show the coverage when the Downstream
AA> Paths equivalent requirement is met vs. when it is relaxed (as
AA> currently in the draft).
We added some test to section 6 to cover the worse than expected case.
AA> Fifth, for a better understanding of realistic behavior, I would like
AA> to see the analysis extended to show the min, average, and max
AA> coverage for the 11 specified topologies after each single failure has
AA> occurred in the topology. (Of course, the computation should
AA> recognize that protecting cut-links isn't feasible and not include
AA> those failures.)
I don't think that this draft is the place to provide a greater analysis
of coverage. However I do think such a draft needs to be written.
I understand that Mike has plans to publish a draft before Berlin
to address this.
AA> While I recognize that link failures are significantly more common
AA> than node failures, I believe that fast-reroute techniques should be
AA> able to cover node failures as well. Technically, I think that Remote
AA> LFA can, of course, be extended to provide node coverage - at the cost
AA> of computing a reverse-SPF from each next-next-hop of the computing
AA> router.
There are drafts covering the node case that are being proposed
by members of the WG.
AA> As I said early, at a minimum, the abstract and introduction
AA> need to clearly specify that Remote LFA only provides link protection
AA> and the traffic looping concerns need to be addressed.
Done
- Stewart
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
