Subject: Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6833bis-27: (with DISCUSS and COMMENT)

From: Martin Duke <[email-masked]>
Date: Wed, 28 Oct 2020 09:03:04 -0700

Hi,

>
> > Sec 5.7. Is the intent that the Map-Notifies are only retransmitted if
> they are
> > unsolicited? If not, repeated Map-Registers could result in a storm of
> > Map-Notifies.
> >
>
> 6833bis specs that Map-Notifies are retransmitted when Map-Notify-Ack
> are not received.
>
> The behaviour of unsolicited Map-Notifies are NOT spec’ed in 6833bis,
> this is specified in draft-ietf-lisp-pubsub
>
> What 6833bis specs -per a review by Mirja- is that if an unsolicited
> Map-Notify is sent, then it will follow the guidelines of RFC8085
>

If I parse your answer correctly, the answer to my question is 'no'. So in
the scenario where the Map-Notify is lost, both the Map-Register and the
Map-Notify are on retransmission timers. The most straightforward reading
of the text is that
- I respond to every Map-Register with a Map-Notify (if it requests it)
- For every Map-Notify I send, I start a retransmission timer.

Imagine a path where Map-Notifies are being consistently lost due to some
sort of temporary half-duplex outage. The packet schedule is thus:

0s: Map-Register
0+eps: Map-Notify #1 (Lost)
1s: Map-Register
1+eps: Map-Notify #2 (Lost)
3s: Map-Register
3+eps: Map-Notify #3 (Lost)
3+eps: Map-Notify (retransmission of #1, lost)
4+eps: Map-Notify (retransmission of #2, lost)
6+eps: Map-Notify (retransmission of #1, lost)
6+eps: Map-Notify (retransmission of #3, lost)
7s: Map-Register
7+eps: Map-Notify #4 (Lost)
7+eps: Map-Notify (retransmission of #2, lost)
9+eps: Map-Notify (retransmission of #1, lost)
9+eps: Map-Notify (retransmission of #3, lost)
10+eps: Map-Notify (retransmission of #4, lost)
10+eps: Map-Notify (retransmit #2, lost)
and so on.

This is not a great retransmission schedule. There are several ways out of
this. The most straightforward one, IMO, is to reset the Map-Notify
retransmission timer if a Map-Register retransmission arrives and triggers
a reply.

>
>
> > Sec 7.1. I very well may have missed something, but it doesn't look like
> the
> > Map-Request is authenticated. So how can the ETR safely update its Map
> Cache
> > based on the information in the Map-Reply?
> >
>
> The Map-Request is just a query to an EID, and as such it is not
> authenticated.
> The Map-Reply carries the response to such query, an EID-to-RLOC
> mapping. This query is authenticated.  The Map-Cache is updated based
> on the received EID-to-RLOC mapping.
>
>
I see now that Sec 5.3 specifies that piggybacked information the Map
Request requires authentication, so I agree there is no issue here. It
might be useful to reiterate this in the 2nd paragraph of 7.1, but I will
remove this part of the DISCUSS.

Thanks for resolving the comments.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Oct 2020 13:30:09 -0700

> If I parse your answer correctly, the answer to my question is 'no'. So in the scenario where the Map-Notify is lost, both the Map-Register and the Map-Notify are on retransmission timers. The most straightforward reading of the text is that

Let me be a bit more clear about how retransmissions of Map-Registers and Map-Notifies work.

There are two broad cases, 

(1) Map-Notify messages as an ack to Map-Registers.
(2) Map-Notify messages that are unsolicited from Map-Servers.

In the first case:

(1) When Map-Registers are sent with the bit set to request acknowledgment for Map-Registers received by Map-Servers, a retransmission timer is set by the xTR for Map-Register retransmissions (which is more often than the periodic Map-Register timer).

(2) The Map-Server sends a Map-Notify for each received Map-Register. There is NO retransmission timer for the Map-Notify.

In the second case:

(1) A Map-Server detects a RLOC-set change and wants to Map-Notify the xTRs in the old and new RLOC-set by sending a Map-Notify message. These messages are acknowledged by the xTR by Map-Notify-Ack messages. In this case the Map-Server DOES have a retransmission timer for the Map-Notify for each xTR. 

(2) The Map-Notify-Ack DOES NOT have a retransmission timer and simply is sent by an xTR when it receives a Map-Notify.

So having said that, you probably still want some better rewording. Please confirm?

Dino

---

From: Martin Duke <[email-masked]>
Date: Wed, 28 Oct 2020 13:34:08 -0700

Yes, the design you describe here makes perfect sense. I did not get this
distinction from the current text at all. So yes, please reword it. The
framework you presented in this email is much clearer and may serve as a
good basis.

Thanks
Martin

On Wed, Oct 28, 2020 at 1:30 PM Dino Farinacci <[email-masked]> wrote:

> > If I parse your answer correctly, the answer to my question is 'no'. So
> in the scenario where the Map-Notify is lost, both the Map-Register and the
> (1) When Map-Registers are sent with the bit set to request acknowledgment
> for Map-Registers received by Map-Servers, a retransmission timer is set by
> the xTR for Map-Register retransmissions (which is more often than the
> periodic Map-Register timer).
>
> (2) The Map-Server sends a Map-Notify for each received Map-Register.
> There is NO retransmission timer for the Map-Notify.
>
> In the second case:
>
> (1) A Map-Server detects a RLOC-set change and wants to Map-Notify the
> xTRs in the old and new RLOC-set by sending a Map-Notify message. These
> messages are acknowledged by the xTR by Map-Notify-Ack messages. In this
> case the Map-Server DOES have a retransmission timer for the Map-Notify for
> each xTR.
>
> (2) The Map-Notify-Ack DOES NOT have a retransmission timer and simply is
> sent by an xTR when it receives a Map-Notify.
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Oct 2020 13:35:25 -0700

Thanks for confirming Martin.

Dino

> On Oct 28, 2020, at 1:34 PM, Martin Duke <[email-masked]> wrote:
> 
> Yes, the design you describe here makes perfect sense. I did not get this distinction from the current text at all. So yes, please reword it. The framework you presented in this email is much clearer and may serve as a good basis.
> 
> Thanks
> Martin
>