Subject: Re: [rrg] Proposals which match rrgarchitectures.html pls check the page

From: Robin Whittle <[email-masked]>
Date: Sat, 03 Jan 2009 16:12:17 +1100

Here is a page:

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

in which I attempt to match proposals to Bill's Summary of architectures:

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

Please let me know via the list of any suggestions for improving this.

  - Robin

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Sat, 03 Jan 2009 12:18:25 +0100

In the page you mention:

Strategy B
This is the elimination class of proposals.  Any such proposal requires 
new host functions, including changes to host stacks, APIs and 
applications.  Strategy B solutions do not not require changes to the 
interdomain routing system or to the rest of the network, except 
perhaps improvements to DNS.

No-one is suggesting such a solution for IPv4 - they are all 
modifications to IPv6.  This is due, in part, to the lack of IPv4 
address space required for this technique, in which each multihomed 
end-user network has a block of space from each upstream ISP, of the 
same size as its network's address space.

ILNP is one such proposal, I think.  HIP may be another.  However 
neither of these is fully documented as a solution to the routing 
scaling problem.

SHIM6 may match this class, but it does not provide proper multihoming, 
with ease of choosing a new ISP, as we are trying to achieve with a 
scalable routing solution.

MB> Shim6 does not requires changes in the APIs nor in the 
applications. So under the definition included in the page, SHIM6 is 
not a strategy B proposal.. Second, i certainly don't agree with the 
statement that shim6 does not provides multihoming.
In addition, i think ProxyShim6 is likely to fit in a strategy B proposal.
Finally, there are tons of geo aggregation proposals, since Deering's 
metro addressing, IXP based addressing, Iljitsch geo addressing.

Regards, marcelo

-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid

---

From: Robin Whittle <[email-masked]>
Date: Sun, 04 Jan 2009 01:32:44 +1100

Short version:     I need help in deciding which existing proposals
                   (including those not really discussed much in the
                   RRG) - if any - fit Strategy B.

                   Is ProxyShim6 a scalable routing proposal?  If so
                   does it really fit Strategy B, or is a new
                   classification needed?

Hi Marcelo,

Thanks very much for this:

> Shim6 does not requires changes in the APIs nor in the applications.
> So under the definition included in the page, SHIM6 is not a strategy B
> proposal.. Second, i certainly don't agree with the statement that shim6
> does not provides multihoming.

OK - I agree.  Perhaps the objections to Shim6 in terms of it being a
scalable routing solution, in addition to it not being helpful for
IPv4, include:

  1 - It is host-based rather than router based.  (Questions of
      where it is implemented and where it is controlled and
      monitored from.)

  2 - It provides no portability - networks still need to renumber
      when choosing a new ISP.  Renumbering is still disruptive
      and expensive, including due to the appearance of IP addresses
      in various places inside and outside the network which are not
      amenable to secure automatic changes.

  3 - Problems with maintaining ACLs in other networks for hosts
      using SHIM6.

  4 - Need for both hosts to support Shim6, when it is still being
      developed and is not widely deployed.

> In addition, i think ProxyShim6 is likely to fit in a strategy B proposal.

Ahh, I see that your I-D:

  http://tools.ietf.org/html/draft-bagnulo-pshim6-02

includes a list of problems with Shim6 which mentions points 1 and 2
above.

A quick scan of the I-D makes me think that it doesn't match Bill's
text:

   "GUID to LOC maps are pushed from the host towards a distributed
    registry as they change. Hosts request and temporarily cache
    individual mappings from the registry as needed."?

Are you suggesting that ProxyShim6 is, or is an important part of, a
solution to the IPv6 routing scaling problem?

