On Tue, 03 Dec 2013 19:40:52 +0200
Yaron Sheffer <yaronf.i...@gmail.com> wrote:

> We would like to ask people who are *not* authors on any of the
> solution drafts to send a short message to the list, saying which of
> the three they prefer, and a few reasons for their choice.
> 
> A quick process reminder: once we adopt a protocol, it becomes the 
> starting point for the working group document. The WG can change the 
> editor team and is free to make material changes to the protocol
> before it is published as RFC.

My preference is on draft-detienne-dmvpn-00 to be used as a BASIS:

- The model is layered properly.

  - It does not try to make IKE a routing protocol, or SPD a full
    blown routing table.

  - Existing routing protocols can be used to setup active/backup
    gateway nodes or multipath routes for given prefix, as well as
    multicast routing (all these and more without additional IKE
    extensions)

- Dynamic routing of prefixes, allowing simpler and more flexible
  hub-to-hub configuration. 

- Multiple inter-operable implementations exists.

- Large installations exists, proving scalability.

Granted, the current draft misses still a lot of details. Especially
useful would be to have exact specification on how "thin" client can
work without routing protocols (e.g. mode config push of static
routes), how to setup NHS topology, what security measures are needed
to make sure nodes cannot impersonate someone else.

DMVPN properly addresses the complex requirement in RFC7018 2.2.
"[...] the routing implications of gateway-to-gateway communication
need to be addressed." which I think is one of the hardest issues here.

- Timo

PS. Please do not reply to this email. It merely reflects my personal
preference and opinion as requested. Non-authors can freely write in
reply to the original poll explaining why they like something else;
authors can freely update their drafts and publish them on separate
thread.

And yes, I have bias towards DMVPN having implemented parts of it.
But I believe similar bias exists when IKE implementers prefer doing
everything in IKE.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to