> First of all, thank you very much to give detailed comments on our draft. > Please check answers for your comments inline.
KJ, thanks for the quick response. I have cut out the text where I agree/accept with your responses. See inline for additional commentary and answers to your questions. Once you update the spec, I'll give another thorough review. Thanks! > >> Which indicates that ETR only wants packets sent to C and D when A and B are >> not reachable from the ITR (by using multiple mechanisms but the most robust >> is RLOC-probing). >> >> Note the use of an RLOC-set comes in multiple forms: >> >> (1) A list like above (default) >> (2) An ELP, where the RLOC-record indicates a encap-path from ITR to ETR. >> (3) An RLE, where the RLOC-record indicates that all RLOCs listed are used >> (multicast replication). >> >> You could use 1 or all combinations of these with filtering/policy support >> on the map-server. > > KJ: The priority you mentioned just represents the network-related capability > in the dynamic anycast viewpoint. However, if parameters to be required for > selecting routing path are not only network-related metrics but also > service-related metrics (i.e., computing loads, number of flows, etc.), we > need other indirection for that. If you want to control where packets go on the underay, you can also consider draft-ietf-lisp-te. That is where ELPs are introduced and designed into the LISP architecture. >> >>> <PastedGraphic-39.png> >> >> It is important to note that if you use equal priorities in an RLOC-set, >> that the ITR can load-split traffic across RLOCs and that will break >> connnection oriented applications (or applications that require remote state >> for a session). >> >> So an ITR that is configured that a particular EID in its map-cache is an >> anycast-EID, it can use an RLOC-set above with each RLOC priority=1 and then >> choose based on the implementation's idea of what is a better RLOC to use. >> >> IMO opinion, the better way to design/implement this is using an >> anycast-EID-to-anycast-RLOC mapping. Which means you only need a register >> from one place (an SDN controller) or each ETR registering the same RLOC >> (without merge semantics). So the serivce is chosen by destination address >> in a packet (the anycast-EID) which maps to an anycast-RLOC where the >> underlay takes you to the "closest" LISP site. But closest is just one way >> of getting to a service. You may have other ways and hence why you >> introduced a metric. > > KJ: In my understanding, in your suggestion, anycast RLOC is allocated to > the ETRs which can deliver packet destined to anycast-EID by internal routing > and routing between those ETRs are chosen in the underlay. Is it right? Yes. You assign the same RLOC address to multiple ETRs and have underlay routing take a source to the closest LISP site. >> >> Yes, it is better to gather the metrics data outside of LISP. But yes, the >> control-plane could store it. I would suggest just mapping your collection >> metrics to priorities so no protocol messages would need to be modified. I >> believe LISP already has designed in everything you need. Do you agree? > > KJ: yes. I agree with your point that LISP already has the solution to > mapping metrics to priorities. That is the one of reasons that I think that > it is possible to provide dynamic anycast routing using LISP without huge > modifications. Yes agree. Then the ITR came make an RLOC selection based on existing documented approaches. But if the metrics change too much then the contents of the RLOC-set changes which requires more frequent map-cache updates. So we have to analyze this tradeoff more in depth. > So, I think that we should not give fixed solutions on how to collect and > store metrics but we can mention possible solutions for that. Because it is > more implemental issue. Is it right approach? Yes, I agree. > <PastedGraphic-45.png> >> >> Yes, it can, see draft-rodrigueznatal-lisp-multi-tuple-eids. > > KJ: Thank you for giving that information. I will check and update Thanks again, Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
