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
