Subject: [lisp] lisp deployment document

From: Paul Vinciguerra <[email-masked]>
Date: Wed, 7 Nov 2012 02:19:59 +0000

Jakab, et al.            Expires April 23, 2013                [Page 21]
Internet-Draft               LISP Deployment                October 2012

       *  To verify LISP connectivity, ping LISP connected sites.  See
          http://www.lisp4.net/ and/or http://www.lisp6.net/ for
          potential candidates.

This section seems overly simple.

There are three deployment options that I am aware of:

*         Deployment in the Beta network

*         Deployment in a separate LISP Island connected via DDT

*         Deployment in a separate LISP Island not connected via DDT

With PxTR's in the mix, pinging LISP sites doesn't assure end-end LISP connectivity.  It is our experience that PxTR's just magically make things work, and because of that, it doesn't always flow the way you think it does.

There probably needs to be some prefix that doesn't have a coarse aggregate announced into the DFZ for testing end-end LISP connectivity for the first two deployment options listed above.  If you're the last deployment case, you're on your own to verify end-end LISP connectivity.

Paul

---

From: [email-masked]
Date: Wed, 7 Nov 2012 07:55:01 -0500 (EST)

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: 

(1) Unicast:
Square degree#:

The globe may be conceived as 180 rings of sphericaltriangles/rectangles, starting at the South pole with a ring of 360 sphericaltriangles, each of which is limited by two longitudes and latitude 89° Southfrom the Equator. Towards North there follow 178 rings of 360 sphericalrectangles, each of which is limited by two consecutive longitudes andlatitudes. Finally there is a last ring of 360 spherical triangles around theNorth pole.  
Each spherical triangles/rectangles is assigned a square degree number from 1 to 64800, startingat the South Pole with that triangle which is limited by the twolongitude degrees 0 and 1 East, the South Pole and latitude 89 South, windingfrom there in eastbound direction, while forming a full circle such that number360 is assigned to that triangle, which is limited by the two longitudedegrees 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 89South and 88 South. While winding in eastbound direction and while windingtowards the North Pole, the last number 64800 is assigned to thatspherical triangle which is limited by the longitudes 1 West and 0, the latitude89 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.

(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,.....)

H.H.

---

From: Lori Jakab <[email-masked]>
Date: Wed, 07 Nov 2012 16:00:18 +0200

Hi Paul,

Thank you for the feedback on the document, it's great having the
operational community participate. Indeed, the existance of PxTR's are
making the ping check less meaningful. How about combining the ping
check with a traceroute? Even if the routers carrying the LISP
encapsulated packets won't show up on a traceroute, you can see if the
encapsulation/decapsulation happens at the expected locations (xTRs
instead of PxTRs) or not.

The LISP-only EID prefix you propose is definitely a good option too.
But if I understand it correctly, it depends on a third party running a
known good LISP test site. At the time of writing we didn't know of any
such service, so it was not included as an possibility.

Regading deployment options, why do you consider the first and second
one separately? According to the ddt-root.org web site, the Beta network
is a DDT connected LISP island as well. Sure, it runs deeper in the
tree, delegating the 153.16/16 further down, but I wouldn't look at it
as a separate deployment option.

-Lori

On 11/07/12 04:19, Paul Vinciguerra wrote:
> ·Deployment in the Beta network
>
> ·Deployment in a separate LISP Island connected via DDT
>
> ·Deployment in a separate LISP Island not connected via DDT
>
> With PxTR’s in the mix, pinging LISP sites doesn’t assure end-end LISP
> connectivity. It is our experience that PxTR’s just magically make
> things work, and because of that, it doesn’t always flow the way you
> think it does.
>
> There probably needs to be some prefix that doesn’t have a coarse
> aggregate announced into the DFZ for testing end-end LISP connectivity
> for the first two deployment options listed above. If you’re the last
> deployment case, you’re on your own to verify end-end LISP connectivity.
>
> Paul
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 7 Nov 2012 06:06:15 -0800

> 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#, s…

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.  
> 

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.

> 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-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 7 Nov 2012 06:16:30 -0800

The LISP-only EID-prefix is one use of the draft-ietf-lisp-eid-block draft.

Dino

---

From: Paul Vinciguerra <[email-masked]>
Date: Wed, 7 Nov 2012 14:44:10 +0000

> making the ping check less meaningful. How about combining the ping check
> with a traceroute? Even if the routers carrying the LISP encapsulated packets
> won't show up on a traceroute, you can see if the

[PV] When we started doing more complex configurations that included LISP with NAT and crypto, we could not rely on pings and traceroutes.  We had to rely on debugs and packet captures.  It is great that LISP decodes are available in wireshark.

> But if I understand it correctly, it depends on a third party running a known
> good LISP test site. At the time of writing we didn't know of any such service,
> so it was not included as an possibility.
> 

[PV] I would expect that we should be able to request a small prefix from ARIN for this as a Sect. 4.4 Micro allocation while waiting on the draft-ietf-lisp-eid-block.

> Regading deployment options, why do you consider the first and second one
> separately? According to the ddt-root.org web site, the Beta network is a
> DDT connected LISP island as well. Sure, it runs deeper in the tree, delegating
> the 153.16/16 further down, but I wouldn't look at it as a separate
> deployment option.
> 

[PV] If you deploy onto the beta network, the DDT component is already done and is working.  If you are connecting a new island to DDT, you may have additional DDT related troubleshooting to perform. (for example, 
The correctness of the authoritative map server DDT config)  We were never part of the beta network, we started out as my third case and evolved into my second listed case. 

