Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02

Hi Vishwas,

See a couple of notes inline.

On Dec 13, 2012, at 9:54 AM, Vishwas Manral <vishwas.ietf@gmail.com> wrote:

> Hi Brian,
> 
> Thanks a lot for your comments and sorry I did not reply immediately. I have still been waiting for the version 2 to upload. I have sent it to the internet-drafts@ietf.org address.
> 
> My comments are inline and will be updated in version 03. We could do it in version 02 too if it does not get posted soon enough.

Updating version 03 is fine with me. I was a bit late with the comments.

> The only issue I have is with the L3VPN comment and would want Lou Berger's opinion on it, as he thought the text would add value there (though if you see previous comments I am more of the opinion similar to yours).
> 
> On Tue, Dec 11, 2012 at 12:30 PM, Brian Weis <bew@cisco.com> wrote:
> Hi Steve & Vishwas,
> 
> Here are a couple of comments on the proposed -02 sent a few days ago.
> 
> Requirement 1 says "gateways and endpoints MUST minimize configuration changes when a new gateway or endpoint is added, removed or changed." While I certainly agree with the sentiment behind the requirement, this statement is about as strong as "gateways and endpoints MUST perform well", or "gateways and endpoints MUST be easy to use". In other words, it isn't a testable assertion that can be evaluated. Also the body of the document says "it is desired that there be minimal configuration on each gateway", which does not support a MUST requirement. This ought to be a SHOULD rather than a MUST.
> Changed the MUST to a SHOULD. 
> 
> 
> Requirement 8 has gone through several versions, but I think it could still be made clearer. It first requires Gateways and endpoints "to work when they are behind NAT boxes", and then makes a bunch of necessary exceptions. The following replacement text attempts to make the same points as the original but might be clearer:
> 
>    8.  Gateways and endpoints MUST have the capability to participate
>    in an AD VPN even when they are located behind NAT boxes. However,
>    in some cases they may be deployed in such a way that they will not be
>    fully reachable behind a NAT box.  It is especially difficult
>    to handle cases where the Hub is behind a NAT box.  Where the
>    two endpoints are both behind separate NATs, communication between
>    these spokes SHOULD be supported using workarounds
>    such as port forwarding by the NAT or detecting when two spokes
>    are behind uncooperative NATs and using a hub in that case.
> VM> Updated. 
> 
> Requirement 14 says "The ADVPN solution MUST support Provider Edge (PE) based VPN's". This requirement seems unfair to the end point use cases in 2.1 and 2.3, or even gateway-to-gateway ADVPN solutions that have nothing to do with L3VPNs! I think you're trying to say it must be possible to build an ADVPN solution that meets the requirements of L3VPN, which I have no problem with but I don't think think this it's a fair requirement to put in Section 4. Is there anything beyond the new text you added in 2.2 regarding L3VPN that needs to be said?
> VM> No I did not add any extra text for L3VPN besides this one. The idea was that if IPsec over GRE as PE to PE communication tunnels the ADVPN technology should not preclude such a solution.Like I have said earlier I do not have strong opinion regarding this requirement. Lou thought this should be there and I asked the list if there were objections to this, and I did not hear anyone object, so I added it.
>  

Thanks for the background. It should be possible to address Lou's concern underlying  concern without adding a requirement that is onerous for ADVPN use cases where L3VPN doesn't apply. The Section 2.2 text I referred to is "There is also the case when L3VPNs operate over IPsec Tunnels." Maybe that could be expanded into a new paragraph in lieu of a requirement? I notice the use of lower case "must" is used in this section. 

> Lets try to hear from Lou on this.

Lou, would something like the following text in Section 2.2 be a satisfactory replacement for Requirement 14?

    There is also the case when L3VPNs operate over IPsec Tunnels, 
    for example Provider Edge (PE) based VPN's. An AD VPN must
    support L3VPN as an application protected by the IPsec
    Tunnels.

Thanks,
Brian

> 
> There's a couple remaining nits:
> 
> Section 2.2: s/A fully meshed solution is would/A fully meshed solution would/
> Section 4: s/This sectiondefines/This section defines/
> VM> Updated.
> 
> Thanks,
> Vishwas 
> 
> Thanks,
> Brian
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 