On 11/10/2013 14:29, [email protected] wrote:
Completely agree with Chris.
Moreover having the algorithm part described clearly inside the main
paragraphs of the document rather than the appendix is completely
inline with what has been done for basic LFA specification (RFC 5286
Paragraph 3.6 -- Selection procedure).
As mentioned by Chris, it is important to mention that rLFA alternate
must not be dependant on any direct LFA selection. rLFA must be able
to rely on any LFA (Extended P Space) whatever this LFA is best or not.
See version 3 was soon as I can find a home for it and please propose an
exact change
Stewart
Stephane
*De :*[email protected] [mailto:[email protected]] *De la
part de* Chris Bowers
*Envoyé :* jeudi 10 octobre 2013 19:00
*À :* [email protected]
*Objet :* RE: algorithm description for draft-ietf-rtgwg-remote-lfa
Stewart proposed in another thread making this algorithm text part of
an appendix (see snippet below.) I want to emphasize the importance
of adding more quantitative content to the normative sections of the
text, by illustrating an example of the confusion created by some of
the current text.
Today I was in a discussion regarding the criteria for evaluating for
use as a tunnel endpoint, a node Y in extended-P space which is
reachable from source S by way of S's neighbor N1. Some confusion
arose during the discussion over whether or not the node Y should be
rejected for consideration if policy had been applied rejecting N1 as
a (local)LFA for reaching Y. We agreed that the evaluation of Y as a
tunnel endpoint for remote LFA should not depend on the policy applied
to the (local)LFA to reach Y.
However, the text below in section 4.2.2 leads to confusion on this
point.
"Another way to describe extended P-space is that it is the union of (
un-extended ) P-space and the set of destinations for which S has a
per-prefix LFA protecting the link S-E."
I think this text should be removed and replaced with precise
quantitative criteria for membership in extended P-space. It is
likely that remote LFA will be deployed together with (local)LFA with
policy determining which type of alternate to use
(draft-litkowski-rtgwg-lfa-manageability). Describing remote LFA in
terms of (local)LFA will create confusion for someone trying to apply
policy. Quantitative criteria avoid this confusion.
If this text creates such confusion among experts, it is likely to
create even more confusion among end-users of the technology, when
trying to figure out what is really going on in their network. While
one might argue that this behavior is up to the vendor to document,
confusing text in the base rlfa draft will make that task much more
difficult.
---------
A response to this algorithm text showed up in another thread so I am
cutting
and pasting Stewart Bryant's response from 10/2/13 to this thread to
keep things organized.
[SB] "I plan to put in the algorithm text, although having discussed
this with Mike, our inclination is to include this as an
appendix since it is not required for interoperability that
you do the computation that way."
---------
Chris
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of *Chris Bowers
*Sent:* Wednesday, September 04, 2013 4:22 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* algorithm description for draft-ietf-rtgwg-remote-lfa
As has been pointed out in other email threads,
the current version of draft-ietf-rtgwg-remote-lfa-02.txt
lacks a formal description of the algorithm being proposed.
Below is a such a formal algorithm description, based on my
reading of the current draft. It would help progress this
draft forward if the authors would correct any errors
in this pseudo-code representation of the algorithm.
The pseudo-code below avoids unnecessary SPF computations, but
for the sake of readability, it does not otherwise try to
optimize the code.
Remote LFA algorithm
Compute_and_Store_Forward_SPF(node root)
Compute_Forward_SPF(root)
foreach node z in network
store D_opt(root,z)
Compute_and_Store_Reverse_SPF(node root)
Compute_Reverse_SPF(root)
foreach node z in network
store D_opt(z,root)
Compute_Neighbor_SPFs()
foreach interface intf in self
if (intf.remote_node != fail_intf.remote_node)
Compute_and_Store_Forward_SPF(intf.remote_node)
Compute_Extended_P_Space()
foreach node y in network
y.in_extended_P_space = false
if (D_opt(self, y) <
D_opt(self, fail_intf.remote_node) +
D_opt(fail_intf.remote_node,y))
y.in_extended_P_space = true
foreach interface intf in self
if (intf.remote_node != fail_intf.remote_node)
if ( D_opt(intf.remote_node, y) <
D_opt(intf.remote_node, self) +
D_opt(self,fail_intf.remote_node) +
D_opt(fail_intf.remote_node,y) )
y.in_extended_P_space = true
Compute_Q_Space()
Compute_and_Store_Reverse_SPF(fail_intf.remote_node)
foreach node y in network
if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +
D_opt(self,fail_intf.remote_node) )
y.in_Q_space = true
else
y.in_Q_space = false
Intersect_Extended_P_and_Q_Space()
foreach node y in network
if ( y.in_extended_P_space && y.in_Q_space )
y.valid_tunnel_endpoint = true
else
y.valid_tunnel_endpoint = false
Apply_Downstream_Constraint()
foreach node y in network
if (y.valid_tunnel_endpoint)
Compute_and_Store_Forward_SPF(y)
if ((D_opt(y,dest) < D_opt(self,dest))
y.valid_tunnel_endpoint = true
else
y.valid_tunnel_endpoint = false
Compute_Neighbor_SPFs()
Compute_Extended_P_Space()
Compute_Q_Space()
Intersect_Extended_P_and_Q_Space()
if (guarantee_no_looping_on_worse_than_protected_failure)
Apply_Downstream_Constraint()
**********
I would also like to propose that the following text to be
inserted after the last paragraph of
section 4.2.1. "Computing Repair Paths".
It should be noted that using the Q-space of E as a proxy for the Q-space
of each destination can result in failing to identify valid remote LFAs.
The extent to which this reduces the effective protection coverage is
topology dependent.
***********
Thanks,
Chris
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
