Subject: [RRG] On the Transitionability of LISP

From: Christian Vogt <[email-masked]>
Date: Thu, 02 Aug 2007 10:24:23 +0300

Folks,

I brought this up at the microphone during the RRG meeting in Chicago,
but would like to elaborate with more details here on the mailing list.

There is a transition problem with any ID/locator split mechanism that
requires mapping functions both locally at an edge network, and remotely
at any correspondent edge network that the former edge network may
exchange traffic with.  One such mechanism is LISP, where the local and
remote mapping functions each take the form of an ITR/ETR pair.

The requirement for support on both sides implies that an "upgraded"
edge network using mapped IDs will no longer be reachable from "legacy"
edge networks that do not yet support the mapping.  This is a
disincentive for edge networks to adopt the ID/locator split mechanism
during an early transition stage.

The only way I see to get around this disincentive is the approach of
Ivip:  Decouple the remote mapping function from potential correspondent
edge networks, move it further into transit space, and use anycast IDs
to reach it.

(The reason one needs anycast IDs is to let multiple alternative
providers perform the same remote mapping for an edge network.  Unicast
IDs would bind the remote mapping to a single provider.  This would
create a dependency of the edge network on that provider, which is
exactly what we want to avoid with multi-homing.)

A side effect of anycast IDs is a change in the Internet business model.
 Edge networks today only need business relationships with providers
they directly connect to.  A transition towards mapped anycast IDs would
require an edge network to additionally subscribe to the remote-mapping
service of multiple providers further inside transit space.

As many as possible remote-mapping subscriptions would be needed per
edge network to limit the increase in packet propagation delays, which
the new, triangular routes via a remote-mapping provider would entail.

Coordination would be required between remote-mapping providers.  The
providers would need to jointly administer a large, aggregatable block
of anycast IDs, and consistently map slices of this to the locators of
subscribing edge networks.

- Christian

--
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: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Aug 2007 12:03:41 +0200

> remote mapping functions each take the form of an ITR/ETR pair.

There are two things in the shim6 design that avoid this problem
(as part of shim6's "first, do no harm" principle):

1. The ID in shim6 is also a globally valid locator.

2. If the other end doesn't respond to shim6 messages, shim6 is a
no-op.

In any solution, if the other end doesn't respond in a way that
makes it clear that it supports the solution, then we can assume
that it still has valid routeable addresses that can be used. In
that case, the host at this end would need a legacy routeable address
to obtain connectivity. In other words, during the coexistence
era, hosts would need one ID-style address and one PA/PI style address
per address family.

I think this is more deployable than coordinating an anycast
solution.

     Brian

---

From: David Meyer <[email-masked]>
Date: Thu, 2 Aug 2007 07:22:20 -0700

Christian,

> during an early transition stage.

	This would seem to be incorrect. There is no reason that
	early adopters need withdraw their "legacy" routes from
	the DFZ until it makes sense. So legacy sites reach the
	site via the legacy system, and the upgraded sites use
	the new mechanism. You could even have example.com
	(legacy) and example-new.com (or whatever). Or both,
	depending on what makes sense.

	It also seems pretty obvious that more work is required
	on transition strategies, but I just wanted to mention
	that one could imagine many scenarios in which benefit
	can be accrued w/o a flag day (i.e., incrementally). 

	Dave

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 02 Aug 2007 17:09:48 +0200

David,

But what would be the trigger ? What makes a critical mass that anyone 
could stop advertising their addresses into DFZ ?

What happens then to some which still did not joined LISP cart ?

I think the suggestion Vince once mentioned on the list reg LPAs (Lisp 
Proxy Aggregators) would be a much better answer and transition 
strategy. But it is also true that they would tend to do much worse job 
then IViP as that one relies on huge chunks of addresses to be injected 
into DFZ not just what can be aggregated at a given point of time.

Cheers,
R.

---

From: David Meyer <[email-masked]>
Date: Thu, 2 Aug 2007 08:28:02 -0700

Hey Robert,

> could stop advertising their addresses into DFZ ?

	Like everyone, the folks looking at LISP are thinking
	about incentives, transitition schemes, etc. So those
	details are just the ones we're trying to understand. A
	few early ideas include the possibility of doing
	advantageous TE and the availablity of expanded EID space
	inside a site. But these aren't really cooked (devil in
	the details and all).

> strategy. 

	Yes, that's one transition mechanism.

> But it is also true that they would tend to do much worse job 

	I'm not sure its required rather than desired. Do you see
	it differently?

	Dave

---

From: Robin Whittle <[email-masked]>
Date: Fri, 03 Aug 2007 01:48:25 +1000

Hi Brian,

