Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers

From: [email-masked] (Noel Chiappa)
Date: Sat, 19 Sep 2009 13:18:20 -0400 (EDT)

> From: Robin Whittle <[email-masked]>

    > AFAIK, you haven't specified the commercial relationship between the
    > operator of the LISP node and the operator of the PETR which it uses.

Right, but obvious commercial arrangements are outside the IETF scope. If
your point was that you can't see that there will be any economically
workable arrangement, that I think would be something that should concern us.
As to that, I have no idea...

    > Do you plan to have provision for two or more PETRs, for redundancy?

You mean, 'would each non-LISP destination site be served by two or more
PETRs'? Or did you mean 'would each LISP source site be served by two or more
PETRs'?

Because I think the original post said something about wanting PETRs
scattered around the system, to minimize extra hops. If a PETR is close to
either the source, or the destination, it will minimize the path length.
Which model you pick probably depends on the economic relationship; i.e.
whether a PETR is associated with a source, or a destination. For the former,
you'd want it close to the source so it can serve multiple destinations
without increased path length, and vice versa for the other relationship.

Anyway, getting back to your original point, the system should _allow_
either, but I'm not sure it should _mandate_ anything.

    > I understand that the concept of a PETR is quite separate from that of
    > the one or more ETRs a LISP node may be using. For LISP nodes which
    > need a PETR, does the LISP node perform its own ETR function?

The terminology may be a little confusing. PETRs serve non-LISP destinations,
i.e. they only handle traffic flowing from a LISP site, to a non-LISP site.
The ETR of a LISP site would, instead, be associated with traffic coming to
the LISP site. How the ETR service for the LISP node is handled is not
something this proposal needs to cover.

    > In the PETR model, I understand the LISP node simply encapsulates
    > packets to send to the PETR

The 'LISP node' might be either i) a LISP site, in which unmodified hosts are
sending packet to an ITR which is doing the LISP encapsulation, or ii) some
other source of LISP-encapsulated packets. Again, the detail there, of where
the LISP-encapsulated packets are coming from, is not something this proposal
needs to cover.

    > The PETR only receives packets from LISP nodes which are addressed to
    > non-LISP addresses.

Right.

    > So there is no need for the PETR to contain or be close to an ITR.

That would likely depend on the economic model/relationship between the PETR,
the non-LISP hosts being served, and the source of the LISP-encapsulated
traffic - see the comment above about PETR placement.

    > Can you list the sorts of scenarios in which the LISP node would be
    > using a PETR?

I'm not sure an exhaustive list is possible. It's just a pretty basic,
generic building block, and those kind of things tend to get used in many
ways that were not forseen. As to a list of possible/plausible ones, Darrel's
original message gave two, perhaps others can come up with more?

    > Must the LISP node be on a global unicast address, or can it be behind
    > one or more layers of NAT?

Again, the term "LISP node" confuses me a little - are you talking of
the original source of the packets, or the ITR, or what?

The ITR will have to have a global unicast address, but that does not prevent
it being behind a NAT - it just has to figure out what the _NAT_'s global
unicast address is, and register that as the RLOC associated with the EIDs
which which that ITR is responsible.

    > Do you expect the LISP node to be connected to the Net via a slow,
    > expensive and unreliable last mile link such as a wireless mobile
    > network? 

I don't think we're making any assumptions about the kind of link it will
have. Like I said, it's a pretty generic building block, and will likely be
used in many different ways.

    > How do you plan to cope with PMTUD and packet loss problems between the
    > LISP node and the PETR?

The same way we would between the ITR and any other ETR, I would assume.

    > How does the LISP node ensure that the PETR is still alive?

That's an interesting point. Some of the techniques used to detect
reachability/liveness of the ETR won't necessarily work with PETRs. E.g.
unless a PETR is co-located in the same box as a PITR, there won't be any
reverse user-data traffic to piggyback nonces on.

However, reachability/liveness testing does fall back to explicit probing,
when none of the other mechanisms are giving a positive signal, so there will
be a backstop. And some of the other ones might work (e.g. PITR/PETR
colocation), there's no way to know about a particular configuration until
it's examined.

	Noel

---

From: Robin Whittle <[email-masked]>
Date: Sun, 20 Sep 2009 14:06:20 +1000

