Thanks again KJ. Dino
> On Aug 11, 2021, at 6:14 PM, 선경재 <[email protected]> wrote: > > > Dino, > > Thank you for discussing this topic. It was very helpful for making clear to > our proposal. > > I will update draft depending on these discussions. > > Additional comments and discussion by LISP folks are always welcome. > > Sincerely > > KJ. > ᐧ > > 2021년 8월 12일 (목) 오전 5:29, Dino Farinacci <[email protected]>님이 작성: >> > 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 >> > > > -- > ==================================================================== > > 선경재 / Kyoungjae Sun (KJ Sun) > > 연구원 / 클라우드 및 네트워크 연구실 > > Researcher / Distributed Cloud and Network lab > > Office : +82-2-814-0151 Phone : +82-10-3643-5627 > > Email : [email protected] > > ====================================================================
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
