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. 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 - 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). Frank > -----Original Message----- > From: Frank Brockners (fbrockne) <[email protected]> > Sent: Dienstag, 1. Oktober 2019 10:22 > To: Frank Brockners (fbrockne) <[email protected]> > Subject: Re: [Int-area] New Version Notification for draft-herbert-ipv4-hbh- > destopt-00.txt > > Joe, > > > On Sep 28, 2019, at 8:05 AM, Joe Touch <mailto:[email protected]> > wrote: > > > > Hi, David, > > > > Although I appreciate new interest in trying this experiment, that's not > > what I > was asking. > > > > My understanding of the logic is as follows: > > - IPv4 in-header options aren't supported > > - so let's make a version of IPv4 options inspired by IPv6 HBH options > > > > That logic only works if IPv6 HBH options were a success. I'm asking for > anyone to point to a success case. > > > > If there are no widely deployed IPv6 HBH options at this point (given > > they've > been available for two decades), this is not a useful approach to mimic in > IPv4. > > To add, my preference would be see effort go into making a few IPv6 HBH > options work on the Internet, vs. trying to update all IPv4 implementations to > support a similar mechanism for IPv4. > > Bob > > > > > > Joe > > > >> On Sep 27, 2019, at 7:11 AM, Black, David <mailto:[email protected]> > wrote: > >> > >> There may be a relatively contained early-adopter opportunity to try > something in this area of IPv4 options - Deterministic Networking (DetNet - > detnet WG) is using 6-tuple match (2 x IP address, L4 protocol [e.g., TCP, > UDP], 2 > x port, DSCP) to pick off traffic flows that go through the DetNet data plane > in > routers instead of the default data plane. DetNet appears to nee IOAM in > order > to ensure that OAM traffic goes through the DetNet data plane - if the DetNet > data plane is down, having an OAM continuity check report that the default > data plane is functional turns out to be worse than useless, as it has the > potential to mislead the operator about where and what the problem is. > >> > >> Thanks, --David > >> > >> From: Int-area <mailto:[email protected]> On Behalf Of Joe > Touch > >> Sent: Thursday, September 26, 2019 11:17 AM > >> To: Tom Herbert > >> Cc: int-area > >> Subject: Re: [Int-area] New Version Notification for > >> draft-herbert-ipv4-hbh- > destopt-00.txt > >> > >> [EXTERNAL EMAIL] > >> > >> Hi, Tom, > >> > >> > >> On Sep 26, 2019, at 7:54 AM, Tom Herbert > <mailto:[email protected]> wrote: > >> > >> Joe, > >> > >> Your arguments seems to be more against use of Hop-by-Hop options in > general. > >> > >> My concern is that you are trying to copy what appears to be a failed > approach. I have no position on whether it *should* fail, but more rather > that it > *has*. > >> > >> I.e., I'm following your logic: > >> - IPv4 options are not deployed and so are not useful > >> > >> I agree completely. But isn't the same true for IPv6 HBH? > >> > >> If not, can you provide *an example of a widely deployed HBH option in > current use*? > >> > >> > >> Last time I checked, Hop-by-Hop options have not been deprecated by IETF. > Neither do I see why it's incumbent on us to show they're widely deployed as a > prerequisite to developing them. Additionally, what is the evidence that > they're > not widely deployed-- for instance do we _know_ for a fact that they're not > deployed in some large private network? (IOAM is targeted to closed networks). > For that matter if we only are allowed to work with protocols that are widely > deployed, then how could we ever work on new protocols? E.g. why should we > develop new UDP options when they currently they have no deployment. > >> > >> Agreed, but your logic leads to the conclusion that you should be using > >> IPv4 > options (unless you show that space is a problem) first. > >> > >> If that is a problem, then an IP protocol is sufficient, as it was for > >> IPsec. > >> > >> I see no need for an IPv4 framework to address a problem that doesn't need > that *framework*. > >> > >> Joe > > > > _______________________________________________ > > Int-area mailing list > > mailto:[email protected] > > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