Short version:    What are the business models for PETRs?

                  When would PETRs be used?  Darrel's text mentions
                  "LISP-NR" sites, but these are sites with EID
                  addresses not covered by a PTR advertisement.  I
                  can't imagine why any end-user site would want
                  to be a LISP-NR site, since this means that their
                  hosts would unreachable from all non-LISP networks.

                  PETRs have nothing much in common with ETRs.  How
                  can the ITR, or whatever it is which sends packets
                  to the PETR, make sure the PETR is alive, getting
                  most or all its packets and is able to handle them?

Hi Noel,

> As to that, I have no idea...

I understand that specific business arrangements are not a matter for
the IETF, but in developing a scalable routing proposal, we
definitely need to plan the types of business relationships which we
anticipate will develop to support the technical arrangements we are
devising.

I am not saying there isn't a viable business model for PETRs.  I am
just saying that I don't know what the business model is for PETRs
and that I think that at least one seemingly viable model should be
proposed before the whole PETR concept is accepted.

> PETRs'? Or did you mean 'would each LISP source site be served by two or more

The latter, since any PETR can send packets to all non-LISP sites.

> either the source, or the destination, it will minimize the path length.

Darrel wrote:

    In order to minimize stretch on communications between LISP
    and non-LISP sites, its very likely that they should be located
    in separate places in the topology.

but there is no reference to the location of PETRs in the text he
proposed for discussion.

Since the typical situation is for a given source to be sending
packets to destinations all around the Net, the only way to minimise
stretch (longer total packet paths than would be required without the
PETR) is to locate the PETR close to the source.

So my question was whether a given LISP site using PETRs would have
two or more of them.  Implicitly, it would be best if they were close
to the site.

This raises questions about business models.  Since the purpose of
LISP or any other core-edge separation solution to the routing
scaling problem is to allow each end-user network to keep its address
range and use any ISP in the world, if the PETR is outside its
current ISP and needs to be "close", then we need to think about
business arrangements by which the site chooses one or more PETRs.

Part of this involves the possibility of two or more PETRs, both
ideally nearby (but not absolutely necessarily nearby) which are
operated by different companies and therefore are likely to be
different networks - to provide some network-level and business-level
redundancy.  The network-level redundancy is obvious.  The
business-level redundancy is to do with what happens if there is an
administrative glitch, or the operator of the PETR decides the site
hasn't paid its bill.

The business arrangements for the TTR model are discussed in:

  http://www.firstpr.com.au/ip/ivip/#mobile
  TTR Mobility Extensions for Core-Edge Separation Solutions to the
  Internet's Routing Scaling Problem
  Robin Whittle, Steven Russert 2008-08-25

> without increased path length, and vice versa for the other relationship.

Yes - I can't see any sense in having multiple PETRs distant from the
 LISP site, with the LISP site's router having to choose between them
for packets depending on the physical location of the destination of
those packets.

> either, but I'm not sure it should _mandate_ anything.

I imagine the LISP PETR specification will allow all sorts of things,
but the key thing is to show the desired arrangements are attractive
from both technical and business perspectives.

> something this proposal needs to cover.

OK.

> the LISP-encapsulated packets are coming from, is not something this proposal

I don't understand either i) or ii).  I think the PETR specification
needs to identify when PETRs would be needed and when not.  As part
of this it should give some principles and ideally examples of the
sorts of "LISP-node", "LISP-site" or whatever which will be sending
packets to the PETR.

> > The PETR only receives packets from LISP nodes which are addressed to

OK.

> traffic - see the comment above about PETR placement.

OK.

> original message gave two, perhaps others can come up with more?

Darrel's messages gave two purposes, or functions to be performed.

I think it would help me and other people if there were some specific
examples of when PETRs would be needed.  If there are multiple types
of scenario when they are needed, it would be good to have two or
more examples of each kind of scenario, together with a more formal
definition of the scenario.

Without this, the discussion inevitably becomes messy since I and
others are trying to imagine why the main LISP developers want PETRs
- but are probably getting it wrong because the developers have not
yet clearly explained, with examples, when they would be needed.

> the original source of the packets, or the ITR, or what?

A am asking about whatever it is which is sending packets to the PETR.

I see the term "LISP-NR" is used - but I didn't know what this meant.

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

     LISP Non-Routable (LISP-NR) Site:

        A LISP site whose addresses are EIDs only, these EIDs are
        not found in the legacy Internet routing table.

