Subject: [RRG] Comments on draft-lewis-lisp-interworking

From: Jari Arkko <[email-masked]>
Date: Wed, 05 Mar 2008 00:03:30 +0200

I read this draft a couple of weeks ago and had a few comments.

First of all, as I have stated before, having this document has been a
big improvement. We need to talk about the way legacy and new networks
communicate, we need to talk about the incentives and deployment
scenarios. Thanks for writing it!

>    In case 3 (LISP site to Non-LISP site), a LISP site can send packets
>    to a non-LISP site because the non-LISP site prefixes are routable.
>    The non-LISP site need not do anything new to receive packets.  The
>    only action the LISP site needs to take is to know when not to LISP-
>    encapsulate packets.

Hmm. But aren't there other things involved, too? If you do not
LISP-encapsulate, you must be performing some kind of NAT translation to
the transit address space, right? You describe that later in the
document, but the above text excerpt does not recognize that you have to
do more than just send packets...

Observation on Section 4.3: limiting the impact of routable EIDs is not
enough, we have to create an incentive to do so. Since we cannot block
people from advertising things in BGP, pretty much the only remaining
option is to make some other approach more desirable: better, cheaper,
faster, etc. Can you say something about what

Comment on Section 5: The document should talk about what is the
motivation for deploying PTRs.

Comment on Section 5: I don't understand how we distinguish advertising
the EIDs vs. larger prefixes. Given the non-aggregability of EIDs, can
you even have larger ones, other than "all EIDs"? The business
implications seem severe, because you cannot have contracts for specific
service.

Section 5.2: it seems that the MTU implications of PTRs are different
from pure LISP. In pure LISP, you have the ability to locally configure
your network with an MTU that fits in 1500 bytes even if a LISP header
is added to it. With PTRs, the encapsulation is happening without the
knowledge of the legacy endsite. This means that either we must require
the legacy endsites (and paths to them) to be able to deal with PMTU
discovery or the PTR - LISP site tunneling mechanisms need to be able to
carry 1500 byte payload packets. Some discussion of this might be useful
in the document.

Section 5.3, scaling. It seems that we hit the worst point when 50% of
the Internet is LISP capable and 50% not. Assuming equal traffic
distribution, 25% of traffic in the Internet would have to go through a
PTR, right? It would be interesting to see some discussion of the
anycast routing properties in this situation. For instance, do we expect
that only "all EIDs" can be advertised? If so, how stable can we expect
the anycast routing to stay? Can we expect sudden switching to other
PTRs, which with these traffic amounts would obviously be a pretty
significant event? I'm sure we have some data on this from DNS anycast
already...

Section 7, security considerations. There is the obvious vulnerability
that you can advertise someone else's EID space as a PTR, and you get to
see their traffic. But the interesting question is if this is any
different from you doing the same thing in regular BGP. I think there is
one difference -- in BGP you are limited with what you can do for the
attacker - victim site path, because you need to simultaneously attract
the victim's packets to you but also be able to forward them to the
victim after taking a peek into them. With LISP encapsulation, this is
not an issue and you can do it from any location.

In any case, I'd like to see some discussion of this draft and the above
topics in the meeting!

Jari

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 5 Mar 2008 22:56:03 -0800

> I read this draft a couple of weeks ago and had a few comments.

Thanks for reading the draft and sending comments.

> scenarios. Thanks for writing it!

Yes, a big improvement over having nothing, sure.  ;-)

> Hmm. But aren't there other things involved, too? If you do not

Like what?

> LISP-encapsulate, you must be performing some kind of NAT  

No, not in this case. We break out the case when the non-LISP site  
wants to send packets to the LISP site into 2 sub-cases, if the LISP  
site has routable addresses and when it does not.

And of course when it doesn't have routable addresses, you have to  
NAT, you have no choice. Just like your home network does.

> faster, etc. Can you say something about what

That is what the PTR option is for. It's simply a question of having  
this control locally at the site (the NAT solution) or having the  
infrastructure help (the PTR solution). They both have their downsides.

> motivation for deploying PTRs.

Will add to it, but you probably guess the motivation is so you can  
pull PI addresses out of the core as soon as possible without using  
NATs on the edges.

> the EIDs vs. larger prefixes. Given the non-aggregability of EIDs, can

Don't assume EIDs are not aggregatable, they could be very much  
aggregatable in IPv6 down to a /16. In IPv4, we'll have to use a few  
prefixes, hopefully just 10 or so and not in the 100s and definitely  
won't deploy it if in the 1000s. But many think this is still a very  
small price to pay (in the 1000s) to be able to suppress more specific  
PA advertisements of PI advertisements from the 10^6 multi-homed sites  
we expect to come.

> implications seem severe, because you cannot have contracts for  

Well, maybe a business opportunity too!

> from pure LISP. In pure LISP, you have the ability to locally  

Please don't differentiate a PTR from a pure LISP. A PTR is a router  
that does ITR functionality but does not do ETR functionality because  
the packet has a direct-site return path.

> carry 1500 byte payload packets. Some discussion of this might be  

See draft-farinacci-lisp-06.txt for resolving MTU issues.

> PTR, right? It would be interesting to see some discussion of the

How do you think 25% of all traffic today will go through one router?  
Well, it doesn't happen so LISP can't help create more switching  
capacity. You build out many of them. And deployment experience will  
tell us if the "interworking tunnels" should have large diameter (PTRs  
deployed closer to non-LISP sites) or smaller diameter (PTRs deployed  
closer to LISP-sites).

This will also depend on if PA address are also used as EIDs. Because  
you'll have an overlap situation between these two namespaces.

This is why 240.0.0.0/4 has value. You could use it strictly for  
additional addresses for the locator namespace or use it the EID  
namespace. The former is easier to deploy because it would be required  
in a smaller set of product platforms. But the later is more  
beneficial for PTR aggregation performance but will require host  
platform changes too.

> anycast routing properties in this situation. For instance, do we  

PTRs might look like they use anycast addressing since other proposals  
refer to it as such. But it's not using anycast addressing. That is  
the PTR routers do not have the same IP address assigned to each of  
them. They simply advertise the same EID-prefixes making the non-LISP  
sites think there are multiple paths to the EID. This way, you  
distribute load by having sources send to the closest PTR which will  
encapsulate to the LISP site.

> significant event? I'm sure we have some data on this from DNS anycast

I am not following you, how would switching to other PTRs help the  
"all EIDs cannot be advertised" question.

> that you can advertise someone else's EID space as a PTR, and you  

Someone elses? They all advertise the entire space if we can pull it  
off. And if SoBGP is up and running, we can say what AS origins can  
advertise the EID-prefixes.

> not an issue and you can do it from any location.

I think it's the same, in both cases you build a secure infrastructure  
or you do ingress filtering the best you can.

> In any case, I'd like to see some discussion of this draft and the  

Sure, when or if we get a time slot.

Dino

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Mar 2008 14:11:49 -0500

Dino,

> NAT, you have no choice. Just like your home network does.

Right. I was merely pointing out the need for the NAT in the second case.

> infrastructure help (the PTR solution). They both have their downsides.

I understand that there are two options, and that they are different.
But it still has to be the case that whatever my site decides to do the
end result has to be better than simply pushing the information via BGP,
otherwise it won't get done. I think the PTR approach is the potentially
more attractive approach. However, for me to rely on that there has to
be someone who deploys a PTR. Who do they deploy it? (I think there are
good answers to this; I'm asking you to document those.)

> pull PI addresses out of the core as soon as possible without using

This is a motivation from the point of view of the Internet, not a
motivation for me as an business person to buy a new box that serves
some other people.

As I said above, I think there are reasons for doing this. For instance,
I could imagine a business where I'm selling PTR connectivity to LISP
sites. However, this appears to work only if I can choose the LISP sites
that I'm serving. This seems to imply that I can only advertise part of
the identifier space with anycast. I'm wondering how that's better than
advertising PI space... but maybe your responses below on aggregation
will shed some light on this.

> PA advertisements of PI advertisements from the 10^6 multi-homed sites

I'm sorry, but I don't understand why you believe the EIDs are
aggregatable. Sure, we can choose a /4 which holds the EID space. But
the question is whether a PTR can advertise all of this, or if due to
business reasons you want to be able to switch between PTR providers. If
this is needed, I don't see how you can aggregate EID space.

> Well, maybe a business opportunity too!

Ok -- can you say more?

I realize that you don't want to reveal the business opportunities that
you see. But I would like to see even one example of a situation where
this makes business sense AND you can aggregate EID space.

> the packet has a direct-site return path.

Point taken about the return path.

> See draft-farinacci-lisp-06.txt for resolving MTU issues.

I did read it earlier, and I liked the MTU handling. However, you still
need to deal with path MTU on the legacy-to-LISP path with PTRs, and as
I explained above, you have to assume one of the following for this to work:

1) support for the new ICMP-less path MTU RFC in the legacy site.
2) that ICMP is not blocked in the legacy site or on the path to it
3) that path between PTR and LISP site has MTU > 1500 bytes.

> How do you think 25% of all traffic today will go through one router? 

Not one router, but through the set of all PTRs in the world.