You compared SHIM6 with LISP, and by implication with Ivip (with
your mention of anycast, in the context of Christian's discussion of
Ivip's "anycast ITRs in the core".

> I think this is more deployable than coordinating an anycast

Within the restricted scope that SHIM6 operates, it may be easier to
deploy than a bunch of anycast ITRs for IPv4 and/or IPv6.  SHIM6
only involves IPv6 hosts, and it is assumed that it is feasible to
upgrade their operating systems with SHIM6 code, whenever that
becomes finalised.

However, LISP, eFIT-APT and Ivip all solve a much broader set of
problems than SHIM6 solves.  Here is a table:

             SHIM6  Six/  Mobile  LISP-   LISP-   eFIT-  Ivip
                    One   IPv6    NERD    CONS    APT	

Address
portability                       Y       Y       Y      Y

Multihoming   Y     Y             Y       Y       Y      Y

Mobility                  Y                              Y*

IPv4 too                          Y       Y       Y      Y

No host                           Y       Y       Y      Y*
changes

* Mobile IPv4 or IPv6 hosts making use of Ivip will need new host
  software.

There are various administrative and business questions to be solved
regarding who is going to run a database system - and in the case of
Ivip, who is going to run anycast ITRs.  Considering the problems
this would solve, I think it would be easier to solve these business
problems than change all host software, change everyone over to IPv6
etc.

I think that it might be a profitable enterprise right now to create
an Ivip system, with TTRs and ITRs combined, all over the Net.  Then
rent out the space it maps, in single IP addresses or any larger
number - prefixes or arbitrary contiguous sets of addresses.  The
end-user either uses special software to tunnel to the nearest TTR,
which saves them trying to send packets in their current provider
network with source address = an Ivip-mapped address.

Alternatively, if they can get their packets out OK, they can have a
little software and be their own ETR.

(This assumes that the problems of MTU limits, fragmentation, PMTUD
etc. are solved - they are common problems for LISP and eFIT-APT
too. It also assumes a good method is devised of getting mapping
data out to all the ITRs in a few seconds.  I think this is feasible.)

This would be more profitable once supplies of fresh IPv4 space dry up.

The operators wouldn't need to wait for IETF standards - they could
make their own protocols, and also provide a multihoming monitoring
system with hooks into the database.

On one hand, I wonder - who is going to build these ITRs?  On the
other, I could imagine one or more companies doing it and making money.

Hi David,

> depending on what makes sense.

Then during transition, there is no removal of prefixes from the
global BGP routing table.  (There can still be benefits, because if
you use the system appropriately, I think you can serve more
end-users in a given space than with the old BGP-based techniques.)

During transition, you have a mixed bag of results.  You only get
portability, multihoming and TE for packets from upgraded networks -
unless the border router of the site acts as an ITR.

If it does act as an ITR, then you get sub-optimal paths if the ETR
for some EID in the space is somewhere distant.

For instance, if the sending host in a non-upgraded network is in
Sydney, the ITR is a border router in San Francisco, and the ETR is
in Melbourne, packets have to cross the Pacific twice to get from
Sydney to Melbourne.

Ivip proposes to solves this by having ITRs not too far from most
non-upgraded networks.  An ITR somewhere in Sydney would solve the
problem and give close to optimal path lengths.

If your border router is not an ITR, then you have portability,
multihoming and TE only for packets sent from hosts in LISP-upgraded
networks.

You can't remove the BGP advertisement until you don't care about
the small number of hosts in non-upgraded networks who won't be able
to reach any of the hosts in the address range.  So the transition
time would be very long indeed - until you could somehow convince
almost all networks to install their own ITR.

I think it would be easier to put anycast ITRs in the core than to
try to get people to use address space in a system which produced
half-baked results.

I have no clear understanding of what a LISP "proxy aggregator" is.
 Can you explain it, perhaps with a diagram and examples, rather
than a few terse words, which is all I remember about Vince's
mention of it some time ago on the RAM list?

Hi Christian,

You wrote, in part:

> There is a transition problem with any ID/locator split mechanism
> that requires mapping functions both locally at an edge network,
> and remotely at any correspondent edge network that the former
> edge network may exchange traffic with.  One such mechanism is
> LISP, where the local and remote mapping functions each take the
>  form of an ITR/ETR pair.
>
> The requirement for support on both sides implies that an
> "upgraded" edge network using mapped IDs will no longer be
> reachable from "legacy" edge networks that do not yet support the
> mapping.  This is a disincentive for edge networks to adopt the
> ID/locator split mechanism during an early transition stage.

This is the basic problem with LISP, unless one of the workarounds
is adopted, both involving continued BGP advertisement of the whole
block of addresses which is being subject to LISP mapping.

1 - Get packets from non-upgraded networks to the border router
    and then only be able to transport them in that network,
    which means that if the end-user's host or network is in
    another network, they have no connectivity from hosts in
    non-upgraded networks.  This is the ordinary border router
    option.  It means there is no portability, multihoming etc.
    for packets from non-upgraded networks - which I think makes
    it highly unattractive for anyone thinking of using LISP
    mapped addresses and taking their network to some other
    network than wherever this border router is located - which
    is the whole point of portability, multihoming and TE.

2 - The "border router is the ITR for the world for this block
    of LISP-mapped addresses" approach, which involves highly
    sub-optimal path lengths if the ETR is far from the
    border router.

3 - Adopt Ivip's "anycast ITRs in the core" idea . . .

> The only way I see to get around this disincentive is the approach
> of Ivip:  Decouple the remote mapping function from potential
> correspondent edge networks, move it further into transit space,
> and use anycast IDs to reach it.

Yes - the address block which is XXX-mapped, or rather all such
address blocks, are advertised by multiple BGP routers all over the
Net, operated probably by multiple ASes, at their border routers, or
as ITRs sitting as islands in the midst of transit routers and
border routers of other providers etc.

It doesn't matter technically who runs them.  Each such router has
its own IP address from which it tunnels the packets to the
appropriate ETRs.

> providers perform the same remote mapping for an edge network.

> Unicast IDs would bind the remote mapping to a single provider.

That is the option 2 above there is only one ITR advertising the
address block, which is run by one provider.

> This would create a dependency of the edge network on that
> provider, which is exactly what we want to avoid with
> multi-homing.)

Yes.  So there needs to be a generally highly reliable global
network of ITRs, some run inside networks, other as anycast BGP
routers catching packets from nearby non-upgraded networks.  Then
they all need to tunnel according to some centralised/distributed,
database and replication system.  All end-users trust the
connectivity of their system to all this machinery, and to the
business survival of whoever runs it.

> A side effect of anycast IDs is a change in the Internet business
> model. Edge networks today only need business relationships with
> providers they directly connect to.  A transition towards mapped
> anycast IDs would require an edge network to additionally
> subscribe to the remote-mapping service of multiple providers
> further inside transit space.

I think you mean that an edge network runs an ITR, and the ITR needs
to get database updates from multiple organisations each of whom
control the mapping for one of the many blocks of Ivip-mapped
address space.

I think this involves assumptions about who controls the various
sections of the entire mapping database.  In the Ivip I-D, I propose
a tree-structured set of Update Authorisation System, where one Root
Update Authorization System RUAS is authoritative for one Ivip
Mapped Address Block (IMAB).  There could me many such IMABs.  I
suppose that each IMAP must have been assigned by an RIR to some AS
- so that means the RUAS for that IMAB is run by, or authorised by,
that AS.

However, maybe each RIR runs multiple IMABs, all controlled by its
one RUAS.  Then it can deal out IP address space in arbitrary sizes,
down to single IP addresses.

This represents a significant extension of the RIR activities, but
maybe they do it by assigning the space to some reasonably stable
consortium, which itself is unlikely to fail in business.  Then,
end-users who get some of the space within each such IMAB are
dealing with some more substantial and stable thing than a mere ISP,
which could be taken over, go bankrupt etc.

> As many as possible remote-mapping subscriptions would be needed
> per edge network to limit the increase in packet propagation
> delays, which the new, triangular routes via a remote-mapping
> provider would entail.

Maybe you mean "there must be lots of ITRs so packets don't go
far before finding one"?

> Coordination would be required between remote-mapping providers.
> The providers would need to jointly administer a large,
> aggregatable block of anycast IDs, and consistently map slices of
> this to the locators of subscribing edge networks.

I don't understand these paragraphs.

If you could express it with terminology similar to that in the Ivip
I-D, or contrast what you are trying to describe with what I
describe in the I-D, that would help.   You may be describing
exactly what I am describing, but using different words.

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

---

From: "Mark Handley" <[email-masked]>
Date: Thu, 2 Aug 2007 16:52:45 +0100

> could stop advertising their addresses into DFZ ?

It seems to me that the problem is basically disaggregation, which is
reasonably closely related to multihoming.

One scenario is that LISP-enabled sites actually get proper
multihoming (so long as both ends are enabled), but non-LISP sites
increasingly find that their long-prefix routes are filtered by ISPs
that buy into LISP.  It's not that non-LISP sites are unreachable;
it's just that they're only reachable via the aggregated path, and
their multihoming doesn't work the way they wish.