So to me, this means addresses used by an end-user network where the
addresses are LISP-mapped, and will be handled by ITRs in the sending
network, and tunneled to the ETR of the end-user network, wherever it
is - *and* that this address range is not covered by an advertisement
by an Proxy Tunnel Router.  (If it was in a PTR advertisement, then
these EID addresses used by the end-user network would be encompassed
by one of the BGP-advertised prefixes.)

This makes no sense to me.  Why would anyone adopt LISP-mapped
addresses without them being covered by PTRs?  To do so would mean
that these addresses are only reachable from hosts in networks with
ITRs.

This contrasts with another definition:

     LISP Routable (LISP-R) Site:

        A LISP site whose addresses are used as both globally
        routable IP addresses and LISP EIDs.

To me, this means a LISP site with EID addresses which are covered by
PTR advertisements.  This is the only way I imagine anyone might want
to adopt LISP-mapped addresses, since the PTRs are the only way their
hosts would be reachable from hosts in networks without ITRs.  (In
Ivip, all Ivip-mapped addresses are covered by OITRDs, which do the
same job as PTRs.)

So are PETRs really only needed for this subset of end-user networks
which don't have their addresses covered by PTRs?  If so, I would
like to understand why - and why anyone thinks LISP would be adopted
on this basis by any end-user networks.

> which which that ITR is responsible.

Is this formally specified anywhere yet?  It seems unworkable to me
that an ITR would have to figure out the address of its NAT box.
What if it is behind multiple layers of NAT?

I think there really needs to be a full description of why anyone
expects a LISP ITR to be behind NAT - with all the business and
technical reasons why this is the case.

Having the ITR behind NAT violates one of the original principles of
LISP, which is there in the very first I-D, I am sure, about ETRs and
ITRs always being on "RLOC" global unicast addresses, not on "EID"
addresses and implicitly not behind NAT, since behind NAT means their
actual address is not global unicast.

> used in many different ways.

I think you need to make some specific examples.  The original LISP
concept did not anticipate ITRs being on slow, expensive or
unreliable links.  If this is being contemplated, it needs to be
recognised clearly - and reasons given for this change.  Then, this
particular class of ITRs may require different arrangements for
PMTUD, handling dropped packets etc.

> The same way we would between the ITR and any other ETR, I would assume.

Just because this new network element is called a Proxy ETR doesn't
mean it has anything in common with an ordinary LISP ETR.  With the
original ETR concept, you knew it was either:

  1 - In the network of the ISP which was one of the ISPs by which
      the end-user network is using for Internet access.

or

  2 - It is a Provider Edge router in the end-user network, right
      next to the ISP (but presumably at the end-user site, not
      at the ISP).

I think there was ongoing debate about where ETRs were located and I
don't recall it being settled either way.

These PETRs do not in any way resemble ETRs.  They are not at or near
the destination end-user network and they are not in a business sense
associated with any destination end-user network.  They are, I
suggest, more likely to be close to and in a business sense
associated with the end-user network which is sending packets.

With the basic ETR concept, if the ETR is dead, this means (for a
multihomed destination end-user site) that each sending ITRs somehow
discover this and then decides to tunnel packets to another ETR which
is specified in the mapping.

So with this basic concept of an ETR, the ITR is not generally
concerned about two-way communication to make sure all packets it
tunnels to it are received.

If a PETR is dead, this has nothing to do with mapping or any
particular end-user site.  The ITR really needs to be sure all the
packets (or almost all of them) it tunnels to the PETR are received
there and that the PETR can handle them properly.  A PETR failure is
not at all like an ETR failure, since there is no mapping involved,
no alternative ETR to choose etc.

> reverse user-data traffic to piggyback nonces on.

OK - as I wrote above.

> colocation), there's no way to know about a particular configuration until

OK.

  - Robin

---

From: Sam Hartman <[email-masked]>
Date: Sun, 20 Sep 2009 11:33:09 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    >> From: Robin Whittle <[email-masked]> AFAIK, you haven't
    >> specified the commercial relationship between the operator of
    >> the LISP node and the operator of the PETR which it uses.

    Noel> Right, but obvious commercial arrangements are outside the
    Noel> IETF scope. If your point was that you can't see that there
    Noel> will be any economically workable arrangement, that I think
    Noel> would be something that should concern us.  As to that, I
    Noel> have no idea...

Noel, Dan and I have both commented on why many business model aspects
are in scope here in terms of management, operability, and security.

I understand there is a claim generally held to be true that business
models are out of scope for the IETF.  There are certainly aspects of
that claim that are very true.