> deployed closer to non-LISP sites) or smaller diameter (PTRs deployed

This sounds reasonable, but I'm not sure I fully understand how this
works -- maybe we need to resolve the aggregation question first before
we can talk about this. If you can aggregate EID space in the PTRs, I
think this will work.

> encapsulate to the LISP site.

So, the PTRs have different IP addresses, but all advertise at least
partially overlapping EID space? Ok, the PTRs do not act as anycast end
points. Still, in the routing system the same EID space is advertised
from multiple locations. I suspect the properties of this are similar to
anycast.

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 6 Mar 2008 21:37:10 -0800

> end result has to be better than simply pushing the information via  

Pushing what information to BGP? I'm not following you.

> good answers to this; I'm asking you to document those.)

If a LISP sites wants non-LISP sites to connect to it, which they  
will, they will figure out how to deploy a PTR. So you, the non-LISP  
site doesn't have to care.

> motivation for me as an business person to buy a new box that serves

You don't buy it just because it *only serves* another person. You, as  
a site, want LISP so you can get portable EID prefixes and that you  
can do multihoming cheaper and get ingress TE on your links.

> will shed some light on this.

That is not the way it should work, or else you'll have EIDs for each  
island of support.

Is your point that there is no motivation for anyone to deploy a PTR?

> this is needed, I don't see how you can aggregate EID space.

Not just one PTR. A bunch of them will advertise it for compatibility  
sake. But if I had to choose I would error on using NAT as the  
solution because I don't want any additional infrastructure if I can  
avoid it.

We put PTRs in there to allow a solution that doesn't use NAT.  
Possibly for IPv6 which could be NAT-free.

> need to deal with path MTU on the legacy-to-LISP path with PTRs, and  

Could you explain this better please. References don't do me any good.  
I want to know exactly what you are talking about before I speculate a  
reply.

> 3) that path between PTR and LISP site has MTU > 1500 bytes.

Well, can't you tell from the spec we believe in 3)?

> Not one router, but through the set of all PTRs in the world.

Right, so you answered your own question.

> we can talk about this. If you can aggregate EID space in the PTRs, I

Here's the scenario:

1) Start out deploying 100 PTRs for IPv6.
2) They each advertise an IANA-assigned global IPv6 EID block of  
0240::/16.
3) As more LISP sites come on, you add more PTRs.

> partially overlapping EID space? Ok, the PTRs do not act as anycast  

I didn't say that. See scenario above.

> from multiple locations. I suspect the properties of this are  

People confuse this a lot. Anycast is how you assign addresses to  
boxes. Advertising the same prefix from multiple spots is multi-path  
routing.

Dino

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 6 Mar 2008 23:14:11 -0800

Jari,

I'd like to add to a few of Dino's comments about PTRs.  Please see
below.

Thanks again for the feedback on the draft, its very much appreciated.

> You don't buy it just because it *only serves* another 
> person. You, as a site, want LISP so you can get portable EID 
> prefixes and that you can do multihoming cheaper and get 
> ingress TE on your links.

I'd also like to add that an ISP can benefit by deploying PTRs.  Post
encapsulation, the outer header is the destination RLOC.  A provider who
doesn't deploy a PTR will have to route all LISP destined traffic to
someone who does.  One could imagine a scenario where providers could
end up sending more traffic to expensive transit links rather than to
RLOC addresses to which they may have settlement-free peering.  For
large transit providers, deploying PTRs may attract more traffic, and
therefore more revenue, from their customers.

> 
> > As I said above, I think there are reasons for doing this. For 
> > instance, I could imagine a business where I'm selling PTR 
> > connectivity to LISP sites. However, this appears to work only if I 
> > can choose the LISP sites that I'm serving. This seems to 
> imply that I 
> > can only advertise part of the identifier space with anycast. I'm 
> > wondering how that's better than advertising PI space... but maybe 
> > your responses below on aggregation will shed some light on this.
> 
> That is not the way it should work, or else you'll have EIDs 
> for each island of support.
> 
> >>> Comment on Section 5: I don't understand how we distinguish 
> >>> advertising the EIDs vs. larger prefixes. Given the 
> >>> non-aggregability of EIDs, can
> >>
> >> small price to pay (in the 1000s) to be able to suppress more 
> >> specific PA advertisements of PI advertisements from the 10^6 
> >> multi-homed sites we expect to come.
> >
> > business reasons you want to be able to switch between PTR 
> providers. 
> > If this is needed, I don't see how you can aggregate EID space.
> 
> Not just one PTR. A bunch of them will advertise it for 
> compatibility sake. But if I had to choose I would error on 
> using NAT as the solution because I don't want any additional 
> infrastructure if I can avoid it.
> 

PTRs also solve the case where a non lisp site wants to use, say, DNS to
resolve the address of a destination.  In the case of NAT, which address
should the destination site put into DNS?  The NAT'd address, or the
LISP-NR EID?  With a PTR in place, the site just has to place the EID in
DNS and that's it.

Some other solutions have suggested running a separate instance of DNS
to handle this case, and that would work except it adds cost to the
site.  PTRs allow for a site to be accessed without NAT or configuration
burden if they choose to do so.

So we basically have two options here, in once case the LISP site can
use NAT and manage the transition all on their own.  In the other, we
can add a new network element called a PTR that can relieve that burden
on the site, with the downside of potentially adding stretch to incoming
connections.  You can consider PTRs optional, but NAT is a core
requirement for any sensible interworking between LISP and non LISP-NR
sites.

> 
> >>> is added to it. With PTRs, the encapsulation is happening without 
> >>> the knowledge of the legacy endsite. This means that 
> either we must 
> >>> require the legacy endsites (and paths to them) to be 
> able to deal 
> >>> with PMTU discovery or the PTR - LISP site tunneling 
> mechanisms need 
> >>> to be able to carry 1500 byte payload packets. Some discussion of 
> >>> this might be useful in the document.
> >>
> > I did read it earlier, and I liked the MTU handling. However, you 
> > still need to deal with path MTU on the legacy-to-LISP path 
> with PTRs, 
> > and as
> 
> I want to know exactly what you are talking about before I 
> speculate a reply.
> 
> > I explained above, you have to assume one of the following 
> for this to 
> > work:
> >

I would just like to add that I don't think that the a PTR will have any
more MTU issues than an ITR might (or might not) have.

> >> tell us if the "interworking tunnels" should have large diameter 
> >> (PTRs deployed closer to non-LISP sites) or smaller diameter (PTRs 
> >> deployed closer to LISP-sites).
> >
> > works -- maybe we need to resolve the aggregation question first 
> > before we can talk about this. If you can aggregate EID 
> space in the 
> > PTRs, I think this will work.
> 
> Here's the scenario:
> 
> 2) They each advertise an IANA-assigned global IPv6 EID block 
> of 0240::/16.

I think that this is a key point - PTRs are more attractive to me the
more you can aggregate EID space. 

> > from multiple locations. I suspect the properties of this 
> are similar 
> > to anycast.
> 
> People confuse this a lot. Anycast is how you assign 
> addresses to boxes. Advertising the same prefix from multiple 
> spots is multi-path routing.

We've tried to make this clear in the text, I guess it needs to be
clearer. :-/

-Darrel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Mar 2008 16:47:33 +1300

On 2008-03-07 20:14, Darrel Lewis (darlewis) wrote:

...
> You can consider PTRs optional, but NAT is a core

Can you expand on that a bit please? I have a little trouble parsing
"non LISP Non-Routable". And by "NAT" do you mean "LISP-NAT"
specifically?

     Brian

---

From: Robin Whittle <[email-masked]>
Date: Wed, 12 Mar 2008 15:08:59 +1100

Regarding:

  http://tools.ietf.org/html/draft-lewis-lisp-interworking-00

>> requirement for any sensible interworking between LISP and non LISP-NR

I too would appreciate an explanation.

I understand that Proxy Tunnel Routers advertise the prefixes
enclosing one or more (ideally many) EIDs to the DFZ, attracting
packets from networks without ITRs, and then tunnelling those
packets to the correct ETR.  I can't imagine how LISP could be
incrementally deployed without Proxy Tunnel Routers.

The LISP-NAT approach doesn't seem useful to me.  See my 4 point
critique:

  http://psg.com/lists/rrg/2007/msg00674.html

I don't recall any response to that critique.

  - Robin

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 11 Mar 2008 21:14:15 -0700

> requirement for any 
> > sensible interworking between LISP and non LISP-NR sites.
> 
> Can you expand on that a bit please? I have a little trouble 
> parsing "non LISP Non-Routable". And by "NAT" do you mean "LISP-NAT"
> specifically?
> 

Brian,

Sorry about the jargon above.  I was using terms defined in the draft
that aren't very easy to parse.  Also, I think I have a Boolean problem
in the above statement, so let me take it over again from the top.

To be more clear, LISP-NAT and PTR are two ways (they have some nice
synergies, but are independent) for LISP sites whose EIDs are not found
in the DFZ to communicate with non-LISP sites. 

 LISP-NR is a short for LISP-Non Routable, that is a site whose EIDs are
found only in the LISP Mapping database, and _not_ in the Internet DFZ.

 LISP-R is short for  LISP Routable, that is a site whose EIDs are found
both in the LISP Mapping database, and the Internet DFZ. 

LISP-NAT is a form of NAT that allows for LISP-NR addressed hosts to
send packets who's sources get translated to LISP-R addresses.  LISP-NAT
confines the Interworking problem to be site specific, which some sites
may consider a benefit.  It has the classic limitations of NAT,
including the 'global directory' problem:  Which of the two EIDs are in
DNS, the LISP-NR EID, or the LISP-R EID?

PTRs are network elements that advertise (highly) aggregated LISP-NR
space into the DMZ (essentially making it routable).  These devices act
_only_ as ITRs and encapsulate traffic destined to LISP-NR sites.   Note
that return traffic does not back go through the PTR, but is returned
natively (not lisp encapsulated) by the LISP-NR site's xTR to the
originating host.