A possible early stage of such a transition plan might involve LISP
sites continuing to advertise their existing long prefixes for their
multi-homed customers, but marking them with a transitive attribute
that says "you may drop this route if you do LISP".  Thus LISP-enabled
networks have smaller routing tables than non-LISP networks.  After
enough LISP sites exist, they can also start filtering routes with
long prefixes that are not marked in this way.

Anyway, it's premature to fixate on the details of this at this stage;
the point is that there are transition paths that don't involve making
prefixes unreachable but rather make then suboptimally reachable.

 - Mark

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 2 Aug 2007 18:39:21 -0400

>              SHIM6  Six/  Mobile  LISP-   LISP-   eFIT-  Ivip

Just to point out that:

Shim6 can support address portability, if you use portable  
identifiers, such as ULAs. No need to change anything in the shim6  
specs to support that

Shim6 can be used as a RO mechanism for mobility, (it does not  
provides mobility anchor point capabilities, though)

Shim6 can easily support v4 locators (but not v4 identifiers) (the  
NAT traversal capabilities would need to be worked out, but we are  
discussing about that)

I don't know what kind of problem being solved is "No host changed"  
though... why didn't you include a line about "No router changes"? ;-)

However, the main limitation of shim6 is about traffic engineering,  
that you seem to have missed. Shim6 do provides host enforced TE  
capabilities, but does not provides router enforced TE capabilitis,  
which seems to be a desired feature. (OTOH, Six/One seems to provide  
exactly that complementing Shim6)

Regards, marcelo

---

From: Robin Whittle <[email-masked]>
Date: Fri, 03 Aug 2007 12:33:40 +1000

Hi Mark,

Here is what I think will be the deal for people adopting
Ivip-mapped address space, not counting some problems which are
common to LISP, eFIT-APT and Ivip, regarding Path MTU Discovery,
fragmentation and packet overheads:

  Your hosts will be reachable from all hosts, with full
  portability, multihoming and TE (Ivip enables TE simply
  by the user mapping individual IP addresses or small
  subnets to one ETR or the other).

  Paths will be optimal or very close to optimal from
  hosts in networks with ITRs and there should be no
  reduction in bandwidth limits.

  Path lengths from hosts in non-upgraded networks will be
  generally close to optimal depending on where the closest
  anycast ITR is.  Bandwidth limits will depend on the
  load on that particular ITR.

So for Ivip to involve no loss of connectivity, there needs to be a
substantial ITR system which each able to handle whatever load is
placed upon it.  Generally, ISPs will be motivated to run their own
ITRs, since they have paying customers and part of their service
will be to ensure packets leaving their network don't depend on
external ITRs.

Exactly how the administration or economics of anycast ITRs will
work out, I am not sure.  If there are lots of them, then there will
be little incentive for provider and AS-end-user networks to install
their own ITRs.  If there are too few, then there could be capacity
limits or excessive path lengths which would discourage adoption of
Ivip-mapped address space.

The business plan for all these proposals is hard to determine at
such an early stage.

At least Ivip has a robust, simple, technical solution to the
transition period where some or many networks don't have their own
ITRs.  As long as there are some ITRs in the core, Ivip doesn't
require all networks to have their own ITRs.

Ivip doesn't involve trade-offs such as some packets having benefits
and others not, and about when to pull the plug on hosts in
non-upgraded networks.  With the anycast ITR approach, all packets
are handled by ITRs in the same way.

LISP could ensure all packets were handled by an ITR, if the border
router of some network is the sole BGP advertiser of the prefix and
functions as an ITR.  This would involve sub-optimal path lengths
when the ETR was far from this ITR, potential capacity limits and
continued dependence on that network and its border router.  This is
a single point of failure, so the result is not proper multihoming
for packets arriving from networks without ITRs.

If the border router which advertised the prefixes doesn't function
as an ITR, then adopters of LISP-mapped address space have all this
messy stuff to think about:  packets from some hosts have the new
benefits and packets from hosts in non-upgraded networks have none
of the benefits and just go to the one network, which is not
necessarily where the destination host with the LISP-mapped address is.

You wrote:

> multihoming (so long as both ends are enabled), 

This is multihoming with loss of reachability from a large
proportion of sending hosts, at least in the early stages of adoption.

> but non-LISP sites
> that buy into LISP.  

I don't understand this.  Why would a network with ITRs and ETRs
want to stop sending packets to networks which don't?

The problem we are discussing is how sending hosts in non-upgraded
networks get their packets to the destination, which can only be
done via an ITR and an ETR.

> It's not that non-LISP sites are unreachable;

I don't understand this - LISP doesn't involve making it impossible
to send packets to networks without ITRs or ETRs.  Unless you are
discussing networks which have invested in ITRs and ETRs trying to
freeze out networks which haven't in order to encourage them to
install LISP ITRs and ETRs.

> networks have smaller routing tables than non-LISP networks.  

This is extra trouble for the LISP-enabled networks for a not
particularly valuable benefit: a reduction in routing table size,
when their routers - like all other routers - are able to handle
however big the global routing table is anyway.

> After

I think that what this really means is something like: "When the
LISP-enabled networks decide that the their end-users with
LISP-mapped addresses don't mind not being reachable from hosts in
non-upgraded networks, the network will stop accepting packets from
those non-upgraded networks.

> prefixes unreachable but rather make then suboptimally reachable.

The LISP transition path results in messy outcomes both for hosts
sending packets and for hosts receiving them on LISP-mapped
addresses.  The "anycast ITRs in the core" provides a much cleaner
outcome, but it involves extra investment.

Initially, to get Ivip off the ground, there wouldn't need to be
thousands of "anycast ITRs in the core" because the traffic volumes
wouldn't be so high.  However, they do need to be pretty widely
spread to avoid overly long paths.  There would need to be a few in
Australia to start with, and an a few in any country which was not
part of the big mesh of connectivity of North America, Europe,
Japan, Korea etc.

  http://www.chrisharrison.net/projects/InternetMap/

 - Robin

---

From: Christian Vogt <[email-masked]>
Date: Fri, 03 Aug 2007 19:27:02 +0300

David:

> 	the DFZ until it makes sense. 

I do agree that, to remain reachable, upgraded edge networks would have
to use their old locator space in addition to the new ID space.  What I
am concerned about are the following two problems that arise from this:

  1. It defeats all of the benefits of the ID/locator split.
  2. It makes reliable address resolution infeasible.

Regarding problem 1:  The four main benefits envisioned for an
ID/locator split are the following.

  (i)   Enabling edge networks to route packets via arbitrary providers.
  (ii)  Reducing the network reconfiguration cost related to rehoming.
  (iii) Reducing the size of the global routing table.
  (iv)  Reducing the update frequency of the global routing table.

Now, if an edge network is forced to maintain its old locator space in
addition to new ID space, then /none/ of (i) through (iv) will be
satisfied.  On the contrary, network administration overhead will be
increased, and the global routing table will become larger.

