Hi Alia, MoFRR to me is a kind of applying the LFA idea to multicast, and also given that implementations already exist (for quite some time now, if I'm correct), I do support it.
Trying to be constructive again, I would give some feedback for this one, too :-) 1. I suggest a little more glue between the text in chapter 7 (non-ECMP mode MoFRR) and the LFA spec. Non-ECMP mode seems very much like the LFA rules, yet they are redefined, which is not a problem, but I'd prefer having a similar notation/syntax/terminology and rules as far as possible. If there are differences, they should be highlighted. 2. Chapter 5, detecting failures. I think we should try to give a little more details. Packet comparison details, what needs to be stored? Complete packet? Packet hash? RTP seq number? ... I think the "third option", to rely on IGPs is by definition not FRR, so this should be the last option. The fourth option is "leveraging connected link failure". I think this option could be the easiest/most natural approach, and I guess since LoS, BFD and any local DP failure detection mechanism is usually tied already to unicast FRR, why not propose this to be the primary option for MoFRR, too? 3. Chapter 10: "The MoFRR principle may be applied to MVPNs." Let's give more details, if possible. 4. Due to mLDP, probably the MPLS WG chairs should be involved, too, not only PIM. 5. Why is the intended status "informational"? Why should it be different from LFA or remote LFA? I agree the solution practically does not require any novel cooperation method from other nodes, which is an advantage, so there is little to be a "Standard", but that's true for LFA or RLFA as well. So? 6. We often used the terminology "live-live" in other drafts, such as in MRT. I actually thought that it came from MoFRR, but now I did find no trace of it in the doc. Maybe we should add a sentence about it, saying that MoFRR implements what is often called "live-live" protection. I started to realise I'm often too long, sorry for that :-) András > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Alia Atlas > Sent: 2012. június 12. 22:42 > To: [email protected]; [email protected] > Subject: poll on draft-karan-mofrr-02 to become a WG draft > > This email is to start a poll and discussion on whether > draft-karan-mofrr-02 should > become an RTGWG draft. Please include comments, details, and whether > you have > read the draft. > > The earlier version was presented positively to the PIM WG as well. > > Authors, please indicate whether there is any IPR associated with this > draft. > > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
