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

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

Hi Med, 

PCP server can always communicate a failure in checkpointing to end
client, by not setting a corresponding reserved bit in the corresponding
PCP response of a PCP request. When checkpointing is successful, this bit
MUST be set in the response. But, I agree an option can always help in
future extensions, not sure what they would be, and a bit may not be as
versatile as extensions.

You brought an interesting point with PREFER_FAILURE. For a PREFER_FAILURE
request, if PCP resources are available but for some reason, checkpointing
failed, does that mean we should fail the request? I mean should
PREFER_FAILURE be carried over to checkpointing? I feel, in this case
where mappings could be allocated but checkpointing failed, a succeed the
request by sending allocated resources and also indicating that
checkpointing failed.

This way application knows about both status, and takes necessary action.

Thanks
Suresh

On 8/18/14 2:03 AM, "[e-mail]"
<[e-mail]> wrote:

>Hi all,
>
>I do agree with Tiru that an option would be more appropriate than
>associating a meaning with a reserved bit.
>
>For example: when used with PREFER_FAILURE, a client can be aware if its
>request has been honored by the server. This can be used for example to
>trigger counter measures by the PCP client such duplicating entries when
>several servers are available, shorten the lifetime for this mapping,
>etc. 
>
>Cheers,
>Med
>
>>-----Message d'origine-----
>>De : pcp [mailto:[e-mail]] De la part de Tirumaleswar Reddy
>>(tireddy)
>>Envoyé : vendredi 8 août 2014 10:22
>>À : Suresh Kumar Vinapamula Venkata
>>Cc : [e-mail]
>>Objet : Re: [pcp] FW: New Version Notification for draft-vinapamula-flow-
>>ha-01.txt
>>
>>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.
>>
>>[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.
>>
>>[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.
>>
>>[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.
>>
>>[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.
>>
>>[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"
>>
>>[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 DPI,
>>which
>>fails with encrypted traffic.
>>
>>[6]   2.  A connection may not be long lived but critical like shorter
>>       phone conversations.
>>
>>Comment> Replace "phone conversation" with "VOIP conversation"
>>
>>[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 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.
>>
>>[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.)
>>
>>[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 ?
>>
>>[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 paid
>>VoIP calls, free call could also be an emergency call or high-priority
>>call.
>>
>>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 ?
>>Comment 2> I did not understand this draft usage with load balancers and
>>IPSec.
>>
>>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
>>
>>_______________________________________________
>>pcp mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pcp