Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ipsecme-ad-vpn-problem-07.txt

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 9 Jul 2013 21:58:04 +0000

Hi Suresh,

Good comments.

* Section 2.3

The following sentence is a bit confusing. How does a mobile user
connect to a new gateway without reinitiating a connection? Can you
please clarify or reword.

"The mobile user ought to be able to discover and then connect to the
current most efficient gateway without having to reinitiate the connection."
VM> The idea here is that the connection doesn't get reinitiated and is never down, we move the connection between 2 IPsec gateways. I have changed the text as I see where you are coming from.

VM> A mobile user roaming on the Internet may connect to a gateway, which because of roaming is no longer the most efficient gateway to use (reasons could be cost/ efficiency/ latency or some other factor). The mobile user ought to be able to discover and then connect to the current most efficient gateway in a seamless way          without having to bring down the connection.

* Section 4.1. Requirement 5

Shouldn't there be a requirement here that states what kind of damage is
allowed and prohibited in case a hub node is compromised?
VM> The Hub is the central point in my view, which leads to the single point of failure. I think the solution will allow for multiple hubs (HP DVPN solution already does) and it uses AES-256 encryption etc. I think these however are elements of the implementation, not requirements. 

VM> I added the following as a requirement:
     There ADVPN solution SHOULD take care of now letting the Hub to be a single point of failure

* Section 4.1. Requirement 12

It is unclear what this requirement means. Is the requirement for the
solution to integrate with multicast routing protocols to come up with a
different (and optimized) multicast ADVPN topology or to simply allow
the advpn to carry (flattened out) multicast traffic?
VM> General solutions uses Multiple unicast as broadcast and that does not scale. What we are mentioning here is that the solution for traffic does not scale. The document that's why says:

VM>       The ADVPN solution SHOULD be able to scale for multicast traffic.

* Section 4.1. Requirement 14

Are there any special requirements that L3VPN poses on top of what is
required for carrying generic IP traffic? If so, can you elaborate here.
VM> No there are no special requirements. We got the comment from Lou Berger who felt we should explicitly state the same as the solution will be used in L3VPN use cases too. This is so that we do not exclude a use case when thinking of the solution.

Thanks,
Vishwas