Regarding problem 2:  A coexistence of locators and IDs implies that the
result of address resolution depends on the location of the resolving
host:  Hosts in legacy edge networks MUST obtain legacy locators, while
hosts in upgraded edge networks SHOULD obtain IDs.

If there was only DNS for address resolution, then this could be
achieved by setting up DNS servers in upgraded edge networks so that
they provide IDs, while having DNS servers in legacy edge networks
continue to provide locators.  Filters at the borders of upgraded edge
networks would prevent DNS signaling from leaking between legacy and
upgraded edge networks.

However, there is a plethora of application layer protocols -- such as
SIP or peer-to-peer protocols -- that exchange addresses and thus
perform their own address resolution.  Addresses in packets from all of
these protocols would have to be translated at edge network borders.
This seems infeasible.  [Pekka Nikander calls this problem the "referral
problem" in draft-nikander-ram-generix-proxying-00.]

> 	                  You could even have example.com

Hmm, this is a transition mechanism that is based on changes in user
behavior...

- Christian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Aug 2007 12:38:15 -0400

>increased, and the global routing table will become larger.

Actually, there seem to be quite a few stages between
     advertise all locators in BGP, exactly as today
     advertise nothing in BGP

For example, at a later stage in deployment one could easily imagine 
advertising only heavily aggregated reachability in BGP, for those 
sites that have not upgraded, while using LISP (or other solutions) 
for the bulk of ones traffic.
That would give significant benefit without losing connectivity from 
the non-upgraded world.

>hosts in upgraded edge networks SHOULD obtain IDs.

This is actually somewhat harder.  If hosts actually checked 
reachability, or really used all the A records they got back, it 
might suffice as part of transition to use the EID plus aggregatable 
A information.  (It's too bad DNS A records do not have preferences 
like MX records, but we can't change that now.)

Yours,
Joel

---

From: David Meyer <[email-masked]>
Date: Fri, 3 Aug 2007 10:00:38 -0700

Joel/Christian,

> >  (iv)  Reducing the update frequency of the global routing table.

	All goodness. I would add that there are also a bunch of
	well-known (and other) security benefits that accrue from
	a ID/loc split. 

> for the bulk of ones traffic. That would give significant
> benefit without losing connectivity from  the non-upgraded world.

	Right. In addition, these edge networks might not initially go to
	something like LISP; rather someone might provide an ITR
	for them (seems like a service someone might like to provide).

	BTW, I'm not really sure what an edge network is, or what
	such a distinction buys one (especially given that in
	practice [implementation], the distinction between core and
	edge is rapidly disappearing).

> like MX records, but we can't change that now.)

	Agreed.

	BTW, I explicitly tried not to introduce the term "legacy
	locator" which is why I quoted it in my previous
	message. Let's not go there.

	Dave

---

From: "Darrel Lewis \(darlewis\)" <[email-masked]>
Date: Fri, 3 Aug 2007 10:29:04 -0700

Christian Vogt <> wrote on :

>>> disincentive for edge networks to adopt the ID/locator split
>>> mechanism during an early transition stage.
>> 
> I do agree that, to remain reachable, upgraded edge networks
> would have to use their old locator space in addition to the
> new ID space.  What I am concerned about are the following
> two problems that arise from this:
> 

Just a note:

If a site has existing PI space, then their keeping this space in the DFZ doesn't increase the DFZ's state.

-D

---

From: Christian Vogt <[email-masked]>
Date: Fri, 03 Aug 2007 21:18:11 +0300

> DFZ doesn't increase the DFZ's state.

Darrel,

You are right.  The routing table size will neither in- nor decrease.

- Christian

---

From: [email-masked] (Noel Chiappa)
Date: Sat, 4 Aug 2007 08:59:40 -0400 (EDT)

> From: Christian Vogt <[email-masked]>

    > to use their old locator space in addition to the new ID space. 

The whole issue of what routes need to be carried where is a complex one;
alas, no time/energy to explore it in depth now. It depends a lot on the
exact operational details, so changing them changes the picture.

However, I don't think the picture is this dire (at least in this area - a
bigger issue, IIRC, is getting to legacy networks from inside areas of the
network that have converted).

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Aug 2007 11:45:38 +0200

On 2007-08-03 18:38, Joel M. Halpern wrote:
...
> reachability, or really used all the A records they got back, it might 
> suffice as part of transition to use the EID plus aggregatable A 
> information.  (It's too bad DNS A records do not have preferences like 
> MX records, but we can't change that now.)

I'm glad you wrote "A" records. In the case of "AAAA" records,
the correct practice is to try them in sequence, using the RFC 3484
algorithm by default, and possibly a site-wide RFC 3484 policy.

     Brian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 06 Aug 2007 14:41:24 +0300

Mark,

I don't think providers will make their own customers' non-mapped
prefixes sub-optimally reachable in order to speed up LISP deployment,
especially since the providers won't benefit from this themselves.
Furthermore, an ability to prune long prefixes in edge networks would
leave the Internet core with large, frequently updated routing tables.

My personal summary of this discussion so far is the following:

Early adopters of LISP would need to use non-mapped ("legacy") prefixes
in addition to mapped prefixes.  The continued existence of non-mapped
prefixes, in turn, would defeat much of the purpose of the mapping.

Specifically, the existence of non-mapped prefixes would imply...

for provider-DEPENDENT non-mapped prefixes
- limited TE capabilities
- network reconfiguration overhead during rehoming

for provider-INDEPENDENT non-mapped prefixes
- no decrease in the size of the global routing table
- no decrease in the update frequency of the global routing table

A second problem is that, when initiating a communication session, a
host would have to select the correct type of IP source AND destination
addresses.  Non-mapped addresses must be used if either side does not
support LISP.  Mapped IP source or destination addresses should be used
only if both sides support LISP.

The address selection therefore depends on whether...

- the host's own edge network is LISP-enabled
- the (remote) correspondent host's edge network is LISP-enabled

Related to this is the problem that, if a host has multiple addresses to
choose from, there is no way to tell which ones are mapped and which
ones are non-mapped.  This applies to selecting an IP source address
amongst the host's own addresses as well as to selecting an IP
destination address from the set of addresses of the correspondent host.

Extensions to DNS may solve this latter problem.  But DNS is not the
only way in which hosts obtain addresses.  E.g., you have address
references in application layer protocols (-> referral problem).

- Christian

---

From: Robin Whittle <[email-masked]>
Date: Wed, 08 Aug 2007 01:32:24 +1000

I am responding to Noel and Christian.

> network that have converted).

As far as I know, there is no problem getting a packet out from a
network with LISP, eFIT-APT or Ivip ITRs and or ETRs to a host in
any other network where that host's address is not part of the LISP,
eFIT-APT or Ivip mapping system.  The outgoing packet is not touched
by any ITR or ETR function in any router it passes through.

The problem is getting packets sent by hosts in networks without an
ITR to an ITR so it can be tunneled to whatever ETR is required.

There as been recent discussion about complex, messy, transitional
arrangements for LISP.  I wrote about my best guess of eFIT-APT
transition in the section "Incremental deployability" of:

  http://www.firstpr.com.au/ip/ivip/comp/

Christian Vogt wrote:

> Early adopters of LISP would need to use non-mapped ("legacy")
> prefixes in addition to mapped prefixes.  The continued existence
> of non-mapped prefixes, in turn, would defeat much of the purpose
> of the mapping.

My understanding is that there is only one prefix involved.  Let's
say 20.0.0.0/20 was LISP-NERD/CONS-mapped.

With the basic conception of LISP, ITRs are only within each
"network" (of a provider or some AS-end-user with ordinary PI BPG
reachable address space).  That is, the ITR functions are found in
internal routers and/or in border routers.  With basic LISP,
20.0.0.0/20 is not advertised in BGP, so if a packet is sent to
20.0.0.5 from a host in a non-upgraded network the packet is dropped
in that network - it never gets out the border router.

There are two more promising options, as far as I know, for LISP
(other than adopting "anycast ITRs in the core" - and there's no
reason I know of why this couldn't be adopted):

1 - 20.0.0.0/20 is still advertised in BGP, by a single border
    router of some network L.  This router is an ITR.

2 - 20.0.0.0/20 is still advertised in BGP, by a single border
    router of some network L.  This router is a not an ITR.

In the former case, all packets sent from any network in the world
to any address in 20.0.0.0/20 will either find their way to an ITR
in their originating network, or will be sent out of the border
router (from a non-LISP-upgraded network) and arrive at the ITR,
where they will be tunneled to wherever they should go.  The
problems with this are mainly the possibility of longer path
lengths.  If the sender is in Düsseldorf, the ITR is in Japan and
the ETR is in  Cologne, then the path length is terribly
sub-optimal.  There are also single-point of failure problems due to
all hosts in non-upgraded networks relying on this one ITR for their
connectivity to the LISP-mapped hosts using the 20.0.0.0/20 addresses.

However, in principle, it should work.  As with Ivip, it only really
helps with reducing the BGP routing table size if there are, as a
result of LISP-mapping, more end-users using this space than was
possible with ordinary BGP.

If each prefix which is LISP-mapped and remains advertised like this
only supports as many users as it does today, then I think little
will be achieved, except for a reduction in BGP changes and whatever
benefits of finer control of multihoming, and TE LISP brings
compared to BGP.

Ivip is intended to be used in a different way from this "BYO
prefix" model.  There are supposed to be fairly large subnets (short
prefixes) assigned to Ivip, with lots more separate end-users making
use of this prefix than would be possible with current BGP techniques.

In the second case, the packets from non-upgraded networks arrive at
some network L, but the router there is not an ITR so it can't get
the packets to a destination host if that host is no longer part of
network L.  Therefore there is this mixed up state of some packets
being portable and multihomable to any ETR in any network and some
just arriving at network L.

So I don't respond to the rest of the message because I think it is
based on some notion I don't understand involving two prefixes at once.

  - Robin

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Aug 2007 19:24:42 +0200

Hi Robin,

Please see below.

> However, in principle, it should work.

I think I would handle this differently.  Prior to withdrawing 
20.0.0.0/20 there should be a reasonable number of ITRs in SP 
environments.  At that point it makes sense for those to at least 
locally propagate a NOEXPORT route along the lines of 20.0.0.0/8.  One 
could go further and say that it should be a 0.0.0.0/1 and 128.0.0.0/1.  
At that point you can have multiple ITRs doing this for redundancy's 
sake, and you're doing it with very few routes.  Maybe 200-300 at most.

Eliot

---

From: Christian Vogt <[email-masked]>
Date: Tue, 07 Aug 2007 20:47:10 +0300

Robin:

> eFIT-APT or Ivip mapping system. [...]

There is an issue in this case as well:  If the host in the LISP-enabled
network uses a mapped IP source address for the outgoing packet, the
correspondent host in the legacy network won't be able to respond.

It is unclear how one could make the sending host select a mapped IP
source address for a packet if and only if the recipient correspondent
host, too, sits in a LISP-enabled network.  Two reasons:

(1)  The sending host does not know whether or not the correspondent
host's network is LISP-enabled.

(2)  IP source address selection would not behave as needed even if the
sending host was aware of the correspondent host's network's LISP status
-- given that the sending host is supposed to be unmodified.

It may be possible to fix this by having the ITR of the sending host act
as a classic NAT box.  The cost is a loss of end-to-end semantics.  Many
customers don't like this, providing another deployment disincentive.

> ITR to an ITR so it can be tunneled to whatever ETR is required.

Right, here the problem is selection of the right IP destination address
by the host in the legacy network.  The above-mentioned issues (1) and
(2) apply here as well -- replacing "source" by "destination" in (2).

In order to avoid breaking communications between LISP and non-LISP
networks, one option would be to order IP addresses in DNS replies such
that non-mapped addresses are first and mapped addresses are second.
However, the negative consequence of this would be that non-mapped
addresses would likely be selected even in the case were LISP was
deployed on both ends of a connection.

> connectivity to the LISP-mapped hosts using the 20.0.0.0/20 addresses.

Robin, one main purpose of multi-homing is to avoid a dependency on a
single provider.  The provider with the ITR in your example is a single
point of failure, which is exactly what multi-homing tries to avoid.

Morerover, if I understand you correctly, in your example you would
advertise a provider-independent edge network prefix in BGP.  So there
also wouldn't be an advantage in terms of reduced routing table load.

Please clarify if I did not understand you correctly.

- Christian

---

From: Robin Whittle <[email-masked]>
Date: Thu, 09 Aug 2007 11:29:25 +1000

Hi Christian,

> correspondent host in the legacy network won't be able to respond.

I think this is the same problem viewed from a different place.

If a host H1 in a non-upgraded network ISP-A can't send a packet to
a host H2 in ISP-B because H2 is using a LISP-mapped address, and
ISP-A has no ITR, then there is a problem: H1 cannot initiate or
maintain communications with H2.

What you are discussing, I think, is that H2 can send packets to H1,
but won't get a reply.

Clearly it would be unacceptable to introduce a new architecture
which was so disruptive.

The only solution is to either add things to LISP so it maintains
full reachability, or to get some other architecture which naturally
maintains it - such as Ivip.

I snipped a bunch of what you wrote, because it was complex attempts
at workarounds for a problem which I think should never be allowed
in the first place.

> point of failure, which is exactly what multi-homing tries to avoid.

I agree these are lousy approaches.

I was not discussing Ivip - I was discussing my understanding of two
ways LISP could be adapted to achieve reachability from non-upgraded
networks, while still being different from the way I think is best:
Ivip's "anycast ITRs in the core".

> Please clarify if I did not understand you correctly.

I have tried to explain this a number of times, but here goes again.

This is mentioned in the I-D:

  http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html

     Ivip's capacity to reduce the growth on the BGP routing table
     and to enable the efficient use of IPv4 space by giving
     end-users precisely the number of addresses they need - not
     256, 512, 1024 etc. addresses - rests on the RIRs developing an
     address management policy for Ivip-mapped address space which
     generally ensures that large blocks of addresses are assigned
     to the Ivip system, with each block being used to serve the
     needs of many end-users. It should not be difficult to develop
     implement such policies.

If either LISP/eFIT-APT or Ivip worked in the way I think you
suggest (one end-user per BGP advertised prefix which is dedicated
to the ITR-ETR mapping system), which I call "BYO address space",
then nothing much would be achieved in terms of reducing the number
of advertised prefixes.  There would be benefits for the end-user,
and there would be no updates in BGP for this prefix.

"BYO address space" means that for any end-user who uses mapped
addresses, they bring their own PI space to the mapping system and
by not let anyone else use it.

LISP, eFIT-APT and Ivip could be used this way - but it is not the
way I intend Ivip to be used.  Alternatively they could be used like
this:

Maybe I will call this the "Two or many more peas in a pod" approach:

The prefixes which are advertised and controlled by the LISP/Ivip
etc. mapping system are big enough to serve the needs of multiple
end-users.  These prefixes might not be usable by more than one
end-user now, with current BGP-based approaches to address
management.  With any of these ITR-ETR tunnelling and mapping
schemes (LISP/eFIT-APT or Ivip), the space can be divided down as
finely as desired, including into individual IP addresses.

If every end-user who needs portability and multihoming always
required a minimum of 256 IPv4 addresses, and had genuine needs
which always existed in multiples of 256 addresses, then there would
be little to be gained from using LISP, eFIT-APT and Ivip to slice
and dice the address space.

However, I am sure that some - probably many - end-users ("end-user"
in this message means those who need multihoming, portability, TE
etc.) don't need as much as 256 addresses.  Therefore all these
schemes - LISP, eFIT-APT and Ivip - enable more end-users to use a
/24 or a /23 than is possible today with BGP's clunky 256 address
resolution.  (This /24 limit is not fixed in the protocol - but by a
general practice of filtering advertisements to be for prefixes no
longer than 24.)

Ivip could probably slice and dice finer, because I intend it have
arbitrary ranges of address space given the same mapping, not binary
boundary prefixes like LISP and eFIT-APT.

Apart from that detail, LISP, eFIT-APT and Ivip could all be used
just as well to get more use out of a given amount of IPv4 address
space.

This greater usage of IPv4 space is not an explicit goal of LISP or
eFIT-APT, but it is of Ivip.

So the fact that Ivip has one prefix in the global routing table for
20.0.0.0/20 is not such a problem, as long as it is supporting two
or more end-users who otherwise would need to get PI space and
advertise it in BGP.   Clearly, the bigger the subnet (shorter the
prefix), of each Ivip-Mapped Address Block (IMAB), the more
end-users can be in it and the more savings there will be for the
global routing table.

If two separate end-users brought contiguous IMAB blocks (PI space
they had been assigned by an RIR) to Ivip:

  20.0.0.0/20
  20.0.16.0/20

and if they agreed for the mapping of their space to be mapped by
the one Root Update Authorisation System (RUAS), then database dumps
and update streams for the two could be handled as one.  Then all
the ITRs could advertise the two as a single IMAB:

  20.0.0.0/19

and this would reduce the number of advertised prefixes by one.

Ideally, Ivip or whatever would be launched with an RIR or some
large, stable, multi-party organisation (one that is not going to go
out of business) running a RUAS and having a whole slab of fresh
address space, such as a /8, to use for tens or hundreds of
thousands of multihoming and/or portability requiring end-users.

However, by the time this system is running, all that space will
probably be gone.  I recently floated the idea of saving a few /8s
for Ivip etc. on the RIPE Address Policy mailing list and it was not
hugely popular . . .

Ivip should enable such improved use of IP address space including
for mobility, that I reckon there could be profitable businesses
running their own independent Ivip systems, with ITR/TTRs all over
the Net, renting out IP addresses for mobility and multihoming.
Alternatively, there could be a global Ivip system with multiple
RUASes, each controlling various amounts of address space, either
that they have been assigned themselves by an RIR or which someone
else has allowed them to use.

All this is going to require RIR approval anyway, but there should
be no problems because it enables multihoming, more end-users etc.
without burdening BGP (except for there being one prefix per IMAB,
which is relatively stably advertised by ITRs all over the Net).

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Aug 2007 17:53:07 +0300

Joel,

#email catchup mode on
> That would give significant benefit without losing connectivity from

Yes -- but that still begs the question of what drives the removal
of information from BGP. Presumably there must be some
advantage to the new model (better TE, better resiliency
in network failures). So this translates to a disadvantage
to the old system, assuming only an aggregated
reachability is advertised. Why would I as an end-site
want to advertise less in BGP? There is no push-back
or cost involved in that, not for me at least...

Jari

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Aug 2007 08:47:37 -0700

Jari,
> or cost involved in that, not for me at least...

I think a direct benefit of LISP is that one can make use of PI address 
space without having to participate in BGP.  This is the win for 
enterprises.  That's only a benefit, of course, if the RIRs strongly 
encourage use of PA space.  It also means that SPs have to support such 
an allocation policy.  This is something to think about as we go a bit 
further down the road.

Eliot

---

From: Lars Westberg <[email-masked]>
Date: Thu, 23 Aug 2007 08:50:14 +0200

hi, 
I am new but I think it is an interesting discussion. some questions.

Isn't the current BGP too complicated already ?
Shouldn't the target be to reduce it ?

It sound simpler to have separated protocols rather that extend BGP.

regards Lasse

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Aug 2007 08:59:17 +0200

On 2007-08-22 16:53, Jari Arkko wrote:

...
> Why would I as an end-site

ISP pricing models could fix that, if the ISPs
can clearly see a cost advantage to them in
reducing BGP size.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Aug 2007 10:06:16 +0300

Brian,

> can clearly see a cost advantage to them in

Yes, but the issue is that we need to understand
that a new ISP pricing model is needed as a part
of the solution. (And, if we had that... would we
be where we are now?)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Aug 2007 10:43:56 +0300

Hi Lasse,

> It sound simpler to have separated protocols rather that extend BGP.

The routing system has to be as complex as is needed to
get the job done, but not more complex than that. I'm
not sure I want to say anything about how well we are
doing in this respect today :-)

