Re: [pcp] Comments on draft-ietf-pcp-optimize-keepalives-00

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Mon, 02 December 2013 09:55 UTC

Return-Path: <tireddy@cisco.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DBA1AE0F9 for <pcp@ietfa.amsl.com>; Mon, 2 Dec 2013 01:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Level:
X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0auUKJtTLb5I for <pcp@ietfa.amsl.com>; Mon, 2 Dec 2013 01:55:53 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 04E4B1AE08F for <pcp@ietf.org>; Mon, 2 Dec 2013 01:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20282; q=dns/txt; s=iport; t=1385978151; x=1387187751; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fysqglMA69BxMIae0ChGP6dg0othFeJUn0tYZnt3Ehc=; b=dGDcO+fGMJypsWeWJI6MxSqbKhDnklPj6RAtuoG+CQ+/idMHKVzKzbrH iNag7WggJKpT9mOBRdhhq13wUwNr+yWxpyFqr7EqDMsR2PiDnT0SADXr6 X7/PhFO5gEFql9bfMWu5iqpJqzWRaqnm1ELHfg63amiQUeh1oto1+CkPY s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsFAPxYnFKtJV2Z/2dsb2JhbABZgkNEOFO4V4EhFnSCJQEBAQQtXAIBCBEEAQELFgcHMhQJCAIEARIIh3m/IheOVzcBgyCBEwOJCqEdgymCKg
X-IronPort-AV: E=Sophos;i="4.93,809,1378857600"; d="scan'208,217";a="3582019"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 02 Dec 2013 09:55:43 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB29thxX030979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <pcp@ietf.org>; Mon, 2 Dec 2013 09:55:43 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 03:55:42 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: "Prashanth Patil (praspati)" <praspati@cisco.com>, "Reinaldo Penno (repenno)" <repenno@cisco.com>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] Comments on draft-ietf-pcp-optimize-keepalives-00
Thread-Index: AQHOzo/D4iCDjuIyjkqi4oYMprmUs5pA62nQ
Date: Mon, 02 Dec 2013 09:55:42 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A24271415@xmb-rcd-x10.cisco.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06040B7320E5@xmb-rcd-x04.cisco.com> <B235506D63D65E43B2E40FD27715372E1CEFB7A4@xmb-rcd-x07.cisco.com>
In-Reply-To: <B235506D63D65E43B2E40FD27715372E1CEFB7A4@xmb-rcd-x07.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.39.66.116]
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A24271415xmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [pcp] Comments on draft-ietf-pcp-optimize-keepalives-00
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 09:55:56 -0000

Hi Reinaldo,

Responding to your comments in the pdf

Comment1> The application keepalive would keep the state alive in the FW/NAT as well, right ? This sentence seems out of place here.

Reply1> No. The time interval to send keepalives for maintaining state on the Application Server could be greater than FW/NAT mapping lifetime. In this case application keepalives will not maintain the FW/NAT mappings. For example in case where application keepalive interval every 60 minutes is required whereas FW/NAT keepalive interval is 30 minutes.

Comment2>  I believe this section should have an introduction and two sub-sections. One sub¬section should be called "PCP based detection" and have the first paragraph part of it since it only talks about PCP based detection. The second sub¬section should talk about application based detection.

Reply2> Agreed, updated the draft.

Comment3> Then the title of this section needs to change to "NAT Topologies and Detection"

Reply3> Yes, changed the title.

Comment4> Suggest to change title to "Detection of..". But more generally, I wonder if this discussion of detection belongs in this draft. Can this  section be removed ?

Reply4> Yes, changed the title. In the previous WG discussions there was specific ask to add this section explaining the "Detection of PCP Unaware Firewalls".

Comment5> Needs RFC reference
Reply4> RFC reference is already provided

Comment 6>It will insert if it supports this experimental RFC, if it has another IP address, etc. I believe some more clarification is needed.
Reply6> Agreed, updated the text.

Comment 7> Application layer protocols ?
Reply7> Yes

Comment 8> This is all STUN, why this is in this draft ?
Reply8> In the previous WG discussions there was specific ask from Dave to add this section and explain the Keepalive Interval determination procedure when PCP unaware Firewall or NAT is detected.

-Tiru.
From: Prashanth Patil (praspati)
Sent: Monday, October 21, 2013 3:51 AM
To: Reinaldo Penno (repenno); pcp@ietf.org
Subject: Re: [pcp] Comments on draft-ietf-pcp-optimize-keepalives-00

Hi Reinaldo,
Sections "3.3 Detect PCP Unaware Firewall" and "4. Keepalive Interval Determination Procedure when PCP unaware Firewall or NAT is detected" were added based on Dave's recommendation.

Section 3.3 does not introduce anything new, it only provides an example on how a PCP unaware firewall can be detected using STUN. Section 4 is also a recommendation on what can be potentially done if a PCP unaware firewall was detected.

Dave, what are your thoughts on this?

-Prashanth

On 11/10/13 4:45 PM, "Reinaldo Penno (repenno)" <repenno@cisco.com<mailto:repenno@cisco.com>> wrote:

I reviewed this draft for a possible WGLC but I do not think it is ready.
My summary is that this draft has lots of text related to detection of PCP
unaware NAT/FW using STUN which IMO belong in a separate draft, or some
other document since it is generic text. Maybe the WG sees value in having
a separate document that talks exclusively about detection of PCP unaware
FWs.

This draft could just say "assuming all NAT/FW in the path are PCP
aware..." and take it from there since the goal is optimizing keep-alive
and not standardizing detection mechanisms.

Removing all detection text would make this draft quite short and easier
to understand its purpose.

Thanks,

Reinaldo