Joe, > On Sep 28, 2019, at 8:05 AM, Joe Touch <[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 <[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 <[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 <[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 > [email protected] > https://www.ietf.org/mailman/listinfo/int-area
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
