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

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. 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.

Lets try to hear from Lou on this.

>
> 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
>