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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Suresh Kumar Vinapamula Venkata [mailto:[e-mail]]
> Sent: Thursday, August 14, 2014 12:51 AM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]
> Subject: Re: [pcp] FW: New Version Notification for draft-vinapamula-flow-
> ha-01.txt
> 
> 
> 
> On 8/12/14 7:47 PM, "Tirumaleswar Reddy (tireddy)" <[e-mail]>
> wrote:
> 
> >> -----Original Message-----
> >> From: Suresh Kumar Vinapamula Venkata [mailto:[e-mail]]
> >> Sent: Tuesday, August 12, 2014 11:33 PM
> >> To: Tirumaleswar Reddy (tireddy)
> >> Cc: [e-mail]
> >> Subject: Re: [pcp] FW: New Version Notification for
> >>draft-vinapamula-flow-
> >> ha-01.txt
> >>
> >>
> >>
> >> On 8/12/14 1:35 AM, "Tirumaleswar Reddy (tireddy)"
> >> <[e-mail]>
> >> wrote:
> >>
> >> >> -----Original Message-----
> >> >> From: Suresh Kumar Vinapamula Venkata
> [mailto:[e-mail]]
> >> >> Sent: Tuesday, August 12, 2014 12:06 AM
> >> >> To: Tirumaleswar Reddy (tireddy)
> >> >> Cc: [e-mail]
> >> >> 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)"
> >> >> <[e-mail]>
> >> >> 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,
> >> >> Suresh> 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
> >> >> Suresh> involves 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.
> Ok
> >
> >
> >> >
> >> >> 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
> >> >> >Comment> and paid
> >> >> >VoIP calls, free call could also be an emergency call or
> >> >> >high-priority call.
> >> >> Suresh> In this context, media streaming refers to streaming
> >> >> Suresh> services 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.
> They talk about SA state and checkpointing of that state. SA could be created
> at the granularity of flows, aggregated flows. Please look at IPSec and Ike
> RFCs.

Yes, SA state is check pointed periodically and the  SA counter synchronization solution is discussed in section 5 which suggests forwarding the IPSEC counters by a large value.
I don't see a problem with the above solution which causes packets of critical flows to be dropped when there is a fail-over.

-Tiru

> >
> >-Tiru
> >
> >> >
> >> >-Tiru
> >> >
> >> >> Similarly for load balancing.
> >> >> >
> >> >> >Cheers,
> >> >> >-Tiru
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> On 6/13/14 4:19 PM, "Suresh Kumar Vinapamula Venkata"
> >> >> >> <[e-mail]> 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, "[e-mail]"
> >> >> >> ><[e-mail]>
> >> >> >> >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
> >> >> >> >[e-mail]
> >> >> >> >https://www.ietf.org/mailman/listinfo/pcp
> >> >> >
> >> >
> >