Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07

From: Geoff Huston <[email-masked]>
Date: Mon, 2 Dec 2013 12:40:47 +1100

It may be minor, but the last sentence in section 4 is unclear. The txt I see is:

----------------

The prefix must not be used as normal prefix and announced in the BGP
   routing infrastructure.

in the BGP
   routing infrastructure.

---------------

There is some error in the markup processing used to generate this draft, but the more
substantive comment is that I can't clearly parse the sentence.

Did the authors mean:

a) The prefix must not be used as normal prefix and must not be announced in the BGP
   routing infrastructure.

or

b) The prefix must not be used as normal prefix but will (must?) be announced in the BGP
   routing infrastructure.

or

c) something else

I would prefer to see this  resolved before saying "we're done!" which I suppose is a
"NO" response to the WGLC at this stage.

regards,

    Geoff

On 29 Nov 2013, at 12:39 pm, Terry Manderson <[email-masked]> wrote:

> All,
> 
> As requested in Vancouver, and after the authors updated the draft (to
> -07) based on the Vancouver in-room discussion.
> 
> This starts a 14 day last call for this document, the last call will end
> on Friday the 13th December 2013.
> 
> You will find its text here:
> http://www.ietf.org/id/draft-ietf-lisp-eid-block-07.txt
> 
> Please review this WG item and provide any last comments.
> 
> Cheers
> Terry
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 2 Dec 2013 15:37:01 +0100

Hi Geoff,

I agree that the sentence is unclear.

The purpose was to make sure that people do not get an IP prefix for free and inject it in BGP, so it is close your interpretation a).

What about the following text:

The prefix must be used for LISP experimentation and must not be 
used as normal prefix, hence, it must be used according to [RFC6832] 
and [I-D.ietf-lisp-deployment] and must not be natively announced in the 
BGP routing infrastructure. 

Would this solve the issue?

Luigi

> The prefix must not be used as normal prefix and must not be announced in the BGP
>   routing infrastructure.

---

From: Sander Steffann <[email-masked]>
Date: Mon, 2 Dec 2013 20:48:22 +0100

Hi,

> Would this solve the issue?

That would mean that it is not allowed to be announced in BGP at all, which would mean that it is not possible to run PITRs for it. Is that really the intention?

Cheers,
Sander

---

From: Geoff Huston <[email-masked]>
Date: Tue, 3 Dec 2013 06:56:42 +1100

I'm afraid thats its still unclear to me - "natively announced" is a term I do not understand.

Are you saying that all more specifics _and_ the aggregate /32 itself must not be advertised into the IPv6 global unicast network?

Or are you saying that all more specifics of this /32 must not be advertised into IPv6 global unicast network, but the aggregate /32 should (must?) be advertised?

i.e. is this /32 unreachable from the rest of the IPv6 net in its entirety, ore are you saying that any LISP gateways into this /32 must advertise the entire /32 and not just advertise more specifics?

regards,

   Geoff

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 3 Dec 2013 22:29:40 +0100

Hi Steffan,
On 2 Dec. 2013, at 20:48 , Sander Steffann <[email-masked]> wrote:

[snip]
> That would mean that it is not allowed to be announced in BGP at all, which would mean that it is not possible to run PITRs for it. Is that really the intention?

No, that is not the intention, that is why there is a reference to the interworking RFC 6832.

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 3 Dec 2013 22:44:41 +0100

Hi Geoff,

as I said to Steffan, there is a reference to rfc 6832 that covers interworking, that should be used as reference.

PITR should announce the largest aggregate possible, ideally the /32.

Let’s try again ;-)

The prefix must be used for LISP experimentation and must not be 
used as normal prefix. Interworking between the EID block prefix 
and the non-LISP Internet is done according to [RFC6832] 
and [I-D.ietf-lisp-deployment].

Better?

Luigi

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 4 Dec 2013 15:26:19 +0000

> PITR should announce the largest aggregate possible, ideally the /32.

Luigi,

Is this really what is going to happen? 

If a PITR announces the entire /32 into the global Internet, it puts itself on the forwarding path for the entire /32, and incurs the cost associated with transporting traffic towards every site in that /32. This is supportable only if the PITR operator is somehow compensated for carrying all of that traffic.

