Subject: The Natural Entropy of the Internet?

From: Danny McPherson <[email-masked]>
Date: Thu, 31 Jul 2003 23:50:19 -0600

On Thursday, July 31, 2003, at 07:57 PM, Mark Prior wrote:

> Having this new stuff separate from the production stuff is good
> and the more separate the better.

And this is where the problem arises.  "the more separate the
better" perhaps holds true when simply considering complexity
increase of a system, but what about *other* pragmatic factors
such as competitiveness, economies or commercial market
forces?

The reality is that service providers are converging networks in
order to decrease operational expenditures associated with
maintaining multiple parallel [overlay] networks (networks that
likely already employ the same transport substrate), all while
continuing to expand service offerings, associated footprints and
overall service availability.  Anyone that doesn't buy this, go
talk to your marketing, finance or business folks -- or customers,
it's reality, whether we like it or not.

Much of the arguable complexity being added to BGP and other
routing protocols is simply a result of its success (e.g., trivial to
implement, leverages deployed code and protocols, existing operator
knowledge base, ease of deployment, etc, etc..).  The same holds
true for the carriage of new services via IP networks (i.e., pseudo
wires and the whole VPLS & L2/L3 VPN thing).  "IP Everywhere",
we asked for it!  If it's really a good idea or not is far to often an
afterthought.  Success breeds repetition (as any network operator
attempting to halt another "one-off" would likely attest to).

My position, which isn't firmly within either of the two obvious
"camps", is that allowing such "extensions" to continue unmetered
will unquestionably have a negative impact on the global
Internet, regardless of what scoped deployment scenarios the
designers of any individual feature or extension initially
envisioned.  However, with that said, I fear the reality is that
regardless of the outcome of these or any other [largely academic]
discussions,  the immediate tangible value of this whole passel of
convergence-oriented subjects will prevail.

Beyond increasing awareness of the intricacies and associated
implications to the global Internet, and perhaps beginning work
on some next-generation routing/signaling protocols, there's little
we can do at this stage.

-danny 

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Danny McPherson <[email-masked]>
Date: Thu, 31 Jul 2003 23:50:19 -0600

-danny

---

From: Mark Prior <[email-masked]>
Date: Fri, 01 Aug 2003 15:32:16 +0930

> such as competitiveness, economies or commercial market
I agree there is a practical limit where extending the division makes no
sense as these things need to operate on the same underlying infrastructure
but having a mechanism that keeps them from affecting each other within the
routing hardware would be a good thing. Having some new feature take out my
production BGP process would be a bad thing. Worst still if it required a
reboot into another version of the operating system to get a version of that
process that didn't continually crash.

Mark.

---

From: Mark Prior <[email-masked]>
Date: Fri, 01 Aug 2003 15:32:16 +0930

Mark.

---

From: Russ White <[email-masked]>
Date: Fri, 1 Aug 2003 13:00:12 -0400 (Eastern Daylight Time)

> And this is where the problem arises.  "the more separate the better"
> perhaps holds true when simply considering complexity increase of a
> system, but what about *other* pragmatic factors such as competitiveness,
> economies or commercial market forces?

And another point that's rather interesting in this context, that I've
brought up before: Once this new "protocol" stablizes, and becomes part of
the "production network," then you will not want new features in it, right?
Or do we develop two protocols, one for "new stuff," once the "new stuff"
is stable, and "in production," then we move it from the "expermiental"
protocol to the "stable" protocol?

Or do we invent a new distribution mechanism for each new "thing" we want
to roll out? Or is there some middle ground, that we can say when you get
over x number of applications, you create a new protocol, or.... (?) There
has to be a long term plan, not a single "oh, let's fix BGP, and move on to
some other problems," since we're really just talking about raising the
same issues with "son of BGP" in a couple of years.

I've not seen this question answered yet--how do you address this?

Either we state that for architectural purity, each new application should
come with it's own protocol, or we accept that we are going to have one
"overloaded" protocol, which carries things which are experimental and
things which are not experimental.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Russ White <[email-masked]>
Date: Fri, 1 Aug 2003 13:01:14 -0400 (Eastern Daylight Time)

And further, more seperated is _not_ always better. Based on the laws of
statistics, there is a balance point between the two.

10 T1's may _feel_ more reliable than a single OC3, but they really aren't.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Fri, 1 Aug 2003 13:01:14 -0400 (Eastern Daylight Time)

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Fri, 1 Aug 2003 13:00:12 -0400 (Eastern Daylight Time)

:-)

Russ