However, deployment, management, operations and security are all very
much in scope for this working group. As such, a large number of
business relationship discussions are in scope, especially initially.

It's possibl things may get out of hand, but let us start by being
inclusive rather than trying to shut people down in the first couple
messages of a thread.

Sam Hartman
LISP co-chair.

---

From: Robin Whittle <[email-masked]>
Date: Tue, 22 Sep 2009 00:18:24 +1000

Hi Sam,

Thanks for this.  Can you or anyone else point me to the RFCs or
whatever which give guidance on discussing "business models" within
an IETF WG?

Irrespective of what those restrictions are, I think there's no point
in devising a scalable routing solution without a thorough set of
possible business models to match everything which needs to be
adopted, changed deployed etc.

We can't force the solution on anyone.  We need to show, in theory,
at least one and ideally more plausible reasons why existing and new
organisations will want to do all the things which need to be done.

I recognise in an experimental WG such as this, we can't necessarily
come up with a perfectly satisfactory business model for adoption of
every element of the proposed solution, but the earlier we start
thinking about these things the better.

The business aspects of PETRs have a big impact on the design of the
protocols.  For instance:

  1 - Who is paying to access what PETR - or are all PETRs open
      for everyone - in which case, who pays for them?

  2 - How close are PETRs usually to the LISP sites which send
      them packets.  If they are close, then how does an end-user
      network move to a completely different network on the other
      side of the planet, and get access to PETRs there, if the
      PETRs are independent of the networks they are using for
      access?  They would presumably need to deal with a new
      company which runs PETRs in the other location.  Then
      there needs to be authentication so all this can happen
      securely without much administrative fuss.

If there are going to be ITRs behind NAT then how is the PETR going
to distinguish between multiple ITRs behind a single global unicast
address?

How is a PETR going to avoid accepting packets sent by other parties
than the authorised ITRs?  Anyone can send a packet to the PETR with
a tunnel protocol identical to LISP, but with a forged ITR address
matching that of an ITR which the PETR is authorised to handle
packets from.

 - Robin

  - Robin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Sep 2009 10:27:42 -0400

I think that there is a distinction that is important to keep in mind.
First, some assumptions I make:
For LISP to work, it has to be deployable.
Deployability includes the presence of suitable incentives for 
deployment.  That clearly includes appropriate balance of financial 
incentives and disincentives.

For many parts of this system, that is straightforward, and does not 
involve business models.

For PTRs and PETRs there does appear to be a question about what the 
incentives for deployment are going to be.  Who will deploy them, and why?

It is quite reasonable, and I think necessary, to discuss what possible 
incentives there are, who needs to deploy the things, and why they might 
do so.
The distinction I draw is between that and "a thorough set of possible 
business models."  We are not trying to explore the space of business 
models, or determine whether this is compatible with every one.  We do 
not even have to do a full economic analysis confirming that there is a 
business model that covers everything.

Phrased differently, I think we need to convince ourselves that the 
business model has enough solidity that it may succeed.  After that, the 
experiments should help us tell who is interested, and what the actual 
costs are, etc...  Our initial evaluation needs to look at overall 
incentives and overall costs, not details of business models.

Yours,
Joel

> adopted, changed deployed etc.
...

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 10:55:42 -0400

>>>>> "Robin" == Robin Whittle <[email-masked]> writes:
8
    Robin> Hi Sam, Thanks for this.  Can you or anyone else point me
    Robin> to the RFCs or whatever which give guidance on discussing
    Robin> "business models" within an IETF WG?

Most of the restrictions would come from US anti-trust law.  I am not
qualified to give legal advice.  I do not know of specific IETF
policies that cover what is and is not acceptable in detail; if I need
help I'll consult Jari and the IESG.

I do think Joel's comments are quite helpful on this.

There's an additional factor Joel didn't cover that is important for
security.  Whith whom am I likely to have relationships?  For example
if I'm likely to have some sort of relationship with my EID provider,
it is probably reasonable that I'm going to need to set up a secret
used for map registers with that provider.  However if I'm going to be
communicating with parties with whom I have no prior relationship,
then assuming a shared secret or shared trust anchor may be a very
dubious assumption.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 21 Sep 2009 10:25:08 -0700

> proposed before the whole PETR concept is accepted.

