Re: [pcp] FW: New Version Notification for draft-vinapamula-flow-ha-01.txt

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Wed, 13 August 2014 02:47 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 95B181A6FCF for <pcp@ietfa.amsl.com>; Tue, 12 Aug 2014 19:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level:
X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 0HbCSfHwgx4c for <pcp@ietfa.amsl.com>; Tue, 12 Aug 2014 19:47:16 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429C01A6F96 for <pcp@ietf.org>; Tue, 12 Aug 2014 19:47:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17234; q=dns/txt; s=iport; t=1407898036; x=1409107636; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=C/tWAe/UWr7Ae5nOxBTiCFNtXvLa1USaaHIBs3DhGG8=; b=MYRfuw4foUWVa7ZjkOGP58AcvjABsWlSeb3jcw3aBK4U2bsPhEGO/q7x LalT84Ys3U5daeMFnvwBwj9LWLy9pHsOx8XArmXBnUnQT2vNFiYrsrO9w PN5d7WlyMERu4zbLRvRUyT2Vw2n1kVN9I1xwlt6BpIT83ltFcrfzCZnRz 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiEFAPnQ6lOtJA2G/2dsb2JhbABQCoMNUlMEBIJ1yikKh0gBGXgWd4QDAQEBBAEBASARMQkJAgwGAQgRBAEBAQICBh0DAgQlCxQBBwEJAQQOBQgBiDkIBa88lUgXgSyNNQoFDxwWGw2CczaBHQWPCoIThCaITZMng1xsgQdB
X-IronPort-AV: E=Sophos;i="5.01,854,1400025600"; d="scan'208";a="347053232"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 13 Aug 2014 02:47:15 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7D2lFN7021247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 02:47:15 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 21:47:14 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Suresh Kumar Vinapamula Venkata <sureshk@juniper.net>
Thread-Topic: [pcp] FW: New Version Notification for draft-vinapamula-flow-ha-01.txt
Thread-Index: Ac+2oNv1R1HvUmsWSsSTlaq6Dxd2tw==
Date: Wed, 13 Aug 2014 02:47:14 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A28314D26@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.75.234.152]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/WPno8q0Ym_q5swvLcCSCyfPMHeg
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] FW: New Version Notification for draft-vinapamula-flow-ha-01.txt
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: Wed, 13 Aug 2014 02:47:18 -0000

> -----Original Message-----
> From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net]
> Sent: Tuesday, August 12, 2014 11:33 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: pcp@ietf.org
> Subject: Re: [pcp] FW: New Version Notification for draft-vinapamula-flow-
> ha-01.txt
> 
> 
> 
> On 8/12/14 1:35 AM, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
> wrote:
> 
> >> -----Original Message-----
> >> From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net]
> >> Sent: Tuesday, August 12, 2014 12:06 AM
> >> To: Tirumaleswar Reddy (tireddy)
> >> Cc: pcp@ietf.org
> >> Subject: Re: [pcp] FW: New Version Notification for
> >>draft-vinapamula-flow-
> >> ha-01.txt
> >>
> >> Thanks for your comments. Please see inline.
> >>
> >> On 8/8/14 1:22 AM, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
> >> wrote:
> >>
> >> >Hi Suresh,
> >> >
> >> >Comments:
> >> >
> >> >[1] What is the reason for updating the reserved field in the PCP
> >> >Common Request Packet Format ?
> >> >A new PCP option can also be defined to signal if it's a critical
> >> >flow or not.
> >>
> >> Suresh> Yes, a PCP option can also be used and we thought about it.
> >> Suresh> We
> >> were debating if option would be an overkill, as there is nothing
> >>negotiated  unlike other options, while indicating checkpointing. We
> >>are debating on the  use cases where bit is not sufficient and an
> >>option is required. Please let us  know if you think of cases where
> >>bit will not work.
> >
> >A new PCP option will help to add more fields for future use cases.
> I am not sure what fields can be added for future use. I agree it is better to
> have scope for extensions. We will work on it.

Okay.

