Re: [RRG] GSE?

"Mayutan A." <mayutan.arumaithurai@gmail.com> Wed, 11 June 2008 14:48 UTC

Envelope-to: rrg-data@psg.com
Delivery-date: Wed, 11 Jun 2008 14:50:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=6L4Oig1qQMB2DjzT6olGliAZqBahLMnpPAm6v3+JQXU=; b=Dxx50FtLyPgrcrO6QO/egwfvjR+EDk/tT+q7IO0r7EqDZ+DsYV3uDdT+oR+vkv34EX +GlfGWb3SxTWkUS6BWgkZgEhxXnd1RjYihBp91BMleuJr72ZIg8eQNVnZdb5524mq92K GUpfnHr6kdVCTSu4t9yaQb9XC0R0uVQyK2CJ4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=p1KZxFLOWLJxyAJMOM5jPapLbjH6r9ZQt7VHRqn0Wjd0T8tBV5SWUxnG0IxCSEgaG/ 6k1tjlaPXv+sb4Idkau87I6gEH6OFDQJQzTKvYCReBKggh3sw0VwNMDE5t8Hfss3RTNh pVpwrCflR0muga3tyUmBScZknO8y2G44WkoAo=
Message-ID: <f18355b80806110748s8a4d21eq65d03994287a194e@mail.gmail.com>
Date: Wed, 11 Jun 2008 16:48:01 +0200
From: "Mayutan A." <mayutan.arumaithurai@gmail.com>
To: Robin Whittle <rw@firstpr.com.au>
Subject: Re: [RRG] GSE?
Cc: Routing Research Group <rrg@psg.com>, tony.li@tony.li
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_24344_20102335.1213195681243"

Hi,

Isn't the Six-One proposal by Christian Vogt an enhancement of the GSE.
http://www.watersprings.org/pub/id/draft-vogt-rrg-six-one-01.txt

Correct me if I am wrong.

Mayutan

On Wed, Jun 11, 2008 at 3:55 PM, Robin Whittle <rw@firstpr.com.au> wrote:

> Hi Tony,
>
> You wrote in:
>
> http://lists.arin.net/pipermail/arin-ppml/2008-June/010988.html
>
> > Please, please, please go read GSE.  You may not like it, you may
> > not agree with it, but until you grok it, you haven't seen a big
> > chunk of the solution space.
>
>   http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr-00
>   (See quickie summary below my signature.)
>
> In the context of the RRG potentially forming a consensus that we
> don't need to recommend a solution for IPv4, but can rely on some
> IPv6-based solution and mass migration to IPv6, I think it is vital
> that all significant parts of the IPv6 solution space be considered.
>
> GSE seems to have been developed briefly around 1997.  I understand
> that applying it to IPv6 as used today would involve major changes
> in routers, host stacks and some or all applications.
>
> There may well be some major attractions in doing this, if it could
> be done, but it sounds like a radical thing on which to bet the
> future of the Net.
>
> Could you or someone else put together a proposal and link to it
> from the RRG wiki?  An 8 page summary and analysis document would be
> good too.
>
> A crucial part of this would be the time-frame for transitioning the
> current IPv6 system to whatever it is you are planning, and then
> having a transition plan for most end-users from IPv4 to the new system.
>
> I think it would also be good to explain why you would prefer to do
> this in a hurry for IPv6 - due to whatever urgency you or other
> people might think about the IPv4 scaling problem - rather than
> fixing the IPv4 problem with a map-encap scheme and then being able
> to take more time on whatever it is you propose for IPv6.
>
> If there was a plan to keep IPv4 going nicely for another decade or
> two with map-encap while cooking up something more elegant and
> lasting - including perhaps GSE for IPv6 without the need for
> map-encap - then I might be able to get enthusiastic about it.
>
> Still, I think map-encap + TTRs is the way forward for scalable,
> generally optimal path mobility.  If the GSE system could do
> multihoming and portability without the need for map-encap, then
> this reduces the scale and cost of the map encap system to that
> required for genuinely mobile hosts and networks.
>
> I understand that a GSE-based solution would not involve
> encapsulation at all, and encapsulating IPv6 packets is a more
> costly process than IPv4 packets, due to the very long addresses.
> I think this is a significant problem for map-encap for IPv6 VoIP
> packets.
>
>  - Robin
>
>
> GSE stands for "Global, Site, and End-system address elements".  It
> is only applicable to IPv6, or to an addressing system with 128 bits.
>
>  The 16 byte IPv6 address is split into 3 pieces:
>
>            0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
>          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>          |  Routing Goop    | STP| End System Designator |
>          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>                 6+ bytes   ~2 bytes       8 bytes
>
>  Routing Goop signifies where the Site attaches to the Global
>  Internet.  The Site Topology Partition (STP) is Site-private "LAN
>  segment" information.  The End System Designator (ESD) specifies
>  an interface on an end-system.
>
> The ESD for each host is globally unique.  Routing Goop is used by
> the global routing system and is rewritten in the destination field
> when it arrives at a site.
>
> I haven't read enough to know how it provides multihoming and
> portability (of the ESD part of the address) when changing ISPs.
>
>  One immediate result is that upper-layer protocols must use only
>  the ESD for purposes such as pseudo-header checksums and the like.
>  The ESD is the invariant token, the RG is possibly transient
>  topology information subject to change.
>
> So how does the Routing Goop and STP get set when the packet leaves
> the site for another?  Does a router change them or does the sending
> host have to get it right.  Does there need to be a mapping function
> and consequently a mapping database to determine what to set these
> to, since the ESD is what uniquely identifies the destination host?
>
> What lead to the demise of GSE ten years ago?
>
> --
> to unsubscribe send a message to rrg-request@psg.com 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
>



-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)