Anyway, what majority of proposals on the table do is to introduce
some modularity into the system. The routing in the core
of the Internet would be handled by a something resembling
the current BGP, but hopefully requiring smaller amount
of data and less features. The remaining part of the routing
problem would be handled as an additional task in some
subset of routers, e.g., on network edges. For those routers
complexity increases, but complexity and other pain is
reduced on the rest.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Aug 2007 11:53:26 +0300

Eliot,

> I think a direct benefit of LISP is that one can make use of PI
> address space without having to participate in BGP.  This is the win
> for enterprises.  That's only a benefit, of course, if the RIRs
> strongly encourage use of PA space.  It also means that SPs have to
> support such an allocation policy.  This is something to think about
> as we go a bit further down the road.

No argument there. But the question is how can we
simultaneously (a) get the benefit, such as not having
to do BGP, and (b) still be connected to the rest of the
world that did not upgrade yet.

Jari

---

From: "Lars Westberg (KI/EAB)" <[email-masked]>
Date: Thu, 23 Aug 2007 12:03:44 +0200

I don't understand your statement. 

We have an engieering choice to select different protocols to solve
different probelms. The general statement that about development of
"christmas-tree" protocols applies as well to the routing system. 
 
I think we should consider to develop an modularity in the architecture.

Regards Lasse

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: den 23 augusti 2007 09:44
> To: Lars Westberg (KI/EAB)
> Cc: Joel M. Halpern; RRG Mailing List
> Subject: Re: [RRG] On the Transitionability of LISP
> 
> Hi Lasse,
> 
> The routing system has to be as complex as is needed to get 
> the job done, but not more complex than that. I'm not sure I 
> want to say anything about how well we are doing in this 
> respect today :-)
> 
> Anyway, what majority of proposals on the table do is to 
> introduce some modularity into the system. The routing in the 
> core of the Internet would be handled by a something 
> resembling the current BGP, but hopefully requiring smaller 
> amount of data and less features. The remaining part of the 
> routing problem would be handled as an additional task in 
> some subset of routers, e.g., on network edges. For those 
> routers complexity increases, but complexity and other pain 
> is reduced on the rest.
> 
> Jari
> 
>

