Tom Herbert <t...@herbertland.com> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to