Re: [rrg] Proposals which match rrgarchitectures.html pls checkthepage

MARCELO BAGNULO BRAUN <marcelo@it.uc3m.es> Sun, 04 January 2009 13:54 UTC

Return-Path: <rrg-bounces@irtf.org>
X-Original-To: rrg-archive@ietf.org
Delivered-To: ietfarch-rrg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E5428C0E1; Sun, 4 Jan 2009 05:54:27 -0800 (PST)
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D290F3A6951 for <rrg@core3.amsl.com>; Sun, 4 Jan 2009 05:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level:
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=-1.349, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR04-ZKBDu2r for <rrg@core3.amsl.com>; Sun, 4 Jan 2009 05:54:26 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 9ABCD3A69FB for <rrg@irtf.org>; Sun, 4 Jan 2009 05:54:25 -0800 (PST)
Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp03.uc3m.es (Postfix) with ESMTP id 1DC0472B651;Sun, 4 Jan 2009 14:54:10 +0100 (CET)
Received: from r190-132-74-108.dialup.mobile.ancel.net.uy(r190-132-74-108.dialup.mobile.an cel.net.uy [190.132.74.108]) bywebcartero01.uc3m.es (Horde MIME library) with HTTP; Sun, 04 Jan 200914:54:08 +0100
Message-ID: <20090104145408.q0i0wpgtck48kssg@webcartero01.uc3m.es>
Date: Sun, 04 Jan 2009 14:54:08 +0100
From: MARCELO BAGNULO BRAUN <marcelo@it.uc3m.es>
To: Robin Whittle <rw@firstpr.com.au>
References: <4959B44C.2030709@firstpr.com.au><885A118B-76C8-4E8D-91C0-7C5C69 96784F@cs.colostate.edu><4959C284.4060805@firstpr.com.au><1230690036.5700.7 .camel@localhost><3c3e3fca0812301907y2feb8904r410845562929a8ed@mail.gmail .com><1230720711.5901.25.camel@localhost><495EF3B1.1030408@firstpr.com.au> <20090103121825.co8r3bgpwkwwggk4@webcartero01.uc3m.es><495F770C.4070004@firstpr.com.au>
In-Reply-To: <495F770C.4070004@firstpr.com.au>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.0.4)
X-imss-version: 2.051
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-14.0263 TC:1F TRN:65 TV:5.5.1026(16380.007)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Cc: rrg@irtf.org, Randall Atkinson <rja@extremenetworks.com>
Subject: Re: [rrg] Proposals which match rrgarchitectures.html pls checkthepage
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/pipermail/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: rrg-bounces@irtf.org
Errors-To: rrg-bounces@irtf.org

Robin Whittle <rw@firstpr.com.au> dijo:

> 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.)
>

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

>  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.
>

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
>      using SHIM6.
>

I don't understand this one

>  4 - Need for both hosts to support Shim6, when it is still being
>      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

>
>> 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?
>

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

> 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?
>

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

>
>> Finally, there are tons of geo aggregation proposals, since Deering's
>> 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
>



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

_______________________________________________
rrg mailing list
rrg@irtf.org
https://www.irtf.org/mailman/listinfo/rrg