---

From: András Császár (IJ/ETH) <[email-masked]>
Date: Thu, 23 Aug 2007 17:37:18 +0200

> * Mobile IPv4 or IPv6 hosts making use of Ivip will need new host

Hmmm, that made me think. Drawing such a table is a VERY good idea, and we could extend it with a lot of other rows (goals) and columns (solutions), and also other solutions. One solution that should be shown in the table  is the use of PI addresses. Which then automatically generates a row for scalable routing tables.

And some people raised the issue that ISPs are advertising more specifics just for doing inbound TE or to prevent prefix hijacking. Do any of the solutions address these?

And there are a lot more.

I have quite a long list of possible goals in my head. I'll try to write them down until tomorrow grouped by goals of end-user/enterprise networks; ISPs; router vendors :-), along with how I think they are solved today.

András

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Aug 2007 08:40:51 -0700

Jari,
> world that did not upgrade yet.

Well stated.  I think I wrote a note to RAM about this some time ago, 
and we have ponderings in this space that involve the use of aggregate 
announcements that originate from ITRs.  I am told that this is not 
unlike Robin's work.  The work here is nascent.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Aug 2007 09:01:09 +0200

>> * Mobile IPv4 or IPv6 hosts making use of Ivip will need new host

BTW I forgot to comment that
(a) shim6 doesn't explicitly support mobility, but it can function
in a mobile (e.g. MIP6) host.

