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.
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
