Hi Daniel, I agree w/ what you said, let the ipsec mailing list discussion this out, I just opened the forum w/ my inputs "*instance-id". *Since this draft is towards keeping IKEv2/IPsec session alive when any fault is detected on current node.
Thanks, Yogendra Pal (Ericssson, India) On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares < [email protected]> wrote: > 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 <[email protected]>: > > 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 <[email protected]> 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 < >>> [email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> >>> >>> >>> >>> >> >> >> > -- Thanks and Regards, Yogendra Pal +919686202644
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