Isn't it more likely that the PITR operator will advertise only slices of the /32, with each of those slices being assigned to either its customers (from whom it collects revenue) or the customers of other operators with whom it has made financial arrangements?

                                                      Ron

---

From: Brian Haberman <[email-masked]>
Date: Wed, 04 Dec 2013 11:31:46 -0500

> Is this really what is going to happen?

The above is why I explicitly mentioned the pain felt by 6to4 relay
routers during the Vancouver meeting.  Advertising the entire range is
not a good idea.

> If a PITR announces the entire /32 into the global Internet, it puts
> itself on the forwarding path for the entire /32, and incurs the cost
> associated with transporting traffic towards every site in that /32.
> This is supportable only if the PITR operator is somehow compensated
> for carrying all of that traffic.
> 
> Isn't it more likely that the PITR operator will advertise only
> slices of the /32, with each of those slices being assigned to either
> its customers (from whom it collects revenue) or the customers of
> other operators with whom it has made financial arrangements?

I would hope this would be the case.

Regards,
Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Dec 2013 08:44:26 -0800

> If a PITR announces the entire /32 into the global Internet, it puts itself on the forwarding path for the entire /32, and incurs the cost associated with transporting traffic towards every site in…

But maybe only from a few sources. But if the /32 needs to be divided based on region, then maybe /40s could be advertised. But to the point about "few sources", the more PITRs there are, the better the load is shared. 

And I envision PITRs will be deployed on on-path boxes anyways. Those boxes right now can route to the entire Internet, they are called PE boxes, are they not Ron?

> Isn't it more likely that the PITR operator will advertise only slices of the /32, with each of those slices being assigned to either its customers (from whom it collects revenue) or the customers…

No it won't be that way. EIDs are provider independent. If you do what we suggest, we make no forward progress.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 4 Dec 2013 16:51:27 +0000

Dino,

I am not understanding your response. Let me ask the question another way.

Assume that an operator deploys a PITR. What policy can that operator enforce to ensure that it is compensated for all (or even most) of the traffic that it carries across that PITR?

                                                                        Ron

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2013 11:44 AM
> To: Ronald Bonica
> Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list
> list
> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07
> 
> > Luigi,
> >
> But maybe only from a few sources. But if the /32 needs to be divided
> based on region, then maybe /40s could be advertised. But to the point
> about "few sources", the more PITRs there are, the better the load is
> shared.
> 
> And I envision PITRs will be deployed on on-path boxes anyways. Those
> boxes right now can route to the entire Internet, they are called PE
> boxes, are they not Ron?
> 
> its customers (from whom it collects revenue) or the customers of other
> operators with whom it has made financial arrangements?
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 04 Dec 2013 12:01:46 -0500

A partial answer that has been suggested is that the oeprator who 
deploys the PITR is an EID allocator rather than a conventional / 
existing ISP.  Unfortunately, if LISp succeeds it is not clear that the 
compensation levels can match the increasing demand for traffic in the 
critical periods.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Dec 2013 09:17:49 -0800

> Assume that an operator deploys a PITR. What policy can that operator enforce to ensure that it is compensated for all (or even most) of the traffic that it carries across that PITR?

Through the same monetizing means it does today to attract any type of traffic it wants to transit.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Dec 2013 09:20:20 -0800

> A partial answer that has been suggested is that the oeprator who deploys the PITR is an EID allocator rather than a conventional / existing ISP.  Unfortunately, if LISp succeeds it is not clear that the compensation levels can match the increasing demand for traffic in the critical periods.

Yes, it could be an (MSP) Mapping Service Provider that is an allocator. But since LISP will be a substrate it has, it can monetize other services like mobility and multi-homing at lower OpEx than it can today (that is lower OpEx for multi-homing today, there really is no seamless roaming service available).

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 4 Dec 2013 19:27:32 +0000

Hi Dino,

Could you be a bit more explicit? 

Please assume the following operator requirements:

- In order to ensure the customer experience, an operator wants to attract all traffic from the global Internet to LISP sites that it supports through PITRs that it operates.
- In order to maintain financial viability, that same operator does not want to attract any traffic from the global Internet to LISP sites that it does not support through PITRs that it operates.