LISP-NAT can work along side PTRs nicely, I can describe how this works
in more detail if there is interest.  But the trade off in this space is
that PTRs allow for sites not to have to deal with Interworking, at the
cost of connections inbound to the site potentially having stretch.
LISP-NAT allows site independent Interworking, with the (pretty well
understood) limitations of NAT.

Hope this helps explain things more clearly, thanks for your interest.

-D

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 11 Mar 2008 21:35:18 -0700

> I don't recall any response to that critique.

Robin,

I'm sorry that I didn't respond to your critique of LISP-NAT.  It got
tail dropped from the queue until this reminder.   I'm going to paste
your points below and respond to them in order.  My comments are
prefaced with <DL>.

You wrote:
--------------------
Here is a critique of LISP-NAT, based on my potentially faulty
understanding.

1 - LISP-NAT does not solve the problem which "(typically)
    Anycast ITRs in the Core" (Ivip, LISP PTR) does - the
    problem of how a host in a site with no ITR can send a
    packet to a host with a LISP-mapped address (EID) and
    have that packet delivered properly - that is, via an
    ITR which tunnels it to the correct ETR.  This problem exists
    irrespective of whether the ordinary host or the  host with
    the LISP-mapped (EID) address initiates a two-way
    communication.  The Net needs to work for single, isolated,
    packets.

    LISP-NAT only helps in a two-way communication session - and
    then only when the host with the LISP-mapped (EID) address
    initiates this session.
--------------------------------
<DL>
LISP-NAT works when the LISP-NR EID side initiates the connection, true.
However, it works when non-LISP site initiates the connection as well
assuming the DNS address for the host resolves to the LISP-R (the
outside nat) address.  This is a well understood NAT problem.
</DL>
------------------------------------
2 - The LISP-NAT device can only do its work for as many
    concurrently active hosts with LISP-mapped (EID)
    addresses as the device has "publicly routable" IP addresses.

    These "publicly routable" addresses are either ordinary
    addresses, for exclusive use for this LISP-NAT purpose,
    or they are a curious thing - "LISP-R" addresses.

    As I understand it, a "LISP-R" address is a LISP-mapped address
    (an EID - an address such that an ITR handling a packet
    addressed to this address would encapsulate the packet and
    tunnel it to a specific ETR close to the destination host
    which actually has this address) *and* which is also part of
    an advertised BGP prefix and reachable via ordinary BGP
    router forwarding.  This means, I think, that this address
    is not covered by PTRs which advertise the prefix which it
    is within.  This means that there are two ways a packet
    could get to the router which handles this LISP-R address.

       Firstly, it could originate in a site with a LISP ITR, which
       would tunnel the packet to the ETR (presumably the same
       router which is responsible for this address).

       Secondly, if the packet originates in a host in a site with
       no LISP ITR, it arrives by ordinary forwarding through the
       BGP router system.

    As such, the use of LISP-R address space seems to introduce
    complexities and limitations which make it unsuitable for
    robust multihoming, or portability between ISPs.
---------------------------
<DL>
LISP-R addresses are found both in the LISP Mapping system and in the
DFZ.  There are several possible reasons for their existance.  One being
PA addresses assigned by a provider to a site for use as a NAT pool.  A
second example would be an existing site with PI addressing that does
not choose to remove their existing addresses from the DMZ, but wants to
implement LISP (note that this doesn't require the site to use NAT).
</DL>

------------------
3 - Therefore, LISP-NAT provides no multihoming, portability etc.
    benefits, for the packets coming from the host in the site with
    no ITR - while "Anycast ITRs in the Core" (Ivip, LISP PTR)
    provides all these the benefits.

-------------------
<DL>
Sorry but I don't think this aguement has merit based on my explanation
of 1. and 2., above.  I do agree with your second statement that
LISP-PTRs are a viable alternative, however.
</DL>

-----------------------------
4 - It is not clear how long the NAT-ITR should maintain the
    association between the LISP-mapped host's address and the
    LISP-R address in the translation pool.  If there is a pause
    in activity, the communicating hosts reasonably expect to be
    able to send packets to each other in the future.  But unless
    the NAT-ITR has as many LISP-R addresses in its pool as it has
    LISP-mapped host addresses, it will have to recycle the pool
    addresses at some point in time, with the risk that a remote
    host will send a packet to a pool address which has now been
    associated with a different LISP-mapped host than the one
    it was previously communicating with.
-----------------------------
<DL> 
How exactly the LISP-NAT pool is maintained an implementaiton detail
that I think at this point is out of scope of the Interworking draft.
The draft keeps this deliberately simple in order to foster an
implementation that can be used to gain more experience on how this will
work in the real world.
</DL>

Regards,

-Darrel

---

From: Robin Whittle <[email-masked]>
Date: Wed, 12 Mar 2008 17:01:11 +1100

Hi Darrel,

>   http://psg.com/lists/rrg/2007/msg00674.html

1

> LISP-NAT works when the LISP-NR EID side initiates the connection, true.

OK - that is my main critique.

A further critique is that the nature of the communication session
must be recognised by the NAT box in order to associate packets
coming from the outside world. This would often be the case, but if
the application involved a response coming back on a different UDP
or TCP port, or involved some other protocol such as SCTP which the
NAT box wasn't aware of, then it wouldn't work.

> outside nat) address.  This is a well understood NAT problem.

I can't imagine how this would be useful.  The NAT box would need to
know a particular address and perhaps port, and forward packets
received there to a particular host on a LISP-mapped address, with
address translation.  Then the application code at both ends needs
to be able to cope with the translations.

However my main concern is that this approach would involve manual
configuration, fixed uses for addresses, a host having one address
in the global DNS and another on its LISP-mapped actual address etc.
 I can't imagine how this could be useful enough to deploy, when
Proxy Tunnel Routers do everything needed already.

2

