Subject: Re: [rrg] RRG to hibernation

From: [email-masked] (Noel Chiappa)
Date: Fri, 9 Nov 2012 22:29:42 -0500 (EST)

> From: Tony Li <[email-masked]>

    > 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

---

From: William Herrin <[email-masked]>
Date: Sat, 10 Nov 2012 08:42:08 -0500

> Nonsense. It has produced no routing work at all.

Hi Noel,

I have a notion for a "routing" protocol which manages link changes
through dynamic readdressing and multiply addressing hosts. By and
large the addresses change so that the trivially aggregable routes
don't have to. Not just at the host level but all the way downstream
from the link change. Even bumps automatic resizing requirements
upstream so that over time any given router offers exactly one route
outward which automatically aggregates with the route its upstream
already holds.

It does require a new suite of transport protocols where layer 4 is as
loosely bound to layer 3 as layer 3 currently is to layer 2, along
with a new suite of APIs which don't expect the application layer to
manage remote addresses.

It's fresh. Might even be a genuinely new approach to routing. Are you
game to flesh it out and see how far we can run with it, even though
the odds of ever reaching deployment on an approach which requires us
to abandon TCP and UDP are not good?

Regards,
Bill Herrin

--
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Danny McPherson <[email-masked]>
Date: Sat, 10 Nov 2012 11:23:12 -0500

> and _nothing_ has been proposed to improve/replace it.

No, but I suspect if we bolt on BGPSEC extensions and things like "periodic updates" and per router signing & validation of updates, we're going to need to work on a replacement in short order.

Some of the smart folks here applying their perspective would certainly be of value, methinks.

-danny

---

From: Tony Li <[email-masked]>
Date: Sat, 10 Nov 2012 09:24:16 -0800

Amazing.  For years, I unsuccessfully try to spark discussions.  Then I say that we're done and THAT sparks discussions.  ;-)

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

> Some of the smart folks here applying their perspective would certainly be of value, methinks.

I agree that some security needs to be deployed.  I'm not convinced that it needs to be BGPSEC.  We've muddled along for many years and never found the gumption to actually deploy anything.  Must not be important to people.  I don't get it, but that's the observable behavior.  

In any case, this doesn't seem like a research topic.  This is pretty clearly an engineering issue.

Tony

---

From: Danny McPherson <[email-masked]>
Date: Sat, 10 Nov 2012 12:35:11 -0500

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

That's Noel's comment, I suspect hes got some perspective on that :-)

> In any case, this doesn't seem like a research topic.  This is pretty clearly an engineering issue.

I don't agree.  The engineering solution that SIDR is actively working (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there's no tomorrow.  The USG has stated intentions of "expediting secure routing work through the Internet standard process" and "fostering adoption through government procurement vehicles".  

As an operator this scares the hell out of me, especially considering what they've designed is largely a system to control "what's routed on the Internet and by whom".  They can't seem to do anything in BGP(SEC) without introducing the equivalent of "periodic updates", and undoing all the goodness of things like update packing completely.  

Some serious thinkers working on this problem would be goodness...

-danny

---

From: Tony Li <[email-masked]>
Date: Sat, 10 Nov 2012 09:54:37 -0800

> Some serious thinkers working on this problem would be goodness…

I agree, but as you correctly point out, SIDR is an engineering solution.  If you dislike that particular solution, you're of course free to propose others.  However, the correct forum for engineering solutions is the IETF.  

Tony

---

From: Shane Amante <[email-masked]>
Date: Sat, 10 Nov 2012 18:38:57 -0700

> On Nov 10, 2012, at 12:24 PM, Tony Li wrote:
[--snip--]
> Some serious thinkers working on this problem would be goodness...

Let me add that I share Danny's concerns ...

However, let me try to take a step back and share with everyone a much broader set of, potentially, architectural concerns that I'm not sure this RG considered during the last round.

BGP was originally designed for flooding of reachability information.  But, reachability information is the end-result /after/ the application of _routing_policy_, describing "intent", by operators of individual networks based on various contractual agreements they have with parties whom they directly interconnect.  Assuming you agree with this premise, this presents a paradox from a security PoV.  Specifically, 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 in real-time, while offboard systems carry accompanying routing policy and security information in order to assist in making "optimal" Inter-Domain routing/forwarding decisions?

A second concern is also related to the original design of BGP and what it has organically involved into, today.  Specifically, BGP is /also/ now being tasked as a generic "message bus" and service discovery mechanism.  Not to pick on anyone, in particular, but the following are recent examples that come to my mind wrt this trend:
http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-01
http://tools.ietf.org/html/draft-ietf-idr-operational-message-00
... and, there may be others.  Although, contrast those proposals with what should be most concerning to people in this RG, and in the IETF:
http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-05
In short, operators (such as myself) are _extremely_ concerned that a single erroneous update results in a complete reset of BGP sessions.  Due to the overwhelming success of BGP, it's now (and, has been for a while) a mission-critical protocol, thus such catastrophic session resets -- caused by a single malformed UPDATE -- are widely visible/impactful.  This impact is compounded by the 'cost to recover'.  Namely, due to the large and growing amount of information in the RIB (again, not just reachability, but also service-discovery and completely orthogonal information), it takes longer to exchange RIB information and, ultimately, restore services.  Is this really the best we, as an industry, can do?

