Hi Yogendra,
Thank you for your comments and pointing out the lack of the IPComp
parameter.
I will update the draft including the IPComp flag , as well as the IPcomp
algo and the cpi-in/out values.
I understand when you say the draft "SHOULD capture at least
*instance-id*or *flow-id".
*However, I'm not familiar with this definitions as IKEv2 or IPsec
standards. Please don't hesitate to address me to those documents if they
are actually standardized.
On the other hand, I could understand that those parameters you just
mention (*instance-id* and *flow-id*), might be proprietary solutions to
improve IPsec treatment among several processing units. If it is the case,
I believe that our document may introduce supplementary information in the
context prior some negotiation, but I believe we should let the whole
mailing-list discuss about this.
By now, our wish is to isolate the IKEv2 and IPsec mandatory parameters in
order to keep an IKEv2/IPsec session alive.
KR,
Daniel Palomares
2014-02-18 17:25 GMT+01:00 yogendra pal <jntu...@gmail.com>:
> Hi Daniel,
>
> Given that ike and ipsec can runs on different context and nodes, context
> SHOULD capture at least *instance-id* or *flow-id*. This *instance-id*can
> help the node to identify which packet processing unit will process
> this ipsec traffic or which ipsec instance out of multiple ipsec processing
> unit will process this ipsec traffic.
>
> Let me take a simple example case to explain:
>
> On a node A, which has 10 processing unit (pu) = {1,2,3,4,5,6,7,8,9,10}
> and out of which ike is using single unit = {1} and ipsec is using 7
> processing unit(s) = {2,3,4,5,6,7,8} and other processing units = {9,10}
> for general purpose.
>
> Each IPsec SA processing can be tied with specific processing unit and can
> be called as *instance-id *or *flow-id*. This SA can hold *instance-id *or
> *flow-id *information. Upon sync up of context for each IPsec SA to other
> node B upon failure, it can process the same SA on specific *instance-id*or
> *flow-id.*
>
> P.S: If your need some text around this, I can provide you a example and
> usage of it.
>
> BR,
> Yogendra Pal
> (Ericsson, India)
>
>
> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal <jntu...@gmail.com> wrote:
>
>> Hi Daniel,
>>
>> Quickly went through your draft, have one input for you,
>> [In section "*5. IPsec Session parameters*"]
>> - Consider to have case of IPCOMP also for ipsec session parameters.
>>
>>
>> BR,
>> Yogendra Pal
>> (Ericsson)
>>
>>
>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares <
>> daniel.palomares.i...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Please find a draft we have Posted. They concern the definition of IKEv2
>>> and IPsec contexts.
>>> Comments are welcome,
>>>
>>> BR,
>>>
>>> Daniel Palomares
>>>
>>>
>>>
>>>
>>>
>>> Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition.
>>>
>>> Revision: 00
>>> Title: IKEv2/IPsec Context Definition
>>> Document date: 2014-02-12
>>> Group: Individual Submission
>>> Pages: 8
>>> URL:
>>> http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt<http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt>
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00
>>>
>>>
>>> Abstract
>>>
>>> IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a
>>> single address by the end user. The traffic is then split between
>>> the nodes via specific IP load balancing policies. Once a session is
>>> assigned to a given node, IPsec makes it difficult to assign the
>>> session to another node. This makes management operations and
>>> transparent high availability for end users difficult to perform
>>> within the cluster.
>>>
>>> This document describes the contexts for IKEv2 and IPsec that MUST be
>>> transferred between two nodes so a session can be restored. This
>>> makes possible to transfer an IPsec session transparently to the end
>>> user.
>>>
>>>
>>>
>>> *Daniel* *PALOMARES*
>>>
>>> *Orange Labs, Issy-les-Moulineaux*
>>>
>>> +33 6 34 23 07 88
>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>>
>>
>>
>>
>>
>
>
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