> implement LISP (note that this doesn't require the site to use NAT).

Since I can see LISP-NAT only being useful for outgoing sessions
from LISP-R hosts (assuming the protocol is supported by NAT) I
don't see how your statement alters my critique:

For instance, how do you multihome and maintain connectivity when
using PA NAT pool addresses from ISP-A, and that ISP goes down and
you need to use ISP-B instead?  Portability isn't so bad in this
respect, but I think that for NAT to be in any way usable, you would
need something like what (I think) you suggested in your response to
point 1, which I think involves careful configuration of the NAT
system to accept incoming packets on particular addresses and
translate them to particular LISP-R hosts.

Perhaps I don't have a clear enough understanding of what you are
suggesting, but if I do, then the system looks unwieldy and requires
a great deal of careful manual configuration when changing from one
ISP to another - and it can't provide session continuity in a
multihoming service restoration situation.

3

> LISP-PTRs are a viable alternative, however.

I haven't changed my mind about LISP-NAT being only partially useful
- not enough to be deployed.

4 (NAT association time-outs)

> implementation that can be used to gain more experience on how this will

I don't think you need experience in the field to establish that
there is no clear way your NAT system can know when to time-out an
association.  So you have to trade off robustness for existing
sessions with how many sessions you can support on a given sized NAT
pool.

Proxy Tunnel Routers (the same as Ivip's "anycast ITRs in the
core/DFZ") have no such problem.

Since Proxy Tunnel Routers do the trick, I can't imagine what help
it would be to have LISP-NAT, which seems more complex, hard to
configure and prone to failure.

  - Robin

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2008 15:12:25 +1300

Darrel,

Thanks for the clarification... see below.

> understood) limitations of NAT.

I was afraid you'd say that ;-). I think there will be a lot of resistance
to a solution that require v6-v6 NAT; we pretty much know NAT is
inevitable to deal with IPv4 address space, but it would be very
distressing to have non-reversible mappings in the IPv6 address
space. LISP has the nice property of reversing the mapping in
general, and I don't like any solution that loses it.

     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Mar 2008 22:10:37 -0700

> general, and I don't like any solution that loses it.

With IPv6 and a single allocation for the global EID-prefix space, we  
can use PTRs very efficiently by injecting a single route from 100s of  
places.

So we don't have to use NAT for IPv6.

Dino

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Mar 2008 08:09:41 +0200

Dino.

First, I have the same concern with large scaling NATs with v6 as Brian had.

> can use PTRs very efficiently by injecting a single route from 100s of

Yes. But in the meeting you promised to come back to the issue of how
this can be made to work business-wise. The problem that I can see is
that if all PTRs announce the whole (or big chunks of it), they have no
capability to say no to any customer. Anyone's packets can be routed to
the nearest PTR, and once the PTR has a packet, it cannot refuse to
tunnel it to the right place. So from a business point of view this
makes it hard or perhaps impossible to contract with customers for this
service. Presumably the motives for deploying PTRs must then lie
elsewhere, such as in improving your regular customer's service, or some
interaction with the business models of plain old Internet SP business
models.

Have you thought more about this now, and can you say something about it
on the list?

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Mar 2008 23:22:52 -0700

> interaction with the business models of plain old Internet SP business

There are only 2 technical solutions, NATs or PTRs. They can solve the  
problem. If you choose something else that you think makes business  
sense it could not even come close to solving the problem.

Let's first worry about solving the technical problem. Or else we  
don't have to worry about any business models.

> Have you thought more about this now, and can you say something  

It's the same answer I said when I was standing up at RRG. Providers  
will do whatever they can to attract traffic. They typically don't  
want to say no. The more traffic they attract the more peering they  
can get. And the business opportunities start from there.

Dino

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Mar 2008 09:20:05 +0200 (EET)

On Wed, 19 Mar 2008, Dino Farinacci wrote:
> It's the same answer I said when I was standing up at RRG. Providers will do 
> whatever they can to attract traffic. They typically don't want to say no. 
> The more traffic they attract the more peering they can get. And the business 
> opportunities start from there.

I may be missing something as I wasn't at the meeting, and at the risk 
of stating the obvious...

End-site would not want to attract traffic that would result in giving 
transit to other sites (they'll likely have to pay for the traffic for 
their upstream ISP per megabit).

An ISP would be OK attracting traffic from its customers (or 
customers' customers etc.) because they'll pay for it -- depending on 
where in the foodchain the ISP is, they may get a payment in bulk or 
per megabit.

However, if there is some ISP B that provides a free PTR ("a la 6to4 
relay") that peers with ISP A, ISP A has little incentive to deploy a 
PTR of its own (provided that the traffic to ISP B's PTR is not too 
prohibitive) unless it is a tier1/tier2 (ie., has downstream 
multihomed customer ASs that pay per mbit, and you can only attract 
that traffic you advertise the aggregate downstream).

However, an ISP would not want to attract traffic from their peers 
(except if the traffic is targeting their customers) because they 
won't get paid for it and would in essence be giving out free transit.

As a result, I could see especially tier1/2 ISPs deploying PTRs (if 
there is another incentive to do so) but they would not want to 
advertise that to their peers.  But unless all the tier1s do it (or 
someone provides the service for free), some folks in the Internet 
become unreachable.  On the other hand, it's difficult to see the case 
for any end-site deploying PTR.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: <[email-masked]>
Date: Thu, 20 Mar 2008 09:51:02 +0200

Dino wrote
>It's the same answer I said when I was standing up at RRG. 
>Providers will do whatever they can to attract traffic. They 
>typically don't want to say no. The more traffic they attract 
>the more peering they can get. And the business opportunities 
>start from there.
>

Many times the peering ISPs do not want to share their uplink transport
connection with their peers, only their customer and peer links. The
topology and location of the PTR matters. The PTR provider doesn't want
to pay for traffic this not stemming from their customers but elsewhere.
(This is the very same issue that has hampered the deployment of
Internet wide multicast.)

Regards Hannu 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of ext Dino Farinacci
>Sent: Thursday, March 20, 2008 08:23
>To: Jari Arkko
>Cc: Brian E Carpenter; Darrel Lewis (darlewis); rrg; 
>[email-masked]
>Subject: Re: [RRG] Comments on draft-lewis-lisp-interworking
>
>> that if all PTRs announce the whole (or big chunks of it), they have 
>> no capability to say no to any customer. Anyone's packets can be 
>> routed to the nearest PTR, and once the PTR has a packet, it cannot 
>> refuse to tunnel it to the right place. So from a business point of 
>> view this makes it hard or perhaps impossible to contract with 
>> customers for this service. Presumably the motives for 
>deploying PTRs 
>> must then lie elsewhere, such as in improving your regular 
>customer's 
>> service, or some interaction with the business models of plain old 
>> Internet SP business models.
>
>There are only 2 technical solutions, NATs or PTRs. They can 
>solve the problem. If you choose something else that you think 
>makes business sense it could not even come close to solving 
>the problem.
>
>Let's first worry about solving the technical problem. Or else 
>we don't have to worry about any business models.
>
>> Have you thought more about this now, and can you say 
>something about 
>> it on the list?
>
>It's the same answer I said when I was standing up at RRG. 
>Providers will do whatever they can to attract traffic. They 
>typically don't want to say no. The more traffic they attract 
>the more peering they can get. And the business opportunities 
>start from there.
>
>Dino
>
>
>--

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Mar 2008 10:29:16 +0200

Dino,

> don't have to worry about any business models.

I'm sorry but I don't think this is acceptable. Deployability and
incentives have been a key issue from day one in this work. We really
need to have a solution that the relevant players want to deploy. That
is as important as the technical solution. We cannot fail either in the
technical solution or the business incentives of the design. I don't
think we should postpone discussion of the incentives; its an integral
and necessary part of the solution. Just like mapping and encapsulation
are both needed in the technical solution; encapsulation without the
mapping function isn't going to be very useful.

> can get. And the business opportunities start from there.

Ok, this is interesting. Not quite as concrete and clear-cut as I had
hoped, but a start. What do others think of this? Is there a way for us
to evaluate whether this is a sufficient incentive?

Jari

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 Mar 2008 09:54:19 -0400

I would have to disagree with the description below.

Dino Farinacci wrote:
> will do whatever they can to attract traffic. They typically don't want 
> to say no. The more traffic they attract the more peering they can get. 
> And the business opportunities start from there.
> 
> Dino

When geographic addressing (for v6, or even for v4) was proposed, one of 
the big issues, brought forward by the providers, was that it would 
require the provider to accept traffic for any customer in the 
geographic region, and deliver it.  This was unacceptable.  It costs 
money to have infrastructure to handle packets. And no one was / is 
paying for that infrastructure.
This seems to me to be exactly the same issue as for PTRs as proposed.
There may be a way to deploy PTRs that gets them paid for, but I don't 
know what it is.

Ignoring economic issues is a recipe for failure.  If no one can afford 
to deploy the solution if it catches on, then they will avoid doing so. 
  (Yes, anyone can afford PTRs in the early stage.  That's not the 
question.)

And no, operators don't want to attract traffic.  They may want peering 
relationships (not all want them.)  As Peter sarcastically but 
accurately put it at the mike, they want to be paid for traffic, but 
they don't actually want the traffic.

Yours,
Joel

---

From: David Meyer <[email-masked]>
Date: Thu, 20 Mar 2008 07:47:50 -0700

On Thu, Mar 20, 2008 at 09:51:02AM +0200, [email-masked] wrote:
> connection with their peers only their customer 

	Right. If they do, that's called transit (or "paid
	peering" aka "partial transit").

> and peer links. 

	Right. That's called peering (if I understand you; the
	conjunction [and] is a bit hard for me to parse).

	In any event, your point is?

> The topology and location of the PTR matters. The PTR provider doesn't want

	Seems hard, if not impossible, to know/enumerate the
	creative ways in which people will deploy stuff, or for
	what reasons. If nothing else, history has taught us that
	lesson. So while one can try, at this point its all
	conjecture. 

> Internet wide multicast.)

	If I understand you, my experience has been somewhat
	different. 
	
	BTW, I thought business models were explicitly out of
	scope for the IETF (someone please correct me if I am
	mistaken). Apparently the same is not true for the IRTF?

	In any event, I can see analyzing where the costs in
	a given model lie (and how they are distributed by a
	given architecture/deployment), but debating how people
	are going to run their businesses based on some abstract
	understanding of the problem space doesn't seem like it
	is going to yield anything actionable.

	Dave

---

From: David Meyer <[email-masked]>
Date: Thu, 20 Mar 2008 07:52:24 -0700

Jari, 

	I'm pretty sure that we can stipulate that that
	deployability is of critical importance (at least you can
	get that from me). 

	However, as I said (and if its not actually out of
	scope), maybe we should get the biz people in this
	disussion if you want to talk about that angle. Stated
	otherwise, do we have the right group of people engaged
	to take on the business end of this? What I see is a lot
	of speculation, but not much more. 

	Dave

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Mar 2008 17:07:20 +0200

Dave,

> 	of speculation, but not much more. 

That's a good question. I would love to get more operator and business
people involved in this question. Also, I know there are a few
researchers looking at new mechanisms and architectures from a economic
and game theory point of view. Would be good to invite such people as well.

Jari

---

From: David Meyer <[email-masked]>
Date: Thu, 20 Mar 2008 08:11:21 -0700

> paying for that infrastructure.

	Joel, that may have been a small part if it. But the
	larger reality  was that geo/metro would have required a
	central authority and the fear was that such an
	arrangement would subject the settlement free bilateral
	arrangements that have really powered the growth of the
	internet to regulation. That was the main pushback. It
	really had little to do with attacting traffic. Vince
	Fuller can add any level of detatil you like on these
	points. 

	That said, no one wants work they are not being paid for,
	but I can tell you from experience that the more traffic
	an ISP can get from peers, the better (of course transit
	is the best kind of (non-SMS) traffic, because it
	typically has the most favorable margins [given the OSRs
	in the design of most pops I've seen or worked on]).

> There may be a way to deploy PTRs that gets them paid for, but I don't  

	Again, business models in scope?

> (Yes, anyone can afford PTRs in the early stage.  That's not the  

	Uh, the IETF does precisely that, AFAIK. But if you want
	to take that on, do you really feel that this group is
	qualified to talk about ISP business models? As I said in
	a previous email, analyzing and documenting the cost
	distribution imposed by a given architecture is a good
	thing (tm), and would seem appropriate for this
	group. Speculating on what a given ISP might do with its
	particular business model seems at best ill-advised. That
	is especially true given the fact that I would suspect
	that very few of the folks who are involved in this
	thread have ever run a network of any scale, much less
	dealt with the biz people behind those networks.

> relationships (not all want them.)  

	Joel, sorry, but this characterization is, to the best of
	my understanding and experience, just wrong. And ISPs
	only want peering to the extent they can't sell transit
	to downstreams or to the extent that they themselves can
	bypass upstream transit providers (like what you see with
	google and yahoo, or in the developing world these days,
	but this is an old story). 

> As Peter sarcastically but  

	As you point out, Peter was being sarcastic. He wants to
	build the biggerst network on the planet, and that means
	the network that attracts the most traffic. Same was true
	for UUNET back in the day (ask Vijay), or Verio (ask
	Andrew or heas), or Sprint, or ... It was all about
	getting traffic. 

	Dave

---

From: David Meyer <[email-masked]>
Date: Thu, 20 Mar 2008 08:16:53 -0700

> and game theory point of view. Would be good to invite such people as well.

	More brains, more better. That's pretty easy. Less random
	speculation, more better too. 

	As a data point, we just did a really cool workshop on
	the economics of IP address allocation. We had a bunch
	of world class economists, operators (both ISP types and
	MSO types), application providers (google, etc), and
	vendors (I probably missed some class of people). In any
	event, one of the conclusions is that there needs to be
	more cross-pollination; technology people had little or no
	grasp on the economic issues; economic people had only a
	superficial grasp of the technology issues, etc. 

	All that by way of saying it couldn't hurt of we could
	engage some of these types of people in the "economic
	analysis" phase of this, since they understand that angle
	(at least theoretically). They are just notoriously hard
	to engage. Finally, I'll just note that understanding
	economic principles is a different thing than running a
	profitable business. 

	Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 Mar 2008 11:31:47 -0400

I realize that there has to be a limit how far down the economic / 
business analysis we go.
Among other things, we need to start by coming up with ideas, without 
regard to such limits.
But when it comes to deployment analysis, ignoring the question of who 
pays, and why, is just not going to work.  We don't need (don't want, 
and can't) to mandate a business model.  I would hope that a sensible 
recommendation allows for multiple business models.  But if we can not 
even imagine one that works, then it fails.

And with regard to wanting more traffic, operators only want more 
traffic if they are going to get paid for it.  That does suggest a path 
for deployment of PTRs.  If they are deployed by folks at the who are 
paid for transit on a volume basis, and who do not pay for transit, then 
there may be enough incentives to pay for the extra cost of the traffic.
But for most ISPs (who get paid for traffic and pay for traffic), and 
particularly for ISPs who send and receive most traffic over either free 
peerings or pay for transit) it would be difficult.  (Such ISPs could at 
least provide PTRs for their own customers if they wished, once there 
was some reason to do so.)
The basic pain point to avoid is dragging in traffic, which does not 
have money attached, and then having to deliver it a way that doesn't 
have money attached.  Bandwidth and routers are not free.

Yours,
Joel

---

From: David Meyer <[email-masked]>
Date: Thu, 20 Mar 2008 09:05:27 -0700

> even imagine one that works, then it fails.

	Well, I agreed right up until the end. That this group
	can't imagine something doesn't mean it can't exist (I'm
	not advocating ignoring all of this, mind you, but I did
	want to make leave open the possiblity that there might
	be ideas we haven't yet collectively thought of).

> traffic if they are going to get paid for it.

	Core operators don't really get paid for traffic with
	their peers (other than indirectly through their transit
	customers) . That's the point. 

> That does suggest a path for deployment of PTRs.  If they are
> deployed by folks at the who are paid for transit on a volume
> basis, and who do not pay for transit, then   

	Possibly. I'm really not arguing that point.

> was some reason to do so.)

	Sure.

> have money attached.  Bandwidth and routers are not free.

	B/W in a colo might close to free (mod the cost of router
	ports; but those costs are falling quickly as well; the
	"circuits" in these cases are basically just
	cross-connects). 

	Dave

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Mar 2008 09:35:11 -0700

> mapping function isn't going to be very useful.

Then we use NATs. Choose your poison. There is no magic bullet here.

> to evaluate whether this is a sufficient incentive?

The net is dirty and we don't have much options. It's PTRs or NAT,  
pick one.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Thu, 20 Mar 2008 10:45:54 -0700

|> It's the same answer I said when I was standing up at RRG. Providers
|> will do whatever they can to attract traffic. They typically don't
|> want to say no. The more traffic they attract the more peering they
|> can get. And the business opportunities start from there.
|
|Ok, this is interesting. Not quite as concrete and clear-cut as I had
|hoped, but a start. What do others think of this? Is there a way for us
|to evaluate whether this is a sufficient incentive?

I'm not quite convinced.  Service providers are interested in one thing,
being profitable.  Their revenues come from their customers.  Since running
a PTR has clear non-zero costs, the provider should be able to see some
offsetting revenue or strategic advantage.

The theory proposed above seems based on the fact that providers want to
attract traffic.  I infer that the thinking here is that more inbound
traffic would help offset unfavorable traffic balances, which would be
helpful for peering negotiations.  In the case of customer traffic
approaching a PTR, this would seem to be no different, as the traffic would
be arriving at the ISP anyway.  Thus, the benefit would seem to be for
non-customer traffic.  However, for non-customer traffic, the PTR would
encapsulate/decapsulate and hairpin the traffic back outside of the
provider.  In effect, this gives a way for the provider to attract new
traffic, both inbound and outbound, and not receive revenue for it.  While I
can see that it might be of interest to some, I don't see the broad appeal.

Real operators should correct me if I'm off base.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Mar 2008 10:57:45 -0700

> be arriving at the ISP anyway.  Thus, the benefit would seem to be for

Right, you got it.

> encapsulate/decapsulate and hairpin the traffic back outside of the

The PTR just encapsulates. The return traffic uses the RLOCs (from the  
LISP site's point of view) which are routable addresses of the non- 
LISP site.

> can see that it might be of interest to some, I don't see the broad  

I bet an exchange carrier would love to attract traffic.

And why does every service provider want Google, Yahoo, MSN, Facebook,  
EBAY, and MySpace to be their customer?

There is appeal and I wish operators on this list would speak up.

Dino

---

From: [email-masked]
Date: Thu, 20 Mar 2008 14:04:53 EDT

Attracting or not attracting transit traffic:
IMHO the routing architecture should enable packet forwarding such  that some 
ISP network may
choose   a route which utilizes this ISP network a)  maximal   AND b) minimal.
 
Heiner

---

From: "Tony Li" <[email-masked]>
Date: Thu, 20 Mar 2008 11:24:12 -0700

|The PTR just encapsulates. The return traffic uses the RLOCs 
|(from the  
|LISP site's point of view) which are routable addresses of the non- 
|LISP site.

If you do that, then the return traffic can't be encapsulated in any way.
That implies that the source addresses seen by the core are non-routable
EIDs, and you would run into source address filtering issues.

|I bet an exchange carrier would love to attract traffic.

Relative to other exchanges, certainly.  However an exchange would still
have to have a way to deliver the attracted traffic.  How?

|And why does every service provider want Google, Yahoo, MSN, 
|Facebook,  
|EBAY, and MySpace to be their customer?

In the words of peering negotiations, there are content networks and eyeball
networks.  All of the ones that you list above are content networks, where
outbound is much higher than inbound.  Eyeball networks are the reverse,
where inbound is much higher than outbound (ignoring P2P ;-).  Eyeball
networks would like to balance their traffic load, so they want to attract
content.

PTRs are neutral: they attract customer traffic (not new) or non-customer
traffic (hairpinned).  What's the win?

Tony

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 20 Mar 2008 11:33:00 -0700

> something about it on the list?
> 
> Jari
> 
> 

The discussion about this has been good, but I think there are a couple
of points here that I want to clarify.  The gist of this discussion will
also be included in the 01 rev of the draft.  Thanks Jari for spurring
this discussion - your feedback that started all of this.

To summarize:

1) Large providers who are running a default free core will want to
attract traffic from their customers.  This is how they sell upgrades to
their customer links.  

2) Smaller providers who may not have full peering to enable a default
free core and therefore buy transit will want to avoid using that
transit link.  By deploying a PTR they route on RLOCs and if the RLOC is
reachable over a peering link they can avoid paying transit prices for
that traffic.

