Hi Chris,
Thanks it appears to be ok.
I will go through the draft again. If I come across some things
can be updated or improved upon, I will keep you updated.
Thanks & Regards
Anil S N
"Be liberal in what you accept, and conservative in what you send" - Jon Postel
From: Chris Bowers [mailto:[email protected]]
Sent: 10 June 2015 00:29
To: Anil Kumar S N (VRP Network BL); Gábor Sándor Enyedi;
[email protected]; Alia Atlas; [email protected]
Cc: [email protected]; [email protected]
Subject: RE: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03
Anil,
Thanks for the suggestion to clarify the use of root to mean gadag_root or
spf_root in the pseudo-code, as well as the typo. I made the changes on
github. The diff can be found at:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/ada619050ec9d773b7919a1c622f068d5a5a5e88
Tell me if you agree with these changes.
With respect to comment#3, if ((D is F) or (D.order_proxy is F)), then there
are several cases to consider:
1) If the link from S to F is a cut-link,
a) if this is a single cut-link between S and F, then there is
no alternate
b) if there are parallel cut-links between S and F, then one
can, for example, ECMP across the remaining links, noting that there is no link
protection.
2) if the link from S to F is not a cut-link, then at least one of the MRT
next-hops for D (red or blue) will not be the same as the primary next-hop for
D. In which case, one should use the color that is not the primary next-hop as
the alternate, noting that the alternate does not provide node protection.
I agree that the existing pseudo-code is not very clear here. I am planning to
update this part of the pseudo-code in the near future to make it clearer, but
hopefully the explanation above suffices for the moment.
Chris
From: rtgwg [mailto:[email protected]] On Behalf Of Anil Kumar S N
(VRP Network BL)
Sent: Tuesday, June 09, 2015 1:27 AM
To: Gábor Sándor Enyedi;
[email protected]<mailto:[email protected]>; Alia Atlas;
Chris Bowers; [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03
Hi Authors,
As discussed before, Please find my review comments :
Comment 1: Can we rename parameter which is passed to these functions as real
SPF root or GADAG root ?
Run_DFS(node root)
Run_Lowpoint(node root)
Compute_Localroot(root, root)
Construct_GADAG_via_Lowpoint(topology, root)
Add_Undirected_Links(topo, root)
Assign_Block_ID(root, max_block_id)
Compute_MRT_NextHops(x, root)
Comment 2: Here parenthesis are not matching, four '(' and five ')'.
This must be typo mistake.
In_Common_Block(x, y)
if ( (x.block_id is y.block_id))
or (x is y.localroot) or (y is x.localroot) )
return true
return false
Comment 3: Is it possible to rephrase "if an MRT doesn't use primary_intf"
What does the sentence "MRT doesn't use primary_intf" mean ? Dose it mean
neither Red interface nor Blue interface is same as primary interface ?
What does the sentence "return that MRT color" means ?
Select_Alternates_Internal(S, D, F, primary_intf,
D_lower, D_higher, D_topo_order)
//When D==F, we can do only link protection
if ((D is F) or (D.order_proxy is F))
if an MRT doesn't use primary_intf
indicate alternate is not node-protecting
return that MRT color
Thanks & Regards
Anil S N
"Be liberal in what you accept, and conservative in what you send" - Jon Postel
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
