Hi Mike, Thanks for the response. See below...
On 10/23/2013 2:54 PM, Mike Sullenberger (mls) wrote: > Lou, > > Thank you for your comments, more inline. > > Mike. > > Mike Sullenberger, DSE > m...@cisco.com .:|:.:|:. > Customer Advocacy CISCO > > > >> -----Original Message----- >> From: Lou Berger [mailto:lber...@labn.net] >> Sent: Friday, October 18, 2013 3:29 PM >> To: draft-detienne-dm...@tools.ietf.org >> 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. > How does this work? As I understand it, NHRP is run inside the GRE tunnel so this means that the IPsec and GRE endpoints now need some way to communicate (for e.g., public ("NBMA") addresses and GRE/IPsec tunnel creation/removal coordination). Am I missing something? >> - 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 missed that the tunnel key MUST be "provided". Can you elaborate on this? I only see one oblique reference to it in the draft. >> - 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. For clarification: routing runs over the configured DMVPN topology, but not shortcuts, right? > The routing protocol will redirect the data > packets via different tunnels and/or spokes as the routing is > updated. I think your answer to my next question actually helps answer this one. So Section 6.1 of RFC2332 says: ... In such circumstances, NHRP should not be used. This situation can be avoided if there are no "back door" paths between the entry and egress router outside of the NBMA subnetwork. Protocol mechanisms to relax these restrictions are under investigation. Do you believe this restriction still applies? > Note, if static routing is used then you lose this > capability. Sure. > >> - 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. > okay, I think this comes back to where the draft says: > In this document, we will depart the > underlying notion of a centralized NHS. I think the part that's missing (or perhaps I just missed) is an explicit statement that an egress must follow the NHS procedures related to any issued Resolution Reply. >> - 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. > I guess it all depends on the number of routes in the system and reachability pattern at a particular spoke. I think when both are large, the use of per prefix soft state refreshes will prove problematic. I'm a bit surprised you've run into routing protocol scaling issues though, but that's certainly out of scope. >> - 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. > Avoiding duplicate specification is certainly goodness, but I think some additional pointers to when standard NHRP procedures are to be followed (or not) would be a valuable addition as part of the cleanup. Much thanks, Lou >> - 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 > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