3) In both cases there is further benefit for deploying PTRs, that is
that post encapsulation you route towards RLOCs, so you can hot-potato
the traffic off your network.  That means that you would probably see
providers installing PTRs in every PoP.

4) There are some other (minor?) benefits along the lines of traffic
analysis and evaluation of traffic, as well as a controlling traffic.

Finally, lets remember exactly what a PTR is, it's an interface on a
router.  It just encapsulates, and many of the existing (and in
development) hardware out there will be able to perform this function.
So the opex cost of deployment is limited to configuration and
announcement of the route, and dedicating an interface(s) (possibly per
PoP) to handle the traffic.

Hope that helps give some more clarity to our ideas.  Feedback, as
always, welcome. 

-Darrel

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 20 Mar 2008 11:50:37 -0700

> 
> When geographic addressing (for v6, or even for v4) was 
> proposed, one of the big issues, brought forward by the 
> providers, was that it would require the provider to accept 
> traffic for any customer in the geographic region, and 
> deliver it.  This was unacceptable. 

Agreed.

?It costs money to have 
> infrastructure to handle packets. And no one was / is paying 
> for that infrastructure.

It is not, because nothing is said about how the provider who creates a
PTR propagates the PTR routes.  Does he de-aggregate internally?  Does
he send the routes to customers, or to peers, or to both?  The provider
can choose this.  This is the crucial difference from geo addressing.

> There may be a way to deploy PTRs that gets them paid for, 
> but I don't know what it is.

