Hi Richard, thanks for your review.
Our answers can be found inline On Sep 2, 2011, at 18:46 , Joel M. Halpern wrote: > (Terry, I believe you saw this, copying the WG for everyone's information.) > This Genart review makes an interesting point. I would like to hear from the > authors as to whether they agree. > > Yours, > Joel M. Halpern > > -------- Original Message -------- > Subject: [Gen-art] Gen-ART LC review of draft-ietf-lisp-map-versioning-02 > Date: Fri, 2 Sep 2011 11:07:23 -0400 > From: Richard L. Barnes <[email protected]> > To: General Area Review Team <[email protected]> > > 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> Thanks for the pointer, but while the nomenclature looks pretty similar, the context is quite different. AFAIK, in xmpp when a client contacts a server it asks for the roster, to which a version number can be associated since it changes not that often. This works perfectly in the client-server model where for each query a check is done, if something is different then an update takes place. In LISP there are scenarios where communication may be asymmetric and/or triangular, e.g., two ITRs sending to the same ETR. The core idea of map-version is to have a mean for xTRs to understand if they are using the "latest" mapping. This must work also for ongoing flows, roughly it can be translated to a changing version in the middle of a query in xmpp (may be a forced parallel but it might give the idea). To this end it is necessary to introduce the notion of ordering in the version number. This is necessary in several scenarios we describe in the document. For instance, let's consider two ITRs from the same site that are sending traffic to the same ETR of a remote site. If a mapping update happens during heavy traffic exchange due to obvious path propagation differences even if the ITRs change mapping exactly at the same time the ETR will receive for a certain period (which at high bandwidth can mean a lot of packets) a series of interleaved packets with different version number in its header. With the simple policy you suggest above the risk is that the ETR will send out a burst of requests because each time it will think that the version has changed. This can potentially lead instabilities. Hope this simple scenario clarifies the need of ordering. The question of sequential version vs. opaque version (nonce) has been discussed in depth on the mailing list and ended with a WG consensus during the Anaheim meeting (77th IETF). > > 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. This could not happen. As we explain in section 8.1, all ETRs needs to have (and announce to the mapping system) exactly the same mapping. Any inconsistency can lead to traffic disruption. This is a general property of LISP is not specific to versioning. The Map-Version number is just another field in the Map-Record and like any other field must be consistent on all ETRs. > 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. This is an interesting point. In the LISP model the ETR is the authoritative network element concerning mappings. This is a basic principle of the LISP model and the security threats of this model are analyzed in [LISP-THREATS] while how to secure mapping is covered in [LISP-SEC]. > 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. They should refresh the mapping if the TTL expires and they want to use it. Failing to do so has obviously consequences. The stale mapping can even have disappeared. This is independent from map-versioning. > If such an ITR just has all its traffic dropped, then it has no signal to > refresh. Rightful observation, however, while the ETR MAY drop the traffic it can as well signal back to the ITR to update the mapping. This is done through a Map-Request with the SMR bit set. > Suggest adding an error message here that indicates the proper version. > > Minor issues: > > Thanks for pointing out these typos. > 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." was meant for "with respect to", will be expanded. Luigi on behalf of the authors > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
