Lou, Thank you for your comments, more inline.
Mike. Mike Sullenberger, DSE [email protected] .:|:.:|:. Customer Advocacy CISCO > -----Original Message----- > From: Lou Berger [mailto:[email protected]] > Sent: Friday, October 18, 2013 3:29 PM > To: [email protected] > Cc: IPsecme WG > Subject: Some comments on draft-detienne-dmvpn-00 > > Hi, > I have the following comments/questions on the draft: > > - Why allow IPsec tunnel mode? Is there a case where it provides some value? [Mike Sullenberger] You are correct that IPsec tunnel mode is not really needed and transport mode is far recommended and preferred. There are a couple of rare situations where tunnel-mode could help, like when separating the GRE/NHRP tunneling and IPsec encryption onto separate nodes, these cases are not recommended, but we thought we should leave in the possibility. > - Do you want to recommend omitting the GRE checksum? [Mike Sullenberger] Good idea, we definitely don't use the GRE checksum, and I don't think it provides any value so we should recommend omitting it. I think this is also the case for most of the other optional GRE header attributes. Though, the GRE Tunnel Key must be allowed, handled and provided. > - I think the draft should discuss what happens when the best route moves > from one spoke to another spoke. Both the cases where the host/prefix is > still reachable via the original spoke and when it isn't should be covered. As > should avoiding blackholes, and any periods of suboptimal forwarding. [Mike Sullenberger] We can add some more discussion around this point. The main feature here is that this is handled by the routing protocol that is running over the DMVPN tunnels. The routing protocol will redirect the data packets via different tunnels and/or spokes as the routing is updated. Note, if static routing is used then you lose this capability. > - I think the draft is missing a description of how/when NHRP Purges are > used, e.g., resulting from interactions with routing. (Yes there is an overlap > with the above, but it depends a bit on your solution.) [Mike Sullenberger] As you have noted, NHRP purges are used to keep the distributed NHRP database in sync. If a local node loses access to a destination that it has previously replied with itself as the egress point in an NHRP mapping (and the entry hasn't timed out yet) then it will generate an NHRP purge and send a copy to each requester (recorded when it sent the original reply). This will then clear out these now invalid mapping entries on the remote nodes and trigger them to find an alternate path if available. Note, this is basically what is described in NHRP (RFC2332), we didn't really want to duplicate this in this RFC, but it could be added. > - I the draft should discuss the NHRP scaling considerations that are > important in implementation and deployment/operation. (Basically the > solution is proposing network wide ARP.) You already have a teaser on this > when you mention rate limiting. [Mike Sullenberger] We can certainly do so. In DMVPN deployments we haven't really found that NHRP scaling has been an issue. Usually we ran into either Routing protocol or IPsec scaling issues first. It is correct we do mention a couple of places about rate limiting triggering or sending of NHRP messages, mainly because it wasn't felt that it was useful to continue to "bother" another node if it was working on the previous request, which was the same as the one to be sent again. Note, we do have mechanisms for retransmission and back-off of messages. Again some of this is covered in the NHRP RFC. > - NIT/editorial: If section 4 is your "Solution Overview", where is the > solution specification? More seriously, I found parts of this section more of > a narrative of an example than a protocol specification. [Mike Sullenberger] Yes, I think this needs to be cleaned up. Since a lot of what we do with NHRP is covered in the NHRP RFC we didn't want to duplicate too much here, but we can certainly make a more clear solution specification. I think the solution overview section is also useful since, a walk through can help people to understand how the solution is intended to work. Many times I find it hard with just solution specifications to get a real feel for how things go together. > - NIT: Assuming the Indirection Notification described in section 4.3 is the > same as the NHRP Traffic Indication covered in 5.1, can you align the names > and fix the reference in 4.3? [Mike Sullenberger] Yes, thanks for noting this. We tend to use those terms interchangeably, but we should be more consistent here. > > Thanks, > Lou _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