Do you agree that these are both valid requirements? If so, how can the operator do this while advertising only large aggregates of the EID address block to the global Internet?

                                                                            Ron

> Sent: Wednesday, December 04, 2013 12:18 PM
> To: Ronald Bonica
> > Assume that an operator deploys a PITR. What policy can that operator
> enforce to ensure that it is compensated for all (or even most) of the
> traffic that it carries across that PITR?
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 4 Dec 2013 20:03:47 +0000

Hi Joel,

In that model, assume that I obtain EID space from an EID allocator. At some point in the future, the PITR service that that EID allocator provides becomes inadequate. What is my can I do?

Are there competing EID allocators? If I go with a competing EID allocator, do I have to renumber?

                                                          Ron

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2013 12:02 PM
> To: Ronald Bonica; Dino Farinacci
> Cc: LISP mailing list list
> >> based on region, then maybe /40s could be advertised. But to the
> >> point about "few sources", the more PITRs there are, the better the
> >> load is shared.
> >>
> >> No it won't be that way. EIDs are provider independent. If you do
> >> what we suggest, we make no forward progress.
> >>
> >> Dino
> >>
> >>>
> >>>                                                       Ron
> >>>
> >>>

---

From: Geoff Huston <[email-masked]>
Date: Thu, 5 Dec 2013 08:15:18 +1100

I don't think its quite as simple as that Ron. If the role of a service provider is to provide service to its customers then an ISP with a LISP interface may advertise the entire LISP prefix to its global unicast non-LISP customers, but no further. This is in addition to your consideration that the ISP would conventionally want to advertise the specific LISP prefixes of its customers to the larger inter-domain routing space. This is comparable to conventional routing theology: you advertise default to your customers and advertise your customers' specific routes to the world at large.

We tried this with a similar experiment with 2002::/16 some years back. It was not a blinding success, but maybe there are lessons to be learnt from that experience.

  Geoff

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 4 Dec 2013 22:34:37 +0000

> 
> I don't think its quite as simple as that Ron. If the role of a service
> provider is to provide service to its customers then an ISP with a LISP
> interface may advertise the entire LISP prefix to its global unicast
> non-LISP customers, but no further. 

Is this really how it works? If so, how would someone connected to an ISP that does not deploy a PITR access a LISP site?

                                                                 Ron

P.S. It would be great if we could nail down some of these details. For instance, who is expected to operate the PITR, the EID allocator (as Joel suggests) or the ISP (as you suggest). Who is expected to advertise which routes. Until we understand this, it is impossible to have an intelligent conversation and probably premature to make an address block allocation.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 5 Dec 2013 11:20:02 +1100

> Is this really how it works? If so, how would someone connected to an ISP that does not deploy a PITR access a LISP site?

Our experience with piecemeal advertisements of 2002::/16 points to an answer that says that such folk as you describe here are then reliant on the kindness of strangers, or alternatively things are broken for them, or even both.

> P.S. It would be great if we could nail down some of these details. For instance, who is expected to operate the PITR, the EID allocator (as Joel suggests) or the ISP (as you suggest). Who is expec…

I'm not sure I agree Ron - the prospect of the allocation has teased out this matter, and it has made an otherwise abstract conversation into one that probably needs some level of timely resolution, if we can. If we can clarify the draft even in terms of expectation of routing behaviour I think that we would have done enough for an experimental allocation context at this point in time.

Geoff

---

From: Paul Vinciguerra <[email-masked]>
Date: Thu, 5 Dec 2013 03:34:07 +0000

Ron,

I think that Dino is suggesting that ISP's with their own populations deploy PITRs for this /32 prefix and announce the /32 into BGP with a no-export community, so that you as an ISP provide encapsulation as close to source of your customer population only.  This will (1) save you transit costs to another PITR provider for this prefix. You would only be paying for transit if the RLOC were not on your network. where otherwise you might be paying for transit between two of your customers. (2) it will give your customers an optimal path because you are encapsulating close to the source. and this will (3) allow for PITR Gateways to be deployed on smaller equipment.