(b) the list lacks a row for TE.

(c) IMHO address "portability" is a bogus criterion, since a solution
that doesn't require portability shouldn't be measured against it.

    Brian

---

From: András Császár (IJ/ETH) <[email-masked]>
Date: Fri, 24 Aug 2007 17:18:27 +0200

Pj4+ICAgICAgICAgICAgICBTSElNNiAgU2l4LyAgTW9iaWxlICBMSVNQLSAgIExJU1AtICAgZUZJVC0gIEl2aXANCj4+PiAgICAgICAgICAgICAgICAgICAgIE9uZSAgIElQdjYgICAgTkVSRCAgICBDT05TICAgIEFQVA0KPj4+IA0KPj4+IEFkZHJlc3MNCj4+PiBwb3J0YWJpbGl0eSAgICAgICAgICAgICAgICAgICAgICAgWSAgICAgICBZICAgICAgIFkgICAgICBZDQo+Pj4gDQo+Pj4gTXVsdGlob21pbmcgICBZICAgICBZICAgICAgICAgICAgIFkgICAgICAgWSAgICAgICBZICAgICAgWQ0KPj4+IA0KPj4+IE1vYmlsaXR5ICAgICAgICAgICAgICAgICAgWSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFkqDQo+Pj4gDQo+Pj4gSVB2NCB0b28gICAgICAgICAgICAgICAgICAgICAgICAgIFkgICAgICAgWSAgICAgICBZICAgICAgWQ0KPj4+IA0KPj4+IE5vIGhvc3QgICAgICAgICAgICAgICAgICAgICAgICAgICBZICAgICAgIFkgICAgICAgWSAgICAgIFkqIGNoYW5nZXMNCj4+PiANCj4+PiAqIE1vYmlsZSBJUHY0IG9yIElQdjYgaG9zdHMgbWFraW5nIHVzZSBvZiBJdmlwIHdpbGwgbmVlZCBuZXcgaG9zdA0KDQpIaSENCg0KSSB0aGluayB3ZSBzaG91bGQgZnVydGhlciBncm93IHRoZSB0YWJsZS4NCg0KSW4gdGhlIGFib3ZlIHRhYmxlIHRoZSByb3dzIGFyZSBzb21ldGhpbmcgbGlrZSBnb2FscyAoY2hhbGxhbmdlcykgYW5kIGNvbmRpdGlvbnMsIGFuZCB0aGUgY29sdW1ucyBhcmUgbW9yZSBvciBsZXNzIG5ld2x5IHByb3Bvc2VkIHNvbHV0aW9ucy4NCg0KSSB3b3VsZCBmaW5kIGl0IGludGVyZXN0aW5nLCBpZiB3ZSBjb3VsZCBoYXZlIGEgYmlnIHRhYmxlIGluIHNvbWUgb25saW5lIGNvbGxhYm9yYXRpdmUgc3ByZWFkc2hlZXQgYXBwbGljYXRpb24gd2hlcmUgd2UgY291bGQgYWRkIGFsbCBvdGhlciBnb2Fscy9jb25kaXRpb25zLCBhbmQgYWxzbyB0aGUgc29sdXRpb25zIHVzZWQgdG9kYXkgZm9yIHRoZSBkaWZmZXJlbnQgcHJvYmxlbXMhIFdvdWxkIHRoZXJlIGJlIGludGVyZXN0IGluIGNyZWF0aW5nIHN1Y2ggYSBiaWcgdGFibGUgaW4gY29sbGFib3JhdGlvbj8gV2UgY291bGQgZG8gaXQgd2l0aCBHb29nbGUgU3ByZWFkc2hlZXQgYnV0IHRoYXQgY2FuIGJlIGFjY2Vzc2VkIG9ubHkgd2l0aCBhIEdvb2dsZSBhY2NvdW50LiBJcyB0aGVyZSBzb21lIG90aGVyIHRvb2w/IE9yIGRvZXMgZXZlcnlvbmUgaGF2ZSBhIEdvb2dsZSBhY2NvdW50PyA7LSkNCg0KQW55d2F5LCByZWdhcmRpbmcgdGhlIGdvYWxzLCBJIHRoaW5rIHdlIGNhbiBncm91cCBnb2FscyBhcyBlbmQtdXNlci9lbnRlcnByaXNlIG5ldHdvcmsgZ29hbHMgYW5kIHRoZSBnb2FscyBvZiBwcm92aWRlcnMgKElTUHMpLiBTbywgaGVyZSBpcyBhIGxpc3QgZm9yIGEgc2hvb3Qtb3V0IDotKSAoaW4gYnJhY2tldCB0aGUgc29sdXRpb24gdXNlZCB0b2RheSkNCg0KRW5kLXVzZXIvRW50ZXJwcmlzZSBuZXR3b3JrIGdvYWxzOg0KLSBIb3N0IG11bHRpLWhvbWluZyAoYXBwbGljYXRpb25zIHJlY29ubmVjdCAtIG5vIHNlc3Npb24gY29udGludWl0eSwgYnV0IHdobyBjYXJlcy4uLikNCi0gUHJvcGVyIGVuZC10by1lbmQgcGF0aCBzZWxlY3Rpb24gZm9yIGFwcHJvcHJpYXRlIHNlcnZpY2UgbGV2ZWwgcGVyIGFwcGxpY2F0aW9uL3BlciBmbG93ICh4KQ0KLSBBdm9pZCBvciBlYXN5IHJlbnVtYmVyaW5nIHdoZW4gY2hhbmdpbmcgSVNQIChQSSBhZGRyZXNzZXMsIG9yIFBBIGFkZHJlc3NlcyB3aXRoIERIQ1AgcmVjb25maWd1cmF0aW9uKQ0KLSBTaXRlIG11bHRpLWhvbWluZyB3aXRoICJwcm9wZXIiIFRFICh4IC0gb2YgY291cnNlIHNpdGUtbXVsdGlob21pbmcgZm9yIHJlc2lsaWVuY3kgaXMgZWFzeSkNCi0gTW9iaWxpdHkgZm9yIHRoZSBob3N0IChMMiBzb2x1dGlvbnMgYW5kIE1JUCwgUE1JUCBpbiBMMykNCi0gUHJpdmFjeSBvZiB0cmFuc3BvcnQsIHByb3RlY3RlZCBhZGRyZXNzZXMgKEZpcmV3YWxsLCBJUFNlYykNCg0KRW5kLXVzZXIvRW50ZXJwcmlzZSBuZXR3b3JrcycgZXhwZWN0ZWQgcHJvcGVydGllcyBvZiBhbnkgc29sdXRpb246DQotIE5vIGhvc3QgY2hhbmdlcw0KLSBObyBvciBlYXN5IHRvIHVwZ3JhZGUgQ0UgY3VzdG9tZXIgZWRnZSByb3V0ZXIgY2hhbmdlcw0KLSBCYWNrd2FyZCBjb21wYXRpYmlsaXR5IChpLmUuIGFiaWxpdHkgdG8gY29tbXVuaWNhdGUpIHdpdGggc2l0ZXMvZW5kLWhvc3RzIG5vdCBoYXZpbmcgdGhlIGltcHJvdmVtZW50DQotIElQdjQmdjYgc3VwcG9ydA0KDQoNClByb3ZpZGVyKElTUHMsVGllci14IHByb3ZpZGVyKSBnb2FsczoNCi0gU3VwcG9ydCBvZiBhbGwgYWJvdmUgZW50ZXJwcmlzZSBnb2FscyAtIGUuZy4gaW4gdGhlIGZvcm0gb2YgYSBzZXJ2aWNlDQotIFNjYWxhYmxlIHJvdXRpbmcgKHgpDQotIFByb3BlciBUcmFmZmljIEVuZ2luZWVyaW5nIChvbmx5IHdoYXQgQkdQIE1FRCBhbmQgQkdQIHRyaWNrcyBvZmZlcikNCi0gU2ltcGxlciBtYW5hZ2VtZW50IChjZW50cmFsaXNlZCBtZ210IHN5c3RlbXMgZm9yIHJlbW90ZS9hdXRvIGNvbmZpZ3VyYXRpb24/KQ0KLSBTY2FsYWJsZSBWUE4gc3VwcG9ydCAoTDJWUE4gYW5kIEwzVlBOIHNvbHV0aW9ucywgbW9zdCByZXF1aXJlIE1QTFMgYXQgbGVhc3QgaW4gdGhlIFBFIHJvdXRlcikNCi0gRWFzeSBpbnRlci0vaW50cmFkb21haW4gbXVsdGljYXN0IHN1cHBvcnQgKD8gLSBpcyB0b2RheSdzIG11bHRpY2FzdCBnb29kIGVub3VnaD8pDQoNClByb3ZpZGVycycgKElTUHMsVGllci14IHByb3ZpZGVyKSBleHBlY3RlZCBwcm9wZXJ0aWVzIG9mIGFueSBzb2x1dGlvbjoNCi0gRWFzaWx5IG1hbmFnYWJsZSANCi0gTm8gb3IgZWFzeSB0byB1cGdyYWRlIGFuZCBjaGVhcCBwcm92aWRlciByb3V0ZXIgY2hhbmdlcw0KLSBJUHY0JnY2IGNvbXBhdGlibGUNCg0KDQpSb3V0ZXIgdmVuZG9yIGdvYWxzOg0KLSBTdXBwb3J0IG9mIGFib3ZlIElTUCBnb2Fscw0KDQpSb3V0ZXIgdmVuZG9ycycgZXhwZWN0ZWQgcHJvcGVydGllcyBvZiBhbnkgc29sdXRpb246DQotIEJpZyByb3V0aW5nIHRhYmxlIG9yIGxvdCBvZiBkaWZmZXJlbnQgbmV3IGZlYXR1cmVzIDstKQ0KDQoNCkNhbiB3ZSBleHRlbmQgb3IgcmVwYWlyIHRoaXMgbGlzdD8gQW5kIG1hdGNoIHRoZSBwcm9wb3NlZCBzb2x1dGlvbnMgYW5kIHRoZSBleGlzdGluZyBvbmVzIHRvIGVhY2ggYXNwZWN0Pw0KDQpSZWdhcmRzLA0KQW5kcsOhcw0K--to unsubscribe send a message to [email-masked] with theword 'unsubscribe' in a single line as the message text body.archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg