> Dino, thank you for your response. > > I haven't followed up LISP for a long time and indeed read draft-...-lcaf-00 > today for the first time. > Hereby I saw that particular address family and as one of several choices the > indication of longitude/latidude degree/minute/second which was and which > still is the basis for what I described by draft-hummel-tara-00. > > For sure, the geographical coordination information can be 1:1 mapped from > type 5 to my proposed "TARA"-form and vice versus. > The advantage of receiving the unicast-locator in the TARA-form is that you > can use it like an incoming MPLS-label, here to offset either 1 or 3 tables > for retrieving the next hop info. This is much faster than running 19 binary > search cycles applied to a FIB with more than 2^18 entries and the conversion > from type 5 to TARA-type wouldn't have to be done at each next hop either > (and, see above,if one needs the info in type 5 form that can easily be > derived from TARA-form too). > > Multicast, Anycast: > In the past I also believed that there can't be a thing like a > Multicast-Locator. But then I developed a Multicast-model which only needs > finite-state-machines > at the senderTR, at the receiverTRs, and yes at entry-border nodes of > geopatches. Any other participating node does only have a single > multicast-FIB entry wrt to a particular multicast instance. I call that > state-less multicast.
Since April 2008, ala draft-ietf-lisp-multicast, there has been a multicast locator. It turns out to be a delivery group that (S,G) packets are encapsulated in and delivered by the multicast-capable core. > What is new, i.e. what breaks up with traditional IETF-view: > a) I differentiate between a unicast-FIB, a multicast-FIB, a anycast-FIB > (instead of having a (one) FIB per se) > b) Only the (already) participating nodes (wrt a particular multicast > instance) do have such a multicast-FIB entry which comprises just the > particular multicast-locator, one uplink, and evtl. multiple downlinks to > neighboring nodes - nothing else. In summary they form the delivery tree > which is also used for exchanging messages like QUIT, PRUNE, and especially > for new messages which are needed as to enable that all participating parties > (the sender as well as the receivers) can roam i.e can be mobile. > > Anycast: So far no one has ever developed an Anycast-model with JOINs and > QUITs analogously to Multicast. This is not how "anycast" has been defined before. So this is a new capability/use-case and you should probably call it with a different name. Dino > Don't think that I do not know the traditional understanding of anycast. And > there are certainly services whereby EVERY node should "participate" in the > anycast service without extra-joining, i.e. just by learning about the > potential anycast-destinations. > I think there are enough application of either brand ( I always think of > well-scoped anycast when I have to drive around in Munich looking for a > parking lot:-) > > Heiner > > > > > -----Ursprüngliche Mitteilung----- > Von: Dino Farinacci <[email protected]> > An: HeinerHummel <[email protected]> > Cc: lisp <[email protected]> > Verschickt: Mi, 7 Nov 2012 3:06 pm > Betreff: Re: [lisp] draft-ietf-lisp-lcaf-00 > > > As there is AFI=16387 Type 5, I would like to suggest an additional Type by > which the geographical coordinates wrt longitude and latitude are bijectively > mapped to {square degree#,square minute#, second row#, second column#} such > that > the meridian (east/west) and equator ( north/south) dominated scheme is > transformed into a fast addressable (offsetting) scheme which starts at the > south pole and which only knows the directions to-east and to north as by the > following: > > Why? Can you give us a specific use-case. > > > (1) Unicast: > > Square degree#: > > The globe may be conceived as 180 rings of spherical triangles/rectangles, > starting at the South pole with a ring of 360 spherical triangles, each of > which > is limited by two longitudes and latitude 89° South from the Equator. Towards > North there follow 178 rings of 360 spherical rectangles, each of which is > limited by two consecutive longitudes and latitudes. Finally there is a last > ring of 360 spherical triangles around the North pole. > > Each spherical triangles/rectangles is assigned a square degree number from > > 1 > to 64800, starting at the South Pole with that triangle which is limited by > the > two longitude degrees 0 and 1 East, the South Pole and latitude 89 South, > winding from there in eastbound direction, while forming a full circle such > that > number 360 is assigned to that triangle, which is limited by the two > longitude > degrees 1 West and 0,while number 361 is assigned to that spherical > rectangle, > which is limited by the longitude degrees 0 and 1 East and the latitudes 89 > South and 88 South. While winding in eastbound direction and while winding > towards the North Pole, the last number 64800 is assigned to that spherical > triangle which is limited by the longitudes 1 West and 0, the latitude 89 > North > and the North Pole. > > > > Square minute# derived from given longitude minute x and latitude minute y. > > if South of the Equator then minute row# = 60 –y else minute row# = y+1 > > if West of Greenwich then minute column# = 60- x else minute column# = x+1. > > square minute# = (minute row# -1) times 60 + minute column#Square minute# > derived from given longitude minute x and latitude minute y. > > > > second row# and second column# derived from given longitude second x and > latitude second y. > > if South of the Equator then second row# = 60 –y else second row# = y+1 > > if West of Greenwich then second column# = 60- x else second column# = x+1. > > (no second square# needs to be calculated) > > > > The proposed enhancement would enable a next-hop determination by either > > one > or three table offsets in case of unicast forwarding > > > > (2) Multicast > > Multicast-Locator {square degree#; "multicast address"-number which is > > unique > per indicated square degree} > > Well-known Multicast-Locator {square degree# =64801; standardized > > "Multicast > address" number for that well-known service} > > > > The Multicast-Locator enables the retrieving of the proper entry from a new > Multicast-FIB entry (inside a participating node only) which enables multiple > concurrent next-hops eventually. > > But a multicast entry will describe a set of receivers spread across the > planet. > So the concept of a multicast group have a physical presents is in conflict > to > its traditional and fundamental meaning. > > > (3) Anycast > > Anycast-Locator {square degree#; "anycast address"-number which is unique > > per > indicated square degree} > > Well-known Anycast-Locator {square degree# =64802; standardized "Anycast > address" number for that well-known service} > > > > The Anycast-Locator enables the retrieving of an entry of a new Anycast-FIB > > > (inside a participating node only) which enables just one next hop. > > > > While (2) and (3) specify which one out of multipe > > Multicast/Anycast-services, > at a more general place of the LISP header there should be > > some flags which indicate the fundamental forwarding type > > 0=unicast,1=multicast, > 2= anycast, 3=.broadcast, 4=mp2p,.....) > > This is going to be a problem as well. An anycast address is multiple unicast > address residing in physically different places. One would have a semantic > issue > knowing if an address is in multiple physical places (same as the multicast > point I brought up above) or an address has moved from one physical location > to > another. > > Dino > > > > > H.H. > > > > > > > > > > > > _______________________________________________ > > lisp mailing list > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/lisp > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