Also, this would not stop a given EID who wants to have global reachability from a given PITR gateway system from buying "EID Transit" from a PITR provider who will announce the more specific EID prefix out of the /32 for a price.  I don't know that announcing a more specific globally is a great idea, though.  It actually could cause traffic to take a less direct path.       

Paul
________________________________________
From: lisp [[email-masked]] on behalf of Ronald Bonica [[email-masked]]
Sent: Wednesday, December 04, 2013 2:27 PM
To: Dino Farinacci
Cc: LISP mailing list list
Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07

Hi Dino,

                                                                            Ron

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Dec 2013 20:24:38 -0800

> - In order to ensure the customer experience, an operator wants to attract all traffic from the global Internet to LISP sites that it supports through PITRs that it operates.

That would create a bad customer experience.

> - In order to maintain financial viability, that same operator does not want to attract any traffic from the global Internet to LISP sites that it does not support through PITRs that it operates.

It certainly does if its customers are LISP sites.

> Do you agree that these are both valid requirements? If so, how can the operator do this while advertising only large aggregates of the EID address block to the global Internet?

No, I don't agree.

As I said before, the /32 advertisements of an EID-block are advertised within an ISP towards the edges of the network. Those edges are towards its customers so its customers, as sources in non-LISP sites, can reach destinations in LISP sites.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Dec 2013 20:25:48 -0800

Exactly.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Dec 2013 20:27:17 -0800

Exactly. And arguably the closer the the ISP PITRs are to its customer sources, it may be on their default path so maybe the /32 doesn't need to be advertised at all.

Dino

---

From: Sander Steffann <[email-masked]>
Date: Thu, 5 Dec 2013 08:02:03 +0100

Hi,

> As I said before, the /32 advertisements of an EID-block are advertised within an ISP towards the edges of the network. Those edges are towards its customers so its customers, as sources in non-LIS…

So if it is only done this way, that means for global reachability of the LISP prefix at least one global transit provider has to run PITRs. They wouldn't mind attracting the traffic from their customers. That is what they are paid for :-)  That would make it work, *if* we can convince the big transit(s).

Cheers,
Sander

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Dec 2013 04:28:53 -0500

There are two pieces here.
We do hypothesize (and design for) having competing EID allocators and 
the ability for someone who got an allocation to move to a different EID 
allocator covering the same space.  That is necessary to keep the prices 
for allocation and map maintenance competitive.

PITRs can be run by anyone who wants to (with suitable authentication / 
authorization).  So they can be run (as Dino hypothesizes) by the ISPs. 
  They can be run by the EID allocators.  Or by third parties.  In all 
cases, they either have to be prepared for too much traffic or restrict 
what they advertise into the BGP system.  Which is why I hope that it 
will make business sense for the allocators to run PITRs, since they are 
the only ones in the right place to easily provide aggregation of EID 
allocations.

Yours,
Joel

PS: Some of this is discussed in the lisp-deployment draft.  Some of it 
isn't.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Dec 2013 05:03:44 -0500

Fortunately, the nature of the LISP architecture is that there is not 
one right way to deploy PITRs.  There are several deployment models, 
each of which address different sets of customers.  As a demonstration, 
if LISP PITR deployment required ISP support we would not have a running 
LISP testbed.

Yours,
Joel

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 5 Dec 2013 16:39:11 +0100

>> PITR should announce the largest aggregate possible, ideally the /32.

Hi Ron,

note as well that I used the word “ideally”… because IMHO it will not happen in reality ;-)

The sentence came along with the idea to avoid deploy personal PITRs.
If every LISP site gets an EID prefix and announces it in BGP by himself we would end up polluting the BGP table with EID prefixes. 

This is something we absolutely do not want.

To avoid misinterpretation I would change the following sentence currently in the document (section 4)

	To guarantee reachability from the Legacy Internet the prefix may be
  	announced in the BGP routing infrastructure by one or more PITR(s) as
   	part of larger aggregates (ideally just the entire LISP EID block).

in just

	To guarantee reachability from the Legacy Internet EID prefixes may be
  	announced in the BGP routing infrastructure by one or more PITR(s) as
   	part of larger aggregates.