Here is a simple one.  A provider wants to advertise that it allows for
IPv6 connectivity, but it does not have equipment in the access network
that supports v6 natively.  So it offers a v6 service that includes a
CPE device that runs LISP, and some PETRs for those CPE's to use when
accessing non-LISP sites.  IPv6 packets sent from the hosts at the site
are encapsulated in v4 and sent over the access network that does not
support v6.

There are a myriad of other possibilities here, including over-the-top
service providers who offer PETR services.  

-Darrel

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 14:11:18 -0400

>>>>> "Darrel" == Darrel Lewis (darlewis) <[email-masked]> writes:

    >> 
    >> I am not saying there isn't a viable business model for PETRs.
    >> I am just saying that I don't know what the business model is
    >> for PETRs and that I think that at least one seemingly viable
    >> model should be proposed before the whole PETR concept is
    >> accepted.
    >> 
    >> 
    >> 

Here is a simple one.  A provider wants to advertise that it allows for
    Darrel> IPv6 connectivity, but it does not have equipment in the
    Darrel> access network that supports v6 natively.  So it offers a
    Darrel> v6 service that includes a CPE device that runs LISP, and
    Darrel> some PETRs for those CPE's to use when accessing non-LISP
    Darrel> sites.  IPv6 packets sent from the hosts at the site are
    Darrel> encapsulated in v4 and sent over the access network that
    Darrel> does not support v6.

Speaking as an individual, I'd like to find deployment models f
Speaking as an individual, this deployment model has two problems:

1) The IETF already has other solutinos in that space with a lot more
successful deployment than LISP (6to4, Teredo, probably even 6rd).

2) This deployment model does not actually get to the deployment we
need.

As I understand it, for interworking to be useful, we need to get to a
point where everyone using LISP either

A) Is on a link that can loosen URPF

or
B)  has a PETR they can use.

So, you need to show that there are sufficient insentives to make
PETRs available to all lisp sites on access networks that are going to
enforce URPF.  Combining with v6 deployment doesn't really seem to
help this much.

I can see insentives for whomever is selling you your EID to make a
PETR available to you, but unless you are going to end up tied to a
single ISP, I don't see why they will be in a position to make a PETR
available close to you.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 21 Sep 2009 11:39:28 -0700

> Speaking as an individual, this deployment model has two problems:

To be clear, I also am speaking as an individual.

> 2) This deployment model does not actually get to the deployment we

It is one of many possible ones, and since it is one we have existence
proof for (there are many over the top providers offering v6 via GRE
today), I used it as an example.  I don't think that we're required to
exhaustively discuss the deployment and business models for an
experimental protocol.

But if you like I can provide another example of a virtual over the top
provider offering LISP, VPN, and other services.

> A) Is on a link that can loosen URPF

To be specific, the provider has to work around strict uRPF.  The draft
provides a few examples of how to do this, including using a less strict
version, or (preferably) adding a static route to the EID space on the
PE router.

> B)  has a PETR they can use.

Or 

C) they use LISP-NAT

> So, you need to show that there are sufficient incentives to make

This is not correct, NAT is always an option.

For v6, we have a difference of opinion here it seems.  I believe that
using this to hop over my provider's v4 only access network is
interesting.  I don't see why the existence of alternatives should
preclude LISP experimenting with this problem - certainly there are
other alternatives to the routing problem (like shim6) that have not
precluded experimentation with LISP.

> 
> I can see incentives for whomever is selling you your EID to make a

If we can see the incentives, that should be enough correct? 

-Darrel

---

From: David Meyer <[email-masked]>
Date: Mon, 21 Sep 2009 13:48:55 -0700

> 2) This deployment model does not actually get to the deployment we

	Understand that you are speaking as an individual;
	however, are you stating your points above are reqired
	either by the IETF and/or by the WG? That is, are you
	Experimental RFCs should not be developed when there are
	other solutions in the same general space? 2) is a little
	harder to deal with (being subjective); see below.

	If so, can you point at any document that states that
	work designed to lead to an Experimental RFC should *not*
	be undertaken if another solution exists (your 1) above)?
	If not, why do you raise the issue?

	With respect to assertion 2): I understand that this is
	your (and perhaps others) opinion. However, there are
	many other folks with opinions that differ from yours, so
	I'm not sure what the significance of your statement is
	in the context of WG's milestones. 

	Please clarify what you are trying to say here (in both cases).

	Appreciated,

	Dave

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 17:25:24 -0400