I tried to explain the benefits in another email.
> 
> Ignoring economic issues is a recipe for failure.  If no one 
> can afford to deploy the solution if it catches on, then they 
> will avoid doing so. 
> And no, operators don't want to attract traffic.  They may 
> want peering relationships (not all want them.) As Peter 
> sarcastically but accurately put it at the mike, they want to 
> be paid for traffic, but they don't actually want the traffic.
> 

Its been my experience that its hard to sell upgrades to customer links
until you start filling them up.  I well know Peter's point though, it
sure is nice to sell a 10g customer link and have him not use it.
Imagine a customer with links to four providers.  Two of the providers
have PTRs.  Which of the providers are going to see more traffic and
therefore sell upgrades?

-Darrel

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Mar 2008 17:09:07 -0700

> If you do that, then the return traffic can't be encapsulated in any  

The return traffic isn't encapsulated. The LISP site returns traffic  
to the non-LISP site without use of the PTR. The LISP site knows the  
destination is a non-LISP site because it's addresses are not in the  
mapping database.

> EIDs, and you would run into source address filtering issues.

What are source address filtering issues. ACLs? uRPF? Say more.

> have to have a way to deliver the attracted traffic.  How?

It deploys PTRs. That's how we started this conversation.

> networks would like to balance their traffic load, so they want to  

And if they deploy LISP they can. That is the appeal of deploying LISP  
at the site.

> traffic (hairpinned).  What's the win?

You associated customer traffic with non-LISP traffic. There is  
customer traffic that can be LISP sites.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Thu, 20 Mar 2008 18:43:12 -0700

|> That implies that the source addresses seen by the core are non- 
|> routable
|> EIDs, and you would run into source address filtering issues.
|
|What are source address filtering issues. ACLs? uRPF? Say more.

uRPF is one example of an implementation of this type of sanity checking.
You can also do it via ACLs.  The concept is the same either way.

If you generalize things, I think that you want to position the PTR
functionality so that the PTR is nothing more than a giant ITR/ETR that LISP
sites would use by 'default'.  Conceptually you've worked out how to get one
LISP site to talk to another.  PTRs are one way of simply turning the entire
rest of the Internet into a single giant LISP site.

|> Relative to other exchanges, certainly.  However an exchange would  
|> still
|> have to have a way to deliver the attracted traffic.  How?
|
|It deploys PTRs. That's how we started this conversation.

Sorry, I was unclear.  The exchange site still would have to deliver the
traffic via some transit provider.  While the exchange might want more
traffic (relative to other exchanges), I'm not seeing the benefits to the
transit providers.  Again, hairpinning traffic doesn't seem like a win to
anyone.

|> Eyeball
|> networks would like to balance their traffic load, so they want to  
|> attract
|> content.
|
|And if they deploy LISP they can. That is the appeal of 
|deploying LISP  
|at the site.
|
|> PTRs are neutral: they attract customer traffic (not new) or non- 
|> customer
|> traffic (hairpinned).  What's the win?
|
|You associated customer traffic with non-LISP traffic. There is  
|customer traffic that can be LISP sites.

Irrelevant to the ISP.  The customer traffic is coming to the ISP
regardless.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Fri, 21 Mar 2008 14:15:45 +1100

Short version:     Agreeing with Joel and requesting the LISP team
                   write a unified account of LISP Proxy Tunnel
                   Routers, with detailed examples.

Hi Joel,

> even imagine one that works, then it fails.

I entirely agree.

In the early brainstorming phases of development - as I regard the
RRG process at present - I think we need to explore all sorts of
wild ideas, without much regard to business models.

Maybe there is some combination of unlikely-sounding technical ideas
which have an unexpected synergy and solve a bunch of other
problems, leading to practical solutions which are novel, valuable
and practical - with possible business models.

When we are approaching the point where we start to take a technical
solution seriously - when we make it part of the basic architecture
and start working on other aspects of the system to build on it - we
need to have some tentative business models, or at least flag one
that has no viable model as badly in need of one.

I am about to post a message on Ivip's "Open ITRs in the DFZ" - the
ITRs previously known as "Anycast ITRs in the core/DFZ".  In that, I
discuss some important elaborations on the original concept, and
some business models for why these would be deployed.

It would be great if the LISP team did a comprehensive round-up of
everything they know about Proxy Tunnel Routers, and could post that
to the list with some examples to make it easy for other folks to
envisage how PTRs would work.  For instance:  Where are the PTRs?
Where are the various ETRs are for whatever EIDs prefixes each PTR
advertises.  Who runs these ETRs and who runs the PTR?  How each BGP
prefix a PTR advertises is comprised of one or more LISP EID
prefixes etc. and who are the end-users for these?  Also, which ISPs
have the one or more ETRs for each such EID prefix.

 - Robin         http://www.firstpr.com.au/ip/ivip/

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Mar 2008 23:48:29 -0700

> You can also do it via ACLs.  The concept is the same either way.

Okay and what was your point?

> sites would use by 'default'.  Conceptually you've worked out how to  

In practice we have LISP sites talking to other LISP sites.

> rest of the Internet into a single giant LISP site.

LISP sites are not the ones that use PTRs, the non-LISP sites do.

> transit providers.  Again, hairpinning traffic doesn't seem like a  

We can't be all things to all people. But there is a benefit to  
transition to LISP so the providers can reduce their routing tables at  
the same time as maintaining non-LISP site to LISP site connectivity.

> Irrelevant to the ISP.  The customer traffic is coming to the ISP

Don't follow. Or, what is your point?

Dino

---

From: "Tony Li" <[email-masked]>
Date: Sat, 22 Mar 2008 00:19:08 -0700

|> uRPF is one example of an implementation of this type of sanity  
|> checking.
|> You can also do it via ACLs.  The concept is the same either way.
|
|Okay and what was your point?

Simply this: if return packets leaving a LISP site, headed for a non-LISP
site, use a EID as the source address, then it is highly likely that the
packets will be dropped due to the source address filtering.

It would seem like you would want to encapsulate the outbound packet at
least as far as the PTR to protect against this.

|We can't be all things to all people. But there is a benefit to  
|transition to LISP so the providers can reduce their routing 
|tables at  
|the same time as maintaining non-LISP site to LISP site connectivity.

So you admit then that your argument about the benefits of hosting a PTR
don't hold water?

Tony

---

From: "ext Dino Farinacci" <[email-masked]>
Date: Fri, 21 Mar 2008 23:48:29 -0700

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 22 Mar 2008 08:08:04 -0700

> packets will be dropped due to the source address filtering.

That problem exists today with a source address from a PI block. So if  
you want to deliver such packets, you don't do that today.

> So you admit then that your argument about the benefits of hosting a  

1) We need solutions to a technical problem. We understand the problem  
and solution space.
2) We don't know the business benefits yet of deploying PTRs.
3) There are business benefits for deploying LISP.
4) You need to have interworking between upgraded sites and non- 
upgraded sites.

We can't be sure of anything at this point. Therefore, we can't be  
sure it won't hold water.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Sat, 22 Mar 2008 10:22:56 -0700

|> Simply this: if return packets leaving a LISP site, headed 
|for a non- 
|> LISP
|> site, use a EID as the source address, then it is highly 
|likely that  
|> the
|> packets will be dropped due to the source address filtering.
|
|That problem exists today with a source address from a PI 
|block. So if  
|you want to deliver such packets, you don't do that today.

Correct, however, today the provider typically will have some involvement in
distributing the PI advertisement.  This approach implies that the provider
now must be party to all EID allocations for the site and must make manual
configurations to allow new allocations.  We all know how well that has
worked.