While the IETF IDR WG has been looking at mechanisms for how BGP may defend against certain types of erroneous BGP UPDATE's for external BGP sessions:
http://tools.ietf.org/html/draft-ietf-idr-error-handling-02
... there does not appear to be any [straightforward] answer with respect to internal BGP sessions, given the requirement that BGP speakers internal to an AS must have a globally consistent RIB and FIB, otherwise packet forwarding loops will result.  And, in my personal operational experience it's _rarely_ the case that malformed UPDATE's are detected at the first ASBR (attached to an eBGP neighbor) in my AS, thus it concerns me that mechanisms such as draft-ietf-idr-error-handling-02 are an adequate solution to the problems we experience.  IOW, as an operator I desire "defense in depth" where a heterogeneous mix of vendor equipment (HW + SW), participating as interior BGP speakers, have mechanisms to detect *and* automatically recover from malformed UDPATE's received over iBGP sessions.  This is another area that I would point research colleagues toward.

So, this raises the classic conundrum of: increasing complexity, increasing RIB (and FIB) size information coupled with a contrasting need from operators who are concerned about the robustness of the protocol and the requirement to NOT sustain any failures[1].  Something's got to give.

Ultimately, this makes me question whether it's no longer _just_ growth of RIB (and, FIB) size that this RG should be (primarily?) focused on.  Rather, will the requirements for:
a) operational robustness, in the face of critical messaging errors in an Inter-Domain Routing Protocol, which the IETF may be unable to address on its own;
b) designing security as a first-class principle of an Inter-Domain Routing Protocol -- either carried within or outside of control-plane reachability information
c) increased scalability of RIB (and, other?) information
... lead us down a path of considering we may be approaching the end-of-the-road for BGPv4 and we need something new?

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

-shane

[1] It is not cool to suggest that operators should just stop asking for new features and we wouldn't have this problem.  :)

---

From: Eliot Lear <[email-masked]>
Date: Sun, 11 Nov 2012 11:22:17 +0100

Tony,

First, thanks for taking on and navigating work within the RRG for as
long as you have done.  I think people forget that this group has
induced a tremendous amount of stress and turbulence over time, and that
you were often the target of that stress.

This having been said, I think this group like any other group – based
on contributions and participation.  If there are no contributions and
if there is no participation, no work can continue.  On the other hand,
when there are contributions or participation, we shouldn't be hasty in
closing the effort.  Therefore, I would suggest a solicitation for new
topics with the threat of closure, before actually closing – or going
dormant.

Eliot

---

From: Tony Li <[email-masked]>
Date: Sun, 11 Nov 2012 09:45:33 -0800

> topics with the threat of closure, before actually closing – or going

Eliot,

Thanks, but as you may recall, we did do a solicitation of new topics some time ago.  It didn't provoke anything substantive and there has been no additional input.

Further, the transition to hibernation is easily reversed if and when a new substantive topic presents itself.

Tony

---

From: Danny McPherson <[email-masked]>
Date: Sun, 11 Nov 2012 18:45:19 -0500

> I agree, but as you correctly point out, SIDR is an engineering solution.  If you dislike that particular solution, you're of course free to propose others. However, the correct forum for engineeri…

I was hoping for some research and fresh thinking related to rate+state+autonomous operations &security in inter-domain routing, hence my message here.  I don't have a solution envisaged, I just know what I'm seeing in current work is err.., going to present some challenges.

I was hoping for "architectural alternatives, research and experimentation in secure routing architectures and algorithms being encouraged, with an aim to understand whether new directions can provide effective solutions, to work out candidate designs as necessary for a complete solution, and to fully understand both the gains and the tradeoffs that the new solutions may bring." (some of that text may sound familiar :-)

As a side benefit, whether the routed protocol changes or not, using security as the fulcrum may well help foster broader consideration of alternative routed protocols...

Else -- some work into scalable *static* inter-domain routing techniques and solutions might be a worthwhile endeavor *8^/

If that's not within RRG scope then I suppose I understand how we arrived where we currently are...

-danny

---

From: Dae Young KIM <[email-masked]>
Date: Mon, 12 Nov 2012 09:49:48 +0900

Dear Noel,

As I know, the original rationale for RRG was to find a solution to
mitigate the DFZ routing table explosion. LIS like ILNP was then proposed
as a solution mechanism.

One might argue that LIS does not help reduce the DFZ routing table size;
please find the attachment. If there's any point in the argument, then
we've not accomplished our original task wrt DFZ routing table explosion,
echoing your point.

On Sat, Nov 10, 2012 at 12:29 PM, Noel Chiappa <[email-masked]>wrote:

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

-- 
DY

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 12 Nov 2012 10:26:36 +0200

> If that's not within RRG scope then I suppose I understand how we arrived where we currently are...

Hi Danny,

if some of the RRG proposals (LISP, ILNP, IRON, hIPV4) gets globally
implemented then the endpoint locators (EID, ELOC etc) will not show
up in the DFZ and the global routing table should be more static than
today.
However, none of the RRG proposals have a proper solution for
inter-domain traffic engineering, thus I think your concerns are right
on spot.
It would be interesting to take the IRS approach (as an interface to
the FIB) and design from scratch an inter-domain traffic engineering
architecture, where the ISPs can create explicit paths for certain
traffic flows/bundles between domains without inserting more granular
prefixes in the RIB of DFZ. This new inter-domain architecture would
be designed as an additional control plane in parallel with the
current control plane of the existing BGP based DFZ.
Is this doable, what are the pros&cons?

Patrick