Re: comments on the architecture document

Noel Chiappa <jnc@ginger.lcs.mit.edu> Wed, 29 April 1992 06:34 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00328; 29 Apr 92 2:34 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00992; 29 Apr 92 2:39 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa00986; 29 Apr 92 2:39 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa25160; 29 Apr 92 1:48 EDT
Received: from BBN.COM by PARK-STREET.BBN.COM id aa25156; 29 Apr 92 1:47 EDT
Received: from GINGER.LCS.MIT.EDU by BBN.COM id aa06372; 29 Apr 92 1:47 EDT
Received: by ginger.lcs.mit.edu id AA18330; Wed, 29 Apr 92 01:47:19 -0400
Date: Wed, 29 Apr 92 01:47:19 -0400
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Message-Id: <9204290547.AA18330@ginger.lcs.mit.edu>
To: idpr-wg@bbn.com, yakov@watson.ibm.com
Subject: Re: comments on the architecture document
Cc: jnc@ginger.lcs.mit.edu

	Yakov, I found most of your comments useful. Some brief comments
on a few I didn't agree with:


> Specifically you failed to mention that Link State requires globally 
> agreed upon syntax/semantics for the set of transit policies, ... .

No. In fact you sort of agree below, where you say:

> Using Link State in conjunction with private source policies locks you
> into the source specified forwarding, whether you want it or not.

Hop-by-hop LS routing requires global agreement on policies (otherwise
permanent forwarding loops can form), but not source routed LS. This was one
of the reasons I went with source routing when I first came up with this
approach.

There were many reasons that source routing appeared desireable to me, and
allowing relaxation of the requirement for global agreement on policies
(important in a growing large internet, where incremental deployment of new
capabilities is desireable) was just one.

In general, source routing is more robust in the sense that you are less
likely to create forwarding loops when errors happen. Also, source routing
allows user specification of very complex policy attributes that cannot be
expressed otherwise. It allows users to hide policies from outside agents. It
allows users to make decisions about which of several alternate paths they
prefer their traffic to take; i.e. enforce their trust models. These are just
a few off the top of my head.


> Transient looping will be present with IDPR as well, as long
> as IGPs that IDPR relies on have transient loops.
> Thus, I would suggest to either (a) remove the whole section, or (b) state
> state that transient looping is unavoidable both with DV and with LS,
> and thus can not be viewed as an argument in favor of a particular
> approach.

It's true that hop-by-hop LS can have transient loops. However, IDPR is not
hop-by-hop; getting rid of basically all transient loops is another advantage
of source routing. The fact that some IGP subcomponent may fail cannot be held
against IDPR. (Nimrod! Flush IGP's! Run it on the metal! Yah! :-) You are
straining to find arguments here.

Also, on average, all hop-by-hop LS transient loops will disappear faster than
some DV transient loops. This is one of the advantages of LS (identified in
the original BBN report #3803, April 1978, page 159). LS algorithms stabilize
in a short, very bounded time (basically a flood time plus a tree recompute
time). DV algorithms (even with EI-N detection, such as BGP) may take a
shorter or longer time, the time depending on the topology and the exact
change. There is thus a wider dispersion of stabilization times in DV systems.


> Source specified forwarding is dictated by the selection of
> LS, rather than DV, and lack of globally consistent information.

You seem to view the lack of enforced global consistency as a bug, not a
feature. In my view it is an explicit feature of a routing architecture for a
very large internet that it can grow to handle new capabilities in an
incremental way. As stated above, there is no single reason for going with
source routing, but the ability to do this was one major one.


	Noel