Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101

> On 3 May 2018, at 17:19, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> Hi Fred,
> 
>> What do we call such a chassis? I call it a chassis.
> 
> In my industry, we call it a "platform". A platform can be anything from an airplane
> to a cellphone to a drone to a laptop computer to an automobile to a high-end
> router, to a VM to, etc. etc.
> 
> Platform is a generic term that can be applied to any type of device that might
> ever want to receive a prefix delegation. I understand your chassis comment,
> but to me it sounds a bit too automotive-centric. So, instead of host, router,
> node, etc. we could refer to them as platforms.

We already have a name in IPv6. We call them nodes. 

Ole

> 
> Thanks - Fred
> 
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker
>> Sent: Sunday, April 29, 2018 5:09 PM
>> To: V6 Ops List <v6ops@ietf.org>
>> Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101
>> 
>> 
>> 
>>> On Apr 28, 2018, at 9:41 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
>>> 3. Does the answer to 2. depend on the weak-host, strong-host distinction?
>> 
>> Speaking for myself, and hats off, I think the weak-host/strong-host distinction isn't currently an accurate depiction of how hosts or
>> routers work in 2018, and isn't an obvious choice for a virtualized system. I refer to RFC 1122, section 3.3.4.2,  Multihoming
>> Requirements, which has to do with the choice of source address from a host with more than one interface.
>> 
>> The rules given are that (1) if the packet is being sent in response to a packet received, it MUST use the destination address in that
>> packet as its source address, (2) it MUST be possible for the application to specify the source address, and (3) if neither (1) nor (2)
>> apply, the communication layers below the application MUST (as in, "are forced to") select a source address. As additional
>> considerations, (A) a host MAY discard a packet received on a physical interface other than that which its destination address is used
>> on, and (B) a host MAY restrict itself to sending datagrams from the interface configured with whatever source address it uses.
>> 
>> The document then continues with "discussion", which to my thinking is the most interesting part of RFC 1122, 1123, and 1812, which
>> has to do with "why". The "Weak ES model" and the "Strong ES model" are found in that discussion, and are explicitly non-normative.
>> 
>> In the Strong ES model,
>>                      The Strong ES (End System, i.e., host) model
>>                      emphasizes the host/gateway (ES/IS) distinction,
>>                      and would therefore substitute MUST for MAY in
>>                      issues (A) and (B) above.  It tends to model a
>>                      multihomed host as a set of logical hosts within
>>                      the same physical host.
>> 
>> In other words, (A) a host MUST discard a packet received on a physical interface other than that which its destination address is used
>> on, and (B) a host MUST restrict itself to sending datagrams from the interface configured with whatever source address it uses.
>> 
>>                      Note that this model logically requires that in
>>                      general there be at least one default gateway, and
>>                      preferably multiple defaults, for each IP source
>>                      address.
>> 
>> The Weak ES Model
>>                      de-emphasizes the ES/IS distinction, and
>>                      would therefore substitute MUST NOT for MAY in
>>                      issues (A) and (B).  This model may be the more
>>                      natural one for hosts that wiretap gateway routing
>>                      protocols, and is necessary for hosts that have
>>                      embedded gateway functionality.
>> 
>> In other words, (A) a host MUST NOT discard a packet received on a physical interface other than that which its destination address is
>> used on, and (B) a host MUST NOT restrict itself to sending datagrams from the interface configured with whatever source address it
>> uses.
>> 
>> 
>> The question Fred is asking has to do with "end systems that receive a prefix delegation", and whether we would call such a one a
>> host, a router, a node, or something else.
>> 
>> 
>> From my perspective, if a prefix is assigned to a chassis for use in addressing its applications, containers, virtual hosts, or whatever, it is
>> not assigned to an interface per se. It is best thought of as having been assigned to a network that in some sense lies "behind" a
>> router, comparable to having been assigned to a home or other network through the CPE that connects to the upstream network. So
>> any discussion of the prefix being "on an interface" isn't visible to that upstream network. There is an address there, of course, which
>> may be only a link-local address, and in the upstream router is primarily used as the next hop in the route toward the prefix in
>> question. Whether it as available for network management purposes is not specified; if it is a global address, it might be used for
>> network management purposes, and if it is link-local, the network management application would have to be on the same LAN for
>> that to work. I would expect, rather, that network management is done via some application in the same chassis, perhaps in a
>> container or virtual host. Yes, that address would be used in network management messages on the interface in question; if the
>> chassis had multiple physical interfaces, it might also be used on them.
>> 
>> In other words, the weak and strong ES models are inadequate to describe a chassis allocated a prefix. It is a case not discussed in
>> currently-published RFCs.
>> 
>> What do we call such a chassis? I call it a chassis. It would be valid to call it a node, although from a networking perspective it contains
>> multiple virtualized nodes. It is not, in my view, exactly a host (a system with an address on one or more interfaces and responding
>> only packets sent to one of those addresses), nor is it exactly a router (a system that receives messages sent to an address not
>> configured on one of its interfaces and forwarding it toward another system, the indicated host); it is a third category. That category is
>> a set of systems that contain one or more identifiable routers and MAY contain one or more identifiable hosts, in some virtualized
>> sense.
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops