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

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

Sent from my iPhone

On Aug 22, 2014, at 7:55 PM, "Tirumaleswar Reddy (tireddy)" <[e-mail]> wrote:

>> -----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.
> 
Correct, what I am trying to say is that this negotiation can be triggered only for critical connections only. Apart from this, the IPSec SA state of a flow can be checkpointed only for critical connections only and not for all connections. Criticality can be indicated by end client. Does it make sense?  

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