David: > > > > So the question - that is not administrative - boils down > > > > imho to: can we exclusively concentrate on the LISP protocol(s) > > > > specifics leaving the issue of our confidence on the Loc/ID > > > > split and associated challenges open. That question deserves > > > > imho a specific discussion that should happen in the context > > > > of a BoF. > > > > > > It would seem that one could apply the same argument to > > > SHIM6, HIP, SCTP, and several other protocols that have > > > been or are being standardized. > > > > > > So my question to you is: > > > > > > (i). Given your argument above, do you believe that > > > say, the SHIM6 WG should not have been chartered > > > (or perhaps that the SIGTRAN WG, which produced > > > RFCs 4960 and 3286) should not have been > > > chartered? Clearly they did not have such an > > > analysis, or we wouldn't be talking about doing > > > it now (and again, that is not to say there isn't > > > a ton of literature on loc/id split). > > > > > > (ii). If on the other hand you believe that, say SHIM6 > > > should have been chartered, the question is why > > > (again, given your argument above)? > > > > Applying that approach (SCTP had foundations coming from > outside IETF) > > may work with relatively simpler problems/protocols. The level of > > complexity of the task to reach a certain objective drives > the approach. > > Agreed that its complex, though you dismiss SCTP without > explanation.
I mean for SCTP the base work was already done when protocol was translated in the IP world. SCTP follows the path described by D.Thaler in the IAB doc. "What Makes For a Successful Protocol?" > In addition, I don't see the relevance of > SCTP coming from outside the IETF. In any event, you > might make the same claim for LISP (that its coming from > outside the IETF). > > > In the present case, some of the main challenges are known > beforehand > > and they are certainly not limited yet to protocol implementation > > specific aspects. One may certainly initiate a cycle of experiments > > using experimental protocol specs together with a specific set of > > eval.objective and criteria. This said, the approach in spiral > > (LISPv1->experiment->analysis->LISPv2-> ...) works iff > > proto-development takes these elements into account (otherwise any > > experimentation is hardly useful as it will not deliver the expected > > outcomes in order to make real progress) and outcomes/analysis are > > documented accordingly before moving to the next iteration. > > > > Here, the problem in understanding stems because: LISP WG focus on > > experimental specification to resolve only protocol > engineering problems > > leaving actual challenges outside of its own protocol work > but at the > > same time acknowledges that such experimentation are > complementary to > > achieve real progress on its own protocols. However, at > this point in > > time, I do not see how the protocol engineering problem can > be decoupled > > from the purpose of the experimental effort in spiral. > > > > Hope this clarifies my concern, > > Not really. First, you didn't answer my question. Your question is: does one size (of approach) fits all and the answer is no. Indeed, these situations can not be compared (SHIM6 is a WG whereas HIP is a WG and a RG) but none did intend to address the Internet routing system scalability. If my answer yes they should have been chartered it does not provide any element for answering the present question. > Second, > what you are arguing can be applied to say, OSPF (v1-n), > EGP->BGP, ..... Essentially any protocol that has ever > been rev'ed. Indeed. This is what i had in mind as example but there is a main difference: BGPv1 has been released in 1989 and progressed together with the growth of the Internet until reaching BGPv4. The conditions/environment is thus different but one thing remains multiple iterations will be needed. > Just to be clear: I understand the concern to further > understand the properties of loc/id split. If fact, to > the best of my knowledge no one in the current RRG cycle > has written about this except for me and Darrel > (draft-meyer-loc-id-implications-00.txt). That, however, > shouldn't stop us from developing protocols. If it did, > we'd never develop any protocol (since obviously the set > of such questions is clearly *not* recursively > enumerable). Work on cache-based mapping is ongoing, and there is still open work for mapping system itself (any reason for instance why you consider ALT as the only mapping distribution technique ?) to a name a few whereas there is no outcome yet for what it concerns impact on spatio-temporal traffic properties. All these "uncertainties" are left outside the design space - at least as the charter translates it - > Finally, what happens if the properties you want to study > are in some sense "emergent" (e.g., the Internet's > heavy-tailed robustness-complexity curve). The point here > is that you won't see those properties until you have a > system to study, so in our case (the Internet) the > approach you are advocating would not have revealed the > deepest and most fundamental (and hence most interesting) > properties of "the architecture" (check out > > http://www.cds.caltech.edu/~doyle/SFI_robustness/rigor_robust.htm > or any of Doyle's work on this topic). Uncertainties are intrinsically part of the experimental work: this reference states "robust to known and designed-for uncertainties". Paraphrasing that statement it seems the LISP charter does not leave room for addressing uncertainties (e.g. mapping system consider only ALT so only ALT could be experimented) - a BoF session should clarify why this is the case - Thanks, -dimitri. > Dave > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
