Re: Fundamental Design Choices in IDPR
Noel Chiappa <jnc@ginger.lcs.mit.edu> Mon, 04 May 1992 23:05 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04948;
4 May 92 19:05 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02929;
4 May 92 19:10 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa02921;
4 May 92 19:10 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa18625;
4 May 92 18:15 EDT
Received: from BBN.COM by PARK-STREET.BBN.COM id aa18621; 4 May 92 18:14 EDT
Received: from GINGER.LCS.MIT.EDU by BBN.COM id aa20530; 4 May 92 18:13 EDT
Received: by ginger.lcs.mit.edu
id AA25265; Mon, 4 May 92 18:13:09 -0400
Date: Mon, 4 May 92 18:13:09 -0400
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Message-Id: <9205042213.AA25265@ginger.lcs.mit.edu>
To: idpr-wg@bbn.com
Subject: Re: Fundamental Design Choices in IDPR
Cc: jnc@ginger.lcs.mit.edu
Oh, in addition to those, I'd like to point out that there are a number of fundamental design choices *I* didn't agree with, which led me to not put much energy into this WG. They are: 1) Application of this protocol at the inter-AS level only, routing to AS's, not all the way down to individual network interfaces, rather than a unified routing architecture which would dispense with IGP's and EGP's. 2) (Sort of a result of the first.) Routing in a single level address space only, without handling a tree structured hierarchical address space and the ensuing abstraction issues, which to me are the most difficult (and most interesting). Noel
- Fundamental Design Choices in IDPR Noel Chiappa
- Re: Fundamental Design Choices in IDPR Noel Chiappa