>>>>> "David" == David Meyer <[email-masked]> writes:

    David> 	Understand that you are speaking as an individual;
    David> however, are you stating your points above are reqired
    David> either by the IETF and/or by the WG? That is, are you
    David> Experimental RFCs should not be developed when there are
    David> other solutions in the same general space? 

We have a fairly specific charter for why we're developing LISP.
I don't think easing IPv6 transition is part of it.
As an individual, I prefer that the WG not spend its energy working on problems where that's the motivation.
I prefer that when we do work on a problem that we try and think about v6 transition.
So, if we do PETRs, we should make them friendly to transition.
However, since we're not in the transition business, we shouldn't do PETRs simply for transition.

Also, yes, I definitely believe it's the case that the IETF should not
do work that is not needed.  I'd hope I don't need to find an RFC to
back that up.  It's my opinion that we have a lot of operational
experience with Teredo and 6to4, and that suggests we're not really
looking for additional mechanisms to tunnel v6 over v4 to get around
NATs and access network issues.  There is some work within the charter
of softwires focused around providing that sort of transition as a
service.  I agree that is needed, although I think even they concluded
they didn't need new encapsulations.

    David> 	With respect to assertion 2): I understand that this
    David> is your (and perhaps others) opinion. However, there are
    David> many other folks with opinions that differ from yours, so
    David> I'm not sure what the significance of your statement is in
    David> the context of WG's milestones.

Well, these people with different opinions need to write to the list
for their opinions to be considered.  So far, the people who have
opinions as far as the WG are concerned are Darrel, Noel, Robbin and
myself.

Presumably since you're writing you have a different opinion.

My assertion #2 roughly boiled down to two parts:

A) If PETRs are going to solve the interworking problem for people who
have URPF blockage, then those people need a PETR they can use.

B) It seems fairly clear to me that if people deploy PETRs as a v6
transition service, they won't be available to the right people to
solve the interworking problem.

I'm hoping to get Darrel to focus on the deployment incentives for
PETRs as a part of the interworking problem between LISP sites and
non-LISP sites, not other deployment incentives that might also
increase the global number of PETRs.

---

From: David Meyer <[email-masked]>
Date: Mon, 21 Sep 2009 14:43:12 -0700

> I don't think easing IPv6 transition is part of it.

	Ok, fair enough. However easing v6 transition was just
	used as an example. The topic was (as you know) on
	interworking, which is part of the charter. Please see
	http://www.ietf.org/dyn/wg/charter/lisp-charter.html.

	That stipulated, note that the title of the Interworking
	Draft is "Interworking LISP with IPv4 and IPv6". Since
	that draft is clearly within the current scope of the WG,
	are you calling for recharting the WG? If so, please
	provide a formal request to both the WG and ADs.

> As an individual, I prefer that the WG not spend its energy
> working on problems where that's the motivation. 

	That's fine. 

> think about v6 transition. 

	Please clarify. I couldn't parse that in the context of
	the rest of your note.

> So, if we do PETRs, we should make them friendly to transition.

	Of course, I think everyone wants that.

> However, since we're not in the transition business, we
> shouldn't do PETRs simply for transition. 

	Again, you've just asserted something that is neither
	supported by the charter or any consensus call that I
	know of.

> back that up.

	I'm sorry, here "what's needed" is an arbitrary call on
	your part. Can you support your definition of "what's
	needed" with anything other than that assertion? 

> It's my opinion that we have a lot of operational

	Again, these are arbitrary assertions. Please provide a
	proceedural artifact to support this. If you can not to
	this, then the above statement is not relevant to the
	operation of the WG.

> Presumably since you're writing you have a different opinion.

	Different than what?

> solve the interworking problem.

	You've just restated your opinion, which to be blunt
	doesn't help. You might also explictly state what you
	would like the WG to accomplish (and provide process
	artififacts other than just restating your opinion).
	
	Dave

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 17:56:45 -0400

>>>>> "David" == David Meyer <[email-masked]> writes:
Dave, I somehow managed to leave out the entire point of my
message--or at least the point that was worthwhile enough to cause me
to hit the send key.
Please see below and see if you can help me out.

    >> Presumably since you're writing you have a different opinion.

    David> 	Different than what?
mine I was hoping that I could restate my opinion and get you to
explain what part of it you disagreed with.  So far you've been grumpy
that I stated an opinion, but not actually stated one of your own.