and conclude the section with the paragraph (proposed in previous discussion with Geoff):

	The EID block must be used for LISP experimentation and must not be 
	used as normal prefix. Interworking between the EID block sub-prefixes 
	and the non-LISP Internet is done according to [RFC6832] 
	and [I-D.ietf-lisp-deployment].

Do you folks think this is OK?

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Dec 2013 07:41:42 -0800

> PITRs can be run by anyone who wants to (with suitable authentication / authorization).  So they can be run (as Dino hypothesizes) by the ISPs.  They can be run by the EID allocators.  Or by third parties.  In all cases, they either have to be prepared for too much traffic or restrict what they advertise into the BGP system.  Which is why I hope that it will make business sense for the allocators to run PITRs, since they are the only ones in the right place to easily provide aggregation of EID allocations.

I envision existing ISPs to run PxTRs because they have capacity planned for data movement. Where MSPs are adminstrative and policy driven. They don't need the bandwidth capacity as the data-plane providers. So, in theory they could do both but I envision that an existing data-plane ISP would offer MSP services versus the other way around.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Dec 2013 07:44:16 -0800

>   	part of larger aggregates.

Could you use "restrictively announced"? Or "announced with heavy policy applied"?

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 5 Dec 2013 16:06:02 +0000

Sander,

I think that what you are saying is true. Do folks agree?

                          Ron

> From: Sander Steffann [mailto:[email-masked]]
> Sent: Thursday, December 05, 2013 2:02 AM
> To: Dino Farinacci
> Cc: Ronald Bonica; Luigi Iannone; Geoff Huston; LISP mailing list list
> > As I said before, the /32 advertisements of an EID-block are
> advertised within an ISP towards the edges of the network. Those edges
> are towards its customers so its customers, as sources in non-LISP
> sites, can reach destinations in LISP sites.
> 
> So if it is only done this way, that means for global reachability of
> the LISP prefix at least one global transit provider has to run PITRs.
> They wouldn't mind attracting the traffic from their customers. That is
> what they are paid for :-)  That would make it work, *if* we can
> convince the big transit(s).
> 
> Cheers,
> Sander
> 
>

---

From: Sander Steffann <[email-masked]>
Date: Thu, 5 Dec 2013 17:31:40 +0100

Hi Luigi,

> Do you folks think this is OK?

Ok for me,
Sander

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 5 Dec 2013 17:16:04 +0000

Its certainly one, but as Joel said, not the only, way one could envision global deployment of PxTRs.  Another one is that regional LISP mapping providers announce their customer's (PI) EID prefixes.  In the latter case, the gains to the global routing systems are modest, but at least individual sites are not deaggregating for TE purposes.

-Darrel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Dec 2013 13:45:10 -0500

And ISPs are certainly allowed to run PITRs.
They can either advertise only the customers they support, or forward 
traffic for other folks who may well not even be their customers.  Their 
call.
But the LISP RFCs are not going to mandate that.
And I expect that there will be other alternatives.

Yours,
Joel

---

From: Geoff Huston <[email-masked]>
Date: Fri, 6 Dec 2013 06:45:12 +1100

> 	To guarantee reachability from the Legacy Internet EID prefixes may be

s/guarantee/provide/

there are no guarantees in this world!

s/Legacy Internet/non-LISP Internet/

The prospects of LISP prevailing in time are by no means assured and the use of the term "Legacy" in this context is neither informative or even remotely accurate at present. Remove it.

>   	part of larger aggregates.

s/part of large aggregates/more specifics/

please use terminology that is consistent with standard routing terms. In this case the text is referring to "more specifics" so please use that term.

The text would also add the sentence: "The intended scope of these more specific prefix advertisements may be deliberated limited by the PITR to reflect local routing policies."

> 	and [I-D.ietf-lisp-deployment].

s/used as a normal prefix/advertised in the form of more specific route advertisements in the non-LISP inter-domain routing environment/

> Do you folks think this is OK?

Not yet. Please review these suggested specific changes.

  Geoff

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 5 Dec 2013 19:59:38 +0000

Folks,

>From the conversation so far, I glean that there are two competing PITR deployment models. These are:

- User pays
- Altruistic party pays

