> On Sep 8, 2019, at 8:50 PM, Brian E Carpenter <[email protected]>
> wrote:
>
> On 09-Sep-19 12:15, Joe Touch wrote:
>>
>>
>>> On Sep 8, 2019, at 1:26 PM, Brian E Carpenter <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>>>
>>>>> Wouldn't that require the middle box to become an architectural element?
>>>>
>>>> Yes, but not just “an” (one):
>>>>
>>>> Touch, J: Middlebox Models Compatible with the Internet. USC/ISI
>>>> (ISI-TR-711), 2016. (Type: Technical Report | Links | BibTeX)
>>>>
>>>> * https://www.strayalpha.com/pubs/isi-tr-711.pdf
>>>
>>> I'll take the liberty of pointing out that we've known for many years that
>>> there are multiple types of middleboxes and they have multiple facets:
>>> https://tools.ietf.org/html/rfc3234
>>
>> Facets are just properties. That doc makes no attempt to describe them as
>> architectural roles.
>
> Agreed. My point is that the issue has been lying on the IETF table for many
> years, and we've collectively chosen to ignore it.
By “we”, I’m not sure who you mean. There have been plenty of us complaining
about this gap for a very long time in the IETF.
>
>>>
>>> So far, we haven't added them to any formal architectural description of
>>> the Internet, probably because we don't have one.
>>
>> RFC1122, RFC1123, RFC1812 as standards.
>>
>> I (and IMO those RFCs) disagree with the position you took in RFC1958, FWIW.
>
> "you" = the IAB in 1996; I was only the document editor.
Fair point, but presumably you were on the IAB at the time?
> But IMHO those RFCs are not architectural as such. They describe functions of
> nodes, not how the nodes work together as a system.
An architecture is (IMO) the behavior of a system that is the consequence of
the behavior of its components and the ways in which they interact.
Arguably, those RFCs - adding 791 and 3819, and a few others, do exactly that.
In a nutshell: routers relay; subnets (as links) interconnect), and hosts
source, sink, and do the rest (including reliability), all based on
globally-unique addresses in that can be aggregated by bit prefix. No, there’s
no “roadmap” doc that provides the top-level description, but the rest is
definitely there in those and other docs.
IMO, the issue is that middleboxes can’t simply be added to that list
consistently - they aren’t a third thing that can be peers to routers or hosts.
There is a way to describe them that’s consistent, though - but only if they
are different elements when viewed from different points in the network (as I
described in the tech report).
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
