> > On 07/ 6/10 04:24 AM, Daniel Gavelle wrote: > > If there are multiple LBR's, with different PIO's, the network still > > needs a single CO. For example, a possible Smart Grid network would be > > to have: An LBR in the meter with a PIO of the back haul to the > > utility and a prefix assigned by the utility. A second LBR in a > > broadband router with general access to the Internet and a prefix > > assigned by an ISP. The LBRs would need to be configured to cooperate > > correctly so there is only one set of context information in the > > network but each LBR may be advertising a different PIO. > > > > I am not sure in this case if both LBRs advertise both PIO's or each > > advertises its own PIO. If both advertise both PIOs, the optimisation > > is lost and the CO needs to be carried explicitly. If each just > > advertises its own PIO, there is potential for confusion as two > > different default COs may be derived. > > The fundamental issues around such deployments are business issues. > Suppose one could get all the technical matters worked out, and then one > day I find that the network is not working. Do I call the Electrical Company or > the ISP? What prevents their support lines from just pointing fingers at the > other company? > > On the technical side there are issues even if CO isn't used. For instance, I > expect the service providers to follow best security practices and do ingress > filtering on the source addresses. That means that if a host picks a source > address from the ISP prefix, then those packets better go out via the ISP's > 6LBR, and vice versa. > > If we can solve that set of business issues and the ingress filtering issue, then > how to handle CO coordination might fall out as a result; I would expect any > solution to the issues require some coordination between the Electrical > Company and the ISP.
[Pascal] All true. RPL expects a different instance for different 2 service cies. In the simplest case, we'd end up with 2 LBRs, one serving the Electrical Company and one the ISP. Each LBR spawns its own DODAG. Some relay routers in the home belong to both instances to support both the electric lights and the security monitoring. So packets are tagged to follow the right topology. Whatever a LBR injects is contained within the scope of the instance it injects it into. It appears that the CO dissemination would benefit from the same model. Just like we can map the abstract TID in the RPL path sequence, would there be a way to define an abstract ND context ID that could map into the RPL instance ID? It appears that such context ID could help scope the dissemination process in ND. Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
