Re: [rrg] RRG to hibernation

heinerhummel@aol.com Sun, 11 November 2012 19:53 UTC

Return-Path: <heinerhummel@aol.com>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE9B21F84DD for <rrg@ietfa.amsl.com>; Sun, 11 Nov 2012 11:53:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.131
X-Spam-Level:
X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJk8rQbsIko9 for <rrg@ietfa.amsl.com>; Sun, 11 Nov 2012 11:52:59 -0800 (PST)
Received: from imr-da02.mx.aol.com (imr-da02.mx.aol.com [205.188.105.144]) by ietfa.amsl.com (Postfix) with ESMTP id D851A21F84DA for <rrg@irtf.org>; Sun, 11 Nov 2012 11:52:58 -0800 (PST)
Received: from mtaomg-mb02.r1000.mx.aol.com (mtaomg-mb02.r1000.mx.aol.com [172.29.41.73]) by imr-da02.mx.aol.com (Outbound Mail Relay) with ESMTP id 3B7391C000095; Sun, 11 Nov 2012 14:52:58 -0500 (EST)
Received: from core-dqa002b.r1000.mail.aol.com (core-dqa002.r1000.mail.aol.com [172.29.211.197]) by mtaomg-mb02.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 0554EE000088; Sun, 11 Nov 2012 14:52:58 -0500 (EST)
To: swb@internet2.edu, jnc@mercury.lcs.mit.edu
X-MB-Message-Source: WebUI
Received: from 178.27.21.1 by webmail-m019.sysops.aol.com (64.12.101.103) with HTTP (WebMailUI); Sun, 11 Nov 2012 14:52:57 -0500
MIME-Version: 1.0
From: heinerhummel@aol.com
X-MB-Message-Type: User
Content-Type: multipart/alternative; boundary="--------MB_8CF8E5D483959BE_914_D9800_webmail-m019.sysops.aol.com"
X-Mailer: Webmail 37130-STANDARD
Message-Id: <8CF8E5D4815A51E-914-3A6E4@webmail-m019.sysops.aol.com>
X-Originating-IP: [178.27.21.1]
Date: Sun, 11 Nov 2012 14:52:57 -0500 (EST)
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1352663578; bh=tgbjYdHQMcghSQmnNrP203qKoYWWIdSFTQV4moy1GCY=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=FutfE5WH49bqN/Lv1uNcoHupi3XDEV9McPHLsUkBqhn7GdScl5do8qipQ3Ar4g9Hl S0Ouw7+Z4hZG4nWJhsG9SYQ7oLfqE7YCmG93vP3oS/Es07F+2zgCx+QNMN9hcN4yZA zKrlUJFQHwCZZIUs0ir58vVnQgA6CbCwSHFvnR8o=
X-AOL-SCOLL-SCORE: 0:2:481120192:93952408
X-AOL-SCOLL-URL_COUNT: 0
x-aol-sid: 3039ac1d294950a0021a225d
Cc: rrg@irtf.org
Subject: Re: [rrg] RRG to hibernation
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Nov 2012 19:53:00 -0000

I an not pleased ether.
One group goes ahead with LISP-DDT, which is doomed to fail ! With drums and trumpets! As sure as the Amen in church ! With no rescuing trick in sight! 
The other group believes in IPv6. I admit, I don't know what is special about IPv6. All I know is that the inventors came up with a crazy address space and I do remember voices from many many years ago which proclaimed the advent of the internet for our galaxy.I am sure, IPv6 would only create additional scalability problems. Imagine a future where we have only IPv6. Hereby imagine New York at New Year's Eve and several hundred thousand people operating as mobile sender's of  IPv6-multicast instances with multicast receivers far away (which may as well be mobile) !  We wouldn't not only have a scalability problem wrt forwarding but as well with respect to identifying the individual entities. How many IPv6-addresses are needed to identify one single mobile multicast instance? 1? 2? 3? How should it be retrieved by software?


Loc/id-split:  
Obviously what is a locator and whether there are several components thereof or not hasn't been understood.
A unicast locator MUST BE location-indicating! A multicast -locator CANNOT but this doesn't mean that there can't be any.


Topology-aware BGP:
Distance Vector versus Dijsktra.
DV will never tell you about the upstream network (see also Shane Amante's email). This is a disaster if you want to manage traffic load (balance/ dissolve congestion) :-(
Reachability: We don't need reachability. we only need to know where is the indicated location !!!  Location based routing means no user reachability dissemination,  only location reachability dissemination!


Whenever I addressed these issues it was like I had sinned against some holy paradigm.


And we are far away from better routing:
I you only know the ALL-Nodes-Spanning-Tree (and not the All-Links-Spanning-Tree) then you call it Spanning Tree per se.
If you only know the Unicast-FIB (and not a Multicast-FIB, nor a Anycast-FIB)  then you call it FIB per se.


To reach a higher level you must view things from a greater distance and sometimes leave the old trails behind you.


Ich habe fertig
Heiner

















-----Urspr√ľngliche Mitteilung----- 
Von: Scott Brim <swb@internet2.edu>
An: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: rrg <rrg@irtf.org>
Verschickt: Sa, 10 Nov 2012 4:40 am
Betreff: Re: [rrg] RRG to hibernation


Well, this will be fun. Yes Noel, you're right, this group didn't produce any 
routing revolutions, and loc/id separation is about problems on the identity 
function side, not routing ... but this group's best accomplishment imho was to 
understand that and spread the knowledge. 

Now I'll go back to doing good things with higher layer identities.  Ciao.

Scott

jnc@mercury.lcs.mit.edu wrote:

    > From: Tony Li <tony.li@tony.li>

    > The publication of these RFCs concludes our long standing work item on
    > a revised routing architecture.

Separation of location and identity is very desirable, but it has basically
nothing to do with routing (other than removing identity functionality from
the names used for routing, making them a bit more tractable).

We still have the same old kludgy BGP global routing system we always had,
and _nothing_ has been proposed to improve/replace it.

    > The group has ... helped push the boundaries of routing farther
    > forward.

Nonsense. It has produced no routing work at all.

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