Recent experience tells us that only the "user pays" model is viable. So, we are left to choose between the following variations of the "user pays" model:

1) Owner of a LISP site pays
2) Owner of a non-LISP site that access LISP sites pays

In http://www.ietf.org/mail-archive/web/lisp/current/msg04955.html, Joel describes a scenario that realizes model #1. In this scenario, a portion of the LISP address block is assigned to an EID allocator. For the purpose of example, assume that a /40 is assigned to the EID Allocator. From this /40, the EID allocator assigns smaller address blocks to its customers. The EID operator also operates one or more PITRs and advertises the /40, as a single aggregate prefix, from each PITR. The owner of the LISP site pays the EID allocator for these services.

In http://www.ietf.org/mail-archive/web/lisp/current/msg04965.html, Paul describes a scenario that realizes model #2. In this scenario, an ISP deploys one or more PITRs and announces the entire LISP address block (/32) from each of them. The ISP announces the /32 to its customers only and with the no-export community set. The ISP distributes the cost of the PITRs among its customers in some equitable manner.

The major advantage of model #1 is that it allows LISP sites to be globally accessible, even when some ISPs do not deploy PITRs. However, the major disadvantage of model #1 is that it leads to de-aggregation of the LISP address block. De-aggregation may be significant if customers are not required to renumber when the move from one EID allocator to another.

The major advantage of model #2 is that it allows the LISP address block to be advertised as a single, aggregate prefix. However, in this model, LISP sites are not accessible from autonomous systems that do not deploy PITRs.

Does everybody agree with this much?

                                                   Ron

---

From: Geoff Huston <[email-masked]>
Date: Fri, 6 Dec 2013 07:04:08 +1100

> I think that what you are saying is true. Do folks agree?

agree, yes. But at the same time I should point out that this approach
has some serious downside risk.

This limited advertisement scope was the theory behind the intended routing
scope of 2002::/16. The theory was that every provider would advertise
2002::/16 to its customers, and noone would need to take the unfunded transit
traffic hit of advertising this gateway prefix globally.

And some providers did precisely that. However most folk did absolutely nothing,
so reachability into the 2002::/16 space was erratic, unmanaged and non-functional.
The approach described below by Sander could be seen as a replay of this
same piecemeal limited scope advertisement scenario, and has the same risk.

What's the risk?

Again 2002::/16 has some clues.

While the experiment is of small scale and the traffic levels are insignificant
some folk will advertise the /32 prefix globally and absorb the unfunded
transit traffic as part of the experiment. This sounds great, but it has
some serious downsides.

The consequent routing from the non-LISP world to the LISP world may well
have highly inefficient and lengthy paths for many, as the "closest" gateway
may well be on the other side of the planet.  (e.g. from Australia I still
send most of my Teredo traffic via Amsterdam - obviously performance sucks when this
happens!)

The consequent impact on performance of these extended "dog leg" paths that need
to head to the PITR gateway to transit between the LISP and non-LISP routing domains
which may well have some negative impact on the perceptions of LISP performance
in the context of this experiment. i.e. it appears that the negative 6to4 perceptions were
not only due to widespread use of local protocol 41 filters, but also due to the
asymmetric and highly erratic transit paths between end users and the sparsely deployed
6to4 gateways.

Geoff

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Dec 2013 13:07:38 -0800

> send most of my Teredo traffic via Amsterdam - obviously performance sucks when this

This is possibly why the overlay could go very far to the edges. To the point of in the hosts or the attached networking device. We have seen this happen, a bit, with the data center overlays.

Dino

P.S. Let the host versus network battle begin ... again ...

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Dec 2013 10:09:43 +0100

Hi Geoff,

I was more thinking of one or more large (glibal) transit providers to include LISP PITR services as an official managed service with anycast nodes around the world. I definitely don't want to repeat the 6to4 disaster where there are a few sparsely distributed volunteer nodes, and to make it usable we cannot expect each and every ISP to run a PITR for their own customers. Certainly not while it is experimental.

Transit providers actually get paid for the traffic they handle, so for them it can be economically interesting to offer well performing PITR services.

Met vriendelijke groet,
Sander Steffann

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 6 Dec 2013 16:07:14 +0100

