Hi Tom, Section 6, last part is bit garbled.
"A request can be a detailed list of services requested for a flow, and the provide signal encapsulates the services to be provider." Do you mean "the provider signal encapsulates the services to be provided”? Also are you saying that host can ask network what services it can offer? "The response to a request is the signal data that the host or application can attach to its packets." The response part is unclear to me. Maybe related to the previous sentence (or not) Is this a response from the network A (in your dumbbell topology)? Had additional questions from requirements perspective: 1. Will the intermediate nodes processing these signals end up doing decrypt-process-encrypt again? 2. Should there be a requirement on mutability of signal data? E.g. Are nodes authorized/permitted to modify metadata or parameters for a signal? 3. In some cases that interest me, it is sufficient that host communicates its service request to the network it is attached to. Intelligent network edges can take care of the service delivery from then on. Would it make sense to allow edge nodes to map to internal service construct and remove the signal. I am asking this because it is one way to not mitigate signal exposure of the packets transiting through the network. Although encryption will serve the purpose but thought I should still ask. Thanks for putting the requirements together. Cheers, Kiran On September 27, 2023 at 4:11:39 PM, Tom Herbert (tom=40herbertland....@dmarc.ietf.org (mailto:tom=40herbertland....@dmarc.ietf.org)) wrote: > Hi, > > I've posted a use case and motivation document for Host to Network Signaling. > > I apologize for cross posting, but I believe this most likely falls in > the intarea, however we've seen some proposals that could use a common > protocol framework being presented in tsvwg. > > The goal of this document is to motivate discussion on the topic, and > I believe that it may be significant enough to warrant work on this in > IETF. > > Please review and comment! > > Thanks, > Tom > > ---------- Forwarded message --------- > From: > Date: Wed, Sep 27, 2023 at 4:09 PM > Subject: New Version Notification for draft-herbert-net2hostsig-00.txt > To: Tom Herbert > > > A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has been > successfully submitted by Tom Herbert and posted to the > IETF repository. > > 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 > > > Abstract: > > This document discusses the motivations, use cases, and requirements > for Host to Network Signaling. In Host to Network Signaling, a hosts > annotate packets with information that is intended for consumption by > on-path elements. Signals may be used to request services on a per > packet basis from on-path elements to request admission into the > network or to provide diagnostics and tracing information. > > > > The IETF Secretariat > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
