Hi Pascal,
> Please consider those options, and come discuss them at 6Lo: > > Option 1 considers that a network where this specification applies > is physically separate from a network where the Mesh Header > defined in [RFC4944] is used. With that assumption, the Mesh > Header dispatch space can be reused. A variation is proposed > whereby the NALP pattern 00xxxxxx is reused instead of the Mesh > Header pattern. > The group has considered this option extensively, and there has been consistent push-back, disapproval, and dissent. Repurposing NALP (Not A LowPan) is clearly problematic -- there MUST be a way for proprietary 15.4 (or other link) protocols to live in parallel with 6lo. I'm not sure why this repurposing proposal keeps coming back and getting characterized as the "first option". There are many other technical solutions, many quite simple and natural extensions to 6lo architecture, that don't have the same push back: defining a new compressed next header dispatch code for example. Option 1 generally describes solutions that "fork 6lo" into two versions: v1 (currently defined) and v2 (repurposed dispatch for RPL protocol) with no way to discern which version is being used. To the extent that 6lo is an approved standard, forking it violates IETF conformance policy, unless like IP, there is a version nibble, as IP uses to specify IPv4 or IPv6. If IPv4 and IPv6 had to be in physically separate networks that would be very complex to manage, and arguably wouldn't work well. Martin
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