Hi Geoff,

thanks for the suggestions.

If I include as well the previous comment from Dino the text right now looks like this:

	To provide reachability from the non-LISP Internet EID prefix may be
	restrictively announced in the BGP routing infrastructure by one or more 
	PITR(s) as more specifics. The intended scope of these more specific 
	prefix advertisements may be deliberated limited by the PITR to reflect 
	local routing policies.

	The EID block must be used for LISP experimentation and must not be 
	advertised in the form of more specific route advertisements in the 
	non-LISP inter-domain routing environment. Interworking between the 
	EID block sub-prefixes and the non-LISP Internet is done according to 
	[RFC6832] and [I-D.ietf-lisp-deployment].

Does it look better now?

Luigi

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 6 Dec 2013 16:41:33 +0000

Joel,

Are there any rules regarding a) who can run a PITR and b) what prefixes that PITR can advertise? If so, who enforces the rules? How?

                                               Ron

> Sent: Thursday, December 05, 2013 1:45 PM
> To: Dino Farinacci
> Cc: Ronald Bonica; LISP mailing list list
> traffic for other folks who may well not even be their customers.
> Their call.
> >> PITRs can be run by anyone who wants to (with suitable
> authentication / authorization).  So they can be run (as Dino
> hypothesizes) by the ISPs.  They can be run by the EID allocators.  Or
> by third parties.  In all cases, they either have to be prepared for
> too much traffic or restrict what they advertise into the BGP system.
> Which is why I hope that it will make business sense for the allocators
> to run PITRs, since they are the only ones in the right place to easily
> provide aggregation of EID allocations.
> >
> > I envision existing ISPs to run PxTRs because they have capacity
> planned for data movement. Where MSPs are adminstrative and policy
> driven. They don't need the bandwidth capacity as the data-plane
> providers. So, in theory they could do both but I envision that an
> existing data-plane ISP would offer MSP services versus the other way
> around.
> >
> > Dino
> >
> >
> >
>

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 6 Dec 2013 19:54:46 +0100

> I think that what you are saying is true. Do folks agree?

Yes, Sander's explanation was better than the one I was working on.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 6 Dec 2013 19:56:19 +0100

On Thu, Dec 5, 2013 at 4:39 PM, Luigi Iannone <[email-masked]> wrote:
<snip>
> Do you folks think this is OK?

Yes it's ok for me.

--

---

From: Ross Callon <[email-masked]>
Date: Fri, 6 Dec 2013 19:04:29 +0000

> ... and to make it usable we cannot expect each and every ISP to run a PITR for their own customers

Yes indeed. A problem with all service providers offering PITR service to 
their own customers only is that for quite a while not all service providers
will choose to do anything related to LISP. Thus in the intermediate term if 
some service providers offer and use LISP, and others do not, there needs to 
be some way for customers from the "no LISP" service providers to send traffic 
to customers using LISP from the "I support LISP" service providers.

Thus to me it seems that service providers who support LISP for their 
customers are going to need to supply the PITRs to reach their customers. 
Of course it is possible that you could be right and this could be one
global provider who can offer service in many parts of the world (assuming
that someone chooses to be that provider). 

Ross

-----Original Message-----
From: lisp [mailto:[email-masked]] On Behalf Of Sander Steffann
Sent: Friday, December 06, 2013 4:10 AM
To: Geoff Huston
Cc: LISP mailing list list
Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07

Hi Geoff,

Met vriendelijke groet,
Sander Steffann

---

From: [email-masked]
Date: Mon, 9 Dec 2013 05:33:37 -0500 (EST)

Sounds like a job for the NSA - collateral compensation included :-(

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Joel M. Halpern <[email-masked]>
An: Ronald Bonica <[email-masked]>; Dino Farinacci <[email-masked]>
Cc: LISP mailing list list <[email-masked]>
Verschickt: Mi, 4 Dez 2013 6:02 pm
Betreff: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07

Yours,
Joel

On 12/4/13 11:51 AM, Ronald Bonica wrote:
> Assume that an operator deploys a PITR. What policy can that operator enforce 
to ensure that it is compensated for all (or even most) of the traffic that it 
carries across that PITR?