Re: [Int-area] Fwd: New Version Notification for draft-herbert-host2netsig-00.txt
Tom Herbert wrote: > This is an update to the host to network signaling draft. Note the name > is now properly host2netsig. > Other changes include: * Add suggestion that signals could be in a > namespace managed by IANA and allow vendors to define their own signals I found section 3 vs section 4 a bit confusing. Many of the things in section 3 seemed to be actually existing mechanisms. for instance: 3.4. Traffic flow analysis [I-D.cc-v6ops-wlcg-flow-label-marking] describes a mechanism to mark packets of flows with information that identifies the application or user that is sending packets. seems to be a different host to network signaling mechanism. Section 4 seems to be more about what didn't work :-) I just want to re-iterate section 4.1.1: * Stateful devices can be an anonymous single points of failure in the network path. For instance, stateful devices can break individual connections mid-flow due to state eviction. The incumbent telco in Canada has long used ECMP in a stateful way that basically always breaks ssh connections that last longer than a few minutes. They only fixed this when HTTP/1.1 became predominant. Even sending keepalives did not help. "* They are IPv6 specific, there is no equivalent support in IPv4." seems like a feature for IPv6, not a problem :-) We have many ways for embedding IPv4 inside IPv6, if needed. Do you really need to make such a long argument for IPv6 Hop-by-Hop? I think that this document is really a kind of merge Requirements and Architecture. Maybe it will also be a Roadmap to other documents? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Fwd: New Version Notification for draft-herbert-host2netsig-00.txt
Hi, This is an update to the host to network signaling draft. Note the name is now properly host2netsig. Other changes include: * Add suggestion that signals could be in a namespace managed by IANA and allow vendors to define their own signals * Added a use case that host to network signals could be used as routing hints * Describe motivation and requirement for removing host to network signals from packets in flight, gave example of how this might be done in Hop-by-Hop Options * Added a requirement to define a common carrier protocol for host to network signals * Added a requirement to define a key distribution protocol if signals are encrypted Any feedback is appreciated! Thanks, Tom -- Forwarded message - From: Date: Wed, Oct 4, 2023 at 7:01 AM Subject: New Version Notification for draft-herbert-host2netsig-00.txt To: Tom Herbert A new version of Internet-Draft draft-herbert-host2netsig-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-host2netsig Revision: 00 Title:Host to Network Signaling Date: 2023-10-04 Group:Individual Submission Pages:25 URL: https://www.ietf.org/archive/id/draft-herbert-host2netsig-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-host2netsig/ HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-host2netsig Abstract: This document discusses the motivations, use cases, and requirements for Host to Network Signaling. In Host to Network Signaling, 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