However all I did was restate my opinion without actually asking you to comment on it.

    >> A) If PETRs are going to solve the interworking problem for
    >> people who have URPF blockage, then those people need a PETR
    >> they can use.
    >> 
    >> B) It seems fairly clear to me that if people deploy PETRs as a
    >> v6 transition service, they won't be available to the right
    >> people to solve the interworking problem.

---

From: David Meyer <[email-masked]>
Date: Mon, 21 Sep 2009 15:13:29 -0700

> However all I did was restate my opinion without actually asking you to comment on it.

	Well, a PETR is a general tool with multiple applications.
	More specifically, the point of PETR/PTRs is not
	specifically to aid in v6 transition (though that is a
	use case), but rather to fully utilize LISP's IP protocol
	independence, and to bring the benefits of LISP to sites
	that run LISP day one (i.e., without waiting for the
	entire network to transition to LISP). There are also
	advantages that accrue from the use of PTRs that may not
	be immediately obvious (such as helping ingress TE for
	LISP sites).   

	Dave

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 18:13:54 -0400

>> >>>>> "David" == David Meyer <[email-masked]> writes:
    David> Understand that you are speaking as an individual; however,
    David> are you stating your points above are reqired either by the
    David> IETF and/or by the WG? That is, are you Experimental RFCs
    David> should not be developed when there are other solutions in
    David> the same general space?
    >> 
    >> We have a fairly specific charter for why we're developing
    >> LISP.  I don't think easing IPv6 transition is part of it.

    David> 	Ok, fair enough. However easing v6 transition was just
    David> used as an example. 

Right.  And I was basically saying I didn't think it was a good
example for why PETRs would be deployed in the right places.  I was
not in that message commenting on whether I think PETRs are a good
idea for interworking.  In a later message I commented that I don't
know if they are a good idea because I don't understand the security
or deployment issues.

[We both agree interworking is in the charter.]

    David> 	That stipulated, note that the title of the
    David> Interworking Draft is "Interworking LISP with IPv4 and
    David> IPv6". 

Hmm, I've always read that draft to be about how LISP works with
non-lisp sites on both V4 and V6 networks.  I have not read that draft
to be about how LISP is used as a cross-protocol transition mechanism.
I agree that some of the mechanisms described in the interworking draft
do make it easier for LISP to be used as a cross-protocol mechanism.
I just re-read the abstract of that draft and as far as I can tell it supports my reading of the purpose of the draft.
So, I'm quite happy with the scope of the draft and the charter.

    >> think about v6 transition.

    David> 	Please clarify. I couldn't parse that in the context
    David> of the rest of your note.

    >> So, if we do PETRs, we should make them friendly to transition.

    David> 	Of course, I think everyone wants that.

OK, so we're on the same page here.  That's the sort of issue I'm
talking about when I say when we do our work we should think about
transition.

    >> shouldn't do PETRs simply for transition.

Restating: If the only reason to create PETRs were that we needed to
do so in order to make LISP a better mechanism for v6 transition, then
I don't think we should do so.  Note that no one is claiming PETRs are
only for transition.  More to the point, I think if your example about
why PETRs will be deployed is only about transition, then I personally
believe that we should work on better deployment examples.

    David> 	Again, you've just asserted something that is neither
    David> supported by the charter or any consensus call that I know
    David> of.

Yes. It's true.  Remember that I said I was stating my own individual
opinion--as an individual contributor *not* as a chair.  The IETF is
kind of frustrating, but so far, it has not yet driven me to a point
where I have enough internal disunity that I need to make consensus
calls inside my own head before deciding what I think.:-)

In all seriousness, I think in some of the cases where you claim I
made assertions, I did provide enough support that I think I
contributed to the discussion.  I did not provide enough support to
make any comment as a chair; nor did I intend to.

This has all been blown way out of proportion though: I was trying to
say that I wish Darrel would focus on giving deployment examples
related to interworking.  Sorry it turned into such a mess.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 18:26:28 -0400

>>>>> "Darrel" == Darrel Lewis (darlewis) <[email-masked]> writes:

    Darrel> For v6, we have a difference of opinion here it seems.  I
    Darrel> believe that using this to hop over my provider's v4 only
    Darrel> access network is interesting.  

I do too.

I think my message was read as a broader statement than I intended.

Robbin asked you roughly "Why will someone deploy the PETR I need?"

You responded, as I understand it, "They might deploy a PETR so they could help you with v6."

I intended to say "Really the main point here is interworking, so I'd
rather focus on deployment incentives for that use case."

