Hi Ice, On Wed, May 6, 2015 at 3:25 PM, IJsbrand Wijnands <[email protected]> wrote:
> Hi Alia, > > Thanks for your review. > > See below response to your comments; > > > On Thu, Apr 16, 2015 at 3:19 PM, Alia Atlas <[email protected]> wrote: > > As is usual, I have done my AD review of draft-ietf-rtgwg-mofrr-06. I > don't have any specific comments on the text(assuming that the RFC Editor > will pick up the typos I saw). However, I do see a couple gaps that I > think would be very useful to address. Feel free to convince me otherwise > - but I think these will make for a stronger RFC. > > > > It would have been nice to have a sentence or two in there that > considered the operational and troubleshooting aspects of MoFRR. For > instance, can mtrace work? Would lsp-ping fail to work on the secondary > UMH because of packets being dropped? > > > > I also recall a private discussion about the interaction of MoFRR and > IGP reconvergence after a failure and whether there can be relevant > micro-forwarding loops as a result. It would be very useful to have a > sentence or two in this draft that discusses whether micro-forwarding loops > are a concern that can either be frequently avoided because the secondary > UMH or that needs to be considered in modeling or.... > > > > I'd welcome discussion to clarify these two aspects while the draft is > in IETF Last Call. I'd like to have these resolved by May 7 so that it can > be on the IESG telechat on May 15. > > You raise interesting points, but the fact is that the existing > troubleshooting tools for Multicast (mtrace, ping, LSP ping) have not been > modified to help troubleshoot the secondary path. So packets will get > dropped due to the secondary being path being inactive and not forwarding > packets. I can add that to the MoFRR draft, but I don’t think it will > become a stronger RFC due to it. If customers need such troubleshooting I’m > sure they will raise it and the IETF can address it. But for now my > preference would be to leave it like it is and move it forward. > It is a gap and I'd like to see a short sentence about it in the draft. Troubleshooting is very important. I don't expect this draft to address it, but to indicate the gap would be, I believe, useful. Regarding the micro-loops related to MoFRR. I was not involved in the > private discussion you had regarding MoFRR, IGP re-convergence and loops. > So I can’t really address that concern. To me it does not look any > different from a normal IGP convergence with PIM and mLDP. Can clarify? > Sure - the question is whether - during IGP reconvergence - either of the trees will actually stay stable or will have micro-loops. If the topology is basically split - so dual-plane backbone or the like - this isn't an issue. However, for more interesting topologies, there can be micro-loops that may affect the traffic even when it is using the secondary tree. Again - just a brief sentence mentioning the concern to consider would be useful. I think that'll help avoid surprises by folks interested in MoFRR. Thanks, Alia > Thx, > > Ice > > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
