Subject: Re: progressing draft-ietf-rtgwg-mofrr-06 [AUTHOR RESPONSE NEEDED]

From: Alia Atlas <[email-masked]>
Date: Fri, 1 May 2015 10:56:35 -0400

The IETF Last Call has expired without comment.  I have not seen any
responses to
the two gaps that I mentioned in my AD review.

If this draft is to be on the May 14 telechat, I need responses and
resolved draft by
May 7.

Regards,
Alia

On Thu, Apr 16, 2015 at 3:19 PM, Alia Atlas <[email-masked]> 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.
>
> Thanks for the good work,
> Alia
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 1 May 2015 17:20:39 +0200

Thanks Alia, we’ll work out the gaps you mentioned and come back to you ASAP.

Ice.

> On 01 May 2015, at 16:56, Alia Atlas <[email-masked]> wrote:
> 
> The IETF Last Call has expired without comment.  I have not seen any responses to
> If this draft is to be on the May 14 telechat, I need responses and resolved draft by
> May 7.
> 
> Regards,
> Alia
> 
> 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.
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 6 May 2015 21:25:40 +0200

Hi Alia,

Thanks for your review.

See below response to your comments;

> 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.

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?

Thx,

Ice

---

From: Alia Atlas <[email-masked]>
Date: Mon, 11 May 2015 11:40:31 -0400

Hi Ice,

On Wed, May 6, 2015 at 3:25 PM, IJsbrand Wijnands <[email-masked]> wrote:

> > 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
> > 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

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 12 May 2015 10:18:09 +0200

Hi Alia,

> 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.  

Ok, I’ll add this to the draft.

> 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.

I think what you are saying is that with non-DUAL plane topologies, there is no guarantee that the secondary path is going to be stable, un-interuppted traffic flow after switching to it. If the secondary path is effected by the same failure that effected the primary path, any sort of failure may apply here, including micro-loops. I don’t see any additional concerns regarding micro-loops with MoFRR, do you agree?

I can add a statement regarding the above in the draft, but its its not specific to micro-loops..

Thx,

Ice.

---

From: Alia Atlas <[email-masked]>
Date: Tue, 12 May 2015 11:06:01 -0400

Hi Ice,

> Ok, I’ll add this to the draft.

Thanks

> > 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.
>
> I think what you are saying is that with non-DUAL plane topologies, there
> is no guarantee that the secondary path is going to be stable,
> un-interuppted traffic flow after switching to it. If the secondary path is
> effected by the same failure that effected the primary path, any sort of
> failure may apply here, including micro-loops. I don’t see any additional
> concerns regarding micro-loops with MoFRR, do you agree?
>

A general statement is fine.  I think you are right that microloops aren't
an extra concern.

Regards,
Alia