> > *Deployment in the Beta network
> >
> > *Deployment in a separate LISP Island connected via DDT
> >
> > *Deployment in a separate LISP Island not connected via DDT
> >
> > With PxTR's in the mix, pinging LISP sites doesn't assure end-end LISP
> > connectivity. It is our experience that PxTR's just magically make
> > things work, and because of that, it doesn't always flow the way you
> > think it does.
> >
> > There probably needs to be some prefix that doesn't have a coarse
> > for the first two deployment options listed above. If you're the last
> > deployment case, you're on your own to verify end-end LISP connectivity.
> >
> > Paul
> >

---

From: Lori Jakab <[email-masked]>
Date: Wed, 07 Nov 2012 17:27:10 +0200

> The LISP-only EID-prefix is one use of the draft-ietf-lisp-eid-block draft.

Sure, but that's IPv6-only.

-Lori

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 7 Nov 2012 07:32:23 -0800

We could request a block of Class B IPv4 prefixes but the working group didn't want to do that.

Dino

---

From: Paul Vinciguerra <[email-masked]>
Date: Wed, 7 Nov 2012 15:39:30 +0000

Isn't  153.16.0.0/16 already the de facto ipv4 draft-ietf-lisp-eid-block?

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2012 10:32 AM
> To: Lori Jakab
> Cc: Paul Vinciguerra; [email-masked]
> Subject: Re: [lisp] lisp deployment document
> 
> >>> operational community participate. Indeed, the existance of PxTR's
> >>> are making the ping check less meaningful. How about combining the
> >>> ping check with a traceroute? Even if the routers carrying the LISP
> >>> encapsulated packets won't show up on a traceroute, you can see if
> >>> the encapsulation/decapsulation happens at the expected locations
> >>> (xTRs instead of PxTRs) or not.
> >>>
> >>> But if I understand it correctly, it depends on a third party
> >>> running a known good LISP test site. At the time of writing we
> >>> didn't know of any such service, so it was not included as an possibility.
> >>>
> >>> Regading deployment options, why do you consider the first and
> >>> second one separately? According to the ddt-root.org web site, the
> >>> Beta network is a DDT connected LISP island as well. Sure, it runs
> >>> deeper in the tree, delegating the 153.16/16 further down, but I
> >>> wouldn't look at it as a separate deployment option.
> >>>
> >>> -Lori
> >>>
> >>>> With PxTR's in the mix, pinging LISP sites doesn't assure end-end
> >>>> LISP connectivity. It is our experience that PxTR's just magically
> >>>> make things work, and because of that, it doesn't always flow the
> >>>> way you think it does.
> >>>>
> >>>> aggregate announced into the DFZ for testing end-end LISP
> >>>> connectivity for the first two deployment options listed above. If
> >>>> you're the last deployment case, you're on your own to verify end-end
> LISP connectivity.
> >>>>
> >>>> Paul
> >>>>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 7 Nov 2012 07:42:24 -0800

> Isn't  153.16.0.0/16 already the de facto ipv4 draft-ietf-lisp-eid-block?

Defacto, but an individual owns it and has been gracious to lend it out. I'm not sure he would agree on global general use. Plus it is only a single /16.

Dino

---

From: Lori Jakab <[email-masked]>
Date: Wed, 07 Nov 2012 17:48:55 +0200

> Defacto, but an individual owns it and has been gracious to lend it out. I'm not sure he would agree on global general use. Plus it is only a single /16.

...and is advertized in BGP, so it's not EID-only and the PxTR problem
is still there, unless it is broken up into smaller prefixes (which is
probably not what we want).

-Lori

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 7 Nov 2012 07:52:34 -0800

> probably not what we want).

But it will always be injected in underlying BGP because you need non-LISP sites to talk to this destination prefix. The point is that this prefix is not used as a locator (i.e. it is not the outer address of any LISP encapsulated packet).

Dino

---

From: Lori Jakab <[email-masked]>
Date: Wed, 07 Nov 2012 18:02:07 +0200

> But it will always be injected in underlying BGP because you need non-LISP sites to talk to this destination prefix. The point is that this prefix is not used as a locator (i.e. it is not the outer…

Right, but if I understood it correctly (and Paul, please correct me if
I got it wrong), Paul was advocating for the existance of a small block
that is a "hole" in the DFZ, as a reliable way to determine LISP
connectivity. Do we want to ask for a block specifically for that purpose?

-Lori

[...]

aggregate announced into the DFZ for testing end-end LISP connectivity
for the first two deployment options listed above.

---

From: Paul Vinciguerra <[email-masked]>
Date: Wed, 7 Nov 2012 16:12:16 +0000

> 
> Right, but if I understood it correctly (and Paul, please correct me if I got it
> wrong), Paul was advocating for the existance of a small block that is a "hole"
> in the DFZ, as a reliable way to determine LISP connectivity. Do we want to
> ask for a block specifically for that purpose?

[PV] Yes.  I was asking about a single "tree in the forest"  for exactly that purpose and I think Dino is pointing out that there are other reasons for this besides mine and we need to address the much broader need "the forest".

For this one purpose, a single /24 goes a long way under LISP.

---

From: [email-masked]
Date: Wed, 7 Nov 2012 11:37:57 -0500 (EST)

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.

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.
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-masked]>
An: HeinerHummel <[email-masked]>
Cc: lisp <[email-masked]>
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: 

> (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# = (minute row# -1) times 60 + minute column#Square minute# 
derived from given longitude minute x and latitude minute y.
> The proposed enhancement would enable a next-hop determination by either one 
or three table offsets in case of unicast forwarding
> 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.

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 7 Nov 2012 14:52:25 -0800

> 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…

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.

> 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