> On Oct 1, 2019, at 1:45 AM, Frank Brockners (fbrockne) <[email protected]> > wrote: > > Expanding from Bob's preference: IMHO it would make sense to explore what we > can solve with extension headers (HbyH and DO) - rather than argue the past > or judge from the past. Hardware is changing - and what used to be the case, > does not necessarily hold true in present or the future.
Sure, but... > Back in the hackathon at IETF 100 we even showcased a hardware implementation > of what is ultimately an extension header use-case, see e.g. > https://www.globenewswire.com/news-release/2017/11/10/1195153/0/en/Barefoot-Networks-Collaborates-with-Cisco-to-Demonstrate-In-situ-Operations-Administration-and-Management-IOAM-Showcasing-the-Power-of-Programmable-Forwarding-Plane-Technology.html > > > Providing a holistic implementation in hardware for recent efforts that > leverage EH (like PDM, IOAM, etc.) would become easier if we had a protocol > independent approach to EH. This would mean that e.g. for IOAM we could use > almost the same implementation for v4 as we'd do for v6 I think you’re missing Bob’s point, which I’ll expand on: a) you can already proceed for IPv6; show us it has been deployed b) as you note, IPv4 != IPv6. “almost the same” has a lot of variants... > - protocol specific efforts would be limited, and as a nice side effect we'd > avoid more complex encapsulations for IOAM in IPv4 which we'd need to use > otherwise (e.g. one proposal is to use GRE - which doesn't make things > easier). I can see how GRE might be more complex, but not why a HBH code point is needed (e.g., vs. just an IPv4 protocol code point and using the IPsec approach). Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
