> Another option that creating specific document would be to restructure > 6830bis so to have one big section on liveness instead of having > sections here and there talking about it. For example, merging 10 and 11 into > one general section about reachability, and explain as an introduction > of this section that LISP changes the way we can see the reachability and > that we have to consider both RLOC and EID reachability.
Sections are not here and there about RLOC reachability. There is one section (section 10) that explains two mechanisms. Section 11 talks about EID reachability which is completely different than RLOC reachability because it is site side (which discusses site partitioning) rather than core side. >>> 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. > Map-Request are used for RLOC probing and SMR and they explicitly appear in > this data-plane document as data-plane features and now you say Map-Requests > are not data-plane. So finally we agree that they should be in control-plane > document as they are control-plane elements! Let me make this perfectly clear. I, in the first place, never wanted to separate this document. We have a possible requirement, at best, that other data-planes may want to use the LISP control-plane and for some reason they couldn’t look in RFC6830 for it. So now we split it up, and I said in the document, we’d have to make hard calls to not make this unmanageable. I think what we have right now is a decent balance. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