> >
> >> >
> >> >[1b] It may help the client to know if the flow is check pointed or
> >> >not, this way the client can make a decision to prioritize the flows
> >> >accordingly when multiple interfaces with associated PCP servers are
> >> >involved.
> >>
> >> Suresh> A reserve bit in the PCP response can indicate that PCP
> >> Suresh> server
> >> honored PCP checkpoint request or not. Will update the draft.
> >> >
> >> >[1c] Success or fail response ((e.g. Quota exceeded) from PCP server
> >> >can also help the client to remove check pointing for some of the
> >> >existing flows so as to check point new flows.
> >> Suresh> Would response to 1b handle it?
> >
> >Yes.
> >
> >> >
> >> >[2] This document describes a mechanism for a host to signal various
> >> >   network functions' High Availability (HA) module to checkpoint
> >> >   interested connections through PCP.
> >> >
> >> >Comment> The above line is not clear.
> >>
> >> Suresh> Not sure what is not clear, What I meant to say here is, this
> >> document provides a mechanism to signal any network functions'
> >>(firewall  NAT IPSec etcŠ) high availability module for checkpointing
> >>interested  connections by host. If this is still not clear, can you
> >>please be more specific ?
> >
> >Client has no clue if network function have HA or not, instead let the
> >client just signal it's a critical flow or not.
> Yes, Client will indicate what flows are business critical through PCP.
> And PCP server will invoke interested network function's high availability
> module to checkpoint respective connection's state.

Works for me.

> >
> >>
> >> >
> >> >
> >> >[3]   Internet service continuity is critical in service provider
> >> >        environment.  To achieve this, most service providers have
> >>active-
> >> >        backup systems.
> >> >
> >> >Comment> Enterprise networks also typically deploy Active-Standby.
> >> Suresh> Ok will update document.
> >> >
> >> >
> >> >[4] For service continuity of those connections on backup
> >> >   when active fail, that corresponding state had to be checkpointed on
> >> >   the backup.
> >> >
> >> >Nit> Replace "fail" with "fails"
> >> Suresh> ok.
> >> >
> >> >[5]   Typically, this is addressed by identifying long lived
> >>connections
> >> >        and checkpointing state of only those connections that lived
> >>long
> >> >         enough, to the backup for service continuity.
> >> >
> >> >Comment> You may want to add that identification is also done by
> >> >Comment> DPI,
> >> >which fails with encrypted traffic.
> >> Suresh> ok
> >> >
> >> >[6]   2.  A connection may not be long lived but critical like shorter
> >> >       phone conversations.
> >> >
> >> >Comment> Replace "phone conversation" with "VOIP conversation"
> >> Suresh> ok
> >> >
> >> >[7]     3.  Similarly not every long lived connection need to be
> >>critical,
> >> >       say a free-service connection of a hosted service need not be
> >> >       checkpointed while a paid-service connection has to be
> >> >       checkpointed.
> >> >
> >> >Comment> Why would the application client differentiate and not
> >> >Comment> signal
> >> >that it's a critical flow in both the cases. Are you envisioning
> >> >that the application client software makes this decision internally
> >> >or it involves human intervention from some UI to signal to the
> >> >network that it's a critical flow.
> >
> >> Suresh> Human intervention may or may not be required. What involves
> >> Suresh> in
> >> signaling is out of scope and is left for implementation. For
> >>example, a  hosted service knows if the subscriber is a free
> >>subscriber or a paid  subscriber. A policy may be enforced to
> >>automatically trigger checkpoint if  the service requested is from a
> >>paid subscriber and not trigger if the service  requested is from a
> >>free subscriber.
> >
> >If policy is triggered by the network automatically then what is the
> >need for endpoint to explicitly signal that the flow is critical or not
> >?
> The policy referred here is not the network function policy. It is the policy in
> the hosted service.

It will be good to clarify what "hosted service" means in the terminology section. 

> >
> >> As another example, a human may be
> >> given a choice for signaling, just like human intervention when a
> >>location  based services app is launched. Or in some cases application
> >>may decide.
> >> And, one may come up with an even smarter way of when to signal.
> >> So, what involves in signaling is left for implementation and is of
> >>scope of this  document. However, I can mention the above as examples,
> >>if required.
> >
> >Okay.
> >
> >> >
> >> >[8] How would this work when PCP authentication is used ?
> >> >(I mean will authentication related info be also check pointed or
> >> >client will have to authenticate afresh when backup becomes active
> >> >and other related issues.)
> >> Suresh> I would not expect another authentication to happen. The
> >> implementation should ensure all the necessary state is check pointed
> >> on backup so that it doesn¹t need to re authenticate.
> >
> >PCP authentication has stateful information like sequence number, which
> >need to be synced regularly for HA to work and creates more chatter b/w
> >Active and Standby.
> >When PCP authentication is used it will be good to identify all the
> >relevant issues with HA.
> Yes, all the relevant state has to be check pointed. This happens even for
> IPSec, where window is check pointed periodically.
> >
> >> >
> >> >[9]   1.  Disruption in a phone connection is not desired.  Application
> >> >       that is initiating a phone connection MUST mark connection HA
> >>bit
> >> >       in the header, while initiating a PCP request for checkpointing.
> >> >
> >> >Comment> Are you referring to VoIP signaling connection ?
> >> Suresh> I am referring to VOIP signaling and data.
> >> >
> >> >[10]   2.  Similarly disruption in media streaming is not desired.  A
> >>user
> >> >       hosting a media service, MUST mark HA bit in the header while
> >> >       initiating a mapping request, and MAY mark connection associated
> >> >       with that mapping, depending on whether the connection is from a
> >> >       paid subscriber or from a free subscriber through a PEER
> >>request.
> >> >       So checkpointing mapping doesn't result in auto checkpointing of
> >> >       connections, as it gives flexibility to the end user to pick
> >> >       specific connections only to checkpoint.
> >> >
> >> >Comment> I am not sure why this distinction is required b/w free and
> >> >Comment> paid
> >> >VoIP calls, free call could also be an emergency call or
> >> >high-priority call.
> >> Suresh> In this context, media streaming refers to streaming services
> >> Suresh> like
> >> netflix, hulu, yupptv, spotify or some privately owned services etc.
> >
> >The content provided by these services is typically in the form of
> >chunks (HTTP Adaptive Streaming) and can be short-lived TCP sessions.
> >I don't see the need to checkpoint these flows.
> They might be short lived, but they are business critical.
> >
> >
> >> Yes,
> >> emergency calls are free and are high priority and implementor can
> >>always  initiate checkpointing for those calls. And, I am not sure why
> >>you are relating  them here? Am I missing something?
> >> >
> >> >6.   In conjunction with NAT, other network functions that MAY maintain
> >> >   state for each conneciton such as Stateful Firewall, IPSec, Load
> >> >   balancing etc..., MAY register to PCP server, and MAY be triggered
> >> >   for checkpointing respective state of that connection.
> >> >
> >> >Comment1> Are there stateless firewalls ?
> >> Suresh> Yes, simple packet filters or ASIC based firewall etcŠ
> >>
> >> >Comment 2> I did not understand this draft usage with load balancers
> >> >and IPSec.
> >> Suresh> Suppose IPSec as a gateway service along with firewall and NAT.
> >> IPSec may register with PCP, such that IPSec's HA module will be
> >>triggered by  PCP server to checkpoint state associated with a flow,
> >>when a PCP request for  that flow with HA bit set is received.
> >
> >Why would IPSEC care about the state associated with flows ?
> IPSec should care about IPSec state associated with flows right? Otherwise
> when master IPSec fails, and backup takes over, how would IPSec continue to
> secure traffic seamlessly?

May be I am missing some detail, IPSEC HA is explained in http://tools.ietf.org/html/rfc6311 and there is no discussion about individual flow state.

-Tiru

> >
> >-Tiru
> >
> >> Similarly for load balancing.
> >> >
> >> >Cheers,
> >> >-Tiru
> >> >
> >> >
> >> >>
> >> >> On 6/13/14 4:19 PM, "Suresh Kumar Vinapamula Venkata"
> >> >> <sureshk@juniper.net> wrote:
> >> >>
> >> >> >Hi
> >> >> >
> >> >> >This new version of draft address review comments received on the
> >> >> >previous version. Kindly review.
> >> >> >Sorry for the delay.
> >> >> >
> >> >> >Thanks
> >> >> >Suresh
> >> >> >
> >> >> >On 6/13/14 4:14 PM, "internet-drafts@ietf.org"
> >> >> ><internet-drafts@ietf.org>
> >> >> >wrote:
> >> >> >
> >> >> >>
> >> >> >>A new version of I-D, draft-vinapamula-flow-ha-01.txt has been
> >> >> >>successfully submitted by Suresh Vinapamula and posted to the
> >> >> >>IETF repository.
> >> >> >>
> >> >> >>Name:		draft-vinapamula-flow-ha
> >> >> >>Revision:	01
> >> >> >>Title:		Flow high availability through PCP
> >> >> >>Document date:	2014-06-13
> >> >> >>Group:		Individual Submission
> >> >> >>Pages:		6
> >> >> >>URL:
> >> >> >>http://www.ietf.org/internet-drafts/draft-vinapamula-flow-ha-01.
> >> >> >>txt
> >> >> >>Status:
> >> >> >>https://datatracker.ietf.org/doc/draft-vinapamula-flow-ha/
> >> >> >>Htmlized:
> >>http://tools.ietf.org/html/draft-vinapamula-flow-ha-01
> >> >> >>Diff:
> >> >> >>http://www.ietf.org/rfcdiff?url2=draft-vinapamula-flow-ha-01
> >> >> >>
> >> >> >>Abstract:
> >> >> >>   This document describes a mechanism for a host to signal various
> >> >> >>   network functions' High Availability (HA) module to checkpoint
> >> >> >>   interested connections through PCP.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>Please note that it may take a couple of minutes from the time
> >> >> >>of submission until the htmlized version and diff are available
> >> >> >>at tools.ietf.org.
> >> >> >>
> >> >> >>The IETF Secretariat
> >> >> >>
> >> >> >
> >> >> >_______________________________________________
> >> >> >pcp mailing list
> >> >> >pcp@ietf.org
> >> >> >https://www.ietf.org/mailman/listinfo/pcp
> >> >
> >