> On Aug 2, 2018, at 1:06 PM, Ole Troan <[email protected]> wrote: > > Joe, > > >>>>>> I am not ignoring them; I'm claiming that they all have the same >>>>>> inherent deployment and implementation limitations. >>>>>> >>>>>> Just because operators/vendors "want" to do otherwise does not make it >>>>>> possible. >>>>> >>>>> There was IETF consensus behind those documents (A+P). >>>> >>>> You mean the *experimental* RFCs that describe an approach that doesn't >>>> update RFC791? (i.e., RFC6364?) Or something else? >>> >>> The protocol specifications of A+P are all standards track. >>> RFC7596, RFC7597, RFC7599. >>> >> Thanks for the refs. Note that none of those update RFCs 791 or 1122, so if >> frag breaks them, then it's their error. > > I wouldn’t be surprised if there were disagreements about that interpretation > of “updates”.
That’s not how it works, any more than there are disagreements over “standards track”. Those docs are either compatible with existing specs, update those specs, or are in error. RFC791 takes precedence, having come earlier - until it is overridden by an update. > >> It also looks like (at first glance at least) these devices work only when >> there isn't multipath between the back and front side. > > The A+P routers are stateless and do support multipath. Including traffic > does not need to be symmetric. > That’s the main selling point for A+P, that you don’t need per flow state in > the core of the network. The +P part doesn’t seem like it’s compatible with fragmentation, though - yet it doesn’t update RFC791 to deprecate it throughout the Internet. The only conclusion is that A+P should never be deployed in the presence of fragmentation - not that it should drop fragments, nor that we should consider deprecating fragmentation to address that flaw. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
