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: Tuesday, August 19, 2014 11:55 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]
> Subject: Re: [pcp] FW: New Version Notification for draft-vinapamula-flow-
> ha-01.txt
> 
> 
> 
> 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
> >> >> >> Suresh> 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
> >> >> >> >Comment> by 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
> >> >> >> >Comment> not 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.
> >> >> >> Suresh> 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
> >> >> >> >Comment> free 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
> >> >> >> Suresh> 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 ?

No, the above message is to only negotiate that the peer and active member support IPsec relay counter synchronization.

-Tiru

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