Subject: [lisp] a /16 of IPv6 for LISP EID

From: Terry Manderson <[email-masked]>
Date: Thu, 2 Dec 2010 17:13:00 -0800

Folks,

WG co-chair hat on.

During the Beijing meeting, the desire for a block of IPv6 for LISP EIDs
what expressed by several participants. Some discussion occurred and a /16
appeared to be the suitable size.

The action item on the Chairs was to bring this to the mailing list and
first ask the questions:

o - Is a IPv6 block for LISP needed?
o - Is a /16 the "right" size?

If there is consensus on this we can then fully resurrect Dave's draft (that
he has already posted to the list) to achieve the IPv6 allocation from IANA.

Cheers
Terry (& Joel)

PS, it may also be worth thinking about how you want this block administered
and the required work needed in RIR-land.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Dec 2010 18:04:39 -0800

> o - Is a IPv6 block for LISP needed?

I think so.

> o - Is a /16 the "right" size?

I think so.

> he has already posted to the list) to achieve the IPv6 allocation  

I vote for resurrection.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 3 Dec 2010 09:47:03 +0100

On Dec 3, 2010, at 2:13 , Terry Manderson wrote:

[snip]
> o - Is a IPv6 block for LISP needed?

I think that it will help, but...

We should try to be clever and not evolve to a LISPv6 world where only people that are in that block can use LISP. Ergo, let's keep the system open to people that are no willing to renumber.

> o - Is a /16 the "right" size?

IMHO it is more than enough.

> he has already posted to the list) to achieve the IPv6 allocation from IANA.

OK also on this, but....

I would prefer avoiding any reference to specific mapping system solutions. In the version forwarded by Dave there is strong reference to LISP+ALT. I would prefer more discussion on why and how we plan to use the block. I can help in the writing if needed.

ciao

Luigi

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: David Meyer <[email-masked]>
Date: Fri, 3 Dec 2010 07:14:10 -0800

I'll just note that I'll update the draft to use current definitions and to
give
a bit more of an explanation as to why we'd like the block.

Dave

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Dec 2010 08:45:20 -0800

> We should try to be clever and not evolve to a LISPv6 world where  
> only people that are in that block can use LISP. Ergo, let's keep  
> the system open to people that are no willing to renumber.

Definitely agree.

What this new /16 block does is in an ITR at a remote site that is  
sending to all types of destinations (i.e. non-LISP destinations, LISP  
destinations not in this block, and LISP destinations in this block)  
that when configured with a configuration command to "use-well-known- 
eid-block" that when a packet arrives that is not destined to this  
block, the ITR will natively forward it is not a LISP site.

Today, the way this behaves is by sending a Map-Request for a  
destination that is not a LISP-site which means packets are dropped  
until the mapping system tells the ITR that it's not a LISP site.

To be sensitive to Luigi's comment above, when the configuration  
command is disabled, then it works like it does today.

Dino

> I would prefer avoiding any reference to specific mapping system  
> solutions. In the version forwarded by Dave there is strong  
> reference to LISP+ALT. I would prefer more discussion on why and how  
> we plan to use the block. I can help in the writing if needed.
>
> ciao
>
> Luigi
>
>
>> Cheers
>> Terry (& Joel)
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Dec 2010 12:41:18 -0500

I am not sure I follow how this would "work".
(Color me a confused participant.)
On the one hand, it is not clear to me why it would be valuable in IPv6 
to permit LISP EIDs from some block other than the reserved block.

On the other hand, I do not see how a reserved prefix helps us if any 
noticeable amount of LISP IPv6 usage is outside of that block.
Dino, you suggest that it could be used depending upon a setting of the 
border ITR.  But the question of whether one needs to check is not a 
matter of the originating site.  It is precisely a matter of whether one 
is talking to sites that are LISP and outside of the prefix.
So it seems like turning on the knob you propose (to turn off the map 
checks for destinations outside of the allocated prefix) would mean that 
such destinations would end up going through some random PITR, since 
they are actually LISP sites.  Hence they would get worse traffic 
behavior when talking to regular LISP sites than they would if they did 
not use LISP.

Yours,
Joel

On 12/3/2010 11:45 AM, Dino Farinacci wrote:
>> We should try to be clever and not evolve to a LISPv6 world where only
>> people that are in that block can use LISP. Ergo, let's keep the
>> system open to people that are no willing to renumber.
>
> Definitely agree.
>
> that when configured with a configuration command to
> "use-well-known-eid-block" that when a packet arrives that is not
> destined to this block, the ITR will natively forward it is not a LISP
> site.
>
> To be sensitive to Luigi's comment above, when the configuration command
> is disabled, then it works like it does today.
>
> Dino
>
>>
>> solutions. In the version forwarded by Dave there is strong reference
>> to LISP+ALT. I would prefer more discussion on why and how we plan to
>> use the block. I can help in the writing if needed.
>>
>> ciao
>>
>> Luigi
>>
>>
>>> Cheers
>>> Terry (& Joel)
>>>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Dec 2010 16:25:40 -0800

> On the one hand, it is not clear to me why it would be valuable in  
> IPv6 to permit LISP EIDs from some block other than the reserved  
> block.

Because you don't want existing IPv6 sites to renumber to deploy LISP?

> On the other hand, I do not see how a reserved prefix helps us if  
> any noticeable amount of LISP IPv6 usage is outside of that block.

Is any noticeable mean a lot or a little?

> Dino, you suggest that it could be used depending upon a setting of  
> the border ITR.  But the question of whether one needs to check is  
> not a matter of the originating site.  It is precisely a matter of  
> whether one is talking to sites that are LISP and outside of the  
> prefix.

No, not really, but I'm having a problem parsing your words above. Can  
you rephrase please?

