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

[Martin Duke <[e-mail]>]

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.