Further, this isn't going to be effective if the provider is using uRPF
unless the provider inserts a static route.  ;-(

|We can't be sure of anything at this point. Therefore, we can't be  
|sure it won't hold water.

And you can't be sure that it will... 

Tony

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 24 Mar 2008 07:27:30 -0700

> Simply this: if return packets leaving a LISP site, headed 
> for a non-LISP site, use a EID as the source address, then it 
> is highly likely that the packets will be dropped due to the 
> source address filtering.

It would pass a lose-mode check since the route is in the table, which
is the current best practice for multi-homed networks.

> 
> It would seem like you would want to encapsulate the outbound 
> packet at least as far as the PTR to protect against this.
> 
> 
> tables at 
> So you admit then that your argument about the benefits of 
> hosting a PTR don't hold water?

Sorry, I don't admit this at all.

-Darrel

---

From: "Tony Li" <[email-masked]>
Date: Mon, 24 Mar 2008 09:53:00 -0700

Hi Darrel, 

|> Simply this: if return packets leaving a LISP site, headed 
|> for a non-LISP site, use a EID as the source address, then it 
|> is highly likely that the packets will be dropped due to the 
|> source address filtering.
|
|It would pass a lose-mode check since the route is in the table, which
|is the current best practice for multi-homed networks.

Ok, but as you're transitioning to LISP, you want to remove routes to EID
prefixes from the routing table.  That breaks loose or strict mode.

|> So you admit then that your argument about the benefits of 
|> hosting a PTR don't hold water?
|
|Sorry, I don't admit this at all.

Ok cool, so assuming you've been following the conversation, is there a flaw
in my argument?

Tony

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 24 Mar 2008 15:31:56 -0500

Thus spake "Joel M. Halpern" <[email-masked]>
> pays, and why, is just not going to work.  We don't need (don't want, and 
> can't) to mandate a business model.  I would hope that a sensible 

Okay, here's one I can imagine, even if it might not be politically 
feasible:

The RIRs pay the Tier 1s to all run PTRs, using fees charged to people who 
get EID space from them*.  More people using LISP, more traffic, more fees, 
more PTRs...

And another one:

The Tier 1s decide that the cost of deploying PTRs is less than the cost of 
upgrading routers to handle the routing table growth that will happen if 
LISP doesn't get deployed widely.

So, that's two business models that I can _imagine_, even if I'm not sure 
they'd necessarily work in practice.  I'd expect there are other models that 
I haven't thought of yet and that someone will find a way to make money, 
somehow.

> The basic pain point to avoid is dragging in traffic, which does not have 
> money attached, and then having to deliver it a way that doesn't have 
> money attached.  Bandwidth and routers are not free.

It's not that simple.  It's a very strange world out there...

I once knew a colo shop that ran an IRC server specifically because the 
traffic from the near-constant DDoS attacks (which IRC servers naturally 
attract).  The nature of the content biz is that they naturally send far 
more than they receive; _any_ inbound traffic they can attract is good 
because it helps balance their peering ratios, which makes other networks 
more willing to peer with them, which in turn saves them money on transit.

S

(* I assume the RIRs would distribute EIDs.  That also means there would 
likely be five different EID prefixes and five databases, but that's not a 
meaningful change to the technical model.)

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 24 Mar 2008 15:38:30 -0500

Thus spake "Tony Li" <[email-masked]>
> prefixes from the routing table.  That breaks loose or strict mode.

Presumably, the EID _aggregate_ would be in the routing table, so loose mode 
would succeed.  However, the route would be pointing in the "wrong" 
direction, so strict mode would fail.  Putting a static route (not 
redistributed) for the customer's EID on their interface would make both 
succeed.

S

---

From: "William Herrin" <[email-masked]>
Date: Mon, 24 Mar 2008 17:19:26 -0400

On Mon, Mar 24, 2008 at 4:31 PM, Stephen Sprunk <[email-masked]> wrote:
>  more PTRs.

The RIRs would likely use the NRO as their vehicle so that there's one
central authority. But even if it was possible to get past the
appearance of a money-grab by the megacorps, sorting out the payment
dynamics would be a public policy nightmare of the first order.

>  LISP doesn't get deployed widely.

That rather goes against human nature.

>  more willing to peer with them, which in turn saves them money on transit.

As crazy as it sounds, this is probably the most realistic scenario
I've heard for deploying a LISP PTR: a small edge organization deploys
it to adjust some completely unrelated traffic factor. Perhaps they
even use it to justify peering in the first place: we know we'd
normally come in shy of your qualifications Mr. Tier1 but if you add
us as a peer at your convenient data center, we'll take care of this
whole LISP PTR thing for you.

Its a hell of a thing to hang a critical-path item on.

Regards,
Bill Herrin

-- 
William D. Herrin                  [email-masked] [email-masked]
Web: <http://bill.herrin.us/>

---

From: "Tony Li" <[email-masked]>
Date: Mon, 24 Mar 2008 15:01:37 -0700

|Presumably, the EID _aggregate_ would be in the routing table, 
|so loose mode 
|would succeed.  However, the route would be pointing in the "wrong" 
|direction, so strict mode would fail.  Putting a static route (not 
|redistributed) for the customer's EID on their interface would 
|make both 
|succeed.

Agreed.  The static route seems like a serious maintenance issue, IMHO.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Mar 2008 13:04:31 +1300

> configurations to allow new allocations.  We all know how well that has

Maybe I'm naive, but I'd been assuming that EIDs would in practice be
identically equal to addresses allocated under a registry-allocated
PI prefix.  So the provider can know about the prefix just like today,
even if there's no advertisement. I don't see why that would change
fundamentally, even if the proposed LISP-ALT EID prefix space is used.

   Brian

---

From: "William Herrin" <[email-masked]>
Date: Mon, 24 Mar 2008 20:35:34 -0400

>  fundamentally, even if the proposed LISP-ALT EID prefix space is used.

Hi Brian,

We don't want to trade consumption in the routing table for
consumption in the source filter; they both consume the FIB. If your
transit provider is filtering your source addresses like he's supposed
to, he'll have to carry a filter for every distinct block of EIDs
downstream. In practice this means that he'll find it too much trouble
to carry any source filters and we'll have a fresh problem with
spoofed source addresses. The problem isn't especially tractable with
BGP but it looks worse under map-enacap.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr ....................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: "Tony Li" <[email-masked]>
Date: Mon, 24 Mar 2008 17:42:34 -0700

|Maybe I'm naive, but I'd been assuming that EIDs would in practice be
|identically equal to addresses allocated under a registry-allocated
|PI prefix.  So the provider can know about the prefix just like today,
|even if there's no advertisement. I don't see why that would change
|fundamentally, even if the proposed LISP-ALT EID prefix space is used.

It's unfortunate that it wouldn't change, because the provider would need to
know about both the PA allocation and the EID assignment.  Effectively, it's
double the hassle factor.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Mar 2008 14:35:45 +1300

> double the hassle factor.

Er, right, which I guess is why Plan A for IPv6 has always been
pure PA, and use multiple prefixes on a site that has multiple
ISPs. But the premise in RRG is that this won't fly, and hence we get
this hassle. If Bill is right about source filtering being sacrificed
as a result, there seems to be a biggish fly in the ointment.

    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2008 18:38:35 -0700

> |fundamentally, even if the proposed LISP-ALT EID prefix space is  

Agree.

> double the hassle factor.

The provider doesn't have to know about EID-prefixes. It can filter  
and uRPF on the locator address that is part of it's own block.

Dino

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 24 Mar 2008 21:02:00 -0500

Thus spake "Dino Farinacci" <[email-masked]>
>> It's unfortunate that it wouldn't change, because the provider would need 
>> to know about both the PA allocation and the EID assignment.
>> Effectively, it's double the hassle factor.
>
> The provider doesn't have to know about EID-prefixes. It can filter  and 
> uRPF on the locator address that is part of it's own block.

Packets coming out of a LISP site will have a source address in the EID
prefix if they're headed to a non-LISP site or depending on a PTR or
ISP-provided ITR to reach other LISP sites; all of those cases give you uRPF
or filtering problems.  Packets will only have a source address in the RLOC
prefix if they've been encapsulated by a customer ITR for transmission to
another LISP site -- and we must assume that will be rare, at least
initially.

Tony is correct; the ISP now has to maintain routes (for uRPF) or filters
for two prefixes per customer instead of one.  OTOH, that is a cost paid in
one place, while the benefit of LISP accrues to every BGP router with a full
table.  That seems like a reasonable trade-off...

S

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2008 19:24:36 -0700

>>> It's unfortunate that it wouldn't change, because the provider  
>>> would need to know about both the PA allocation and the EID  
>>> assignment.
>> The provider doesn't have to know about EID-prefixes. It can  
>> filter  and uRPF on the locator address that is part of it's own  
>> block.
>

Well that depends:

1) If the source address is indeed an EID, and you want your packets  
to return from a non-LISP site, then they are routable and hence can  
be filtered or uRPF'ed against.

2) If the source address is out of EID space, but the ITR is doing  
LISP-NAT, then again you have a routable address you can filter and  
uRPF against.

> another LISP site -- and we must assume that will be rare, at least

Or translated into an RLOC.

> table.  That seems like a reasonable trade-off...

No, I disagree. It has to keep a single set of filters, and that is  
based on the source address leaving the site. That can be the 1)  
source host's address, 2) the ITR's RLOC addres, or 3) a translated  
address. In all cases, they are out of the attached provider block.

There is no choice here, we have to do this. And if we don't accept  
it, nothing will come close to getting deployed. So we have to try to  
make it work as simplest as we can.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Mon, 24 Mar 2008 19:48:08 -0700

Brian,

|Er, right, which I guess is why Plan A for IPv6 has always been
|pure PA, and use multiple prefixes on a site that has multiple
|ISPs. 

That plan went south awhile ago, when the RIR's decided to hand out PI
instead.  Oops.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Mon, 24 Mar 2008 19:53:18 -0700

Hi Dino,

|No, I disagree. It has to keep a single set of filters, and that is  
|based on the source address leaving the site. That can be the 1)  
|source host's address, 2) the ITR's RLOC addres, or 3) a translated  
|address. In all cases, they are out of the attached provider block.

That would seem to be inconsistent.  As you've previously said, when
operating with a PTR, the source address coming out of the LISP site would
be a pure EID.  That is necessarily not part of the provider block.

|There is no choice here, we have to do this. And if we don't accept  
|it, nothing will come close to getting deployed. So we have to try to  
|make it work as simplest as we can.

No, this is also not true.  There is a clear alternative: tunnel from the
ITR back out to the PTR.  

FWIW, I don't like that either, but we should consider the alternatives.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2008 20:02:03 -0700

> be a pure EID.  That is necessarily not part of the provider block.

I am saying there are multiple ways to go. You could have a LISP site  
that does NAT even when there are PTRs deployed. But the point is the  
"routability" of the prefix. It doesn't matter if it's PA or PI.  
Today, there are PI addresses and PA addresses which are filtered.

But when the LISP site sources packets, it's one type of address, that  
is the source address of the packet that is put on the CE-PE link. So  
when a LISP site talks to another LISP site, that source address is an  
RLOC from the ISPs block. When that same LISP site is sending to a non- 
LISP site, the ITR can translate it's source address to the same RLOC  
as in the LISP-to-LISP case.

Therefore, the ISP doesn't have to deal with 2-sets of addresses for  
filtering or whatever.

> No, this is also not true.  There is a clear alternative: tunnel  

