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

[Suresh Kumar Vinapamula Venkata <[e-mail]>]

On 8/18/14 7:20 PM, "Tirumaleswar Reddy (tireddy)" <[e-mail]>
wrote:

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

Even to negotiate the capability IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, one
has to indicate that it is is critical and so negotiate it right?
>
>-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
>> >> >> >
>> >> >
>> >
>