Subject: [RAM] Fwd: RAM post from [email-masked] requires approval

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Apr 2007 10:28:41 -0700

Resend.

Dino

Begin forwarded message:

> From: Lixia Zhang <[email-masked]>
> Date: April 13, 2007 8:06:27 AM PDT
> To: Dino Farinacci <[email-masked]>
> Subject: Fwd: RAM post from [email-masked] requires approval
>
> this is the msg that was held up.
> where came that long reference list?
>
>
> Begin forwarded message:
>
>>
>> From: [email-masked]
>> Date: April 11, 2007 10:54:53 PM PDT
>>
>>
>> References:  
>> <[email-masked]><98D229CF-EC80-4274- 
>> [email-masked]><460D253A. 
>> [email-masked]><E537E08A-6FD2-4FBD-8E09- 
>> [email-masked]><[email-masked]><03F894F9-33 
>> [email-masked]><461124DB. 
>> [email-masked]><[email-masked] 
>> rg><[email-masked]><A3C28ADA-8EDC-4C77-8345-0DC534208378@ 
>> virtualized.org><[email-masked]>  
>> <[email-masked]>  
>> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH- 
>> NW-7V2.nw.nos.boeing.com>  
>> <[email-masked]>  
>> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH- 
>> NW-7V2.nw.nos.boeing.com>  
>> <[email-masked]> <5E51FC14-95F1-4A4F- 
>> [email-masked]>  
>> <[email-masked]> <A0175920- 
>> [email-masked]>  
>> <[email-masked]>  
>> <B98418F8-316A-4CD0-8FF0-576!
>>   [email-masked]> <558071D3-41B4-4362- 
>> [email-masked]>
>> Mime-Version: 1.0 (Apple Message framework v752.3)
>> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>> Message-Id: <[email-masked]>
>> Cc: marcelo bagnulo braun <[email-masked]>,
>>  Tony Li <[email-masked]>,
>>  "Templin, Fred L" <[email-masked]>,
>>  [email-masked]
>> Content-Transfer-Encoding: 7bit
>> From: Dino Farinacci <[email-masked]>
>> Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP
>> Date: Wed, 11 Apr 2007 22:54:51 -0700
>> To: Peter Schoenmaker <[email-masked]>
>> X-Mailer: Apple Mail (2.752.3)
>> Return-Path: [email-masked]
>> X-OriginalArrivalTime: 12 Apr 2007 05:54:52.0895 (UTC) FILETIME= 
>> [16F6AEF0:01C77CC7]
>>
>>> I hope ultimately customers use PI addresses that are not injected
>>> into the BGP core.  This seems like the ultimate solution, to give
>>> every host a unique identifier.  link-local/private addresses are
>>> only an interim step.
>>
>> So let me ask you this Peter. If you get longer prefix routes (but
>> not more of them) does that give you (a tier-1 ISP) better
>> opportunity to aggregate to your peers?
>>
>> Dino
>>
>>
>>
>>
>> From: [email-masked]
>> Subject: confirm 2b3f21d937eef3857989c83e845322e5041b4736
>>
>>
>> If you reply to this message, keeping the Subject: header intact,
>> Mailman will discard the held message.  Do this if the message is
>> spam.  If you reply to this message and include an Approved: header
>> with the list password in it, the message will be approved for  
>> posting
>> to the list.  The Approved: header can also appear in the first line
>> of the body of the reply.
>>

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Peter Schoenmaker <[email-masked]>
Date: Fri, 13 Apr 2007 13:48:55 -0400

>>> opportunity to aggregate to your peers?

Today it does not make a difference because we do not aggregate  
routes from customers that we recieve via BGP.  The main reason we do  
this is that we do not know if they are announcing the same route to  
other providers.

peter

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Apr 2007 14:00:08 -0700

> routes from customers that we recieve via BGP.  The main reason we  
> do this is that we do not know if they are announcing the same  
> route to other providers.

Don't you think this process can change if we had a locator-id split?  
That is the site would only advertise the blocks you gave them back  
to you and no where else. Even if they didn't follow this process,  
you could still aggregate. Would this help on the core side?

Dino

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Apr 2007 14:16:28 -0700

> Don't you think this process can change if we had a locator-id  
> split? That is the site would only advertise the blocks you gave  
> them back to you and no where else. Even if they didn't follow this  
> process, you could still aggregate. Would this help on the core side?

If we do the split properly, then the end-site wouldn't need to  
advertise anything to the ISP in the first place, so there'd be  
nothing to aggregate.

Tony

---

From: Peter Schoenmaker <[email-masked]>
Date: Fri, 13 Apr 2007 17:21:13 -0400

> process, you could still aggregate. Would this help on the core side?

The BGP policy may not change, so we may still not want to aggregate  
bgp announcement.  The key difference will be that customer will not  
need BGP in order to multihome.  Teaching customers that they do not  
need BGP to multihome may become a difficult education process.

peter

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Apr 2007 14:28:43 -0700

> advertise anything to the ISP in the first place, so there'd be  

I was referring to the ISP further aggregating.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Apr 2007 14:30:18 -0700

> The BGP policy may not change, so we may still not want to  
> aggregate bgp announcement.  The key difference will be that  
> customer will not need BGP in order to multihome.

I see, that sounds like a good OpEx savings to me.

>   Teaching customers that they do not need BGP to multihome may  
> become a difficult education process.

I'm sure if you tell them they can turn off something, that they will  
listen.

Dino

---

From: Peter Schoenmaker <[email-masked]>
Date: Fri, 13 Apr 2007 17:35:38 -0400

On Apr 13, 2007, at 5:30 PM, Dino Farinacci wrote:

> I'm sure if you tell them they can turn off something, that they  
> will listen.

New customers will not be a problem.  Customers that are familiar  
with how BGP multihoming works will be much more difficult to educate  
to think with a different mindset.

peter

---

From: "Chris L. Morrow" <[email-masked]>
Date: Fri, 13 Apr 2007 21:37:15 +0000 (GMT)

> need BGP to multihome may become a difficult education process.

there is also the issue of what 'size' customer... a smaller site that
doesn't have 'PI' space (locator space) may not (will not depending on the
split) need bgp at all.  A larger site that justifies/needs/pays-for 'PI'
(locator) space will still do BGP and participate in the 'DFZ'.

This is likely understood, but I think it's good to be explicit that not
everything will be behind X large providers. There are shades/degrees and
we'll have to deal with that going forward.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Apr 2007 15:57:14 -0700

> (locator) space will still do BGP and participate in the 'DFZ'.

Well, you could take a PI advertisement from the site but deploy an  
ITR on your PE so the PI can stop there. Not sure what your incentive  
is to do so though. I guess if they pay you big dollars for PI, the  
cost will be a bit more for you to manage the non-pollution of it.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Apr 2007 06:26:13 -0700

I may be missing the point of this, but in a LISP 2/3 world
why couldn't it be that all customers (large and small) could
get PI prefixes if they wanted them? The PI identifiers are
not carried in the core, so there is no strong requirement
for hierarchical aggregation, right?

Fred
[email-masked]  

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Friday, April 13, 2007 3:57 PM
> To: Chris L. Morrow
> Cc: [email-masked]
> Subject: Re: [RAM] Fwd: RAM post from [email-masked] requires approval
> 
> >>>
> aggregate
> > doesn't have 'PI' space (locator space) may not (will not 
> depending  
> > on the

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 Apr 2007 09:14:33 -0700

> for hierarchical aggregation, right?

To make distribution of the mapping entires scale, you don't want to  
send them everywhere, bandwidth-vs-memory tradeoff.

Dino