Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt
OK, I see where you are coming from and it makes sense. Hopefully that will become clear when the IANA Considerations section gets completed. Just out of curiosity, how would key distribution and updating work for the encryption? From: Int-area On Behalf Of Tom Herbert Sent: Friday, September 29, 2023 11:12 AM To: Robinson, Herbie Cc: Tom Herbert ; int-area ; tsvwg Subject: Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.] On Thu, Sep 28, 2023 at 9:32 AM Robinson, Herbie <mailto:Herbie.Robinson=40stratus@dmarc.ietf.org> wrote: > > I have a couple of observations > > > In section 2.2, you make the claim that the actual host to network services > should be vendor specific. Yet in section 2.3, the example services you > mention are all things that should, in fact, be standardized. The relevant text is: "An outcome of this design is that there is no requirement for a standard set of signals that all networks must support; signals can be defined in each provider network per their needs and the network services they offer." It's not so much about being vendor specific, it's more about avoiding a "one size fits all" approach. An automotive network may offer very different services than a mobile network which may be different than a cloud provider. There may be a common set of signals for each of these types of networks, but I think we want to avoid mandating that the services and their signals have to be used by everyone. > While I am willing to accept that there are examples where vendor specific > services should be supported, the main focus should be a model for describing > standard services as well. I am speaking as the maintainer of host networking > software and by extension the applications that use it. Asking applications > to interface to potentially hundreds of different vendor protocols is > unmanageable (from the standpoint of the application developer) and will most > like result in none of them using any of it. Yes, applications should only need one protocol. For the actual signals, they only have to support the carrier in packets. For requesting signals, I would envision that applications contact an agent in the network that makes their request. Maybe something like REST with some XML description of parameterizations. Since these requests are not inline with the data path, the requests for services could be a rich set of parameters (frame rate, latency, anti-censorship, etc.). The set of possible parameters could be standard, but it becomes a network specific thing to turn these parameters into a signal for the services they support in the network the host can use with its packets. > Re: > > |Name: draft-herbert-net2hostsig > |Revision: 00 > |Title: Host to Network Signaling > |Date: 2023-09-27 > |Group: Individual Submission > |Pages: 22 > |URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt > |Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig > |HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt
On Thu, Sep 28, 2023 at 9:32 AM Robinson, Herbie wrote: > > I have a couple of observations > Hi Herbie, Thanks for the comments! > There is a desire to make host to network signals processable in fast router > paths without variable length packet processing. Yet at the same time, there > is a requirement for encryption. Processing variable length packets is going > to be a lot easier in the fast path (all it takes is a barrel shifter) than > decrypting parts of a packet; so, it would appear that these are conflicting > requirements. Both are, of course, implementable with the appropriate > hardware resources, but I suspect it will take a lot of persuading to get any > vendors to do that. I think variable length headers and decryption have different motivations and are orthogonal. Encryption is needed to hide sensitive data from observers. Host to network signals needed to be encrypted (or at least obfuscated) to prevent abuse of the signals. I suppose if the signals were restricted in a limited domain maybe the requirement for encryption. But, given that there's a need for hosts to network signaling in public networks, I think we need a good solution and it will have to be efficient (maybe network nodes can maintain some sort of cache of signal being received so they only have to decrypt once or something like that) Variable length headers provide extensibility. For variable length header processing, I tend to agree that this problem is being solved (hopefully, we can move past this as being a "headache" in high performance datapath processing). We should be able to leverage constructs like TLVs in network layer protocols but with some judicious limits for practicality (see draft-ietf-6man-eh-limits for example). There's another option here also, just because a protocol allows something to be variable length doesn't mean the length *has* to be variable length. For instance, suppose we define a host to network signal in a Hop-by-Hop Option that has a fixed size. If that's the only HBH option being used in the network, then the option is not only fixed length, it's also always at the same offset in packets. Network devices can process the signal without any variable length processing. Effectively, it's a means to extend the IP header with a fixed length. It's an opportunistic optimization that would never apply in the open Internet, but inside a limited domain where the admin has control over the network infrastructure it is feasible. > > In section 2.2, you make the claim that the actual host to network services > should be vendor specific. Yet in section 2.3, the example services you > mention are all things that should, in fact, be standardized. The relevant text is: "An outcome of this design is that there is no requirement for a standard set of signals that all networks must support; signals can be defined in each provider network per their needs and the network services they offer." It's not so much about being vendor specific, it's more about avoiding a "one size fits all" approach. An automotive network may offer very different services than a mobile network which may be different than a cloud provider. There may be a common set of signals for each of these types of networks, but I think we want to avoid mandating that the services and their signals have to be used by everyone. > While I am willing to accept that there are examples where vendor specific > services should be supported, the main focus should be a model for describing > standard services as well. I am speaking as the maintainer of host > networking software and by extension the applications that use it. Asking > applications to interface to potentially hundreds of different vendor > protocols is unmanageable (from the standpoint of the application developer) > and will most like result in none of them using any of it. Yes, applications should only need one protocol. For the actual signals, they only have to support the carrier in packets. For requesting signals, I would envision that applications contact an agent in the network that makes their request. Maybe something like REST with some XML description of parameterizations. Since these requests are not inline with the data path, the requests for services could be a rich set of parameters (frame rate, latency, anti-censorship, etc.). The set of possible parameters could be standard, but it becomes a network specific thing to turn these parameters into a signal for the services they support in the network the host can use with its packets. > > In section 6, I would also claim that it's a requirement that any vendor > specific services must be registered with the IANA and fully described in > documentation provide free of charge by the vendor. Per above, I think it might be the service parameters they used should be registered. The actual services provided are derived from requests containing the parameters. Tom > > Re: > > |Name:
Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt
I have a couple of observations There is a desire to make host to network signals processable in fast router paths without variable length packet processing. Yet at the same time, there is a requirement for encryption. Processing variable length packets is going to be a lot easier in the fast path (all it takes is a barrel shifter) than decrypting parts of a packet; so, it would appear that these are conflicting requirements. Both are, of course, implementable with the appropriate hardware resources, but I suspect it will take a lot of persuading to get any vendors to do that. In section 2.2, you make the claim that the actual host to network services should be vendor specific. Yet in section 2.3, the example services you mention are all things that should, in fact, be standardized. While I am willing to accept that there are examples where vendor specific services should be supported, the main focus should be a model for describing standard services as well. I am speaking as the maintainer of host networking software and by extension the applications that use it. Asking applications to interface to potentially hundreds of different vendor protocols is unmanageable (from the standpoint of the application developer) and will most like result in none of them using any of it. In section 6, I would also claim that it's a requirement that any vendor specific services must be registered with the IANA and fully described in documentation provide free of charge by the vendor. Re: |Name: draft-herbert-net2hostsig |Revision: 00 |Title: Host to Network Signaling |Date: 2023-09-27 |Group: Individual Submission |Pages: 22 |URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt |Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig |HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
