On Fri, Sep 29, 2023 at 4:41 PM Kiran Makhijani <kiran.i...@gmail.com> wrote: > > 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?
Yes, I will reword it to be clearer. > > "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)? The idea is that an application makes a request for services to an agent in its local network, the agent replies with the signal data that the host attaches to its packet to get the granted services applied. Will try to reword to be clearer. > > Had additional questions from requirements perspective: > > 1. Will the intermediate nodes processing these signals end up doing > decrypt-process-encrypt again? They would just decrypt. Signals are not modifiable (if they were then that would fall under the auspices of network to host signals) > > 2. Should there be a requirement on mutability of signal data? E.g. Yes. > Are nodes authorized/permitted to modify metadata or parameters for a > signal? No, signals are not mutable. See above. Network to host signals would be though. > > 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. Yes, if there's only one possible consumer of the signal then I think it makes sense to remove the signal once it has been consumed. If Hop-by-Hop Options are used to carry the signal then it can be removed by removing the Hop-by-Hop Options Header (described draft-herbert-eh-inflight-removal) > > Thanks for putting the requirements together. Thanks for the feedback! Tom > 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
