Skip to main content

Telechat Review of draft-ietf-lisp-map-versioning-
review-ietf-lisp-map-versioning-genart-telechat-barnes-2015-12-31-00

Request Review of draft-ietf-lisp-map-versioning
Requested revision No specific revision (document currently at 09)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-01-17
Requested 2015-12-31
Authors Luigi Iannone , Damien Saucez , Olivier Bonaventure
I-D last updated 2015-12-31
Completed reviews Genart Telechat review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes
State Completed
Request Telechat review on draft-ietf-lisp-map-versioning by General Area Review Team (Gen-ART) Assigned
Completed 2015-12-31
review-ietf-lisp-map-versioning-genart-telechat-barnes-2015-12-31-00
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-lisp-map-versioning-02.txt
Reviewer: Richard Barnes
Review Date: 02 September 2011
IETF LC End Date: 12 September 2011
IESG Telechat date: (if known) -

Summary:
Not ready

Major issues:

General
Overall the distinction  between "older" and "newer" version numbers does not
seem meaningful.  Treating the two cases differently doesn't add any value, and
just causes synchronization problems with things like restarts.  The salient
distinction is "Is this version number the one I have in my cache or not?"  If
so, no action; if not, refresh the mapping.  Cf. <

http://xmpp.org/extensions/xep-0237.html#format

>

Section 5.1. bullet 2
This bullet needs to be reconsidered.  Misbehavior is not the only situation in
which this situation could arise.  Consider, for example, if the ETR for a site
reboots and creates a new random initial map version.  Then everyone that has
mappings cached will have the wrong map-version, and all traffic will get
silently dropped.  Suggest adding an error message here that indicates the
proper version.

Section 5.1. bullet 3
Having an ETR *force* an ITR to update its mapping seems intrusive and fraught
with security risks.  Suggest adding an error message here that indicates the
proper version, so that the ITR can make its own decision as to whether to
update the cache.

Section 5.1. paragraph after bullet 3
Again, I'm concerned about silently dropping packets.  ITRs are not required to
renew mappings when TTLs expire, so it's very plausible that an ITR might have
stale mappings.  If such an ITR just has all its traffic dropped, then it has
no signal to refresh.  Suggest adding an error message here that indicates the
proper version.

Minor issues:

Editorial:

There are numerous grammatical errors, e.g.:
"If it is not the case, a Map Request can be send."
"... map-versioning does not introduce any new problem ..."
"The ETR's synchronization problem is out of the scope of this document."

Please expand "w.r.t."