Subject: RE: [arch-d] Valid and Invalid Internet architectures and approaches

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 8 Dec 2005 10:01:21 -0800

From: Yakov Rekhter [mailto:[email-masked]] 
>With this in mind I suggest we go to where the market 
>demands. Yes, one could argue that market demands could 
>yield less than optimal outcomes. But have we seen any 
>other mechanism that consistenly produces more optimal 
>outcomes?  And after all, what is "optimal" in the first 
>place?

Excellent points, Yakov. However, how far should we take this argument?
Would you say, for example, that we should remove all design constraints
that were historically placed upon defining interoperable IP product
offerings? Is the IETF primarily a marketing arm within the "market
demands"-based world? 

Or perhaps the truth you have just articulated needs to be
counter-balanced by another truth that the market relies upon
technically sound products and the role of our community is to foster
that soundness? Aren't sound products ultimately a function of good
design and good design based upon a viable architectural foundation?

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 8 Dec 2005 15:18:23 -0500 (EST)

[Arck. Somehow that got truncated. Here's the last section, complete...]

    > IMHO, an architecture needs to keep that set of things small - so that
    > one can keep track of them - and architects need to defend that small
    > set.

Precisely. One of the goals of Nimrod was:

  "Minimize the size of the 'core' system which must be implemented on a
  system wide basis. Such minimization maximizes the flexibility, and thus
  the lifetime of the architecture."

which says basically the same thing, albeit in a different way. (Hmm, really
ought to put that "architectural goals of Nimrod" material online...)

    > But I doubt we disagree on this.

Exactement.

	Noel

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 8 Dec 2005 15:03:50 -0800

The Bump in the Wire (BITW) security gateway approach for IPsec in
tunnel mode. In RFC 2401, it was described loosely enough that the
implementation need not segment the network. However, in 2401bis they
"cleaned up" the language such that a BITW middlebox was specified to
decrement the encapsulated (Red) TTL value as though it were a router.
By so doing, it segments the network. Cisco has devised a product (Cisco
Dynamic Multipoint VPN) to overcome this for unicast for Cisco-routers
by establishing redundant mGRE tunnels between the otherwise segmented
routers. However, there is no work around for multicast, though Beau
Williamson of Cisco is reportedly working on a Cisco-proprietary
solution, that may perhaps be added to their IOS someday. However, it is
a really trivial fix to get BITW gateways to work properly (i.e.,
middleboxes should not decrement the TTL just as RFC 3234 implies) but I
was unable to convince the 2401bis editor to make that change.

-----Original Message-----
From: Ted Faber [mailto:[email-masked]] 
Sent: Thursday, December 08, 2005 11:01 AM
To: Fleischman, Eric
Cc: Noel Chiappa; [email-masked]
Subject: Re: [arch-d] Valid and Invalid Internet architectures and
approaches

On Thu, Dec 08, 2005 at 08:54:22AM -0800, Fleischman, Eric wrote:
> Noel's paragraph summarizes my view before I began my recent queries. 
> What got me started on this vector was the discovery that when I 
> identified a feature in RFC 2401 and 2401bis that demonstrably causes 
> irreparable harm to IP and the Internet with no beneficial side 
> affects
[...]

Any chance of a pointer to the problem, or will I not be sleeping
tonight?

-- 
Ted Faber
http://www.isi.edu/~faber           PGP:
http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See
http://www.isi.edu/~faber/FAQ.html#SIG