If so, then I suggest it would be good to write up a summary and
analysis document and add a link to it from the RRG wiki.  (See:
http://psg.com/lists/rrg/2007/msg00908.html .)  Also, does it really
fit Strategy B or should Bill make a new strategy to match it?

> metro addressing, IXP based addressing, Iljitsch geo addressing.

I have updated the page from version 00 to 01.  The start of the page
tells how to see the older versions.  At the end of the page is a
Loose Ends and Discussion section.

Here are the changes:

Deleted this mention of SHIM6 from Strategy B and retained its
mention in Strategy G.

Added to the Loose Ends and Discussion section some queries about
whether ILNP or HIP really match Bill's description.  For instance,
do they involve a mapping system, to match: "GUID to LOC maps are
pushed from the host towards a distributed registry as they change.
Hosts request and temporarily cache individual mappings from the
registry as needed."?

Linked to this message regarding the status of ProxyShim6.

  - Robin

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Sun, 04 Jan 2009 14:54:08 +0100

>      where it is implemented and where it is controlled and

I don't see this as a problem, but i guess there has already been 
enough debeate about this...

>      amenable to secure automatic changes.

Shim6 supports PI identfiiers and uses PA locators, as i guess any 
other ID/loc solution that aims to deal with the routing system 
scalability
The PA locators are visible in the end nodes in end host based shim6 
and are visible in the proxy in the proxy shim6, whcih would reduce 
ever further the renumbering burden.

>  3 - Problems with maintaining ACLs in other networks for hosts

I don't understand this one

>      developed and is not widely deployed.

I guess most of the solutions requires that some device near the other 
end supports the new protocol. The support in the other end in shim6 
can be in the end host itself or in the proxy shim6 box located in the 
target network, or in the target ISP

> solution to the IPv6 routing scaling problem?

PA addressing is a solution fo rthe routing scalability problem
Shim6 or proxy shim6 are means to fix what the usage of PA addressing breaks

> fit Strategy B or should Bill make a new strategy to match it?

mmm, my goal here is just to clarify what i think are misunderstandings 
about shim6
I am certainly not trying to push shim6 nor proxy shim6 here.

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Jan 2009 09:08:07 +1300

> I don't understand this one 

Isn't this in fact a (perceived) problem with the multi-prefix
model? If an endpoint has multiple locators, then any site that
puts one of those locators in an ACL needs to put all of them
in the ACL. So if you want to put somehost.example.net in an
ACL, you need to look up all its A/AAAA records and put all the
results in the ACL. I don't think this has anything to do with
shim6.

   Brian

---

From: "William Herrin" <[email-masked]>
Date: Sun, 4 Jan 2009 22:44:56 -0500

>> I don't understand this one

Marcello,

Shim6 has several weaknesses that can be revealed by comparing it to
the Strategy B criteria. This particular weakness is the lack of
accompanying dynamic source routing protocol.

Unless the IGP in a stratgy B system moves packets first to a valid
exit for the source address and only then to the optimal exit for the
destination address, you end up with a nasty spoofing problem where
routers require extensive manual configuration to tell the difference
between a spoofed source address and a valid multiprefix source
address.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 05 Jan 2009 12:01:04 +0100

> between a spoofed source address and a valid multiprefix source

but this is not specific to shim6, but it is s general problem of 
configuring multiple PA blocks from multiple ISPs that are performing 
ingress filtering.
I mean, if you don't have shim6 and you configure multiple PA prefixes, 
you end up in the same problem.
We have tried to address this problem in the shim6 wg, but the guidance 
was that this was a general problem that was to be addressed in general 
for IPv6, which hasn't been addressed yet

Also, note that Proxy Shim6 does not suffers from this problem, since 
the proxy rewrites the source address and can make it compliant with 
the filters

Regards, marcelo

---

From: Scott Brim <[email-masked]>
Date: Mon, 5 Jan 2009 08:36:14 -0500

Excerpts from Dan Jen at 18:20:36 -0800 on Tue 30 Dec 2008:
> None of the A2s fit APT exactly.

Let's get away from trying to compare entire _packages_ and instead
look at functional components.  Whether APT fits a particular approach
isn't as important as whether APT's pieces do.  When we know which
approaches we prefer, we select building blocks to put them together.
Let's not get trapped arguing about packages.

Scott (back at work)

---

From: Robin Whittle <[email-masked]>
Date: Tue, 06 Jan 2009 01:13:05 +1100

Hi Scott,

> Let's not get trapped arguing about packages.

While I think it is interesting to break down a proposal into it's
various distinctive functional blocks - especially when contemplating
how to improve this or other proposals - ultimately, I believe it
will be complete, carefully designed, proposals which have the best
chance of solving the scaling problem.

It is no good trying to build a car from a collection of GM and Ford
parts - they will never fit together as well as a car made with a
unified design, so all the components are combined to maximise
synergy between the various sub-systems.

I think it is valuable that Bill's page attempts to identify
commonalities and distinctions between the various approaches to
designing a new architecture.

An important test of Bill's taxonomy of architectural design
approaches is whether all the major, real, live proposals actually
fit clearly within it.

If Bill's page isn't updated to the point where the designers of APT
and ILNP are happy that there is a place in the taxonomy for their
designs, then I think the taxonomy would be only a loose and somewhat
misleading account of the actual design choices which are available.

I think it would be best if the designers suggest changes to Bill's
taxonomy - specific words to modify the current Strategies, or to
create new ones.  I did this with Ivip, and Bill used a subset of
what I suggested.

While the taxonomy doesn't consider a number of architectural aspects
which I think are important distinctions between Ivip and other
proposals, at least Ivip has a place in Bill's taxonomy, as does
LISP-ALT, TRRP and LISP-NERD.

 - Robin