Hi Mark, Thanks for the interesting usecase example. Please see in-line.
-----Original Message----- From: Mark ZZZ Smith [mailto:markzzzsm...@yahoo.com.au] Sent: Wednesday, August 21, 2013 1:56 PM To: Samita Chakrabarti; 6...@ietf.org; 6...@ietf.org Cc: Erik Nordmark (nordm...@acm.org); pthub...@cisco.com Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted Hi, I haven't had a chance to do a thorough read though, however I haven't been able to find where the following scenarios is dealt with. In a pure energy efficient scenario, say there are two NEAR routers on the link (NEAR1, NEAR2). An EAH host (EAH1) at bootstrap chooses NEAR1, registers its addresses and uses NEAR1 as its egress router for off-link traffic. For the return traffic (i.e, off-link traffic coming onto the energy efficient segment), what occurs if the upstream network chooses to use NEAR2 to try to forward traffic to EAH1, as the upstream network considers NEAR2 rather than NEAR1 to be closer to EAH1 e.g, because of a smaller IGP metric, or the traffic source link is directly attached to NEAR2? ===> You are right. The document does not clearly handles this case. However implicitly, an EAH can register with multiple routers in the network. But in order to add router policies ( in this case NEAR1 forwards northbound-only, NEAR2 forwards southbound only) and synchronize that with EAH, it needs some more work [ perhaps some additional option with the registration]. Pascal has indicated the backbone router draft function. This document tries to be generic and provides hooks for further enhancement for constrained nodes running IPv6. In my understanding, NEAR2 wouldn't have knowledge of EAH1, because EAH1 has only been registered with NEAR1. So it would seem that currently the only choice is for NEAR2 to drop those packets. ===> Please see above. Further to this two or more NEAR scenario, even if the upstream network always considers NEAR1 to be the closer to the EAHs, if the NEARs are protected by a redundancy protocol such as VRRP, when VRRP switches from using NEAR1 to NEAR2, how does NEAR2 acquire address registration information? Would it be considered a EAH bootstrap event, so that all of the EAHs have to go through selection and then registration of a NEAR? While I think that would work, it would seem to be defeating the purpose of having a redundancy protocol like VRRP which tries to make switching over between routers nearly if not ideally transparent to downstream hosts. ===> We have not thought about interaction with VRRP. Good point. We should discuss that off-line to understand the scenario and its applicability in this document. Best regards, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
