Hi, On Tue, Feb 3, 2009 at 9:06 AM, Richard Graveman <rfgrave...@gmail.com> wrote: > Thanks. Your text is fine. The point was raised that we may not want > both parties redirecting at once. In your use cases, is it always the > IKEv2 responder that would redirect?
Yes. It is always the responder in the client-gateway scenarios. Vijay > > Rich > > On Tue, Feb 3, 2009 at 11:27 AM, Vijay Devarapalli <dvi...@gmail.com> wrote: >> Hi, >> >> On Mon, Feb 2, 2009 at 10:20 PM, Richard Graveman <rfgrave...@gmail.com> >> wrote: >> >>>>> I just read this draft and think your idea is useful. I have one >>>>> question (please excuse me if it's been answered): >>>> >>>> Its not been brought up before. But from the beginning the focus for >>>> this draft has always been on IKEv2 client-gateway scenarios. >>>> >>>>> Is there anything special about VPNs (or MIPv6) that limits the use of >>>>> this? Could you just say "IKEv2 Initiator" instead of "VPN client" and >>>>> "IKEv2 Responder" instead of "VPN Gateway" everywhere? >>>> >>>> The mechanism proposed in the draft can be used between any IKEv2 >>>> initiator and responder without any changes to the protocol. >>> >>> Thanks for the clarification. I think this is worth saying. >> >> I added the following to the Introduction section. >> >> The Re-direct mechanism described in this document is mainly intended >> for use in client-gateway scenarios. However, the mechanism can also >> be used between any two IKEv2 peers. The IKEv2 responder can re- >> direct the initiator to another responder with no changes to the >> mechanism described in this document. >> >> Is this sufficient? >> >> Vijay >> >> >>> >>>>> I have uses for IKEv2 that are neither VPNs nor MIPv6 and could >>>>> possibly benefit from this, but the terminology is somewhat >>>>> constraining. >>>> >>>> If you don't mind, can you share those use-cases/scenarios with us? I >>>> can't imagine a scenario where a re-direct would be useful between two >>>> IKEv2 peers. >>> >>> Sure. My "client" and "server" happen to be running a peer-to-peer >>> signaling protocol to handle GMPLS provisioning. It's a peer-to-peer >>> protocol, because sometimes you "get a phone call" as well as "make a >>> phone call." The "server" at the so-called Provider Edge (PE) has as >>> natural an application of redirect as the remote-access-VPN case >>> (planned downtime, load balancing, etc.) >>> >>> Regards, Rich Graveman >>> >> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
