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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
