Re: [lisp] draft-ietf-lisp-lcaf-00

[Dino Farinacci <[e-mail]>]

> 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 <[e-mail]>
> An: HeinerHummel <[e-mail]>
> Cc: lisp <[e-mail]>
> 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
> > 
> [e-mail]
> 
> > 
> https://www.ietf.org/mailman/listinfo/lisp
> 
> 
>