> So it seems like turning on the knob you propose (to turn off the  
> map checks for destinations outside of the allocated prefix) would  
> mean that such destinations would end up going through some random  
> PITR, since they are actually LISP sites.  Hence they would get  
> worse traffic behavior when talking to regular LISP sites than they  
> would if they did not use LISP.

This is not true. The mapping database tells you if the destination  
address is a LISP site or not. And if the destination is not a LISP  
site, you want to forward packets natively directly to the non-LISP  
site (no PITR involved here). If you turn the knob on, here is the  
algorithm:

(1) If the destination is in the /16 block, send a map-request.
(2) If the destination is not in the /16 block, send packet natively  
to non-LISP site.

Dino

>>> only
>> command
>>> reference

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Dec 2010 23:33:12 -0500

Rephrasing below, using my start and your end...

On 12/3/2010 7:25 PM, Dino Farinacci wrote:
>> IPv6 to permit LISP EIDs from some block other than the reserved block.
>

Given that IPv6 allows multi-numbering, and that there are simply very 
few IPv6 sites, it seems simpler to just not allow it, but see below and 
maybe I am still confused.

> site, you want to forward packets natively directly to the non-LISP site
> (no PITR involved here). If you turn the knob on, here is the algorithm:
>
> (2) If the destination is not in the /16 block, send packet natively to
> non-LISP site.
>
> Dino

So, suppose a site (A) turns the knob on.  And some other site (B) is 
using LISP, but not numbered from the prefix.
Then traffic from A to B gets forwarded as non-LISP.  Since The 
addresses being used for B are actually LISP EIDs, this traffic then has 
to find a PITR in order to get properly tunneled to the site.

There is a way out of this.  All LISP IPv6 sites not from the block 
could be required to continue advertising their LISP prefix in BGP. 
This would mean that they don't get as much advantage (since most folks 
won't treat them as LISP...
Seems like a bad trade.  I will assume that was not your intention.  then:

Consequence: Traffic to LISP sites not within the prefix (early IPv6 
adopters who get persuaded to use LISP) from efficient LISP adopters 
(who want the knob turned on), will have to take the long path through 
the PITR.

This seems counter-productive.

Obviously, we can not stop people from doing this.
If sites like B are not rare, then no one will be willing to turn on the 
knob, at which point there is no point in having allocated the prefix. 
The prefix allocation only makes sense if we expect most sites to be 
able to use that knob, and use it correctly, a lot more than merely 
"most" of the time.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Dec 2010 21:58:11 -0800

> Given that IPv6 allows multi-numbering, and that there are simply  
> very few IPv6 sites, it seems simpler to just not allow it, but see  
> below and maybe I am still confused.

Understand now. Thanks.

>> site
> So, suppose a site (A) turns the knob on.  And some other site (B)  
> is using LISP, but not numbered from the prefix.
> addresses being used for B are actually LISP EIDs, this traffic then  
> has to find a PITR in order to get properly tunneled to the site.

Got it.

> This would mean that they don't get as much advantage (since most  
> folks won't treat them as LISP...

Right, not my intention.

> (who want the knob turned on), will have to take the long path  
> through the PITR.
>

Agree.

> If sites like B are not rare, then no one will be willing to turn on  
> the knob, at which point there is no point in having allocated the  
> prefix. The prefix allocation only makes sense if we expect most  
> sites to be able to use that knob, and use it correctly, a lot more  
> than merely "most" of the time.

Agree. So we can't predict the future, so we can't decide if the new  
block is worth it.

But what the block does help with is that PITRs can advertise one  
prefix and as new sites come on to LISP with EID-prefixes in this  
block, the PITRs don't need to change.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Sat, 4 Dec 2010 20:23:25 +0100

On Dec 4, 2010, at 6:58 , Dino Farinacci wrote:

>> Given that IPv6 allows multi-numbering, and that there are simply very few IPv6 sites, it seems simpler to just not allow it, but see below and maybe I am still confused.
> 
> Understand now. Thanks.

IMHO, The multi-numbering can be very useful for incremental deployment. 
If a site A is in the 2001/16 space instead of renumber the network in the LISP/16 or instead of setup a PITR for its prefix it can just ask for a prefix in the LISP/16 and start deploying LISP in its network. If everything works smoothly and LISP gives advantages to that site it will be natural to drop the old 2001/16 prefix and use only the LISP/16 prefix without disruption.

This makes me realize that if we finally ask for the LISP/16 we should include in the deployment draft text that explains how this LISP/16 can be deployed.

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 4 Dec 2010 11:41:12 -0800

Definitely a good point Luigi.

Dino

On Dec 4, 2010, at 11:23 AM, Luigi Iannone wrote:

>>> very few IPv6 sites, it seems simpler to just not allow it, but  
>>> see below and maybe I am still confused.
>>
>> Understand now. Thanks.
>
> If a site A is in the 2001/16 space instead of renumber the network  
> in the LISP/16 or instead of setup a PITR for its prefix it can just  
> ask for a prefix in the LISP/16 and start deploying LISP in its  
> network. If everything works smoothly and LISP gives advantages to  
> that site it will be natural to drop the old 2001/16 prefix and use  
> only the LISP/16 prefix without disruption.
>
> This makes me realize that if we finally ask for the LISP/16 we  
> should include in the deployment draft text that explains how this  
> LISP/16 can be deployed.
>
> Luigi

---

From: Loránd Jakab <[email-masked]>
Date: Sun, 05 Dec 2010 13:18:22 +0100

> This makes me realize that if we finally ask for the LISP/16 we should include in the deployment draft text that explains how this LISP/16 can be deployed.

Will do, thanks. But maybe we should wait until it's allocated.

-Lori