>>> DSA: what about creating a specific document for reachability? something >>> like liveness problem? >> >> Here are the reasons: >> >> (1) We don’t want to have too many documents for someone to read to get the >> full picture of the LISP data-plane and control-plane. >> > Who is we? The WG or the authors?
The initial people who started out this effort. That is, Albert, Luigi, you, and me. > What is the difference between reading 50 pages in 2 documents or 50 pages > well structured in 3 documents? It is more convenient to have things in one place. > People willing to have just a brief understanding of LISP may not be > interested in knowing the liveness They can get a brief understanding from draft-ietf-lisp-introduction, which is already a separate document. Remember a few years ago, we thought it was worth while having an introduction to the architecture and protocols outside of the main specs. So we already have many specs. > check techniques. On the other hand, many people know LISP but don’t know how > liveness checks are performed, they would thus probably enjoy more a specific > document that talk about that instead of having to decipher a large document > that talks about everything. If there are too many pieces, and a person that DOES want detail, will then not go to all the documents and can miss that. We already have 14 RFCs and I think the modularity we have is a fine balance. >> (2) We have broken it up where another data-plane has sufficient information >> to use the LISP control-plane in one document. If that data-plane wants to >> use the some data-plane features of LISP, they go examine RFC6830bis for it. > I am not sure I get it. For me liveness is a control-plane matter that may > potentially use the data-plane. Echo-noncing is also a liveness mechanism. But since its defined part of the encapsulation header, it needs to be in the data-plane document. RLOC-probing is performed at non-forwarding time but it interacts with RLOC-probing, that is if nonces have been echoed, RLOC-probes may be suppressed. And only the data-plane cares about liveness since it cares about encapsulating to RLOCs that are reachable. > Also there are many possible solutions and that would be worth explaining the > rational of each one, their pros and cons and in what environment to use > them, hence the proposition of a separate document that can explain clearly > that. Again, if I was registering EID ‘damien’ with RLOC <gps-coordinates>, I would not care about using RLOC-probing because the RLOC is on attached to the Internet and you can’t encapsulate to it. So again, this is a data-plane function only. >> (2) Since the SMR is originated by an data-plane node (the ETR), it should >> be part of the data-plane document. > > No really a valid argument. Map-Requests, map-reply, map-notify … are > originated by data-plane nodes, it doesn’t mean that map-request must be in > data-plane, actually they are in the control-plane document already now. Well we originally had those control-plane messages in one place. But we were forced to split it up. So we can’t have both. And all those message types you illustrate are originated by non data-plane nodes all the time. > For me SMR is really a control-plane matter. It is an element to permit the > control of the content of the EID-to-RLOC cache and it is optional, the > data-plane can work without this feature at all. Also in terms It cannot work without this feature. If an RLOC-set changes, and if the ITR doesn’t support this, it encapsulates packets to either black holes or to the wrong place. >> (1) We have decided that the network elements, in their purest form are >> introduced in this data-plane document and that more specific deployment >> scenarios belong in RFC7215. >> > Who is we? The WG or the authors? Albert and I prposed this at the working group in Berlin and Seoul. >> Well it is up to the querier to decide how to populate. For instance, a lig >> client that doesn’t even have a map-cache is a querier, it decides to do the >> lookup and simply print the Map-Reply results on a screen or UI. > > right, so what about changing to: > > Tunnel routers are equipped with a cache, > called map-cache, that contains EID-to-RLOC mappings. The map-cache > _CAN be_ populated using the LISP Control-Plane protocol > [I-D.ietf-lisp-rfc6833bis]. That language is already there. Is it not? >>> DSA: maybe we could deprecate this feature (I don't see a reason to be in >>> the specs, it is an implementation feature, isn't it?) >> >> We should NOT depercate this feature. It is a way of timing out entries and >> important for map-cache management. And that is certainly something ITR >> specific and hence belongs in the data-plane document. > > I agree that deprecated is not the right word. For me it is an implementation > detail, hence not needed to be document in the specs but of course it can be > implemented. Clock sweep is still recommended by vendors. And it should. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