I'll admit that if you're already using LISP, using it as a v6
transition mechanism seems like a great idea.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 21 Sep 2009 15:33:21 -0700

> I intended to say "Really the main point here is Interworking, so I'd

So personally, if I was multihoming with, I'd pay for a site that would
let me hop over my access provider's v4 limitations.  I'd also use it
because that same access provider does not allow me to bypass uRPF even
on their business class service.

If I could not get a PETR service 'close enough', I would use LISP-NAT
for this (URPF avoidance) purpose.  As Dave pointed out in his email, a
very interesting (to me) side effect of both Proxy ITRs and Proxy ETRs
are that LISP sites see the benefits (ingress TE and protocol
independent data plane) of LISP day one.  Both I consider optional
however, since LISP-NAT is an alternative.  

-Darrel

---

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Sep 2009 22:27:38 +0300

This working group is not chartered to develop solutions to the 
IPv4-IPv6 transition problem. We have plenty of other working groups in 
that space already.

Of course, I understand that pretty much any tunneling or translation 
technique can be used for IPv6 deployment as well. I do not mind if such 
use case gets mentioned in a list of other potential uses of Lisp. 
However, the main use case, deployment rationale, etc. needs to stand on 
its own and talk about routing scalability, traffic engineering, and 
other things central to Lisp. I also understand that what we develop 
technology X for may not be what it eventually gets used for; we've been 
surprised before. Lets see what happens with Lisp. But for the RFCs that 
come out of this working group, lets focus on the initial main reason 
why Lisp was developed.

Jari

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Fri, 25 Sep 2009 12:01:09 -0700

Jari, 

> other things central to Lisp. 

Thanks for your note, I have a few comments that follow about the
intended scope of LISP Interworking.  I don't see a conflict with what
you've written, but I want to try to clarify my position on LISP
Interworking for the WG. 

A central design goal of LISP is that it be practical, that is, work
within the existing, deployed, Internet.  Today that Internet has a
mixture of IPv4 only, dual stack, and IPv6 only hosts and networks.  It
also is comprised of a myriad of access technologies, security
mechanisms, that LISP xTR must integrate with in order to be deployable.
LISP attempts to solve the routing scalability problem for both IPv4 and
IPv6, and therefore LISP sites must interwork with non-LISP sites of
both IP protocols.

A central benefit of network based Interworking is how it enables the
benefits of LISP for the site which has deployed LISP:

On ingress, using Proxy Ingress Tunnel Routers, this is primarily the
enablement of LISP's Ingress Traffic Engineering features.  One result
of this is that LISP sites relying on Proxy Ingress Tunnel Routers will
see all ingress traffic LISP encapsulated - and therefore see this
benefit of LISP immediately.  I might add, a second order benefit is
that if the Proxy Ingress Tunnel Router's RLOCs are connected the a Dual
Stack IPv4/IPv6 network, the connectivity from the Proxy Ingress Tunnel
Router to the site's ETR does not have to be Dual Stack.  Proxy Ingress
Tunnel Routers also are a primary tool to encourage sites not to Inject
EIDs into the Internet routing system.  They in effect make EID's
routable without direct injection (and inevitable degradation) of the
EID space by individual sites.

For a site using Proxy Egress Tunnel Routers on egress there are fewer
LISP specific benefits.  This is because LISP does not attempt to
enhance Egress Traffic Engineering (instead utilizing the site's
existing egress IP routing mechanics).  The primary use cases for Proxy
Egress Tunnel routers are actually only to address practical deployment
concerns. These secondary issues include working around limitations to
the installed access networks' implementation of BCP 38 filtering, and
working around the lack of support found in access networks for dual
stack IPv4 and IPv6.  So this means that not every LISP-Site will need a
Proxy Egress Tunnel Router, but we know from our experimentations to
date that it will help some of LISP sites, and this instigated the ideas
and proposed text found in this thread.

Note that both of these network based approaches are not required if
LISP-NAT (currently specified only for IPv4)is used.  LISP NAT instead
uses routable EIDs that fall within the Provider Assigned address space.
But a LISP site using LISP-NAT misses out in the advantages of ingress
TE above, and will obviously not be IPv6 capable.  

>I also understand that what we develop 

Understood, and I think we are.  My opinion is that Proxy Egress Tunnel
routers are an interesting option that I think will assist in LISP sites
to communicate with non-LISP sites.

-Darrel