Dear All, This email presents some comments regarding to the draft-singh-6lowpan-global-connectivity-00, I have found some issues which could be commented face to the meeting of tomorrow and the future improvement of the draft.
First of all, this new draft presents with respect to "6lowpan-global-connectivity-00.txt", some comments regarding to issues,which are not addressed in the mentioned draft, for issues such as AID size, AID mechanism, and mobility support. First of all, in this new consideration for AID, it is considered the no inclusion of AID for source address, since this could be determined from stateless auto-configurability characteristics of IPv6 address, and also because in case of mobility or multiples GWs, it could change its AID for the source address frequently. I consider that this assumption regarding to change of Locator (IP address for the source node) should be analyzed deeply, since in some situations it is not so obvious to avoid the use of source AID, for example when host ID from global IP is not being defined with autoconfiguration based on link layer addressing, whose assumption is not so clear for global IPs. 2- Regarding to the mobility issues, where a Mobile Node changes of GW, this new GW has not knowledge about this mapping. This issue is not well addressed, since in mobility one of the most important steps in "binding transfer", where it is transfered the context information, sessions information and pending packets from the previous GW to the new one, therefore part of the information to be transfered is the information presented in the Table 3, in Section 2.4, which can avoid this unknown of the AIDs. 3- Section 4.1.3 comments that are defined messages for AID management such as AID update message, AID request message, IPv6 update message, and IPv6 request message, in order to synchronize the knowledge between node and GW. This is quite obvious that this signaling, presents probably more overload that the bytes reduced in the header compression. Therefore, it should be considered that AID is generated in an automatic way from GW and MN, for example with a hash function. With respect to aliasing, since the table 3 considers the concrete node, this reduces considerably that possibility, and only in case of aliasing should be considered some kind of common mechanism such as add 1 to the value, since the node also is going to detect the mentioned aliasing, it can be easily solved. Remark, that or AID is automatically managed and generated, or whether it is required AID update messages or equivalents, the performance of this solution is highly questionable. 4- Section 3.2.1 and 3.2.2 comment the mechanism followed when the AID is not found etc. This discussion has not sense, since 1- such as mentioned it needs to be automatized and 2- the mentioned des-synchronized should be analyzed deeply, since probably several of the scenarios which requires this message are because some problem has happened, other way it should be syncronized with the basic mechanism, and such as mentioned for mobility it is also synchronized. 5- Figures such as Figure 4 should be fixed, since they are not well presented. 6- Figure 8 presents that AID size is flexible, I think this is wrong, since this makes more complex the mechanism to determinate the AIDs in an automatic way, in addition it can bring more discussion about how to update previous BIT fields for the tables when the AID size is dynamically increased etc. 7- I consider that the optimizations should focus on draft-ietf-6lowpan-hc-15, which is in case of changes, where should be applied, instead of RFC4944 which is going to be replaced in a short time. 8- Finally, I would like remark that AID idea could be an interesting option for HC, but it should be deeply analyzed, and first of all, it should be analyzed the relation between the proposed AID with the field ""Area context site" used for Header Compression, in order to reach a higher compression, since that context field is currently being used for Header compression and in the 6CO option from Neighbor Discovery, and it could make more simplex and effective the AID field. Tomorrow in the meeting, it can be discussed some of these issues in the minuted assigned to this draft. Best regards, Antonio Jara
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
