Re: [rrg] RRG to hibernation

jnc@mercury.lcs.mit.edu (Noel Chiappa) Mon, 12 November 2012 02:18 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
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 D712E21F842F for <rrg@ietfa.amsl.com>; Sun, 11 Nov 2012 18:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.496
X-Spam-Level:
X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 0iOyqhuccK98 for <rrg@ietfa.amsl.com>; Sun, 11 Nov 2012 18:18:48 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id D2CF721F842E for <rrg@irtf.org>; Sun, 11 Nov 2012 18:18:47 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4EB0218C0C7; Sun, 11 Nov 2012 21:18:47 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20121112021847.4EB0218C0C7@mercury.lcs.mit.edu>
Date: Sun, 11 Nov 2012 21:18:47 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jnc@mercury.lcs.mit.edu
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: Mon, 12 Nov 2012 02:18:49 -0000

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

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

    > Blatantly not true. There's this thing called NIMROD that has been
    > proposed to replace it. Perhaps you've heard of it? ;-)

In my original message, I meant 'here in the RRG, recently'. And you could
probably expand that to 'here in the I*, recently'.

I don't think there's been any serious work in routing since Unified and
Nimrod, right?


    > From: Shane Amante <shane@castlepoint.net>

    > let me try to take a step back and share with everyone a much broader
    > set of, potentially, architectural concerns
    > ...
    > if a downstream network does not have visibility into its upstream
    > network's routing policy is it practical/feasible for the downstream
    > network to understand the _intended_ propagation of reachability
    > information and, ultimately, connectivity? Furthermore, is it feasible
    > to carry such information within the control plane itself? Or, should
    > the control plane be relegated to carrying [strictly] reachability
    > information

You ask a series of very interesting questions, ones I don't have an
immediate answer to.

On the first, I have heard people say that providers don't want to tell
anyone anything about the policies, etc.

As to the second, there has been some thinking along those lines, although
I'm not sure it's all written down.

E.g. in the context of Nimrod, I thought about the possibility of separating
topology informtion from up/down information. E.g. a node might flood
topology information (i.e. long-term, permanent changes), but it would not
flood up/down information (i.e. short-term state changes). A distant node
would find out that an asset that was listed in the map was actually 'down'
when it tried to set up a path through it; the path setup would fail. I.e.
that information would be propogated in 'pull' mode, to try and reduce
overhead, and have that information only sent to those entities which
actually needed it. (There's a lot of complictions, e.g. what happens when an
asset fails when there's traffic using it, but I'm going to gloss over them
all for the moment.) But I'm not sure that stuff got written down... :-(


    > {A long series of other very interesing comments, which I don't have
    > the time to reply to.}

This is all very interesting stuff. Is there any chance you could expand this
into a short note (an RFC might be too much work, but perhaps there's some
other way to distribute it).

This sort of information, from the operational commmunity, is very valuable
to system architects. I personally am going to re-read this message several
times to make sure I have really absorbed everything in it.


    > Does anyone on this list share similar concerns wrt operational
    > robustness, time to recovery and (then) scalability of BGPv4?

Absolutely.

And I also have 'tussle' issues; which is to say, right now, the users have
little insight, and basically zero control (other than having multiple
providers, and picking the outbound provider) over paths. I'd like to see
the users have more insight and control, but the providers probably wouldn't
like that (hence the 'tussle' reference).

	Noel