Well that is a micro fix to the basic interworking architecture. I  
thought many were questioning all of draft-lewis-lisp- 
interworking-00.txt. Which my response was to that.

> FWIW, I don't like that either, but we should consider the  

Well, I'll ask you the same thing I ask Yakov, give me an alternative  
that has a lower cost of deployment.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Mon, 24 Mar 2008 20:32:27 -0700

Hi again Dino,

|I am saying there are multiple ways to go. You could have a LISP site  
|that does NAT even when there are PTRs deployed. 
|
|But when the LISP site sources packets, it's one type of 
|address, that  
|is the source address of the packet that is put on the CE-PE link. So  
|when a LISP site talks to another LISP site, that source 
|address is an  
|RLOC from the ISPs block. When that same LISP site is sending 
|to a non- 
|LISP site, the ITR can translate it's source address to the same RLOC  
|as in the LISP-to-LISP case.

Ok, I'm fine with that.  You're effectively shifting to a NAT approach for
transition.  If you do that, do you even need PTRs anymore?

|Well, I'll ask you the same thing I ask Yakov, give me an alternative  
|that has a lower cost of deployment.

I'm not out to optimize for the lower cost of deployment.  That's a price
that we pay once.  I'm much more concerned with having the right end-goal.
A cheap deployment of a lousy end-goal isn't worth it in the first place.

Tony

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 24 Mar 2008 22:38:56 -0500

>>>> It's unfortunate that it wouldn't change, because the provider  would 
>>>> need to know about both the PA allocation and the EID  assignment.
> 1) If the source address is indeed an EID, and you want your packets  to 
> return from a non-LISP site, then they are routable and hence can  be 
> filtered or uRPF'ed against.

If you assume the existence of PTRs, your EIDs do not need to be "routable" 
in the normal sense.  There will be a route for them, yes, but it'll be an 
aggregate pointing at a PTR, not the customer.  Strict uRPF would fail 
without a static route.

> LISP-NAT, then again you have a routable address you can filter and  uRPF 
> against.

I'm still trying to wrap my brain around LISP-NAT.

>> Tony is correct; the ISP now has to maintain routes (for uRPF) or 
>> filters for two prefixes per customer instead of one.  OTOH, that is
>> a cost paid in one place, while the benefit of LISP accrues to
>> every BGP router with a full table.  That seems like a reasonable
>> trade-off...
>
> No, I disagree. It has to keep a single set of filters, and that is  based 
> on the source address leaving the site. That can be the 1)  source host's 
> address, 2) the ITR's RLOC addres, or 3) a translated  address. In all 
> cases, they are out of the attached provider block.

In at least some of the proposals we're discussing, packet may leave the 
site with either an EID (PI) or RLOC (PA) as the source address.  That means 
the filter for the customer must include both.

> There is no choice here, we have to do this. And if we don't accept  it, 
> nothing will come close to getting deployed. So we have to try to  make it 
> work as simplest as we can.

I did say I thought it was a reasonable trade-off.  I just wanted to point 
out we're shifting/reducing some costs, not eliminating them.  I actually 
_like_ moving the costs closer to the customer who gets the benefit.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 24 Mar 2008 22:30:09 -0500

> That plan went south awhile ago, when the RIR's decided to hand out PI

That plan was dead the day it was conceived; few in the IETF realized it at 
the time because they never bothered to ask end-site operators what they 
thought, but if they had it would have been clear how unacceptable it was.

It became slightly more obvious when dozens of end-user networks started 
applying for /32s by pretending to be LIRs because there was no other 
acceptable option.  If even the highly-skilled early adopters (like, say, a 
certain router vendor) refused the multi-PA model, it should have been clear 
there's no way it was going to fly with the mass market.

ARIN simply decided to end the charade as well as make things a bit more 
manageable in the future.  For instance, the PI prefixes are intentionally 
longer and out of different blocks so that they can be easily filtered by 
ISPs.  Those assignments might eventually morph into EID blocks if this work 
succeeds.  That wasn't an accident on the part of those of us supporting PI 
space; we didn't know what (or even if) magic would save the DFZ, but we at 
least planned for it in case it arrived...

S

---

From: Mark Prior <[email-masked]>
Date: Tue, 25 Mar 2008 14:24:07 +1030

> That plan went south awhile ago, when the RIR's decided to hand out PI

Hardly an oops if there was no way for the end site to make it work 
operationally.

Mark.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2008 21:39:32 -0700

>>> Packets coming out of a LISP site will have a source address in  
>>> the  EID prefix if they're headed to a non-LISP site or depending  
>>> on a
>>> PTR or
>>
>> Well that depends:
>>
>> 1) If the source address is indeed an EID, and you want your  
>> packets  to return from a non-LISP site, then they are routable and  
>> hence can  be filtered or uRPF'ed against.
>
> If you assume the existence of PTRs, your EIDs do not need to be  
> "routable" in the normal sense.  There will be a route for them,  
> yes, but it'll be an aggregate pointing at a PTR, not the customer.   
> Strict uRPF would fail without a static route.

You are right Steve, but since legacy sites and routers can route to  
the "EID", that was my definition of routable. You are defining it to  
be routable from the the LISP site, which you are right, they are not.

>> LISP-NAT, then again you have a routable address you can filter  
>> and  uRPF against.
>

It is really simple:

1) When ITR determines destination site is not in the mapping  
database, it will not encapsulate and will translate the source  
address for egress packets.
2) An ETR will translate the destination address for ingress packets  
when they are not encapsulated.

That's it!

>> No, I disagree. It has to keep a single set of filters, and that  
>> is  based on the source address leaving the site. That can be the  
>> 1)  source host's address, 2) the ITR's RLOC addres, or 3) a  
>> translated  address. In all cases, they are out of the attached  
>> provider block.
>
> In at least some of the proposals we're discussing, packet may leave  
> the site with either an EID (PI) or RLOC (PA) as the source  
> address.  That means the filter for the customer must include both.

Right, just want to say we have some flexibility if the sensitivity is  
for ISP filtering.

>> There is no choice here, we have to do this. And if we don't  
>> accept  it, nothing will come close to getting deployed. So we have  
>> to try to  make it work as simplest as we can.
>
> I did say I thought it was a reasonable trade-off.  I just wanted to  
> point out we're shifting/reducing some costs, not eliminating them.   
> I actually _like_ moving the costs closer to the customer who gets  
> the benefit.

Right, that is indeed what we are doing.

Dino

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Mar 2008 11:03:16 +0200 (EET)

> is the current best practice for multi-homed networks.

This may depend on the ISP and the size of multi-homed network.

In general, I disagree with this categorical statement.  Strict uRPF 
works just fine with multihomed customers.  Even when the traffic is 
asymmetric.  See BCP84 and draft-savola-bcp84-urpf-experiences-03.txt 
for more.

Loose RPF towards a customer is not very useful.

A site originating traffic from its non-routable source addresses is 
akin to Mobile IP designs.  Initially they thought it was OK to use 
the home address to source packets from anywhere but in the end they 
needed to deploy reverse tunneling.  Here, instead of a mobile IP host 
we have an endsite which may or may not use BGP or some other protocol 
to advertise some other part of its address space.

---

From: Randall Atkinson <[email-masked]>
Date: Tue, 25 Mar 2008 03:45:32 -0700

Earlier, Brian Carpenter wrote:
% Er, right, which I guess is why Plan A for IPv6 has always been
% pure PA, and use multiple prefixes on a site that has multiple
% ISPs. But the premise in RRG is that this won't fly, and hence we get
% this hassle. If Bill is right about source filtering being sacrificed
% as a result, there seems to be a biggish fly in the ointment.

It is possible there is an opportunity for the "IPv6 Advocate"
community to do some actual technical training and educational
work on how that "Plan A" above would work.

At present, there is a lot of user demand on the RIRs for PI space.
If that is simply a matter of users not understanding how to make
the "Plan A" work, then training/education might change things.

For what its worth, the perception is that IPv6 renumbering (e.g. if
an upstream provider link fails for a multi-homed site using PA space)
is too hard -- and existing TCP/UDP sessions fail if the PA address
being used belongs to a PA whose link to the multi-homed site fails.

Quite separately, TCP sessions bind to the whole IPv6 address,
not just to an identifier.  So when one upstream link fails, the two
nodes can still reach each other via an address in the other upstream
provider's PA block -- HOWEVER the TCP session will fail after timeout
seconds.

SCTP doesn't have this issue, but TCP/UDP definitely do today,
which is why splitting the IPv6 address into distinct Locator and
Identifier components would be helpful.

(At this point, I will refer to the ILNP draft for one possible way to do that;
HIP is a different way to do that with different tradeoffs; one can implement
something very like HIP using ILNP, but one cannot easily implement the
general ILNP approach in HIP as near as I can tell).

Yours,

Ran
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2008 11:25:18 +1300

On 2008-03-25 16:30, Stephen Sprunk wrote:
> That plan was dead the day it was conceived; few in the IETF realized it
> at the time because they never bothered to ask end-site operators what
> they thought, but if they had it would have been clear how unacceptable
> it was.

Well, I believe I was still an end-site operator at the time
(1995/96), and I didn't see then and don't see now what the *big*
problem is. There are certainly operational implications, but so
there are in the PI model, and if we don't solve those here, I think
you will discover that Plan A isn't actually dead at all. However,
let's not waste RRG time on this. (Therefore, I won't respond to
Ran Atkinson's very apposite message here.)

    Brian