[lisp] Comments to draft-kjsun-lisp-dyncast-00

[Dino Farinacci <[e-mail]>]

Kyoungjae/Younghan, thanks for the draft. See my comments below following your text, that I indented.


Note that the architecture can support anycast EIDs and/or anycast RLOCs with no special protocol considerations. It just depends on how you attach/assign an EID to a service, how the mapping system returns a partial RLOC-set, and how RLOCs are advertised in the underlay (like it is today with existing anycast services).

And in the abstract, it would be good to describe the high-level problem you want to solve. Because in the Introduction section you start out writing how it is solved.

> Having said that dynamic-anycast is an interesting concept so I welcome your contribution."

It would be useful to define the references to nodes in Figure 1 so it is understood when you refer to the diagram what is the relationship of LISP terms with dynamic-anycast terms. Just by looking at the figure, it iw not clear what a D-MA is and why in one case its co-located with an xTR and in another case it is not.

It is also not clear in the diagram where the LISP site boundaries are.  Please add circules that better define the boundary. Thanks.

It is not clear to me at this point in the draft, what a DBID is. The binding between an EID and an RLOC uses a standard term EID-to-RLOC mapping where I think you are proposing a DSID-to-RLOC-set binding. Please confirm.



I'd like to make a suggestion to call this type of EID an "DSEID" so it is clear that you are assigning the anycast attribute to an EID. Or simply make it "AEID" for "Anycast EID" so these concepts can be used more generally.


It sounds like you are giving the mapping system some policy control on what DBID to return and then having the ITR choose an RLOC within the DBID. Is that true? Is that the reason for a indirect mapping with a single lookup?


From this diagram, it appears there is a one-to-one relationship between a given DBID and an RLOC. So why is there a need for another level of indirection?

Today the way LISP supports an EID to RLOC-set mapping is that the EID-to-RLOC-set is registered to the mapping system and the mapping system returns the *entire RLOC-set*, but implementations support the map-server returning a partial set from the registered RLOC-set. But whatever is returned to the ITR allows it to choose which RLOCs to use. Usually the priority value that is created and sent by the ETR in a Map-Register allows the ETR to have control over what is chosen. We have many multi-homing examples of this.

So for your application, you could have a DSEID map to this RLOC-set:

RLOC-A, priority 1
RLOC-B, priority 1
RLOC-C, priority 2
RLOC-D, priority 2

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.


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.


This is already supported if you use the multi-tuple EID draft. But I'd use it as a multi-stage lookup, where the multi-tuple EID mappings that point to an anycast-EID and then there is a anycast-EID mapping that points to RLOCs. It does require a 2-stage lookup but allows the anycast-EID to change for a given multi-tuple EID.


As long as packets are sent to a map-cache entry, the entry stays in the map-cache. And just before it is removed, a refresh Map-Request is sent. If you need a shorter TTL to update the entry, you can (1) support SMRs per RFC6833bis or (2) PubSub per draft-ietf-lisp-pubsub draft.


Or draft-kowal-lisp-policy-distribution.


There is one problem with the mapping-system making the decision. It doesn't have data relative to the source LISP site to make service access optimal for it. So we typically don't have map-servers make decisions based a dependence of a (source, dest) path or (5-tuple) EID. The ITR should make this decision given a set of possibilties that come from the mapping system (but registered somewhere else, note you can co-located an ETR and a map-server so the ETR component registers to "itself", per SDN-controller mentality).



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?


Yes, it can, see draft-rodrigueznatal-lisp-multi-tuple-eids.

Thanks again for the draft,
Dino