On Fri, Jul 27, 2018 at 9:25 AM, Fernando Gont <[email protected]> wrote: > On 07/27/2018 05:15 PM, Tom Herbert wrote: >> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont <[email protected]> wrote: >>> Hi, Joe, >>> >>> On 07/26/2018 04:14 AM, Joe Touch wrote: >>>> Hi, all, > [....] >>> >>> Side coments: >>> >>> It would all seem that there are two operating environments: >>> * Controlled environments, where you can somehow make all this work >>> * Public internet, which is more of a "fingers crossed" thing (if anything). >>> >>> I'm not saying that I'm happy with the outcome, but rather that I think >>> that from an engenering point of view, it all looks like this ship has >>> sailed, and we should probably figure out how to deal with those cases >>> where fragmentation is actually needed. >>> >> Fernado, >> >> Couldn't that same line of thinking be applied to several other >> protocol features? > > Yes, indeed. > > >> So has the ship sailed for out ability to ever use >> extension headers or any protocol other than TCP (and sometimes UDP)? > > It would seem that that's the case, yes. > > >> Maybe documents that recommend operational workarounds should >> distinguish problems that inherent in the protocol from those that >> have arisen because of non-conformant implementation. It's true that >> calling implementations that probably won't help to fix what is out >> there, but maybe this could help prevent new instances of >> non-conformance. > > I kind of agree with you. That path from spec to implementation is what > you'd call engineering (or what others might call "taking shortcuts", etc.). > > For example, what happens with EHs has a lot to do with engineering: > they could be made to work (e.g., remove performance impact), but > devices would probably be more expensive. Folks buying gear wouldn't pay > for something that its not used in practice, and vendors wouldn't just > "improve" the boxes for free. -- yeah, you could argue that "hey, there > shouldn't be penalties for EHs, since they are part of the core IPv6 > spec" -- but, while probably correct, that will not change reality. > Fernando,
The irony is thatxtension headers (and alternative protocols as well), including fragmentation, aren't supposed to have to "be made to work" in intermediate devices. With the exception of Hop-by-Hop options they are supposed to be ignored by design, and even in the case of Hop-by-Hop options RFC8200 relaxed the requirements so that they can be ignored. Extension headers are considered problematic only because of ad hoc assumptions made for "value add", non-standard features implemented in intermediate devices. > Not that I like the situation, but... I think the least we can do is to > do a reality check wrt how things are supposed to work vs. how they > actually work. > > For this particular case, this I-D makes that point for fragmentation: I > I think we all agree that fragmentation is fragile -- making that point > clear at least raises awareness of the problem, and might trigger some > action on the topic (whether to correct the issue, or to circumvent it). > Right, but I still think that we should be more clear about the root origin of problems and blunt in requesting that non-conformant implementations get fixed. For instance, as I mentioned the ECMP hasing problem with fragmentation is entriely solvable if only intermediate devices will use flow label instead of trying to find ports for a hash. Fixing devices to support this reasonable and should be low cost. IMO, use of flow label for ECMP should be a strong recommendation made in this draft. Tom > Thanks, > -- > Fernando Gont > e-mail: [email protected] || [email protected] > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
