From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 01 10:09:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAplI-0005x5-Ry for forces-archive@megatron.ietf.org; Thu, 01 Sep 2005 10:09:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06076 for ; Thu, 1 Sep 2005 10:09:51 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EApn9-0007z7-M6 for forces-archive@IETF.ORG; Thu, 01 Sep 2005 10:11:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010DF1D2@cherry.ease.lsoft.com>; Thu, 1 Sep 2005 10:09:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84563639 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 1 Sep 2005 10:09:40 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 1 Sep 2005 10:09:38 -0400 Received: from [58.100.182.120] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 1 Sep 2005 22:41:33 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <009801c5aeff$127a8500$1f12fea9@wwm1> Date: Thu, 1 Sep 2005 21:53:00 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [Issue 51]Operation Summary table To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: base64 SmFtYWwsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSGFk aSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQoNCj4gSGkgV2VpbWluZywNCj4gDQo+IFNpbmNlIHlv dSBNQVkgaGF2ZSB0aGlzIGFscmVhZHkgaW4geW91ciB0ZXh0Lg0KPiANCj4gU28gd2hhdCBoYXBw ZW5zIGlmIHNvbWVvbmUgYWRkcyBhIG5ldyBUTFYgb3Igb3BlcmF0aW9uIHRoYXQgZ29lcyBpbg0K PiBhZGRpdGlvbiB3aXRoIHRoZSBhbHJlYWR5IGRlZmluZWQgb25lPyBJIHRoaW5rIHdlIG5lZWQg dG8gc3BlY2lmeSB0aGUNCj4gYmVoYXZpb3IuIEV4YW1wbGUgaXQgY291bGQgYmUgIklnbm9yZSIu IEFjdHVhbGx5IGkgdGhpbmsgaXQgc2hvdWxkIGJlDQo+ICJJZ25vcmUiIGZvciBiYWNrd2FyZCBj b21wYXRpYmlsaXR5IHJlYXNvbnMuDQpWZXJ5IHNvcnJ5LCBidXQgSSBqdXN0IGNhbm5vdCBtYWtl IGl0IHZlcnkgY2xlYXJseS4gQ291bGQgeW91IHNob3cgbW9yZSBvZiB5b3VyIHRob3VnaHRzIG9u IHRoaXM/DQpJJ20gbm90IHN1cmUgd2hlcmUgb3RoZXIgdGhhbiBpbiB0aGUgcHJvdG9jb2wgbW9y ZSBvcCBUTFZzIGNhbiBiZSBkZWZpbmVkLg0KIA0KVGhhbmtzLA0KV2VpbWluZw0KPiANCj4gY2hl ZXJzLA0KPiBqYW1hbA0KPiANCj4gDQo+ID4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPiB8ICAgICAgICAg IE1lc3NhZ2VzICAgICAgICAgIHwgICAgVExWcyAgIHwgICAgICAgICBPcGVyYXRpb25zICAgICAg ICAgfA0KPiA+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ID4gfCAgICAgIEFzc29jaWF0aW9uIFNldHVwICAg ICB8IExGQnNlbGVjdCB8ICAgICAgICAgICBSRVBPUlQgICAgICAgICAgIHwNCj4gPiB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KPiA+IHwgQXNzb2NpYXRpb24gU2V0dXAgUmVzcG9uc2UgfCBBU1JyZXN1bHQgfCAg ICAgICAgICAgIE5vbmUgICAgICAgICAgICB8DQo+ID4gfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiB8ICAg IEFzc29jaWF0aW9uIFRlYXJkb3duICAgIHwgQVNUcmVhc29uIHwgICAgICAgICAgICBOb25lICAg ICAgICAgICAgfA0KPiA+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gfCAgICAgICAgICAgQ29uZmlnICAg ICAgICAgICB8IExGQnNlbGVjdCB8ICAgICAgICAgIFNFVCwgREVMICAgICAgICAgIHwNCj4gPiB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KPiA+IHwgICAgICAgQ29uZmlnIFJlc3BvbnNlICAgICAgfCBMRkJzZWxl Y3QgfCBTRVQtUkVTUE9OU0UsIERFTC1SRVNQT05TRSB8DQo+ID4gfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4g PiB8ICAgICAgICAgICAgUXVlcnkgICAgICAgICAgIHwgTEZCc2VsZWN0IHwgICAgICAgICAgICAg R0VUICAgICAgICAgICAgfA0KPiA+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gfCAgICAgICBRdWVyeSBS ZXNwb25zZSAgICAgICB8IExGQnNlbGVjdCB8ICAgICAgICBHRVQtUkVTUE9OU0UgICAgICAgIHwN Cj4gPiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KPiA+IHwgICAgIEV2ZW50IE5vdGlmaWNhdGlvbiAgICAgfCBM RkJzZWxlY3QgfCAgICAgICAgICAgUkVQT1JUICAgICAgICAgICB8DQo+ID4gfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCj4gPiB8ICAgICAgIFBhY2tldCBSZWRpcmVjdCAgICAgIHwgIFJlZGlyZWN0IHwgICAgICAg ICAgICBOb25lICAgICAgICAgICAgfA0KPiA+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gfCAgICAgICAg ICBIZWFydGJlYXQgICAgICAgICB8ICAgIE5vbmUgICB8ICAgICAgICAgICAgTm9uZSAgICAgICAg ICAgIHwNCj4gPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+IA0KPiA+ICAgIFRoZSBmb2xsb3dpbmcgdGFs YmUgc3VtbWFyaXNlcyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgREFUQVJBVyBUTFYNCj4gPiAg ICBhbmQgdGhlIFJFU1VMVCBUTFYgdG8gdGhlIE9wZXJhdGlvbiBUTFZzLg0KPiA+IA0KPiA+ICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0K PiA+ICAgICAgICAgICAgICAgfCAgT3BlcmF0aW9ucyAgfCBEQVRBUkFXIFRMViB8IFJFU1VMVCBU TFYgfA0KPiA+ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tKw0KPiA+ICAgICAgICAgICAgICAgfCAgICAgIFNFVCAgICAgfCAgICAgTVVTVCAg ICB8ICBNVVNUIE5PVCAgfA0KPiA+ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8ICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgfCBTRVQtUkVTUE9OU0Ug fCAgICAgTUFZICAgICB8ICAgIE1VU1QgICAgfA0KPiA+ICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgfCAg ICAgIERFTCAgICAgfCAgICAgTUFZICAgICB8ICBNVVNUIE5PVCAgfA0KPiA+ICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfA0KPiA+ICAgICAg ICAgICAgICAgfCBERUwtUkVTUE9OU0UgfCAgICAgTUFZICAgICB8ICAgIE1VU1QgICAgfA0KPiA+ ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg fA0KPiA+ICAgICAgICAgICAgICAgfCAgICAgIEdFVCAgICAgfCAgIE1VU1QgTk9UICB8ICBNVVNU IE5PVCAgfA0KPiA+ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgfCBHRVQtUkVTUE9OU0UgfCAgICAgTVVT VCAgICB8ICAgICBNQVkgICAgfA0KPiA+ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8ICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgfCAgICBSRVBPUlQg ICAgfCAgICAgTUFZICAgICB8ICBNVVNUIE5PVCAgfA0KPiA+ICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw== From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 01 10:09:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAplK-0005yB-KS for forces-archive@megatron.ietf.org; Thu, 01 Sep 2005 10:09:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06081 for ; Thu, 1 Sep 2005 10:09:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EApnH-0007z7-DD for forces-archive@IETF.ORG; Thu, 01 Sep 2005 10:11:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.010DF042@cherry.ease.lsoft.com>; Thu, 1 Sep 2005 10:09:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84563644 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 1 Sep 2005 10:09:41 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 1 Sep 2005 10:09:39 -0400 Received: from [58.100.182.120] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 1 Sep 2005 22:41:34 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <6.2.1.2.0.20050823105005.02d046b8@localhost> <018401c5a8bc$8f976970$c77cc0dc@WwmLapSamsung> <6.2.1.2.0.20050824165452.02d3cba0@localhost> <008f01c5ab7d$328006c0$1f06c0dc@WwmLapSamsung> <023401c5ae0b$2e615090$1152010a@Necom.hzic.edu.cn> <1125489040.6354.31.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <009901c5aeff$12d52820$1f12fea9@wwm1> Date: Thu, 1 Sep 2005 22:11:18 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: base64 SmFtYWwsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSGFk aSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQogDQo+ID4gDQo+ID4gICAgICAgIC0gQUNLOiBBQ0sg aW5kaWNhdG9yKDIgYml0KQ0KPiA+ICAgICAgICAgICAgVGhlIEFDSyBpbmRpY2F0b3IgZmxhZyBp cyBvbmx5IHVzZWQgYnkgYSBDb25maWcgTWVzc2FnZQ0KPiA+ICAgICAgICAgICAgc2VuZGVyIHRv IGluZGljYXRlIHRoZSBtZXNzYWdlIHJlY2VpdmVyIHdoZXRoZXIgb3Igbm90IGENCj4gPiAgICAg ICAgICAgIGNvbmZpZyByZXNwb25zZSBpcyByZXF1aXJlZCBieSB0aGUgc2VuZGVyLiAgTm90ZSB0 aGF0IGFsbA0KPiA+ICAgICAgICAgICAgb3RoZXIgbWVzc2FnZXMgdGhhbiBDb25maWcgTWVzc2Fn ZSBNVVNUIGlnbm9yZSB0aGlzIGZsYWcuDQo+ID4gDQo+IA0KPiBJIGFwb2xvZ2l6ZSB0byBicmlu ZyB0aGlzIHVwIGF0IHRoZSBsYXN0IG1pbnV0ZTsgSSBtaXNzZWQgZm9sbG93aW5nIHVwDQo+IHRo aXMgZGlzY3Vzc2lvbiB0aGF0IHlvdSBoYWQgd2l0aCBKb2VsLiAgQWxzbywgaW4geW91ciBkaXNj dXNzaW9uIHdpdGgNCj4gSm9lbCB5b3Ugc2FpZCB0aGUgZmxhZyB3YXMgZm9yICJhY2tub3dsZWRn ZW1lbnQgcmF0aGVyIHRoYW4gcmVzcG9uc2UiOyANCj4gSSBkb250IHNlZSB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIHRoZSB0d28uDQpUaGlzIGlzIG1vcmUgc2VtYW50aWNhbGx5IGJhc2VkIEkgdGhp bmsuIFdlIG5vdyBkZWZpbmUgYSByZXNwb25zZSBtb3JlIGFzIGFuIG9wZXJhdGlvbiByZXNwb25z ZSwgd2hpbGUgYW4gYWNrIGFzIGEgd2hvbGUgbWVzc2FnZS4gV2hlcmVhcyBJIGFncmVlIHdpdGgg eW91IHRoYXQgaXQgbWF5IGJlIG5vdCB2ZXJ5IHZpdGFsIGZvciB1cyB0byBkaXN0aW5ndWlzaCB0 aGVtLg0KDQo+IE11c3Qgd2UgdXNlIHN1Y2ggc3Ryb25nIGxhbmd1YWdlIGFib3ZlPyBFeGFtcGxl LCB3aGlsZSBwcm9iYWJseSBub3QgdmVyeQ0KPiBsaWtlbHksIGEpIEkgY291bGQgc2VuZCBhIGhl YXJ0YmVhdCAod2hpY2ggaXMgbm90IGEgQ29uZmlnIG1zZykgdGhhdCBpDQo+IHJlcXVlc3QgYSBy ZXNwb25zZSBmb3IgLSBzZXR0aW5nIHRoZSBBQ0sgZmxhZyBhbGxvd3MgbWUgdG8gDQpUaGUgdGhv dWdodCBJIHVzZSBNVVNUIGhlcmUgaXMgdHJ5aW5nIHRvIGF2b2lkIGxlYWRpbmcgdG8gY29tcGxl eCBkaXNjdXNzaW9uIG9mICBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW0uIEknbSBub3QgdmVyeSBz dXJlIGlmIHdlIHVzZSBTSE9VTEQgaGVyZSB3aWxsIHJlc3VsdCBpbiBzb21lIHByb2JsZW0gb2Yg dGhpcy4gRm9yIGluc3RhbmNlLCBhcyB5b3VyIGV4YW1wbGUgYWJvdmUsIEkgZG9uJ3Qga25vdyBp ZiBpdCB3aWxsIG1ha2UgdGhlIGJvdGggQ0Uob25lIHZlbmRvcikgYW5kIEZFKGFub3RoZXIgdmVu ZG9yKSBwYXJ0cyBhdCBhIGxvc3Mgd2hhdCB0byBkbyBpZiBGRSBzZXRzIHRoZSBoZWFydGJlYXQg QUNLIGFzICdBbHdheXNBQ0snLCBzb21lIENFIG1heSByZXBseSBidXQgc29tZSBtYXkgbm90LCB3 aGlsZSB0aGUgRkUgaXMgYWx3YXlzIHdhaXRpbmcgZm9yIHRoZSBBQ0sgdGhlbi4NCg0KPmFuZCBi KSBJIG1heSBub3Qgd2lzaCB0byByZWNpZXZlIGEgcmVzcG9uc2UgZm9yIGEgY2VydGFpbiBjb25m aWcuICAgDQpOb3QgdmVyeSBzdXJlIHdoYXQgeW91IG1lYW4gaGVyZS4gQ2FuIHdlIGp1c3QgdXNl ICdOb0FDSycgdGhlbj8NCg0KPiBTaGFsbCB3ZSByZWR1Y2UgaXQgdG8gYSByZWNvbW1lbmRhdGlv bj86DQo+ICJUaGUgQUNLIGluZGljYXRvciBmbGFnIGlzIHVzZWQgYnkgdGhlIHNlbmRlciB0byBp bmRpY2F0ZSB0byB0aGUNCj4gcmVjZWl2ZXIgaG93IGl0IHdpc2hlcyB0byBzZWUgYSByZXNwb25z ZS4gQXMgYW4gZXhhbXBsZSBDb25maWcgTWVzc2FnZQ0KPiBTSE9VTEQgYWx3YXlzIHNldCB0aGlz IGZsYWcgd2hpbGUgb3RoZXIgbWVzc2FnZSB0eXBlcyBTSE9VTEQgTk9UIg0KSXQgbWF5IHdvcnRo IHNvbWUgbW9yZSBkaXNjdXNzaW9uIGhlcmUsIHJlZ2FyZGluZyBpZiB1c2luZyBSRUNPTU1FTkQg bWF5IGxlYWQgdG8gc29tZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4NCg0KPiANCj4gSSB1c2Vk IHRoZSB3b3JkICJleGFtcGxlIiBiZWNhdXNlIHlvdSBoYXZlIG1vcmUgY2xhcmlmeWluZyB0ZXh0 IGJlbG93Lg0KPiANCj4gPiAgICAgICAgICAgIFRoZSBmbGFnIHZhbHVlcyBhcmUgZGVmaW5lZCBh cyBiZWxvdzoNCj4gPiANCj4gPiAgICAgICAgICAgICAgICAnTm9BQ0snICgwMCkgLSB0byBpbmRp Y2F0ZSB0aGUgbWVzc2FnZSByZWNlaXZlciBub3QgdG8NCj4gPiAgICAgICAgICAgICAgICBzZW5k IGFueSByZXNwb25zZSBtZXNzYWdlIGJhY2sgdG8gdGhpcyBtZXNzYWdlIHNlbmRlci4NCj4gDQo+ IFsuLl0NCj4gDQo+ID4gICAgICAgICAgICBBbHNvIG5vdGUgdGhhdCBvdGhlciBtZXNzYWdlcyB0 aGFuIENvbmZpZyBNZXNzYWdlLCB3aG9zZQ0KPiA+ICAgICAgICAgICAgcmVxdWlyZW1lbnRzIGZv ciByZXNwb25zZXMgYXJlIHN0YXRpc3RpY2FsbHkgcHJlc2NyaWJlZCBieQ0KPiA+ICAgICAgICAg ICAgdGhlIG1lc3NhZ2UgZGVmaW5pdGlvbnMgaW4gdGhlIGZvbGxvd2VkIFNlY3Rpb25zLiAgVGhl IEFDSw0KPiA+ICAgICAgICAgICAgaW5kaWNhdG9ycyBpbiB0aGVzZSBtZXNzYWdlcyBNVVNUIGJl IGlnbm9yZWQuDQo+ID4gDQo+IA0KPiBBbm90aGVyIHVzZSBvZiB0aGUgdGVybSBNVVNUIGFib3Zl Lg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA== From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 01 10:42:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAqGR-0007e9-PZ for forces-archive@megatron.ietf.org; Thu, 01 Sep 2005 10:42:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08528 for ; Thu, 1 Sep 2005 10:42:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAqIP-0000as-CF for forces-archive@IETF.ORG; Thu, 01 Sep 2005 10:44:06 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010DF306@cherry.ease.lsoft.com>; Thu, 1 Sep 2005 10:42:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84565047 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 1 Sep 2005 10:42:01 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 1 Sep 2005 10:42:00 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j81DxaXK064737; Thu, 1 Sep 2005 06:59:37 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> <009801c5aeff$127a8500$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1125585704.8390.6.camel@localhost.localdomain> Date: Thu, 1 Sep 2005 10:41:44 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 51]Operation Summary table Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <009801c5aeff$127a8500$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi Weiming, On Thu, 2005-01-09 at 21:53 +0800, Weiming Wang wrote: > Jamal, > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > Hi Weiming, > > > > Since you MAY have this already in your text. > > > > So what happens if someone adds a new TLV or operation that goes in > > addition with the already defined one? I think we need to specify the > > behavior. Example it could be "Ignore". Actually i think it should be > > "Ignore" for backward compatibility reasons. > Very sorry, but I just cannot make it very clearly. Could you show more of > your thoughts on this? > I'm not sure where other than in the protocol more op TLVs can be defined. > The possibility is there to add new TLVs that could be actually be future extensions (protocol updates). This could happen after the protocol becomes RFC. If someone implements the protocol according to current spec and meet some of these TLVs in the field in the future, how should they handle them? Typically with other protocols which dont use TLVs, this would be hard to handle and may require strict versioning and even rewriting of existing implementations. We dont have this kind of problem since we use TLVs - but to deal with this well, we need to define the behavior of how an implementation deals when it sees and unknown T. Does this makes sense? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 01 11:02:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAqac-00031C-Fu for forces-archive@megatron.ietf.org; Thu, 01 Sep 2005 11:02:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09384 for ; Thu, 1 Sep 2005 11:02:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAqca-0001CU-MS for forces-archive@IETF.ORG; Thu, 01 Sep 2005 11:04:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010DF15D@cherry.ease.lsoft.com>; Thu, 1 Sep 2005 11:02:51 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84568594 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 1 Sep 2005 11:02:50 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 1 Sep 2005 11:02:49 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j81EKSXK064960; Thu, 1 Sep 2005 07:20:30 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <6.2.1.2.0.20050823105005.02d046b8@localhost> <018401c5a8bc$8f976970$c77cc0dc@WwmLapSamsung> <6.2.1.2.0.20050824165452.02d3cba0@localhost> <008f01c5ab7d$328006c0$1f06c0dc@WwmLapSamsung> <023401c5ae0b$2e615090$1152010a@Necom.hzic.edu.cn> <1125489040.6354.31.camel@localhost.localdomain> <009901c5aeff$12d52820$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1125586958.8390.17.camel@localhost.localdomain> Date: Thu, 1 Sep 2005 11:02:38 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 34] Header flags Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <009901c5aeff$12d52820$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Weiming, Maybe we should make this an agenda item for tommorows concal. More inline. On Thu, 2005-01-09 at 22:11 +0800, Weiming Wang wrote: > Jamal, > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > > > > > - ACK: ACK indicator(2 bit) > > > The ACK indicator flag is only used by a Config Message > > > sender to indicate the message receiver whether or not a > > > config response is required by the sender. Note that all > > > other messages than Config Message MUST ignore this flag. > > > > > > > I apologize to bring this up at the last minute; I missed following up > > this discussion that you had with Joel. Also, in your discussion with > > Joel you said the flag was for "acknowledgement rather than response"; > > I dont see the difference between the two. > This is more semantically based I think. We now define a response more as > an operation response, while an ack as a whole message. Whereas I agree > with you that it may be not very vital for us to distinguish them. > Then we need to explicitly define what an ACK vs response means like you say above. Unfortunately we are using the English language (instead of mathematics) so reducing ambiguity is useful. > > Must we use such strong language above? Example, while probably not very > > likely, a) I could send a heartbeat (which is not a Config msg) that i > > request a response for - setting the ACK flag allows me to > The thought I use MUST here is trying to avoid leading to complex discussion > of interoperability problem. I'm not very sure if we use SHOULD here will > result in some problem of this. For instance, as your example above, I don't > know if it will make the both CE(one vendor) and FE(another vendor) parts at > a loss what to do if FE sets the heartbeat ACK as 'AlwaysACK', some CE may > reply but some may not, while the FE is always waiting for the ACK then. > > >and b) I may not wish to recieve a response for a certain config. > Not very sure what you mean here. Can we just use 'NoACK' then? > yes, NoACK will do. > > Shall we reduce it to a recommendation?: > > "The ACK indicator flag is used by the sender to indicate to the > > receiver how it wishes to see a response. As an example Config Message > > SHOULD always set this flag while other message types SHOULD NOT" > It may worth some more discussion here, regarding if using RECOMMEND may > lead to some interoperability issues. I think if we explicitly say that the ACK flags override; lets discuss tommorow. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 01 11:21:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAqt3-00060P-0L for forces-archive@megatron.ietf.org; Thu, 01 Sep 2005 11:21:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10266 for ; Thu, 1 Sep 2005 11:21:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAqv0-0001pq-If for forces-archive@IETF.ORG; Thu, 01 Sep 2005 11:23:59 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010DF091@cherry.ease.lsoft.com>; Thu, 1 Sep 2005 11:21:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84571012 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 1 Sep 2005 11:21:54 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 1 Sep 2005 11:21:53 -0400 Received: from [58.100.182.120] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 1 Sep 2005 23:53:50 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> <009801c5aeff$127a8500$1f12fea9@wwm1> <1125585704.8390.6.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <00ad01c5af09$2ae14520$1f12fea9@wwm1> Date: Thu, 1 Sep 2005 23:23:51 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [Issue 51]Operation Summary table To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: base64 SmFtYWwsIA0KDQpTb3JyeSwgYWZ0ZXIgcmVhZGluZyB5b3VyIHRleHQgYmVsb3csIEknbSBzdGls bCBub3QgdmVyeSBzdXJlIHdoYXQgeW91IG1lYW4uIENhbiB5b3UganVzdCBzaG93IGhvdyB5b3Ug c3VnZ2VzdCB3ZSBzaG91bGQgZG8gbmV4dCBvbiB0aGlzPw0KDQpUaGFua3MgYSBsb3QuDQpXZWlt aW5nDQoNCj4gPiA+IA0KPiA+ID4gU2luY2UgeW91IE1BWSBoYXZlIHRoaXMgYWxyZWFkeSBpbiB5 b3VyIHRleHQuDQo+ID4gPiANCj4gPiA+IFNvIHdoYXQgaGFwcGVucyBpZiBzb21lb25lIGFkZHMg YSBuZXcgVExWIG9yIG9wZXJhdGlvbiB0aGF0IGdvZXMgaW4NCj4gPiA+IGFkZGl0aW9uIHdpdGgg dGhlIGFscmVhZHkgZGVmaW5lZCBvbmU/IEkgdGhpbmsgd2UgbmVlZCB0byBzcGVjaWZ5IHRoZQ0K PiA+ID4gYmVoYXZpb3IuIEV4YW1wbGUgaXQgY291bGQgYmUgIklnbm9yZSIuIEFjdHVhbGx5IGkg dGhpbmsgaXQgc2hvdWxkIGJlDQo+ID4gPiAiSWdub3JlIiBmb3IgYmFja3dhcmQgY29tcGF0aWJp bGl0eSByZWFzb25zLg0KPiA+IFZlcnkgc29ycnksIGJ1dCBJIGp1c3QgY2Fubm90IG1ha2UgaXQg dmVyeSBjbGVhcmx5LiBDb3VsZCB5b3Ugc2hvdyBtb3JlIG9mIA0KPiA+IHlvdXIgdGhvdWdodHMg b24gdGhpcz8NCj4gPiBJJ20gbm90IHN1cmUgd2hlcmUgb3RoZXIgdGhhbiBpbiB0aGUgcHJvdG9j b2wgbW9yZSBvcCBUTFZzIGNhbiBiZSBkZWZpbmVkLg0KPiA+ICANCj4gDQo+IFRoZSBwb3NzaWJp bGl0eSBpcyB0aGVyZSB0byBhZGQgbmV3IFRMVnMgdGhhdCBjb3VsZCBiZSBhY3R1YWxseSBiZQ0K PiBmdXR1cmUgZXh0ZW5zaW9ucyAocHJvdG9jb2wgdXBkYXRlcykuIFRoaXMgY291bGQgaGFwcGVu IGFmdGVyIHRoZQ0KPiBwcm90b2NvbCBiZWNvbWVzIFJGQy4gSWYgc29tZW9uZSBpbXBsZW1lbnRz IHRoZSBwcm90b2NvbCBhY2NvcmRpbmcgdG8NCj4gY3VycmVudCBzcGVjIGFuZCBtZWV0IHNvbWUg b2YgdGhlc2UgVExWcyBpbiB0aGUgZmllbGQgaW4gdGhlIGZ1dHVyZSwgaG93DQo+IHNob3VsZCB0 aGV5IGhhbmRsZSB0aGVtPyBUeXBpY2FsbHkgd2l0aCBvdGhlciBwcm90b2NvbHMgd2hpY2ggZG9u dCB1c2UNCj4gVExWcywgdGhpcyB3b3VsZCBiZSBoYXJkIHRvIGhhbmRsZSBhbmQgbWF5IHJlcXVp cmUgc3RyaWN0IHZlcnNpb25pbmcgYW5kDQo+IGV2ZW4gcmV3cml0aW5nIG9mIGV4aXN0aW5nIGlt cGxlbWVudGF0aW9ucy4NCj4gV2UgZG9udCBoYXZlIHRoaXMga2luZCBvZiBwcm9ibGVtIHNpbmNl IHdlIHVzZSBUTFZzIC0gYnV0IHRvIGRlYWwgd2l0aA0KPiB0aGlzIHdlbGwsIHdlIG5lZWQgdG8g ZGVmaW5lIHRoZSBiZWhhdmlvciBvZiBob3cgYW4gaW1wbGVtZW50YXRpb24gZGVhbHMNCj4gd2hl biBpdCBzZWVzIGFuZCB1bmtub3duIFQuDQo+IERvZXMgdGhpcyBtYWtlcyBzZW5zZT8NCj4gIA0K PiBjaGVlcnMsDQo+IGphbWFs From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 01 15:15:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuWv-0001mw-AO for forces-archive@megatron.ietf.org; Thu, 01 Sep 2005 15:15:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24547 for ; Thu, 1 Sep 2005 15:15:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAuYu-0001c4-R4 for forces-archive@IETF.ORG; Thu, 01 Sep 2005 15:17:26 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010DF4FF@cherry.ease.lsoft.com>; Thu, 1 Sep 2005 15:15:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84587915 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 1 Sep 2005 15:15:18 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 1 Sep 2005 15:15:18 -0400 Received: from [12.58.128.11] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12137799; Thu, 01 Sep 2005 15:15:17 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> <009801c5aeff$127a8500$1f12fea9@wwm1> <1125585704.8390.6.camel@localhost.localdomain> <00ad01c5af09$2ae14520$1f12fea9@wwm1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050901151320.02db11c0@localhost> Date: Thu, 1 Sep 2005 15:15:15 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [Issue 51]Operation Summary table Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00ad01c5af09$2ae14520$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 The issue alluded to, assuming I am understand it properly, is that the protocol needs to specify what a receiver should do if it receives a TLV it does not understand in a message it does understand. I believe we should simply have it be ignored. We could allocate one bit from the type code space as a mandatory bit, and say that any enclosure of an unknwon mandatory TLV is to be treated as an error. Yours, Joel At 11:23 AM 9/1/2005, Weiming Wang wrote: >Jamal, > >Sorry, after reading your text below, I'm still not very sure what you >mean. Can you just show how you suggest we should do next on this? > >Thanks a lot. >Weiming > > > > > > > > > Since you MAY have this already in your text. > > > > > > > > So what happens if someone adds a new TLV or operation that goes in > > > > addition with the already defined one? I think we need to specify the > > > > behavior. Example it could be "Ignore". Actually i think it should be > > > > "Ignore" for backward compatibility reasons. > > > Very sorry, but I just cannot make it very clearly. Could you show > more of > > > your thoughts on this? > > > I'm not sure where other than in the protocol more op TLVs can be > defined. > > > > > > > The possibility is there to add new TLVs that could be actually be > > future extensions (protocol updates). This could happen after the > > protocol becomes RFC. If someone implements the protocol according to > > current spec and meet some of these TLVs in the field in the future, how > > should they handle them? Typically with other protocols which dont use > > TLVs, this would be hard to handle and may require strict versioning and > > even rewriting of existing implementations. > > We dont have this kind of problem since we use TLVs - but to deal with > > this well, we need to define the behavior of how an implementation deals > > when it sees and unknown T. > > Does this makes sense? > > > > cheers, > > jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 01 21:21:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0F8-0007hP-Bn for forces-archive@megatron.ietf.org; Thu, 01 Sep 2005 21:21:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10986 for ; Thu, 1 Sep 2005 21:21:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB0H6-0003t6-RS for forces-archive@IETF.ORG; Thu, 01 Sep 2005 21:23:30 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010DF9DC@cherry.ease.lsoft.com>; Thu, 1 Sep 2005 21:21:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84607932 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 1 Sep 2005 21:21:14 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 1 Sep 2005 21:21:14 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Fri, 2 Sep 2005 09:53:15 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> <009801c5aeff$127a8500$1f12fea9@wwm1> <1125585704.8390.6.camel@localhost.localdomain> <00ad01c5af09$2ae14520$1f12fea9@wwm1> <6.2.1.2.0.20050901151320.02db11c0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <003b01c5af5c$e49b9260$1f12fea9@wwm1> Date: Fri, 2 Sep 2005 09:22:52 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [Issue 51]Operation Summary table To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.2 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvZWwgTS4gSGFscGVybiIg PGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NClN1YmplY3Q6IFJlOiBbSXNzdWUgNTFdT3BlcmF0aW9u IFN1bW1hcnkgdGFibGUNCg0KDQo+IFRoZSBpc3N1ZSBhbGx1ZGVkIHRvLCBhc3N1bWluZyBJIGFt IHVuZGVyc3RhbmQgaXQgcHJvcGVybHksIGlzIHRoYXQgdGhlIA0KPiBwcm90b2NvbCBuZWVkcyB0 byBzcGVjaWZ5IHdoYXQgYSByZWNlaXZlciBzaG91bGQgZG8gaWYgaXQgcmVjZWl2ZXMgYSBUTFYg aXQgDQo+IGRvZXMgbm90IHVuZGVyc3RhbmQgaW4gYSBtZXNzYWdlIGl0IGRvZXMgdW5kZXJzdGFu ZC4NCj4gSSBiZWxpZXZlIHdlIHNob3VsZCBzaW1wbHkgaGF2ZSBpdCBiZSBpZ25vcmVkLg0KPiBX ZSBjb3VsZCBhbGxvY2F0ZSBvbmUgYml0IGZyb20gdGhlIHR5cGUgY29kZSBzcGFjZSBhcyBhIG1h bmRhdG9yeSBiaXQsIGFuZCANCj4gc2F5IHRoYXQgYW55IGVuY2xvc3VyZSBvZiBhbiB1bmtud29u IG1hbmRhdG9yeSBUTFYgaXMgdG8gYmUgdHJlYXRlZCBhcyBhbiANCj4gZXJyb3IuDQpJIHRoaW5r IHN1Y2ggdGhpbmcgYXMgYW4gdW5rbm93biBUTFYgYXBwZWFycyBkdXJpbmcgcGFyc2luZyBvZiBh IHJlY2VpdmVkIG1lc3NhZ2Ugd2lsbCBhbHdheXMgcG9zc2libHkgaGFwcGVuLCByYXRoZXIgdGhh biBoYXBwZW4gYXQgdGhlIE9wZXJhaW9uIFRMViBsZXZlbC4gIEFsbCB0aGlzIHNob3VsZCBiZSB0 cmVhdGVkIGFzIGEga2luZCBvZiBlcnJvciwgIHRoZSBwYXJzaW5nIGVycm9yLiAgSSBkb24ndCB0 aGluayB3ZSBuZWVkIHRvIHNlcGNpZnkgbW9yZSBvbiBzdWNoIGVycm9yIHByb2Nlc3NpbmcsIG9y IHdlIG1heSBnZXQgIHRvbyBtdWNoIHRvIGRlYWwgd2l0aC4NCg0KVGhhbmtzLA0KV2VpbWluZw0K PiANCj4gWW91cnMsDQo+IEpvZWwNCj4gDQo+IEF0IDExOjIzIEFNIDkvMS8yMDA1LCBXZWltaW5n IFdhbmcgd3JvdGU6DQo+ID5KYW1hbCwNCj4gPg0KPiA+U29ycnksIGFmdGVyIHJlYWRpbmcgeW91 ciB0ZXh0IGJlbG93LCBJJ20gc3RpbGwgbm90IHZlcnkgc3VyZSB3aGF0IHlvdSANCj4gPm1lYW4u IENhbiB5b3UganVzdCBzaG93IGhvdyB5b3Ugc3VnZ2VzdCB3ZSBzaG91bGQgZG8gbmV4dCBvbiB0 aGlzPw0KPiA+DQo+ID5UaGFua3MgYSBsb3QuDQo+ID5XZWltaW5nDQo+ID4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+IFNpbmNlIHlvdSBNQVkgaGF2ZSB0aGlzIGFscmVhZHkgaW4geW91ciB0ZXh0Lg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gU28gd2hhdCBoYXBwZW5zIGlmIHNvbWVvbmUgYWRkcyBhIG5l dyBUTFYgb3Igb3BlcmF0aW9uIHRoYXQgZ29lcyBpbg0KPiA+ID4gPiA+IGFkZGl0aW9uIHdpdGgg dGhlIGFscmVhZHkgZGVmaW5lZCBvbmU/IEkgdGhpbmsgd2UgbmVlZCB0byBzcGVjaWZ5IHRoZQ0K PiA+ID4gPiA+IGJlaGF2aW9yLiBFeGFtcGxlIGl0IGNvdWxkIGJlICJJZ25vcmUiLiBBY3R1YWxs eSBpIHRoaW5rIGl0IHNob3VsZCBiZQ0KPiA+ID4gPiA+ICJJZ25vcmUiIGZvciBiYWNrd2FyZCBj b21wYXRpYmlsaXR5IHJlYXNvbnMuDQo+ID4gPiA+IFZlcnkgc29ycnksIGJ1dCBJIGp1c3QgY2Fu bm90IG1ha2UgaXQgdmVyeSBjbGVhcmx5LiBDb3VsZCB5b3Ugc2hvdyANCj4gPiBtb3JlIG9mDQo+ ID4gPiA+IHlvdXIgdGhvdWdodHMgb24gdGhpcz8NCj4gPiA+ID4gSSdtIG5vdCBzdXJlIHdoZXJl IG90aGVyIHRoYW4gaW4gdGhlIHByb3RvY29sIG1vcmUgb3AgVExWcyBjYW4gYmUgDQo+ID4gZGVm aW5lZC4NCj4gPiA+ID4NCj4gPiA+DQo+ID4gPiBUaGUgcG9zc2liaWxpdHkgaXMgdGhlcmUgdG8g YWRkIG5ldyBUTFZzIHRoYXQgY291bGQgYmUgYWN0dWFsbHkgYmUNCj4gPiA+IGZ1dHVyZSBleHRl bnNpb25zIChwcm90b2NvbCB1cGRhdGVzKS4gVGhpcyBjb3VsZCBoYXBwZW4gYWZ0ZXIgdGhlDQo+ ID4gPiBwcm90b2NvbCBiZWNvbWVzIFJGQy4gSWYgc29tZW9uZSBpbXBsZW1lbnRzIHRoZSBwcm90 b2NvbCBhY2NvcmRpbmcgdG8NCj4gPiA+IGN1cnJlbnQgc3BlYyBhbmQgbWVldCBzb21lIG9mIHRo ZXNlIFRMVnMgaW4gdGhlIGZpZWxkIGluIHRoZSBmdXR1cmUsIGhvdw0KPiA+ID4gc2hvdWxkIHRo ZXkgaGFuZGxlIHRoZW0/IFR5cGljYWxseSB3aXRoIG90aGVyIHByb3RvY29scyB3aGljaCBkb250 IHVzZQ0KPiA+ID4gVExWcywgdGhpcyB3b3VsZCBiZSBoYXJkIHRvIGhhbmRsZSBhbmQgbWF5IHJl cXVpcmUgc3RyaWN0IHZlcnNpb25pbmcgYW5kDQo+ID4gPiBldmVuIHJld3JpdGluZyBvZiBleGlz dGluZyBpbXBsZW1lbnRhdGlvbnMuDQo+ID4gPiBXZSBkb250IGhhdmUgdGhpcyBraW5kIG9mIHBy b2JsZW0gc2luY2Ugd2UgdXNlIFRMVnMgLSBidXQgdG8gZGVhbCB3aXRoDQo+ID4gPiB0aGlzIHdl bGwsIHdlIG5lZWQgdG8gZGVmaW5lIHRoZSBiZWhhdmlvciBvZiBob3cgYW4gaW1wbGVtZW50YXRp b24gZGVhbHMNCj4gPiA+IHdoZW4gaXQgc2VlcyBhbmQgdW5rbm93biBULg0KPiA+ID4gRG9lcyB0 aGlzIG1ha2VzIHNlbnNlPw0KPiA+ID4NCj4gPiA+IGNoZWVycywNCj4gPiA+IGphbWFsDQo+IA== From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 01 22:16:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB16E-0007JK-65 for forces-archive@megatron.ietf.org; Thu, 01 Sep 2005 22:16:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21821 for ; Thu, 1 Sep 2005 22:16:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB18H-0005Sf-CN for forces-archive@IETF.ORG; Thu, 01 Sep 2005 22:18:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010DFC03@cherry.ease.lsoft.com>; Thu, 1 Sep 2005 22:16:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84610064 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 1 Sep 2005 22:16:04 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 1 Sep 2005 22:16:03 -0400 Received: from [70.104.227.167] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12141809 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 01 Sep 2005 22:16:03 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> <009801c5aeff$127a8500$1f12fea9@wwm1> <1125585704.8390.6.camel@localhost.localdomain> <00ad01c5af09$2ae14520$1f12fea9@wwm1> <6.2.1.2.0.20050901151320.02db11c0@localhost> <003b01c5af5c$e49b9260$1f12fea9@wwm1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050901221354.02d9b160@localhost> Date: Thu, 1 Sep 2005 22:16:00 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [Issue 51]Operation Summary table To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003b01c5af5c$e49b9260$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Treating unknown TLVs as always being parsing errors is one feasible and consistent definition. However, that means that if one is upgrading the protocol, one needs to either upgrade the CE and all the FEs at once, or once must do version negotiation. It is often the case that there can be additions to the protocol (new TLVs) that can be ignored if they are not understood. In fact, it is usually argued that the biggest reason for using TLV encodings is to be able to ignore unknown elements. Yours, Joel M. Halpern At 09:22 PM 9/1/2005, Weiming Wang wrote: >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Re: [Issue 51]Operation Summary table > > > > The issue alluded to, assuming I am understand it properly, is that the > > protocol needs to specify what a receiver should do if it receives a > TLV it > > does not understand in a message it does understand. > > I believe we should simply have it be ignored. > > We could allocate one bit from the type code space as a mandatory bit, and > > say that any enclosure of an unknwon mandatory TLV is to be treated as an > > error. >I think such thing as an unknown TLV appears during parsing of a received >message will always possibly happen, rather than happen at the Operaion >TLV level. All this should be treated as a kind of error, the parsing >error. I don't think we need to sepcify more on such error processing, or >we may get too much to deal with. > >Thanks, >Weiming > > > > Yours, > > Joel > > > > At 11:23 AM 9/1/2005, Weiming Wang wrote: > > >Jamal, > > > > > >Sorry, after reading your text below, I'm still not very sure what you > > >mean. Can you just show how you suggest we should do next on this? > > > > > >Thanks a lot. > > >Weiming > > > > > > > > > > > > > > > Since you MAY have this already in your text. > > > > > > > > > > > > So what happens if someone adds a new TLV or operation that goes in > > > > > > addition with the already defined one? I think we need to > specify the > > > > > > behavior. Example it could be "Ignore". Actually i think it > should be > > > > > > "Ignore" for backward compatibility reasons. > > > > > Very sorry, but I just cannot make it very clearly. Could you show > > > more of > > > > > your thoughts on this? > > > > > I'm not sure where other than in the protocol more op TLVs can be > > > defined. > > > > > > > > > > > > > The possibility is there to add new TLVs that could be actually be > > > > future extensions (protocol updates). This could happen after the > > > > protocol becomes RFC. If someone implements the protocol according to > > > > current spec and meet some of these TLVs in the field in the > future, how > > > > should they handle them? Typically with other protocols which dont use > > > > TLVs, this would be hard to handle and may require strict > versioning and > > > > even rewriting of existing implementations. > > > > We dont have this kind of problem since we use TLVs - but to deal with > > > > this well, we need to define the behavior of how an implementation > deals > > > > when it sees and unknown T. > > > > Does this makes sense? > > > > > > > > cheers, > > > > jamal > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 02 10:21:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCQB-00017W-EG for forces-archive@megatron.ietf.org; Fri, 02 Sep 2005 10:21:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09535 for ; Fri, 2 Sep 2005 10:21:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBCSF-0004kp-To for forces-archive@IETF.ORG; Fri, 02 Sep 2005 10:23:48 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010E05A4@cherry.ease.lsoft.com>; Fri, 2 Sep 2005 10:21:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84647782 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 2 Sep 2005 10:21:19 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 2 Sep 2005 10:21:19 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j82DcmXK076554; Fri, 2 Sep 2005 06:38:52 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> <009801c5aeff$127a8500$1f12fea9@wwm1> <1125585704.8390.6.camel@localhost.localdomain> <00ad01c5af09$2ae14520$1f12fea9@wwm1> <6.2.1.2.0.20050901151320.02db11c0@localhost> <003b01c5af5c$e49b9260$1f12fea9@wwm1> <6.2.1.2.0.20050901221354.02d9b160@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1125670870.6185.59.camel@localhost.localdomain> Date: Fri, 2 Sep 2005 10:21:10 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 51]Operation Summary table Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050901221354.02d9b160@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit On Thu, 2005-01-09 at 22:16 -0400, Joel M. Halpern wrote: > Treating unknown TLVs as always being parsing errors is one feasible and > consistent definition. > However, that means that if one is upgrading the protocol, one needs to > either upgrade the CE and all the FEs at once, or once must do version > negotiation. > > It is often the case that there can be additions to the protocol (new TLVs) > that can be ignored if they are not understood. In fact, it is usually > argued that the biggest reason for using TLV encodings is to be able to > ignore unknown elements. > Indeed. Weiming, heres an example/analogy in XML that I have often seen used: Weiming Joel Lets say you wrote an app that parsed and output the following: Sender: Joel Recipient: Weiming Now lets say your app 10 years down the road met the following XML Weiming Joel Jamal It should not die - rather ignore and still output: Sender: Joel Recipient: Weiming It is good practise to log the extra tag that is not understood but in practise specifying that it is to be ignored is a good idea. Back to the draft: We should recommend that unknown TLVs should be ignored. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 02 10:29:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCXu-0003yx-W8 for forces-archive@megatron.ietf.org; Fri, 02 Sep 2005 10:29:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10497 for ; Fri, 2 Sep 2005 10:29:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBCZv-0005Cf-Ah for forces-archive@IETF.ORG; Fri, 02 Sep 2005 10:31:49 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010E0590@cherry.ease.lsoft.com>; Fri, 2 Sep 2005 10:29:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84648206 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 2 Sep 2005 10:29:22 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 2 Sep 2005 10:29:21 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Fri, 2 Sep 2005 23:01:27 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Fri, 2 Sep 2005 22:29:07 +0800 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> <009801c5aeff$127a8500$1f12fea9@wwm1> <1125585704.8390.6.camel@localhost.localdomain> <00ad01c5af09$2ae14520$1f12fea9@wwm1> <6.2.1.2.0.20050901151320.02db11c0@localhost> <003b01c5af5c$e49b9260$1f12fea9@wwm1> <6.2.1.2.0.20050901221354.02d9b160@localhost> <1125670870.6185.59.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <03a701c5afca$abe40830$1152010a@Necom.hzic.edu.cn> Date: Fri, 2 Sep 2005 22:28:45 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 51]Operation Summary table To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: base64 SmFtYWwgYW5kIEpvZWwsDQoNClRoYXQgbWFrZXMgc2Vuc2UgdG8gbWUuIEkgYWdyZWUuIEkgdGhp bmsgdGhlIHRleHQgb2YgYXNzdW1wdGlvbiB0byBpZ25vcmUgdW5rbm93biBUTFZzIGNhbiBiZSBh ZGRlZCBhdCB0aGUgInByb3RvY29sIGdyYW1tYXIiIHNlY3Rpb24sIGlzIGl0IG9rPw0KDQpUaGFu a3MsDQpXZWltaW5nDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFs IEhhZGkgU2FsaW0iIDxoYWRpQHpueXguY29tPg0KVG86IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09G VC5DT00+DQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwMiwgMjAwNSAxMDoyMSBQTQ0KU3ViamVj dDogUmU6IFtJc3N1ZSA1MV1PcGVyYXRpb24gU3VtbWFyeSB0YWJsZQ0KDQoNCj4gT24gVGh1LCAy MDA1LTAxLTA5IGF0IDIyOjE2IC0wNDAwLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4gVHJl YXRpbmcgdW5rbm93biBUTFZzIGFzIGFsd2F5cyBiZWluZyBwYXJzaW5nIGVycm9ycyBpcyBvbmUg ZmVhc2libGUgYW5kIA0KPiA+IGNvbnNpc3RlbnQgZGVmaW5pdGlvbi4NCj4gPiBIb3dldmVyLCB0 aGF0IG1lYW5zIHRoYXQgaWYgb25lIGlzIHVwZ3JhZGluZyB0aGUgcHJvdG9jb2wsIG9uZSBuZWVk cyB0byANCj4gPiBlaXRoZXIgdXBncmFkZSB0aGUgQ0UgYW5kIGFsbCB0aGUgRkVzIGF0IG9uY2Us IG9yIG9uY2UgbXVzdCBkbyB2ZXJzaW9uIA0KPiA+IG5lZ290aWF0aW9uLg0KPiA+IA0KPiA+IEl0 IGlzIG9mdGVuIHRoZSBjYXNlIHRoYXQgdGhlcmUgY2FuIGJlIGFkZGl0aW9ucyB0byB0aGUgcHJv dG9jb2wgKG5ldyBUTFZzKSANCj4gPiB0aGF0IGNhbiBiZSBpZ25vcmVkIGlmIHRoZXkgYXJlIG5v dCB1bmRlcnN0b29kLiBJbiBmYWN0LCBpdCBpcyB1c3VhbGx5IA0KPiA+IGFyZ3VlZCB0aGF0IHRo ZSBiaWdnZXN0IHJlYXNvbiBmb3IgdXNpbmcgVExWIGVuY29kaW5ncyBpcyB0byBiZSBhYmxlIHRv IA0KPiA+IGlnbm9yZSB1bmtub3duIGVsZW1lbnRzLg0KPiA+IA0KPiANCj4gSW5kZWVkLg0KPiBX ZWltaW5nLCBoZXJlcyBhbiBleGFtcGxlL2FuYWxvZ3kgaW4gWE1MIHRoYXQgSSBoYXZlIG9mdGVu IHNlZW4gdXNlZDoNCj4gDQo+IDxlbWFpbGhlYWRlcj4NCj4gPFRPPldlaW1pbmc8L1RPPg0KPiA8 RnJvbT5Kb2VsPC9Gcm9tPg0KPiA8L2VtYWlsaGVhZGVyPg0KPiANCj4gTGV0cyBzYXkgeW91IHdy b3RlIGFuIGFwcCB0aGF0IHBhcnNlZCBhbmQgb3V0cHV0IHRoZSBmb2xsb3dpbmc6DQo+IA0KPiBT ZW5kZXI6IEpvZWwNCj4gUmVjaXBpZW50OiBXZWltaW5nDQo+IA0KPiBOb3cgbGV0cyBzYXkgeW91 ciBhcHAgMTAgeWVhcnMgZG93biB0aGUgcm9hZCBtZXQgdGhlIGZvbGxvd2luZyBYTUwNCj4gDQo+ IDxlbWFpbGhlYWRlcj4NCj4gPFRPPldlaW1pbmc8L1RPPg0KPiA8RnJvbT5Kb2VsPC9Gcm9tPg0K PiA8Q0M+SmFtYWw8L0NDPg0KPiA8L2VtYWlsaGVhZGVyPg0KPiANCj4gSXQgc2hvdWxkIG5vdCBk aWUgLSByYXRoZXIgaWdub3JlIDxDQz4gYW5kIHN0aWxsIG91dHB1dDoNCj4gDQo+IFNlbmRlcjog Sm9lbA0KPiBSZWNpcGllbnQ6IFdlaW1pbmcNCj4gDQo+IEl0IGlzIGdvb2QgcHJhY3Rpc2UgdG8g bG9nIHRoZSBleHRyYSA8Q0M+IHRhZyB0aGF0IGlzIG5vdCB1bmRlcnN0b29kDQo+IGJ1dCBpbiBw cmFjdGlzZSBzcGVjaWZ5aW5nIHRoYXQgaXQgaXMgdG8gYmUgaWdub3JlZCBpcyBhIGdvb2QgaWRl YS4NCj4gDQo+IEJhY2sgdG8gdGhlIGRyYWZ0Og0KPiBXZSBzaG91bGQgcmVjb21tZW5kIHRoYXQg dW5rbm93biBUTFZzIHNob3VsZCBiZSBpZ25vcmVkLg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA== From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 02 10:47:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCpI-0006TC-V5 for forces-archive@megatron.ietf.org; Fri, 02 Sep 2005 10:47:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12007 for ; Fri, 2 Sep 2005 10:47:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBCrS-00062c-QU for forces-archive@IETF.ORG; Fri, 02 Sep 2005 10:49:48 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010E0530@cherry.ease.lsoft.com>; Fri, 2 Sep 2005 10:47:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84649203 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 2 Sep 2005 10:46:48 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 2 Sep 2005 10:46:47 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j82E47XK076806; Fri, 2 Sep 2005 07:04:08 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> <009801c5aeff$127a8500$1f12fea9@wwm1> <1125585704.8390.6.camel@localhost.localdomain> <00ad01c5af09$2ae14520$1f12fea9@wwm1> <6.2.1.2.0.20050901151320.02db11c0@localhost> <003b01c5af5c$e49b9260$1f12fea9@wwm1> <6.2.1.2.0.20050901221354.02d9b160@localhost> <1125670870.6185.59.camel@localhost.localdomain> <03a701c5afca$abe40830$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1125672385.6185.68.camel@localhost.localdomain> Date: Fri, 2 Sep 2005 10:46:25 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 51]Operation Summary table Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <03a701c5afca$abe40830$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On Fri, 2005-02-09 at 22:28 +0800, Wang,Weiming wrote: > Jamal and Joel, > > That makes sense to me. I agree. I think the text of assumption > to ignore unknown TLVs can be added at the "protocol grammar" section, > is it ok? > This is tricky;-> My instinct says section 2 where TLV is defined? Right after text which describes 32 bit alignement a new paragraph with something like: "TLVs are extensively used in the protocol and the different types of TLVs will be defined in this document. For purposes of future extensibility, an implementation SHOULD ignore any TLVs it does not recognize. It is good practise that a debugging log should be emitted by the implementation to notify of the presence of unknown TLVs." The last sentence may be pushing it a little to put in a standard document. I used the term "debug" to imply it can be turned off. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 03 03:03:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBS4F-0000jQ-Js for forces-archive@megatron.ietf.org; Sat, 03 Sep 2005 03:03:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18647 for ; Sat, 3 Sep 2005 03:03:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBS6X-0005p3-Su for forces-archive@IETF.ORG; Sat, 03 Sep 2005 03:06:23 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010E121C@cherry.ease.lsoft.com>; Sat, 3 Sep 2005 3:03:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84700246 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 3 Sep 2005 03:03:56 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 3 Sep 2005 03:03:55 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id j836ndHC021551; Sat, 3 Sep 2005 08:49:44 +0200 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> <1125487290.6354.12.camel@localhost.localdomain> <009801c5aeff$127a8500$1f12fea9@wwm1> <1125585704.8390.6.camel@localhost.localdomain> <00ad01c5af09$2ae14520$1f12fea9@wwm1> <6.2.1.2.0.20050901151320.02db11c0@localhost> <003b01c5af5c$e49b9260$1f12fea9@wwm1> <6.2.1.2.0.20050901221354.02d9b160@localhost> <1125670870.6185.59.camel@localhost.localdomain> <03a701c5afca$abe40830$1152010a@Necom.hzic.edu.cn> <1125672385.6185.68.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Approved-By: Avri Doria Message-ID: <16CEF654-7979-4B26-8DB5-DDC6930B477C@psg.com> Date: Sat, 3 Sep 2005 09:03:41 +0200 Reply-To: Avri Doria Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: [Issue 51]Operation Summary table Comments: To: Jamal Hadi Salim To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1125672385.6185.68.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Hi, Why is this a SHOULD, instead of a MUST? If we are going to leave it as a SHOULD then we need to explain the case where it would be ok to not ignore it. I think there should actually be a specific error that indicates it is a unknown TLV. And I think it should be a different error then a parsing error since that might be an indication that it needs to be sent again. a. On 2 sep 2005, at 16.46, Jamal Hadi Salim wrote: > On Fri, 2005-02-09 at 22:28 +0800, Wang,Weiming wrote: > >> Jamal and Joel, >> >> That makes sense to me. I agree. I think the text of assumption >> to ignore unknown TLVs can be added at the "protocol grammar" >> section, >> is it ok? >> >> > > This is tricky;-> > My instinct says section 2 where TLV is defined? > Right after text which describes 32 bit alignement a new paragraph > with something like: > > "TLVs are extensively used in the protocol and the different types > of TLVs will be defined in this document. For purposes of future > extensibility, an implementation SHOULD ignore any TLVs it does > not recognize. It is good practise that a debugging log should be > emitted by the implementation to notify of the presence of unknown > TLVs." > > The last sentence may be pushing it a little to put in a standard > document. I used the term "debug" to imply it can be turned off. > > cheers, > jamal > > From LindaRosas@supraliminal.com Sat Sep 03 04:03:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBSzp-0000zc-Il; Sat, 03 Sep 2005 04:03:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20807; Sat, 3 Sep 2005 04:03:27 -0400 (EDT) Received: from n219078224235.netvigator.com ([219.78.224.235] ident=log956805) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EBT1x-0007ep-Pj; Sat, 03 Sep 2005 04:05:53 -0400 Received: from fiQ@localhost by NBH.int (8.11.6/8.11.6); Sun, 04 Sep 2005 04:31:51 +0300 Message-ID: From: "Lynda Carlton" Reply-To: "Lynda Carlton" To: forces-archive@ietf.org Cc: ipcdn-admin@ietf.org Subject: Huge $avings on ALL best-selling Office XP titles Date: Sat, 03 Sep 2005 18:31:51 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LindaRosas@supraliminal.com Content-Type: multipart/mixed; boundary="--wNdrxYQ6ymiB6f6k2" X-Spam-Score: 3.2 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 3je ----wNdrxYQ6ymiB6f6k2 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable D
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: nU7wE
 

Sales Rank= : #1
= System requirements  |  Ot= her Versions
Date Coupon Expires:= August 31st, 2005
Average Customer Revie= w:3D"5 Based on 18815 reviews. W= rite a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: 14NxLWXdV
 = ;

Sales Rank: #2
System requirements&nbs= p; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 19956= reviews. Write a review.

=
Microsoft Windows XP Professional or Longhorn Edition=
Microsoft

Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)



Ava= ilability: Available for INSTANT download!
Coupon Code: oXf= Ivo0
 

Sales Rank: #3
System requir= ements  |  Other Versions<= /a>
Date Coupon Expires: August 31st,= 2005
Average Customer Review:3D"5 Based on 17185 reviews. Write a review= .

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: ZIim8UqL
 =

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 19135= reviews. Write a review.

=

<= /form> ----wNdrxYQ6ymiB6f6k2-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 07 13:57:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4BB-0008Kb-D5 for forces-archive@megatron.ietf.org; Wed, 07 Sep 2005 13:57:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06059 for ; Wed, 7 Sep 2005 13:57:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED4EO-0005YG-Vr for forces-archive@IETF.ORG; Wed, 07 Sep 2005 14:01:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010E55AA@cherry.ease.lsoft.com>; Wed, 7 Sep 2005 13:57:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85018869 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 7 Sep 2005 13:57:34 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 7 Sep 2005 13:57:33 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j87HDrXK029358 for ; Wed, 7 Sep 2005 10:13:54 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126115848.8422.47.camel@localhost.localdomain> Date: Wed, 7 Sep 2005 13:57:28 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Folks, At the moment we are ambiguous about the heartbeat; the draft states as it being either from CE->FE or FE->CE and in-fact doesn't discount CE<->CE or FE<->FE (which is outside the scope). a) What we have found is that the most effective way to do this is to actually have heartbeats going from CE->FE since the CE is the master, mostly. More importantly is that this is allows for more complexity on the CE than on the FE (which is important). I also like the fact that if we ever use a multicast capable TML, we can optimize further the amount of traffic on the wire - which is impossible if direction was FE->CE. b) We have implemented the thought originated from Joel to have the heartbeats being optimized (for scalability purposes) to be adaptively traffic-sensitive. In such a scheme heartbeats are only sent if no other traffic has been sent to the FE since the last heartbeat interval. This is a good optimization since it means that in idle (CE->FE) periods a lot more heartbeats are sent than in busy periods. c) Further observation is that the directionality is important. If CE->FE is the direction, all this is doing is health checking from the FEs perspective of the CE. Vice-versa if direction was FE->CE. Ideally we would like both health checks. So one thing we are experimenting with is an extension of #b above. Instead of just the check for whether we have sent any traffic to the FE in the last heartbeat interval, we also check if we have received any. In most cases if we sent, we probably also received a response, so the check doesnt make a difference. In the cases where we have not received traffic from the FE, we set the ACK flag which tells the FE to actually respond to the HB. Only in this case do we have bidirectional HB, i.e, a ping-pong. Could people please express their opinions on this? interop will be affected if any one implementation doesnt obey _all_ 3 rules above. I think all 3 above are very useful and if theres agreement i will edit the draft to reflect things. The FE Protocol Object LFB will have to change, but lets not go there yet - lets agree on the above first. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 07 21:48:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDBWy-0006Uj-9X for forces-archive@megatron.ietf.org; Wed, 07 Sep 2005 21:48:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07079 for ; Wed, 7 Sep 2005 21:48:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDBaD-0003Ei-Gl for forces-archive@IETF.ORG; Wed, 07 Sep 2005 21:52:12 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010E5BD1@cherry.ease.lsoft.com>; Wed, 7 Sep 2005 21:48:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85044782 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 7 Sep 2005 21:48:39 -0400 Received: from 209.119.0.160 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 7 Sep 2005 21:48:39 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.0093AB37@almond.ease.lsoft.com>; Wed, 7 Sep 2005 21:48:39 -0400 Message-ID: Date: Wed, 7 Sep 2005 21:48:24 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 hi, First, I think b) should be followed, as we do it in our implementation and others. Besides, I agree with either of the following two options. Heartbeat Message never expect responses. Message Transfer Direction: CE<->FE CE and FE passively detect the liveness of the peer. Heartbeat Message can expect responses. Message Transfer Direction: CE<->FE FE passively detect the liveness of CE CE actively detect the liveness of FE by requesting ACK regards Ligang ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Thursday, September 08, 2005 1:57 AM Subject: Section 9: Heartbeat Messages > Folks, > > At the moment we are ambiguous about the heartbeat; the draft states > as it being either from CE->FE or FE->CE and in-fact doesn't discount > CE<->CE or FE<->FE (which is outside the scope). > > a) What we have found is that the most effective way to do this is to > actually have heartbeats going from CE->FE since the CE is the master, > mostly. More importantly is that this is allows for more complexity on > the CE than on the FE (which is important). I also like the fact that > if we ever use a multicast capable TML, we can optimize further the > amount of traffic on the wire - which is impossible if direction was > FE->CE. > > b) We have implemented the thought originated from Joel to have the > heartbeats being optimized (for scalability purposes) to be adaptively > traffic-sensitive. In such a scheme heartbeats are only sent if no other > traffic has been sent to the FE since the last heartbeat interval. This > is a good optimization since it means that in idle (CE->FE) periods a > lot more heartbeats are sent than in busy periods. > > c) Further observation is that the directionality is important. If > CE->FE is the direction, all this is doing is health checking from the > FEs perspective of the CE. Vice-versa if direction was FE->CE. > Ideally we would like both health checks. So one thing we are > experimenting with is an extension of #b above. > Instead of just the check for whether we have sent any traffic to the FE > in the last heartbeat interval, we also check if we have received any. > In most cases if we sent, we probably also received a response, so the > check doesnt make a difference. In the cases where we have not received > traffic from the FE, we set the ACK flag which tells the FE to actually > respond to the HB. Only in this case do we have bidirectional HB, i.e, a > ping-pong. > > Could people please express their opinions on this? interop will be > affected if any one implementation doesnt obey _all_ 3 rules above. > I think all 3 above are very useful and if theres agreement i will edit > the draft to reflect things. > The FE Protocol Object LFB will have to change, but lets not go there > yet - lets agree on the above first. > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 08 09:01:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDM2D-000472-S5 for forces-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:01:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18085 for ; Thu, 8 Sep 2005 09:01:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDM5Y-000398-Bf for forces-archive@IETF.ORG; Thu, 08 Sep 2005 09:05:15 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.010E60C7@cherry.ease.lsoft.com>; Thu, 8 Sep 2005 9:01:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85073361 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 8 Sep 2005 09:01:07 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Sep 2005 09:00:51 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 8 Sep 2005 21:33:45 +0800 (CST) References: <1126115848.8422.47.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <007f01c5b475$8bd850f0$1f12fea9@wwm1> Date: Thu, 8 Sep 2005 21:02:19 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: base64 SmFtYWwsDQoNCkkgdGhpbmsgb2YgdGhlIGhlYXJ0YmVhdCBtZWNoYW5pc20gYSBiaXQgZGlmZmVy ZW50bHksIHN1bW1hcml6ZWQgYXMgYmVsb3c6DQoNCjEuIGEgaGVhcnRiZWF0IGFjdHMgYXMgYSBz aWduYWwgdG8gc2hvdyB0aGUgbGl2ZW5lc3Mgb2YgdGhlIHNlbmRlciwgdGhlcmVmb3JlLCBJIGNh bm5vdCBzZWUgdGhlIHZhbHVlIHRvIGhhdmUgYSBoZWFydGJlYXQgcmVzcG9uc2UuIFdoYXQgZG9l cyBzdWNoIHJlc3BvbnNlIGFjdHVhbGx5IG1lYW4/IA0KDQoyLiB0byBoYXZlIGEgcGlnZ3ktYmFj a2luZyBoZWFydGJlYXQgaXMgdmFsdWFibGUuIFdlIGhhdmUgYWxyZWFkeSBoYWQgaXNzdWUgMTEg Zm9yIHRoaXMsIGFuZCBJIHRoaW5rIGl0IGhhcyBiZWVuIGFjY2VwdGVkLiBUaGUgb25seSB0aGlu ZyBsZWZ0IGlzIHdlIGhhdmUgbm90IGhhZCBpdCByZWZsZWN0ZWQgaW4gdGhlIGRyYWZ0IHRleHQu IEl0J3MgcmVhbGx5IG5vdCBhIGJpZyBjaGFuZ2UsIGFuZCBJIHN1cHBvc2UgdGhlIGZvbGxvd2lu ZyB0ZXh0IHRvIGluY29ycGFyYXRlIHRoZSBwaWdneS1iYWNraW5nIGhlYXJ0YmVhdDoNCg0KPG9y aWdpbmFsIFAuNDI+DQpGRSBQcm90b2NvbCBhdHRyaWJ1dGVzIChjYW4gYmUgcmVhZCBhbmQgc2V0 KToNCi4uLg0KICAgICAgKiAgSGVhcnRiZWF0IEludGVydmFsLiAgRGVmdWFsdCBWYWx1ZSA9IDMw MCBtc2VjDQo8L29yaWdpbmFsIFAuNDI+DQoNCldlIG1heSBhZGQgdGhlIHBpZ2d5LWJhY2tpbmcg aGVhcnRiZWF0IGJ5IG1vZGlmeWluZyB0aGlzIGF0dHJpYnV0ZSBhcyBzb21ldGhpbmcgbGlrZToN Cg0KPGNoYW5nZSB0bz4NCkZFIFByb3RvY29sIGF0dHJpYnV0ZXMgKGNhbiBiZSByZWFkIGFuZCBz ZXQpOg0KLi4uDQogICAgICAqIEhlYXJ0YmVhdCBwb2xpY3kgYW5kIHBhcmFtZXRlcnMsIHdoaWNo IGluY2x1ZGVzIGZpZWxkcyBhczoNCg0KICAgICAgICAuIEhlYXJ0YmVhdCBwb2xpY3ksIHdoaWNo IGZ1cnRoZXIgaW5jbHVkZXMgdHdvIGZpZWxkczoNCg0KICAgICAgICAgICBDRSBoZWFydGJlYXQg cG9saWN5OiB0byB0ZWxsIEZFIHdoaWNoIGhlYXJ0YmVhdCBwb2xpY3kgdGhlIENFIGNob29zZXMu DQoNCiAgICAgICAgICAgIDAgLSBDRSBubyBoZWFydGJlYXQNCiAgICAgICAgICAgIDEgLSBDRSBu b3JtYWwgaGVhcnRiZWF0DQogICAgICAgICAgICAyIC0gQ0UgcGlnZ3ktYmFja2luZyBoZWFydGJl YXQNCg0KICAgICAgICAgICBGRSBoZWFydGJlYXQgcG9saWN5OiB0byBjb21tYW5kIHRoZSBGRSB0 byB1c2UgdGhlIGhlYXJ0YmVhdCBwb2xpY3kuDQoNCiAgICAgICAgICAgIDAgLSBGRSBubyBoZWFy dGJlYXQNCiAgICAgICAgICAgIDEgLSBGRSBub3JtYWwgaGVhcnRiZWF0DQogICAgICAgICAgICAy IC0gRkUgcGlnZ3ktYmFja2luZyBoZWFydGJlYXQNCg0KICAgICAgICAuIENFIGhlYXJ0YmVhdCBp bnRlcnZhbCwgdG8gdGVsbCBGRSB0aGUgaGVhcnRiZWF0IGludGVydmFsIENFIHVzZXMuIGlmIG5v dCBzZXQgb3Igc2V0IHRvIDAsIGl0IG1lYW5zIENFIGNob29zZXMgYSBkZWZhdWx0IHZhbHVlLCB3 aGljaCBpcyAzMDBtc2VjDQoNCiAgICAgICAgLiBGRSBoZWFydGJlYXQgaW50ZXJ2YWwsIHRvIGNv bW1hbmQgRkUgdG8gdXNlIHRoZSBpbnRlcnZhbCBmb3IgdGhlIEZFIGhlYXJ0YmVhdC4gSWYgbm90 IHNldCBvciBzZXQgdG8gMCwgaXQgbWVhbnMgRkUgbXVzdCBjaG9vc2UgdGhlIGRlZmF1bHQgdmFs dWUsIHdoaWNoIGlzIDMwMG1zZWMNCg0KPC9jaGFuZ2UgdG8+DQoNCk5vdGUgaW4gYWJvdmUsIENF IG5lZWQgdG8gdGVsbCBGRSBob3cgaXQgZ2VuZXJhdGVzIGhlYXJ0YmVhdCBhbHNvLCBzbyB0aGF0 IEZFIGNhbiBjb3JyZWN0bHkgc2Vuc2UgdGhlIENFIGxpdmVuZXNzLg0KDQpXZSBtYXkgYWxzbyBu ZWVkIHRvIGFkZCBzb21lIHRleHQgaW4gdGhlIEhlYXJ0YmVhdCBNZXNzYWdlIHNlY3Rpb24gbWVu dGlvbmluZyB0aGF0ICJ0aGUgaGVhcnRiZWF0IGlzIGdlbmVyYXRlZCBhY2NvcmRpbmcgdG8gdGhl IGhlYXJ0YmVhdCBwb2xpY3kgc2V0IGluIHRoZSBGRSBQcm90b2NvbCBMRkIgYXR0cmlidXRlLCB3 aGljaCBzcGVjaWZpZXMgd2hldGhlciB0aGUgaGVhcnRiZWF0IGdlbmVyYXRlZCBpcyBub3JtYWwg b3IgcGlnZ3ktYmFja2luZyBvdmVyIG90aGVyIG1lc3NhZ2VzLiINCg0KQW55IHRob3VnaHRzPw0K DQpUaGFua3MsDQpXZWltaW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9t OiAiSmFtYWwgSGFkaSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQoNCj4gRm9sa3MsDQo+IA0KPiBB dCB0aGUgbW9tZW50IHdlIGFyZSBhbWJpZ3VvdXMgYWJvdXQgdGhlIGhlYXJ0YmVhdDsgdGhlIGRy YWZ0IHN0YXRlcw0KPiBhcyBpdCBiZWluZyBlaXRoZXIgZnJvbSBDRS0+RkUgb3IgRkUtPkNFIGFu ZCBpbi1mYWN0IGRvZXNuJ3QgZGlzY291bnQNCj4gQ0U8LT5DRSBvciBGRTwtPkZFICh3aGljaCBp cyBvdXRzaWRlIHRoZSBzY29wZSkuDQo+IA0KPiBhKSBXaGF0IHdlIGhhdmUgZm91bmQgaXMgdGhh dCB0aGUgbW9zdCBlZmZlY3RpdmUgd2F5IHRvIGRvIHRoaXMgaXMgdG8NCj4gYWN0dWFsbHkgaGF2 ZSBoZWFydGJlYXRzIGdvaW5nIGZyb20gQ0UtPkZFIHNpbmNlIHRoZSBDRSBpcyB0aGUgbWFzdGVy LA0KPiBtb3N0bHkuIE1vcmUgaW1wb3J0YW50bHkgaXMgdGhhdCB0aGlzIGlzIGFsbG93cyBmb3Ig bW9yZSBjb21wbGV4aXR5IG9uDQo+IHRoZSBDRSB0aGFuIG9uIHRoZSBGRSAod2hpY2ggaXMgaW1w b3J0YW50KS4gSSBhbHNvIGxpa2UgdGhlIGZhY3QgdGhhdCANCj4gaWYgd2UgZXZlciB1c2UgYSBt dWx0aWNhc3QgY2FwYWJsZSBUTUwsIHdlIGNhbiBvcHRpbWl6ZSBmdXJ0aGVyIHRoZQ0KPiBhbW91 bnQgb2YgdHJhZmZpYyBvbiB0aGUgd2lyZSAtIHdoaWNoIGlzIGltcG9zc2libGUgaWYgZGlyZWN0 aW9uIHdhcw0KPiBGRS0+Q0UuDQo+IA0KPiBiKSBXZSBoYXZlIGltcGxlbWVudGVkIHRoZSB0aG91 Z2h0IG9yaWdpbmF0ZWQgZnJvbSBKb2VsIHRvIGhhdmUgdGhlDQo+IGhlYXJ0YmVhdHMgYmVpbmcg b3B0aW1pemVkIChmb3Igc2NhbGFiaWxpdHkgcHVycG9zZXMpIHRvIGJlIGFkYXB0aXZlbHkNCj4g dHJhZmZpYy1zZW5zaXRpdmUuIEluIHN1Y2ggYSBzY2hlbWUgaGVhcnRiZWF0cyBhcmUgb25seSBz ZW50IGlmIG5vIG90aGVyDQo+IHRyYWZmaWMgaGFzIGJlZW4gc2VudCB0byB0aGUgRkUgc2luY2Ug dGhlIGxhc3QgaGVhcnRiZWF0IGludGVydmFsLiBUaGlzDQo+IGlzIGEgZ29vZCBvcHRpbWl6YXRp b24gc2luY2UgaXQgbWVhbnMgdGhhdCBpbiBpZGxlIChDRS0+RkUpIHBlcmlvZHMgYQ0KPiBsb3Qg bW9yZSBoZWFydGJlYXRzIGFyZSBzZW50IHRoYW4gaW4gYnVzeSBwZXJpb2RzLg0KPiANCj4gYykg RnVydGhlciBvYnNlcnZhdGlvbiBpcyB0aGF0IHRoZSBkaXJlY3Rpb25hbGl0eSBpcyBpbXBvcnRh bnQuIElmDQo+IENFLT5GRSBpcyB0aGUgZGlyZWN0aW9uLCBhbGwgdGhpcyBpcyBkb2luZyBpcyBo ZWFsdGggY2hlY2tpbmcgZnJvbSB0aGUNCj4gRkVzIHBlcnNwZWN0aXZlIG9mIHRoZSBDRS4gVmlj ZS12ZXJzYSBpZiBkaXJlY3Rpb24gd2FzIEZFLT5DRS4NCj4gSWRlYWxseSB3ZSB3b3VsZCBsaWtl IGJvdGggaGVhbHRoIGNoZWNrcy4gU28gb25lIHRoaW5nIHdlIGFyZQ0KPiBleHBlcmltZW50aW5n IHdpdGggaXMgYW4gZXh0ZW5zaW9uIG9mICNiIGFib3ZlLiANCj4gSW5zdGVhZCBvZiBqdXN0IHRo ZSBjaGVjayBmb3Igd2hldGhlciB3ZSBoYXZlIHNlbnQgYW55IHRyYWZmaWMgdG8gdGhlIEZFDQo+ IGluIHRoZSBsYXN0IGhlYXJ0YmVhdCBpbnRlcnZhbCwgd2UgYWxzbyBjaGVjayBpZiB3ZSBoYXZl IHJlY2VpdmVkIGFueS4NCj4gSW4gbW9zdCBjYXNlcyBpZiB3ZSBzZW50LCB3ZSBwcm9iYWJseSBh bHNvIHJlY2VpdmVkIGEgcmVzcG9uc2UsIHNvIHRoZQ0KPiBjaGVjayBkb2VzbnQgbWFrZSBhIGRp ZmZlcmVuY2UuIEluIHRoZSBjYXNlcyB3aGVyZSB3ZSBoYXZlIG5vdCByZWNlaXZlZA0KPiB0cmFm ZmljIGZyb20gdGhlIEZFLCB3ZSBzZXQgdGhlIEFDSyBmbGFnIHdoaWNoIHRlbGxzIHRoZSBGRSB0 byBhY3R1YWxseQ0KPiByZXNwb25kIHRvIHRoZSBIQi4gT25seSBpbiB0aGlzIGNhc2UgZG8gd2Ug aGF2ZSBiaWRpcmVjdGlvbmFsIEhCLCBpLmUsIGENCj4gcGluZy1wb25nLg0KPiANCj4gQ291bGQg cGVvcGxlIHBsZWFzZSBleHByZXNzIHRoZWlyIG9waW5pb25zIG9uIHRoaXM/IGludGVyb3Agd2ls bCBiZQ0KPiBhZmZlY3RlZCBpZiBhbnkgb25lIGltcGxlbWVudGF0aW9uIGRvZXNudCBvYmV5IF9h bGxfIDMgcnVsZXMgYWJvdmUuDQo+IEkgdGhpbmsgYWxsIDMgYWJvdmUgYXJlIHZlcnkgdXNlZnVs IGFuZCBpZiB0aGVyZXMgYWdyZWVtZW50IGkgd2lsbCBlZGl0DQo+IHRoZSBkcmFmdCB0byByZWZs ZWN0IHRoaW5ncy4NCj4gVGhlIEZFIFByb3RvY29sIE9iamVjdCBMRkIgd2lsbCBoYXZlIHRvIGNo YW5nZSwgYnV0IGxldHMgbm90IGdvIHRoZXJlDQo+IHlldCAtIGxldHMgYWdyZWUgb24gdGhlIGFi b3ZlIGZpcnN0Lg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA== From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 08 09:31:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMUi-0002o0-Cy for forces-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:31:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19271 for ; Thu, 8 Sep 2005 09:31:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDMY2-0003tN-0u for forces-archive@IETF.ORG; Thu, 08 Sep 2005 09:34:42 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010E616E@cherry.ease.lsoft.com>; Thu, 8 Sep 2005 9:31:06 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85075886 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 8 Sep 2005 09:31:05 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Sep 2005 09:31:04 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j88CkeXK038248; Thu, 8 Sep 2005 05:46:41 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126186227.6416.27.camel@localhost.localdomain> Date: Thu, 8 Sep 2005 09:30:27 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Section 9: Heartbeat Messages Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <007f01c5b475$8bd850f0$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Weiming, On Thu, 2005-08-09 at 21:02 +0800, Weiming Wang wrote: > Jamal, > > I think of the heartbeat mechanism a bit differently, summarized as below: > > 1. a heartbeat acts as a signal to show the liveness of the sender, Yes, this is the way i see too ;-> More below. > therefore, > I cannot see the value to have a heartbeat response. What does such response > actually mean? > CE->FE is announcing liveliness of CE to FE. A response from FE is to announce liveliness of FE to CE. Given Joels optimization - the only time we have traffic both directions is when neither the CE nor FE has any activity. There could be some semi-quiet period, for example it is possible to have FE send synchronous/periodic events like stats in which case we know it is alive. In most cases the interaction will be config/query form. In the case of config and query from CE->FE we know the FE is alive when we receive a response for the query/config. So the optimization works very well, only we need to use it in both directions to reduce the number of HB messages in busy periods. > 2. to have a piggy-backing heartbeat is valuable. We have already had issue > 11 for this, and I think it has been accepted. The only thing left is we have > not had it reflected in the draft text. It's really not a big change, and I > suppose the following text to incorparate the piggy-backing heartbeat: > Ok, so issue 11 is one of the reasons that prompted me to post actually. BTW, it should be open until text is entered. I was a big fan of piggybacking before - After we implemented current HB i found it to be unnecessary to have piggybacking. This is because _every message_ between a CE<->FE is a liveliness checker. Does this make sense? I am not asking for its removal if people have implemented and found it necessary (we too in the past have implemented that way). > > FE Protocol attributes (can be read and set): > ... > * Heartbeat Interval. Defualt Value = 300 msec > > > We may add the piggy-backing heartbeat by modifying this attribute as something like: > [..] > > Note in above, CE need to tell FE how it generates heartbeat also, so that FE can > correctly sense the CE liveness. > Refer to my comments above. I think it is not necessary for the FE to send any heartbeats at all. It will always be responding to queries and configs and from that we can tell its liveliness (given the optimizations). My recommendation is that since the CE is the master it should be the one issuing the ACK flag when it hasnt heard from the FE when the heartbeat interval expires. Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 08 10:08:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDN4V-0003ja-Hl for forces-archive@megatron.ietf.org; Thu, 08 Sep 2005 10:08:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21258 for ; Thu, 8 Sep 2005 10:08:09 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDN7p-0004t1-DK for forces-archive@IETF.ORG; Thu, 08 Sep 2005 10:11:42 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010E6427@cherry.ease.lsoft.com>; Thu, 8 Sep 2005 10:08:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85077189 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 8 Sep 2005 10:08:05 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Sep 2005 10:08:05 -0400 Received: from [12.58.128.11] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12439176 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 08 Sep 2005 10:08:03 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050908100629.02dd9840@localhost> Date: Thu, 8 Sep 2005 10:08:02 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <007f01c5b475$8bd850f0$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b There are two (at least) valid implementation models for heartbeats... One can say that the heartbeat is a signal that the sender is live. Then each side independently sends heartbeats. One can also say that heartbeat is a connection liveness monitor, managed by one side. This usually requires the other side to respond. This has the advantage or disadvantage that the behavior is driven by one side. Yours, Joel At 09:02 AM 9/8/2005, Weiming Wang wrote: >Jamal, > >I think of the heartbeat mechanism a bit differently, summarized as below: > >1. a heartbeat acts as a signal to show the liveness of the sender, >therefore, I cannot see the value to have a heartbeat response. What does >such response actually mean? > >2. to have a piggy-backing heartbeat is valuable. We have already had >issue 11 for this, and I think it has been accepted. The only thing left >is we have not had it reflected in the draft text. It's really not a big >change, and I suppose the following text to incorparate the piggy-backing >heartbeat: > > >FE Protocol attributes (can be read and set): >... > * Heartbeat Interval. Defualt Value = 300 msec > > >We may add the piggy-backing heartbeat by modifying this attribute as >something like: > > >FE Protocol attributes (can be read and set): >... > * Heartbeat policy and parameters, which includes fields as: > > . Heartbeat policy, which further includes two fields: > > CE heartbeat policy: to tell FE which heartbeat policy the CE > chooses. > > 0 - CE no heartbeat > 1 - CE normal heartbeat > 2 - CE piggy-backing heartbeat > > FE heartbeat policy: to command the FE to use the heartbeat > policy. > > 0 - FE no heartbeat > 1 - FE normal heartbeat > 2 - FE piggy-backing heartbeat > > . CE heartbeat interval, to tell FE the heartbeat interval CE > uses. if not set or set to 0, it means CE chooses a default value, which > is 300msec > > . FE heartbeat interval, to command FE to use the interval for > the FE heartbeat. If not set or set to 0, it means FE must choose the > default value, which is 300msec > > > >Note in above, CE need to tell FE how it generates heartbeat also, so that >FE can correctly sense the CE liveness. > >We may also need to add some text in the Heartbeat Message section >mentioning that "the heartbeat is generated according to the heartbeat >policy set in the FE Protocol LFB attribute, which specifies whether the >heartbeat generated is normal or piggy-backing over other messages." > >Any thoughts? > >Thanks, >Weiming > >----- Original Message ----- >From: "Jamal Hadi Salim" > > > Folks, > > > > At the moment we are ambiguous about the heartbeat; the draft states > > as it being either from CE->FE or FE->CE and in-fact doesn't discount > > CE<->CE or FE<->FE (which is outside the scope). > > > > a) What we have found is that the most effective way to do this is to > > actually have heartbeats going from CE->FE since the CE is the master, > > mostly. More importantly is that this is allows for more complexity on > > the CE than on the FE (which is important). I also like the fact that > > if we ever use a multicast capable TML, we can optimize further the > > amount of traffic on the wire - which is impossible if direction was > > FE->CE. > > > > b) We have implemented the thought originated from Joel to have the > > heartbeats being optimized (for scalability purposes) to be adaptively > > traffic-sensitive. In such a scheme heartbeats are only sent if no other > > traffic has been sent to the FE since the last heartbeat interval. This > > is a good optimization since it means that in idle (CE->FE) periods a > > lot more heartbeats are sent than in busy periods. > > > > c) Further observation is that the directionality is important. If > > CE->FE is the direction, all this is doing is health checking from the > > FEs perspective of the CE. Vice-versa if direction was FE->CE. > > Ideally we would like both health checks. So one thing we are > > experimenting with is an extension of #b above. > > Instead of just the check for whether we have sent any traffic to the FE > > in the last heartbeat interval, we also check if we have received any. > > In most cases if we sent, we probably also received a response, so the > > check doesnt make a difference. In the cases where we have not received > > traffic from the FE, we set the ACK flag which tells the FE to actually > > respond to the HB. Only in this case do we have bidirectional HB, i.e, a > > ping-pong. > > > > Could people please express their opinions on this? interop will be > > affected if any one implementation doesnt obey _all_ 3 rules above. > > I think all 3 above are very useful and if theres agreement i will edit > > the draft to reflect things. > > The FE Protocol Object LFB will have to change, but lets not go there > > yet - lets agree on the above first. > > > > cheers, > > jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 08 10:24:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNK6-0008Eq-Qk for forces-archive@megatron.ietf.org; Thu, 08 Sep 2005 10:24:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22759 for ; Thu, 8 Sep 2005 10:24:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDNNU-0005He-77 for forces-archive@IETF.ORG; Thu, 08 Sep 2005 10:27:49 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010E6230@cherry.ease.lsoft.com>; Thu, 8 Sep 2005 10:24:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85077877 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 8 Sep 2005 10:24:11 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Sep 2005 10:24:09 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 8 Sep 2005 22:57:26 +0800 (CST) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> Date: Thu, 8 Sep 2005 22:25:58 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: base64 amFtYWwsDQoNCkxldCdzIGZpcnN0IHN5bmNyb25pemUgc29tZXRoaW5nLiBNeSB1bmRlcnN0YW5k aW5nIG9mIHBpZ2d5LWJhY2tpbmcgaXMgbm90IHRvIGxldCBhIGhlYXJ0YmVhdCBtZXNzYWdlIHBp Z2d5LWJhY2tlZCBvbiBvdGhlciBtZXNzYWdlcywgaW5zdGVhZCwgaXQgaXMgZXhhY3RseSB0aGUg bWVhbmluZyB0aGF0IGFueSBtZXNzYWdlcyBjYW4gYWN0IGZvciBoZWFydGJlYXQuIFdpdGggdGhp cyBpbiBtaW5kLCBJIHRoaW5rIHdlIGFyZSBvbiB0aGUgc2FtZSBwYWdlIHdpdGggdGhlIHVzZSBv ZiBzdWNoIHBpZ2d5LWJhY2tpbmcgKG1heWJlIG5lZWQgc29tZSB0ZXh0IHRvIGNsYXJpZnkgaXQg bW9yZSBpbiB0aGUgdGV4dCB0aGF0IEkgcHJvcG9zZWQpLiANCg0KTm93IHRoZSBvbmx5IHRoaW5n IGxlZnQgaXMsIHlvdSBzZWVtIHRvIHByZWZlciB0byB1c2UgdGhlIENFLT5GRSBoZWFydGJlYXQg YXMgc29tZSBraW5nIG9mIGxpdmVuZXNzIHN0cm9iZSBtZXNzYWdlLCBpLmUuLCBDRSBzZW5kcyBh IGhlYXJ0YmVhdCB0byBGRSBvbmx5IGluIHRoZSBob3BlIG9mIGdldHRpbmcgYSByZXNwb25zZSBz byBhcyB0byBzZW5zZSB0aGUgbGl2ZW5lc3Mgb2YgdGhlIEZFLiBXZSBtYXkgaGF2ZSB0d28gc2hv cnRjdXRzIHVzaW5nIHN1Y2ggc2NoZW1lLCBJIHN1cHBvc2U6DQoNCjEuIGl0J3Mgc3RpbGwgbm90 IGFibGUgdG8gbGV0IEZFIHRvIHNlbnNlIHRoZSBsaXZlbmVzcyBvZiBDRSAod2UgbWF5IGdvIHRv IHRoZSBkaXNjdXNzaW9uIG9uIGlmIEZFIG5lZWQgdG8gc2Vuc2UgbGl2ZW5lc3Mgb2YgQ0UsIGJ1 dCBsZXQncyBzdXBwb3NlIGl0IGlzIG5lZWRlZCkuIExldCdzIHRyeSB0byBnaXZlIGEgc2NlbmFy aW8gZm9yIHRoaXM6IHNheSBDRSBpcyBxdWl0ZSwgYW5kIEZFIGlzIGZyZXF1ZW50bHkgc2VuZGlu ZyBldmVudHMuICBCZWNhdXNlIENFIGNhbiBzZW5zZSB0aGUgRkUsIENFIHdpbGwgYWxzbyBub3Qg c2VuZCBhbnkgQ0UtPkZFIHN0cm9iZSBtZXNzYWdlIHRoZW4uIEluIHRoaXMgY2FzZSwgQ0UgY2Fu IHNlbnNlIEZFIGxpdmVuZXNzLCB3aGlsZSBGRSBjYW5uJ3Qgc2Vuc2UgQ0UuDQoNCjIuIEknbSBu b3Qgc3VyZSBpZiBpdCdzIG1vcmUgb3B0aW1pemVkIHRvIHNlbnNlIEZFIGJ5IENFIGFjdGl2ZWx5 IHNlbmRpbmcgc3Ryb2JlIG1lc3NhZ2UgdGhhbiBieSB0aGUgRkUgYWN0aXZlbHkgc2VuZGluZyBo ZWFydGJlYXQgbWVzc2FnZSwgYmVjYXVzZSB0aGUgZm9ybWVyIG5lZWRzIHR3byBtZXNzYWdlcywg d2hpbGUgdGhlIGxhdHRlciBvbmx5IG9uZS4NCg0KVGhhbmtzLA0KV2VpbWluZw0KLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4 LmNvbT4NCg0KPiBXZWltaW5nLA0KPiANCj4gT24gVGh1LCAyMDA1LTA4LTA5IGF0IDIxOjAyICsw ODAwLCBXZWltaW5nIFdhbmcgd3JvdGU6DQo+ID4gSmFtYWwsDQo+ID4gDQo+ID4gSSB0aGluayBv ZiB0aGUgaGVhcnRiZWF0IG1lY2hhbmlzbSBhIGJpdCBkaWZmZXJlbnRseSwgc3VtbWFyaXplZCBh cyBiZWxvdzoNCj4gPiANCj4gPiAxLiBhIGhlYXJ0YmVhdCBhY3RzIGFzIGEgc2lnbmFsIHRvIHNo b3cgdGhlIGxpdmVuZXNzIG9mIHRoZSBzZW5kZXIsIA0KPiANCj4gWWVzLCB0aGlzIGlzIHRoZSB3 YXkgaSBzZWUgdG9vIDstPiBNb3JlIGJlbG93Lg0KPiANCj4gPiB0aGVyZWZvcmUsIA0KPiA+IEkg Y2Fubm90IHNlZSB0aGUgdmFsdWUgdG8gaGF2ZSBhIGhlYXJ0YmVhdCByZXNwb25zZS4gV2hhdCBk b2VzIHN1Y2ggcmVzcG9uc2UgDQo+ID4gYWN0dWFsbHkgbWVhbj8gDQo+ID4gDQo+IA0KPiBDRS0+ RkUgaXMgYW5ub3VuY2luZyBsaXZlbGluZXNzIG9mIENFIHRvIEZFLg0KPiBBIHJlc3BvbnNlIGZy b20gRkUgaXMgdG8gYW5ub3VuY2UgbGl2ZWxpbmVzcyBvZiBGRSB0byBDRS4NCj4gR2l2ZW4gSm9l bHMgb3B0aW1pemF0aW9uIC0gdGhlIG9ubHkgdGltZSB3ZSBoYXZlIHRyYWZmaWMgYm90aCBkaXJl Y3Rpb25zDQo+IGlzIHdoZW4gbmVpdGhlciB0aGUgQ0Ugbm9yIEZFIGhhcyBhbnkgYWN0aXZpdHku IFRoZXJlIGNvdWxkIGJlIHNvbWUNCj4gc2VtaS1xdWlldCBwZXJpb2QsIGZvciBleGFtcGxlIGl0 IGlzIHBvc3NpYmxlIHRvIGhhdmUgRkUgc2VuZA0KPiBzeW5jaHJvbm91cy9wZXJpb2RpYyBldmVu dHMgbGlrZSBzdGF0cyBpbiB3aGljaCBjYXNlIHdlIGtub3cgaXQgaXMNCj4gYWxpdmUuICANCj4g SW4gbW9zdCBjYXNlcyB0aGUgaW50ZXJhY3Rpb24gd2lsbCBiZSBjb25maWcvcXVlcnkgZm9ybS4N Cj4gSW4gdGhlIGNhc2Ugb2YgY29uZmlnIGFuZCBxdWVyeSBmcm9tIENFLT5GRSB3ZSBrbm93IHRo ZSBGRSBpcyBhbGl2ZSB3aGVuDQo+IHdlIHJlY2VpdmUgYSByZXNwb25zZSBmb3IgdGhlIHF1ZXJ5 L2NvbmZpZy4NCj4gU28gdGhlIG9wdGltaXphdGlvbiB3b3JrcyB2ZXJ5IHdlbGwsIG9ubHkgd2Ug bmVlZCB0byB1c2UgaXQgaW4gYm90aA0KPiBkaXJlY3Rpb25zIHRvIHJlZHVjZSB0aGUgbnVtYmVy IG9mIEhCIG1lc3NhZ2VzIGluIGJ1c3kgcGVyaW9kcy4NCj4gDQo+ID4gMi4gdG8gaGF2ZSBhIHBp Z2d5LWJhY2tpbmcgaGVhcnRiZWF0IGlzIHZhbHVhYmxlLiBXZSBoYXZlIGFscmVhZHkgaGFkIGlz c3VlIA0KPiA+IDExIGZvciB0aGlzLCBhbmQgSSB0aGluayBpdCBoYXMgYmVlbiBhY2NlcHRlZC4g VGhlIG9ubHkgdGhpbmcgbGVmdCBpcyB3ZSBoYXZlIA0KPiA+IG5vdCBoYWQgaXQgcmVmbGVjdGVk IGluIHRoZSBkcmFmdCB0ZXh0LiBJdCdzIHJlYWxseSBub3QgYSBiaWcgY2hhbmdlLCBhbmQgSSAN Cj4gPiBzdXBwb3NlIHRoZSBmb2xsb3dpbmcgdGV4dCB0byBpbmNvcnBhcmF0ZSB0aGUgcGlnZ3kt YmFja2luZyBoZWFydGJlYXQ6DQo+ID4gDQo+IA0KPiBPaywgc28gaXNzdWUgMTEgaXMgb25lIG9m IHRoZSByZWFzb25zIHRoYXQgcHJvbXB0ZWQgbWUgdG8gcG9zdCBhY3R1YWxseS4NCj4gQlRXLCBp dCBzaG91bGQgYmUgb3BlbiB1bnRpbCB0ZXh0IGlzIGVudGVyZWQuDQo+IA0KPiBJIHdhcyBhIGJp ZyBmYW4gb2YgcGlnZ3liYWNraW5nIGJlZm9yZSAtIEFmdGVyIHdlIGltcGxlbWVudGVkIGN1cnJl bnQgSEINCj4gaSBmb3VuZCBpdCB0byBiZSB1bm5lY2Vzc2FyeSB0byBoYXZlIHBpZ2d5YmFja2lu Zy4NCj4gVGhpcyBpcyBiZWNhdXNlIF9ldmVyeSBtZXNzYWdlXyBiZXR3ZWVuIGEgQ0U8LT5GRSBp cyBhIGxpdmVsaW5lc3MNCj4gY2hlY2tlci4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/IEkgYW0gbm90 IGFza2luZyBmb3IgaXRzIHJlbW92YWwgaWYgcGVvcGxlDQo+IGhhdmUgaW1wbGVtZW50ZWQgYW5k IGZvdW5kIGl0IG5lY2Vzc2FyeSAod2UgdG9vIGluIHRoZSBwYXN0IGhhdmUNCj4gaW1wbGVtZW50 ZWQgdGhhdCB3YXkpLg0KPiANCj4gPiA8b3JpZ2luYWwgUC40Mj4NCj4gPiBGRSBQcm90b2NvbCBh dHRyaWJ1dGVzIChjYW4gYmUgcmVhZCBhbmQgc2V0KToNCj4gPiAuLi4NCj4gPiAgICAgICAqICBI ZWFydGJlYXQgSW50ZXJ2YWwuICBEZWZ1YWx0IFZhbHVlID0gMzAwIG1zZWMNCj4gPiA8L29yaWdp bmFsIFAuNDI+DQo+ID4gDQo+ID4gV2UgbWF5IGFkZCB0aGUgcGlnZ3ktYmFja2luZyBoZWFydGJl YXQgYnkgbW9kaWZ5aW5nIHRoaXMgYXR0cmlidXRlIGFzIHNvbWV0aGluZyBsaWtlOg0KPiA+IA0K PiANCj4gWy4uXQ0KPiANCj4gPiANCj4gPiBOb3RlIGluIGFib3ZlLCBDRSBuZWVkIHRvIHRlbGwg RkUgaG93IGl0IGdlbmVyYXRlcyBoZWFydGJlYXQgYWxzbywgc28gdGhhdCBGRSBjYW4gDQo+ID4g Y29ycmVjdGx5IHNlbnNlIHRoZSBDRSBsaXZlbmVzcy4NCj4gPiANCj4gDQo+IFJlZmVyIHRvIG15 IGNvbW1lbnRzIGFib3ZlLiBJIHRoaW5rIGl0IGlzIG5vdCBuZWNlc3NhcnkgZm9yIHRoZSBGRSB0 bw0KPiBzZW5kIGFueSBoZWFydGJlYXRzIGF0IGFsbC4gSXQgd2lsbCBhbHdheXMgYmUgcmVzcG9u ZGluZyB0byBxdWVyaWVzIGFuZA0KPiBjb25maWdzIGFuZCBmcm9tIHRoYXQgd2UgY2FuIHRlbGwg aXRzIGxpdmVsaW5lc3MgKGdpdmVuIHRoZQ0KPiBvcHRpbWl6YXRpb25zKS4gDQo+IE15IHJlY29t bWVuZGF0aW9uIGlzIHRoYXQgc2luY2UgdGhlIENFIGlzIHRoZSBtYXN0ZXIgaXQgc2hvdWxkIGJl IHRoZQ0KPiBvbmUgaXNzdWluZyB0aGUgQUNLIGZsYWcgd2hlbiBpdCBoYXNudCBoZWFyZCBmcm9t IHRoZSBGRSB3aGVuIHRoZQ0KPiBoZWFydGJlYXQgaW50ZXJ2YWwgZXhwaXJlcy4NCj4gDQo+IFRo b3VnaHRzPw0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA== From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 08 10:32:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNRl-0001P4-Qb for forces-archive@megatron.ietf.org; Thu, 08 Sep 2005 10:32:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23019 for ; Thu, 8 Sep 2005 10:32:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDNV9-0005SP-Am for forces-archive@IETF.ORG; Thu, 08 Sep 2005 10:35:44 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010E6203@cherry.ease.lsoft.com>; Thu, 8 Sep 2005 10:32:11 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85078332 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 8 Sep 2005 10:32:11 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Sep 2005 10:32:10 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j88DmHXK038807 for ; Thu, 8 Sep 2005 06:48:19 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <6.2.1.2.0.20050908100629.02dd9840@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126189923.6416.41.camel@localhost.localdomain> Date: Thu, 8 Sep 2005 10:32:03 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050908100629.02dd9840@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On Thu, 2005-08-09 at 10:08 -0400, Joel M. Halpern wrote: > There are two (at least) valid implementation models for heartbeats... > One can say that the heartbeat is a signal that the sender is live. Then > each side independently sends heartbeats. > One can also say that heartbeat is a connection liveness monitor, managed > by one side. The connection liveliness aspect i think is the responsibility of the TML. As an example a simple KEEPALIVE on the TCP TML may suffice in most cases. Note TCP KEEPALIVEs get acks back and are issued by one side. I think this distinction should be noted in the draft. > This usually requires the other side to respond. This has > the advantage or disadvantage that the behavior is driven by one side. I claimed in my other email it is an advantage for the CE to be the driver - not just because the relationship is one between a master (CE) and a slave (FE) but rather because it really simplifies things on the FE side. I think the fact that there is a one-to-many relation between the CE and FEs implies, depending on the TML and FEID mapping, that a further optimization to be used is sending a single multicast message on the wire (except in the case where responses are needed). Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 08 11:11:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDO3w-0002kh-7q for forces-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:11:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25663 for ; Thu, 8 Sep 2005 11:11:37 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDO7J-0006ga-3q for forces-archive@IETF.ORG; Thu, 08 Sep 2005 11:15:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010E628A@cherry.ease.lsoft.com>; Thu, 8 Sep 2005 11:06:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85080061 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 8 Sep 2005 11:04:01 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Sep 2005 11:03:59 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j88EJhXK039117; Thu, 8 Sep 2005 07:19:44 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126191810.6416.59.camel@localhost.localdomain> Date: Thu, 8 Sep 2005 11:03:30 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Section 9: Heartbeat Messages Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Weiming, Thanks for keep-aliving the discussion, and now for my ACK below .. ;-> On Thu, 2005-08-09 at 22:25 +0800, Weiming Wang wrote: > jamal, > > Let's first syncronize something. My understanding of > piggy-backing is not to let a heartbeat message piggy-backed > on other messages, instead, it is exactly the meaning that any > messages can act for heartbeat. Ok, my understanding was actually the opposite of yours from reading issue 11;-> i.e a heartbeat is sent and it includes some other content like stats. > With this in mind, I think we are > on the same page with the use of such piggy-backing (maybe need > some text to clarify it more in the text that I proposed). > We are in sync on this then. My only doubts at this point is whether we should call the optimization piggy-backing or traffic-sensitive heartbeating ;-> And whether we need to have the flags you mentioned earlier. > Now the only thing left is, you seem to prefer to use the > CE->FE heartbeat as some king of liveness strobe message, > i.e., CE > sends a heartbeat to FE only in the hope of getting a response so > as to sense the liveness of the FE. We may have two shortcuts > using such scheme, I suppose: > > 1. it's still not able to let FE to sense the liveness of CE (we > may go to the discussion on if FE need to sense liveness of CE, > but let's suppose it is needed). The FE has HA information on multiple CEs - so my take is that it may need to know the liveliness details so it can failover to one of the other CEs listed. > Let's try to give a scenario for > this: say CE is quite, and FE is frequently sending events. > Because CE can sense the FE, CE will also not send any CE->FE > strobe message then. In this case, CE can sense FE liveness, while > FE cann't sense CE. > I think i mispoke in my last email. The scheme works based on direction of sending. i.e. CE->FE is sent if CE hasnt sent in the last interval. FE->CE is requested via ACK if during that same period, the CE saw no message from the FE. Does this make sense? > 2. I'm not sure if it's more optimized to sense FE by CE actively > sending strobe message than by the FE actively sending heartbeat > message, because the former needs two messages, while the latter > only one. Unless i misunderstood you, the two are equivalent in the number of messages. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 08 11:45:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOaO-0003t3-14 for forces-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:45:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27219 for ; Thu, 8 Sep 2005 11:45:09 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDOdm-0007b9-1b for forces-archive@IETF.ORG; Thu, 08 Sep 2005 11:48:43 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010E62D0@cherry.ease.lsoft.com>; Thu, 8 Sep 2005 11:45:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85085390 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 8 Sep 2005 11:45:09 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Sep 2005 11:45:05 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Fri, 9 Sep 2005 00:18:26 +0800 (CST) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <00e401c5b48c$8c7535c0$1f12fea9@wwm1> Date: Thu, 8 Sep 2005 23:46:59 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: base64 PiBXZSBhcmUgaW4gc3luYyBvbiB0aGlzIHRoZW4uIE15IG9ubHkgZG91YnRzIGF0IHRoaXMgcG9p bnQgaXMgd2hldGhlcg0KPiB3ZSBzaG91bGQgY2FsbCB0aGUgb3B0aW1pemF0aW9uIHBpZ2d5LWJh Y2tpbmcgb3IgdHJhZmZpYy1zZW5zaXRpdmUNCj4gaGVhcnRiZWF0aW5nIDstPiBBbmQgd2hldGhl ciB3ZSBuZWVkIHRvIGhhdmUgdGhlIGZsYWdzIHlvdSBtZW50aW9uZWQNCj4gZWFybGllci4NCkxl dCdzIGRpZmZlciB0aGUgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHdlIGNhbGwgaXQgaGVhcnRiZWF0 IG9yIG5vdCB0aWxsIHdlIHNlZSB0aGUgc29sdXRpb24gOikNCkZvciB0aGUgZmxhZ3MsIG15IHRo b3VnaHQgaXMgd2UgbWF5IG5lZWQgdG8ga2VlcCB0aGUgZmxleGliaWxpdHkgYXMgbm8gc3VjaCBo ZWFydGJlYXQgb3Igd2l0aCBub3JtYWwgaGVhcnRiZWF0LCBidXQgd2UgY2FuIGFsc28gZGlmZmVy IHRoaXMgSSB0aGluay4NCg0KPiBJIHRoaW5rIGkgbWlzcG9rZSBpbiBteSBsYXN0IGVtYWlsLiBU aGUgc2NoZW1lIHdvcmtzIGJhc2VkIG9uIGRpcmVjdGlvbg0KPiBvZiBzZW5kaW5nLiBpLmUuDQo+ IENFLT5GRSBpcyBzZW50IGlmIENFIGhhc250IHNlbnQgaW4gdGhlIGxhc3QgaW50ZXJ2YWwuDQpP aywgd2Ugc3luY3Jvbml6ZSBtb3JlIHRoZW4uDQoNCj4gRkUtPkNFIGlzIHJlcXVlc3RlZCB2aWEg QUNLIGlmIGR1cmluZyB0aGF0IHNhbWUgcGVyaW9kLCB0aGUgQ0Ugc2F3IG5vDQo+IG1lc3NhZ2Ug ZnJvbSB0aGUgRkUuIA0KTm93LCBsZXQncyBzZWUgdGhlIGRpZmZlcmVuY2UgdGhlbi4gU2VlbXMg dGhpcyBpcyBhbHNvIHRoZSBvbmx5IGRpZmZlcm5lY2UgbGVmdC4NCg0KTXkgdGhvdWdodCBpcywg Zm9yIEZFLT5DRSwgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBDRS0+RkUgYW55dGhpbmcuIEZF IG9ubHkgc2VuZHMgaGVhcnRiZWF0KGxldCdzIHN0aWxsIGNhbGwgaXQgdGhpcyB3YXkpIHdoZW4g dGhlIGludGVydmFsIGVuZHMuDQoNCk1heSBJIHJld3JpdGUgeW91ciB0aG91Z2h0IGFzOiBpZiBm b3JtZXIgQ0UtPkZFIGhlYXJ0YmVhdCBpcyBzZXQgQUNLIGFuZCBpZiB0aGUgaW50ZXJ2YWwgZW5k cywgdGhlbiB0aGUgRkUgbmVlZHMgdG8gc2VuZCBiYWNrIGEgaGVhcnRiZWF0IHJlc3BvbnNlIHRv IENFLCBvciBlbHNlIGl0IHdpbGwgbm90IHNlbmQgYW55dGhpbmcgZXh0cmEuDQoNClRoaXMgc3Rp bGwgbGVhZHMgdG8gc29tZSBzaG9ydHMsIEknbSBhZnJhaWQ6DQoxLiB0aGlzIG1lYW5zIGZvciBz b21lIENFLT5GRSBoZWFydGJlYXQsIGV2ZW4gc2V0IHdpdGggQUNLLCBpdCBtYXkgbm90IGdldCBy ZXNwb25zZSAoYmVjYXVzZSBzb21lIEZFLT5DRSBtZXNzYWdlIG92ZXJyaWRlcyBpdCkNCjIuIFdo YXQgdGhlbiBpZiB0aGUgZm9ybWVyIENFLT5GRSBoZWFydGJlYXQgaGFzIG5vdCBzZXQgdGhlIEFD Sz8NCjMuIFdoYXQgaXMgdGhlIHJlYWwgdmFsdWUgdG8gdXNlIEFDSyBhbmQgdXNlIGhlYXJ0YmVh dCByZXNwb25zZSwgcmF0aGVyIHRoYW4gdG8gdXNlIGp1c3QgYSBGRS0+Q0UgaGVhcnRiZWF0IHRo ZW4/DQoNClRoYW5rcywNCldlaW1pbmcNCg== From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 08 12:07:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOve-0000qq-LU for forces-archive@megatron.ietf.org; Thu, 08 Sep 2005 12:07:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29874 for ; Thu, 8 Sep 2005 12:07:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDOz2-0008U2-W4 for forces-archive@IETF.ORG; Thu, 08 Sep 2005 12:10:42 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.010E638E@cherry.ease.lsoft.com>; Thu, 8 Sep 2005 12:07:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85086994 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 8 Sep 2005 12:07:07 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Sep 2005 12:07:06 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j88FMtXK039723; Thu, 8 Sep 2005 08:22:56 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126195602.6416.76.camel@localhost.localdomain> Date: Thu, 8 Sep 2005 12:06:42 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Section 9: Heartbeat Messages Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00e401c5b48c$8c7535c0$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On Thu, 2005-08-09 at 23:46 +0800, Weiming Wang wrote: > > We are in sync on this then. My only doubts at this point is whether > > we should call the optimization piggy-backing or traffic-sensitive > > heartbeating ;-> And whether we need to have the flags you mentioned > > earlier. > Let's differ the discussion on whether we call it heartbeat or not till > we see the solution :) NP. > Ok, we syncronize more then. > > > FE->CE is requested via ACK if during that same period, the CE saw no > > message from the FE. > Now, let's see the difference then. Seems this is also the only difference left. > > My thought is, for FE->CE, it has nothing to do with CE->FE anything. FE only > sends heartbeat(let's still call it this way) when the interval ends. > > May I rewrite your thought as: if former CE->FE heartbeat is set ACK and if > the interval ends, then the FE needs to send back a heartbeat response to CE, > or else it will not send anything extra. > > This still leads to some shorts, I'm afraid: > 1. this means for some CE->FE heartbeat, even set with ACK, it may not get > response (because some FE->CE message overrides it) This is fine if you assume any message from the FE is a response to the HB sent by CE. i.e it cancels need to wait for response. > 2. What then if the former CE->FE heartbeat has not set the ACK? > 3. What is the real value to use ACK and use heartbeat response, rather than > to use just a FE->CE heartbeat then? > Lets enumerate all scenarios (luckily theres only 4) in which something may be idle or busy during HB interval. When timer expires: case 00: CE idle, FE idle --> CE Send HB with no ACK case 01: CE idle, FE active ---> Send HB with ACK. -----> Wait for response, if _any_ msg from FE, we claim FE is alive Case 10: CE active, FE idle --> same as case 01. I think this is the case you probably said there was two messages instead of one. case 11: CE active, FE active --> Do nothing Ok, lets use the above scenarios for further discussion. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 08 12:10:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOz8-0001pe-Sw for forces-archive@megatron.ietf.org; Thu, 08 Sep 2005 12:10:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00326 for ; Thu, 8 Sep 2005 12:10:43 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDP2X-0000BN-BJ for forces-archive@IETF.ORG; Thu, 08 Sep 2005 12:14:18 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010E6550@cherry.ease.lsoft.com>; Thu, 8 Sep 2005 12:10:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85087189 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 8 Sep 2005 12:10:44 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Sep 2005 12:10:43 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j88FQlXK039773 for ; Thu, 8 Sep 2005 08:26:48 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126195835.6416.78.camel@localhost.localdomain> Date: Thu, 8 Sep 2005 12:10:35 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126195602.6416.76.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Thu, 2005-08-09 at 12:06 -0400, Jamal Hadi Salim wrote: > > Lets enumerate all scenarios (luckily theres only 4) in which something > may be idle or busy during HB interval. When timer expires: > > case 00: > CE idle, FE idle > --> CE Send HB with no ACK > > case 01: > CE idle, FE active > ---> Send HB with ACK. > -----> Wait for response, if _any_ msg from FE, we claim FE is alive > Sorry, 00 CE Send HB with ACK and 01 with no ACK. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 09 08:55:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDiPQ-000602-Kr for forces-archive@megatron.ietf.org; Fri, 09 Sep 2005 08:55:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29899 for ; Fri, 9 Sep 2005 08:55:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDiSq-0000uz-QN for forces-archive@IETF.ORG; Fri, 09 Sep 2005 08:58:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010E736B@cherry.ease.lsoft.com>; Fri, 9 Sep 2005 8:54:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85158525 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 9 Sep 2005 08:54:51 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 9 Sep 2005 08:54:49 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Fri, 9 Sep 2005 21:27:59 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Fri, 9 Sep 2005 20:54:09 +0800 References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> Date: Fri, 9 Sep 2005 20:53:56 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: base64 Tm93LCBJIGNhbiB1bmRlcnN0YW5kIHlvdXIgdGhvdWdodCB3ZWxsLiBJIHRoaW5rIHRoZSBvbmx5 IGRpZmZlcmVuY2UgbWF5IGxpZSBpbiB3aGVyZSB0aGUgdGltZXIgZm9yIGludGVydmFscyBpcyBw dXQuIFRoZSBzY2hlbWUgeW91IHByb3Bvc2VkIGFsc28gbmVlZHMgdHdvIHRpbWVycywgb25seSBi b3RoIHRpbWVycyBhbGwgcmVzaWRlIGluIENFLCBvbmUgaXMgZm9yIENFIHRvIG1lYXN1cmUgdGhl IGludGVydmFsLCBvbmUgaXMgdG8gbWVhc3JlIHRoZSBGRSBpbnRlcnZhbC4gVHdvIGNhc2VzIHdp bGwgdHJpZ2dlciB0aGUgQ0UgdG8gc2VuZCBIQiwgd2hlbiBDRSBpdHNlbGYgYXJyaXZlcyBtZXNz YWdlIHNlbmRpbmcgaW50ZXJ2YWwsIGFuZCB3aGVuIENFIGRvZXMgbm90IHJlY2VpdmUgRkUgbWVz c2FnZSB3aXRoaW4gYW4gaW50ZXJ2YWwuIA0KDQpJJ20ganVzdCBhIGxpdHRsZSB3b3JyeSB0aGF0 IGZvciB0aGUgbGF0dGVyIHRpbWVyLCBDRSBtYXkgYnVyZGVuIHF1aXRlIHNvbWUsIGFzIHdlIGtu b3csIHdlIG1heSBoYXZlIGh1bmRyZWRzIG9mIEZFcywgd2hpY2ggbWF5IG1ha2UgQ0UgcXVpdGUg aGFyZCB0byBtYW5hZ2UuDQoNClRoYW5rcywNCldlaW1pbmcNCg0KPiANCj4gTGV0cyBlbnVtZXJh dGUgYWxsIHNjZW5hcmlvcyAobHVja2lseSB0aGVyZXMgb25seSA0KSBpbiB3aGljaCBzb21ldGhp bmcNCj4gbWF5IGJlIGlkbGUgb3IgYnVzeSBkdXJpbmcgSEIgaW50ZXJ2YWwuIFdoZW4gdGltZXIg ZXhwaXJlczoNCj4gDQo+IGNhc2UgMDA6IA0KPiBDRSBpZGxlLCBGRSBpZGxlIA0KPiAtLT4gQ0Ug U2VuZCBIQiB3aXRoIG5vIEFDSw0KPiANCj4gY2FzZSAwMTogDQo+IENFIGlkbGUsIEZFIGFjdGl2 ZQ0KPiAtLS0+IFNlbmQgSEIgd2l0aCBBQ0suIA0KPiAtLS0tLT4gV2FpdCBmb3IgcmVzcG9uc2Us IGlmIF9hbnlfIG1zZyBmcm9tIEZFLCB3ZSBjbGFpbSBGRSBpcyBhbGl2ZQ0KPiANCj4gQ2FzZSAx MDoNCj4gQ0UgYWN0aXZlLCBGRSBpZGxlDQo+IC0tPiBzYW1lIGFzIGNhc2UgMDEuIEkgdGhpbmsg dGhpcyBpcyB0aGUgY2FzZSB5b3UgcHJvYmFibHkgc2FpZCB0aGVyZQ0KPiB3YXMgdHdvIG1lc3Nh Z2VzIGluc3RlYWQgb2Ygb25lLg0KPiANCj4gY2FzZSAxMToNCj4gQ0UgYWN0aXZlLCBGRSBhY3Rp dmUNCj4gLS0+IERvIG5vdGhpbmcNCj4gDQo+IE9rLCBsZXRzIHVzZSB0aGUgYWJvdmUgc2NlbmFy aW9zIGZvciBmdXJ0aGVyIGRpc2N1c3Npb24uDQo+IA0KPiBjaGVlcnMsDQo+IGphbWFs From hammond@uhaultrailer.com Mon Sep 12 07:29:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmVb-0002fs-QA for forces-archive@megatron.ietf.org; Mon, 12 Sep 2005 07:29:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11760 for ; Mon, 12 Sep 2005 07:29:30 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEmZI-0000Lw-VK for forces-archive@ietf.org; Mon, 12 Sep 2005 07:33:51 -0400 Received: from cpc4-lutn3-4-0-cust96.lutn.cable.ntl.com ([82.16.119.96] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EEmV1-0006fQ-B4 for forces-archive@ietf.org; Mon, 12 Sep 2005 07:29:24 -0400 Date: Mon, 12 Sep 2005 12:29:49 +0100 From: "Gershwin" To: Subject: Best love dr@gs at best store! Message-ID: <000601c5b6c2$7f62f6f0$116e81d4@mata> MIME-Version: 1.0 Content-Type: multipart/related; boundary="=_2dc2df50263a605d703d026d508c3281" X-Spam-Score: 2.9 (++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 --=_2dc2df50263a605d703d026d508c3281 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
--=_2dc2df50263a605d703d026d508c3281 Content-Type: image/gif Content-Disposition: inline; filename="5eac09a123d29ed370a8b851151a84d1.gif" Content-ID: <0eb61e7c23fd12f18cf5b1a1e0b7e1c6> Content-Transfer-Encoding: base64 R0lGODdhWAKWAIAAAP///wAAMywAAAAAWAKWAAAC/oSPqcvtD6OctNqLs968+w+G4kiW5omm6sq2 7gvH8kzX9o3n+s73/g8MCofEovGI3AWWgGUA9owwJdFgFeJMXLFbSlcxTbayDud3cialVd1wxZ0h H9ZgOqtqr+V5+7Knj7UAqLSC9xA1iNBWODKYOMfxKIjzdGU2h5jZBFdXmWnpuZUnZ2C2NoXqqXhZ Kme6KspqigfH2lpZxkRG+grJqaWbGpbaunmqijlsa0y7Cdt0awx2CHnbXAtMKhj8Cer9u1rsrMz7 O2qLbH3YK43pnAxtLRkZX19vKE6dXwrM0GepSN89RPyqASw4qRpCewEVxmvmZyHDL6gEElSI7x2X /oIHGdqDeFFjxoYN8HWs6FBixIckJf7DGDINxUAwObb0hzMcS3EdXfTMOHLlRC0l0WSzAxSmG3Yy jxJNKC+kR6K4bs5U+XQnwqRUDJJsw9Qr1EUWF3It2rUqM1FZad7DiLZtSV4G2cWVa/KrtjEtz+7p OTSnlLtj4U77mPJmX8FTAU9T67IwtZF+jdo0rHgrVn5kyyLWLHSy1sCJ41ZmXHplXi+oV2OdR8+h yaCm2WbeDPUz2mFiL4tM+fO244GibWOm/Vh23dSST/bOKhWgpJhfmYMuWhUicOsPT5O+vRi0o9a9 UeI+Ua6WKrv+dCUTtnTZtl3y24/jtvYZOVjw/mmh++9KMKK95w08ex32Xj/cgMNfg88QGA19nIDF hXr7HfjggBF2U+BG+AX4jX8M5rchh7kAKEw7WSwImxEtigFjCS8ORsOMMd6IYxH15chjISP+8SN6 QfZIZJFGHolkkkouyWSTTj4JZZRSTklllVZeiWWWWm7JZZdefglmmGKOSWaZZp6JZppqgjAkFGu+ CWecP1xFiJx23omnBf9pxAyEvnzjDobjbBUgn+fliWiicZ50kXN1+Each7gwGpmill4qZ1iQIjcb Ol2xNAtmh2JKaqlbOjoap8+B9xRBZyBnaqyycqmda29dJxWrDbkqmI2z/gpsjiuGoqI2IBYr/uGI w3YnYTujBgtttNJOS2211l6Lbbbabsttt95+C2644o5Lbrnmnotuuuquy2677r4Lb7zyzktvvfbe i2+++u7Lb7/+/gtwwAIPTHDBBh+McMIKL8xwww4/DHHEEk9MccUWX4xxxhpvzHHHHn+MsKBjLmPO RlL4+kKbQqJ8Jct6KjshycnihyyzyVLh8qfd6VmhylZsh8FLbDRSI5M5xybCX4Sdxlukt44WmhoI whq1ZG/ocEo2Whuy458O3ifiOukh5R5ngCboZ58n0uesLNmJTfZ6xKqDNontfUI32PB8zRTNd4v4 Y1OpQfb2VNAYN4pTNas9lyv5zC2PXL3W/k0iezJkjaDTuW6zqTvhEabbWCCZRfpnw0mOzXJl54a5 SMalyp1yuoET3GvW1e5W5q8upZXMiNNY+kGnJzap57Drmrfw1eXQ+udau8UhbaFGPbzhtkZX9/TU 637ZMSKjSiDgsT+nKevlL89Y9eCdTjhnhf2eu6OA07GIWoxOCHz0lB+tQfOyJwe9zXQGeP/LzfKU V5rNCYR4u4JUW5onPdaNzzfgeyBqfLFA9YkqdIrh1dSsJhT5TVAlmiid5PI3KqpdDmgWNAxSVsVA yxwvfS5sIPme1UHu7URwhoJOBKd2lrnohTnsUw79nKcavByHUI9bouF0aBYNHpBzneOZ/gNNqEKf xAdE5AAJg4ZlIruJ8W5fa5x/kHU2MVqOP/1x0LK810P9RC5ty4qGyQwUii12sUPIY5z25sNFPoaK bYfbYzdOxsV+sLFCLoSc5eKmxzDuDWQ94B8QLHknkVFyZJo8Uic3CcpQinKUpCylKU+JylSqcpWs JBImWwlLT3aCDT4DEuiuNoNaJkGXk7TjB+LmLCtYMmdk68AnxaDApPVvA6/M5Zx+GTQD4lKaIBRC M0eItD5iMwYCKsaxMuM7XWovnJI0I9f4eJ9AobObG1qbOuV4onS6ThltK9Qey+i7JyavF+NMj80G aJrsOVKTYNznPh5Dz3cUtHGLzEU9/mOBjHSskY2aSOSg9GnMmLzqUbKTogEReJ0Meu51Ch0pXhpl PAnyhIm1qWFNPmeeAWLPaSq1XXhqdctOmIemHPzg7G7nnSxW6mQ0fBx1ZJhS063HBEE84UBQFAed hm2EJGMhrqx6K/WVb6ZFfdr56LjBteivpxQF51F2uj4UipV4E3XpVe8SVAJiNK3/a+oCSWjDZP4h rEAT6nRaCJ0LNBV+TxsqV2t6vRC6tbBYDCudkOjUxpxwo8u8Il5ZQxm+1tWIOsPhE3Fn1+21EKUy 0uxEeAfFOH7UpE7salAI+9rA8tSHblWW8UqIU9q+FWo2VS1uHivZ1rLGsh4ZT2Y5/nKMRgZEaei7 YF3jetfi5tWzgg1kQ4HjNmMh8lgsep458SjJcDZ0oSsSm96aBTPCRVRAdnmj38YmvnZ+d630tZt8 9gLMmc1xv6G5bzoUpB4+ncOfawuRgUrUS0C2EW1vZKox43DNO1Azmiv8V4Sda4MLZ5iX0OyRsTic tzEcM14jThqI1VDiWKp4xSxusYtfDOMYy3jGNK6xjW/8Bg1rGMc8nnBpewzkeN7Mm11cbhqJsd/6 7DjIoUzsQSk1QycDZslM3mTxkixVrqBqqvWlbpVnfOUKWu+GIYXhl888icL9xqlO3pnp0AxnPxSo u34i74fBFsnIxnnPfO6zn/8M/uhAC3rQhC60oQ+N6EQretGMbrSjHw3pSEt60pSutKUvjelMa3rT nO60pz8N6lCLetSkLrWpT43qVKt61azO0yz+u8vq4m167c2udenbtesuVMF0zHX/itnrW+8Nvfzs ZN8g9zz9Rkgnei4YaYlpTfQNVrYstNXkyuxTr26zs0trLdOkbWZqq3DKQzRrxNiix56Vc08Wjed1 EUsakkJmO4S9tvs8o+1DsXvOgdiyE9FdnXqDcN6pJeu9tUmwWFTRtVBM3bNwlxN0MhaiH3U4/bQL SXwStNwa7Te432qb6FgcblShCUDvK91zy/aPgMyhY9tqFWOTDqInDy4Gm1vN4MTtNotbNSF2NJ7u SmFP4Nl++GUlCNCGwe+vR2fsXDPX7MPCkKRWqWbRnw5dffrb4BmyuQ0DI3VsU9voKTcfldu1dKRq GedPB+xcR15mqlc73DjXeb6dXu6sJjXbwN05s0EeQG2W7LamdRh3F/w3igsUvnArpxDD58sw4tfW 8FG3dxMf7CC5d251nI80Pqz4pyoyKiHGfNcfX+eHBvPsrW69618P+9jLfva0r73tb4/73Ot+97zv ve9/D/zgC3/4xC++8Y+P/OQrf/nMb77znw/96Et/+tSvvvWvj/3s+6sAADs= --=_2dc2df50263a605d703d026d508c3281 Content-Type: image/gif Content-Disposition: inline; filename="63862dcc5740a0fc644ab84f2084ed34.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODdhWAIoAKUAAP////8AAAAAAF9fX9/f35+fnx8fHz8/P7+/v39/f/9fX//f33NTU/+fn18A AP8fH58AAL8AAP+/v98AAOsLC28vL38AAP9/fx8AAPc3N3MTE/8/P1c3N1cXF8+Pj+PDw/NTUz8A APcXF4cnJ+MDA+enp8NjY8enp+cnJ+8PD6sLC88PD8MjI78/P89PT+uLi7d3d6uLi48PD58fH5s7 OwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAWAIoAAAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH5PVgT+CnxZfwFMFw8BDxuC boRNjksLgVqQXpWMQ5eYm5xRC4R/DJ1ShAJKF6AqB6NnpUyuSQ2IA5R/ppa2o7CsvL1DDaABDgS+ r7lJiMICGLTFYbtJ0EbSVdSDx5zWztt6yRB/EQXcSNpCpeLE414C7MYBt+TYV+VW9Hn26vltEn8T AhR/Kkz7A6DBhj8bJAj5lOhIsgXxCh1KpBDAxIRGJCF6oABiEY2JGgCgR83gxg0iixCSgGgSEYYP HP7xWHDDyZRENF1a2VKJ/gSbAVCOJJiJqLk/LANM0hbMqBCTiYS6EyArUceMCjZeXVLKoFWav4B+ zUlwIkewQyVq9QhTZgCI+PTJReMngAUDqAJAQKDyz7dgHoSA+KOhCDC9AtL1DRABcF1CgYfwa1qC yGRQKJg2HbLgYFMUiyeAa0ZkcIDCRA5DSNy5aQDQZN/FhkdINGPSRS4TyoxtV+3RaeEtBnWr9Wd3 jYNVlux6ebQ/Fpp+IOKZclHG1q8nB7XcNOpffhMj8je3PBxCGBIwnIA7resIfCeHo/4nRPvrTW2D gr8wWbAJfAGwgH+uCRcbcUJU19QKB0K3Sm7giDOEZ/YBoGAwDF4nnG/B/ljw4EcENkVbbx2uolkw t1wISobPuRbABCf05xqASrjoVzqHRYDBMn/x515+Af74X3wR0hdAhQdFYIB5TK6RY2IAZEDYcA4s k9wED4rwBwec9SNAkKGFIEB0f5AgJplYCpGXjlZOaREhVQrgAIJICFBKO4fptSMGfwUwwnUT7ChA AkdoGQCXC3mJQJ4Q7Nnnn0fJpiGgghJqRF7KYDAnh5KmFSg7hJZjpy14EtIoj4RAGpEychIiAzFr 7pncd0fUViWf/TSTTAgHEPNBPw+CEuemp+E3LCGoGYqogIpayNiHTUZLhmcOPJijhJFWKc6vfyz5 pl7p1HVXiyEYgABD/sKYi663nmHQKwDczketABKaQBI2nlkgwADEEMBCkWk5YIBil94ohLhL5rtv v/8yJiE0nApMcBHzouMCpyOmq9i9nSrMLwD+AlzrH9oKYS9jhLb7brzYDpTutoR4C4AB7AS4brb0 muzXwyTnDMDJEIiTFwThQuetHxBAK+3SXqDrc1rLpoUBtrCg2wx6lo4cAAYBosezpCGCkmYyU3cp j8vwkJ01sy8G+0fZSVgdaXoAqP0SsJFuSOLWLRtBNrZOTzp3yxyn/fba6ykdG9xsj21jmhExLo0E DWRFp9dmszd45rTILbWlSN/H9OhYYOqiBRvbknqnUgpTEDhQRhR7/inpwGJjt8ERXLiGE8ec98RG tO7A64xBSfti3kK8d+yy674877PVuHzvuDcf25K3ByAz2qvDU1WBv18f/nXeCk98BLGjYoHopLc/ Rdj/Za18p9dSq3j0eQueDDv89y/13WdbjOG29hEv5W8J9SPZg8hWwBfdYheBOyAy3gbATmFMgNLr FAMBSJ7IcdAU++uf/2SHvzxNAAIWCIHtKJi5B7IwUQ58SoTsBx4HrM19OIyCbmzUAcFJMC0j8FLf MChBWFArCdRSTJ4MRERn2YVgdVHSD1sURAdKKF9QBEfyXrhEHyIhiUPAVMbG2EStwQOLRIji9haD OvAwJmEki8L8/m6RjCoZYAAJWOET3SjFtLRRhm+8ThX9gS1gOGCIOUzkEsQlQnaQaS8/hMZjjMaV 5x0wLxMwgYDysohvBUCTxAsg/kLZAohIghC8miISJmkXmeWplAJ6TCrrBo7pfM+CoiQCpjS5ANOR cYocw4BHXmlKWd4vUgGAZZ489K1MbhIhGdSbpM4hhMu48A/KJAQz3ZNNBw2BleMiQgGepshyxg1r GSGEKIIzSgDskG7R9GHVbFQtAaXgdkxsJ29cs5qu5RJCoICnEPbZlH4mCJ9ePAK6XPRLdrbTb4QA QToIGgyDrio/dFtoMOpJQsF5BgIQuSUGkIlRS90uUFl759o0/mHOlqYGdsCLEsmIMcciGKp4MR3l BYVQAn76rKfB2E4+vbiAFfiUNHEBwE3RR7CiHpU5Fd2pEl7QFKHK82z0qI7mBGTUgu4rg9tB5cB4 6lNERvIYOyxTfWjql6aUq3ZtDcZbibBU5jnUpXg9qDCOea27+tWTHI1nEeVxAgjYJgJVwk1hRTMB fe2OCAQYQQQYGwEx4SapmArsECI72RdV9qtE8EByEDsqXHZKCTAYbZWkKg16OFUvMuMsZS1byXfM gLGnAtNiwZFYwUpQtLgNAQbAwZdS0AC3OwqScZH7pSJkVmlJzSvpDsAOswJgnAJ4EP+KsF1dUpMJ 3RVCeAEw/l6QDYBm2R0iAc4rAAMQqrxGgO91D0AzAxwATOJtRxPEaNYC0Le99z0CAqibXvLqN79D NcKA2XGAGBhwCOOFr3whS+D2+Le+AQZvOxJQ348VYb3oPYB1IXxgBBNhwB1GAAEYzM4CdNh5snFx ez3sXVsMccLSzXEWLrMaHUMVMXMgBE5+okUfT8Ee+OBxgo3MZCy4lX3mfPIcVCSsYza5oy1aspSv zOVamKq5Oq4omOOQ1i+PuMsJRVsGw4NfNLsZCskgLZTNGefe0uEEFuisZ+385izXdsl1Bm2fB/2E EJ/ZnIa+AwES8F8AH7rPOCbxkmfG4EcT+tKYzrSmN83pSU57+tOgDrWoR03qUpv61KhOtapXzepW u/rVsI61rGdN61rb+ta4zrWud83rXvv618AOtrCHTexiG/vYyE62spfN7GY7+9lzCAIAOw== --=_2dc2df50263a605d703d026d508c3281-- --=_4c1bfaddc375e300982cd7419c39d9a2-- From hammond@uhaultrailer.com Mon Sep 12 07:29:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmVb-0002ft-Rj for forces-archive@megatron.ietf.org; Mon, 12 Sep 2005 07:29:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11762 for ; Mon, 12 Sep 2005 07:29:31 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEmZI-0000M0-VF for forces-archive@ietf.org; Mon, 12 Sep 2005 07:33:51 -0400 Received: from cpc4-lutn3-4-0-cust96.lutn.cable.ntl.com ([82.16.119.96] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EEmV3-0006hC-HU for forces-archive@ietf.org; Mon, 12 Sep 2005 07:29:25 -0400 Date: Mon, 12 Sep 2005 12:29:53 +0100 From: "Goldwyn" To: Subject: No more penis enlarge ripoffs! Message-ID: <000601c5b6c3$a08d7430$116e81d4@tet> MIME-Version: 1.0 Content-Type: multipart/related; boundary="=_f2fc6013b97d7c13822fc6c0b41f0169" X-Spam-Score: 3.5 (+++) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 --=_f2fc6013b97d7c13822fc6c0b41f0169 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
--=_f2fc6013b97d7c13822fc6c0b41f0169 Content-Type: image/gif Content-Disposition: inline; filename="3ae22e4121b3ccc68d2f7b8235ccff18.gif" Content-ID: <0b41a9d9761da17ebcaaaa0d336f473f> Content-Transfer-Encoding: base64 R0lGODdhWAIoAMYAAP////8AAAAAAB8fHz8/P5+fn19fX7+/v9/f339/f/8fH/8/P/+fn9s7O4dH Rx8AAF8AAN8AAL8AALd3d/+/v//f358AAD8AAP9/f49vb3NTU4cnJ+8vL48PD/NTU+sLC+uLi/MT E+9vb/9fX99fX59fX8enp/cXF98fH/sbGzsbG68vL1cXF8MjI+cnJ88PD38AAJs7O58fH9cXF7cX F+PDw8cHB+cHB+dHR28vL/c3N3MTE1c3N8+Pj6sLC+enp+MDA8NjY89PT6uLiwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAWAIoAAAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u6ABvr++CgsMhcDGwIO/GIa/hM2FDAsKwSMUkBQj08HDh8fby4jR2gojxITa 1oQVvxWFFMEA3sfJvt31ivLC5oUjvyPF8pC5y7ZtH70A9hBqwjBNWKcK/1oxDOAw1jNeqiDqCuir gTOOvgQIApYBYACRI0MS6ueNhCOW3kIYjMcRhaEK2o65aCeIJYwDhBj8goCAEAZfMAaAVEnzJDOm iEB6VGdMw0eQKAFUWCAvRLqUTk1mtXT0lw8CmxhMM8CqrK+z/hahYjSlNgBbXEsdHOSIEpiFogez /srq1lsJRlxBTrgaUIa6nN5u1BD0LkCEBIQSB5BQ4JyvCwmWhh38NGxUkHoHCQVGdG9AlDhB9ghc emwlbRAEPLibifQq3Lp5u/I91xRxW4MFKH8AIYIvCUCbKp9OXTlYX1Zpg82qzcID5Recb46OCKaE C98FXLDwC3pg6g8k+Lo8SLOFC+DZ+7IB+JcKxgGgJcg6IQFFXXLUbVcbPiFNx5x47gnS3XOdDXJg gwkCoBkM6T0AQ3vRHacgJoN1BlhvcqFSIgAnDpdicaKISMtxCEwwn4AylvbcicT1GJIBgJnwi4CH EBhAbgQc/gDYATFEwCGRItbwywCUDSWAAdEd4MAvOQiSWGsArCbeBar5YoFt0iWEZo7aCVLjjVVa JsAHvnSppiGVBYBfAoAhUIKTD+D4IpuRiCgONTwNOBFF3Fx3kSMVLKqPIYdSNEKiaapDEDmYJgJR Q5eaFGZiC3w1oiCVcnoVBdNEBAAF0gTAzaNabRrqVQBMpEA6E5V6k62dNhONL746eg9yg/pCZaYM WubLBm0Sp40EpiIwXSJlnVlhIQUMwGebA/rGkraG4GAmUKtx1pMvEJy77pHCnXrVmi/OW9qyPg2Q LXn28oOUAPwKcoC3/SVrGiXe1CfPDwNC9osLxh68SGw6/mW2cFMCveoNw4rkCQzHYOkHzGxtamYM yL9AyJbHvrhAHMu+gNyUfCPD5AvJcZ58lci/kOwNmnFJXFkEfdVr0gXzVeijaYWdMAIGnSKS2AXx NjvWVs+hpA3VhwzNlpECTkN0CJbd9csD24KrNrN3EjJ00QE8kACBEVTNtoSfYcaIjIQ68nOYz333 gH7ufSk4zdD+7YjhuiGOauC6EX7A3xQbE0HAj3lzuWvGRJhpuoJLbiwMBFSuuOkpkxeQeMBEiPp8 qgfknuK1EFdBXQFYsOxS83LgSwenHoeCNynMVBvmiSx1gaBxI2/ksil8pnHuA7DEwvQSCNCivJzT 3rZW/rjrDvhm2gOggy87fB8Y8jq+hokACAKwNQFFSWkZWr9cUED9SQMAP4aPyN/+AGC/CHRmfvy7 n//iVxYJHA592IJcfCB4ndxMUIEjQiAB4dSUCKQnAW6xYLt808AHBiB9YIkAfj7kCyCskIMlbBwF MWZBmkVAQP87iXWQxRGuYUweggmJkUqyNNtsgHXAmMppJJaw7gEDBgDbzva0s6+yQMAAq/lJWUin PicaA2hezB9bviSgdKWNe3dL3lLAWCi5DEA50Xme/H7BAQa0w1oC2J3REpGTOt5ROct6YxS1MqVT JSZQCVTXIQ5Jvw1uRmnsEkBn7BeAZTFLkHEsZFMg/jAAwHxJkiwSgm8YmUhI6mkABzASJ1OpSVI6 UpFWmqQm0zgLkOQmRFihjQfMhIAiGqIAKoCABZC4AjXGzSTACKI3OCQAvTXlAYgwEkq8pg20EUgC CdiaM/uFTPcZUx63lOa2fsGDBZkEmo0QDRub2MVXMYAgpLGZL3Qwk74dQp4BoGfX3gkZuHFndUQq hMOAcUOwoC1aKaIAP5Np0G1Vc1vSxJs8CvpMXMbNlFoDaEMRKrEZHSMCEfAOKLdTnQylqQJ0CsCW oMImBBTAACyw4TYtpqcW0S45F7BhBlq0tSlOj2gHYcF8yne+AORgqMjLEYIu1FEAzSek3+lMYZa5 /j0Z9TSdGGLqOo8BxuPgjquCaEFMvmLPQ4j1GF5RzUCZsjR5WLKbx9DjSXjEUqh89YtSDIxN2coR uZZPOgUbTV/zGrw9wmKpeRwAkLhpTJSA4Dm+nGMAoiYkZSGigQGbTmQP8IL9tGhcyBuXJVkinqQI ooFmeitj19Y3xA5AsYBZK0FnKiOfsE8s5kwIQ7+3GstYAAZIg4oGYECzX9jAomxUxHCLux90pey3 wRWsabRR0msdgrrV9Sc3fdPbkALXN8epJlWYgt3qFtY0vilvSeUV2VuU9b1QIdtuM5WYv7iDTUZy zPdsd4Nnue0XMaCUGMsEDNDkjF12oyXfDEso/ph543qrnV4ADgMNBUCNtYY17/eAo9jQyAUBCeAB BIrLvOQqAsQiJrFkc9Nh8ELlS5CAcWO3S95ItpivB/vSidyCEhkvUZlA9hK7rEbjpsoCvkbmJsuC PL4AtCAdt5sWG3fpCxRQoB0VoMCi0CuXx1ombb7rSDqw0Z5BEjKZsVtRO9PY2j36pLostAC/chTm AJAAy1r+BQoCS68kQ6KIFcqTSLTBE5cO1aBRUwSh3VSAQ6tZ0KcqSwSCoJWyLCCClqF0pIgFrsg+ 2sUHc4umC4MSSY+a0+dlsqkrjWq2Le0BiQ6aiX8oD3DVmcumcVkPA2qIGSwle2rTNfAGUYH+/q4u UIUoKvlouuwft7PNRjaS3G7yi+ygUSvGDgiy2WzYAL7YTO34KjTTNZlNU0+iAfBAUWgl4M2UO1tU qm+4c4JO2wUEArwm9r1LXOQegztM9JaXkYAYLnDyO9UF9wa+2QuVnKjbvd2mteKOM3Ama6Wz4DQz ImiwOiSpLU8lGUQNbCAPB3ayEG7hIoEDoPI1L9jPbErXX5PNLroaeeQTxQ+fc2uJl3kDCJ8pSgO8 kb27aKZutCTE0I9RdAkDA+g1ZdsPvEEuREz9GFU/TmQdDPULrDtFXm4dca5ujKzXFddZIbtfRqr1 b88nwa9AMl+4J4L2smgDw5yPBJh5RkQs/lc8IcXPANImI3NtpkUIwDvgLYCkKebJwPr2xbSdzfNr r03IR8r34x55eTdtQAKLZ3Ga+zxrrB6sB6D3LXqeE50YpH4zUCRSBTAuvrK6HkKxHwTqnRP4B7D+ bibI+2ZyA3dBBB9CxO/02bOye9X7fjxpnADNJJCb4xz/OclHuLyuP/wrKd80s08tLqy7iOxWx0I7 JEQCyO+/9A/ipYIcAAG+5QgQEyD+WDoE+wdhAOXkG/6AZAB9NwgHMB0Bg0czp3/uRwj7JwgNWAgP KAgEoBwDKAgF4H8MuIC/dH8B2HcPGIGSsH8HwIGKpSQYaIEcKADzVwgIMIHeRxOlVwAp/riChDCC b1SCeIRDGogABiBIBFCBLNiD/ndG+8d+7GeDeYQlOeiAGggAI+h/Q3BohMCDPkiE7meEC0iFQwiB C8h+LagcxQcjYjiGZFiGs7AOwGaGteQL+wArz6FaahiHcjiHdFiHltAPy2OHrWAyx7BweviHgBiI gjiGCxADGjeIo+BgZjJSiNiIjviIkEgKPxiJo2ACxAV41PeClLiJnNiJnviJp2B/8TeJoFiKpniK qJiKqriKrNiKrviKsBiLsjiLtFiLtniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiM zviM0BiN0jiN1FiN1niN2JiN2riNEtzYjd74jeAYjuI4juRYjrMYCAA7 --=_f2fc6013b97d7c13822fc6c0b41f0169 Content-Type: image/gif Content-Disposition: inline; filename="e641191b19b076eef6b6e9e1cb139a9d.gif" Content-ID: <8e0fb0c1ddb12b1f4cc92fbab06bbb2e> Content-Transfer-Encoding: base64 R0lGODdhWAIsAYAAAP///wAAMywAAAAAWAIsAQAC/oSPqcvtD6OctNqLs968+w+G4kiW5omm6sq2 7gvH8kzX9o3n+s73/g8MCofEovGI7AWWwoCCmYBGgVJT9XR9ZC1biVP7xXSTiHDqan6lyY7wevh+ N1VyUp1xn+Qpcf1i/wHY9iMYUcjGkbYEtWiw6ObU2CaJF+l4QFn2F4VGyTQG8Hnp6Bm5Z1omqcqY uZn5mCr1eRpqBjuFiZpb1XjXy2p7ewla+1obmzeLvMtbekza+tf8DH08C9lsWb1MSv0YHM0ZTI2o GKp5jplriF5p3Q6v/gQPOeouarue3sBon56/L+ATN/6+AHyWzGBBXPoUyqs3yJ/AOA75SRt10N2/ /nZrDvaTCEGRQ4jkAlZEQ6+hvJQhOYFEYm4jNE96hG2S+bLPvJX7CFrc+M2nwJ09hZ38FhEj0mI0 X3KcifIp049O1WnjObSnlpv/lv7EqVVc07B+pHoceCujSa9CKRLDKpRNzJN4vMTDVTGrToYmV/rC mJVsXcB+7RUCuJdhsodJDee8O+WqxL2LieZtSdgxX6mBv2o+u3khS8tYiTYWLJcnr8GYS+IVHVrv 6Lg7FcqhTbpoKsgawZbW/PXyZp+UF0ueWLgqcOJ8GCf3/Rw318/6hhbnezs67NPSk7TqtCqcONfV RE1lhk2W0VKmbiszmPYaP/nFvIkUby2b+vD1/iu1h4oeM8hgQ54m4GSzS3/zERgeMTbZpOB59bEX Unz/TQhggOXBxx4wCnZ4ioURIkJiiSbacWIgJh6SYosuvgijNCzGuA1M+NGIY4467shjjz7+CGSQ Qg5JZJFGHolkkkouyWSTTj4JZZRSTklllVZeiWWWWm5ZgVcqZgBhCG9l2MGYNZh5xIwajAGKmii4 SSOcRHSnxm9iTLeVcp2ZRgiXdurpJwhyktiWM299FyZk9DGV4C/GHOoXiLFohSYYOK1XoIEHbtNg hep1kx83+REoqjKNCniqRa+Ah5CpmN4o4YhswXrRUZ926Ck4Xa16Xz2V4sBcpID29WdgUS33/htV rOWFG0nKromKZBAllBlYzDYWLKjXgmqaRyOp5Fym3mAHLkIcAaLWXKpxES2xJalFrm5VZTRtmiC2 xY6oyz7rriXS0TnTgKVlp1xQEdnGVrFkJVxUouiNYxbD0xlMHVqq8Ladu9ZCBbBYfBbkpV1AcfYw GBfjOdrCaX4M3GkY99utVai1jDJovHVclm3L5rlxZofNp5hTdcBbcWxEr5vytgR3GVpMYAJms8Is LR2zdkZ0tHNrGnPV7FNX4asn1txmq3KZUGcdnGEQDys0bMLNe3O40Mnbm9Py1osya8iZBXSeOj8n tbAwTzabaoOekcVSjk7SILr76RfZeBsO/p24qRGudyG07Uq4uH/9/VIdmf6xMjavwOiXHoefm86g e5dj3nDDpyfEuoax7rnhrqkLzHirrNoO+1iBDt/i4SvmDazxKf5KfPOEMH/ig7TSoPzyzl+Pffba b899995/D3744o9Pfvnmn49++uqvz3777r8PI/RX14RuE9VPWoL8Ytwv6Iy/8g8/QR1vAwC0gd3u JCbk5U8JPHtZDgpIpVfpinakaxU5JEjB9NhOVhbiD3/WgSA2ZU56q+AWyGq3IFx140Ze0kXA3iE7 DSrGQ4zaoIx8NUHGrQZyCQJhm1xYw1GRyXJBXFTIkuQtn/3FaubqV/3kRid63YU2IlGi/qWmxpkD ig1QdiNJA8GFmHYhJh5SJNbR3PYtE+btI+lyiSHSqDaWsfFc8WqSxLaVwiw+RGIle+EQPRNEkFAx aFv7GMUCOUhFTa+LgXuMUtJCGMx95zUcQ5UOwXZGR+ruWGxbmFHWuMdPWuxJNsNja8A2N9wNJmqx ydgw+ES2yjiwbHD5Ip5Y6bKw6EQ4b6vlzFiGNF06kDIFayXX3AbKag3TSc4KV5silhyqYSuONCvj Y7ZYNAfJEZpkhKLWBpevsu3ylXIzJNEy2UwrJgWT3CnLpf5lNWlqTH8vAl3nQDe6Kp6Od0cUywRJ laFZQahXqvPgJfk5UF208HEZlOHt/hbUqNlNyF8kZOhuEEore9IHnxCd3BA7GKIQtud3E+WQREUn rvFB8ExmC6CfVurSQNCTB9MbXUy5VNOb6nSnPO2pT38K1KAKdahELapRj4rUpCp1qUxtqlN55DCR satMh/lfVQF5RakFhXJWgKkaZgrMHQgCrO4UXy/D2UjljTWsxlQgF9oayVwK0ANeRSuU6pq+Qt1K i1EdBg+/KcmTquqv50CQDyd1QO48qlMmy+EHJbhBEvoupKnzhQuNyCqHphA+F+RV7PQ1mb5O1I+v 6ywQR7lCav21c3Pypram6IVYotWaaZXta8kIR042EDRxWaI6xyi4rjnTlFVjG1W6/pDEQs4Gju+s 495cScetVbG5nsFb3/CIM7G69pezFM0hsdVCtk7tjsPZbicJ2sNKHnRwB0KlW5Rl0mcGk2dRVKRo HxTKk+ntob3abcacRtw6dsy2hVWldquFyv1Wt5PzbZpUU5nIaHZXb2fJZLx4G8wEexcdP2tw2uCW LAQKk6207Yxve+ZLFE8McMeE2XHmIBgN56ZuDIauIIsli7YRjm9qbI7gLuXO466Nbu6lpnW1ZmEm FjeVKy5aypzoXN/Ct7zqpDCLc1PhtVABUfsZEVom8TpYCXR2ugIaCu8pIg8muUajpWE/EVtQL7YZ s/8sjw1ROxUKRlaSvMunvsbc/md8Kk60GCLtoC/Ui8ZGlHKInuR0n6pTvIoXBpJOoAgqDWmnEnoE OaUDWRH3adJmetSkLrWpT43qVKt61axutatfDetYy3rWtK61rW+N61zrete87rWvfw3sYAt72MQu trGPjexkK3vZzG62s58N7WhLe9rUrra1r43tbGt729zutrfhh+kZhFvaiZZprtQU6jV5bL1UnRND NWvTO/ew0yYbCGhv2GcuvrmrWGWaDsZN1+oY74kGnjQWVqOwAZe1TzG2MTLf2Mh8maO30wQxfesE YwLC5IabsmTg9JpDv+4zoqJGU4lnHFjEWqXjKHWJCnPXbw6/DJd1sVXrTuzM/pmTDK7kTK1mCZ0w w6b2sOkNFcn97PEwAZyuxrhwN0+54bG17CjbMfmTsbxzIjM3wG5Empwv0uJiRkqbW7+yvWXucCcm 7o2PjrrYjTwcqj/3tl93sHkLznDrHHqSueKn5/yeX/2dfN1/bCVxAG1Liq1ZNvLON47JmeW1qveh FkuMgY/Tkb07qOlzp6UW725ItO84NTcmsV3NWHMslvNpHrY7zYy1evFis/Wi/1OH2/q3yPsNebef sNG2eQENA5jFw1cubEFvo3i6leDB5fHdynX22S5zhhJW/pJrxjXa8b7rhHz7lF+p/WSGjmToxr7B H975Ij+duh8Gbo0ZyOVA/qe8o3D2o5tdZZ7bjQnx9D96mG8eUPdVUQxyemtROaDVVyVUcgXnFqJm Wv3Fc1yGOo33UY32coiUZh4SUn8WDUuXJR7oI8wXJ81jeeoGa5u2JSg4bPEHJvT2bS8IgzEogzNI gzVogzeIgzmogzvIgz3ogz8IhEEohENIhEVohEeIhEmohEvIhE3ohE8IhVEohVNIhVVohVeIhVmo hVvIhV0ogyDIQDFYbgNTV/sGZjIggZblgn1jP7MngX1HgX+3hn9naBmFQlplhnYwNBonbo4DU3V3 fnyId77HabQXdgoWcwdWZsjyeGZXExGHGRRnfOhncNl1aSNoS4UoI9mn/jpFlDloI1kE0UH1F0gp 5VwXZ3+huHIcyEIj5FnytX1pR3N+YHOL5jLutyezeHladoFA90lCZ3TBWFoipUNEZ2ebxVm9aIdr t2TYJXk9k06SeGRD9kVAt11b9CnQOEyMRDdsqChXt1zQow3YhYeq93ayU4md4HSNCHe41Y5wkVsn hjeAOEXcuHidt2OVFXEDKDTg8X3f5WOIyIo5ZniBB281ozgTNnt6J2aJ4j+Q5zUMKH8NGQ6J5QpN o3l6RnzdF2FOlkHVx0XmBFK9x3g551auB2Hz5Hasl4il93pLc1YJB3xh45I0+WCQeDYuhju9VIL9 Vn6hF4gcSWW0NHpc/pdhyIeSmlQhKVaPcXOTzweS1sUv4xd2FoaN7GR9pwiU1Nc7xWV5yDVfkHJb jvFikjOTPTZ1wWd+PHeUo8eI6Tdc64SVpriQPVlzEyg6/hhf9TYeI+c7MDeGC3Vu92aW/mc6tsg5 AniHY6hYjeNxJpRQurWJ9oESz4iBB/iYSucp/jSRP0QhjlmHeIlmZVl/o5kpisePLWdH3yOC1AOG gxgldqmWT6WCHziH1LNULLg/6eaFvembvwmcwSmcw0mcxWmcxxlUrwktC9clh2AmkomcwlZpLEKS yhmd/+YMlIlDBMhmsZKA42hJllNBpXh50xBC2MFZx3iZ+HidQ4Jh/mjElWEpi2IUXXPJnvs1R2pU fNNITTjZnnEimH1kHY2pjz8xEqLkeQO1cGQDS66leOv3n0TCVXaykBgTk5QkLUxEXNUZeymmNE0W oUpCMN2BTdyoTAfTcwSpS3K3j4TURhwmd9cRoksyaKUDmqEpWJRHcnFWUkQnaIqpgX6pfwqFf595 jzOKpEmqpEvKpE3qpE8KpVEqpVNKpVVqpVeKpVmqpVvKpV3qpV8KpmEqpmNKpmVqpmeKpmmqpmvK pm3qpm8Kp3Eqhdb5QEPoi73BccGnnISVp0znbm54mIoWh5N5m19mNCyXRzZEWbwJcQLJnC6wf4wa Tq0pk+8Hm4Uo/okf1pJsaUAnZI65mHV8YIkShz8GYojgVIn+2VLx800s4B7MmCqaqooiZ1KkmFCk mnaeZFGxCkSpeQ+PQ4qOWkboFKq0qDZdxkKARBfsyF27OA7KeCi/uIjBSESrYlriAlmxynHJCKyP +ZTSFV3tJ3oEKY3QR42rdKoj9pICV3aTqJ/jGiK3JDzy6K3s0K7NSpV7k6kgqpmbeVFep3PN545Q CY9Vxq/x2KqcZJRymaFJI6gBRYcQa5DsAkkJt5jAdHh8lngJmVbNOKj99JAFppOWeUKSwm4QqioY OZIPixrF17Iuuo1jsbADU3nxFbIIFmWJV3umCrAdOpvuOqBX/gaTIXmLIIquORuIsmmgKOYvu1eQ J/mNb7WVhKhH6yd8MMus9kkLSWmpWOuW9OiS3wdkYzmVaKmpO2kZWguS4Hh88Rmx8hl3aKNl9EWO pFl0FCqvcvuTXIt3pTSUV+t8sKiiLIpVFTpwhCVQp1k5RJqNaqaeAcp29VqqhrlaGwVSjdVe2qqs GkuefKqgfNmtMmNXIcNY/1qK/dqVe2aySNej3hmoAWiBO/kelntaA7KXwFObO0KnOEKpaPiau8uq QZmJyVmoUpK7NwC82aObeiqpcuq8zwu90Su900u91Wu97JO8ovqoj8i9S0m111s+0+lvowu+X9W4 DkVnn4W7/j/0TnvVEAfph7txnvSQnoW2nhZZvlYQuOHan1U3n++QXGrre9NFuM8Vo/DKqfnLdNJj uzS7ue+GopukoYq6oD5rwN7FsW6pwFjgjfKEczsbwQ3ref9VwSdqtSuZrhu8QDdBotc3rDmTouon ZAm8nyibnkf2YyrcAjWqnbeLoz6so7nDo6xVpJP1ka3rq0b3o0b6vTrsxE8MxVEsxVNMxVVsxVeM xVmsxVvMxV3sxV8MxmEsxmNMxmVsxmeMxmmsxmvMxm3sxm8Mx3GMVNmLm9FGuoNShsdriqAWh3mo vXAAjK4brXhJP92pObD0uomKUos6bmwiiDEQah25qW+i/qq/m7SVWoA09ZZBe46jCnaXurRFh4v0 anHrhHHBu6p8tatsJp7cymTL8YorJ6RL3HY+GWThOauFhahmSGd11pLwQqyOaBe16FGJ+MJZa3v2 Kr+hS56Vt4qifFm9ap6+HG/CyJiCaKLNSsDRtDlZ437k2rNNBDJsh6jenHXO0q5WaY/5yn3wqKKg Onbld684swXH3MneGr+mi3rIPJah9Y7+zH4Ha7AE1IGcWcojLBNqmLnGopcYrMfwVIzAg7ET64Ai qV8SGbBBLG8hC56FYbdJOWZHPJSDkFioCaQ757KSTGCsu9KPjLQmJpRxBc+fyrMreaGTepIl6sBY N7w7/s22SBli38rRTCuyoWyhUBvU49u2TUyUF1xNXjvT4sTUCpRcL1u1+fnB/Okz5VK2e9zSWzm4 6Pc2VjmTm+e3Pl0g+yqW4kwpsmuXXzm0lbyWA1y1HrqRgStlc/lpHRg8AJWYrnge+Weotpqdjmu/ kMuXFT25MPd/iKl5mDuRu6i68FvOn9uVzFzU1TiK+FzZBZ3YeTl/LE27zJyapql98mHY5EPHLtK7 kGzJ3KO0Sk1UelwltF3Hmba8FLvacszbve3bvw3cwS3cZFq8/0YGVteCf+y9quqmuy0k4huQgJW/ qPkhiVzN44lBvNrQir1Cx4pD74vPkWuM9jvOlImO/prr3CGaeet4z1udw92oku76HlAm1Uyp2QNd w/1cwOkdoXWZkZc0ZIdUoe5coEfrw+rHXyX8yvn9SBeNv9Rbl0g9L0cz4CDWYX/zli3NoSZs1/us lRsc4ZfMwnh7ivYciTEcT/ut4BuKFwectk9s0oSchzy8qwslmkncl+M4u4AdpKqJUatDyEpcpMh6 pMNt5EeO5Emu5EvO5E3u5E8O5c7DWnoXfVO9wCG4hyvQvK7tP1mePC5NSvxtb/sn4a5aPNt7yolw 25ko5h83PHtLadHck/dBeNV60pM35t493tftimaNuDVkrcSoyBjyWIayO0k35HCYZycrzehlZt1a /uiwakFDCoHWbOhxxlWV+4kut52IruM2KsF1gnni57B0l9FAO3Qi3NX0na46faLbDN/s/Y/16dMu 3t7GBXbZTC2fyuJ17bGm/t742kRnfV3j98167cmYyp5zXjh6XnHD8i0CbrHCg+drBDsNirPr9Z6F 90sZvEmkjOszFlprLaDLqsEyBre6+s7C/BlBh7breo0dOlZ+fMtR+3ttWZJG+0QY3n38GpSuntkd HszZPrYZXjW46F8dK+4wXbQjTsK+/tIElh1bm5If3dQeXt/Ce4karJTp/tWl7rSkCTDpRIjZAs5/ 278v3o0INy6MKJU3ne6oaNW5WuEsD5ctP3dn/k3ykYOKE//uM3PseyTWkDrahy7Iobs4fhxYjAZD h+ZlpYnjkynEnej0BtU7Pa6fO17dvhyYd77oiT2aOdqnoE14Q2re6wuAc+bZV5+jFu+JicxRib7Y MNjmjppUHlj31Wbbfbjl61PcuxnlgS/4g0/4hW/4h2+Ee+8mZGVyVtW9//7ggw/zCkayLKmzmWz3 sp33UQxye+7og1XOD1ygM97Yz8zKjX6fhC/xATbvQA3ynJxVznjuCGvlRy7xmJzwAElh4cWpYYSg n0fwXZvkt2+TSPZ+Z1Th7N3vTl3kgW/uF7/8XTf5P42NZ5iS5x6XiF/Nqbjpg10rQT72/323nJy+ 0GGP6YwNytqv/uvP/u3v/u8P//Ev//NP//Vv//eP//mv//vP//3v//9PAPAxdbn9YZSTVntx1pt3 /8FQHMnSPNFUXdnWfeFYnunavvFc3/ne/4FB4ZBYNB6RSeWS2XQ+oVHplFq1XrFZ7Zbb9X7BYfGY XDaf0Wn1mt12v+Fx+Zxet9/xef2e3/f/AQMFBwkLDQ8RExUXGYsKAAA7 --=_f2fc6013b97d7c13822fc6c0b41f0169-- --=_98dc31a893dc1ce804ee4d75988f615b-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 12 10:45:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpYp-00030O-G6 for forces-archive@megatron.ietf.org; Mon, 12 Sep 2005 10:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23122 for ; Mon, 12 Sep 2005 10:45:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEpcr-0005jn-B5 for forces-archive@IETF.ORG; Mon, 12 Sep 2005 10:49:41 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010EA319@cherry.ease.lsoft.com>; Mon, 12 Sep 2005 10:45:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85372230 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Sep 2005 10:45:15 -0400 Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 12 Sep 2005 10:45:15 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8CEjEd7172670 for ; Mon, 12 Sep 2005 14:45:14 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8CEjDIj161742 for ; Mon, 12 Sep 2005 16:45:13 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8CEjDrV014909 for ; Mon, 12 Sep 2005 16:45:13 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8CEjDC3014906 for ; Mon, 12 Sep 2005 16:45:13 +0200 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA28544 for ; Mon, 12 Sep 2005 16:45:13 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id j8CEjEd7172670 Approved-By: Robert Haas Message-ID: <4325947C.501@zurich.ibm.com> Date: Mon, 12 Sep 2005 16:45:16 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Weiming, Jamal, A few comments on the HB issue: - the HB is a mechanism to check liveliness of the PL layer. If the PL=20 crashes at the FE or the CE, then (even if the TML is still working) the=20 association must go down. - somehow the FE has to know when the association with its CE goes down,=20 because it must then decide whether to continue forwarding packets or=20 not, among other things. So HBs from CEs to FEs are obviously necessary. - the CE would like to know the same thing, so it can perform HA=20 procedures, for instance. So liveliness indicators from the FEs are=20 necessary. - this can be achieved with HB messages, or any other PL message=20 whenever they are exchanged. BTW, I think the HB piggy-backing was=20 proposed by Evangelos Haleplidis some time ago. And the idea was a=20 "virtual piggy-backing", i.e., nothing else but a normal PL message is=20 exchanged. - multicasting HBs from the CE to all FEs is a good idea. But HBs (or=20 ACKs to HBs) from the FEs to the CE do not benefit much from multicast. So the two solutions how to perform PL-liveliness checks are: 1) "CE driven": The FE does not originate any HB by itself, it merely=20 responds to CE HBs that have the ACK flag ON. 2) "independent" The FE generates its own HBs according to a timer value=20 that the CE can set. I find solution 2) simpler to implement. Note that both solutions can=20 benefit from "virtual piggy-backing". The same amount of messages is=20 necessary in both cases (assuming the HB period of the FE and CE are the=20 same). Regards, -Robert Wang,Weiming wrote: >Now, I can understand your thought well. I think the only difference may= lie in where the timer for intervals is put. The scheme you proposed als= o needs two timers, only both timers all reside in CE, one is for CE to m= easure the interval, one is to measre the FE interval. Two cases will tri= gger the CE to send HB, when CE itself arrives message sending interval, = and when CE does not receive FE message within an interval.=20 > >I'm just a little worry that for the latter timer, CE may burden quite s= ome, as we know, we may have hundreds of FEs, which may make CE quite har= d to manage. > >Thanks, >Weiming > > >>Lets enumerate all scenarios (luckily theres only 4) in which something >>may be idle or busy during HB interval. When timer expires: >> >>case 00:=20 >>CE idle, FE idle=20 >>--> CE Send HB with no ACK >> >>case 01:=20 >>CE idle, FE active >>---> Send HB with ACK.=20 >>-----> Wait for response, if _any_ msg from FE, we claim FE is alive >> >>Case 10: >>CE active, FE idle >>--> same as case 01. I think this is the case you probably said there >>was two messages instead of one. >> >>case 11: >>CE active, FE active >>--> Do nothing >> >>Ok, lets use the above scenarios for further discussion. >> >>cheers, >>jamal >> > > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=C3=A4umerstrasse 4 CH-8803 R=C3=BCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 12 10:56:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpjC-0004le-St for forces-archive@megatron.ietf.org; Mon, 12 Sep 2005 10:56:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23594 for ; Mon, 12 Sep 2005 10:56:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEpnK-00061k-1x for forces-archive@IETF.ORG; Mon, 12 Sep 2005 11:00:31 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010EA20E@cherry.ease.lsoft.com>; Mon, 12 Sep 2005 10:56:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85373329 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Sep 2005 10:56:06 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 12 Sep 2005 10:56:06 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8CEB3XK074456; Mon, 12 Sep 2005 07:11:03 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126536947.6435.27.camel@localhost.localdomain> Date: Mon, 12 Sep 2005 10:55:47 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Section 9: Heartbeat Messages Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hi Weiming, I think what you are referring to is more timer implementation issues. As an example in the Linux kernel i have tested upto 100K different timers (one per flow) with no issues. There are many ways to achieve this goal and well known algorithms exist - If you want we can talk offline further on this; i just dont see it as an issue that will overburden the CE. cheers, jamal On Fri, 2005-09-09 at 20:53 +0800, Wang,Weiming wrote: > Now, I can understand your thought well. I think the only difference > may lie in where the timer for intervals is put. The scheme you > proposed also needs two timers, only both timers all reside in CE, > one is for CE to measure the interval, one is to measre the FE interval. > Two cases will trigger the CE to send HB, when CE itself arrives message > sending interval, and when CE does not receive FE message within an interval. > > I'm just a little worry that for the latter timer, CE may burden quite some, > as we know, we may have hundreds of FEs, which may make CE quite hard to manage. > > Thanks, > Weiming > > > > > Lets enumerate all scenarios (luckily theres only 4) in which something > > may be idle or busy during HB interval. When timer expires: > > > > case 00: > > CE idle, FE idle > > --> CE Send HB with ACK > > > > case 01: > > CE idle, FE active > > ---> Send HB with no ACK. > > -----> Wait for response, if _any_ msg from FE, we claim FE is alive > > > > Case 10: > > CE active, FE idle > > --> same as case 01. I think this is the case you probably said there > > was two messages instead of one. > > > > case 11: > > CE active, FE active > > --> Do nothing > > > > Ok, lets use the above scenarios for further discussion. > > > > cheers, > > jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 12 11:08:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpvM-00078t-IN for forces-archive@megatron.ietf.org; Mon, 12 Sep 2005 11:08:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24764 for ; Mon, 12 Sep 2005 11:08:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEpzN-0006Zo-U7 for forces-archive@IETF.ORG; Mon, 12 Sep 2005 11:13:00 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010EA3DA@cherry.ease.lsoft.com>; Mon, 12 Sep 2005 11:08:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85374504 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Sep 2005 11:08:34 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 12 Sep 2005 11:08:33 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8CENkXK074525; Mon, 12 Sep 2005 07:23:47 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126537711.6435.40.camel@localhost.localdomain> Date: Mon, 12 Sep 2005 11:08:30 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Section 9: Heartbeat Messages Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4325947C.501@zurich.ibm.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Robert, On Mon, 2005-12-09 at 16:45 +0200, Robert Haas wrote: > Weiming, Jamal, > A few comments on the HB issue: > - the HB is a mechanism to check liveliness of the PL layer. If the PL > crashes at the FE or the CE, then (even if the TML is still working) the > association must go down. Indeed. Infact one could go further than this and check the health of some pieces of the PL before sending a HB - but i would leave that to implementation details. > - somehow the FE has to know when the association with its CE goes down, > because it must then decide whether to continue forwarding packets or > not, among other things. So HBs from CEs to FEs are obviously necessary. yes > - the CE would like to know the same thing, so it can perform HA > procedures, for instance. So liveliness indicators from the FEs are > necessary. yes > - this can be achieved with HB messages, or any other PL message > whenever they are exchanged. BTW, I think the HB piggy-backing was > proposed by Evangelos Haleplidis some time ago. And the idea was a > "virtual piggy-backing", i.e., nothing else but a normal PL message is > exchanged. Ok, thats what we are settling on. > - multicasting HBs from the CE to all FEs is a good idea. But HBs (or > ACKs to HBs) from the FEs to the CE do not benefit much from multicast. > Let us leave this to be a TML dependent discussion (to avoid distraction). To comment though: with multicast one way you would benefit from cutting down the traffic by O(n) where n is the numberof(FEs -1) > So the two solutions how to perform PL-liveliness checks are: > 1) "CE driven": The FE does not originate any HB by itself, it merely > responds to CE HBs that have the ACK flag ON. > 2) "independent" The FE generates its own HBs according to a timer value > that the CE can set. > > > I find solution 2) simpler to implement. Note that both solutions can > benefit from "virtual piggy-backing". The same amount of messages is > necessary in both cases (assuming the HB period of the FE and CE are the > same). > The FE should still have a timer - a dead interval timer which is configured on FE Protocol object by the CE. This is not a heartbeat timer. On expiry of this timer, if the Fe hasnt heard from the CE (via heartbeats or piggybacks) it declares the association dead and invokes its HA rules. So it is still #1 i see with no need for #2 (i.e HB from FE->CE). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 05:17:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF6uw-0008V5-54 for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 05:17:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11412 for ; Tue, 13 Sep 2005 05:17:22 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF6zD-0005Ma-05 for forces-archive@IETF.ORG; Tue, 13 Sep 2005 05:21:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010EB4D9@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 5:17:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85439125 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 05:17:21 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 05:17:09 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id j8D91XHC004499; Tue, 13 Sep 2005 11:01:33 +0200 References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Approved-By: Avri Doria Message-ID: Date: Tue, 13 Sep 2005 11:17:01 +0200 Reply-To: Avri Doria Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: Section 9: Heartbeat Messages Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4325947C.501@zurich.ibm.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit On 12 sep 2005, at 16.45, Robert Haas wrote: > - this can be achieved with HB messages, or any other PL message > whenever they are exchanged. BTW, I think the HB piggy-backing was > proposed by Evangelos Haleplidis some time ago. And the idea was a > "virtual piggy-backing", i.e., nothing else but a normal PL message > is exchanged. if i understand this correctly, it means that the receiver has to treat the PL message as if it were a HB and take the appropriate actions, e.g. resetting timers. Does it do this with all PL messages or just come? My question is wether this doesn't become more of a burden then actually just having a specialized HB message going back and forth. > - multicasting HBs from the CE to all FEs is a good idea. But HBs > (or ACKs to HBs) from the FEs to the CE do not benefit much from > multicast. not unless there is more the one CE tracking liveliness. > > So the two solutions how to perform PL-liveliness checks are: > 1) "CE driven": The FE does not originate any HB by itself, it > merely responds to CE HBs that have the ACK flag ON. > 2) "independent" The FE generates its own HBs according to a timer > value that the CE can set. > > I find solution 2) simpler to implement. Note that both solutions > can benefit from "virtual piggy-backing". The same amount of > messages is necessary in both cases (assuming the HB period of the > FE and CE are the same). i also recommend solution 2. once thing the CE has to be careful about, especially in the case of massive FE systems is to make sure the HB are not synchronized to each other. a. From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 11:53:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFD5y-0003qq-3D for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 11:53:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28374 for ; Tue, 13 Sep 2005 11:53:03 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFDA9-0005hg-6A for forces-archive@IETF.ORG; Tue, 13 Sep 2005 11:57:41 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010EC573@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 11:52:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85473314 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 11:52:58 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 11:52:58 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8DF7uXK085528; Tue, 13 Sep 2005 08:07:56 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126626769.6467.24.camel@localhost.localdomain> Date: Tue, 13 Sep 2005 11:52:49 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages Comments: To: Avri Doria To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Ok, folks we need to close on this issue so we can progress on other unresolved issues. More below. On Tue, 2005-13-09 at 11:17 +0200, Avri Doria wrote: > On 12 sep 2005, at 16.45, Robert Haas wrote: > > > > - this can be achieved with HB messages, or any other PL message > > whenever they are exchanged. BTW, I think the HB piggy-backing was > > proposed by Evangelos Haleplidis some time ago. And the idea was a > > "virtual piggy-backing", i.e., nothing else but a normal PL message > > is exchanged. > > if i understand this correctly, it means that the receiver has to > treat the PL message as if it were a HB and take the appropriate > actions, e.g. resetting timers. Does it do this with all PL messages > or just come? My question is wether this doesn't become more of a > burden then actually just having a specialized HB message going back > and forth. > I think it would be implementation specific. For example a PL message could set a boolean state to indicate some traffic was seen which is then cleared by the expired HB timer etc. > > - multicasting HBs from the CE to all FEs is a good idea. But HBs > > (or ACKs to HBs) from the FEs to the CE do not benefit much from > > multicast. > > not unless there is more the one CE tracking liveliness. > Lets leave this out of the current discussion - it would be TML specific. > > So the two solutions how to perform PL-liveliness checks are: > > 1) "CE driven": The FE does not originate any HB by itself, it > > merely responds to CE HBs that have the ACK flag ON. > > 2) "independent" The FE generates its own HBs according to a timer > > value that the CE can set. > > > > I find solution 2) simpler to implement. Note that both solutions > > can benefit from "virtual piggy-backing". The same amount of > > messages is necessary in both cases (assuming the HB period of the > > FE and CE are the same). > > > i also recommend solution 2. > How about this as a middle ground so we can close this: - the CE can instruct the FE to send its own heartbeats at defined intervals. It should also define its dead interval. All these attributes will reside in the FE Proto Object. - The CE MUST be able to instruct the FE to send heartbeats. - The CE MAY decide not to instruct the FE to send heartbeats and instead drive them via ACKs. - The FE MAY support sending heartbeats. Which means we need a capability announcement to indicate the FE can do this via FE Protocol Object. This way one can choose to never implement heartbeats from the FE (I know this will be our preference for reasons i described earlier based on implementation experience) but the CE should still deal with them when it has to. On a personal level i see complexity supporting both but if thats what it takes to reach consensus so be it. > once thing the CE has to be careful about, especially in the case of > massive FE systems is to make sure the HB are not synchronized to > each other. Very good point. I will incorporate in the text. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 14:25:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFSs-00025u-VD for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 14:25:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05225 for ; Tue, 13 Sep 2005 14:24:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFXA-0000w1-Ja for forces-archive@IETF.ORG; Tue, 13 Sep 2005 14:29:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010EC7DC@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 14:24:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85482320 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 14:24:54 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 14:24:54 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8DHdpXK086795 for ; Tue, 13 Sep 2005 10:39:52 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-hh6beIDucOI9UyIFpwu8" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1126635891.6467.31.camel@localhost.localdomain> Date: Tue, 13 Sep 2005 14:24:51 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: minor changes: introduction section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 --=-hh6beIDucOI9UyIFpwu8 Content-Type: text/plain Content-Transfer-Encoding: 7bit I made some small changes to the introduction for readability - please comment on attachment. cheers, jamal --=-hh6beIDucOI9UyIFpwu8 Content-Disposition: attachment; filename=diff-intro.txt Content-Type: text/plain; name=diff-intro.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Internet-Draft ETRI Expires: February 2, 2006 R. Haas (Ed.) IBM - J. Hadi (Ed.) + J. Hadi Salim (Ed.) Znyx H. Khosravi (Ed.) Intel @@ -116,51 +116,51 @@ Table of Contents @@ -241,18 +241,16 @@ accordingly control the FEs in a standardizded way and by means of the ForCES protocol. - This document defines the ForCES protocol specifications. Basically, - the ForCES protocol works in a master-slave mode in which FEs are - slaves and CEs are masters. The ForCES protocol is a message - exchange protocol, information exchanged between FEs and CEs is - always in the form of protocol messages. The protocol is also a TLV - based protocol that include commands for transport of LFB information - as well as TLVs for association, configuration, status, and event - notifications, etc. + This document defines the ForCES protocol specifications. The ForCES + protocol works in a master-slave mode in which FEs are slaves and CEs + are masters. Information exchanged between FEs and CEs makes + extensive use of TLVs. The protocol includes commands for transport + of LFB configuration information as well as for association, status, + and event notifications, etc. - This specification does not specify a transport mechanism for - protocol messages, but does include a discussion of the services that - must be provided by the transport interface. + This specification does not define a transport mechanism for protocol + messages, but does include a discussion of service primitives that + must be provided by the underlying transport interface. Section 2 provides a glossary of terminology used in the specification. --=-hh6beIDucOI9UyIFpwu8-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 14:27:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFVL-0002re-G9 for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 14:27:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05311 for ; Tue, 13 Sep 2005 14:27:37 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFZj-0000zt-87 for forces-archive@IETF.ORG; Tue, 13 Sep 2005 14:32:15 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010EC814@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 14:27:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85482383 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 14:27:33 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 14:27:33 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8DIRU48010428; Tue, 13 Sep 2005 18:27:30 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8DIRDHW011055; Tue, 13 Sep 2005 18:27:28 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005091311272731825 ; Tue, 13 Sep 2005 11:27:27 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 11:27:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] minor changes: introduction section Thread-Index: AcW4kHRcnCin50caQgCWjOQY8KuH9wAAFAaA X-OriginalArrivalTime: 13 Sep 2005 18:27:28.0040 (UTC) FILETIME=[CB970280:01C5B890] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 13 Sep 2005 11:27:26 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: minor changes: introduction section Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Looks like a good improvement to me. -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Tuesday, September 13, 2005 11:25 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] minor changes: introduction section I made some small changes to the introduction for readability - please comment on attachment. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 14:28:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFVx-000312-7m for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 14:28:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05341 for ; Tue, 13 Sep 2005 14:28:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFaH-00010t-0Z for forces-archive@IETF.ORG; Tue, 13 Sep 2005 14:32:45 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010EC7DA@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 14:28:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85482403 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 14:28:07 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 14:28:06 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8DHh4XK086822 for ; Tue, 13 Sep 2005 10:43:04 -0700 (PDT) References: <1126635891.6467.31.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-E35pgTlfPc82LGO6Ty3m" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1126636084.6467.36.camel@localhost.localdomain> Date: Tue, 13 Sep 2005 14:28:04 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: minor changes: introduction section To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126635891.6467.31.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --=-E35pgTlfPc82LGO6Ty3m Content-Type: text/plain Content-Transfer-Encoding: 7bit Please ignore previous attachment and use this instead. cheers, jamal --=-E35pgTlfPc82LGO6Ty3m Content-Disposition: attachment; filename=diff-intro-def.txt Content-Type: text/plain; name=diff-intro-def.txt; charset=utf-8 Content-Transfer-Encoding: 7bit Internet-Draft ETRI Expires: February 2, 2006 R. Haas (Ed.) IBM - J. Hadi (Ed.) + J. Hadi Salim (Ed.) Znyx H. Khosravi (Ed.) Intel @@ -241,18 +241,16 @@ accordingly control the FEs in a standardizded way and by means of the ForCES protocol. - This document defines the ForCES protocol specifications. Basically, - the ForCES protocol works in a master-slave mode in which FEs are - slaves and CEs are masters. The ForCES protocol is a message - exchange protocol, information exchanged between FEs and CEs is - always in the form of protocol messages. The protocol is also a TLV - based protocol that include commands for transport of LFB information - as well as TLVs for association, configuration, status, and event - notifications, etc. + This document defines the ForCES protocol specifications. The ForCES + protocol works in a master-slave mode in which FEs are slaves and CEs + are masters. Information exchanged between FEs and CEs makes + extensive use of TLVs. The protocol includes commands for transport + of LFB configuration information as well as for association, status, + and event notifications, etc. - This specification does not specify a transport mechanism for - protocol messages, but does include a discussion of the services that - must be provided by the transport interface. + This specification does not define a transport mechanism for protocol + messages, but does include a discussion of service primitives that + must be provided by the underlying transport interface. Section 2 provides a glossary of terminology used in the specification. @@ -273,66 +271,12 @@ exchange descriptions. Section 8 describes mechanism in the protocol to support high - - - -Doria (Ed.), et al. Expires February 2, 2006 [Page 5] - -Internet-Draft ForCES August 2005 - - availability mechanisms including redundancy and fail over. Section 9 defines the security mechanisms provided by the PL and TML. @@ -342,8 +286,7 @@ This document follows the terminology defined by the ForCES Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. This document also uses the terminology defined by ForCES FE model in - [FE-MODEL]. We copy the definitions of some of the terminology as - indicated below: + [FE-MODEL] repeated below for clarity. Addressable Entity (AE) - A physical device that is directly addressable given some interconnect technology. For example, on IP @@ -483,8 +426,8 @@ message transportation issues, such as how the protocol messages are mapped to different transport media (like TCP, IP, ATM, Ethernet, etc), and how to achieve and implement reliability, multicast, - ordering, etc. The ForCES TML is specifically addressed in a - separate ForCES TML Specification document. + ordering, etc. The ForCES TML specifications are detailed in + separate ForCES documents one for each TML. --=-E35pgTlfPc82LGO6Ty3m-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 14:33:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFad-0003le-Tq for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 14:33:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05498 for ; Tue, 13 Sep 2005 14:32:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFew-00017L-KK for forces-archive@IETF.ORG; Tue, 13 Sep 2005 14:37:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010EC84A@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 14:32:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85483254 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 14:32:56 -0400 Received: from 81.228.8.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 14:32:56 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 977DD37E6F; Tue, 13 Sep 2005 20:32:55 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 84DE337E6A for ; Tue, 13 Sep 2005 20:32:55 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 6150337E44 for ; Tue, 13 Sep 2005 20:32:55 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EFFaQ-0002bj-Bm for forces@peach.ease.lsoft.com; Tue, 13 Sep 2005 20:32:54 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.5 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Jamal Hadi Salim Message-ID: <1126636374.14.0.100984003942.issue58@mip4.org> Date: Tue, 13 Sep 2005 18:32:54 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: [issue58] small issues with definitions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable New submission from Jamal Hadi Salim : I noticed a few things while browsing the draft. 1=2E LFB instance is not defined 2=2E Attribute is too overloaded these days. What about capabilities, etc? 3=2E Should we just have a separate document that captures in one spot? 4=2E "Forces NE" instead of just plain "NE" - shall we do a mass edit for consistency? The FE and CE are not refered to as FOrCES CE/FE. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 336 nosy: jamal priority: May fix status: Accepted title: small issues with definitions ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 14:44:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFlo-00060z-Mj for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 14:44:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05963 for ; Tue, 13 Sep 2005 14:44:30 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFq7-0001Ll-Fz for forces-archive@IETF.ORG; Tue, 13 Sep 2005 14:49:08 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010EC793@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 14:44:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85493219 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 14:44:28 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 14:44:27 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8DHxOXK086936 for ; Tue, 13 Sep 2005 10:59:24 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-rh9HiuwZZpPIoMZrmDjn" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1126637064.6521.3.camel@localhost.localdomain> Date: Tue, 13 Sep 2005 14:44:24 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: major changes: Protocol overview section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: cbe7c30f51299faf131c2a6265d05db8 --=-rh9HiuwZZpPIoMZrmDjn Content-Type: text/plain Content-Transfer-Encoding: 7bit This section went through some major changes to reflect discussion in last IETF meeting. It still requires some work. For this reason i am attaching both the text and the diff from last revision. This is requred reading for tommorow concal. Please review. cheers, jamal --=-rh9HiuwZZpPIoMZrmDjn Content-Disposition: attachment; filename=overview.diff.txt Content-Type: text/plain; name=overview.diff.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit @@ -622,10 +622,10 @@ tearing down such associations. An FE uses the PL layer to throw various subscribed-to events to the CE PL layer as well as respond to various status requests issued from the CE PL. The CE configures - both the FE and associated LFBs attributes using the PL layer. In - addition the CE may send various requests to the FE to activate or - deactivate it, reconfigure its HA parametrization, subscribe to - specific events etc. More details in Section 6. + both the FE and associated LFB'ss operational parameters using the PL + layer. In addition the CE may send various requests to the FE to + activate or deactivate it, reconfigure its HA parametrization, + subscribe to specific events etc. More details in Section 6. 3.1.2. The TML layer @@ -648,11 +648,10 @@ ForCES protocol. The best way to think of them are as configurations/parameterizations for the PL and TML before they become active (or even at runtime based on implementation). In the - simplest case, the FE or CE read a static configuration file which - they use as the FEM/CEM interface. RFC 3746 has a lot more detailed - descriptions on how the FEM and CEM could be used. We discuss the - pre-association phase where the CEM and FEM play briefly in section - Section 3.2.1. + simplest case, the FE or CE read a static configuration file. RFC + 3746 has a lot more detailed descriptions on how the FEM and CEM + could be used. We discuss the pre-association phase where the CEM + and FEM play briefly in section Section 3.2.1. An example of typical things FEM/CEM would configure would be TML specific parameterizations such as: @@ -664,6 +663,7 @@ c. Security parameterization such as keys etc. + d. Connection association parameters @@ -673,8 +673,6 @@ Internet-Draft ForCES August 2005 - d. Connection association parameters - Example "send up to 3 association messages each 1 second apart" Vs " send up to 4 association messages with increasing exponential timeout". @@ -684,7 +682,7 @@ ForCES, in relation to NEs, involves two phases: the Pre-Association phase where configuration/initialization/bootup of the TML and PL layer happens, and the association phase where the ForCES protocol - operates. + operates to parametrize FEs. 3.2.1. Pre-association @@ -697,7 +695,8 @@ considered static pre-association. Dynamic configuration may also happen using the Fc, Ff and Fl reference points. Vendors may use their own proprietary service discovery protocol to pass the - parameters. + parameters. Essentially only guidelines are provided here and the + details are left to the implementation. The following are scenarios reproduced from the Framework Document to show a pre-association example. @@ -724,6 +723,7 @@ + Doria (Ed.), et al. Expires February 2, 2006 [Page 13] Internet-Draft ForCES August 2005 @@ -750,18 +750,18 @@ Before the transition to the association phase, the FEM will have established contact with the appropriate CEM component. - Initialization of the ForCES interface will be completed, and - authentication as well as capability discovery may be complete as - well. Both the FE and CE would have the necessary information for - connecting to each other for configuration, accounting, - identification and authentication purposes. Both sides also would - have all the necessary protocol parameters such as timers, etc. The - Fl reference point may continue to operate during the association - phase and may be used to force a disassociation of an FE or CE. - Because the pre-association phase is out of scope, these details are - not discussed any further in this specification. The reader is - referred to the framework document [RFC3746] for more detailed - discussion. + Initialization of the ForCES interface will have completed, and + authentication as well as capability discovery may be complete. Both + the FE and CE would have the necessary information for connecting to + each other for configuration, accounting, identification and + authentication purposes. To summarize, at the completion of this + stage both sides have all the necessary protocol parameters such as + timers, etc. The Fl reference point may continue to operate during + the association phase and may be used to force a disassociation of an + FE or CE. Because the pre-association phase is out of scope, these + details are not discussed any further in this specification. The + reader is referred to the framework document [RFC3746] for a slightly + more detailed discussion. 3.2.2. Post-association @@ -769,11 +769,11 @@ using the ForCES protocol (PL over TML) as defined in this document. There are three sub-phases: - o Association setup state + o Association Setup state o Established State - o Association teardown state. + o Association Lost state. @@ -785,7 +785,7 @@ Internet-Draft ForCES August 2005 -3.2.2.1. Association setup state +3.2.2.1. Association Setup state The FE attempts to join the NE. The FE may be rejected or accepted. Once granted access into the NE, capabilities exchange happens with @@ -803,16 +803,44 @@ In this state the FE is continuously updated or queried. The FE may also send asynchronous event notifications to the CE or synchronous - heartbeat notifications. This continues until a termination is - initiated by either the CE or the FE. + heartbeat notifications if programmed to do so. This continues until + a termination occurs because of loss of connectivity or is initiated + by either the CE or the FE. Refer to section on protocol scenarios Section 7 for more details. +3.2.2.2.1. Association Lost state + + In this state, both or either the CE or FE declare the other side is + no longer associated. The disconnection could be physically + initiated by either party for administrative purposes but may also be + driven by operation reasons such as loss of connectivity. + + When an association is lost between a CE and FE, the FE continues to + operate as instructed by the CE via the CE failover policy (for + further discussion refer to in XXXX). + + Editorial note: We need text on XXXX - issue 36 Editorial note: We + need A state machine to show transitions + + For this revision of the protocol (as defined in this document), the + FE, upon re-association, MUST declare all the state it has as invalid + and retrieve new state. This approach is motivated by a desire for + simplicity (as opposed to efficiency). + 3.3. Protocol Mechanisms Various semantics are exposed to the protocol users via the PL header including: Transaction capabilities, atomicity of transactions, two phase commits, batching/parallelization, High Availability and + + + +Doria (Ed.), et al. Expires February 2, 2006 [Page 15] + +Internet-Draft ForCES August 2005 + + failover as well as command windows. 3.3.1. Transactions, Atomicity, Execution and Responses @@ -885,60 +913,66 @@ vendor where the FE-CE pair is tightly coupled. In such a case, the transactional operations maybe simplified further by extra computation at the CE. We do not discuss this view further other - than to mention it in not dissallowed. For the purpose of + than to mention it is not dissallowed. For the purpose of interopability, we define a classical transactional protocol known as two phase commit which meets the ACID properties to be used for transactions. - - -Doria (Ed.), et al. Expires February 2, 2006 [Page 16] - -Internet-Draft ForCES August 2005 - - 3.3.1.1.3. Transaction protocol - A 2PC starts with a START | ATOMIC flag on its first message of a - transaction. A transaction may span multiple messages. It is up to - the CE to keep track of the different seq #s making up a transaction. - This may then be followed by more messages which are part of the same - atomic transaction. + A 2PC starts with the header flags containg a SOT(start of + transaction) and AT (Atomic Transaction) on its first message + configuration message. A transaction may span multiple messages. It + is up to the CE to keep track of the different outstanding messages + making up a transaction. This may then be followed by more messages + which are part of the same atomic transaction. Any failure notified by the FE causes the CE to execute an ABORT to all FEs involved in the transaction, rolling back all previously executed operations in the transaction. + [Editorial Note: We need to discuss how to issue the ABORT - flags vs + type] + The transaction commitment phase is signalled by an empty DONE msg type. + Editorial note: Ok to rename DONE to be EOT (end of transaction)? + + [Editorial Note: We need to discuss how to issue the DONE - flags vs + type] + + The FE MUST respond to the CE's DONE message. If no response is + received from the CE within a specified timeout, the transaction MUST + be aborted by the CE. + + + +Doria (Ed.), et al. Expires February 2, 2006 [Page 17] + +Internet-Draft ForCES August 2005 + + 3.3.1.1.4. Recovery Any of the participating FEs, or the CE, or the associations between - them, may fail after the DONE message has left the CE and before it - has received all the responses, (possibly the DONE never reached the - FEs). At this point it is known that none of the operations failed - but it is presumed that the data has not yet been made durable by the - FEs. The means of detecting such failures may include loss of - heartbeat (within the scope of ForCES) or mechanisms outside the - scope of ForCES. When the associations are re-established, the CE - will discover a transaction in an intermediate state. Some FEs will - have made the data durable and closed the transaction; others may - have failed while doing so, and may, or may not, still have that - data. At this point the transaction enters the recovery phase. + them, may fail after the DONE response message has left the FE and + before it has received all the responses, (possibly the DONE response + never reached the CE). - The CE re-issues an empty DONE message to all FEs involved in the - transaction. Those that completed the transaction confirm this to - the CE. Those that did not, commit the data and confirm this to the - CE. An FE that has lost all records of the transaction MUST reply - with status UNKNOWN and the actions subsequently taken by the CE are - implementation dependent. + In this protocol revision, for sake of simplicity as indicated in + Section 3.2.2.2.1, an FE losing an association would be required to + get new state from the newly associated CE from scratch upon a + reassociation. The decision on what an FE should do after a lost + association is dicated by the CE Failover policy (refer to XXXX). + + Editorial note: section XXXX needed. 3.3.1.1.5. continue-execute-on-failure In which several independent operations are targeted at one or more LFB selectors. Execution continues at the FE when one or more - operations fail. This mode is signalled by a missing ATOMIC flag. + operations fail. This mode is signalled by a missing AT flag. 3.3.1.1.6. execute-until-falure @@ -960,28 +987,37 @@ Multipart flags apply. I.e all messages in a transaction except for the last have a MULTIPART flag on. - There has to be consistency across the multi parts of the messages. - In other words the first message starting with mode #1 above, implies - the rest do. Any inconsitency implies a cancelled transaction in - which all messages are dropped and the sender NACKED. + Multi-part messages MUST be consistent in their use of execution + modes. If the first message starts with one mode (such as continue- + execute-on-failure mode), then it implies the rest that are part of + the same multi-part messages do. Any inconsitency implies an error + and a cancelled transaction in which all messages are dropped and the + sender NACKED. -3.3.2. FE, CE, and FE protocol LFBs +3.3.2. FE, and FE protocol LFBs - All PL messages operate on LFB structures as this provides more + All PL messages operate on LFB constructs as this provides more flexibility for future enhancements. This means that maintenance and configurability of FEs, NE, as well as the ForCES protocol itself must be expressed in terms of this LFB architecture. For this reason special LFBs are created to accomodate this need. In addition, this shows how the ForCES protocol itself can be controlled by the very same type of structures (LFBs) it uses to control functions such as IP forwarding, filtering, etc. - To achieve this, the following LFBs are used: + To achieve this, the following speacilized LFBs are introduced: o FE Protocol LFB - o FE LFB + o FE Object LFB These LFBs are detailed in Section 6.2. A short description is provided here: @@ -1001,16 +1037,12 @@ between the CE and the FE. Such attributes can be FEState (refer to model draft), vendor, etc. The FE LFB contains in particular a table that maps a virtual LFB Instance ID to one or more Instance IDs of LFBs in the FE. + o [Editorial note: the term "FE attributes" is more technical than + implied above. We now use it to define a subsection of the LFB + elements, discuss]. + 3.3.3. Scaling by Concurrency It is desirable that the PL layer not become the bottleneck when @@ -1037,8 +1077,8 @@ o multiple PL PDUs can be aggregated under one TML message - o multiple LFB classes and instances can be addressed within one PL - PDU + o multiple LFB classes and instances (as indicated in the LFB + selector) can be addressed within one PL PDU o Multiple operations can be addressed to a single LFB class and instance --=-rh9HiuwZZpPIoMZrmDjn Content-Disposition: attachment; filename=proto-overview.txt Content-Type: text/plain; name=proto-overview.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 3. Overview The reader is referred to the Framework document [RFC3746], and in particular sections 3 and 4, for an architectural overview and an explanation of how the ForCES protocol fits in. There may be some content overlap between the framework document and this section in order to provide clarity. 3.1. Protocol Framework Figure 1 below is reproduced from the Framework document for clarity. It shows a NE with two CEs and two FEs. --------------------------------------- | ForCES Network Element | -------------- Fc | -------------- -------------- | | CE Manager |---------+-| CE 1 |------| CE 2 | | -------------- | | | Fr | | | | | -------------- -------------- | | Fl | | | Fp / | | | Fp| |----------| / | | | | |/ | | | | | | | | | Fp /|----| | | | | /--------/ | | -------------- Ff | -------------- -------------- | | FE Manager |---------+-| FE 1 | Fi | FE 2 | | -------------- | | |------| | | | -------------- -------------- | | | | | | | | | | | ----+--+--+--+----------+--+--+--+----- | | | | | | | | | | | | | | | | Fi/f Fi/f Fp: CE-FE interface Fi: FE-FE interface Fr: CE-CE interface Fc: Interface between the CE Manager and a CE Ff: Interface between the FE Manager and an FE Fl: Interface between the CE Manager and the FE Manager Fi/f: FE external interface Figure 1: ForCES Architectural Diagram The ForCES protocol domain is found in the Fp Reference Point. The Protocol Element configuration reference points, Fc and Ff also play a role in the booting up of the Forces Protocol. The protocol Doria (Ed.), et al. Expires February 2, 2006 [Page 9] Internet-Draft ForCES August 2005 element configuration is out of scope of the ForCES protocol but is touched on in this document since it is an integral part of the protocol pre-association phase. Figure 2 below shows further breakdown of the Fp interface by example of a MPLS QoS enabled Network Element. ------------------------------------------------- | | | | | | | |OSPF |RIP |BGP |RSVP |LDP |. . . | | | | | | | | ------------------------------------------------- | ForCES Interface | ------------------------------------------------- ^ ^ | | ForCES | |data control | |packets messages| |(e.g., routing packets) | | v v ------------------------------------------------- | ForCES Interface | ------------------------------------------------- | | | | | | | |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | | | | | |fier | | ------------------------------------------------- Figure 2: Examples of CE and FE functions The ForCES Interface shown in Figure 2 constitutes two pieces: the PL and TML layer. Doria (Ed.), et al. Expires February 2, 2006 [Page 10] Internet-Draft ForCES August 2005 This is depicted in Figure 3 below. +------------------------------------------------ | CE PL layer | +------------------------------------------------ | CE TML layer | +------------------------------------------------ ^ | ForCES | (i.e Forces data + control PL | packets ) messages | over | specific | TML | encaps | and | transport | | v +------------------------------------------------ | FE TML layer | +------------------------------------------------ | FE PL layer | +------------------------------------------------ Figure 3: ForCES Interface The PL layer is in fact the ForCES protocol. Its semantics and message layout are defined in this document. The TML Layer is necessary to connect two ForCES PL layers as shown in Figure 3 above. The TML is out of scope for this document but is within scope of ForCES. This document defines requirements the PL needs the TML to meet. Both the PL and the TML layers are standardized by the IETF. While only one PL layer is defined, different TMLs are expected to be standardized. To interoperate the TML layer at the CE and FE are expected to conform to the same definition. On transmit, the PL layer delivers its messages to the TML layer. The TML layer delivers the message to the destination TML layer(s). On receive, the TML delivers the message to its destination PL layer(s). 3.1.1. The PL layer The PL is common to all implementations of ForCES and is standardized Doria (Ed.), et al. Expires February 2, 2006 [Page 11] Internet-Draft ForCES August 2005 by the IETF as defined in this document. The PL layer is responsible for associating an FE or CE to an NE. It is also responsible for tearing down such associations. An FE uses the PL layer to throw various subscribed-to events to the CE PL layer as well as respond to various status requests issued from the CE PL. The CE configures both the FE and associated LFB'ss operational parameters using the PL layer. In addition the CE may send various requests to the FE to activate or deactivate it, reconfigure its HA parametrization, subscribe to specific events etc. More details in Section 6. 3.1.2. The TML layer The TML layer is essentially responsible for transport of the PL layer messages. The TML is where the issues of how to achieve transport level reliability, congestion control, multicast, ordering, etc are handled. It is expected more than one TML will be standardized. The different TMLs each could implement things differently based on capabilities of underlying media and transport. However, since each TML is standardized, interoperability is guaranteed as long as both endpoints support the same TML. All ForCES Protocol Layer implementations should be portable across all TMLs, because all TMLs have the same top edge semantics as defined in this document. 3.1.3. The FEM/CEM Interface The FEM and CEM components, although valuable in the setup and configurations of both the PL and TML layers, are out of scope of the ForCES protocol. The best way to think of them are as configurations/parameterizations for the PL and TML before they become active (or even at runtime based on implementation). In the simplest case, the FE or CE read a static configuration file. RFC 3746 has a lot more detailed descriptions on how the FEM and CEM could be used. We discuss the pre-association phase where the CEM and FEM play briefly in section Section 3.2.1. An example of typical things FEM/CEM would configure would be TML specific parameterizations such as: a. how the TML connection should happen (example what IP addresses to use, transport modes etc); b. the ID for the FE or CE would also be issued at this point. c. Security parameterization such as keys etc. d. Connection association parameters Doria (Ed.), et al. Expires February 2, 2006 [Page 12] Internet-Draft ForCES August 2005 Example "send up to 3 association messages each 1 second apart" Vs " send up to 4 association messages with increasing exponential timeout". 3.2. ForCES Protocol Phases ForCES, in relation to NEs, involves two phases: the Pre-Association phase where configuration/initialization/bootup of the TML and PL layer happens, and the association phase where the ForCES protocol operates to parametrize FEs. 3.2.1. Pre-association The ForCES interface is configured during the pre-association phase. In a simple setup, the configuration is static and is read from a saved config file. All the parameters for the association phase are well known after the pre-association phase is complete. A protocol such as DHCP may be used to retrieve the config parameters instead of reading them from a static config file. Note, this will still be considered static pre-association. Dynamic configuration may also happen using the Fc, Ff and Fl reference points. Vendors may use their own proprietary service discovery protocol to pass the parameters. Essentially only guidelines are provided here and the details are left to the implementation. The following are scenarios reproduced from the Framework Document to show a pre-association example. <----Ff ref pt---> <--Fc ref pt-------> FE Manager FE CE Manager CE | | | | | | | | (security exchange) (security exchange) 1|<------------>| authentication 1|<----------->|authentication | | | | (FE ID, attributes) (CE ID, attributes) 2|<-------------| request 2|<------------|request | | | | 3|------------->| response 3|------------>|response (corresponding CE ID) (corresponding FE ID) | | | | | | | | Figure 4: Examples of a message exchange over the Ff and Fc reference points Doria (Ed.), et al. Expires February 2, 2006 [Page 13] Internet-Draft ForCES August 2005 <-----------Fl ref pt--------------> | FE Manager FE CE Manager CE | | | | | | | | (security exchange) | | 1|<------------------------------>| | | | | | (a list of CEs and their attributes) | 2|<-------------------------------| | | | | | (a list of FEs and their attributes) | 3|------------------------------->| | | | | | | | | | Figure 5: An example of a message exchange over the Fl reference point Before the transition to the association phase, the FEM will have established contact with the appropriate CEM component. Initialization of the ForCES interface will have completed, and authentication as well as capability discovery may be complete. Both the FE and CE would have the necessary information for connecting to each other for configuration, accounting, identification and authentication purposes. To summarize, at the completion of this stage both sides have all the necessary protocol parameters such as timers, etc. The Fl reference point may continue to operate during the association phase and may be used to force a disassociation of an FE or CE. Because the pre-association phase is out of scope, these details are not discussed any further in this specification. The reader is referred to the framework document [RFC3746] for a slightly more detailed discussion. 3.2.2. Post-association In this phase, the FE and CE components communicate with each other using the ForCES protocol (PL over TML) as defined in this document. There are three sub-phases: o Association Setup state o Established State o Association Lost state. Doria (Ed.), et al. Expires February 2, 2006 [Page 14] Internet-Draft ForCES August 2005 3.2.2.1. Association Setup state The FE attempts to join the NE. The FE may be rejected or accepted. Once granted access into the NE, capabilities exchange happens with the CE querying the FE. Once the CE has the FE capability information, the CE can offer an initial configuration (possibly to restore state) and can query certain attributes within either an LFB or the FE itself. More details are provided in the protocol scenarios section. On successful completion of this state, the FE joins the NE and is moved to the Established State. 3.2.2.2. Association Established state In this state the FE is continuously updated or queried. The FE may also send asynchronous event notifications to the CE or synchronous heartbeat notifications if programmed to do so. This continues until a termination occurs because of loss of connectivity or is initiated by either the CE or the FE. Refer to section on protocol scenarios Section 7 for more details. 3.2.2.2.1. Association Lost state In this state, both or either the CE or FE declare the other side is no longer associated. The disconnection could be physically initiated by either party for administrative purposes but may also be driven by operation reasons such as loss of connectivity. When an association is lost between a CE and FE, the FE continues to operate as instructed by the CE via the CE failover policy (for further discussion refer to in XXXX). Editorial note: We need text on XXXX - issue 36 Editorial note: We need A state machine to show transitions For this revision of the protocol (as defined in this document), the FE, upon re-association, MUST declare all the state it has as invalid and retrieve new state. This approach is motivated by a desire for simplicity (as opposed to efficiency). 3.3. Protocol Mechanisms Various semantics are exposed to the protocol users via the PL header including: Transaction capabilities, atomicity of transactions, two phase commits, batching/parallelization, High Availability and Doria (Ed.), et al. Expires February 2, 2006 [Page 15] Internet-Draft ForCES August 2005 failover as well as command windows. 3.3.1. Transactions, Atomicity, Execution and Responses In the master-slave relationship the CE instructs one or more FEs on how to execute operations and how to report back the results. This section details the different modes of execution that a CE can order the FE(s) to perform in Section 3.3.1.1. It also describes the different modes a CE can ask the FE(s) to format the responses back after processing the operations requested. 3.3.1.1. Execution There are 3 execution modes that could be requested for a batch of operations spanning on one or more LFB selectors: a. Transactional execute-all-or-none b. Loose transactional execute-until-failure c. Non-transactional continue-execute-on-failure 3.3.1.1.1. 'all-or-none' Atomic transaction A transaction maybe atomic: a. Within an FE alone Example: updating multiple tables which are dependent on each other. If updating one fails, then any others already updated must be undone. b. Across the NE Example: updating the same type of table(s) that are interdependent across several FEs (such as L3 forwarding related tables). 3.3.1.1.2. Transaction Definition We define a transaction as a collection of one or more ForCES operations within one or more PL messages that MUST meet the ACIDity properties[ACID], defined as: o *Atomicity*. In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are. Doria (Ed.), et al. Expires February 2, 2006 [Page 16] Internet-Draft ForCES August 2005 o *Consistency*. A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started. o *Isolation*. A transaction in process and not yet committed must remain isolated from any other transaction. o *Durability*. Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state. There are cases where the CE knows exact memory and implementation details of the FE such as in the case of a FE-CE pair from the same vendor where the FE-CE pair is tightly coupled. In such a case, the transactional operations maybe simplified further by extra computation at the CE. We do not discuss this view further other than to mention it is not dissallowed. For the purpose of interopability, we define a classical transactional protocol known as two phase commit which meets the ACID properties to be used for transactions. 3.3.1.1.3. Transaction protocol A 2PC starts with the header flags containg a SOT(start of transaction) and AT (Atomic Transaction) on its first message configuration message. A transaction may span multiple messages. It is up to the CE to keep track of the different outstanding messages making up a transaction. This may then be followed by more messages which are part of the same atomic transaction. Any failure notified by the FE causes the CE to execute an ABORT to all FEs involved in the transaction, rolling back all previously executed operations in the transaction. [Editorial Note: We need to discuss how to issue the ABORT - flags vs type] The transaction commitment phase is signalled by an empty DONE msg type. Editorial note: Ok to rename DONE to be EOT (end of transaction)? [Editorial Note: We need to discuss how to issue the DONE - flags vs type] The FE MUST respond to the CE's DONE message. If no response is received from the CE within a specified timeout, the transaction MUST be aborted by the CE. Doria (Ed.), et al. Expires February 2, 2006 [Page 17] Internet-Draft ForCES August 2005 3.3.1.1.4. Recovery Any of the participating FEs, or the CE, or the associations between them, may fail after the DONE response message has left the FE and before it has received all the responses, (possibly the DONE response never reached the CE). In this protocol revision, for sake of simplicity as indicated in Section 3.2.2.2.1, an FE losing an association would be required to get new state from the newly associated CE from scratch upon a reassociation. The decision on what an FE should do after a lost association is dicated by the CE Failover policy (refer to XXXX). Editorial note: section XXXX needed. 3.3.1.1.5. continue-execute-on-failure In which several independent operations are targeted at one or more LFB selectors. Execution continues at the FE when one or more operations fail. This mode is signalled by a missing AT flag. 3.3.1.1.6. execute-until-falure In which all operations are executed on FE sequentially until first failure. The rest of the operations are not executed but everything up to failed is not undone unlike the case of all-or-none execution. flag: GOTON (global) 3.3.1.1.7. Relation to Multipart messages Multipart flags apply. I.e all messages in a transaction except for the last have a MULTIPART flag on. Multi-part messages MUST be consistent in their use of execution modes. If the first message starts with one mode (such as continue- execute-on-failure mode), then it implies the rest that are part of the same multi-part messages do. Any inconsitency implies an error and a cancelled transaction in which all messages are dropped and the sender NACKED. 3.3.2. FE, and FE protocol LFBs All PL messages operate on LFB constructs as this provides more flexibility for future enhancements. This means that maintenance and configurability of FEs, NE, as well as the ForCES protocol itself must be expressed in terms of this LFB architecture. For this reason special LFBs are created to accomodate this need. Doria (Ed.), et al. Expires February 2, 2006 [Page 18] Internet-Draft ForCES August 2005 In addition, this shows how the ForCES protocol itself can be controlled by the very same type of structures (LFBs) it uses to control functions such as IP forwarding, filtering, etc. To achieve this, the following speacilized LFBs are introduced: o FE Protocol LFB o FE Object LFB These LFBs are detailed in Section 6.2. A short description is provided here: o The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The CE operates on this LFB to subscribe or unsubscribe to Heartbeat messages, define the Heartbeat interval, or to discover which ForCES protocol version is supported and which TMLs the FE supports. The FE Protocol LFB also contains the various ForCES ID to be used: unicast IDs a table of the PL multicast IDs the FE must be listening to. o The FE LFB (referred to as "FE attributes" in the model draft) should not be confused with the FE Protocol Object. The FE LFB is a logical entity in each FE and contains attributes relative to the FE itself, and not to the operation of the ForCES protocol between the CE and the FE. Such attributes can be FEState (refer to model draft), vendor, etc. The FE LFB contains in particular a table that maps a virtual LFB Instance ID to one or more Instance IDs of LFBs in the FE. o [Editorial note: the term "FE attributes" is more technical than implied above. We now use it to define a subsection of the LFB elements, discuss]. 3.3.3. Scaling by Concurrency It is desirable that the PL layer not become the bottleneck when larger bandwidth pipes become available. To pick a mythical example in today's terms, if a 100Gbps pipe is available and there is sufficient work then the PL layer should be able to take advantage of this and use all of the 100Gbps pipe. Two mechanisms are provided to achieve this. The first one is batching and the second one is a command window. Batching is the ability to send multiple commands (such as Config) in one PDU. The size of the batch will be affected by, amongst other things, the path MTU. The commands may be part of the same transaction or part of unrelated transactions that are independent of Doria (Ed.), et al. Expires February 2, 2006 [Page 19] Internet-Draft ForCES August 2005 each other. Command windowing allows for pipelining of independent transactions which do not affect each other. Each independent transaction could consist of one or more batches. 3.3.3.1. Batching There are several batching levels at different protocol hierarchies. o multiple PL PDUs can be aggregated under one TML message o multiple LFB classes and instances (as indicated in the LFB selector) can be addressed within one PL PDU o Multiple operations can be addressed to a single LFB class and instance 3.3.3.2. Command Pipelining The protocol allows any number of messages to be issued by the CE before the corresponding acknowledgments (if requested) have been returned by the FE. Hence pipelining is inherently supported by the protocol. Matching responses with requests messages can be done using the correlator field in the message header. Doria (Ed.), et al. Expires February 2, 2006 [Page 20] Internet-Draft ForCES August 2005 --=-rh9HiuwZZpPIoMZrmDjn-- From mulligan@wifiwashington.com Tue Sep 13 16:00:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGx2-0005ZD-Rh for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 16:00:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12804 for ; Tue, 13 Sep 2005 16:00:16 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFH1Q-00049w-AW for forces-archive@ietf.org; Tue, 13 Sep 2005 16:04:56 -0400 Received: from p54ad6082.dip.t-dialin.net ([84.173.96.130] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EFGwq-000333-C4 for forces-archive@ietf.org; Tue, 13 Sep 2005 16:00:08 -0400 Date: Di, 13 Sep 2005 22:00:12 +0100 From: "Handler" To: Subject: Cialis ($uper /iagra) at $1.99 per dose Message-ID: <001101c5b862$74bd7900$306d81d4@wdw> MIME-Version: 1.0 Content-Type: multipart/related; boundary="=_3db4e20f0ec7b31fef7cb2fc1bc32ec7" X-Spam-Score: 2.8 (++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 --=_3db4e20f0ec7b31fef7cb2fc1bc32ec7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
--=_3db4e20f0ec7b31fef7cb2fc1bc32ec7 Content-Type: image/gif Content-Disposition: inline; filename="6d08f2a0ceb2a350a9872abcd3200df8.gif" Content-ID: <41288a07957957ebe019f8ca50ec7975> Content-Transfer-Encoding: base64 R0lGODdhWAKWAIAAAP///wAAMywAAAAAWAKWAAAC/oSPqcvtD6OctNqLs968+w+G4kiW5omm6sq2 7gvH8kzX9o3n+s73/g8MCofEovGI7AWWn6WTeQiAnomn1OAEXLFZLlTLtF6z4u2C6v2i01CrpLvp wrW6NfZtjk7yyb5ftsWHMXZXQliFEBioR8fY2KhWeHiW6Lj4+HiJySCoYdZ5o2kB+vZnetqSJxX2 OeegqrZaCPbVIIopmFs5Szg5a7ubaamn6njmlha1WqvwqQxbS7ZM+0wKfAzNB11lt4n6Dd6ECCYZ /EqpTC5rjL6Zzf6r2fvr3Rwsb8l82x6fHuHbj5Eif8as8bNXcJxCXAvDOXx4oZgwWq448Tu0rBtC /nfXdA0rR0fiuXzRhr2DIHLiP3ru0DhjSdHgxoPI4LVkVg+izp00ecF84BHkulL0QAEMOHGeOYsf X6rcJTPlvo4zXzrVtnTlNaQwjfL8ChblR0ijLpaTKbAqPpA+2eoTO/bS1bFbkaLlYhZvpn0DCY7k mK8h17thC4eDI22MxmbRqEiDtLgaNznUEjXW1yazZYNrEFPcLCcSp5qdI3ObHGsaNcVzHv/EBlqR atIuNRI2jDu37t0ubuvlDTy48OG6TQMljjy58uXMmzt/Dj269OnUq1u/jj279u3cu3v/Dj68+PHk y5s/jz69+vXs27t/Dz++/Pn069u/jz+//v38/vv7/w9ggAIOSGCBBh6IYIIKLshggw4+CGGEEk5I YYUWXohhhhpuyGGHHn4IYogijpiKcYOk5ltWOOHUQUXPeMGGZYxl5gqLdX2mYic2ZlAjY3ugBtog JIY1FY8LpfhXVhxEtVRQbT2VE1NPJimYJxREVVJaNsE1JE9yKQaji/A4dQw5L87ETk2jobgjQypC SddQx23p4jayDXTZnakdlKRVlYTBCytbdvmNHWtFmQxXZQJWJZmkOEoUVogUKYqcfVJply99aapk PXdB6qagQ2VJKESHHiolp3+lZNNJdZE5kqR/kpQoMUS95qk5rHkWaGtSdpoXW2SRBWqpD506/uuc w+IKpZODPqprpGhW5uayMGqFq5N+tqPqT85eqqVQdxRr7GFNOcNZuIg2y2e1iJILlLPIPllkQ7do 64+O4ZLa6I8JhXqWX0iW+4Oa6sBqS54otVYaYrWJGSQbnGXDGrUOL5IYl2fGyPFqu1Yc2jRiVKNn vBe3QqM6YQJLcGEDX2ney87V2zJYEDfR5nYyJ2dozT7/DHTQQg9NdNFGH4100kovPeTO+znNtH43 j5IztTHBsvCKn8a75ApVv6J11ijW4eNpaEIddQhoq8vtv+Mqy9DWrfo7rQkDA2Qpnwjv8C2jadcw cq2sWOObvsIGe9SvaqomeDfamFiamboO/o6ptb8qeprCeN0s6MZKfrv2311H+9vCdB/J7Fzrprlo t4a7jTjeCk08zsSagy1sX6b7Pfe0oYtuJemr1038XpA/PHVRbXf86dSq807zPQbHynJSpNHNald6 A2+DVIMilO7l3/t+q/a5jy++8PfaE37fVI0vV/qp9lt8ldz3hjqzm3Epq72vV886egWKLlUBF7sm lbXL8atb88uJ3HhnPo3drze0YVP51rQi2AisTl97nGwq4xqrYaNqDQOh407nOczcLmF5+pjYYkOy GL5pgg75Hf6+8sAbqs1rNOyPDXOQPBoE8Upfa1EPj4jEJCpxiUxsohOfCMUoSnGKVKxi/oNcFZGy yUgEyTvhP9wHM4lhaXdfzF4HVYikH1oxBc2D1+jsFzz+GWkE8Rve8NBCmPA9JUVqXGNEOtewIrpR RpdpF8VMpidoaVAy/jukBIvCsFFVxFWBE6H+7vGndXxQNH6cwaYwGUbMmS17uYJdAdH3LuFF0F03 GswAWUmu/6HSlQcLicA6KUSoXC+UrNwIKeXlPFW2sklebCQeaeIS6fUIhnRqV0+0pBRR4pIF26pf sNa1vrp55VUATKUpwcikU54PlqqU5SX7h5G3mXKaqchXA+G2N1D2Ln/ZEuZWvFe6UkqTfq/8ZD6v Ek8wxgUqAStdH9mZwJJ5DoN3eqEM/mMiw+nNKJEJfKhrKkgjQc5ofynrqAvDlJGTKZShEXsMyLqJ UBQclJfiWWmhZplSOg6RjUW8jkv90LOY6nSnPO2pT38K1KAKdahELapRjxoHZGA0o29BqlPpOFAB Ku+pVBWHSDCGQGtWdatlnN1C68TVsAoJi5bKmx3Filbz7e2maR1qUOZ11rbKtUaRCFwlLynXvOp1 r3ztq1//CtjACnawhC2sYQ+L2MQqdrGMbaxjHwvZyEp2spStrGUvi9nManaznO2sZz8L2tCKdrSk La1pT4ta/5Bhh19M6jaEhMgQkg2H7qtpHP0CNxwlrEVtMtGS+sjWJOhOh1nU6iPB/nc4+NwGbcvt qtsEesH3GcJu0MkF43S7mq9OsowUvRojD0ZKBUoOuxjlWiwspkLjoSxnkTsZ2CqGXUjaCXdm6hxE F4pXd310XLbr7j2/m91EAYpYt6PccZVjqHTuC59TNaA+MyU/ZI6zmtichI0AGpB4QtiepIMVvvLp S3e+BrrlbFXiYHfMCYtYEiKTnOvyWJ212JVKBtNjL2/CK2c+EzKBJBnhCMjhSvp2l7H5MS6KWeJV RdWQp3uePK+ZYh5TZqJtKCiLO1OB4JpCxjrWLxxRvOMvo7CO1MPesz53YLsYd19NgrKy4KrNJj8Z yEmW44N7F03LwXQ6nCSzMDEMuMBBhtdpV13lid+5zQxf05d8yTKg57mXOfWZgCQGs1S9uc/aQTpx 6RSNObmTkYgxL5J7YioifSyxiNoGD5s09X07hsGHvjrBISOhqGht68nUN5CtNm+oL8bMV5O0Vtfy 2KNEemw0NjSGJjUwxyTa5edoWTvTTq1wbRufmVp729zutre/De5wi3vc5C63uc+N7nSre93sbre7 3w3veMt73vSut73vje9863vf/O63v/8N8IALfOAUKgAAOw== --=_3db4e20f0ec7b31fef7cb2fc1bc32ec7 Content-Type: image/gif Content-Disposition: inline; filename="dd29072cf1d26c6e1e07d4c73c59fb4e.gif" Content-ID: <77ebfee0b5f91ec9fda598b8f3c8bb30> Content-Transfer-Encoding: base64 R0lGODdhWAIoAMYAAP////8AAAAAAL+/v19fXx8fHz8/P5+fn9/f339/f/+/v/9fX/8fH/8/P/+f n//f3/MTE8+Pj38AAB8AAL8AAD8AAJ9fX98AAP9/f+8vL99fX98fH+cHB+PDw8cHB4cnJ58AAF8A AHNTU+sLC28vL/c3N3MTE1c3N1cXF8enp/cXF/sbG9s7OzsbG68vL8MjI+cnJ88PD+8PD6sLC69P T+MDA58fH7d3d+enp9cXF89PT/NTU5s7O7cXF49vb+uLi48PD+dHR78/P8NjYwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAWAIoAAAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u6MKCwwBAQwNDobBAYgLxwuIx4zOhQ4NwMILCo8Pv8EMGA+MDcHFiA7BDQDQ hsrBzIq+1MLEh8fz8BiK6gHsvIPZheiy//7tW9RvoMGDD8DRCwbh2qBjAgw9oCdCXrCIiiASwkdP Q6MH747J6LCIXAAKBxApDGFAY6GJ8yomW3gMgriHNI9tQATzmMx9DoARIOQS4EWcATAeHCd0qdNc IHMei4BU6SCTx0IgMHY0Y1cAGKQGsPAt54ytXgOcOKQA4oGi/lfpaT2kUOwNomID2DiENdjcfXDh wioq+KmgwoYTt6orYYIAARMkHKMw4PDXQdRABEPJNemiopkdC6hwYXPltCEgSw429F4wEGg3vo5Y OPPmlIXwUagguoJm01UfP55AIdiFBIZsn8TNS7BwWnCfK646vTqrtsEqCEiAFoGFC40NWPZMCPsF ASOCkehs1SL5cxcJoE1xTLwiahNSdjDeXuKx1vwcM8FQgpmHnnovZSWAAQOgNQAP4E1gH3zvCbJf MAUUYmB6AazXiDTADHMTUgBIU45DhGQT4gLeJEITiSRiEKJDMgbQAIr8aMMAix/pWAxhwaRYIzwj CqJiOUUK/gIikZ35EySJJtqI4ouKHGljkiVOw6STyODV5XhgrdhiNFqK2GSUN1pHiToSCHAaIQMU wN147bFZQFgBgPAmnZ99RQ0FOCIgXSLqXNBBQsFIkOEiJfhVCJ4UCLCVYHbiqSchlgrAHCEHyBmb YD3Vmeidr+15CKILwcDlb/NQNQh29ODg4kIYAXkSPRFwFICrgsA6j6ztpGorRlGlWh5NLKRY1zyq emmVraxONd48/b2KrLI0NUvdthQWFyu2xnoZbTC8qvkINRUg98xlFE6QAEwXAMhnWkrhGYwKC3SD DU2RqquISRdsSg1L8yLlLrzyKlSBvH1WiGqkXB5sHMOG/ixLTwxe8ntasfRcYCpS1BYsVWn0UGZk SMd4nAjHNCnl0kqOERfMByfnxMMgFs+DMbcUuiyVyS3zhPIxNwuS8zE7F9wzyAupbLRUSVOosbmQ QPSxe1aZFOlWjQZgApfVOkvIBjStgOUhXR/T5oSLQBAMCtYGcB5ucGktKQBdf13V1c3kVQHbdnMd jN7jHANCzKzSPG1qMsttH6Qxe0u4IQJA9JjIxmm3WgA1aG7c45tFPngi9qYmQAghz3tMBQdsdWHA YGUOmbewY3U4ZInzbGsAjNNuX+UXXX4Inhdo13jthiN+jOJLczuP6aiPXmLyuC8Pcu+fU/0IYlgT spJ9/lpvyj3PAHxAMj3JVjl0uo9YepqdPH+v5G3kUzktTW3uKf/0yyWiUJvyAQACXkA/CqVGP8dY lEIk5LoCds952SnAAHoSAgn2RIHBYCAALsQZuvhFU4IYwrAE8Y4MOMAbghJAhlYiwQ1yoDErTJQA AjjAAgbmKwpCIIbIVwgWVqYDL5xADAMAwK3UsH/NwxzvQAgAEeYpJf+boREJiMQcbjCB2nOEgLT4 lVAx5xhr4SHYDHGAFoQABOcLgAtW9qfNXSAFCjBTlXwCgJ64i1teREoY28Wl1EmNHo3ZTorcosdE 4Mdfdcxeu77YlaGljG1jhGAAJnAaAdGtkSODJGYy/sicUG1LVwEowYgsOQgEeAoAhxyk45Rmq/xI MmzjcaUgTDmnVAZolUlMIimNNDFUZhCR8LLPLnOZRUNmJzb0GoS9ciKBT7GLPYhAwAEIgALaIVI2 eVoQDY5Rg67ZYFNoSxQCIHW3gi0Tf2hRGDKDRqfR0M4HyIydWJrZt6TEE4s9cyZ58rKoByqxnBBB i0v4Wc9y/nMQVKRHQ+gUz6rcc4e5HJY+fVYh9jSUoVxa1A3fE1AvZaijHsWo0oo5EyLyLZK+FMtx xCi2lI5pEPSBaHIy2JobLOSOwZJbAtDFNtDkZaXyNBkhhDNCAAwgBsHwQDwdOQ+gznSSCZJbrS7j /hJqCOeqwvOnLnHIVfJYFauDipgqOXoZEUjAW8fwQGW2iAj8RPU8BfMkK7sKSz62NYNvnep75GpX Xko1pRPI61wrSlJDwIos0eDGmFziK6nAbaTQBIBCYKMh7gkoNhGYBwgMmggVBGMG/NkTY/PyNr/q paB45MDMjkXax1ZMnNikgEap2pWVRGKjFM3ttmz7iJXEBiu6JQQCEnCCEKBVPL49mb4kC9tBqEO2 sYwLXVtKzB76BS0gWe7/kPnc2UJ1fl2lJ3ihu93YevdZzyxsITJwDA144wEKsNcGBNoVNoFVAKu5 VHUjiZUXOOQBQdlM2P4kK/ha7AWNOKeiImlf/rDm9zQ70IkC3hvfdwRXED8wDnMajNUH8+UYQngv Pv42WIwQbwh1xJM5ZjXJxU73oPK8AIofoGLSHQPF/HsxNVokTf7E+C6oksFWsBLiOo7YPn8iSYBf rMQJvPRRxgGyQoSc4yJnY3VI3oySLQyyImNFAuIhsoixXGL1Vkm1YpEQn+x4zUQGQyak5RYM/KZJ 8JI2B4zoyS/HyGb/vHkQOSAtxEY65wAAwbQ4HetPClFommy2krQlj57lUmcSHmMH9CWrpoM76edV +gEyEEtwtUYSGr8mQ6DOSQUF0eiFPPppUrlwEt+BaZ6EmiarBkCr6fFq5saaaR3D6a4166Yy/ps5 ER3wQE6KB9CjBC6cvJtUXvSqlAcgVdXFRoQOcrIbkpF4ERGezUM982xDdO0vAOjByFIzoQIdwwf8 2xq00Z2ia/N6hrr7Cg4czUQP9nKrm+bWvl3db0MMfB5ovTAL+IVvAByc2LixNr8B1Ng8FbVgdYlX Ih5uOCZKnOAUdzW0FlKBAmDX3sQGEG6PrQgEfIACJLsACFLTQj7tzxDh+yM74eJyNBqHAoEEpyEs 4HO5zXxBKZhB/hgBq4VB8+bRcCAAzApz44BAOwUQ3zODsBkEQJ0QOT+Ey6t+gd003NiCSEHRKZAa itX71DAGuFXUTjK2nx0RdJdbmy4OAB5U/v0kayNE3k/SduG+vDRl1w7DIuAtu/O9KB8HQT8PMXi7 y2vsiDf74hufmmFByOiO2RPm5aZ56u6X5ZwyQAEeUwACCF06BniM0AdxgMf87r5XHURYBTHN1avQ AHNixAAI4PvW4wYBBGgzIgYgnKvBXvaJqP2CCjFc1bOeAM7PKiEIYHsAxL7ghZB+pXlv/QIwiHLa B8Duke97A8ye+t8HUFjnr/31E9/276f+/eWk/vqn/wDWtyBtxn74dwgAuHrmdzUD8H3u139WsXth hQDxtwgEuCCzd4C/p4AMmBKDohGdokIBREbld36FAIHph3oomIIquIIsaAnj04IwGIMygjiDNEgJ L1iDOJiDOriDqHeDPPiDQBiEQtgc6TWERniESJiEqLB7StiETviEUBiFUjiFVFiFVniFWJiFWriF XNiFXviFYBiGYjiGZFiGZniGaJiGariGbNiGbviGcBiHcjiHdFiHdniHeJiHeriHfNiHfviHgBiI gjiIhFiIhsiGgQAAOw== --=_3db4e20f0ec7b31fef7cb2fc1bc32ec7-- --=_0bf7521e4936e60e1a60fa681fa74cdb-- From mulligan@wifiwashington.com Tue Sep 13 16:00:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGx3-0005ZC-1L for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 16:00:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12806 for ; Tue, 13 Sep 2005 16:00:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFH1S-0004AE-Gn for forces-archive@ietf.org; Tue, 13 Sep 2005 16:04:56 -0400 Received: from p54ad6082.dip.t-dialin.net ([84.173.96.130] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EFGwt-00033F-0k for forces-archive@ietf.org; Tue, 13 Sep 2005 16:00:11 -0400 Date: Di, 13 Sep 2005 22:00:18 +0100 From: "Finkelstein" To: Subject: Primary source of OEM MS 2003 software Look no further ! Message-ID: <001101c5b863$74bd7900$306d81d4@wdw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html X-Spam-Score: 2.0 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 w
Opt-in Email Special Offer     unsubscribe me
SEARCH

TOP 10 NEW TITLES

 ON SALE NOW!

 1 Office Pro 2003
 2 Adobe Photoshop 9.0
 3 Windows XP Pro
 4 Adobe Acrobat 7 Pro
 5 Flash MX 2004
 6 Corel Draw 12
 7 Norton Antivirus 2005
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
 10 Adobe Illustrator 11
  See more by this manufactu! rer
   Microsoft
   Symantec
   Adobe
  Customers also bought
   these other items...

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 

List Price:$499.00
Price:$69.99
You Save:$429.01 (86%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #1
System requirements ! |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.! 99
You Save:$529.01 (90%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.!

Microsoft Windows XP Professional or Longhorn Edition
Microsoft

Choose:
 

List Price:$279.00
Price:$49.99
You Save:$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales ! Rank: #3
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

Adobe Acrobat Professional V 7.0
Adobe

Choose:
 

List Price:$499.00
Price:$69.99
You Save:$429.01 (85%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #4
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

From lynch@zgas.net Tue Sep 13 16:06:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFH2m-0005ZJ-Kh for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 16:06:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14842 for ; Tue, 13 Sep 2005 16:06:13 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFH77-0004uD-Ki for forces-archive@ietf.org; Tue, 13 Sep 2005 16:10:52 -0400 Received: from pcp0012174952pcs.pimaco01.az.comcast.net ([69.252.128.214] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EFH2X-0004sj-GB for forces-archive@ietf.org; Tue, 13 Sep 2005 16:06:01 -0400 Date: Tue, 13 Sep 2005 13:06:02 +0100 From: "Gunzberg" To: Subject: No Forms All orders filled V|AGR@ :Soma: fTpyXK1f Message-ID: <001101c5b862$74bd7900$306d81d4@wdw> MIME-Version: 1.0 Content-Type: multipart/related; boundary="=_3db4e20f0ec7b31fef7cb2fc1bc32ec7" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 --=_3db4e20f0ec7b31fef7cb2fc1bc32ec7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
--=_3db4e20f0ec7b31fef7cb2fc1bc32ec7 Content-Type: image/gif Content-Disposition: inline; filename="6d08f2a0ceb2a350a9872abcd3200df8.gif" Content-ID: <41288a07957957ebe019f8ca50ec7975> Content-Transfer-Encoding: base64 R0lGODdhWAKWAIAAAP///wAAMywAAAAAWAKWAAAC/oSPqcvtD6OctNqLs968+w+G4kiW5omm6sq2 7gvH8kzX9o3n+s73/g8MCofEovGI7AWWn6WTeQiAnomn1OAEXLFZLlTLtF6z4u2C6v2i01CrpLvp wrW6NfZtjk7yyb5ftsWHMXZXQliFEBioR8fY2KhWeHiW6Lj4+HiJySCoYdZ5o2kB+vZnetqSJxX2 OeegqrZaCPbVIIopmFs5Szg5a7ubaamn6njmlha1WqvwqQxbS7ZM+0wKfAzNB11lt4n6Dd6ECCYZ /EqpTC5rjL6Zzf6r2fvr3Rwsb8l82x6fHuHbj5Eif8as8bNXcJxCXAvDOXx4oZgwWq448Tu0rBtC /nfXdA0rR0fiuXzRhr2DIHLiP3ru0DhjSdHgxoPI4LVkVg+izp00ecF84BHkulL0QAEMOHGeOYsf X6rcJTPlvo4zXzrVtnTlNaQwjfL8ChblR0ijLpaTKbAqPpA+2eoTO/bS1bFbkaLlYhZvpn0DCY7k mK8h17thC4eDI22MxmbRqEiDtLgaNznUEjXW1yazZYNrEFPcLCcSp5qdI3ObHGsaNcVzHv/EBlqR atIuNRI2jDu37t0ubuvlDTy48OG6TQMljjy58uXMmzt/Dj269OnUq1u/jj279u3cu3v/Dj68+PHk y5s/jz69+vXs27t/Dz++/Pn069u/jz+//v38/vv7/w9ggAIOSGCBBh6IYIIKLshggw4+CGGEEk5I YYUWXohhhhpuyGGHHn4IYogijpiKcYOk5ltWOOHUQUXPeMGGZYxl5gqLdX2mYic2ZlAjY3ugBtog JIY1FY8LpfhXVhxEtVRQbT2VE1NPJimYJxREVVJaNsE1JE9yKQaji/A4dQw5L87ETk2jobgjQypC SddQx23p4jayDXTZnakdlKRVlYTBCytbdvmNHWtFmQxXZQJWJZmkOEoUVogUKYqcfVJply99aapk PXdB6qagQ2VJKESHHiolp3+lZNNJdZE5kqR/kpQoMUS95qk5rHkWaGtSdpoXW2SRBWqpD506/uuc w+IKpZODPqprpGhW5uayMGqFq5N+tqPqT85eqqVQdxRr7GFNOcNZuIg2y2e1iJILlLPIPllkQ7do 64+O4ZLa6I8JhXqWX0iW+4Oa6sBqS54otVYaYrWJGSQbnGXDGrUOL5IYl2fGyPFqu1Yc2jRiVKNn vBe3QqM6YQJLcGEDX2ney87V2zJYEDfR5nYyJ2dozT7/DHTQQg9NdNFGH4100kovPeTO+znNtH43 j5IztTHBsvCKn8a75ApVv6J11ijW4eNpaEIddQhoq8vtv+Mqy9DWrfo7rQkDA2Qpnwjv8C2jadcw cq2sWOObvsIGe9SvaqomeDfamFiamboO/o6ptb8qeprCeN0s6MZKfrv2311H+9vCdB/J7Fzrprlo t4a7jTjeCk08zsSagy1sX6b7Pfe0oYtuJemr1038XpA/PHVRbXf86dSq807zPQbHynJSpNHNald6 A2+DVIMilO7l3/t+q/a5jy++8PfaE37fVI0vV/qp9lt8ldz3hjqzm3Epq72vV886egWKLlUBF7sm lbXL8atb88uJ3HhnPo3drze0YVP51rQi2AisTl97nGwq4xqrYaNqDQOh407nOczcLmF5+pjYYkOy GL5pgg75Hf6+8sAbqs1rNOyPDXOQPBoE8Upfa1EPj4jEJCpxiUxsohOfCMUoSnGKVKxi/oNcFZGy yUgEyTvhP9wHM4lhaXdfzF4HVYikH1oxBc2D1+jsFzz+GWkE8Rve8NBCmPA9JUVqXGNEOtewIrpR RpdpF8VMpidoaVAy/jukBIvCsFFVxFWBE6H+7vGndXxQNH6cwaYwGUbMmS17uYJdAdH3LuFF0F03 GswAWUmu/6HSlQcLicA6KUSoXC+UrNwIKeXlPFW2sklebCQeaeIS6fUIhnRqV0+0pBRR4pIF26pf sNa1vrp55VUATKUpwcikU54PlqqU5SX7h5G3mXKaqchXA+G2N1D2Ln/ZEuZWvFe6UkqTfq/8ZD6v Ek8wxgUqAStdH9mZwJJ5DoN3eqEM/mMiw+nNKJEJfKhrKkgjQc5ofynrqAvDlJGTKZShEXsMyLqJ UBQclJfiWWmhZplSOg6RjUW8jkv90LOY6nSnPO2pT38K1KAKdahELapRjxoHZGA0o29BqlPpOFAB Ku+pVBWHSDCGQGtWdatlnN1C68TVsAoJi5bKmx3Filbz7e2maR1qUOZ11rbKtUaRCFwlLynXvOp1 r3ztq1//CtjACnawhC2sYQ+L2MQqdrGMbaxjHwvZyEp2spStrGUvi9nManaznO2sZz8L2tCKdrSk La1pT4ta/5Bhh19M6jaEhMgQkg2H7qtpHP0CNxwlrEVtMtGS+sjWJOhOh1nU6iPB/nc4+NwGbcvt qtsEesH3GcJu0MkF43S7mq9OsowUvRojD0ZKBUoOuxjlWiwspkLjoSxnkTsZ2CqGXUjaCXdm6hxE F4pXd310XLbr7j2/m91EAYpYt6PccZVjqHTuC59TNaA+MyU/ZI6zmtichI0AGpB4QtiepIMVvvLp S3e+BrrlbFXiYHfMCYtYEiKTnOvyWJ212JVKBtNjL2/CK2c+EzKBJBnhCMjhSvp2l7H5MS6KWeJV RdWQp3uePK+ZYh5TZqJtKCiLO1OB4JpCxjrWLxxRvOMvo7CO1MPesz53YLsYd19NgrKy4KrNJj8Z yEmW44N7F03LwXQ6nCSzMDEMuMBBhtdpV13lid+5zQxf05d8yTKg57mXOfWZgCQGs1S9uc/aQTpx 6RSNObmTkYgxL5J7YioifSyxiNoGD5s09X07hsGHvjrBISOhqGht68nUN5CtNm+oL8bMV5O0Vtfy 2KNEemw0NjSGJjUwxyTa5edoWTvTTq1wbRufmVp729zutre/De5wi3vc5C63uc+N7nSre93sbre7 3w3veMt73vSut73vje9863vf/O63v/8N8IALfOAUKgAAOw== --=_3db4e20f0ec7b31fef7cb2fc1bc32ec7 Content-Type: image/gif Content-Disposition: inline; filename="dd29072cf1d26c6e1e07d4c73c59fb4e.gif" Content-ID: <77ebfee0b5f91ec9fda598b8f3c8bb30> Content-Transfer-Encoding: base64 R0lGODdhWAIoAMYAAP////8AAAAAAL+/v19fXx8fHz8/P5+fn9/f339/f/+/v/9fX/8fH/8/P/+f n//f3/MTE8+Pj38AAB8AAL8AAD8AAJ9fX98AAP9/f+8vL99fX98fH+cHB+PDw8cHB4cnJ58AAF8A AHNTU+sLC28vL/c3N3MTE1c3N1cXF8enp/cXF/sbG9s7OzsbG68vL8MjI+cnJ88PD+8PD6sLC69P T+MDA58fH7d3d+enp9cXF89PT/NTU5s7O7cXF49vb+uLi48PD+dHR78/P8NjYwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAWAIoAAAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u6MKCwwBAQwNDobBAYgLxwuIx4zOhQ4NwMILCo8Pv8EMGA+MDcHFiA7BDQDQ hsrBzIq+1MLEh8fz8BiK6gHsvIPZheiy//7tW9RvoMGDD8DRCwbh2qBjAgw9oCdCXrCIiiASwkdP Q6MH747J6LCIXAAKBxApDGFAY6GJ8yomW3gMgriHNI9tQATzmMx9DoARIOQS4EWcATAeHCd0qdNc IHMei4BU6SCTx0IgMHY0Y1cAGKQGsPAt54ytXgOcOKQA4oGi/lfpaT2kUOwNomID2DiENdjcfXDh wioq+KmgwoYTt6orYYIAARMkHKMw4PDXQdRABEPJNemiopkdC6hwYXPltCEgSw429F4wEGg3vo5Y OPPmlIXwUagguoJm01UfP55AIdiFBIZsn8TNS7BwWnCfK646vTqrtsEqCEiAFoGFC40NWPZMCPsF ASOCkehs1SL5cxcJoE1xTLwiahNSdjDeXuKx1vwcM8FQgpmHnnovZSWAAQOgNQAP4E1gH3zvCbJf MAUUYmB6AazXiDTADHMTUgBIU45DhGQT4gLeJEITiSRiEKJDMgbQAIr8aMMAix/pWAxhwaRYIzwj CqJiOUUK/gIikZ35EySJJtqI4ouKHGljkiVOw6STyODV5XhgrdhiNFqK2GSUN1pHiToSCHAaIQMU wN147bFZQFgBgPAmnZ99RQ0FOCIgXSLqXNBBQsFIkOEiJfhVCJ4UCLCVYHbiqSchlgrAHCEHyBmb YD3Vmeidr+15CKILwcDlb/NQNQh29ODg4kIYAXkSPRFwFICrgsA6j6ztpGorRlGlWh5NLKRY1zyq emmVraxONd48/b2KrLI0NUvdthQWFyu2xnoZbTC8qvkINRUg98xlFE6QAEwXAMhnWkrhGYwKC3SD DU2RqquISRdsSg1L8yLlLrzyKlSBvH1WiGqkXB5sHMOG/ixLTwxe8ntasfRcYCpS1BYsVWn0UGZk SMd4nAjHNCnl0kqOERfMByfnxMMgFs+DMbcUuiyVyS3zhPIxNwuS8zE7F9wzyAupbLRUSVOosbmQ QPSxe1aZFOlWjQZgApfVOkvIBjStgOUhXR/T5oSLQBAMCtYGcB5ucGktKQBdf13V1c3kVQHbdnMd jN7jHANCzKzSPG1qMsttH6Qxe0u4IQJA9JjIxmm3WgA1aG7c45tFPngi9qYmQAghz3tMBQdsdWHA YGUOmbewY3U4ZInzbGsAjNNuX+UXXX4Inhdo13jthiN+jOJLczuP6aiPXmLyuC8Pcu+fU/0IYlgT spJ9/lpvyj3PAHxAMj3JVjl0uo9YepqdPH+v5G3kUzktTW3uKf/0yyWiUJvyAQACXkA/CqVGP8dY lEIk5LoCds952SnAAHoSAgn2RIHBYCAALsQZuvhFU4IYwrAE8Y4MOMAbghJAhlYiwQ1yoDErTJQA AjjAAgbmKwpCIIbIVwgWVqYDL5xADAMAwK3UsH/NwxzvQAgAEeYpJf+boREJiMQcbjCB2nOEgLT4 lVAx5xhr4SHYDHGAFoQABOcLgAtW9qfNXSAFCjBTlXwCgJ64i1teREoY28Wl1EmNHo3ZTorcosdE 4Mdfdcxeu77YlaGljG1jhGAAJnAaAdGtkSODJGYy/sicUG1LVwEowYgsOQgEeAoAhxyk45Rmq/xI MmzjcaUgTDmnVAZolUlMIimNNDFUZhCR8LLPLnOZRUNmJzb0GoS9ciKBT7GLPYhAwAEIgALaIVI2 eVoQDY5Rg67ZYFNoSxQCIHW3gi0Tf2hRGDKDRqfR0M4HyIydWJrZt6TEE4s9cyZ58rKoByqxnBBB i0v4Wc9y/nMQVKRHQ+gUz6rcc4e5HJY+fVYh9jSUoVxa1A3fE1AvZaijHsWo0oo5EyLyLZK+FMtx xCi2lI5pEPSBaHIy2JobLOSOwZJbAtDFNtDkZaXyNBkhhDNCAAwgBsHwQDwdOQ+gznSSCZJbrS7j /hJqCOeqwvOnLnHIVfJYFauDipgqOXoZEUjAW8fwQGW2iAj8RPU8BfMkK7sKSz62NYNvnep75GpX Xko1pRPI61wrSlJDwIos0eDGmFziK6nAbaTQBIBCYKMh7gkoNhGYBwgMmggVBGMG/NkTY/PyNr/q paB45MDMjkXax1ZMnNikgEap2pWVRGKjFM3ttmz7iJXEBiu6JQQCEnCCEKBVPL49mb4kC9tBqEO2 sYwLXVtKzB76BS0gWe7/kPnc2UJ1fl2lJ3ihu93YevdZzyxsITJwDA144wEKsNcGBNoVNoFVAKu5 VHUjiZUXOOQBQdlM2P4kK/ha7AWNOKeiImlf/rDm9zQ70IkC3hvfdwRXED8wDnMajNUH8+UYQngv Pv42WIwQbwh1xJM5ZjXJxU73oPK8AIofoGLSHQPF/HsxNVokTf7E+C6oksFWsBLiOo7YPn8iSYBf rMQJvPRRxgGyQoSc4yJnY3VI3oySLQyyImNFAuIhsoixXGL1Vkm1YpEQn+x4zUQGQyak5RYM/KZJ 8JI2B4zoyS/HyGb/vHkQOSAtxEY65wAAwbQ4HetPClFommy2krQlj57lUmcSHmMH9CWrpoM76edV +gEyEEtwtUYSGr8mQ6DOSQUF0eiFPPppUrlwEt+BaZ6EmiarBkCr6fFq5saaaR3D6a4166Yy/ps5 ER3wQE6KB9CjBC6cvJtUXvSqlAcgVdXFRoQOcrIbkpF4ERGezUM982xDdO0vAOjByFIzoQIdwwf8 2xq00Z2ia/N6hrr7Cg4czUQP9nKrm+bWvl3db0MMfB5ovTAL+IVvAByc2LixNr8B1Ng8FbVgdYlX Ih5uOCZKnOAUdzW0FlKBAmDX3sQGEG6PrQgEfIACJLsACFLTQj7tzxDh+yM74eJyNBqHAoEEpyEs 4HO5zXxBKZhB/hgBq4VB8+bRcCAAzApz44BAOwUQ3zODsBkEQJ0QOT+Ey6t+gd003NiCSEHRKZAa itX71DAGuFXUTjK2nx0RdJdbmy4OAB5U/v0kayNE3k/SduG+vDRl1w7DIuAtu/O9KB8HQT8PMXi7 y2vsiDf74hufmmFByOiO2RPm5aZ56u6X5ZwyQAEeUwACCF06BniM0AdxgMf87r5XHURYBTHN1avQ AHNixAAI4PvW4wYBBGgzIgYgnKvBXvaJqP2CCjFc1bOeAM7PKiEIYHsAxL7ghZB+pXlv/QIwiHLa B8Duke97A8ye+t8HUFjnr/31E9/276f+/eWk/vqn/wDWtyBtxn74dwgAuHrmdzUD8H3u139WsXth hQDxtwgEuCCzd4C/p4AMmBKDohGdokIBREbld36FAIHph3oomIIquIIsaAnj04IwGIMygjiDNEgJ L1iDOJiDOriDqHeDPPiDQBiEQtgc6TWERniESJiEqLB7StiETviEUBiFUjiFVFiFVniFWJiFWriF XNiFXviFYBiGYjiGZFiGZniGaJiGariGbNiGbviGcBiHcjiHdFiHdniHeJiHeriHfNiHfviHgBiI gjiIhFiIhsiGgQAAOw== --=_3db4e20f0ec7b31fef7cb2fc1bc32ec7-- --=_0bf7521e4936e60e1a60fa681fa74cdb-- From lynch@zgas.net Tue Sep 13 16:06:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFH2m-0005Zb-PS for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 16:06:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14841 for ; Tue, 13 Sep 2005 16:06:13 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFH78-0004uP-81 for forces-archive@ietf.org; Tue, 13 Sep 2005 16:10:52 -0400 Received: from pcp0012174952pcs.pimaco01.az.comcast.net ([69.252.128.214] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EFH2Z-0004uO-NZ for forces-archive@ietf.org; Tue, 13 Sep 2005 16:06:03 -0400 Date: Tue, 13 Sep 2005 13:06:05 +0100 From: "Gersh" To: Subject: Primary source of OEM XP Pro software Look no further ! Message-ID: <001101c5b863$74bd7900$306d81d4@wdw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html X-Spam-Score: 2.6 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 w
Opt-in Email Special Offer     unsubscribe me
SEARCH

TOP 10 NEW TITLES

 ON SALE NOW!

 1 Office Pro 2003
 2 Adobe Photoshop 9.0
 3 Windows XP Pro
 4 Adobe Acrobat 7 Pro
 5 Flash MX 2004
 6 Corel Draw 12
 7 Norton Antivirus 2005
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
 10 Adobe Illustrator 11
  See more by this manufactu! rer
   Microsoft
   Symantec
   Adobe
  Customers also bought
   these other items...

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 

List Price:$499.00
Price:$69.99
You Save:$429.01 (86%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #1
System requirements ! |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.! 99
You Save:$529.01 (90%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.!

Microsoft Windows XP Professional or Longhorn Edition
Microsoft

Choose:
 

List Price:$279.00
Price:$49.99
You Save:$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales ! Rank: #3
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

Adobe Acrobat Professional V 7.0
Adobe

Choose:
 

List Price:$499.00
Price:$69.99
You Save:$429.01 (85%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #4
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 21:42:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFMIY-00020O-Sr for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 21:42:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15007 for ; Tue, 13 Sep 2005 21:42:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFMN0-0001SS-Jd for forces-archive@IETF.ORG; Tue, 13 Sep 2005 21:47:34 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010ECEA4@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 21:42:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85518338 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 21:42:44 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 21:42:44 -0400 Received: from [70.104.236.13] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12478310; Tue, 13 Sep 2005 21:42:44 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126637064.6521.3.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050913213925.02d2d2d8@localhost> Date: Tue, 13 Sep 2005 21:42:35 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: major changes: Protocol overview section Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126637064.6521.3.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 The change at 682 (intro to section 3.2) result in "the ForCES protocol operates to parameterize FEs." This claims that the association phase parameterizes the FE. Do you mean "the ForCES protocol operates to manipulate the parameters of the FEs?" Yours, Joel At 02:44 PM 9/13/2005, Jamal Hadi Salim wrote: >This section went through some major changes to reflect discussion in >last IETF meeting. It still requires some work. >For this reason i am attaching both the text and the diff from last >revision. >This is requred reading for tommorow concal. Please review. > >cheers, >jamal > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 22:13:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFMmM-000230-F0 for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 22:13:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17229 for ; Tue, 13 Sep 2005 22:13:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFMqm-0002Nt-Lc for forces-archive@IETF.ORG; Tue, 13 Sep 2005 22:18:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010ECEFF@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 22:13:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85519549 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 22:13:33 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 22:13:32 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 14 Sep 2005 10:47:56 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Wed, 14 Sep 2005 10:13:08 +0800 References: <1126635891.6467.31.camel@localhost.localdomain> <1126636084.6467.36.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <00b401c5b8d1$ccf7e180$1152010a@Necom.hzic.edu.cn> Date: Wed, 14 Sep 2005 10:12:47 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: minor changes: introduction section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: base64 SmFtYWwsDQoNCkkgYXBwcmVjaWF0ZSB5b3VyIHJldmlldy4gDQoNCkEgdGlueSBxdWVzdGlvbiBp cywgd2h5IHRoZSBzZW50ZW5jZSAgICJUaGUgRm9yQ0VTIHByb3RvY29sIGlzIGEgbWVzc2FnZSBl eGNoYW5nZSBwcm90b2NvbCwgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGJldHdlZW4gRkVzIGFuZCBD RXMgaXMgYWx3YXlzIGluIHRoZSBmb3JtIG9mIHByb3RvY29sIG1lc3NhZ2VzLiAiIHNob3VsZCBi ZSBvbWl0dGVkPyBkbyB5b3UgaGF2ZSBzb21lIG1vcmUgY29uc2lkZXJhdGlvbj8gTXkgdGhvdWdo dCBpcyB3ZSBtYXkgbmVlZCB0byBub3RpZnkgdGhhdCB0aGUgcHJvdG9jb2wgaXMgYSBtZXNzYWdp bmcgcHJvdG9jb2wgcmF0aGVyIHRoYW4gYSBoZWFkZXIgcHJvdG9jb2wgbGlrZSBUQ1AvSVAuIA0K DQpUaGFua3MsDQpXZWltaW5nDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IkphbWFsIEhhZGkgU2FsaW0iIDxoYWRpQHpueXguY29tPg0KVG86IDxGT1JDRVNAUEVBQ0guRUFT RS5MU09GVC5DT00+DQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNCwgMjAwNSAyOjI4IEFN DQpTdWJqZWN0OiBSZTogbWlub3IgY2hhbmdlczogaW50cm9kdWN0aW9uIHNlY3Rpb24NCg0KDQo+ IA0KPiBQbGVhc2UgaWdub3JlIHByZXZpb3VzIGF0dGFjaG1lbnQgYW5kIHVzZSB0aGlzIGluc3Rl YWQuDQo+IA0KPiBjaGVlcnMsDQo+IGphbWFsDQo+IA== From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 22:21:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFMtt-0004uZ-9h for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 22:21:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17560 for ; Tue, 13 Sep 2005 22:21:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFMyP-0002by-Be for forces-archive@IETF.ORG; Tue, 13 Sep 2005 22:26:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.010ECEBC@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 22:21:28 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85519951 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 22:21:27 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 22:21:25 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 14 Sep 2005 10:55:53 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Wed, 14 Sep 2005 10:21:04 +0800 References: <1126636374.14.0.100984003942.issue58@mip4.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <00bc01c5b8d2$e90f1590$1152010a@Necom.hzic.edu.cn> Date: Wed, 14 Sep 2005 10:20:44 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue58] small issues with definitions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: base64 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8 dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gSmFtYWwgSGFk aSBTYWxpbSA8aGFkaUB6bnl4LmNvbT46DQoNCkkgbm90aWNlZCBhIGZldyB0aGluZ3Mgd2hpbGUg YnJvd3NpbmcgdGhlIGRyYWZ0Lg0KDQoxLiBMRkIgaW5zdGFuY2UgaXMgbm90IGRlZmluZWQNCltX ZWltaW5nXSBZZXMsIHdlIG5lZWQgdGhpcywgYnV0IEkgaG9wZSBpdCBjYW4gYmUgZ2l2ZW4gZmly c3QgYnkgbW9kZWwgZHJhZnQsIHRoZW4gd2UgY29weSBpdCwgc28gYXMgdG8ga2VlcCBiZXR0ZXIg Y29uc2lzdGVuY3kuDQoNCjIuIEF0dHJpYnV0ZSBpcyB0b28gb3ZlcmxvYWRlZCB0aGVzZSBkYXlz LiBXaGF0IGFib3V0IGNhcGFiaWxpdGllcywgZXRjPw0KDQozLiBTaG91bGQgd2UganVzdCBoYXZl IGEgc2VwYXJhdGUgZG9jdW1lbnQgdGhhdCBjYXB0dXJlcyBpbiBvbmUgc3BvdD8NCg0KNC4gIkZv cmNlcyBORSIgaW5zdGVhZCBvZiBqdXN0IHBsYWluICJORSIgLSBzaGFsbCB3ZSBkbyBhIG1hc3Mg ZWRpdA0KZm9yIGNvbnNpc3RlbmN5PyBUaGUgRkUgYW5kIENFIGFyZSBub3QgcmVmZXJlZCB0byBh cyBGT3JDRVMgQ0UvRkUuDQpbV2VpbWluZ11JIHRoaW5rICBGb3JDRVMgTkUgaXMgbW9yZSByZWxh dmFudCwgZm9yIHdlIG1heSBlYXNpbHkgdGhpbmsgb2Ygb3RoZXIgTkVzIGlmIG5vdC4gRm9yIENF IGFuZCBGRSwgaXQgaXMgcXVpdGUgb2J2aW91cyBpdCBpcyBGb3JDRVMgQ0UvRkUuICBBIG1hc3Mg ZWRpdGluZyBpcyBnb29kIGZvciBjb25zaXN0ZW5jeSBvZiB0aGlzLiANCg0KVGhhbmtzLA0KV2Vp bWluZw0K From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 23:13:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFNhs-0000fg-EM for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 23:13:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19350 for ; Tue, 13 Sep 2005 23:13:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFNmN-0003lD-Jj for forces-archive@IETF.ORG; Tue, 13 Sep 2005 23:17:48 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010ED3B9@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 23:13:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85523332 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 23:13:04 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 23:13:03 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 14 Sep 2005 11:47:28 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Wed, 14 Sep 2005 11:12:39 +0800 References: <1126637064.6521.3.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <00d601c5b8da$1d4d1760$1152010a@Necom.hzic.edu.cn> Date: Wed, 14 Sep 2005 11:12:18 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: major changes: Protocol overview section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: base64 SmFtYWwsDQoNClRoYXQncyBhIHZlcnkgZ29vZCBjaGFuZ2UuIA0KDQpTb21lIGNvbW1lbnRzIGFy ZSBhcyBiZWxvdy4NCg0KMy4zLjIuICBGRSwgYW5kIEZFIHByb3RvY29sIExGQnMNCg0KICAgQWxs IFBMIG1lc3NhZ2VzIG9wZXJhdGUgb24gTEZCIGNvbnN0cnVjdHMgYXMgdGhpcyBwcm92aWRlcyBt b3JlDQogICBmbGV4aWJpbGl0eSBmb3IgZnV0dXJlIGVuaGFuY2VtZW50cy4gIFRoaXMgbWVhbnMg dGhhdCBtYWludGVuYW5jZSBhbmQNCltXZWltaW5nXSBJJ20gbm90IHN1cmUgaWYgIGl0IGlzIHBy b3BlciB0byBzYXkgJ0FsbCBQTCBtZXNzYWdlJyBoZXJlLCBiZWNhdXNlIGZvciBzb21lIG1lc3Nh Z2VzIGxpa2UgSEIsIGFzc29jaWF0aW9uIHRlYXJkb3duIG1lc3NhZ2VzLCBhbHRob3VnaCB3ZSBt YXkgc2F5IHRoZXkgYXJlIGFsc28gYWRkcmVzc2VkIHRvIExGQnMsICBhdCBsZWFzdCwgZnJvbSB0 aGUgbWVzc2FnZSBmb3JtYXQgcG9pbnQgb2YgdmlldywgdGhleSBhcmUgbm90LiAgDQoNCiAgIGNv bmZpZ3VyYWJpbGl0eSBvZiBGRXMsIE5FLCBhcyB3ZWxsIGFzIHRoZSBGb3JDRVMgcHJvdG9jb2wg aXRzZWxmDQogICBtdXN0IGJlIGV4cHJlc3NlZCBpbiB0ZXJtcyBvZiB0aGlzIExGQiBhcmNoaXRl Y3R1cmUuICBGb3IgdGhpcyByZWFzb24NCiAgIHNwZWNpYWwgTEZCcyBhcmUgY3JlYXRlZCB0byBh Y2NvbW9kYXRlIHRoaXMgbmVlZC4NCiANCiAgIEluIGFkZGl0aW9uLCB0aGlzIHNob3dzIGhvdyB0 aGUgRm9yQ0VTIHByb3RvY29sIGl0c2VsZiBjYW4gYmUNCiAgIGNvbnRyb2xsZWQgYnkgdGhlIHZl cnkgc2FtZSB0eXBlIG9mIHN0cnVjdHVyZXMgKExGQnMpIGl0IHVzZXMgdG8NCiAgIGNvbnRyb2wg ZnVuY3Rpb25zIHN1Y2ggYXMgSVAgZm9yd2FyZGluZywgZmlsdGVyaW5nLCBldGMuDQoNCiAgIFRv IGFjaGlldmUgdGhpcywgdGhlIGZvbGxvd2luZyBzcGVhY2lsaXplZCBMRkJzIGFyZSBpbnRyb2R1 Y2VkOg0KDQogICBvICBGRSBQcm90b2NvbCBMRkINCg0KICAgbyAgRkUgT2JqZWN0IExGQg0KDQog ICBUaGVzZSBMRkJzIGFyZSBkZXRhaWxlZCBpbiBTZWN0aW9uIDYuMi4gIA0KW1dlaW1pbmddIEkg dGhpbmsgaXQgbWF5IGxvb2sgYmV0dGVyIGZvciAgdGhlIG92ZXJhbGwgZHJhZnQgaWYgd2Ugc3Rv cCB0aGlzIHNlY3Rpb24gaGVyZSwgb3IgcHV0IHRoZSBmb2xsb3dpbmcgIHRleHQgaW4gU2VjdGlv biA2LjIgaWYgbmVjZXNzYXJ5LiANCg0KICAgQSBzaG9ydCBkZXNjcmlwdGlvbiBpcyAgcHJvdmlk ZWQgaGVyZToNCg0KICAgbyAgVGhlIEZFIFByb3RvY29sIExGQiBpcyBhIGxvZ2ljYWwgZW50aXR5 IGluIGVhY2ggRkUgdGhhdCBpcyB1c2VkIHRvDQogICAgICBjb250cm9sIHRoZSBGb3JDRVMgcHJv dG9jb2wuICBUaGUgQ0Ugb3BlcmF0ZXMgb24gdGhpcyBMRkIgdG8NCiAgICAgIHN1YnNjcmliZSBv ciB1bnN1YnNjcmliZSB0byBIZWFydGJlYXQgbWVzc2FnZXMsIGRlZmluZSB0aGUNCiAgICAgIEhl YXJ0YmVhdCBpbnRlcnZhbCwgb3IgdG8gZGlzY292ZXIgd2hpY2ggRm9yQ0VTIHByb3RvY29sIHZl cnNpb24NCiAgICAgIGlzIHN1cHBvcnRlZCBhbmQgd2hpY2ggVE1McyB0aGUgRkUgc3VwcG9ydHMu ICBUaGUgRkUgUHJvdG9jb2wgTEZCDQogICAgICBhbHNvIGNvbnRhaW5zIHRoZSB2YXJpb3VzIEZv ckNFUyBJRCB0byBiZSB1c2VkOiB1bmljYXN0IElEcyBhDQogICAgICB0YWJsZSBvZiB0aGUgUEwg bXVsdGljYXN0IElEcyB0aGUgRkUgbXVzdCBiZSBsaXN0ZW5pbmcgdG8uDQoNCiAgIG8gIFRoZSBG RSBMRkIgKHJlZmVycmVkIHRvIGFzICJGRSBhdHRyaWJ1dGVzIiBpbiB0aGUgbW9kZWwgZHJhZnQp DQogICAgICBzaG91bGQgbm90IGJlIGNvbmZ1c2VkIHdpdGggdGhlIEZFIFByb3RvY29sIE9iamVj dC4gIFRoZSBGRSBMRkIgaXMNCiAgICAgIGEgbG9naWNhbCBlbnRpdHkgaW4gZWFjaCBGRSBhbmQg Y29udGFpbnMgYXR0cmlidXRlcyByZWxhdGl2ZSB0bw0KICAgICAgdGhlIEZFIGl0c2VsZiwgYW5k IG5vdCB0byB0aGUgb3BlcmF0aW9uIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wNCiAgICAgIGJldHdl ZW4gdGhlIENFIGFuZCB0aGUgRkUuICBTdWNoIGF0dHJpYnV0ZXMgY2FuIGJlIEZFU3RhdGUgKHJl ZmVyDQogICAgICB0byBtb2RlbCBkcmFmdCksIHZlbmRvciwgZXRjLiAgVGhlIEZFIExGQiBjb250 YWlucyBpbiBwYXJ0aWN1bGFyIGENCiAgICAgIHRhYmxlIHRoYXQgbWFwcyBhIHZpcnR1YWwgTEZC IEluc3RhbmNlIElEIHRvIG9uZSBvciBtb3JlIEluc3RhbmNlDQogICAgICBJRHMgb2YgTEZCcyBp biB0aGUgRkUuDQpbV2VpbWluZ10gdGhlICdGRSBMRkInIG5hbWUgaXMgbm90IGEgY29uc2lzdGVu dCBuYW1lLg0KDQogICBvICBbRWRpdG9yaWFsIG5vdGU6IHRoZSB0ZXJtICJGRSBhdHRyaWJ1dGVz IiBpcyBtb3JlIHRlY2huaWNhbCB0aGFuDQogICAgICBpbXBsaWVkIGFib3ZlLiAgV2Ugbm93IHVz ZSBpdCB0byBkZWZpbmUgYSBzdWJzZWN0aW9uIG9mIHRoZSBMRkINCiAgICAgIGVsZW1lbnRzLCBk aXNjdXNzXS4NCltXZWltaW5nXSBBZ2FpbiwgSSBoaWdobHkgc3VnZ2VzdCB0byBwdXQgYWJvdmUg cGFyYWdyYXBoIGluIFNlY3Rpb24gNi4yIHRvIGVhc2UgdGhlIGNvbnNpc3RlbmN5IG1hbmFnZW1l bnQuDQoNClRoYW5rcywNCldlaW1pbmcNCiA= From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 13 23:20:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFNpM-00028S-4F for forces-archive@megatron.ietf.org; Tue, 13 Sep 2005 23:20:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19730 for ; Tue, 13 Sep 2005 23:20:49 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFNtq-0003vu-7b for forces-archive@IETF.ORG; Tue, 13 Sep 2005 23:25:32 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010ED0BD@cherry.ease.lsoft.com>; Tue, 13 Sep 2005 23:20:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85523518 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Sep 2005 23:20:41 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Sep 2005 23:20:40 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 14 Sep 2005 11:54:59 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Wed, 14 Sep 2005 11:20:10 +0800 References: <1126637064.6521.3.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <00e201c5b8db$2a3879a0$1152010a@Necom.hzic.edu.cn> Date: Wed, 14 Sep 2005 11:19:49 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: major changes: Protocol overview section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: base64 My4zLjEuMS40LiAgUmVjb3ZlcnkNCg0KICAgQW55IG9mIHRoZSBwYXJ0aWNpcGF0aW5nIEZFcywg b3IgdGhlIENFLCBvciB0aGUgYXNzb2NpYXRpb25zIGJldHdlZW4NCiAgIHRoZW0sIG1heSBmYWls IGFmdGVyIHRoZSBET05FIHJlc3BvbnNlIG1lc3NhZ2UgaGFzIGxlZnQgdGhlIEZFIGFuZA0KICAg YmVmb3JlIGl0IGhhcyByZWNlaXZlZCBhbGwgdGhlIHJlc3BvbnNlcywgKHBvc3NpYmx5IHRoZSBE T05FIHJlc3BvbnNlDQogICBuZXZlciByZWFjaGVkIHRoZSBDRSkuDQoNCiAgIEluIHRoaXMgcHJv dG9jb2wgcmV2aXNpb24sIGZvciBzYWtlIG9mIHNpbXBsaWNpdHkgYXMgaW5kaWNhdGVkIGluDQog ICBTZWN0aW9uIDMuMi4yLjIuMSwgYW4gRkUgbG9zaW5nIGFuIGFzc29jaWF0aW9uIHdvdWxkIGJl IHJlcXVpcmVkIHRvDQogICBnZXQgbmV3IHN0YXRlIGZyb20gdGhlIG5ld2x5IGFzc29jaWF0ZWQg Q0UgZnJvbSBzY3JhdGNoIHVwb24gYQ0KICAgcmVhc3NvY2lhdGlvbi4gIFRoZSBkZWNpc2lvbiBv biB3aGF0IGFuIEZFIHNob3VsZCBkbyBhZnRlciBhIGxvc3QNCiAgIGFzc29jaWF0aW9uIGlzIGRp Y2F0ZWQgYnkgdGhlIENFIEZhaWxvdmVyIHBvbGljeSAocmVmZXIgdG8gWFhYWCkuDQoNCiAgIEVk aXRvcmlhbCBub3RlOiBzZWN0aW9uIFhYWFggbmVlZGVkLg0KW1dlaW1pbmddIFBsZWFzZSBqdXN0 IHJlZmVyIHRvIFNlY3Rpb24gNi4yLjEuIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBhZGQgYSBt b3JlIHNwZWNpZmljYSBzZWN0aW9uIGZvciB0aGlzLg0KDQpUaGFua3MsDQpXZWltaW5nDQoNCg0K LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8 aGFkaUB6bnl4LmNvbT4NClRvOiA8Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NPg0KU2VudDog V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTQsIDIwMDUgMjo0NCBBTQ0KU3ViamVjdDogbWFqb3IgY2hh bmdlczogUHJvdG9jb2wgb3ZlcnZpZXcgc2VjdGlvbg0KDQoNCj4gDQo+IFRoaXMgc2VjdGlvbiB3 ZW50IHRocm91Z2ggc29tZSBtYWpvciBjaGFuZ2VzIHRvIHJlZmxlY3QgZGlzY3Vzc2lvbiBpbg0K PiBsYXN0IElFVEYgbWVldGluZy4gSXQgc3RpbGwgcmVxdWlyZXMgc29tZSB3b3JrLg0KPiBGb3Ig dGhpcyByZWFzb24gaSBhbSBhdHRhY2hpbmcgYm90aCB0aGUgdGV4dCBhbmQgdGhlIGRpZmYgZnJv bSBsYXN0DQo+IHJldmlzaW9uLg0KPiBUaGlzIGlzIHJlcXVyZWQgcmVhZGluZyBmb3IgdG9tbW9y b3cgY29uY2FsLiBQbGVhc2UgcmV2aWV3Lg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA0KPiA= From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 06:49:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFUpd-0000Vw-Sm for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 06:49:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03721 for ; Wed, 14 Sep 2005 06:49:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFUuE-0006Xq-27 for forces-archive@IETF.ORG; Wed, 14 Sep 2005 06:54:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010ED59A@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 6:49:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85545310 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 06:49:35 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 06:49:34 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8EA4IXK093897; Wed, 14 Sep 2005 03:04:19 -0700 (PDT) References: <1126637064.6521.3.camel@localhost.localdomain> <6.2.1.2.0.20050913213925.02d2d2d8@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126694967.6465.0.camel@localhost.localdomain> Date: Wed, 14 Sep 2005 06:49:27 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: major changes: Protocol overview section Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050913213925.02d2d2d8@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit On Tue, 2005-13-09 at 21:42 -0400, Joel M. Halpern wrote: > The change at 682 (intro to section 3.2) result in "the ForCES protocol > operates to parameterize FEs." This claims that the association phase > parameterizes the FE. Do you mean "the ForCES protocol operates to > manipulate the parameters of the FEs?" > yes - thanks. Fixed. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 07:05:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFV4e-0003rE-0I for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:05:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04342 for ; Wed, 14 Sep 2005 07:05:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFV9C-0006w6-F3 for forces-archive@IETF.ORG; Wed, 14 Sep 2005 07:09:52 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010ED51B@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 7:05:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85545833 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 07:04:59 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 07:04:58 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8EAIRXK093977; Wed, 14 Sep 2005 03:18:29 -0700 (PDT) References: <1126635891.6467.31.camel@localhost.localdomain> <1126636084.6467.36.camel@localhost.localdomain> <00b401c5b8d1$ccf7e180$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126695817.6465.10.camel@localhost.localdomain> Date: Wed, 14 Sep 2005 07:03:37 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: minor changes: introduction section Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00b401c5b8d1$ccf7e180$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Wed, 2005-14-09 at 10:12 +0800, Wang,Weiming wrote: > Jamal, > > I appreciate your review. > > A tiny question is, why the sentence "The ForCES protocol is a message > exchange protocol, information exchanged between FEs and CEs is always in > the form of protocol messages. " should be omitted? do you have some more > consideration? My thought is we may need to notify that the protocol is a > messaging protocol rather than a header protocol like TCP/IP. > Weiming, I thought the description was redundant from an ietf perspective, i.e - A protocol _already_ means there is message exchange (all IETF protocols have message exchanges). - message exchange _already_ means there is information exchange. - "protocol messages" also repeats the above two points. Terms like Request/Response protocol may be more fitting except we in addition have asynchronous events. If you feel strongly i could change it back. Note, i reviewed that text as part of going over the draft from the begining. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 07:09:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFV9G-0004fF-1n for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:09:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04441 for ; Wed, 14 Sep 2005 07:09:51 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFVDq-00072A-N3 for forces-archive@IETF.ORG; Wed, 14 Sep 2005 07:14:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010ED6A6@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 7:09:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85545952 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 07:09:51 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 07:09:51 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8EAO4XK094020; Wed, 14 Sep 2005 03:24:05 -0700 (PDT) References: <1126636374.14.0.100984003942.issue58@mip4.org> <00bc01c5b8d2$e90f1590$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126696154.6465.16.camel@localhost.localdomain> Date: Wed, 14 Sep 2005 07:09:14 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue58] small issues with definitions Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00bc01c5b8d2$e90f1590$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Wed, 2005-14-09 at 10:20 +0800, Wang,Weiming wrote: > ----- Original Message ----- > From: "Jamal Hadi Salim" > > New submission from Jamal Hadi Salim : > > I noticed a few things while browsing the draft. > > 1. LFB instance is not defined > [Weiming] Yes, we need this, but I hope it can be given first by model > draft, then we copy it, so as to keep better consistency. > I have opened an issue ticket on the model so this gets resolved. > 2. Attribute is too overloaded these days. What about capabilities, etc? > > 3. Should we just have a separate document that captures in one spot? > > 4. "Forces NE" instead of just plain "NE" - shall we do a mass edit > for consistency? The FE and CE are not refered to as FOrCES CE/FE. > [Weiming]I think ForCES NE is more relavant, for we may easily think of other > NEs if not. For CE and FE, it is quite obvious it is ForCES CE/FE. A mass > editing is good for consistency of this. > Sounds reasonable - but when i was reading it sort of irritated me; Can we probably just say it once in the beggining along the lines "this document will refer to a Forces NE as simply NE and when a distinction needs to be made the terms Forces NE and non-Forces NE will be used" Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 07:10:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVA9-0004zK-0t for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:10:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04461 for ; Wed, 14 Sep 2005 07:10:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFVEh-00073I-KS for forces-archive@IETF.ORG; Wed, 14 Sep 2005 07:15:34 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010ED563@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 7:10:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85545987 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 07:10:36 -0400 Received: from 81.228.9.183 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 07:10:36 -0400 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 9102B37F03; Wed, 14 Sep 2005 13:10:35 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5030B37E81 for ; Wed, 14 Sep 2005 13:10:35 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 433C937E4A for ; Wed, 14 Sep 2005 13:10:35 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EFV9u-0003se-K6 for forces@peach.ease.lsoft.com; Wed, 14 Sep 2005 13:10:35 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.5 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Jamal Hadi Salim Message-ID: <1126696229.28.0.572922630911.issue59@mip4.org> Date: Wed, 14 Sep 2005 11:10:29 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: [issue59] definition of LFB instance needed To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable New submission from Jamal Hadi Salim : Refer to issue #58 in the protocol draft ---------- category: Editorial draft: draft-ietf-forces-model messages: 339 nosy: jamal priority: Must fix status: Need clarifying text superseder: small issues with definitions title: definition of LFB instance needed ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 07:38:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVax-0002HI-MO for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:38:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05194 for ; Wed, 14 Sep 2005 07:38:30 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFVfY-0007dD-GL for forces-archive@IETF.ORG; Wed, 14 Sep 2005 07:43:16 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010ED61E@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 7:38:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85546745 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 07:38:29 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 07:38:29 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8EAr0XK094179; Wed, 14 Sep 2005 03:53:01 -0700 (PDT) References: <1126637064.6521.3.camel@localhost.localdomain> <00d601c5b8da$1d4d1760$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126697890.6465.30.camel@localhost.localdomain> Date: Wed, 14 Sep 2005 07:38:10 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: major changes: Protocol overview section Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00d601c5b8da$1d4d1760$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit On Wed, 2005-14-09 at 11:12 +0800, Wang,Weiming wrote: > Jamal, > > That's a very good change. > > Some comments are as below. > > 3.3.2. FE, and FE protocol LFBs > > All PL messages operate on LFB constructs as this provides more > flexibility for future enhancements. This means that maintenance and > [Weiming] I'm not sure if it is proper to say 'All PL message' here, > because for some messages like HB, association teardown messages, although > we may say they are also addressed to LFBs, at least, from the message > format point of view, they are not. > The HB is the closest it comes to some message that has no LFB, but in my opinion it does. Even though we decided to have a shortcut for the HB by not having a LF selector, there is infact an LFB - the FEPO to be precise - that is used to configure HB parameters. I am thinking hard and i cant think of any other message which doesnt have an LFB associated with it. But if you could mention one, I will go back and make changes. > configurability of FEs, NE, as well as the ForCES protocol itself > must be expressed in terms of this LFB architecture. For this reason > special LFBs are created to accomodate this need. > > In addition, this shows how the ForCES protocol itself can be > controlled by the very same type of structures (LFBs) it uses to > control functions such as IP forwarding, filtering, etc. > > To achieve this, the following speacilized LFBs are introduced: > > o FE Protocol LFB > > o FE Object LFB > > These LFBs are detailed in Section 6.2. > [Weiming] I think it may look better for the overall draft if we stop this > section here, or put the following text in Section 6.2 if necessary. > Did you mean not to give the short description below for the two LFBs when you say to "to stop this section here"? > A short description is provided here: > > o The FE Protocol LFB is a logical entity in each FE that is used to > control the ForCES protocol. The CE operates on this LFB to > subscribe or unsubscribe to Heartbeat messages, define the > Heartbeat interval, or to discover which ForCES protocol version > is supported and which TMLs the FE supports. The FE Protocol LFB > also contains the various ForCES ID to be used: unicast IDs a > table of the PL multicast IDs the FE must be listening to. > > o The FE LFB (referred to as "FE attributes" in the model draft) > should not be confused with the FE Protocol Object. The FE LFB is > a logical entity in each FE and contains attributes relative to > the FE itself, and not to the operation of the ForCES protocol > between the CE and the FE. Such attributes can be FEState (refer > to model draft), vendor, etc. The FE LFB contains in particular a > table that maps a virtual LFB Instance ID to one or more Instance > IDs of LFBs in the FE. > [Weiming] the 'FE LFB' name is not a consistent name. Good catch - infact i think some of the description was valid a while back, no longer true since we have formalized these two LFBs. To address (if i understood you) your earlier point, I have changed the text to: ------- 3.3.2. FE Object and FE protocol LFBs All PL messages operate on LFB constructs as this provides more flexibility for future enhancements. This means that maintenance and configurability of FEs, NE, as well as the ForCES protocol itself must be expressed in terms of this LFB architecture. For this reason special LFBs are created to accomodate this need. In addition, this shows how the ForCES protocol itself can be controlled by the very same type of structures (LFBs) it uses to control functions such as IP forwarding, filtering, etc. To achieve this, the following speacilized LFBs are introduced: o FE Protocol LFB which is used to control the ForCES protocol. o FE Object LFB which is used to controls attributes relative to the FE itself. Such attributes include FEState (refer to model draft), vendor, etc. These LFBs are detailed in Section 6.2. ---- > > o [Editorial note: the term "FE attributes" is more technical than > implied above. We now use it to define a subsection of the LFB > elements, discuss]. > [Weiming] Again, I highly suggest to put above paragraph in Section 6.2 to > ease the consistency management. I have removed that text since it was intended to highlight that text to point to a draft-global issue. This issue is now captured in issue #58. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 07:59:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVuo-0006ll-0v for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:59:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05990 for ; Wed, 14 Sep 2005 07:59:00 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFVzL-0008Dx-Uv for forces-archive@IETF.ORG; Wed, 14 Sep 2005 08:03:47 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010ED62C@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 7:58:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85547221 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 07:58:57 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 07:58:57 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8EBDLXK094335; Wed, 14 Sep 2005 04:13:21 -0700 (PDT) References: <1126637064.6521.3.camel@localhost.localdomain> <00e201c5b8db$2a3879a0$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126699111.6465.33.camel@localhost.localdomain> Date: Wed, 14 Sep 2005 07:58:31 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: major changes: Protocol overview section Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00e201c5b8db$2a3879a0$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit On Wed, 2005-14-09 at 11:19 +0800, Wang,Weiming wrote: > 3.3.1.1.4. Recovery > > Any of the participating FEs, or the CE, or the associations between > them, may fail after the DONE response message has left the FE and > before it has received all the responses, (possibly the DONE response > never reached the CE). > > In this protocol revision, for sake of simplicity as indicated in > Section 3.2.2.2.1, an FE losing an association would be required to > get new state from the newly associated CE from scratch upon a > reassociation. The decision on what an FE should do after a lost > association is dicated by the CE Failover policy (refer to XXXX). > > Editorial note: section XXXX needed. > [Weiming] Please just refer to Section 6.2.1. I don't think we need to > add a more specifica section for this. > Thanks. the new text now reads: --- 3.3.1.1.4. Recovery Any of the participating FEs, or the CE, or the associations between them, may fail after the DONE response message has left the FE and before it has received all the responses, (possibly the DONE response never reached the CE). In this protocol revision, for sake of simplicity as indicated in Section 3.2.2.2.1, an FE losing an association would be required to get new state from the newly associated CE from scratch upon a reassociation. The decision on what an FE should do after a lost association is dicated by the CE Failover policy (refer to Section 8 and Section 6.2). ---------- cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 10:35:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYLw-0001IO-M5 for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 10:35:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14479 for ; Wed, 14 Sep 2005 10:35:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFYQY-0003WR-Mo for forces-archive@IETF.ORG; Wed, 14 Sep 2005 10:39:59 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010EDACD@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 10:35:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85555487 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 10:35:09 -0400 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 10:35:09 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8EEZ6OI123196 for ; Wed, 14 Sep 2005 14:35:07 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8EEZ516146662 for ; Wed, 14 Sep 2005 16:35:05 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8EEZ5nU012781 for ; Wed, 14 Sep 2005 16:35:05 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8EEZ5Nj012775; Wed, 14 Sep 2005 16:35:05 +0200 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA48040; Wed, 14 Sep 2005 16:35:05 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id j8EEZ6OI123196 Approved-By: Robert Haas Message-ID: <43283519.1000905@zurich.ibm.com> Date: Wed, 14 Sep 2005 16:35:05 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126626769.6467.24.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Jamal, Jamal Hadi Salim wrote: >Ok, folks we need to close on this issue so we can progress on other >unresolved issues. >More below. > >On Tue, 2005-13-09 at 11:17 +0200, Avri Doria wrote: > =20 > >>On 12 sep 2005, at 16.45, Robert Haas wrote: >> >> >> =20 >> >>>- this can be achieved with HB messages, or any other PL message =20 >>>whenever they are exchanged. BTW, I think the HB piggy-backing was =20 >>>proposed by Evangelos Haleplidis some time ago. And the idea was a =20 >>>"virtual piggy-backing", i.e., nothing else but a normal PL message =20 >>>is exchanged. >>> =20 >>> >>if i understand this correctly, it means that the receiver has to =20 >>treat the PL message as if it were a HB and take the appropriate =20 >>actions, e.g. resetting timers. Does it do this with all PL messages =20 >>or just come? My question is wether this doesn't become more of a =20 >>burden then actually just having a specialized HB message going back =20 >>and forth. >> >> =20 >> We can make this an optional feature of the FE: if the CE wishes so, the=20 FE will refrain from sending HBs in case it is already sending other PL=20 messages. > >[...] > =20 > >How about this as a middle ground so we can close this: > >- the CE can instruct the FE to send its own heartbeats at defined >intervals. It should also define its dead interval. All these attributes >will reside in the FE Proto Object.=20 > >- The CE MUST be able to instruct the FE to send heartbeats. >- The CE MAY decide not to instruct the FE to send heartbeats and >instead drive them via ACKs. >- The FE MAY support sending heartbeats. Which means we need a >capability announcement to indicate the FE can do this via FE Protocol >Object. > =20 > By default, I suggest that the FE must send HBs, without the virtual=20 piggy-back feature. The CE can change this if the FE allows it: for=20 instance, enable HB piggy-backing, or simply turn off HBs. We should=20 decide these two features (HB piggybacking and turning off HB) should be=20 mandatory or optional features of the FE. I propose that they are mandato= ry. Regards, --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 11:44:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZR7-0002Dk-Bb for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 11:44:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17716 for ; Wed, 14 Sep 2005 11:44:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZVg-0005L5-2o for forces-archive@IETF.ORG; Wed, 14 Sep 2005 11:49:24 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010EDD0C@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 11:44:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85561906 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 11:44:31 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 11:44:28 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 15 Sep 2005 00:19:02 +0800 (CST) References: <1126635891.6467.31.camel@localhost.localdomain> <1126636084.6467.36.camel@localhost.localdomain> <00b401c5b8d1$ccf7e180$1152010a@Necom.hzic.edu.cn> <1126695817.6465.10.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <005d01c5b943$6fe679d0$1f12fea9@wwm1> Date: Wed, 14 Sep 2005 23:46:13 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: minor changes: introduction section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: base64 SmFtYWwsDQoNCkFzIEkgbWVudGlvbmVkLCBpdCdzIGEgdGlueSBxdWVzdGlvbi4gSSBjYW4gbGl2 ZSB3aXRoIGl0LCBlc3BlY2lhbGx5IGFmdGVyIHlvdXIgZXhwbGFpbmF0aW9uLiBXZSdkIGJldHRl ciBub3QgbWVudGlvbiAncmVxdWVzdC9yZXNwb25zZSBwcm90b2NvbCcsIEkgdGhpbmssIGZvciBj dXJyZW50IG1lc3NhZ2VzIGRvIG5vdCBzdHJpY3RseSBmb2xsb3cgaXQuDQoNClRoYW5rcywNCldl aW1pbmcNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSGFkaSBT YWxpbSIgPGhhZGlAem55eC5jb20+DQoNCj4gT24gV2VkLCAyMDA1LTE0LTA5IGF0IDEwOjEyICsw ODAwLCBXYW5nLFdlaW1pbmcgd3JvdGU6DQo+ID4gSmFtYWwsDQo+ID4gDQo+ID4gSSBhcHByZWNp YXRlIHlvdXIgcmV2aWV3LiANCj4gPiANCj4gPiBBIHRpbnkgcXVlc3Rpb24gaXMsIHdoeSB0aGUg c2VudGVuY2UgICAiVGhlIEZvckNFUyBwcm90b2NvbCBpcyBhIG1lc3NhZ2UgDQo+ID4gZXhjaGFu Z2UgcHJvdG9jb2wsIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBiZXR3ZWVuIEZFcyBhbmQgQ0VzIGlz IGFsd2F5cyBpbiANCj4gPiB0aGUgZm9ybSBvZiBwcm90b2NvbCBtZXNzYWdlcy4gIiBzaG91bGQg YmUgb21pdHRlZD8gZG8geW91IGhhdmUgc29tZSBtb3JlIA0KPiA+IGNvbnNpZGVyYXRpb24/IE15 IHRob3VnaHQgaXMgd2UgbWF5IG5lZWQgdG8gbm90aWZ5IHRoYXQgdGhlIHByb3RvY29sIGlzIGEg DQo+ID4gbWVzc2FnaW5nIHByb3RvY29sIHJhdGhlciB0aGFuIGEgaGVhZGVyIHByb3RvY29sIGxp a2UgVENQL0lQLiANCj4gPiANCj4gDQo+IFdlaW1pbmcsDQo+IEkgdGhvdWdodCB0aGUgZGVzY3Jp cHRpb24gd2FzIHJlZHVuZGFudCBmcm9tIGFuIGlldGYgcGVyc3BlY3RpdmUsIGkuZQ0KPiANCj4g LSBBIHByb3RvY29sIF9hbHJlYWR5XyBtZWFucyB0aGVyZSBpcyBtZXNzYWdlIGV4Y2hhbmdlIChh bGwgSUVURg0KPiBwcm90b2NvbHMgaGF2ZSBtZXNzYWdlIGV4Y2hhbmdlcykuDQo+IC0gbWVzc2Fn ZSBleGNoYW5nZSBfYWxyZWFkeV8gbWVhbnMgdGhlcmUgaXMgaW5mb3JtYXRpb24gZXhjaGFuZ2Uu DQo+IC0gInByb3RvY29sIG1lc3NhZ2VzIiBhbHNvIHJlcGVhdHMgdGhlIGFib3ZlIHR3byBwb2lu dHMuDQo+IA0KPiBUZXJtcyBsaWtlIFJlcXVlc3QvUmVzcG9uc2UgcHJvdG9jb2wgbWF5IGJlIG1v cmUgZml0dGluZyBleGNlcHQgd2UgaW4NCj4gYWRkaXRpb24gaGF2ZSBhc3luY2hyb25vdXMgZXZl bnRzLg0KPiANCj4gSWYgeW91IGZlZWwgc3Ryb25nbHkgaSBjb3VsZCBjaGFuZ2UgaXQgYmFjay4N Cj4gDQo+IE5vdGUsIGkgcmV2aWV3ZWQgdGhhdCB0ZXh0IGFzIHBhcnQgb2YgZ29pbmcgb3ZlciB0 aGUgZHJhZnQgZnJvbSB0aGUNCj4gYmVnaW5pbmcuDQo+IA0KPiBjaGVlcnMsDQo+IGphbWFs From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 11:57:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZdu-00050V-0c for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 11:57:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18573 for ; Wed, 14 Sep 2005 11:57:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZiX-0005mx-04 for forces-archive@IETF.ORG; Wed, 14 Sep 2005 12:02:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010EDE5A@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 11:50:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85563319 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 11:50:34 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 11:50:33 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 15 Sep 2005 00:25:08 +0800 (CST) References: <1126636374.14.0.100984003942.issue58@mip4.org> <00bc01c5b8d2$e90f1590$1152010a@Necom.hzic.edu.cn> <1126696154.6465.16.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <006b01c5b944$49fcdbf0$1f12fea9@wwm1> Date: Wed, 14 Sep 2005 23:52:19 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue58] small issues with definitions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0i IDxoYWRpQHpueXguY29tPg0KPiA+IDEuIExGQiBpbnN0YW5jZSBpcyBub3QgZGVmaW5lZA0KPiA+ IFtXZWltaW5nXSBZZXMsIHdlIG5lZWQgdGhpcywgYnV0IEkgaG9wZSBpdCBjYW4gYmUgZ2l2ZW4g Zmlyc3QgYnkgbW9kZWwgDQo+ID4gZHJhZnQsIHRoZW4gd2UgY29weSBpdCwgc28gYXMgdG8ga2Vl cCBiZXR0ZXIgY29uc2lzdGVuY3kuDQo+ID4gDQo+IA0KPiBJIGhhdmUgb3BlbmVkIGFuIGlzc3Vl IHRpY2tldCBvbiB0aGUgbW9kZWwgc28gdGhpcyBnZXRzIHJlc29sdmVkLg0KSSBhcHByZWNpYXRl IGl0IGlmIHlvdSBvciBKb2VsIGNhbiBzdWJtaXQgb25lIGFuZCB0aGlzIGlzc3VlIGNhbiBiZSBj bG9zZWQgYXQgb25jZS4NCj4gDQo+ID4gMi4gQXR0cmlidXRlIGlzIHRvbyBvdmVybG9hZGVkIHRo ZXNlIGRheXMuIFdoYXQgYWJvdXQgY2FwYWJpbGl0aWVzLCBldGM/DQo+ID4gDQo+ID4gMy4gU2hv dWxkIHdlIGp1c3QgaGF2ZSBhIHNlcGFyYXRlIGRvY3VtZW50IHRoYXQgY2FwdHVyZXMgaW4gb25l IHNwb3Q/DQo+ID4gDQo+ID4gNC4gIkZvcmNlcyBORSIgaW5zdGVhZCBvZiBqdXN0IHBsYWluICJO RSIgLSBzaGFsbCB3ZSBkbyBhIG1hc3MgZWRpdA0KPiA+IGZvciBjb25zaXN0ZW5jeT8gVGhlIEZF IGFuZCBDRSBhcmUgbm90IHJlZmVyZWQgdG8gYXMgRk9yQ0VTIENFL0ZFLg0KPiA+IFtXZWltaW5n XUkgdGhpbmsgIEZvckNFUyBORSBpcyBtb3JlIHJlbGF2YW50LCBmb3Igd2UgbWF5IGVhc2lseSB0 aGluayBvZiBvdGhlciANCj4gPiBORXMgaWYgbm90LiBGb3IgQ0UgYW5kIEZFLCBpdCBpcyBxdWl0 ZSBvYnZpb3VzIGl0IGlzIEZvckNFUyBDRS9GRS4gIEEgbWFzcyANCj4gPiBlZGl0aW5nIGlzIGdv b2QgZm9yIGNvbnNpc3RlbmN5IG9mIHRoaXMuIA0KPiA+IA0KPiANCj4gU291bmRzIHJlYXNvbmFi bGUgLSBidXQgd2hlbiBpIHdhcyByZWFkaW5nIGl0IHNvcnQgb2YgaXJyaXRhdGVkIG1lOyANCj4g Q2FuIHdlIHByb2JhYmx5IGp1c3Qgc2F5IGl0IG9uY2UgaW4gdGhlIGJlZ2dpbmluZyBhbG9uZyB0 aGUgbGluZXMgInRoaXMNCj4gZG9jdW1lbnQgd2lsbCByZWZlciB0byBhIEZvcmNlcyBORSBhcyBz aW1wbHkgTkUgYW5kIHdoZW4gYSBkaXN0aW5jdGlvbg0KPiBuZWVkcyB0byBiZSBtYWRlIHRoZSB0 ZXJtcyBGb3JjZXMgTkUgYW5kIG5vbi1Gb3JjZXMgTkUgd2lsbCBiZSB1c2VkIg0KVGhhdCdzIE9L IHRvIG1lLiBJdCdzIGp1c3QgYW4gZWRpdG9yaWFsIGFuZCBtaW5vciBjaGFuZ2UuIFBscyBqdXN0 IGdvIGFoZWFkLg0KDQpUaGFua3MsDQpXZWltaW5nDQog From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 12:09:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZpe-0007rN-BU for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 12:09:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19269 for ; Wed, 14 Sep 2005 12:09:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZuG-00067u-FQ for forces-archive@IETF.ORG; Wed, 14 Sep 2005 12:14:45 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010EDF54@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 12:09:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85567450 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 12:09:55 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 12:09:49 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 15 Sep 2005 00:44:15 +0800 (CST) References: <1126637064.6521.3.camel@localhost.localdomain> <00d601c5b8da$1d4d1760$1152010a@Necom.hzic.edu.cn> <1126697890.6465.30.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <007301c5b946$f5e2d4e0$1f12fea9@wwm1> Date: Thu, 15 Sep 2005 00:11:24 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: major changes: Protocol overview section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0i IDxoYWRpQHpueXguY29tPg0KPiA+IA0KPiA+IDMuMy4yLiAgRkUsIGFuZCBGRSBwcm90b2NvbCBM RkJzDQo+ID4gDQo+ID4gICAgQWxsIFBMIG1lc3NhZ2VzIG9wZXJhdGUgb24gTEZCIGNvbnN0cnVj dHMgYXMgdGhpcyBwcm92aWRlcyBtb3JlDQo+ID4gICAgZmxleGliaWxpdHkgZm9yIGZ1dHVyZSBl bmhhbmNlbWVudHMuICBUaGlzIG1lYW5zIHRoYXQgbWFpbnRlbmFuY2UgYW5kDQo+ID4gW1dlaW1p bmddIEknbSBub3Qgc3VyZSBpZiAgaXQgaXMgcHJvcGVyIHRvIHNheSAnQWxsIFBMIG1lc3NhZ2Un IGhlcmUsIA0KPiA+IGJlY2F1c2UgZm9yIHNvbWUgbWVzc2FnZXMgbGlrZSBIQiwgYXNzb2NpYXRp b24gdGVhcmRvd24gbWVzc2FnZXMsIGFsdGhvdWdoIA0KPiA+IHdlIG1heSBzYXkgdGhleSBhcmUg YWxzbyBhZGRyZXNzZWQgdG8gTEZCcywgIGF0IGxlYXN0LCBmcm9tIHRoZSBtZXNzYWdlIA0KPiA+ IGZvcm1hdCBwb2ludCBvZiB2aWV3LCB0aGV5IGFyZSBub3QuICANCj4gPiANCj4gDQo+IFRoZSBI QiBpcyB0aGUgY2xvc2VzdCBpdCBjb21lcyB0byBzb21lIG1lc3NhZ2UgdGhhdCBoYXMgbm8gTEZC LCBidXQgaW4NCj4gbXkgb3BpbmlvbiBpdCBkb2VzLiBFdmVuIHRob3VnaCB3ZSBkZWNpZGVkIHRv IGhhdmUgYSBzaG9ydGN1dCBmb3IgdGhlIEhCDQo+IGJ5IG5vdCBoYXZpbmcgYSBMRiBzZWxlY3Rv ciwgdGhlcmUgaXMgaW5mYWN0IGFuIExGQiAtIHRoZSBGRVBPIHRvIGJlDQo+IHByZWNpc2UgLSB0 aGF0IGlzIHVzZWQgdG8gY29uZmlndXJlIEhCIHBhcmFtZXRlcnMuDQo+IEkgYW0gdGhpbmtpbmcg aGFyZCBhbmQgaSBjYW50IHRoaW5rIG9mIGFueSBvdGhlciBtZXNzYWdlIHdoaWNoIGRvZXNudA0K PiBoYXZlIGFuIExGQiBhc3NvY2lhdGVkIHdpdGggaXQuDQo+IEJ1dCBpZiB5b3UgY291bGQgbWVu dGlvbiBvbmUsIEkgd2lsbCBnbyBiYWNrIGFuZCBtYWtlIGNoYW5nZXMuDQpJIGFncmVlIHlvdXIg ZGVzY3JpcHRpb24gYWJvdmUsIEknbSBqdXN0IGEgbGl0dGxlIHdvcnJ5IHRoYXQgYmVjYXVzZSB3 ZSBjdXJyZW50bHkgZG8gbm90IHVzZSBMRkIgc2VsZWN0b3JzIGZvciBhbGwgbWVzc2FnZXMsIHRo ZXJlZm9yZSwgaXQgbWF5IG1ha2UgcmVhZGVycyBhIGxpdHRsZSBjb25mdXNlZCB3aGVuIHJlYWRp bmcgdGhlIGZvbGxvd2VkIG1lc3NhZ2UgZGVmaW5pdGlvbnMuIE1heSBJIHN1Z2dlc3QgdG8gYWRk IHNvbWUgd29yZHMgdG8gbWVudGlvbiB0aGF0ICJBbGwgUEwgbWVzc2FnZXMgb3BlcmF0ZSBvbiBM RkIgY29uc3RydWN0cy4uLiwgKGV2ZW4gdGhvdWdoIHNvbWUgUEwgbWVzc2FnZXMgbWF5IG9taXQg dGhlIExGQiBzZWxlY3Rpb24gaW4gdGhlIG1lc3NhZ2UgUERVIGJlY2F1c2UgdGhlIExGQiBpcyB1 bmlxdWUgZm9yIHRoZSBtZXNzYWdlLiIgIA0KDQo+ID4gICAgVG8gYWNoaWV2ZSB0aGlzLCB0aGUg Zm9sbG93aW5nIHNwZWFjaWxpemVkIExGQnMgYXJlIGludHJvZHVjZWQ6DQo+ID4gDQo+ID4gICAg byAgRkUgUHJvdG9jb2wgTEZCDQo+ID4gDQo+ID4gICAgbyAgRkUgT2JqZWN0IExGQg0KPiA+IA0K PiA+ICAgIFRoZXNlIExGQnMgYXJlIGRldGFpbGVkIGluIFNlY3Rpb24gNi4yLiAgDQo+ID4gW1dl aW1pbmddIEkgdGhpbmsgaXQgbWF5IGxvb2sgYmV0dGVyIGZvciAgdGhlIG92ZXJhbGwgZHJhZnQg aWYgd2Ugc3RvcCB0aGlzIA0KPiA+IHNlY3Rpb24gaGVyZSwgb3IgcHV0IHRoZSBmb2xsb3dpbmcg IHRleHQgaW4gU2VjdGlvbiA2LjIgaWYgbmVjZXNzYXJ5LiANCj4gPiANCj4gDQo+IERpZCB5b3Ug bWVhbiBub3QgdG8gZ2l2ZSB0aGUgc2hvcnQgZGVzY3JpcHRpb24gYmVsb3cgZm9yIHRoZSB0d28g TEZCcw0KPiB3aGVuIHlvdSBzYXkgdG8gInRvIHN0b3AgdGhpcyBzZWN0aW9uIGhlcmUiPw0KU3Vy ZS4NCj4gDQo+ID4gICAgQSBzaG9ydCBkZXNjcmlwdGlvbiBpcyAgcHJvdmlkZWQgaGVyZToNCj4g PiANCj4gPiAgICBvICBUaGUgRkUgUHJvdG9jb2wgTEZCIGlzIGEgbG9naWNhbCBlbnRpdHkgaW4g ZWFjaCBGRSB0aGF0IGlzIHVzZWQgdG8NCj4gPiAgICAgICBjb250cm9sIHRoZSBGb3JDRVMgcHJv dG9jb2wuICBUaGUgQ0Ugb3BlcmF0ZXMgb24gdGhpcyBMRkIgdG8NCj4gPiAgICAgICBzdWJzY3Jp YmUgb3IgdW5zdWJzY3JpYmUgdG8gSGVhcnRiZWF0IG1lc3NhZ2VzLCBkZWZpbmUgdGhlDQo+ID4g ICAgICAgSGVhcnRiZWF0IGludGVydmFsLCBvciB0byBkaXNjb3ZlciB3aGljaCBGb3JDRVMgcHJv dG9jb2wgdmVyc2lvbg0KPiA+ICAgICAgIGlzIHN1cHBvcnRlZCBhbmQgd2hpY2ggVE1McyB0aGUg RkUgc3VwcG9ydHMuICBUaGUgRkUgUHJvdG9jb2wgTEZCDQo+ID4gICAgICAgYWxzbyBjb250YWlu cyB0aGUgdmFyaW91cyBGb3JDRVMgSUQgdG8gYmUgdXNlZDogdW5pY2FzdCBJRHMgYQ0KPiA+ICAg ICAgIHRhYmxlIG9mIHRoZSBQTCBtdWx0aWNhc3QgSURzIHRoZSBGRSBtdXN0IGJlIGxpc3Rlbmlu ZyB0by4NCj4gPiANCj4gPiAgICBvICBUaGUgRkUgTEZCIChyZWZlcnJlZCB0byBhcyAiRkUgYXR0 cmlidXRlcyIgaW4gdGhlIG1vZGVsIGRyYWZ0KQ0KPiA+ICAgICAgIHNob3VsZCBub3QgYmUgY29u ZnVzZWQgd2l0aCB0aGUgRkUgUHJvdG9jb2wgT2JqZWN0LiAgVGhlIEZFIExGQiBpcw0KPiA+ICAg ICAgIGEgbG9naWNhbCBlbnRpdHkgaW4gZWFjaCBGRSBhbmQgY29udGFpbnMgYXR0cmlidXRlcyBy ZWxhdGl2ZSB0bw0KPiA+ICAgICAgIHRoZSBGRSBpdHNlbGYsIGFuZCBub3QgdG8gdGhlIG9wZXJh dGlvbiBvZiB0aGUgRm9yQ0VTIHByb3RvY29sDQo+ID4gICAgICAgYmV0d2VlbiB0aGUgQ0UgYW5k IHRoZSBGRS4gIFN1Y2ggYXR0cmlidXRlcyBjYW4gYmUgRkVTdGF0ZSAocmVmZXINCj4gPiAgICAg ICB0byBtb2RlbCBkcmFmdCksIHZlbmRvciwgZXRjLiAgVGhlIEZFIExGQiBjb250YWlucyBpbiBw YXJ0aWN1bGFyIGENCj4gPiAgICAgICB0YWJsZSB0aGF0IG1hcHMgYSB2aXJ0dWFsIExGQiBJbnN0 YW5jZSBJRCB0byBvbmUgb3IgbW9yZSBJbnN0YW5jZQ0KPiA+ICAgICAgIElEcyBvZiBMRkJzIGlu IHRoZSBGRS4NCj4gPiBbV2VpbWluZ10gdGhlICdGRSBMRkInIG5hbWUgaXMgbm90IGEgY29uc2lz dGVudCBuYW1lLg0KPiANCj4gR29vZCBjYXRjaCAtIGluZmFjdCBpIHRoaW5rIHNvbWUgb2YgdGhl IGRlc2NyaXB0aW9uIHdhcyB2YWxpZCBhIHdoaWxlDQo+IGJhY2ssIG5vIGxvbmdlciB0cnVlIHNp bmNlIHdlIGhhdmUgZm9ybWFsaXplZCB0aGVzZSB0d28gTEZCcy4gDQo+IFRvIGFkZHJlc3MgKGlm IGkgdW5kZXJzdG9vZCB5b3UpIHlvdXIgZWFybGllciBwb2ludCwgSSBoYXZlIGNoYW5nZWQgdGhl DQo+IHRleHQgdG86DQo+IA0KPiAtLS0tLS0tDQo+IDMuMy4yLiAgRkUgT2JqZWN0IGFuZCBGRSBw cm90b2NvbCBMRkJzDQo+IA0KPiAgICBBbGwgUEwgbWVzc2FnZXMgb3BlcmF0ZSBvbiBMRkIgY29u c3RydWN0cyBhcyB0aGlzIHByb3ZpZGVzIG1vcmUNCj4gICAgZmxleGliaWxpdHkgZm9yIGZ1dHVy ZSBlbmhhbmNlbWVudHMuICBUaGlzIG1lYW5zIHRoYXQgbWFpbnRlbmFuY2UgYW5kDQo+ICAgIGNv bmZpZ3VyYWJpbGl0eSBvZiBGRXMsIE5FLCBhcyB3ZWxsIGFzIHRoZSBGb3JDRVMgcHJvdG9jb2wg aXRzZWxmDQo+ICAgIG11c3QgYmUgZXhwcmVzc2VkIGluIHRlcm1zIG9mIHRoaXMgTEZCIGFyY2hp dGVjdHVyZS4gIEZvciB0aGlzIHJlYXNvbg0KPiAgICBzcGVjaWFsIExGQnMgYXJlIGNyZWF0ZWQg dG8gYWNjb21vZGF0ZSB0aGlzIG5lZWQuDQo+IA0KPiAgICBJbiBhZGRpdGlvbiwgdGhpcyBzaG93 cyBob3cgdGhlIEZvckNFUyBwcm90b2NvbCBpdHNlbGYgY2FuIGJlDQo+ICAgIGNvbnRyb2xsZWQg YnkgdGhlIHZlcnkgc2FtZSB0eXBlIG9mIHN0cnVjdHVyZXMgKExGQnMpIGl0IHVzZXMgdG8NCj4g ICAgY29udHJvbCBmdW5jdGlvbnMgc3VjaCBhcyBJUCBmb3J3YXJkaW5nLCBmaWx0ZXJpbmcsIGV0 Yy4NCj4gDQo+ICAgIFRvIGFjaGlldmUgdGhpcywgdGhlIGZvbGxvd2luZyBzcGVhY2lsaXplZCBM RkJzIGFyZSBpbnRyb2R1Y2VkOg0KPiANCj4gICAgbyAgRkUgUHJvdG9jb2wgTEZCIHdoaWNoIGlz IHVzZWQgdG8gY29udHJvbCB0aGUgRm9yQ0VTIHByb3RvY29sLg0KPiANCj4gICAgbyAgRkUgT2Jq ZWN0IExGQiB3aGljaCBpcyB1c2VkIHRvIGNvbnRyb2xzIGF0dHJpYnV0ZXMgcmVsYXRpdmUgdG8g dGhlDQo+ICAgICAgIEZFIGl0c2VsZi4gIFN1Y2ggYXR0cmlidXRlcyBpbmNsdWRlIEZFU3RhdGUg KHJlZmVyIHRvIG1vZGVsDQo+ICAgICAgIGRyYWZ0KSwgdmVuZG9yLCBldGMuDQo+IA0KPiAgICBU aGVzZSBMRkJzIGFyZSBkZXRhaWxlZCBpbiBTZWN0aW9uIDYuMi4NClRoYXQgbG9va3MgbmljZSB0 byBtZS4gVGhhbmtzLg0KPiA+IA0KPiA+ICAgIG8gIFtFZGl0b3JpYWwgbm90ZTogdGhlIHRlcm0g IkZFIGF0dHJpYnV0ZXMiIGlzIG1vcmUgdGVjaG5pY2FsIHRoYW4NCj4gPiAgICAgICBpbXBsaWVk IGFib3ZlLiAgV2Ugbm93IHVzZSBpdCB0byBkZWZpbmUgYSBzdWJzZWN0aW9uIG9mIHRoZSBMRkIN Cj4gPiAgICAgICBlbGVtZW50cywgZGlzY3Vzc10uDQo+ID4gW1dlaW1pbmddIEFnYWluLCBJIGhp Z2hseSBzdWdnZXN0IHRvIHB1dCBhYm92ZSBwYXJhZ3JhcGggaW4gU2VjdGlvbiA2LjIgdG8gDQo+ ID4gZWFzZSB0aGUgY29uc2lzdGVuY3kgbWFuYWdlbWVudC4NCj4gDQo+IEkgaGF2ZSByZW1vdmVk IHRoYXQgdGV4dCBzaW5jZSBpdCB3YXMgaW50ZW5kZWQgdG8gaGlnaGxpZ2h0IHRoYXQgdGV4dCB0 bw0KPiBwb2ludCB0byBhIGRyYWZ0LWdsb2JhbCBpc3N1ZS4gVGhpcyBpc3N1ZSBpcyBub3cgY2Fw dHVyZWQgaW4gaXNzdWUgIzU4Lg0KDQp0aGFua3MsDQpXZWltaW5nDQo= From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 12:32:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFaBj-0006JE-D8 for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 12:32:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20135 for ; Wed, 14 Sep 2005 12:32:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFaGL-0006gv-SD for forces-archive@IETF.ORG; Wed, 14 Sep 2005 12:37:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010EDF24@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 12:32:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85569359 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 12:32:44 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 12:32:43 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 15 Sep 2005 01:07:14 +0800 (CST) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <00b101c5b94a$2bce5c70$1f12fea9@wwm1> Date: Thu, 15 Sep 2005 00:34:24 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.2 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: base64 Um9iZXJ0IGFuZCBKYW1hbCwNCg0KSmFtYWwsIG5vdCBzdXJlIHdoeSB5b3VyIHBvc3Qgb2YgdGhp cyBkaWQgbm90IHNob3cgb24gdGhlIGxpc3QuIA0KDQpJIHN0aWxsIGNhbiBub3Qgc2VlIHRoZSBt dWNoIHZhbHVlIHRvIGhhdmUgQ0UgYmUgYWx3YXlzIGFjdGl2ZSBmb3IgSEJzIGV2ZW4gZnJvbSBG RS4gSSd2IGFscmVhZHkgc3VtbWFyaXplZCB0aGUgc2hvcnRzIGZvciB0aGlzIGFzOg0KDQoxLiBJ dCBtYWtlcyBDRSBoYXZlIHRvIG1hbmFnZSB0aW1lIGludGVydmFscyBmb3IgZXZlbiBodW5kcmVk cyBvZiBGRXMuIEFsdGhvdWdoIEphbWFsIG1lbnRpb25lZCB0aGF0IHRoZXJlIGlzIGEgZ29vZCBh bGdvcml0aG0gZm9yIHN1Y2ggbWFuYWdlbWVudCB0byBtYWtlIG9uZSB0aW1lciBmb3IgYWxsIHN1 Y2ggaW50ZXJ2YWwgbm90aWZpY2F0aW9uLCBJIGp1c3QgdGhpbmsgZXZlbiBhIGxvZyBmb3Igc28g bWFueSBGRXMgaXMgYSBiaWcgZXh0cmEgYnVyZGVuIGZvciBDRSwgd2hpY2ggSSB0aGluayBjYW4g YmUgcmVtb3ZlZCBhbmQgZGlzdHJpYnV0ZWQgdG8gaW5kaXZpZHVhbCBGRXMuDQoNCjIuIEl0IG1h a2VzIHVzIGhhdmUgdG8gZGVmaW5lIG9uZSBtb3JlIG1lc3NhZ2UgLSB0aGUgSEIgcmVzcG9uc2Ug bWVzc2FnZSwgdGhvdWdoIGl0IG1heSBub3QgYmUgbXVjaCBkaWZmaWN1bHQuDQoNCjMuIEFDSyBv biBhbmQgb2ZmIGlzIGFsc28gYW4gZXh0cmEgd29yayBmb3IgY3VzdG9tZXIgdG8gdXNlLCB3aGlj aCBjYW4gYWxzbyBiZSByZW1vdmVkLg0KDQpPbiB0aGUgb3RoZXJoYW5kLCBJIGNhbiBzZWUgdGhl IG9ubHkgYmVuaWZpdCBiZSB0aGF0IG1heSBicmluZyBpcyBpdCBtYXkgbWFrZSBDRSBtb3JlIGxp a2UgYSBtYXN0ZXIuDQoNCkphbWFsLCBjYW4geW91IHByZXNlbnQgc29tZSBtb3JlIGJlbmlmaXRz IHNvIHRoYXQgd2UgY2FuIHNlZSB0aGUgdmFsdWUgbW9yZT8NCg0KVGhhbmtzLA0KV2VpbWluZw0K DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlJvYmVydCBIYWFzIiA8cmhh QHp1cmljaC5pYm0uY29tPg0KVG86IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQpTZW50 OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNCwgMjAwNSAxMDozNSBQTQ0KU3ViamVjdDogUmU6IENs b3N1cmUgbmVlZGVkIHBsZWFzZSBjb21tZW50IFdBUyhSZTogU2VjdGlvbiA5OiBIZWFydGJlYXQg TWVzc2FnZXMNCltXZWltaW5nXSANCj4+Pg0KPj5pZiBpIHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0 bHksIGl0IG1lYW5zIHRoYXQgdGhlIHJlY2VpdmVyIGhhcyB0byAgDQo+PnRyZWF0IHRoZSBQTCBt ZXNzYWdlIGFzIGlmIGl0IHdlcmUgYSBIQiBhbmQgdGFrZSB0aGUgYXBwcm9wcmlhdGUgIA0KPj5h Y3Rpb25zLCBlLmcuIHJlc2V0dGluZyB0aW1lcnMuICBEb2VzIGl0IGRvIHRoaXMgd2l0aCBhbGwg UEwgbWVzc2FnZXMgIA0KPj5vciBqdXN0IGNvbWU/ICBNeSBxdWVzdGlvbiBpcyB3ZXRoZXIgdGhp cyBkb2Vzbid0IGJlY29tZSBtb3JlIG9mIGEgIA0KPj5idXJkZW4gdGhlbiBhY3R1YWxseSBqdXN0 IGhhdmluZyBhIHNwZWNpYWxpemVkIEhCIG1lc3NhZ2UgZ29pbmcgYmFjayAgDQo+PmFuZCBmb3J0 aC4NCj4+DQo+PiAgICANCj4+DQpXZSBjYW4gbWFrZSB0aGlzIGFuIG9wdGlvbmFsIGZlYXR1cmUg b2YgdGhlIEZFOiBpZiB0aGUgQ0Ugd2lzaGVzIHNvLCB0aGUgDQpGRSB3aWxsIHJlZnJhaW4gZnJv bSBzZW5kaW5nIEhCcyBpbiBjYXNlIGl0IGlzIGFscmVhZHkgc2VuZGluZyBvdGhlciBQTCANCm1l c3NhZ2VzLg0KDQo+DQo+Wy4uLl0NCj4gIA0KPg0KPkhvdyBhYm91dCB0aGlzIGFzIGEgbWlkZGxl IGdyb3VuZCBzbyB3ZSBjYW4gY2xvc2UgdGhpczoNCj4NCj4tIHRoZSBDRSBjYW4gaW5zdHJ1Y3Qg dGhlIEZFIHRvIHNlbmQgaXRzIG93biBoZWFydGJlYXRzIGF0IGRlZmluZWQNCj5pbnRlcnZhbHMu IEl0IHNob3VsZCBhbHNvIGRlZmluZSBpdHMgZGVhZCBpbnRlcnZhbC4gQWxsIHRoZXNlIGF0dHJp YnV0ZXMNCj53aWxsIHJlc2lkZSBpbiB0aGUgRkUgUHJvdG8gT2JqZWN0LiANCj4NCj4tIFRoZSBD RSBNVVNUIGJlIGFibGUgdG8gaW5zdHJ1Y3QgdGhlIEZFIHRvIHNlbmQgaGVhcnRiZWF0cy4NCj4t IFRoZSBDRSBNQVkgZGVjaWRlIG5vdCB0byBpbnN0cnVjdCB0aGUgRkUgdG8gc2VuZCBoZWFydGJl YXRzIGFuZA0KPmluc3RlYWQgZHJpdmUgdGhlbSB2aWEgQUNLcy4NCj4tIFRoZSBGRSBNQVkgc3Vw cG9ydCBzZW5kaW5nIGhlYXJ0YmVhdHMuIFdoaWNoIG1lYW5zIHdlIG5lZWQgYQ0KPmNhcGFiaWxp dHkgYW5ub3VuY2VtZW50IHRvIGluZGljYXRlIHRoZSBGRSBjYW4gZG8gdGhpcyB2aWEgRkUgUHJv dG9jb2wNCj5PYmplY3QuDQo+ICANCj4NCkJ5IGRlZmF1bHQsIEkgc3VnZ2VzdCB0aGF0IHRoZSBG RSBtdXN0IHNlbmQgSEJzLCB3aXRob3V0IHRoZSB2aXJ0dWFsIA0KcGlnZ3ktYmFjayBmZWF0dXJl LiBUaGUgQ0UgY2FuIGNoYW5nZSB0aGlzIGlmIHRoZSBGRSBhbGxvd3MgaXQ6IGZvciANCmluc3Rh bmNlLCBlbmFibGUgSEIgcGlnZ3ktYmFja2luZywgb3Igc2ltcGx5IHR1cm4gb2ZmIEhCcy4gV2Ug c2hvdWxkIA0KZGVjaWRlIHRoZXNlIHR3byBmZWF0dXJlcyAoSEIgcGlnZ3liYWNraW5nIGFuZCB0 dXJuaW5nIG9mZiBIQikgc2hvdWxkIGJlIA0KbWFuZGF0b3J5IG9yIG9wdGlvbmFsIGZlYXR1cmVz IG9mIHRoZSBGRS4gSSBwcm9wb3NlIHRoYXQgdGhleSBhcmUgbWFuZGF0b3J5Lg0KDQpSZWdhcmRz LA0KDQotLSANCkRyLiBSb2JlcnQgUi4gSGFhcw0K From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 12:47:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFaPc-0002fb-3Z for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 12:47:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21095 for ; Wed, 14 Sep 2005 12:47:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFaUE-0007CA-Pd for forces-archive@IETF.ORG; Wed, 14 Sep 2005 12:51:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010EE05F@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 12:47:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85570438 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 12:47:04 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 12:47:04 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8EG1mXK096586 for ; Wed, 14 Sep 2005 09:01:49 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126716422.7551.10.camel@localhost.localdomain> Date: Wed, 14 Sep 2005 12:47:02 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <43283519.1000905@zurich.ibm.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit On Wed, 2005-14-09 at 16:35 +0200, Robert Haas wrote: > By default, I suggest that the FE must send HBs, without the virtual > piggy-back feature. The CE can change this if the FE allows it: for > instance, enable HB piggy-backing, or simply turn off HBs. We should > decide these two features (HB piggybacking and turning off HB) should be > mandatory or optional features of the FE. I propose that they are mandatory. > The above would be fine with me. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 13:01:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFad4-0005Z8-GM for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 13:01:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21553 for ; Wed, 14 Sep 2005 13:00:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFahg-0007VQ-84 for forces-archive@IETF.ORG; Wed, 14 Sep 2005 13:05:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010EE057@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 13:00:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85571667 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 13:00:58 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 13:00:55 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8EGFPXK096736; Wed, 14 Sep 2005 09:15:25 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126717233.7551.25.camel@localhost.localdomain> Date: Wed, 14 Sep 2005 13:00:33 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00b101c5b94a$2bce5c70$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit On Thu, 2005-15-09 at 00:34 +0800, Weiming Wang wrote: > Robert and Jamal, > > Jamal, not sure why your post of this did not show on the list. > Hrm, that is strange. I saw it echo back and it seems at least Robert saw it as well. This is one of the reason i always CC the person who sent the email. > I still can not see the much value to have CE be always active for > HBs even from FE. I'v already summarized the shorts for this as: > > 1. It makes CE have to manage time intervals for even hundreds of > FEs. Although Jamal mentioned that there is a good algorithm for > such management to make one timer for all such interval notification, > I just think even a log for so many FEs is a big extra burden for CE, > which I think can be removed and distributed to individual FEs. > On the scaling issues in this particular case, I am going to disagree: The piggybacking scheme allows HBs to be a function of how busy the connection is between CE-FE. HB will be sent more only when the system is idle. Note, however: I am not proposing disallowing HB from the FE to CE - my suggestion is to make that an option; if the NE setup is to do it that way it should still work. > 2. It makes us have to define one more message - the HB response > message, though it may not be much difficult. > Why do you need a new message? A HB with an ACK is responded to with a HB with no ACK > 3. ACK on and off is also an extra work for customer to use, which > can also be removed. > There should be no ACK configuration. The behavior in general may be configured with a default of some sort. i.e the default could be to have the FE send HBs if it can do that. If it cant do that, then they are driven by CE etc. > On the otherhand, I can see the only benifit be that may bring is > it may make CE more like a master. > Yes, that is beneficial - but probably not strong enough on its own. I claim that the major benefit is simplifying the FE side. > Jamal, can you present some more benifits so that we can see the > value more? see above. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 14 16:49:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeCR-00053T-6n for forces-archive@megatron.ietf.org; Wed, 14 Sep 2005 16:49:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10665 for ; Wed, 14 Sep 2005 16:49:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFeH4-0007n4-O2 for forces-archive@IETF.ORG; Wed, 14 Sep 2005 16:54:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010EE467@cherry.ease.lsoft.com>; Wed, 14 Sep 2005 16:49:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85596356 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Sep 2005 16:49:43 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Sep 2005 16:49:42 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8EKnf9C030083 for ; Wed, 14 Sep 2005 20:49:41 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8EKnVwC003203 for ; Wed, 14 Sep 2005 20:49:41 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005091413494108944 for ; Wed, 14 Sep 2005 13:49:41 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 13:49:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5B96D.D421630C" Thread-Topic: conference call info for this week (protocol draft) Thread-Index: AcW5bdPdszBdGWpfReCRsorYXm2kRg== X-OriginalArrivalTime: 14 Sep 2005 20:49:41.0528 (UTC) FILETIME=[D45BB180:01C5B96D] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06AC36F9@orsmsx408> Date: Wed, 14 Sep 2005 13:49:40 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: conference call info for this week (protocol draft) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5B96D.D421630C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks =20 The protocol design team has been having regular conference calls to discuss protocol issues, etc. Now that the draft is pretty mature we would be happy to have any others folks interested in giving us feedback to join in. =20 Here is the conference calls info for this week... =20 Thursday, September 15, 2005 7:00 AM US Pacific Time (1 hr) Where: 916-356-2663, Bridge: 1, Passcode: 8106647 Friday, September 16, 2005 7:00 AM US Pacific Time (1 hr) Where: 916-356-2663, Bridge: 2, Passcode: 7999353 =20 BTW, this mailing list is also prefectly reasonable place to give us any feedback on the draft, regards Hormuzd ------_=_NextPart_001_01C5B96D.D421630C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks
 
The = protocol design=20 team has been having regular conference calls to discuss protocol = issues,=20 etc.
Now = that the draft=20 is pretty mature we would be happy to have any others folks interested=20 in giving us feedback to join in.
 

Here is the conference calls info for = this=20 week...

 

Thursday, September 15, 2005 7:00 = AM US Pacific=20 Time (1 hr)

Where: 916-356-2663, Bridge: 1, Passcode: = 8106647

Friday, September 16, 2005 7:00 AM = US Pacific=20 Time (1 hr)

Where: 916-356-2663, Bridge: 2, Passcode: = 7999353

 

BTW, = this mailing list=20 is also prefectly reasonable place to give us any feedback on the=20 draft,

regards
Hormuzd
------_=_NextPart_001_01C5B96D.D421630C-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 15 09:59:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFuGf-0007IN-8r for forces-archive@megatron.ietf.org; Thu, 15 Sep 2005 09:59:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11796 for ; Thu, 15 Sep 2005 09:59:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFuLP-0001kR-T4 for forces-archive@IETF.ORG; Thu, 15 Sep 2005 10:04:12 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010EF0AF@cherry.ease.lsoft.com>; Thu, 15 Sep 2005 9:59:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85647039 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 15 Sep 2005 09:59:07 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Sep 2005 09:59:06 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8FDDcXK006963 for ; Thu, 15 Sep 2005 06:13:39 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E06AC36F9@orsmsx408> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126792744.6516.5.camel@localhost.localdomain> Date: Thu, 15 Sep 2005 09:59:04 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: conference call info for this week (protocol draft) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E06AC36F9@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Should have posted sooner, but here goes.. Agenda Items for today: 1) Section 3 a) Should we get rid of the transactional 2pc? b) if not: i) decision on the sanity of the mechanisms ii) Go over t he text to agree on the flags or new message types > 2) Heartbeats Resolution cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 15 16:31:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG0OB-0004Ij-GT for forces-archive@megatron.ietf.org; Thu, 15 Sep 2005 16:31:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08855 for ; Thu, 15 Sep 2005 16:31:20 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG0T2-0005wr-Qx for forces-archive@IETF.ORG; Thu, 15 Sep 2005 16:36:25 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010EF61A@cherry.ease.lsoft.com>; Thu, 15 Sep 2005 16:31:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85672488 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 15 Sep 2005 16:31:17 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Sep 2005 16:31:16 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8FJjhXK010706 for ; Thu, 15 Sep 2005 12:45:44 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-hb3lJy9dntH5IPZSJh5Q" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1126816273.6516.18.camel@localhost.localdomain> Date: Thu, 15 Sep 2005 16:31:13 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: updated section 3 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e02509f7a15c0aaea12155beed3396f0 --=-hb3lJy9dntH5IPZSJh5Q Content-Type: text/plain Content-Transfer-Encoding: 7bit Attached an updated section 3. Ive added a sentence that was used by Robert in the concal to reason for 2pc. Ive changed the names of the flags to be reflective. I have also added a reference to the origins of 2pc. Additionaly there is now a sentence or two to suggest how to use correlators to keep track of transactions. If you can please read the whole thing and critique and lets come to closure in tommorow's concal. With that said, in relation to the current header flags as promised on the concal: - I don't see the need for the two BATCH bits we have anymore, but require 4 bits instead for the following flags involved: AT == Atomic Transaction flag to signal an atomic all-or-none transaction (1 bit). This already exists today and is called the atomicity flag in the draft. We need another bit to signal the 2 other modes: {execute-until-failure, continue-execute-on-failure}. Unfortunately we have 3 modes and 2 bits - we may have to say 00 is none of the above. SOT == Start of Transaction - to signal the first configuration message in a transaction EOT == End of Transaction - to signal the end of transaction ala commit ABT = Abort Transaction - to signal to the FE to abort a specific transaction. cheers, jamal --=-hb3lJy9dntH5IPZSJh5Q Content-Disposition: attachment; filename=sec3.txt Content-Type: text/plain; name=sec3.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 3. Overview The reader is referred to the Framework document [RFC3746], and in particular sections 3 and 4, for an architectural overview and an explanation of how the ForCES protocol fits in. There may be some content overlap between the framework document and this section in order to provide clarity. 3.1. Protocol Framework Figure 1 below is reproduced from the Framework document for clarity. It shows a NE with two CEs and two FEs. --------------------------------------- | ForCES Network Element | -------------- Fc | -------------- -------------- | | CE Manager |---------+-| CE 1 |------| CE 2 | | -------------- | | | Fr | | | | | -------------- -------------- | | Fl | | | Fp / | | | Fp| |----------| / | | | | |/ | | | | | | | | | Fp /|----| | | | | /--------/ | | -------------- Ff | -------------- -------------- | | FE Manager |---------+-| FE 1 | Fi | FE 2 | | -------------- | | |------| | | | -------------- -------------- | | | | | | | | | | | ----+--+--+--+----------+--+--+--+----- | | | | | | | | | | | | | | | | Fi/f Fi/f Fp: CE-FE interface Fi: FE-FE interface Fr: CE-CE interface Fc: Interface between the CE Manager and a CE Ff: Interface between the FE Manager and an FE Fl: Interface between the CE Manager and the FE Manager Fi/f: FE external interface Figure 1: ForCES Architectural Diagram The ForCES protocol domain is found in the Fp Reference Point. The Protocol Element configuration reference points, Fc and Ff also play a role in the booting up of the Forces Protocol. The protocol Doria (Ed.), et al. Expires February 2, 2006 [Page 9] Internet-Draft ForCES August 2005 element configuration is out of scope of the ForCES protocol but is touched on in this document since it is an integral part of the protocol pre-association phase. Figure 2 below shows further breakdown of the Fp interface by example of a MPLS QoS enabled Network Element. ------------------------------------------------- | | | | | | | |OSPF |RIP |BGP |RSVP |LDP |. . . | | | | | | | | ------------------------------------------------- | ForCES Interface | ------------------------------------------------- ^ ^ | | ForCES | |data control | |packets messages| |(e.g., routing packets) | | v v ------------------------------------------------- | ForCES Interface | ------------------------------------------------- | | | | | | | |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | | | | | |fier | | ------------------------------------------------- Figure 2: Examples of CE and FE functions The ForCES Interface shown in Figure 2 constitutes two pieces: the PL and TML layer. Doria (Ed.), et al. Expires February 2, 2006 [Page 10] Internet-Draft ForCES August 2005 This is depicted in Figure 3 below. +------------------------------------------------ | CE PL layer | +------------------------------------------------ | CE TML layer | +------------------------------------------------ ^ | ForCES | (i.e Forces data + control PL | packets ) messages | over | specific | TML | encaps | and | transport | | v +------------------------------------------------ | FE TML layer | +------------------------------------------------ | FE PL layer | +------------------------------------------------ Figure 3: ForCES Interface The PL layer is in fact the ForCES protocol. Its semantics and message layout are defined in this document. The TML Layer is necessary to connect two ForCES PL layers as shown in Figure 3 above. The TML is out of scope for this document but is within scope of ForCES. This document defines requirements the PL needs the TML to meet. Both the PL and the TML layers are standardized by the IETF. While only one PL layer is defined, different TMLs are expected to be standardized. To interoperate the TML layer at the CE and FE are expected to conform to the same definition. On transmit, the PL layer delivers its messages to the TML layer. The TML layer delivers the message to the destination TML layer(s). On receive, the TML delivers the message to its destination PL layer(s). 3.1.1. The PL layer The PL is common to all implementations of ForCES and is standardized Doria (Ed.), et al. Expires February 2, 2006 [Page 11] Internet-Draft ForCES August 2005 by the IETF as defined in this document. The PL layer is responsible for associating an FE or CE to an NE. It is also responsible for tearing down such associations. An FE uses the PL layer to throw various subscribed-to events to the CE PL layer as well as respond to various status requests issued from the CE PL. The CE configures both the FE and associated LFB'ss operational parameters using the PL layer. In addition the CE may send various requests to the FE to activate or deactivate it, reconfigure its HA parametrization, subscribe to specific events etc. More details in Section 6. 3.1.2. The TML layer The TML layer is essentially responsible for transport of the PL layer messages. The TML is where the issues of how to achieve transport level reliability, congestion control, multicast, ordering, etc are handled. It is expected more than one TML will be standardized. The different TMLs each could implement things differently based on capabilities of underlying media and transport. However, since each TML is standardized, interoperability is guaranteed as long as both endpoints support the same TML. All ForCES Protocol Layer implementations should be portable across all TMLs, because all TMLs have the same top edge semantics as defined in this document. 3.1.3. The FEM/CEM Interface The FEM and CEM components, although valuable in the setup and configurations of both the PL and TML layers, are out of scope of the ForCES protocol. The best way to think of them are as configurations/parameterizations for the PL and TML before they become active (or even at runtime based on implementation). In the simplest case, the FE or CE read a static configuration file. RFC 3746 has a lot more detailed descriptions on how the FEM and CEM could be used. We discuss the pre-association phase where the CEM and FEM play briefly in section Section 3.2.1. An example of typical things FEM/CEM would configure would be TML specific parameterizations such as: a. how the TML connection should happen (example what IP addresses to use, transport modes etc); b. the ID for the FE or CE would also be issued at this point. c. Security parameterization such as keys etc. d. Connection association parameters Doria (Ed.), et al. Expires February 2, 2006 [Page 12] Internet-Draft ForCES August 2005 Example "send up to 3 association messages each 1 second apart" Vs " send up to 4 association messages with increasing exponential timeout". 3.2. ForCES Protocol Phases ForCES, in relation to NEs, involves two phases: the Pre-Association phase where configuration/initialization/bootup of the TML and PL layer happens, and the association phase where the ForCES protocol operates to manipulate the parameters of the FEs. 3.2.1. Pre-association The ForCES interface is configured during the pre-association phase. In a simple setup, the configuration is static and is read from a saved config file. All the parameters for the association phase are well known after the pre-association phase is complete. A protocol such as DHCP may be used to retrieve the config parameters instead of reading them from a static config file. Note, this will still be considered static pre-association. Dynamic configuration may also happen using the Fc, Ff and Fl reference points. Vendors may use their own proprietary service discovery protocol to pass the parameters. Essentially only guidelines are provided here and the details are left to the implementation. The following are scenarios reproduced from the Framework Document to show a pre-association example. <----Ff ref pt---> <--Fc ref pt-------> FE Manager FE CE Manager CE | | | | | | | | (security exchange) (security exchange) 1|<------------>| authentication 1|<----------->|authentication | | | | (FE ID, attributes) (CE ID, attributes) 2|<-------------| request 2|<------------|request | | | | 3|------------->| response 3|------------>|response (corresponding CE ID) (corresponding FE ID) | | | | | | | | Figure 4: Examples of a message exchange over the Ff and Fc reference points Doria (Ed.), et al. Expires February 2, 2006 [Page 13] Internet-Draft ForCES August 2005 <-----------Fl ref pt--------------> | FE Manager FE CE Manager CE | | | | | | | | (security exchange) | | 1|<------------------------------>| | | | | | (a list of CEs and their attributes) | 2|<-------------------------------| | | | | | (a list of FEs and their attributes) | 3|------------------------------->| | | | | | | | | | Figure 5: An example of a message exchange over the Fl reference point Before the transition to the association phase, the FEM will have established contact with the appropriate CEM component. Initialization of the ForCES interface will have completed, and authentication as well as capability discovery may be complete. Both the FE and CE would have the necessary information for connecting to each other for configuration, accounting, identification and authentication purposes. To summarize, at the completion of this stage both sides have all the necessary protocol parameters such as timers, etc. The Fl reference point may continue to operate during the association phase and may be used to force a disassociation of an FE or CE. Because the pre-association phase is out of scope, these details are not discussed any further in this specification. The reader is referred to the framework document [RFC3746] for a slightly more detailed discussion. 3.2.2. Post-association In this phase, the FE and CE components communicate with each other using the ForCES protocol (PL over TML) as defined in this document. There are three sub-phases: o Association Setup state o Established State o Association Lost state. Doria (Ed.), et al. Expires February 2, 2006 [Page 14] Internet-Draft ForCES August 2005 3.2.2.1. Association Setup state The FE attempts to join the NE. The FE may be rejected or accepted. Once granted access into the NE, capabilities exchange happens with the CE querying the FE. Once the CE has the FE capability information, the CE can offer an initial configuration (possibly to restore state) and can query certain attributes within either an LFB or the FE itself. More details are provided in the protocol scenarios section. On successful completion of this state, the FE joins the NE and is moved to the Established State. 3.2.2.2. Association Established state In this state the FE is continuously updated or queried. The FE may also send asynchronous event notifications to the CE or synchronous heartbeat notifications if programmed to do so. This continues until a termination occurs because of loss of connectivity or is initiated by either the CE or the FE. Refer to section on protocol scenarios Section 7 for more details. 3.2.2.3. Association Lost state In this state, both or either the CE or FE declare the other side is no longer associated. The disconnection could be physically initiated by either party for administrative purposes but may also be driven by operation reasons such as loss of connectivity. When an association is lost between a CE and FE, the FE continues to operate as instructed by the CE via the CE failover policy (for further discussion refer to Section 8 and Appendix C). Editorial note: Do we need A state machine to show transitions For this revision of the protocol (as defined in this document), the FE, upon re-association, MUST declare all the state it has as invalid and retrieve new state. This approach is motivated by a desire for simplicity (as opposed to efficiency). 3.3. Protocol Mechanisms Various semantics are exposed to the protocol users via the PL header including: Transaction capabilities, atomicity of transactions, two phase commits, batching/parallelization, High Availability and failover as well as command windows. Doria (Ed.), et al. Expires February 2, 2006 [Page 15] Internet-Draft ForCES August 2005 3.3.1. Transactions, Atomicity, Execution and Responses In the master-slave relationship the CE instructs one or more FEs on how to execute operations and how to report back the results. This section details the different modes of execution that a CE can order the FE(s) to perform in Section 3.3.1.1. It also describes the different modes a CE can ask the FE(s) to format the responses back after processing the operations requested. 3.3.1.1. Execution There are 3 execution modes that could be requested for a batch of operations spanning on one or more LFB selectors: a. Transactional execute-all-or-none b. Loose transactional execute-until-failure c. Non-transactional continue-execute-on-failure 3.3.1.1.1. 'all-or-none' Atomic transaction A transaction maybe atomic: a. Within an FE alone Example: updating multiple tables which are dependent on each other. If updating one fails, then any others already updated must be undone. b. Distributed across the NE Example: updating table(s) that are inter-dependent across several FEs (such as L3 forwarding related tables). For distributed transactional consistency across FEs, a classical transactional protocol known as Two Phase Commit [2PCREF] is supported. 3.3.1.1.2. Transaction Definition We define a transaction as a collection of one or more ForCES operations within one or more PL messages that MUST meet the ACIDity properties[ACID], defined as: o *Atomicity*. In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are. Doria (Ed.), et al. Expires February 2, 2006 [Page 16] Internet-Draft ForCES August 2005 o *Consistency*. A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started. o *Isolation*. A transaction in process and not yet committed must remain isolated from any other transaction. o *Durability*. Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state. There are cases where the CE knows exact memory and implementation details of the FE such as in the case of a FE-CE pair from the same vendor where the FE-CE pair is tightly coupled. In such a case, the transactional operations maybe simplified further by extra computation at the CE. We do not discuss this view further other than to mention it is not dissallowed. For the purpose of interopability, we define a classical transactional protocol known as two phase commit which meets the ACID properties to be used for transactions. 3.3.1.1.3. Transaction protocol A 2PC [2PCREF] configuration message starts with the header flags containg a SOT(start of transaction) and AT (Atomic Transaction) on its first message configuration message. A transaction may span multiple messages. It is up to the CE to keep track of the different outstanding messages making up a transaction. As an example, one could use the correlator field to mark transactions and a sequence field to label the different messages within the same atomic transaction. Any failure notified by the FE causes the CE to execute an ABT (Abort Transaction) to all FEs involved in the transaction, rolling back all previously executed operations in the transaction. [Editorial Note: We need to discuss how to issue the ABORT - flags vs type] The transaction commitment phase is signalled from the CE to the FE by an empty EOT configuration message. The FE MUST respond to the CE's EOT message. If no response is received from the CE within a specified timeout, the transaction MUST be aborted by the CE. Doria (Ed.), et al. Expires February 2, 2006 [Page 17] Internet-Draft ForCES August 2005 3.3.1.1.4. Recovery Any of the participating FEs, or the CE, or the associations between them, may fail after the EOT response message has left the FE and before it has received all the responses, (possibly the EOT response never reached the CE). In this protocol revision, for sake of simplicity as indicated in Section 3.2.2.3, an FE losing an association would be required to get new state from the newly associated CE from scratch upon a reassociation. The decision on what an FE should do after a lost association is dicated by the CE Failover policy (refer to Section 8 and Section 6.2). 3.3.1.1.5. continue-execute-on-failure In which several independent operations are targeted at one or more LFB selectors. Execution continues at the FE when one or more operations fail. This mode is signalled by a missing AT flag. 3.3.1.1.6. execute-until-failure In which all operations are executed on FE sequentially until first failure. The rest of the operations are not executed but everything up to failed is not undone unlike the case of all-or-none execution. Editorial note we need an extra main header flag to signal this . EUF for lack of a better name. 3.3.1.1.7. Relation to Multipart messages Multipart flags apply. I.e all messages in a transaction except for the last have a MULTIPART flag on. Multi-part messages MUST be consistent in their use of execution modes. If the first message starts with one mode (such as continue- execute-on-failure mode), then it implies the rest that are part of the same multi-part messages do. Any inconsitency implies an error and a cancelled transaction in which all messages are dropped and the sender NACKED. 3.3.2. FE Object and FE protocol LFBs All PL messages operate on LFB constructs as this provides more flexibility for future enhancements. This means that maintenance and configurability of FEs, NE, as well as the ForCES protocol itself must be expressed in terms of this LFB architecture. For this reason special LFBs are created to accomodate this need. Doria (Ed.), et al. Expires February 2, 2006 [Page 18] Internet-Draft ForCES August 2005 In addition, this shows how the ForCES protocol itself can be controlled by the very same type of structures (LFBs) it uses to control functions such as IP forwarding, filtering, etc. To achieve this, the following speacilized LFBs are introduced: o FE Protocol LFB which is used to control the ForCES protocol. o FE Object LFB which is used to controls attributes relative to the FE itself. Such attributes include FEState (refer to model draft), vendor, etc. These LFBs are detailed in Section 6.2. 3.3.3. Scaling by Concurrency It is desirable that the PL layer not become the bottleneck when larger bandwidth pipes become available. To pick a mythical example in today's terms, if a 100Gbps pipe is available and there is sufficient work then the PL layer should be able to take advantage of this and use all of the 100Gbps pipe. Two mechanisms are provided to achieve this. The first one is batching and the second one is a command window. Batching is the ability to send multiple commands (such as Config) in one PDU. The size of the batch will be affected by, amongst other things, the path MTU. The commands may be part of the same transaction or part of unrelated transactions that are independent of each other. Command windowing allows for pipelining of independent transactions which do not affect each other. Each independent transaction could consist of one or more batches. 3.3.3.1. Batching There are several batching levels at different protocol hierarchies. o multiple PL PDUs can be aggregated under one TML message o multiple LFB classes and instances (as indicated in the LFB selector) can be addressed within one PL PDU o Multiple operations can be addressed to a single LFB class and instance Doria (Ed.), et al. Expires February 2, 2006 [Page 19] Internet-Draft ForCES August 2005 3.3.3.2. Command Pipelining The protocol allows any number of messages to be issued by the CE before the corresponding acknowledgments (if requested) have been returned by the FE. Hence pipelining is inherently supported by the protocol. Matching responses with requests messages can be done using the correlator field in the message header. Doria (Ed.), et al. Expires February 2, 2006 [Page 20] Internet-Draft ForCES August 2005 --=-hb3lJy9dntH5IPZSJh5Q-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 15 19:02:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG2kn-0001r2-Na for forces-archive@megatron.ietf.org; Thu, 15 Sep 2005 19:02:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16917 for ; Thu, 15 Sep 2005 19:02:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG2pd-0001QC-3z for forces-archive@IETF.ORG; Thu, 15 Sep 2005 19:07:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010F0006@cherry.ease.lsoft.com>; Thu, 15 Sep 2005 19:02:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85684949 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 15 Sep 2005 19:02:47 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Sep 2005 19:02:47 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8FN2k9i002674; Thu, 15 Sep 2005 23:02:46 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8FN2V7p005382; Thu, 15 Sep 2005 23:02:46 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005091516024608495 ; Thu, 15 Sep 2005 16:02:46 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 16:02:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] minor changes: introduction section Thread-Index: AcW4kOcbcUyeRho0S6a5XEgC8UXxBABuKqig X-OriginalArrivalTime: 15 Sep 2005 23:02:46.0193 (UTC) FILETIME=[9600A210:01C5BA49] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06B3656B@orsmsx408> Date: Thu, 15 Sep 2005 16:02:45 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: minor changes: introduction section Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Sounds good to me.=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Tuesday, September 13, 2005 11:28 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] minor changes: introduction section Please ignore previous attachment and use this instead. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 15 19:33:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG3EO-0003Zd-6N for forces-archive@megatron.ietf.org; Thu, 15 Sep 2005 19:33:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18662 for ; Thu, 15 Sep 2005 19:33:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG3JF-0002I5-UP for forces-archive@IETF.ORG; Thu, 15 Sep 2005 19:38:32 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010EFF22@cherry.ease.lsoft.com>; Thu, 15 Sep 2005 19:33:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85686346 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 15 Sep 2005 19:33:13 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Sep 2005 19:33:13 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8FNXC1q031196; Thu, 15 Sep 2005 23:33:12 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8FNWM8O028627; Thu, 15 Sep 2005 23:33:12 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005091516331213674 ; Thu, 15 Sep 2005 16:33:12 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 16:33:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] updated section 3 Thread-Index: AcW6NHOav2TIEnzXRMmz4eso3eUdgQAGRKZg X-OriginalArrivalTime: 15 Sep 2005 23:33:11.0857 (UTC) FILETIME=[D62EDA10:01C5BA4D] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06B365FE@orsmsx408> Date: Thu, 15 Sep 2005 16:33:11 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: updated section 3 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Jamal, This sounds reasonable to me. Lets discuss tomorrow on the concall and if there are no issues, we can close this. You will need to update the Header section (5.1) accordingly with the new flags. I agree we don't need the batch flags any more, we have all the functionality needed with the new flags below. Thanks Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Thursday, September 15, 2005 1:31 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] updated section 3 Attached an updated section 3. Ive added a sentence that was used by Robert in the concal to reason for 2pc. Ive changed the names of the flags to be reflective. I have also added a reference to the origins of 2pc. Additionaly there is now a sentence or two to suggest how to use correlators to keep track of transactions. If you can please read the whole thing and critique and lets come to closure in tommorow's concal. With that said, in relation to the current header flags as promised on the concal: - I don't see the need for the two BATCH bits we have anymore, but require 4 bits instead for the following flags involved: AT =3D=3D Atomic Transaction flag to signal an atomic all-or-none transaction (1 bit). This already exists today and is called the atomicity flag in the draft. We need another bit to signal the 2 other modes: {execute-until-failure, continue-execute-on-failure}. Unfortunately we have 3 modes and 2 bits - we may have to say 00 is none of the above. SOT =3D=3D Start of Transaction - to signal the first configuration = message in a transaction EOT =3D=3D End of Transaction - to signal the end of transaction ala = commit ABT =3D Abort Transaction - to signal to the FE to abort a specific transaction. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 15 20:23:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG40p-0008AX-7C for forces-archive@megatron.ietf.org; Thu, 15 Sep 2005 20:23:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20529 for ; Thu, 15 Sep 2005 20:23:29 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG45j-0003Od-C8 for forces-archive@IETF.ORG; Thu, 15 Sep 2005 20:28:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010EFFFE@cherry.ease.lsoft.com>; Thu, 15 Sep 2005 20:23:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85688363 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 15 Sep 2005 20:23:29 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Sep 2005 20:23:28 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8G0NSqS003886 for ; Fri, 16 Sep 2005 00:23:28 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8G0MS84000331 for ; Fri, 16 Sep 2005 00:23:28 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005091517170015827 for ; Thu, 15 Sep 2005 17:17:01 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 17:16:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BA53.F3858D12" Thread-Topic: Clarification needed with Event subscribe/unsubscribe Thread-Index: AcW6U/NBI29wbJFhT22kJFwqp9AQhQ== X-OriginalArrivalTime: 16 Sep 2005 00:16:58.0341 (UTC) FILETIME=[F3B08150:01C5BA53] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06B366C5@orsmsx408> Date: Thu, 15 Sep 2005 17:16:57 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Clarification needed with Event subscribe/unsubscribe To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BA53.F3858D12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One small thing that I found missing in the draft was text for event subscribe/unsubscribe. =20 We need to add some clarifying text in section 6 as to how this is currently support by the protocol/model. I noticed we removed the Operations for this from Config msg, so this should be part of the fe model now, I guess. =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C5BA53.F3858D12 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
One = small thing that=20 I found missing in the draft was text for event=20 subscribe/unsubscribe.
 
We = need to add some=20 clarifying text in section 6 as to how this is currently support by the=20 protocol/model.
I = noticed we removed=20 the Operations for this from Config msg, so this should be part of the = fe model=20 now, I guess.
 
Thanks
Hormuzd
 
------_=_NextPart_001_01C5BA53.F3858D12-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 00:09:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG7XN-0004Iv-KF for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 00:09:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08725 for ; Fri, 16 Sep 2005 00:09:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG7c7-0008OK-Rm for forces-archive@IETF.ORG; Fri, 16 Sep 2005 00:14:27 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010F0350@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 0:09:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85701251 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 00:09:02 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 00:03:24 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Fri, 16 Sep 2005 12:38:10 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Fri, 16 Sep 2005 12:02:55 +0800 References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> Date: Fri, 16 Sep 2005 12:02:30 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 4.0 (++++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: base64 SGksIA0KDQpIZXJlIGlzIHRoZSB0ZXh0IHByb3Bvc2VkIGZvciB0aGUgSEIuIFBscyBjb21tZW50 cy4NCg0KRm9yIEZFIGNhcGFiaWxpdHkgZm9yIGhlYXJ0YmVhdHM6DQoNCjxvcmlnaW5hbD4NCiBv ICBGRSBQcm90b2NvbCBjYXBhYmlsaXRpZXMgKHJlYWQtb25seSk6DQoNCiAgICAgICogIFN1cHBv cnRlZCBGb3JDRVMgcHJvdG9jb2wgdmVyc2lvbihzKSBieSB0aGUgRkUNCg0KICAgICAgKiAgU3Vw cG9ydGVkIEZvckNFUyBGRSBtb2RlbChzKSBieSB0aGUgRkUNCg0KICAgICAgKiAgU29tZSBUTUwg Y2FwYWJpbGl0eSBkZXNjcmlwdGlvbihzKQ0KPC9vcmlnaW5hbD4NCg0KPGNoYW5nZXRvPg0KIG8g IEZFIFByb3RvY29sIGNhcGFiaWxpdGllcyAocmVhZC1vbmx5KToNCg0KICAgICAgKiAgU3VwcG9y dGVkIEZvckNFUyBwcm90b2NvbCB2ZXJzaW9uKHMpIGJ5IHRoZSBGRQ0KDQogICAgICAqICBTdXBw b3J0ZWQgRm9yQ0VTIEZFIG1vZGVsKHMpIGJ5IHRoZSBGRQ0KDQogICAgICAqICBTb21lIFRNTCBj YXBhYmlsaXR5IGRlc2NyaXB0aW9uKHMpDQogICAgDQogICAgICAqICBGRSBjYXBhYmlsaXR5IHRv IGdlbmVyYXRlIEhlYXRiZWF0czogQ2FwYWJsZSBvciBJbmNhcGFibGUuIA0KPC9jaGFuZ2V0bz4N Cg0KRm9yIEZFIGF0dHJpYnV0ZXMgZm9yIGhlYXJ0YmVhdHM6DQoNCjxvcmlnaW5hbCBQLjQyPg0K RkUgUHJvdG9jb2wgYXR0cmlidXRlcyAoY2FuIGJlIHJlYWQgYW5kIHNldCk6DQouLi4NCiAgICAg ICogIEhlYXJ0YmVhdCBJbnRlcnZhbC4gIERlZnVhbHQgVmFsdWUgPSAzMDAgbXNlYw0KPC9vcmln aW5hbCBQLjQyPg0KDQo8Y2hhbmdlIHRvPg0KRkUgUHJvdG9jb2wgYXR0cmlidXRlcyAoY2FuIGJl IHJlYWQgYW5kIHNldCk6DQouLi4NCiAgICAgICogSGVhcnRiZWF0IHBvbGljeSBhbmQgcGFyYW1l dGVycywgd2hpY2ggaW5jbHVkZXMgZmllbGRzIGFzOg0KDQogICAgICAgIC4gSGVhcnRiZWF0IHBv bGljeSwgd2hpY2ggZnVydGhlciBpbmNsdWRlcyB0d28gZmllbGRzOg0KDQogICAgICAgICAgIENF IGhlYXJ0YmVhdCBwb2xpY3k6IHRvIHRlbGwgRkUgd2hpY2ggaGVhcnRiZWF0IHBvbGljeSB0aGUg Q0UgY2hvb3Nlcy4NCg0KICAgICAgICAgICAgMCAtIENFIG5vIGhlYXJ0YmVhdC4gSW4gdGhpcyBj YXNlLCBDRSBkb2VzIG5vdCBzZW5kIGFueSBIZWFydGJlYXQgbWVzc2FnZXMgdG8gRkUuIA0KICAg ICAgICAgICAgMSAtIENFIG5vcm1hbCBoZWFydGJlYXQuIEluIHRoaXMgY2FzZSwgQ0Ugc2VuZHMg SGVhcnRiZWF0IG1lc3NhZ2VzIHRvIEZFIGF0IHRoZSB0aW1lIGludGVydmFscyBzcGVjaWZpZWQg YnkgdGhlIENFIGhlYXJ0ZWJlYXQgaW50ZXJ2YWwgcGFyYW1ldGVyIGFzIGJlbG93Lg0KICAgICAg ICAgICAgMiAtIENFIHBpZ2d5LWJhY2tpbmcgaGVhcnRiZWF0LiBJbiB0aGlzIGNhc2UsIENFIHNl bmRzIEhlYXJ0YmVhdCBtZXNzYWdlcyB0byBGRSBvbmx5IHdoZW4gQ0UgcmVhY2hlcyB0aGUgdGlt ZSBpbnRlcnZhbCB3aXRoIG5vIG90aGVyIG1lc3NhZ2UgdG8gYmUgc2VudCBpbiB0aGUgaW50ZXJ2 YWwuDQogICAgICAgICAgICAzIC0gQ0UgcGlnZ3ktYmFja2luZyBoZWFydGJlYXQgd2l0aCBGRSBo ZWFydGJlYXQgcmVxdWVzdC4gSW4gdGhpcyBjYXNlLCBiZXNpZGVzIENFIHNlbmRzIHBpZ2d5LWJh Y2tpbmcgaGVhcnRiZWF0LCBDRSBhbHNvIHNlbmRzIEhlYXJ0YmVhdCByZXF1ZXN0IG1lc3NhZ2Ug KGFsc28gYSBub3JtYWwgSEIgbWVzc2FnZSwgb25seSB3aG9zZSBBQ0sgZmxhZyBiZWluZyBzZXQg dG8gQWx3YXlzQUNLKSB0byBGRSB3aGVuIENFIGhhcyBub3QgcmVjZWl2ZWQgYW55IG1lc3NhZ2Ug ZnJvbSBGRSBmb3IgdGhlIGludGVydmFsIHBlcmlvZC4gV2hlbiB0aGlzIENFIGhlYXJ0YmVhdCBw b2xpY3kgaXMgY2hvb3NlbiwgdGhlIEZFIGhlYXJ0YmVhdCBwb2xpY3kgYmVsb3cgc2hvdWxkIGJl IHNldCB0byAnRkUgbm8gaGVhcnRiZWF0Jy4NCg0KICAgICAgICAgICBGRSBoZWFydGJlYXQgcG9s aWN5OiB0byBjb21tYW5kIHRoZSBGRSB0byB1c2UgdGhlIGhlYXJ0YmVhdCBwb2xpY3kuDQoNCiAg ICAgICAgICAgIDAgLSBGRSBubyBoZWFydGJlYXQuIA0KICAgICAgICAgICAgMSAtIEZFIG5vcm1h bCBoZWFydGJlYXQuDQogICAgICAgICAgICAyIC0gRkUgcGlnZ3ktYmFja2luZyBoZWFydGJlYXQu IEluIHRoaXMgY2FzZSwgRkUgc2VuZHMgaGVhcnRiZWF0IG1lc3NhZ2VzIHRvIEZFIG9ubHkgd2hl biBpdCByZWFjaGVzIHRoZSB0aW1lIGludGVydmFsIG9mIG5vIG1lc3NhZ2Ugc2VuZGluZy4NCg0K DQogICAgICAgIC4gQ0UgaGVhcnRiZWF0IGludGVydmFsLCB0byB0ZWxsIEZFIHRoZSBoZWFydGJl YXQgaW50ZXJ2YWwgQ0UgdXNlcy4gaWYgbm90IHNldCBvciBzZXQgdG8gMCwgaXQgbWVhbnMgQ0Ug Y2hvb3NlcyBhIGRlZmF1bHQgdmFsdWUsIHdoaWNoIGlzIDMwMG1zZWMNCg0KICAgICAgICAuIEZF IGhlYXJ0YmVhdCBpbnRlcnZhbCwgdG8gY29tbWFuZCBGRSB0byB1c2UgdGhlIGludGVydmFsIGZv ciB0aGUgRkUgaGVhcnRiZWF0LiBJZiBub3Qgc2V0IG9yIHNldCB0byAwLCBpdCBtZWFucyBGRSBt dXN0IGNob29zZSB0aGUgZGVmYXVsdCB2YWx1ZSwgd2hpY2ggaXMgMzAwbXNlYw0KDQo8L2NoYW5n ZSB0bz4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhh ZGkgU2FsaW0iIDxoYWRpQHpueXguY29tPg0KVG86IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5D T00+DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDE1LCAyMDA1IDE6MDAgQU0NClN1YmplY3Q6 IFJlOiBDbG9zdXJlIG5lZWRlZCBwbGVhc2UgY29tbWVudCBXQVMoUmU6IFNlY3Rpb24gOTogSGVh cnRiZWF0IE1lc3NhZ2VzDQoNCg0KPiBPbiBUaHUsIDIwMDUtMTUtMDkgYXQgMDA6MzQgKzA4MDAs IFdlaW1pbmcgV2FuZyB3cm90ZToNCj4gPiBSb2JlcnQgYW5kIEphbWFsLA0KPiA+IA0KPiA+IEph bWFsLCBub3Qgc3VyZSB3aHkgeW91ciBwb3N0IG9mIHRoaXMgZGlkIG5vdCBzaG93IG9uIHRoZSBs aXN0LiANCj4gPiANCj4gDQo+IEhybSwgdGhhdCBpcyBzdHJhbmdlLiBJIHNhdyBpdCBlY2hvIGJh Y2sgYW5kIGl0IHNlZW1zIGF0IGxlYXN0IFJvYmVydA0KPiBzYXcgaXQgYXMgd2VsbC4gVGhpcyBp cyBvbmUgb2YgdGhlIHJlYXNvbiBpIGFsd2F5cyBDQyB0aGUgcGVyc29uIHdobw0KPiBzZW50IHRo ZSBlbWFpbC4NCj4gDQo+ID4gSSBzdGlsbCBjYW4gbm90IHNlZSB0aGUgbXVjaCB2YWx1ZSB0byBo YXZlIENFIGJlIGFsd2F5cyBhY3RpdmUgZm9yDQo+ID4gIEhCcyBldmVuIGZyb20gRkUuIEkndiBh bHJlYWR5IHN1bW1hcml6ZWQgdGhlIHNob3J0cyBmb3IgdGhpcyBhczoNCj4gPiANCj4gPiAxLiBJ dCBtYWtlcyBDRSBoYXZlIHRvIG1hbmFnZSB0aW1lIGludGVydmFscyBmb3IgZXZlbiBodW5kcmVk cyBvZiANCj4gPiBGRXMuIEFsdGhvdWdoIEphbWFsIG1lbnRpb25lZCB0aGF0IHRoZXJlIGlzIGEg Z29vZCBhbGdvcml0aG0gZm9yIA0KPiA+IHN1Y2ggbWFuYWdlbWVudCB0byBtYWtlIG9uZSB0aW1l ciBmb3IgYWxsIHN1Y2ggaW50ZXJ2YWwgbm90aWZpY2F0aW9uLCANCj4gPiBJIGp1c3QgdGhpbmsg ZXZlbiBhIGxvZyBmb3Igc28gbWFueSBGRXMgaXMgYSBiaWcgZXh0cmEgYnVyZGVuIGZvciBDRSwg DQo+ID4gd2hpY2ggSSB0aGluayBjYW4gYmUgcmVtb3ZlZCBhbmQgZGlzdHJpYnV0ZWQgdG8gaW5k aXZpZHVhbCBGRXMuDQo+ID4gDQo+IA0KPiBPbiB0aGUgc2NhbGluZyBpc3N1ZXMgaW4gdGhpcyBw YXJ0aWN1bGFyIGNhc2UsIEkgYW0gZ29pbmcgdG8gZGlzYWdyZWU6DQo+IFRoZSBwaWdneWJhY2tp bmcgc2NoZW1lIGFsbG93cyBIQnMgdG8gYmUgYSBmdW5jdGlvbiBvZiBob3cgYnVzeSB0aGUNCj4g Y29ubmVjdGlvbiBpcyBiZXR3ZWVuIENFLUZFLiBIQiB3aWxsIGJlIHNlbnQgbW9yZSBvbmx5IHdo ZW4gdGhlIHN5c3RlbQ0KPiBpcyBpZGxlLiBOb3RlLCBob3dldmVyOg0KPiANCj4gSSBhbSBub3Qg cHJvcG9zaW5nIGRpc2FsbG93aW5nIEhCIGZyb20gdGhlIEZFIHRvIENFIC0gbXkgc3VnZ2VzdGlv biBpcw0KPiB0byBtYWtlIHRoYXQgYW4gb3B0aW9uOyBpZiB0aGUgTkUgc2V0dXAgaXMgdG8gZG8g aXQgdGhhdCB3YXkgaXQgc2hvdWxkDQo+IHN0aWxsIHdvcmsuDQo+IA0KPiA+IDIuIEl0IG1ha2Vz IHVzIGhhdmUgdG8gZGVmaW5lIG9uZSBtb3JlIG1lc3NhZ2UgLSB0aGUgSEIgcmVzcG9uc2UgDQo+ ID4gbWVzc2FnZSwgdGhvdWdoIGl0IG1heSBub3QgYmUgbXVjaCBkaWZmaWN1bHQuDQo+ID4gDQo+ IA0KPiBXaHkgZG8geW91IG5lZWQgYSBuZXcgbWVzc2FnZT8NCj4gQSBIQiB3aXRoIGFuIEFDSyBp cyByZXNwb25kZWQgdG8gd2l0aCBhIEhCIHdpdGggbm8gQUNLDQo+IA0KPiA+IDMuIEFDSyBvbiBh bmQgb2ZmIGlzIGFsc28gYW4gZXh0cmEgd29yayBmb3IgY3VzdG9tZXIgdG8gdXNlLCB3aGljaCAN Cj4gPiBjYW4gYWxzbyBiZSByZW1vdmVkLg0KPiA+IA0KPiANCj4gVGhlcmUgc2hvdWxkIGJlIG5v IEFDSyBjb25maWd1cmF0aW9uLiBUaGUgYmVoYXZpb3IgaW4gZ2VuZXJhbCBtYXkgYmUNCj4gY29u ZmlndXJlZCB3aXRoIGEgZGVmYXVsdCBvZiBzb21lIHNvcnQuIGkuZSB0aGUgZGVmYXVsdCBjb3Vs ZCBiZSB0byBoYXZlDQo+IHRoZSBGRSBzZW5kIEhCcyBpZiBpdCBjYW4gZG8gdGhhdC4gSWYgaXQg Y2FudCBkbyB0aGF0LCB0aGVuIHRoZXkgYXJlDQo+IGRyaXZlbiBieSBDRSBldGMuDQo+IA0KPiA+ IE9uIHRoZSBvdGhlcmhhbmQsIEkgY2FuIHNlZSB0aGUgb25seSBiZW5pZml0IGJlIHRoYXQgbWF5 IGJyaW5nIGlzIA0KPiA+IGl0IG1heSBtYWtlIENFIG1vcmUgbGlrZSBhIG1hc3Rlci4NCj4gPiAN Cj4gDQo+IFllcywgdGhhdCBpcyBiZW5lZmljaWFsIC0gYnV0IHByb2JhYmx5IG5vdCBzdHJvbmcg ZW5vdWdoIG9uIGl0cyBvd24uDQo+IEkgY2xhaW0gdGhhdCB0aGUgbWFqb3IgYmVuZWZpdCBpcyBz aW1wbGlmeWluZyB0aGUgRkUgc2lkZS4NCj4gDQo+ID4gSmFtYWwsIGNhbiB5b3UgcHJlc2VudCBz b21lIG1vcmUgYmVuaWZpdHMgc28gdGhhdCB3ZSBjYW4gc2VlIHRoZSANCj4gPiB2YWx1ZSBtb3Jl Pw0KPiANCj4gc2VlIGFib3ZlLg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA== From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 08:22:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGFEx-0005wQ-Kq for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 08:22:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13460 for ; Fri, 16 Sep 2005 08:22:49 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGFJx-0004Sb-5S for forces-archive@IETF.ORG; Fri, 16 Sep 2005 08:28:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010F0815@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 8:22:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85725411 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 08:22:48 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 08:22:47 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id j8GC6kHC010310 for ; Fri, 16 Sep 2005 14:06:46 +0200 Mime-Version: 1.0 (Apple Message framework v734) References: <468F3FDA28AA87429AD807992E22D07E06B365FE@orsmsx408> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Approved-By: Avri Doria Message-ID: <78CDE67E-0FC7-4162-A1DE-384F067DDF05@psg.com> Date: Fri, 16 Sep 2005 14:22:44 +0200 Reply-To: Avri Doria Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: updated section 3 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E06B365FE@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Hi, And I will need to update the IANA section with any new flags we add. a. On 16 sep 2005, at 01.33, Khosravi, Hormuzd M wrote: > Jamal, > > This sounds reasonable to me. Lets discuss tomorrow on the concall and > if there are no issues, we can close this. You will need to update the > Header section (5.1) accordingly with the new flags. I agree we don't > need the batch flags any more, we have all the functionality needed > with > the new flags below. > > Thanks > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Thursday, September 15, 2005 1:31 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] updated section 3 > > > Attached an updated section 3. Ive added a sentence that was used by > Robert in the concal to reason for 2pc. Ive changed the names of the > flags to be reflective. I have also added a reference to the > origins of > 2pc. Additionaly there is now a sentence or two to suggest how to use > correlators to keep track of transactions. > If you can please read the whole thing and critique and lets come to > closure in tommorow's concal. > > With that said, in relation to the current header flags as promised on > the concal: > > - I don't see the need for the two BATCH bits we have anymore, but > require 4 bits instead for the following flags involved: > > AT == Atomic Transaction flag to signal an atomic all-or-none > transaction (1 bit). > This already exists today and is called the atomicity flag in the > draft. > We need another bit to signal the 2 other modes: > {execute-until-failure, continue-execute-on-failure}. Unfortunately we > have 3 modes and 2 bits - we may have to say 00 is none of the above. > > SOT == Start of Transaction - to signal the first configuration > message > in a transaction > > EOT == End of Transaction - to signal the end of transaction ala > commit > > ABT = Abort Transaction - to signal to the FE to abort a specific > transaction. > > cheers, > jamal > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 08:26:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGFIK-0006R7-Tt for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 08:26:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13566 for ; Fri, 16 Sep 2005 08:26:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGFNL-0004Xv-Av for forces-archive@IETF.ORG; Fri, 16 Sep 2005 08:31:31 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010F0737@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 8:26:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85725528 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 08:26:14 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 08:26:13 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id j8GC9jHC010313; Fri, 16 Sep 2005 14:09:45 +0200 References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Approved-By: Avri Doria Message-ID: Date: Fri, 16 Sep 2005 14:25:42 +0200 Reply-To: Avri Doria Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: 7bit Hi, I think it is essentially fine except that i think calling it piggy back is misleading, i.e. sounds like there is a HB included in the message. I would recommend implicit or something like that. a. On 16 sep 2005, at 06.02, Wang,Weiming wrote: > Hi, > > Here is the text proposed for the HB. Pls comments. > > For FE capability for heartbeats: > > > o FE Protocol capabilities (read-only): > > * Supported ForCES protocol version(s) by the FE > > * Supported ForCES FE model(s) by the FE > > * Some TML capability description(s) > > > > o FE Protocol capabilities (read-only): > > * Supported ForCES protocol version(s) by the FE > > * Supported ForCES FE model(s) by the FE > > * Some TML capability description(s) > > * FE capability to generate Heatbeats: Capable or Incapable. > > > For FE attributes for heartbeats: > > > FE Protocol attributes (can be read and set): > ... > * Heartbeat Interval. Defualt Value = 300 msec > > > > FE Protocol attributes (can be read and set): > ... > * Heartbeat policy and parameters, which includes fields as: > > . Heartbeat policy, which further includes two fields: > > CE heartbeat policy: to tell FE which heartbeat policy > the CE chooses. > > 0 - CE no heartbeat. In this case, CE does not send any > Heartbeat messages to FE. > 1 - CE normal heartbeat. In this case, CE sends > Heartbeat messages to FE at the time intervals specified by the CE > heartebeat interval parameter as below. > 2 - CE piggy-backing heartbeat. In this case, CE sends > Heartbeat messages to FE only when CE reaches the time interval > with no other message to be sent in the interval. > 3 - CE piggy-backing heartbeat with FE heartbeat > request. In this case, besides CE sends piggy-backing heartbeat, CE > also sends Heartbeat request message (also a normal HB message, > only whose ACK flag being set to AlwaysACK) to FE when CE has not > received any message from FE for the interval period. When this CE > heartbeat policy is choosen, the FE heartbeat policy below should > be set to 'FE no heartbeat'. > > FE heartbeat policy: to command the FE to use the > heartbeat policy. > > 0 - FE no heartbeat. > 1 - FE normal heartbeat. > 2 - FE piggy-backing heartbeat. In this case, FE sends > heartbeat messages to FE only when it reaches the time interval of > no message sending. > > > . CE heartbeat interval, to tell FE the heartbeat interval > CE uses. if not set or set to 0, it means CE chooses a default > value, which is 300msec > > . FE heartbeat interval, to command FE to use the interval > for the FE heartbeat. If not set or set to 0, it means FE must > choose the default value, which is 300msec > > > > > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: > Sent: Thursday, September 15, 2005 1:00 AM > Subject: Re: Closure needed please comment WAS(Re: Section 9: > Heartbeat Messages > > > >> On Thu, 2005-15-09 at 00:34 +0800, Weiming Wang wrote: >> >>> Robert and Jamal, >>> >>> Jamal, not sure why your post of this did not show on the list. >>> >>> >> >> Hrm, that is strange. I saw it echo back and it seems at least Robert >> saw it as well. This is one of the reason i always CC the person who >> sent the email. >> >> >>> I still can not see the much value to have CE be always active for >>> HBs even from FE. I'v already summarized the shorts for this as: >>> >>> 1. It makes CE have to manage time intervals for even hundreds of >>> FEs. Although Jamal mentioned that there is a good algorithm for >>> such management to make one timer for all such interval >>> notification, >>> I just think even a log for so many FEs is a big extra burden for >>> CE, >>> which I think can be removed and distributed to individual FEs. >>> >>> >> >> On the scaling issues in this particular case, I am going to >> disagree: >> The piggybacking scheme allows HBs to be a function of how busy the >> connection is between CE-FE. HB will be sent more only when the >> system >> is idle. Note, however: >> >> I am not proposing disallowing HB from the FE to CE - my >> suggestion is >> to make that an option; if the NE setup is to do it that way it >> should >> still work. >> >> >>> 2. It makes us have to define one more message - the HB response >>> message, though it may not be much difficult. >>> >>> >> >> Why do you need a new message? >> A HB with an ACK is responded to with a HB with no ACK >> >> >>> 3. ACK on and off is also an extra work for customer to use, which >>> can also be removed. >>> >>> >> >> There should be no ACK configuration. The behavior in general may be >> configured with a default of some sort. i.e the default could be >> to have >> the FE send HBs if it can do that. If it cant do that, then they are >> driven by CE etc. >> >> >>> On the otherhand, I can see the only benifit be that may bring is >>> it may make CE more like a master. >>> >>> >> >> Yes, that is beneficial - but probably not strong enough on its own. >> I claim that the major benefit is simplifying the FE side. >> >> >>> Jamal, can you present some more benifits so that we can see the >>> value more? >>> >> >> see above. >> >> cheers, >> jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 09:48:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGZg-0003Sf-72 for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 09:48:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17692 for ; Fri, 16 Sep 2005 09:48:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGea-0006pI-Cc for forces-archive@IETF.ORG; Fri, 16 Sep 2005 09:53:28 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010F08BA@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 9:48:11 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85729969 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 09:48:10 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 09:48:10 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GD2SXK018742 for ; Fri, 16 Sep 2005 06:02:29 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126878487.24495.10.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 09:48:07 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Unfortunately I didn't see Weiming's original email. Can we make the piggybacking aspect mandatory? I dislike that name too. I think we all agree it is a _very useful_ feature. Is there _any_ reason why you would not want that feature on? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 09:57:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGiL-0005I0-8u for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 09:57:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18130 for ; Fri, 16 Sep 2005 09:57:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGnL-00072y-7v for forces-archive@IETF.ORG; Fri, 16 Sep 2005 10:02:28 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010F084C@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 9:57:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85730525 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 09:57:10 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 09:57:09 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Fri, 16 Sep 2005 22:32:04 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Fri, 16 Sep 2005 21:56:43 +0800 References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126878487.24495.10.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <00e801c5bac6$69e23310$1152010a@Necom.hzic.edu.cn> Date: Fri, 16 Sep 2005 21:56:19 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: base64 SmFtYWwsIA0KDQpJJ20gbm90IHN1cmUgaWYgeW91IG1lYW4gdGhlIG5vcm1hbCBIQiBpcyBoZWxw bGVzcy4gSSBhZ3JlZSBpZiBubyBvdGhlciBvYmplY3Rpb25zLiBXaGVyZWFzIHRoZSBjYXNlICdu byBoZWFydGJlYXQnIHNob3VsZCBiZSBrZXB0LiANCg0KQWZ0ZXIgd2UgYWdyZWUgbm8gbm9ybWFs IEhCIGNhc2UsIHRoZW4gb25lIHdheSB0byBhdm9pZCB0aGUgd29yZCBwaWdneWJhY2tpbmcgaXMs IHdlIGp1c3QgdXNlIGl0IGFzIGhlYXJ0YmVhdC4gVGhhdCBtZWFucywgaW4gYW55IGNhc2VzIHdo ZW4gd2UgdXNlIGhlYXJ0YmVhdCwgaXQgYWx3YXlzIGZvbGxvd3MgdGhlIHJ1bGUgb2YgcGlnZ3li YWNraW5nLg0KDQpJcyBpdCBhbGwgcmlnaHQ/DQoNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4LmNvbT4N ClN1YmplY3Q6IFJlOiBDbG9zdXJlIG5lZWRlZCBwbGVhc2UgY29tbWVudCBXQVMoUmU6IFNlY3Rp b24gOTogSGVhcnRiZWF0IE1lc3NhZ2VzDQoNCg0KPiBVbmZvcnR1bmF0ZWx5IEkgZGlkbid0IHNl ZSBXZWltaW5nJ3Mgb3JpZ2luYWwgZW1haWwuDQo+IA0KPiBDYW4gd2UgbWFrZSB0aGUgcGlnZ3li YWNraW5nIGFzcGVjdCBtYW5kYXRvcnk/IEkgZGlzbGlrZSB0aGF0IG5hbWUgdG9vLg0KPiBJIHRo aW5rIHdlIGFsbCBhZ3JlZSBpdCBpcyBhIF92ZXJ5IHVzZWZ1bF8gZmVhdHVyZS4gSXMgdGhlcmUg X2FueV8NCj4gcmVhc29uIHdoeSB5b3Ugd291bGQgbm90IHdhbnQgdGhhdCBmZWF0dXJlIG9uPw0K PiANCj4gY2hlZXJzLA0KPiBqYW1hbA== From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 09:59:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGkT-0005uS-O7 for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 09:59:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18221 for ; Fri, 16 Sep 2005 09:59:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGpV-00075Y-5M for forces-archive@IETF.ORG; Fri, 16 Sep 2005 10:04:41 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010F073B@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 9:59:28 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85730613 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 09:59:25 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 09:59:25 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GDDhXK018814 for ; Fri, 16 Sep 2005 06:13:43 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E06B366C5@orsmsx408> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126879162.24495.18.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 09:59:22 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Clarification needed with Event subscribe/unsubscribe To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E06B366C5@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Thu, 2005-15-09 at 17:16 -0700, Khosravi, Hormuzd M wrote: > One small thing that I found missing in the draft was text for event > subscribe/unsubscribe. > > We need to add some clarifying text in section 6 as to how this is > currently support by the protocol/model. > I noticed we removed the Operations for this from Config msg, so this > should be part of the fe model now, I guess. > Yes to both. It is now part of the model doc and we need clarifying text. Ive noted this in my scribbled copy of the draft here and will add it when i get around to section 6 so no need for a new issue to be opened on the tracker. Essentially event sub/unsubscription is now a config message to SET properties. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 10:04:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGpO-00074T-6S for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 10:04:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18490 for ; Fri, 16 Sep 2005 10:04:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGuP-0007BJ-H4 for forces-archive@IETF.ORG; Fri, 16 Sep 2005 10:09:45 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010F0903@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 10:04:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85730777 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 10:04:32 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 10:04:32 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GDIPXK018857; Fri, 16 Sep 2005 06:18:25 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126878487.24495.10.camel@localhost.localdomain> <00e801c5bac6$69e23310$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126879445.24495.23.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 10:04:04 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00e801c5bac6$69e23310$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit On Fri, 2005-16-09 at 21:56 +0800, Wang,Weiming wrote: > Jamal, > > I'm not sure if you mean the normal HB is helpless. I agree > if no other objections. Whereas the case 'no heartbeat' > should be kept. > > After we agree no normal HB case, then one way to avoid > the word piggybacking is, we just use it as heartbeat. That > means, in any cases when we use heartbeat, it always follows > the rule of piggybacking. > > Is it all right? > I think i agree;-> Maybe we can settle on the concal. In other words what you are saying -if i understood correctly - is it doesnt matter what message goes out from the FE it is a polymorphic heartbeat. If this is what you are saying i agree with you. I was only worried about the extra knob to turn on piggy-backing in FEPO. If we make it mandatory to do the baove then we can remove that knob. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 11:37:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGIHi-0006re-Cr for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 11:37:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24607 for ; Fri, 16 Sep 2005 11:37:51 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGIMh-0001Lx-Er for forces-archive@IETF.ORG; Fri, 16 Sep 2005 11:43:06 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.010F08FE@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 11:37:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85736766 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 11:37:48 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 11:37:48 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GEq5XK019520; Fri, 16 Sep 2005 07:52:05 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126885065.24495.32.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 11:37:45 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages Comments: To: Avri Doria To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit To clarify so we can close. Someone please bounce this message to Weiming as well incase he doesnt see it. I see to have problems sending emails to him sometimes. On Fri, 2005-16-09 at 14:25 +0200, Avri Doria wrote: > Hi, > > I think it is essentially fine except that i think calling it piggy > back is misleading, i.e. sounds like there is a HB included in the > message. I would recommend implicit or something like that. > > a. > > On 16 sep 2005, at 06.02, Wang,Weiming wrote: > > > Hi, > > > > Here is the text proposed for the HB. Pls comments. > > > > For FE capability for heartbeats: > > > > > > o FE Protocol capabilities (read-only): > > > > * Supported ForCES protocol version(s) by the FE > > > > * Supported ForCES FE model(s) by the FE > > > > * Some TML capability description(s) > > > > > > > > o FE Protocol capabilities (read-only): > > > > * Supported ForCES protocol version(s) by the FE > > > > * Supported ForCES FE model(s) by the FE > > > > * Some TML capability description(s) > > > > * FE capability to generate Heatbeats: Capable or Incapable. > > > > As per concal, we are now saying the FE MUST implement heartbeats but CE can turn the generation of heartbeats off. Which means we dont need capability above. > > For FE attributes for heartbeats: > > > > > > FE Protocol attributes (can be read and set): > > ... > > * Heartbeat Interval. Defualt Value = 300 msec > > > > > > > > FE Protocol attributes (can be read and set): > > ... > > * Heartbeat policy and parameters, which includes fields as: > > > > . Heartbeat policy, which further includes two fields: > > > > CE heartbeat policy: to tell FE which heartbeat policy > > the CE chooses. > > > > 0 - CE no heartbeat. In this case, CE does not send any > > Heartbeat messages to FE. > > 1 - CE normal heartbeat. In this case, CE sends > > Heartbeat messages to FE at the time intervals specified by the CE > > heartebeat interval parameter as below. > > 2 - CE piggy-backing heartbeat. In this case, CE sends > > Heartbeat messages to FE only when CE reaches the time interval > > with no other message to be sent in the interval. > > 3 - CE piggy-backing heartbeat with FE heartbeat > > request. In this case, besides CE sends piggy-backing heartbeat, CE > > also sends Heartbeat request message (also a normal HB message, > > only whose ACK flag being set to AlwaysACK) to FE when CE has not > > received any message from FE for the interval period. When this CE > > heartbeat policy is choosen, the FE heartbeat policy below should > > be set to 'FE no heartbeat'. > > If we say the CE MUST send heartbeats then we dont need CE heartbeat policy and we can get rid of above "knobs" altogether. > > FE heartbeat policy: to command the FE to use the > > heartbeat policy. > > > > 0 - FE no heartbeat. > > 1 - FE normal heartbeat. > > 2 - FE piggy-backing heartbeat. In this case, FE sends > > heartbeat messages to FE only when it reaches the time interval of > > no message sending. > > If we agree that associating liveliness of the CE<->FE with heartbeats (what is referred to above as piggy-backing) is always going to be implemented i.e a MUST then 12 only need option 0 or 1. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 11:57:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGIaL-0003lL-2Z for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 11:57:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26003 for ; Fri, 16 Sep 2005 11:57:06 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGIfM-0001xs-FY for forces-archive@IETF.ORG; Fri, 16 Sep 2005 12:02:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010F0A33@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 11:57:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85740990 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 11:57:06 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 11:57:05 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GFBMXK019666 for ; Fri, 16 Sep 2005 08:11:23 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126886223.24495.36.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 11:57:03 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: update section 3 - take 2 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit As per concal ive made the following changes to clarify. ---- 3.2.2.3. Association Lost state In this state, both or either the CE or FE declare the other side is no longer associated. The disconnection could be physically initiated by either party for administrative purposes but may also be driven by operation reasons such as loss of connectivity. It should be noted that loss of connectivity between TMLs is not necessarily indictive of loss of association between respective PL layers unless the programmed FE Protocol Object is exceeded. In other words if the TML repairs the transport loss before then, the association would still be valid. ... ... ---------- Then next: 3.3.1.1.4. Recovery Any of the participating FEs, or the CE, or the associations between them, may fail after the EOT response message has left the FE and before it has received all the responses, (possibly the EOT response never reached the CE). In this protocol revision, for sake of simplicity as indicated in Section 3.2.2.3, an FE losing an association would be required to get new state from the newly associated CE from scratch upon a reassociation. The decision on what an FE should do after a lost association is dicated by the CE Failover policy (refer to Section 8 and Section 6.2). In the case of desire to do HA then multiple associations would exist between the FE and multiple CEs although only one of them would be the master at any time (as described in Section 8). The CEs to which the FE is associated to would need to be synchronized on the state of the FE. The scheme for such a synchronization is outside the scope of ForCES but is mentioned here to indicate that in such a setup, the FE would not be re-associating itself to the new CE master and would therefore not need to reload its state from scratch. ---- And last: --- 3.3.1.1.7. Relation to Multipart messages Multipart messages after the first one are indicated by the MOT flag (Middle of Transaction). The first message is indicated by SOT and the last by EOT. -------- So in addition to the earlier flags we need this new flag. Please comment with nay or yay so we can move to the next issues. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 13:29:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGK1V-00028X-KT for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 13:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00441 for ; Fri, 16 Sep 2005 13:29:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGK6X-0004SE-U1 for forces-archive@IETF.ORG; Fri, 16 Sep 2005 13:34:31 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010F0B48@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 13:29:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85747362 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 13:29:14 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 13:29:13 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GGhTXK020352 for ; Fri, 16 Sep 2005 09:43:30 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126891751.24495.41.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 13:29:11 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: small change in the tml text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Editorial. Diff below. cheers, jamal @@ -1163,7 +1163,7 @@ responsibility. However, on config basis, the PL layer may wish to participate in link failover schemes and therefore the TML must support this capability. - Please refer to the HA Section Section 8 for details. + Please refer to Section 8 for details. From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 13:31:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGK3l-00030X-D9 for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 13:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00582 for ; Fri, 16 Sep 2005 13:31:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGK8o-0004Wo-Nl for forces-archive@IETF.ORG; Fri, 16 Sep 2005 13:36:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010F0AB7@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 13:31:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85747936 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 13:31:35 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 13:31:35 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GGjpXK020376 for ; Fri, 16 Sep 2005 09:45:51 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126891893.24495.45.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 13:31:32 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: version field in the header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Folks, did we decide we are going to make the version field to be 8 bits? At the moment we have in the first word: version(4bits):rsvd(4bits):Type(8bits):Length(16bits) cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 13:47:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKIe-0006ij-22 for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 13:47:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01119 for ; Fri, 16 Sep 2005 13:46:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGKNg-0004pl-GO for forces-archive@IETF.ORG; Fri, 16 Sep 2005 13:52:13 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010F0B4B@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 13:46:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85748925 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 13:46:57 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 13:46:57 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GH1CXK020502 for ; Fri, 16 Sep 2005 10:01:13 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126892814.24495.51.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 13:46:54 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Multicast IDs To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit >From section 5.1. Common Header -- g. It is desirable to address multicast and/or broadcast messages to some LFB instances of a given class. For instance, assume FEs FEa and FEb: - FEa has LFBs LFBaX1 and LFBaX2 of class X - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of class X. A broadcast message should be addressable to only LFBs LFBaX1 and LFBbX1 (this can be the case for instance if these two LFBs belong to the same VPN). To achieve this, a VPN ID (3 octets OUI and 4 octets VPN Index) as defined in RFC 2685 should be used within the ForCES message body as a TLV. As an alternative, a particular multicast ID MAY be associated to a given VPN ID through some configuration means. Messages delivered to such a multicast ID MUST only be applied to LFBs belonging to that VPN ID. ----- Robert, I think this text came from you. If we are going to allow the first scheme - then for interop we need to have more definition. The second scheme would work fine without explicit detailing. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 16:09:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGMWU-0001gU-Pk for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 16:09:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12339 for ; Fri, 16 Sep 2005 16:09:23 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGMbV-0001D1-51 for forces-archive@IETF.ORG; Fri, 16 Sep 2005 16:14:40 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010F0DE2@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 16:09:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85755657 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 16:09:00 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 16:08:59 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GJNEXK021599 for ; Fri, 16 Sep 2005 12:23:14 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126901337.24495.60.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 16:08:56 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: HA and Heartbeats To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit While correlating different sections: --> If a CE and an FE are each sending heartbeats to the other, are they required to use the same values for HB Interval and HB Dead Interval? If not we need to be creative with FEPO. I know it's slightly out of date at the moment, just trying to capture issues. - If an FE is connected to multiple CEs in a CElist for HA purposes and it is associated to all of them (clearly amongst the CEs, theres only one which is a master at a time), on heartbeats: -> Do we allow the FE send heartbeats to the non-primary CEs? -> Do we allow the non-primary CEs send heartbeats to the FE? -> If so, are the CEs required to use the same values for HBI and HBDI? I have some thoughts - but wanted to solicit input first. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 16:32:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGMtE-0000SM-TU for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 16:32:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18197 for ; Fri, 16 Sep 2005 16:32:54 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGMyJ-0003Uc-Pd for forces-archive@IETF.ORG; Fri, 16 Sep 2005 16:38:12 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010F0C6C@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 16:32:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85756775 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 16:32:52 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 16:32:52 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8GJl6XK021780; Fri, 16 Sep 2005 12:47:06 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126902769.24495.84.camel@localhost.localdomain> Date: Fri, 16 Sep 2005 16:32:49 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: LFB link and aliases Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Joel, I promised i was going to send something on events but here's something that popped off some brain cells right now (and has been bothering me for some time now): While thinking of the "port" aka "network device" LFB connectivity, i found an interesting issue. Two schemes are possible to represent/model the ports or any other LFB. 1) Group all of a FE's "netdevices" into one instance (for ease of implementation). A single table in that instance which houses all the netdevice description. A path to the table.index gets details. This is what i showed in my slides at the last meeting. It is my favorite and we have infact implemented this. 2) Create an instance per "netdevice". No table - all the descriptions for a single "netdevice" are in that instance. A little abuse of the instance ID space, memory and CPU - but valid nonetheless. While "netdevice" is a bad example for the use of #2, there are/maybe other LFBs where this will make more sense. However, looking at the FEobject and LFBTopology and in particular to the LFBLink one notices that links are mapped to LFBselectors. This means that only #2 will fit in well. This struck me as i was looking at "netdevices" links to a parent or children netdevices and corelatting with how we have done things. It is clear that packets may flow from a child netdevice to a parent netdevice (or vice versa) as i showed in the meeting. And so while #1 is valid, it makes it hard to fit it into the LFBTopology. So where am i going with this? I would like to suggest a change to the LFBLink to optionaly have a path in addition to an LFBSelector. Then we can easily fit model #1 in the topology. Which actually interestingly enough means that an alias construct as we have defined it now is infact an LFBlink (if we redifine it) - which makes sense. Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 17:33:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGNpu-0005R9-2W for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 17:33:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20770 for ; Fri, 16 Sep 2005 17:33:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGNuz-0004ph-Da for forces-archive@IETF.ORG; Fri, 16 Sep 2005 17:38:49 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010F102C@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 17:33:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85760117 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 17:33:31 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 17:33:31 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8GLXSvL027026; Fri, 16 Sep 2005 21:33:28 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8GLSorV011566; Fri, 16 Sep 2005 21:33:26 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005091609311413662 ; Fri, 16 Sep 2005 09:31:20 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 09:13:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Clarification needed with Event subscribe/unsubscribe Thread-Index: AcW6a3X8qN1tdVH1TCCe3PXnhCEORwAbgv8w X-OriginalArrivalTime: 16 Sep 2005 16:13:10.0168 (UTC) FILETIME=[87F69180:01C5BAD9] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06B36AEE@orsmsx408> Date: Fri, 16 Sep 2005 09:13:08 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Clarification needed with Event subscribe/unsubscribe Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Thanks Joel!=20 -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 Sent: Thursday, September 15, 2005 8:05 PM To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Clarification needed with Event subscribe/unsubscribe There is no special operation for subscribe / unsubscribe. It uses a=20 SET-Properties operation. The properties of the event, as described in the=20 model, include the subscription status. Yours, Joel M. Halpern At 08:16 PM 9/15/2005, Khosravi, Hormuzd M wrote: >One small thing that I found missing in the draft was text for event=20 >subscribe/unsubscribe. > >We need to add some clarifying text in section 6 as to how this is=20 >currently support by the protocol/model. >I noticed we removed the Operations for this from Config msg, so this=20 >should be part of the fe model now, I guess. > >Thanks >Hormuzd > From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 21:08:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGRBk-0002sz-EX for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 21:08:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00443 for ; Fri, 16 Sep 2005 21:08:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGRGl-0000qS-L7 for forces-archive@IETF.ORG; Fri, 16 Sep 2005 21:13:38 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010F1399@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 21:08:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85770618 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 21:08:06 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 21:08:05 -0400 Received: from [162.84.109.40] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12503306; Fri, 16 Sep 2005 21:08:05 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126901337.24495.60.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050916210542.02d7e298@localhost> Date: Fri, 16 Sep 2005 21:08:02 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: HA and Heartbeats Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126901337.24495.60.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 It seems that no matter what, the CE has to configure the FE heartbeat interval. The CE has to also configure the FE as to its timeout for declaring the CE dead. The CE also must have local configuration as to what its heartbeat transmit interval and its timeout for declaring the FE dead are. I am inclined not to couple these two. However, it does not seem to change the protocol or the FE Protocol Object anyway. Yours, Joel At 04:08 PM 9/16/2005, Jamal Hadi Salim wrote: >While correlating different sections: > >--> If a CE and an FE are each sending heartbeats to the other, are they >required to use the same values for HB Interval and HB Dead Interval? >If not we need to be creative with FEPO. I know it's slightly out of >date at the moment, just trying to capture issues. > >- If an FE is connected to multiple CEs in a CElist for HA purposes and >it is associated to all of them (clearly amongst the CEs, theres only >one which is a master at a time), on heartbeats: > -> Do we allow the FE send heartbeats to the non-primary CEs? > -> Do we allow the non-primary CEs send heartbeats to the FE? > -> If so, are the CEs required to use the same values for HBI >and HBDI? > >I have some thoughts - but wanted to solicit input first. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 21:14:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGRHq-0004DW-JF for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 21:14:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00889 for ; Fri, 16 Sep 2005 21:14:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGRMx-00010l-Sa for forces-archive@IETF.ORG; Fri, 16 Sep 2005 21:19:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010F1175@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 21:14:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85770832 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 21:14:36 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 21:14:36 -0400 Received: from [162.84.109.40] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12503331; Fri, 16 Sep 2005 21:14:36 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126902769.24495.84.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050916210903.02d7e008@localhost> Date: Fri, 16 Sep 2005 21:14:33 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB link and aliases Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126902769.24495.84.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 I don't think the change you have described works. I believe that the LFB Link (the topology) really needs to avoid getting entangled in the inside semantics of the LFBs. yes, LFBs can be defined to have one "instance" or to have a table of instances. For LFBs which have a table of instances, there has to be some way that incoming packets are associated with entries in the table. In general, that is up to the LFB designer. There are two common ways. Some LFBs will select table entries based on the incoming port. This can be supported. It does not simplify the topology much. Some LFBs will select table entries based on meta-data associated with the packets. This clearly compresses the topology. And such mapping does not belong in the LFB Link table. Personally, I would recommend that one not use an LFB with a table of information if the selector is the incoming port index. Given that one can merge the outgoing links from several such LFB instances, it is probably simpler to model them separately. On the other hand, if it is meta-data driven one must use a table structure. For example, the example LFB uses meta-data for demuxing traffic aimed at different circuits and laser channels. Yours, Joel M. Halpern At 04:32 PM 9/16/2005, Jamal Hadi Salim wrote: >Joel, > >I promised i was going to send something on events but here's something >that popped off some brain cells right now (and has been bothering me >for some time now): > >While thinking of the "port" aka "network device" LFB connectivity, i >found an interesting issue. > >Two schemes are possible to represent/model the ports or any other LFB. > >1) Group all of a FE's "netdevices" into one instance (for ease of >implementation). A single table in that instance which houses all the >netdevice description. A path to the table.index gets details. >This is what i showed in my slides at the last meeting. It is my >favorite and we have infact implemented this. > >2) Create an instance per "netdevice". No table - all the descriptions >for a single "netdevice" are in that instance. A little abuse of the >instance ID space, memory and CPU - but valid nonetheless. > >While "netdevice" is a bad example for the use of #2, there are/maybe >other LFBs where this will make more sense. > >However, looking at the FEobject and LFBTopology and in particular to >the LFBLink one notices that links are mapped to LFBselectors. This >means that only #2 will fit in well. >This struck me as i was looking at "netdevices" links to a parent or >children netdevices and corelatting with how we have done things. It is >clear that packets may flow from a child netdevice to a parent netdevice >(or vice versa) as i showed in the meeting. And so while #1 is valid, it >makes it hard to fit it into the LFBTopology. > >So where am i going with this? >I would like to suggest a change to the LFBLink to optionaly have a path >in addition to an LFBSelector. Then we can easily fit model #1 in the >topology. Which actually interestingly enough means that an alias >construct as we have defined it now is infact an LFBlink (if we redifine >it) - which makes sense. > >Thoughts? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 22:51:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGSnq-0001du-Ou for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 22:51:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05475 for ; Fri, 16 Sep 2005 22:51:43 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGSsx-0003Gc-Cc for forces-archive@IETF.ORG; Fri, 16 Sep 2005 22:57:05 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010F120B@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 22:51:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85774801 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 22:51:43 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 22:51:42 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sat, 17 Sep 2005 11:26:43 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 17 Sep 2005 10:51:15 +0800 References: <1126886223.24495.36.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <016401c5bb32$9ce5ec40$1152010a@Necom.hzic.edu.cn> Date: Sat, 17 Sep 2005 10:50:50 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: update section 3 - take 2 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 4.0 (++++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: base64 SmFtYWwsDQoNCj4gMy4yLjIuMy4gIEFzc29jaWF0aW9uIExvc3Qgc3RhdGUNCj4gDQo+ICAgIElu IHRoaXMgc3RhdGUsIGJvdGggb3IgZWl0aGVyIHRoZSBDRSBvciBGRSBkZWNsYXJlIHRoZSBvdGhl ciBzaWRlIGlzDQo+ICAgIG5vIGxvbmdlciBhc3NvY2lhdGVkLiAgVGhlIGRpc2Nvbm5lY3Rpb24g Y291bGQgYmUgcGh5c2ljYWxseQ0KPiAgICBpbml0aWF0ZWQgYnkgZWl0aGVyIHBhcnR5IGZvciBh ZG1pbmlzdHJhdGl2ZSBwdXJwb3NlcyBidXQgbWF5IGFsc28gYmUNCj4gICAgZHJpdmVuIGJ5IG9w ZXJhdGlvbiByZWFzb25zIHN1Y2ggYXMgbG9zcyBvZiBjb25uZWN0aXZpdHkuDQo+IA0KPiAgICBJ dCBzaG91bGQgYmUgbm90ZWQgdGhhdCBsb3NzIG9mIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIFRNTHMg aXMgbm90DQo+ICAgIG5lY2Vzc2FyaWx5IGluZGljdGl2ZSBvZiBsb3NzIG9mIGFzc29jaWF0aW9u IGJldHdlZW4gcmVzcGVjdGl2ZSBQTA0KPiAgICBsYXllcnMgdW5sZXNzIHRoZSBwcm9ncmFtbWVk IEZFIFByb3RvY29sIE9iamVjdCBpcyBleGNlZWRlZC4gIEluDQo+ICAgIG90aGVyIHdvcmRzIGlm IHRoZSBUTUwgcmVwYWlycyB0aGUgdHJhbnNwb3J0IGxvc3MgYmVmb3JlIHRoZW4sIHRoZQ0KPiAg ICBhc3NvY2lhdGlvbiB3b3VsZCBzdGlsbCBiZSB2YWxpZC4NCj4gDQo+ICAgIC4uLg0KPiAgICAu Li4NCj4gDQo+IC0tLS0tLS0tLS0NCj4gDQo+IFRoZW4gbmV4dDoNCj4gDQo+IDMuMy4xLjEuNC4g IFJlY292ZXJ5DQo+IA0KPiAgICBBbnkgb2YgdGhlIHBhcnRpY2lwYXRpbmcgRkVzLCBvciB0aGUg Q0UsIG9yIHRoZSBhc3NvY2lhdGlvbnMgYmV0d2Vlbg0KPiAgICB0aGVtLCBtYXkgZmFpbCBhZnRl ciB0aGUgRU9UIHJlc3BvbnNlIG1lc3NhZ2UgaGFzIGxlZnQgdGhlIEZFIGFuZA0KPiAgICBiZWZv cmUgaXQgaGFzIHJlY2VpdmVkIGFsbCB0aGUgcmVzcG9uc2VzLCAocG9zc2libHkgdGhlIEVPVCBy ZXNwb25zZQ0KPiAgICBuZXZlciByZWFjaGVkIHRoZSBDRSkuDQo+IA0KPiAgICBJbiB0aGlzIHBy b3RvY29sIHJldmlzaW9uLCBmb3Igc2FrZSBvZiBzaW1wbGljaXR5IGFzIGluZGljYXRlZCBpbg0K PiAgICBTZWN0aW9uIDMuMi4yLjMsIGFuIEZFIGxvc2luZyBhbiBhc3NvY2lhdGlvbiB3b3VsZCBi ZSByZXF1aXJlZCB0byBnZXQNCj4gICAgbmV3IHN0YXRlIGZyb20gdGhlIG5ld2x5IGFzc29jaWF0 ZWQgQ0UgZnJvbSBzY3JhdGNoIHVwb24gYQ0KPiAgICByZWFzc29jaWF0aW9uLiAgVGhlIGRlY2lz aW9uIG9uIHdoYXQgYW4gRkUgc2hvdWxkIGRvIGFmdGVyIGEgbG9zdA0KPiAgICBhc3NvY2lhdGlv biBpcyBkaWNhdGVkIGJ5IHRoZSBDRSBGYWlsb3ZlciBwb2xpY3kgKHJlZmVyIHRvIFNlY3Rpb24g OA0KSSBkb24ndCBrbm93IHRoZSB3b3JkICdkaWNhdGVkJy4gSXMgaXQgYSBtaXN0eXBpbmc/DQoN Cj4gICAgYW5kIFNlY3Rpb24gNi4yKS4NCj4gDQo+ICAgIEluIHRoZSBjYXNlIG9mIGRlc2lyZSB0 byBkbyBIQSB0aGVuIG11bHRpcGxlIGFzc29jaWF0aW9ucyB3b3VsZCBleGlzdA0KPiAgICBiZXR3 ZWVuIHRoZSBGRSBhbmQgbXVsdGlwbGUgQ0VzIGFsdGhvdWdoIG9ubHkgb25lIG9mIHRoZW0gd291 bGQgYmUNCj4gICAgdGhlIG1hc3RlciBhdCBhbnkgdGltZSAoYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gOCkuICBUaGUgQ0VzIHRvIHdoaWNoDQo+ICAgIHRoZSBGRSBpcyBhc3NvY2lhdGVkIHRvIHdv dWxkIG5lZWQgdG8gYmUgc3luY2hyb25pemVkIG9uIHRoZSBzdGF0ZSBvZg0KPiAgICB0aGUgRkUu ICBUaGUgc2NoZW1lIGZvciBzdWNoIGEgc3luY2hyb25pemF0aW9uIGlzIG91dHNpZGUgdGhlIHNj b3BlDQo+ICAgIG9mIEZvckNFUyBidXQgaXMgbWVudGlvbmVkIGhlcmUgdG8gaW5kaWNhdGUgdGhh dCBpbiBzdWNoIGEgc2V0dXAsIHRoZQ0KPiAgICBGRSB3b3VsZCBub3QgYmUgcmUtYXNzb2NpYXRp bmcgaXRzZWxmIHRvIHRoZSBuZXcgQ0UgbWFzdGVyIGFuZCB3b3VsZA0KPiAgICB0aGVyZWZvcmUg bm90IG5lZWQgdG8gcmVsb2FkIGl0cyBzdGF0ZSBmcm9tIHNjcmF0Y2guDQpPbmUgbW9yZSBxdWVz dGlvbiBpcywgd2UgZG9uJ3QgaGF2ZSB0byBoYXZlIEZFIHRvIHJlc3RhcnQgd2hlbiB3ZSBzd2l0 Y2ggZnJvbSBtYXN0ZXIgQ0UgdG8gYmFja3VwIENFLCB0aGVuLCBkbyB3ZSBuZWVkIHRvIGRlZmlu aXRlbHkgYXNrIEZFIHRvIHJlc3RhcnQgaWYgdGhlIHJlLWFzc29jaWF0ZWQgQ0UgaXMgc3RpbGwg dGhlIG9yaWdpbmFsIG1hc3RlciBvbmUgYWZ0ZXIgdGhlIENFIGlzIGJhY2sgYWdhaW4/ICANCg0K SmFtYWwsIFRoYW5rcyBmb3IgdGhlIGhhcmQgd29yay4NCg0KV2VpbWluZw0KIA== From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 16 23:07:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGT3F-00058q-DW for forces-archive@megatron.ietf.org; Fri, 16 Sep 2005 23:07:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06104 for ; Fri, 16 Sep 2005 23:07:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGT8L-0003aL-P0 for forces-archive@IETF.ORG; Fri, 16 Sep 2005 23:13:00 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010F1500@cherry.ease.lsoft.com>; Fri, 16 Sep 2005 23:07:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85776665 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Sep 2005 23:07:37 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Sep 2005 23:07:34 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sat, 17 Sep 2005 11:42:36 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 17 Sep 2005 11:07:08 +0800 References: <1126891751.24495.41.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <017c01c5bb34$d4ca5310$1152010a@Necom.hzic.edu.cn> Date: Sat, 17 Sep 2005 11:06:43 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: small change in the tml text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: base64 Rm9yIHN1Y2ggc21hbGwgY2hhbmdlcywgeW91IG1heSBwdXJlbHkgZGVjaWRlIGl0IHdoaWxlIHdp dGhvdXQgYmVpbmcgbm90aWZpZWQgc28gYXMgdG8gZmFzdCB0aGUgcGFjZSA6KQ0KDQpUaGFua3Ms DQpXZWltaW5nDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhh ZGkgU2FsaW0iIDxoYWRpQHpueXguY29tPg0KVG86IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5D T00+DQpTZW50OiBTYXR1cmRheSwgU2VwdGVtYmVyIDE3LCAyMDA1IDE6MjkgQU0NClN1YmplY3Q6 IHNtYWxsIGNoYW5nZSBpbiB0aGUgdG1sIHRleHQNCg0KDQo+IEVkaXRvcmlhbC4gRGlmZiBiZWxv dy4NCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCj4gDQo+IEBAIC0xMTYzLDcgKzExNjMsNyBAQA0K PiAgICAgICAgIHJlc3BvbnNpYmlsaXR5LiAgSG93ZXZlciwgb24gY29uZmlnIGJhc2lzLCB0aGUg UEwgbGF5ZXIgbWF5IHdpc2gNCj4gICAgICAgICB0byBwYXJ0aWNpcGF0ZSBpbiBsaW5rIGZhaWxv dmVyIHNjaGVtZXMgYW5kIHRoZXJlZm9yZSB0aGUgVE1MDQo+ICAgICAgICAgbXVzdCBzdXBwb3J0 IHRoaXMgY2FwYWJpbGl0eS4NCj4gLSAgICAgICBQbGVhc2UgcmVmZXIgdG8gdGhlIEhBIFNlY3Rp b24gU2VjdGlvbiA4IGZvciBkZXRhaWxzLg0KPiArICAgICAgIFBsZWFzZSByZWZlciB0byBTZWN0 aW9uIDggZm9yIGRldGFpbHMu From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 17 07:30:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGatc-0007nF-QM for forces-archive@megatron.ietf.org; Sat, 17 Sep 2005 07:30:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08233 for ; Sat, 17 Sep 2005 07:30:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGaym-0005UW-T3 for forces-archive@IETF.ORG; Sat, 17 Sep 2005 07:35:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010F18C2@cherry.ease.lsoft.com>; Sat, 17 Sep 2005 7:30:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85794625 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 17 Sep 2005 07:30:10 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 17 Sep 2005 07:30:10 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8HAiGXK026822 for ; Sat, 17 Sep 2005 03:44:16 -0700 (PDT) References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126956608.6681.31.camel@localhost.localdomain> Date: Sat, 17 Sep 2005 07:30:08 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: HA and Heartbeats To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050916210542.02d7e298@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit The concern is on the case of multiple CEs associating to a single FE (as we defined in section 8 for HA). As described in that section, only one of those CEs is actually configuring the FE. Does the FE need to know of the liveliness of all those CEs (that it associated with)? If yes, then the simplest thing would be at least multiple FEPO LFB _instances_, no? Upto this point we have been saying there is only one instance of the FEPO per FE. Further, if we are saying that only the primary CE is the configurator of the FE, then if we create instances of FEPO - shouldnt we have multiple configurators of at least that one LFB? cheers, jamal On Fri, 2005-16-09 at 21:08 -0400, Joel M. Halpern wrote: > It seems that no matter what, the CE has to configure the FE heartbeat > interval. > The CE has to also configure the FE as to its timeout for declaring the CE > dead. > The CE also must have local configuration as to what its heartbeat transmit > interval and its timeout for declaring the FE dead are. > I am inclined not to couple these two. > > However, it does not seem to change the protocol or the FE Protocol Object > anyway. > > Yours, > Joel > > At 04:08 PM 9/16/2005, Jamal Hadi Salim wrote: > >While correlating different sections: > > > >--> If a CE and an FE are each sending heartbeats to the other, are they > >required to use the same values for HB Interval and HB Dead Interval? > >If not we need to be creative with FEPO. I know it's slightly out of > >date at the moment, just trying to capture issues. > > > >- If an FE is connected to multiple CEs in a CElist for HA purposes and > >it is associated to all of them (clearly amongst the CEs, theres only > >one which is a master at a time), on heartbeats: > > -> Do we allow the FE send heartbeats to the non-primary CEs? > > -> Do we allow the non-primary CEs send heartbeats to the FE? > > -> If so, are the CEs required to use the same values for HBI > >and HBDI? > > > >I have some thoughts - but wanted to solicit input first. > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 17 08:10:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGbX1-0008RI-7T for forces-archive@megatron.ietf.org; Sat, 17 Sep 2005 08:10:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10358 for ; Sat, 17 Sep 2005 08:10:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGbcE-0006bG-8y for forces-archive@IETF.ORG; Sat, 17 Sep 2005 08:16:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010F1AE8@cherry.ease.lsoft.com>; Sat, 17 Sep 2005 8:10:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85796234 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 17 Sep 2005 08:10:57 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 17 Sep 2005 08:10:56 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8HBP1XK029644 for ; Sat, 17 Sep 2005 04:25:02 -0700 (PDT) References: <1126902769.24495.84.camel@localhost.localdomain> <6.2.1.2.0.20050916210903.02d7e008@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126959054.6681.67.camel@localhost.localdomain> Date: Sat, 17 Sep 2005 08:10:54 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB link and aliases To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050916210903.02d7e008@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit On Fri, 2005-16-09 at 21:14 -0400, Joel M. Halpern wrote: > I don't think the change you have described works. > I believe that the LFB Link (the topology) really needs to avoid getting > entangled in the inside semantics of the LFBs. > > yes, LFBs can be defined to have one "instance" or to have a table of > instances. Actually come to think of it - we have had this discussion a few times ;-> and for some reason, whenever i try to derive from first principles i always come to this hump - so bear with me. I think our main differences is you looked at it from the datapath perspective and i kept thinking of it from a protocol/control perspective. Lets take the second example of LFB of netdevices as i described... i.e there is a table which groups netdevices within one LFB class for that FE. If it is modelled as a table of netdevices, it follows that an instance (as in that part of the LFB selector) implies a derivation of the class that has this table. So only one such instance is needed for the class on the FE. In other words: - To configure any of the netdevices (protocol level) i need to specify the path to LFBclass.instance.table.index address. Would you agree? Yes, from a datapath and packet traversal, the functional blocks that processes the packets would be "sown" together using either of the schemes that you specified (metadata etc). And as you indicate: it is upto whoever put together that FE to define it. i.e it doesnt matter from a protocol perspective. Are we still in agreement upto this point? So this leads next to the FE objects Topology map - If i was to show a link to/from a netdevice (as modelled the way i described it) to another LFB instance (or another instance of the same netdevice LFB), what would i show the LFBLink part to be? Is it not the LFBclass.instance.table.index, which is really the address the protocol uses to configure the netdevice? There are other LFB instances whose address is sufficiently described as LFBclass.instance. I currently use aliases to have netdevices point to their children or parent - however, I made the posting because i realized that this is not only related to the LFB i am currently worried but rather all LFBs that will be similarly modeled. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 17 08:23:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGbjQ-0002Gh-6R for forces-archive@megatron.ietf.org; Sat, 17 Sep 2005 08:23:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10719 for ; Sat, 17 Sep 2005 08:23:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGbod-0006pD-Fl for forces-archive@IETF.ORG; Sat, 17 Sep 2005 08:29:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010F1A31@cherry.ease.lsoft.com>; Sat, 17 Sep 2005 8:23:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85796430 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 17 Sep 2005 08:23:46 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 17 Sep 2005 08:23:46 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8HBbUXK029757; Sat, 17 Sep 2005 04:37:31 -0700 (PDT) References: <1126886223.24495.36.camel@localhost.localdomain> <016401c5bb32$9ce5ec40$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1126959803.6681.78.camel@localhost.localdomain> Date: Sat, 17 Sep 2005 08:23:23 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: update section 3 - take 2 Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <016401c5bb32$9ce5ec40$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Hi Weiming, On Sat, 2005-17-09 at 10:50 +0800, Wang,Weiming wrote: > I don't know the word 'dicated'. Is it a mistyping? > fixed. > > In the case of desire to do HA then multiple associations would exist > > between the FE and multiple CEs although only one of them would be > > the master at any time (as described in Section 8). The CEs to which > > the FE is associated to would need to be synchronized on the state of > > the FE. The scheme for such a synchronization is outside the scope > > of ForCES but is mentioned here to indicate that in such a setup, the > > FE would not be re-associating itself to the new CE master and would > > therefore not need to reload its state from scratch. > > One more question is, we don't have to have FE to restart when we switch from > master CE to backup CE, then, do we need to definitely ask FE to restart if > the re-associated CE is still the original master one after the CE is back again? > In my view, the answer is yes if that is the only association you head; it probably doesnt make sense to have multiple associations with sane CE. Other people may have different opinions. We actually havent heard from Joel on this topic. > Jamal, Thanks for the hard work. And thank you for being vigilant and catching all the issues we are glossing over as you did on this section 3 and others before. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 17 10:25:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGdde-0003Ww-JB for forces-archive@megatron.ietf.org; Sat, 17 Sep 2005 10:25:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16239 for ; Sat, 17 Sep 2005 10:25:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGdir-0000m3-L2 for forces-archive@IETF.ORG; Sat, 17 Sep 2005 10:31:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010F191F@cherry.ease.lsoft.com>; Sat, 17 Sep 2005 10:25:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85799771 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 17 Sep 2005 10:25:55 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 17 Sep 2005 10:25:50 -0400 Received: from [162.84.109.40] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12507548 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 17 Sep 2005 10:25:50 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050917102320.02cc05d8@localhost> Date: Sat, 17 Sep 2005 10:25:41 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: HA and Heartbeats To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126956608.6681.31.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 An interesting question that had not occurred to me. We have tried up till now to keep the impact of HA to a minimum for this revision, to keep our lives simple. In fact, I had assumed (possibly incorrectly) that heartbeat was only exchanged with the primary, active, CE. Otherwise, we are going to start need explicit configuration information related to HA support. Yours, Joel M. Halpern At 07:30 AM 9/17/2005, you wrote: >The concern is on the case of multiple CEs associating to a single FE >(as we defined in section 8 for HA). As described in that section, >only one of those CEs is actually configuring the FE. Does the FE need >to know of the liveliness of all those CEs (that it associated with)? If >yes, then the simplest thing would be at least multiple FEPO LFB >_instances_, no? Upto this point we have been saying there is only one >instance of the FEPO per FE. >Further, if we are saying that only the primary CE is the configurator >of the FE, then if we create instances of FEPO - shouldnt we have >multiple configurators of at least that one LFB? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 17 10:32:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGdjv-0004yf-5v for forces-archive@megatron.ietf.org; Sat, 17 Sep 2005 10:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16542 for ; Sat, 17 Sep 2005 10:32:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGdp9-0000tQ-GL for forces-archive@IETF.ORG; Sat, 17 Sep 2005 10:37:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010F1A26@cherry.ease.lsoft.com>; Sat, 17 Sep 2005 10:32:26 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85800236 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 17 Sep 2005 10:32:25 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 17 Sep 2005 10:32:19 -0400 Received: from [162.84.109.40] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12507566; Sat, 17 Sep 2005 10:32:19 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126902769.24495.84.camel@localhost.localdomain> <6.2.1.2.0.20050916210903.02d7e008@localhost> <1126959054.6681.67.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050917102650.02cce370@localhost> Date: Sat, 17 Sep 2005 10:32:15 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB link and aliases Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126959054.6681.67.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d All of the statements you make to confirm the starting point are accurate and agreed, but I think the difference is in a subtlety of semantics. Given an LFB class with a table of net-devices and an LFB instance of that class, when you want to configure a single net-device, you send a SET Request whose LFB instance target is that LFB instance. The path within the SET request will select the table of net-devices and the net-device table entry, and the fields of that netdevice entry you want to manipulate. The LFB Link topology information in the FE will only tell you which LFB instances are interconnected by that link. It will not tell you which table entry within the LFB instance is using that link. Clearly, when the table entry is selected by meta-data, the LFB Link topology information can not refer to it, since it is not topological. We could augment the topology information for the case where the selection is on the basis of incoming port. But... a) I consider that a complication that doesn't add anything, since that knowledge has to be in the LFB instance anyway. b) I would recommend that such mapping be represented by defining the LFB Class to hold a single instance While this will result in more LFB instances, it will result in both clearer LFB behavior and clearer topology. Yours, Joel At 08:10 AM 9/17/2005, Jamal Hadi Salim wrote: >On Fri, 2005-16-09 at 21:14 -0400, Joel M. Halpern wrote: > > I don't think the change you have described works. > > I believe that the LFB Link (the topology) really needs to avoid getting > > entangled in the inside semantics of the LFBs. > > > > yes, LFBs can be defined to have one "instance" or to have a table of > > instances. > >Actually come to think of it - we have had this discussion a few >times ;-> and for some reason, whenever i try to derive from first >principles i always come to this hump - so bear with me. > >I think our main differences is you looked at it from the datapath >perspective and i kept thinking of it from a protocol/control >perspective. > >Lets take the second example of LFB of netdevices as i described... >i.e there is a table which groups netdevices within one LFB class for >that FE. If it is modelled as a table of netdevices, it follows that an >instance (as in that part of the LFB selector) implies a derivation of >the class that has this table. So only one such instance is needed for >the class on the FE. >In other words: >- To configure any of the netdevices (protocol level) i need to specify >the path to LFBclass.instance.table.index address. > >Would you agree? > >Yes, from a datapath and packet traversal, the functional blocks that >processes the packets would be "sown" together using either of the >schemes that you specified (metadata etc). And as you indicate: it is >upto whoever put together that FE to define it. i.e it doesnt matter >from a protocol perspective. > >Are we still in agreement upto this point? > >So this leads next to the FE objects Topology map - If i was to show a >link to/from a netdevice (as modelled the way i described it) to another >LFB instance (or another instance of the same netdevice LFB), what would >i show the LFBLink part to be? Is it not the >LFBclass.instance.table.index, which is really the address the protocol >uses to configure the netdevice? There are other LFB instances whose >address is sufficiently described as LFBclass.instance. >I currently use aliases to have netdevices point to their children or >parent - however, I made the posting because i realized that this is not >only related to the LFB i am currently worried but rather all LFBs that >will be similarly modeled. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Sep 18 09:43:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGzS8-0000XS-WB for forces-archive@megatron.ietf.org; Sun, 18 Sep 2005 09:43:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24060 for ; Sun, 18 Sep 2005 09:43:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGzXV-0006xX-Bt for forces-archive@IETF.ORG; Sun, 18 Sep 2005 09:49:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010F2373@cherry.ease.lsoft.com>; 18 Sep 2005 9:43:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85847995 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 18 Sep 2005 09:43:18 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 18 Sep 2005 09:43:18 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8ICv7XK038192 for ; Sun, 18 Sep 2005 05:57:08 -0700 (PDT) References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127049919.29891.9.camel@localhost.localdomain> Date: Sun, 18 Sep 2005 09:25:19 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: HA and Heartbeats To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050917102320.02cc05d8@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On Sat, 2005-17-09 at 10:25 -0400, Joel M. Halpern wrote: > An interesting question that had not occurred to me. > We have tried up till now to keep the impact of HA to a minimum for this > revision, to keep our lives simple. > In fact, I had assumed (possibly incorrectly) that heartbeat was only > exchanged with the primary, active, CE. We need to make a decision of whether this is what we want to do. > Otherwise, we are going to start need explicit configuration information > related to HA support. We could have all the CEs checking liveliness via heartbeats and that we allow them only to configure/control an instance of FEPO and nothing more. Otherwise it reduces the value of having multiple CEs for HA purposes. Infact, would it be unreasonable to expect multiple CEs as masters of different (non-conflicting) LFB instances? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Sep 18 09:43:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGzS9-0000Xb-Bg for forces-archive@megatron.ietf.org; Sun, 18 Sep 2005 09:43:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24063 for ; Sun, 18 Sep 2005 09:43:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGzXZ-0006xX-Um for forces-archive@IETF.ORG; Sun, 18 Sep 2005 09:49:10 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010F22BE@cherry.ease.lsoft.com>; 18 Sep 2005 9:43:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85848000 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 18 Sep 2005 09:43:22 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 18 Sep 2005 09:43:22 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8ICvBXK038196; Sun, 18 Sep 2005 05:57:12 -0700 (PDT) References: <1126902769.24495.84.camel@localhost.localdomain> <6.2.1.2.0.20050916210903.02d7e008@localhost> <1126959054.6681.67.camel@localhost.localdomain> <6.2.1.2.0.20050917102650.02cce370@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127050821.29891.18.camel@localhost.localdomain> Date: Sun, 18 Sep 2005 09:40:21 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB link and aliases Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050917102650.02cce370@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit On Sat, 2005-17-09 at 10:32 -0400, Joel M. Halpern wrote: > All of the statements you make to confirm the starting point are accurate > and agreed, but I think the difference is in a subtlety of semantics. > Given an LFB class with a table of net-devices and an LFB instance of that > class, when you want to configure a single net-device, you send a SET > Request whose LFB instance target is that LFB instance. The path within > the SET request will select the table of net-devices and the net-device > table entry, and the fields of that netdevice entry you want to manipulate. > The LFB Link topology information in the FE will only tell you which LFB > instances are interconnected by that link. It will not tell you which > table entry within the LFB instance is using that link. > It is true that from a puristic/literal approach, the topology is basically assuming a model that has LFBSelectors as links. My brain block (and again because i brought this same issue before, please bear with me) comes from the desire to be able to stare at the LFB Topology and be able to tell at least the details of the functional processing blocks. Isnt this why we have that Topological detail? The way i read it now is almost like there is an enforcement for a purely detailed topological modelling - which i thought we said was not practical. What would be nice to see is: "the packet coming in via physical port 0 will be sent to L2 LFB instance 1 which may then send it to one of {PPPOE, SIT} netdevices which leads to the L3 LFB instance 1 followed by {PPPOE, SIT} egress processing that then may branch to any of physical ports 5, 6, 7". which is better eye candy than describing it as: "the packet coming in instance 1 of netdevice LFB will be sent to L2 LFB instance 1 then to netdevice instance 1 which leads to the L3 LFB which then leads to netdevice instance 1" The L2/3 details are sufficient for me to get the details. The netdevice aspect though is too vague in the second description. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Sep 18 18:41:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH7qN-0001no-SR for forces-archive@megatron.ietf.org; Sun, 18 Sep 2005 18:41:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00064 for ; Sun, 18 Sep 2005 18:41:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EH7vo-0004AQ-Qi for forces-archive@IETF.ORG; Sun, 18 Sep 2005 18:46:49 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010F26AC@cherry.ease.lsoft.com>; 18 Sep 2005 18:41:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85866336 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 18 Sep 2005 18:41:00 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 18 Sep 2005 18:41:00 -0400 Received: from [162.83.99.86] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12518328; Sun, 18 Sep 2005 18:41:00 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050918184031.02ccfcd0@localhost> Date: Sun, 18 Sep 2005 18:40:58 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: HA and Heartbeats Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127049919.29891.9.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 We have currently declared that this must be done as separate LFBs. Otherwise you have the problem of which CE sets up the data path. Yours, Joel At 09:25 AM 9/18/2005, Jamal Hadi Salim wrote: >Infact, would it be unreasonable to expect multiple CEs as masters of >different (non-conflicting) LFB instances? > >cheers, >jama From owner-forces@PEACH.EASE.LSOFT.COM Sun Sep 18 18:42:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH7rv-0001yB-MK for forces-archive@megatron.ietf.org; Sun, 18 Sep 2005 18:42:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00128 for ; Sun, 18 Sep 2005 18:42:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EH7xQ-0004Bo-Om for forces-archive@IETF.ORG; Sun, 18 Sep 2005 18:48:25 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010F261E@cherry.ease.lsoft.com>; 18 Sep 2005 18:42:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85866420 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 18 Sep 2005 18:42:36 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 18 Sep 2005 18:42:36 -0400 Received: from [162.83.99.86] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12518336; Sun, 18 Sep 2005 18:42:36 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126902769.24495.84.camel@localhost.localdomain> <6.2.1.2.0.20050916210903.02d7e008@localhost> <1126959054.6681.67.camel@localhost.localdomain> <6.2.1.2.0.20050917102650.02cce370@localhost> <1127050821.29891.18.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050918184125.02d7ec28@localhost> Date: Sun, 18 Sep 2005 18:42:30 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB link and aliases Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127050821.29891.18.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c The LFB Topology is necessary so that the FE can pass the packets from one LFB to another. When topology based multiplexing is used it also tells you what the functional path is. When meta-data based muxing is used the topology does not tell you much about the functional path. Yours, Joel At 09:40 AM 9/18/2005, Jamal Hadi Salim wrote: >On Sat, 2005-17-09 at 10:32 -0400, Joel M. Halpern wrote: > > All of the statements you make to confirm the starting point are accurate > > and agreed, but I think the difference is in a subtlety of semantics. > > Given an LFB class with a table of net-devices and an LFB instance of that > > class, when you want to configure a single net-device, you send a SET > > Request whose LFB instance target is that LFB instance. The path within > > the SET request will select the table of net-devices and the net-device > > table entry, and the fields of that netdevice entry you want to manipulate. > > The LFB Link topology information in the FE will only tell you which LFB > > instances are interconnected by that link. It will not tell you which > > table entry within the LFB instance is using that link. > > > >It is true that from a puristic/literal approach, the topology is >basically assuming a model that has LFBSelectors as links. >My brain block (and again because i brought this same issue before, >please bear with me) comes from the desire to be able to stare at the >LFB Topology and be able to tell at least the details of the functional >processing blocks. Isnt this why we have that Topological detail? >The way i read it now is almost like there is an enforcement for a >purely detailed topological modelling - which i thought we said was not >practical. > >What would be nice to see is: >"the packet coming in via physical port 0 will be sent to L2 LFB >instance 1 which may then send it to one of {PPPOE, SIT} netdevices >which leads to the L3 LFB instance 1 followed by {PPPOE, SIT} egress >processing that then may branch to any of physical ports 5, 6, 7". > >which is better eye candy than describing it as: > >"the packet coming in instance 1 of netdevice LFB will be sent to L2 LFB >instance 1 then to netdevice instance 1 which leads to the L3 LFB which >then leads to netdevice instance 1" > > >The L2/3 details are sufficient for me to get the details. The netdevice >aspect though is too vague in the second description. > >cheers, >jamal From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Mon Sep 19 08:19:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHKcp-0001h1-CV for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 08:19:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16347 for ; Mon, 19 Sep 2005 08:19:57 -0400 (EDT) Received: from almond.ease.lsoft.com ([209.119.0.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHKiN-00053t-Ni for forces-archive@IETF.ORG; Mon, 19 Sep 2005 08:25:48 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.00943D31@almond.ease.lsoft.com>; Mon, 19 Sep 2005 8:19:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85899082 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 08:19:54 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 08:19:53 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8JBXUXK046841 for ; Mon, 19 Sep 2005 04:33:30 -0700 (PDT) References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> <6.2.1.2.0.20050918184031.02ccfcd0@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127132390.29891.77.camel@localhost.localdomain> Date: Mon, 19 Sep 2005 08:19:50 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: HA and Heartbeats To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050918184031.02ccfcd0@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Sun, 2005-18-09 at 18:40 -0400, Joel M. Halpern wrote: > We have currently declared that this must be done as separate > LFBs. Otherwise you have the problem of which CE sets up the data path. Ok, true i remember that we reached such a consensus. Is it captured in any text anywhere? On the heartbeats, the way i see it is we have two options: a) no heartbeats between FE-CE. Clearly this means no knowledge of the availability of the backup CE(s) PL layer. It would mean more needs to be done at the FE in terms of signaling on failover. b) We allow the CEs to only configure their FEPO instance. This violates slightly the decision reached so far. Only difference is that the backup CEs are not configuring the datapath. Any other alternatives? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 08:24:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHKhK-0002Hl-OL for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 08:24:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16566 for ; Mon, 19 Sep 2005 08:24:37 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHKmw-0005BM-Bk for forces-archive@IETF.ORG; Mon, 19 Sep 2005 08:30:27 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010F2E73@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 8:24:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85899188 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 08:24:36 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 08:24:36 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8JBcCXK046879 for ; Mon, 19 Sep 2005 04:38:13 -0700 (PDT) References: <1126902769.24495.84.camel@localhost.localdomain> <6.2.1.2.0.20050916210903.02d7e008@localhost> <1126959054.6681.67.camel@localhost.localdomain> <6.2.1.2.0.20050917102650.02cce370@localhost> <1127050821.29891.18.camel@localhost.localdomain> <6.2.1.2.0.20050918184125.02d7ec28@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127132672.29891.83.camel@localhost.localdomain> Date: Mon, 19 Sep 2005 08:24:32 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB link and aliases To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050918184125.02d7ec28@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit On Sun, 2005-18-09 at 18:42 -0400, Joel M. Halpern wrote: > The LFB Topology is necessary so that the FE can pass the packets from one > LFB to another. > When topology based multiplexing is used it also tells you what the > functional path is. When meta-data based muxing is used the topology does > not tell you much about the functional path. Ok - fine; in any case, the details of the LFB topology are optional. My suggestion: I know that if you take the literal transalation of "LFB Topology" it means just that. But in the case where purely topological model is taken for all the LFBs then it reduces to a functional topology. Can we have some text in the model draft to say that the two may not mean the same thing? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 10:07:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMJC-0002Zk-3j for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 10:07:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22622 for ; Mon, 19 Sep 2005 10:07:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHMOo-00082F-69 for forces-archive@IETF.ORG; Mon, 19 Sep 2005 10:13:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010F3079@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 10:07:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85903285 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 10:07:32 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 10:07:32 -0400 Received: from [162.83.99.86] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12525002; Mon, 19 Sep 2005 10:07:27 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> <6.2.1.2.0.20050918184031.02ccfcd0@localhost> <1127132390.29891.77.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050919100618.02dc9ce0@localhost> Date: Mon, 19 Sep 2005 10:07:23 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: HA and Heartbeats Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127132390.29891.77.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 I am not sure it is any better, but I can think of one other alternative. For compelteness... The configuration of information about relations with backup CEs could be the domain of the FEM, and therefore out of scope for the work for now. This would mean that backup CEs could not configure the heartbeat / livness interval. Yours, Joel At 08:19 AM 9/19/2005, Jamal Hadi Salim wrote: >On Sun, 2005-18-09 at 18:40 -0400, Joel M. Halpern wrote: > > We have currently declared that this must be done as separate > > LFBs. Otherwise you have the problem of which CE sets up the data path. > >Ok, true i remember that we reached such a consensus. Is it captured in >any text anywhere? >On the heartbeats, the way i see it is we have two options: > >a) no heartbeats between FE-CE. Clearly this means no knowledge of the >availability of the backup CE(s) PL layer. It would mean more needs to >be done at the FE in terms of signaling on failover. > >b) We allow the CEs to only configure their FEPO instance. This violates >slightly the decision reached so far. Only difference is that the backup >CEs are not configuring the datapath. > >Any other alternatives? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 10:08:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMK2-0002dy-2h for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 10:08:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22700 for ; Mon, 19 Sep 2005 10:08:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHMPb-00083r-I5 for forces-archive@IETF.ORG; Mon, 19 Sep 2005 10:14:28 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010F30E0@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 10:08:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85903327 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 10:08:36 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 10:08:36 -0400 Received: from [162.83.99.86] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12525042 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 10:08:35 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1126902769.24495.84.camel@localhost.localdomain> <6.2.1.2.0.20050916210903.02d7e008@localhost> <1126959054.6681.67.camel@localhost.localdomain> <6.2.1.2.0.20050917102650.02cce370@localhost> <1127050821.29891.18.camel@localhost.localdomain> <6.2.1.2.0.20050918184125.02d7ec28@localhost> <1127132672.29891.83.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050919100750.02cd2948@localhost> Date: Mon, 19 Sep 2005 10:08:29 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB link and aliases To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127132672.29891.83.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 This sounds like a good clarification. Could you open an issue so that when I get the source I can make sure I do this? Yours, Joel At 08:24 AM 9/19/2005, Jamal Hadi Salim wrote: >On Sun, 2005-18-09 at 18:42 -0400, Joel M. Halpern wrote: > > The LFB Topology is necessary so that the FE can pass the packets from one > > LFB to another. > > When topology based multiplexing is used it also tells you what the > > functional path is. When meta-data based muxing is used the topology does > > not tell you much about the functional path. > >Ok - fine; in any case, the details of the LFB topology are optional. > >My suggestion: >I know that if you take the literal transalation of "LFB Topology" it >means just that. But in the case where purely topological model is taken >for all the LFBs then it reduces to a functional topology. Can we have >some text in the model draft to say that the two may not mean the same >thing? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 11:25:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNWN-0003Un-2m for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:25:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02963 for ; Mon, 19 Sep 2005 11:25:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHNbr-0003dY-42 for forces-archive@IETF.ORG; Mon, 19 Sep 2005 11:31:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010F3269@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 10:55:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85914476 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 10:55:52 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 10:55:48 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 19 Sep 2005 23:31:19 +0800 (CST) References: <1126901337.24495.60.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <002a01c5bd2a$72bb70d0$1f12fea9@wwm1> Date: Mon, 19 Sep 2005 22:57:21 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: HA and Heartbeats To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0i IDxoYWRpQHpueXguY29tPg0KU3ViamVjdDogSEEgYW5kIEhlYXJ0YmVhdHMNCg0KDQo+IFdoaWxl IGNvcnJlbGF0aW5nIGRpZmZlcmVudCBzZWN0aW9uczoNCj4gDQo+IC0tPiBJZiBhIENFIGFuZCBh biBGRSBhcmUgZWFjaCBzZW5kaW5nIGhlYXJ0YmVhdHMgdG8gdGhlIG90aGVyLCBhcmUgdGhleQ0K PiByZXF1aXJlZCB0byB1c2UgdGhlIHNhbWUgdmFsdWVzIGZvciBIQiBJbnRlcnZhbCBhbmQgSEIg RGVhZCBJbnRlcnZhbD8NCj4gSWYgbm90IHdlIG5lZWQgdG8gYmUgY3JlYXRpdmUgd2l0aCBGRVBP LiBJIGtub3cgaXQncyBzbGlnaHRseSBvdXQgb2YNCj4gZGF0ZSBhdCB0aGUgbW9tZW50LCBqdXN0 IHRyeWluZyB0byBjYXB0dXJlIGlzc3Vlcy4NCk15IHRob3VnaHQgaXMsIEhCIEludGVydmFsIGFu ZCBkZWFkIGludGVydmFsIGNhbiBiZSBkaWZmZXJlbnQuIFRoZXkgY2FuIGJlIGRpZmZlcmVudGx5 IGFzc2lnbmVkIHRvIEZFIGJ5IENFIHZpYSB0aGUgQ0UvRkUgaGVhcnRiZWF0IHBvbGljeSBhdHRy aWJ1dGUgZWFzaWx5LiANCg0KPiANCj4gLSBJZiBhbiBGRSBpcyBjb25uZWN0ZWQgdG8gbXVsdGlw bGUgQ0VzIGluIGEgQ0VsaXN0IGZvciBIQSBwdXJwb3NlcyBhbmQNCj4gaXQgaXMgYXNzb2NpYXRl ZCB0byBhbGwgb2YgdGhlbSAoY2xlYXJseSBhbW9uZ3N0IHRoZSBDRXMsIHRoZXJlcyBvbmx5DQo+ IG9uZSB3aGljaCBpcyBhIG1hc3RlciBhdCBhIHRpbWUpLCBvbiBoZWFydGJlYXRzOg0KPiAgICAg ICAgIC0+IERvIHdlIGFsbG93IHRoZSBGRSBzZW5kIGhlYXJ0YmVhdHMgdG8gdGhlIG5vbi1wcmlt YXJ5IENFcz8NCk5vLCBJIHRoaW5rLiBBIG5vbi1wcmltYXJ5IENFIGRvZXMgbm90IG5lZWQgdG8g RkUgYWxpdmVuZXNzIHdoZW4gaXQgaXMgc3RpbGwgc3RhbmQtYnkuDQoNCj4gICAgICAgICAtPiBE byB3ZSBhbGxvdyB0aGUgbm9uLXByaW1hcnkgQ0VzIHNlbmQgaGVhcnRiZWF0cyB0byB0aGUgRkU/ DQpGb3IgdGhlIHNpbXBsaWNpdHkgY29uc2lkZXJhdGlvbiwgSSB0aGluayB3ZSdkIGJldHRlciBu b3Qgc2V0IHNvLiBUaGUgb25seSBmdW5jdGlvbiBvZiBub24tcHJpbWFyeSBDRXMgc2VuZGluZyBo ZWFydGJlYXRzIHRvIEZFIGlzIHRvIGxldCB0aGUgRkUga25vdyB0aGUgbm9uLSBwcmltYXJ5IENF IGFsaXZlbmVzcyBzbyB0aGF0IHRoZSBGRSBtaWdodCB1c2UgdGhlIGluZm8gaW4gaXRzIEhBIHBv bGljeS4gQnV0LCBJIHJlYWxseSBkb24ndCB0aGluayB3ZSBuZWVkIHRoaXMgaW4gY3VycmVudCBI QSBzY2hlbWUuIA0KDQo+ICAgICAgICAgLT4gSWYgc28sIGFyZSB0aGUgQ0VzIHJlcXVpcmVkIHRv IHVzZSB0aGUgc2FtZSB2YWx1ZXMgZm9yIEhCSQ0KPiBhbmQgSEJEST8NClRoZW4sIHdlIGRvbid0 IGhhdmUgc3VjaCBjYXJlLg0KDQpUaGFua3MsDQpXZWltaW5nDQoNCj4gDQo+IEkgaGF2ZSBzb21l IHRob3VnaHRzIC0gYnV0IHdhbnRlZCB0byBzb2xpY2l0IGlucHV0IGZpcnN0Lg0KPiANCj4gY2hl ZXJzLA0KPiBqYW1hbA== From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 11:31:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNcL-0006OJ-0b for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:31:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03217 for ; Mon, 19 Sep 2005 11:31:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHNhy-0003mY-1L for forces-archive@IETF.ORG; Mon, 19 Sep 2005 11:37:31 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010F3103@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 11:27:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85925959 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 11:27:22 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 11:27:06 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8JEecXK048343; Mon, 19 Sep 2005 07:40:38 -0700 (PDT) References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> <6.2.1.2.0.20050918184031.02ccfcd0@localhost> <1127132390.29891.77.camel@localhost.localdomain> <6.2.1.2.0.20050919100618.02dc9ce0@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127143620.6580.0.camel@localhost.localdomain> Date: Mon, 19 Sep 2005 11:27:00 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: HA and Heartbeats Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050919100618.02dc9ce0@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit On Mon, 2005-19-09 at 10:07 -0400, Joel M. Halpern wrote: [..] > The configuration of information about relations with backup CEs could be > the domain of the FEM, and therefore out of scope for the work for > now. This would mean that backup CEs could not configure the heartbeat / > liveness interval. > Ok, could i get two more people to agree to this? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 11:37:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNiP-000760-BV for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:37:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03554 for ; Mon, 19 Sep 2005 11:37:54 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHNo3-0003vR-FT for forces-archive@IETF.ORG; Mon, 19 Sep 2005 11:43:47 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010F3341@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 11:37:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85928799 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 11:37:55 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 11:37:43 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Tue, 20 Sep 2005 00:13:05 +0800 (CST) References: <1126901337.24495.60.camel@localhost.localdomain> <002a01c5bd2a$72bb70d0$1f12fea9@wwm1> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <004701c5bd30$486cb1d0$1f12fea9@wwm1> Date: Mon, 19 Sep 2005 23:39:07 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: HA and Heartbeats To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIldlaW1pbmcgV2FuZyIgPHdt d2FuZ0BtYWlsLnpqZ3N1LmVkdS5jbj4NCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQo+IEZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4LmNvbT4NCj4gU3ViamVj dDogSEEgYW5kIEhlYXJ0YmVhdHMNCj4gDQo+IA0KPiA+IFdoaWxlIGNvcnJlbGF0aW5nIGRpZmZl cmVudCBzZWN0aW9uczoNCj4gPiANCj4gPiAtLT4gSWYgYSBDRSBhbmQgYW4gRkUgYXJlIGVhY2gg c2VuZGluZyBoZWFydGJlYXRzIHRvIHRoZSBvdGhlciwgYXJlIHRoZXkNCj4gPiByZXF1aXJlZCB0 byB1c2UgdGhlIHNhbWUgdmFsdWVzIGZvciBIQiBJbnRlcnZhbCBhbmQgSEIgRGVhZCBJbnRlcnZh bD8NCj4gPiBJZiBub3Qgd2UgbmVlZCB0byBiZSBjcmVhdGl2ZSB3aXRoIEZFUE8uIEkga25vdyBp dCdzIHNsaWdodGx5IG91dCBvZg0KPiA+IGRhdGUgYXQgdGhlIG1vbWVudCwganVzdCB0cnlpbmcg dG8gY2FwdHVyZSBpc3N1ZXMuDQo+IE15IHRob3VnaHQgaXMsIEhCIEludGVydmFsIGFuZCBkZWFk IGludGVydmFsIGNhbiBiZSBkaWZmZXJlbnQuIFRoZXkgY2FuIGJlIGRpZmZlcmVudGx5IGFzc2ln bmVkIHRvIEZFIGJ5IENFIHZpYSB0aGUgQ0UvRkUgaGVhcnRiZWF0IHBvbGljeSBhdHRyaWJ1dGUg ZWFzaWx5LiANCg0KQSBjb3JyZWN0aW9uIG9uIHRoaXMsIEkgbWVhbiB0aGUgSEIgSW50ZXJ2YWwv ZGVhZCBpbnRlcnZhbCBmb3IgQ0UgYW5kIGZvciBGRSBjYW4gYmUgZGlmZmVyZW50Lg0KDQpUaGFu a3MsDQpXZWltaW5nDQog From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 11:39:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNjV-0007LK-Tp for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:39:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03617 for ; Mon, 19 Sep 2005 11:39:03 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHNp8-0003xV-Ps for forces-archive@IETF.ORG; Mon, 19 Sep 2005 11:44:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010F334B@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 11:39:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85929190 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 11:38:57 -0400 Received: from 81.228.8.182 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 11:38:47 -0400 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id D82D937E9F; Mon, 19 Sep 2005 17:38:46 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id AABBC37E91 for ; Mon, 19 Sep 2005 17:38:46 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 9A95537E48 for ; Mon, 19 Sep 2005 17:38:44 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EHNj9-0007Bz-Pj for forces@peach.ease.lsoft.com; Mon, 19 Sep 2005 17:38:44 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.5 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Jamal Hadi Salim Message-ID: <1127144323.13.0.147506533609.issue60@mip4.org> Date: Mon, 19 Sep 2005 15:38:43 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: [issue60] FE Object LFB Topology To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable New submission from Jamal Hadi Salim : There are two ways a LFB can be modeled and as a result be controlled and process packets. a) Some LFBs may be modelled such that topology based packet multiplexing is used. In such a case all instances of the LFB could be uniquely identified = with an LFB selector when configuring.=20 b) Others may use metadatum instead for packet multiplexing. Such is the ca= se in LFBs which are modeled to have a single LFB instance that holds multiple functional processing instances in a table. In such a case the LFB selector= will identify the single LFB instance. To configure the functional packet proces= sing one would need to further specify a path. The consequences of this are that FEO LFB Topology while showing the=20 full functional processing if all LFBs are modelled as #a above, it will no= t=20 fully show those details when any LFB uses the #b model. It is practical convinience to use #b sometimes - so we are not enforcing m= odel #a be used. ---------- category: Editorial draft: draft-ietf-forces-model messages: 341 nosy: jamal priority: Must fix status: Need clarifying text title: FE Object LFB Topology ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 11:39:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNk2-0007Q8-Vd for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:39:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03639 for ; Mon, 19 Sep 2005 11:39:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHNph-0003yN-93 for forces-archive@IETF.ORG; Mon, 19 Sep 2005 11:45:29 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010F3166@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 11:39:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85929407 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 11:39:37 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 11:39:30 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8JEr4XK048445; Mon, 19 Sep 2005 07:53:05 -0700 (PDT) References: <1126902769.24495.84.camel@localhost.localdomain> <6.2.1.2.0.20050916210903.02d7e008@localhost> <1126959054.6681.67.camel@localhost.localdomain> <6.2.1.2.0.20050917102650.02cce370@localhost> <1127050821.29891.18.camel@localhost.localdomain> <6.2.1.2.0.20050918184125.02d7ec28@localhost> <1127132672.29891.83.camel@localhost.localdomain> <6.2.1.2.0.20050919100750.02cd2948@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127144367.6580.4.camel@localhost.localdomain> Date: Mon, 19 Sep 2005 11:39:27 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB link and aliases Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050919100750.02cd2948@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit On Mon, 2005-19-09 at 10:08 -0400, Joel M. Halpern wrote: > This sounds like a good clarification. > Could you open an issue so that when I get the source I can make sure I do > this? Issue #60 opened. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 12:07:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHOAy-00068K-9c for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 12:07:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05037 for ; Mon, 19 Sep 2005 12:07:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHOGY-0004gJ-Cw for forces-archive@IETF.ORG; Mon, 19 Sep 2005 12:13:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010F3340@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 12:07:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85945815 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 12:07:22 -0400 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 12:07:21 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j8JG7LSU197150 for ; Mon, 19 Sep 2005 16:07:21 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8JG7K6u228606 for ; Mon, 19 Sep 2005 17:07:20 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j8JG7K4P022099 for ; Mon, 19 Sep 2005 17:07:20 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j8JG7Krd022096; Mon, 19 Sep 2005 17:07:20 +0100 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA47580; Mon, 19 Sep 2005 18:07:19 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1126892814.24495.51.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.uk.ibm.com id j8JG7LSU197150 Approved-By: Robert Haas Message-ID: <432EE236.9050104@zurich.ibm.com> Date: Mon, 19 Sep 2005 18:07:18 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Multicast IDs Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126892814.24495.51.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Jamal, Jamal Hadi Salim wrote: >>From section 5.1. Common Header > > >-- > g. It is desirable to address multicast and/or broadcast > messages to some LFB instances of a given class. For > instance, assume FEs FEa and FEb: > > - FEa has LFBs LFBaX1 and LFBaX2 of class X > > - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of > class X. > > A broadcast message should be addressable to only LFBs > LFBaX1 and LFBbX1 (this can be the case for instance if > these two LFBs belong to the same VPN). To achieve this, > a VPN ID (3 octets OUI and 4 octets VPN Index) as defined > in RFC 2685 should be used within the ForCES message > body as a TLV. > > =20 > If I recall well, we are not going to use a VPN ID TLV. So I suggest to drop the paragraph and only keep the alternative (below). Regards, -Robert > As an alternative, a particular multicast ID MAY be > associated to a given VPN ID through some configuration > means. Messages delivered to such a multicast ID MUST > only be applied to LFBs belonging to that VPN ID. >----- > >Robert, I think this text came from you. >If we are going to allow the first scheme - then for interop we need to >have more definition. The second scheme would work fine without explicit >detailing. > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 12:07:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHOBB-0006Bu-NB for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 12:07:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05058 for ; Mon, 19 Sep 2005 12:07:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHOGq-0004gz-6K for forces-archive@IETF.ORG; Mon, 19 Sep 2005 12:13:32 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010F32D9@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 12:07:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85945834 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 12:07:39 -0400 Received: from 195.212.29.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 12:07:39 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8JG7bTZ158318 for ; Mon, 19 Sep 2005 16:07:37 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8JG7blo181112 for ; Mon, 19 Sep 2005 18:07:37 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8JG7bH5016095 for ; Mon, 19 Sep 2005 18:07:37 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8JG7aRD016081; Mon, 19 Sep 2005 18:07:37 +0200 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA28806; Mon, 19 Sep 2005 18:07:36 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1126891893.24495.45.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.de.ibm.com id j8JG7bTZ158318 Approved-By: Robert Haas Message-ID: <432EE248.2070105@zurich.ibm.com> Date: Mon, 19 Sep 2005 18:07:36 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: version field in the header Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1126891893.24495.45.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable I think we should leave it as currently . Regards, -Robert Jamal Hadi Salim wrote: >Folks, >did we decide we are going to make the version field to be 8 bits? >At the moment we have in the first word: > >version(4bits):rsvd(4bits):Type(8bits):Length(16bits) > > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 12:08:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHOBi-0006Gh-2X for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 12:08:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05080 for ; Mon, 19 Sep 2005 12:08:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHOHL-0004hl-L1 for forces-archive@IETF.ORG; Mon, 19 Sep 2005 12:14:04 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010F32E8@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 12:08:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85945865 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 12:08:11 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 12:08:11 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id j8JFpgHC018742 for ; Mon, 19 Sep 2005 17:51:42 +0200 Mime-Version: 1.0 (Apple Message framework v734) References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> <6.2.1.2.0.20050918184031.02ccfcd0@localhost> <1127132390.29891.77.camel@localhost.localdomain> <6.2.1.2.0.20050919100618.02dc9ce0@localhost> <1127143620.6580.0.camel@localhost.localdomain> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Approved-By: Avri Doria Message-ID: <74B4B35E-537B-4AD5-815F-8A297054701D@psg.com> Date: Mon, 19 Sep 2005 18:08:05 +0200 Reply-To: Avri Doria Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: HA and Heartbeats To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127143620.6580.0.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit I agree with the idea that FE should only configure and send HB to the controlling CE. And that the backup CE should not be configuring/ sending HB to the FEs. It is up to the CEs to have coordinated information. The CE should have a means of communicating the state of the FE under their care. Of course this work is not currently in scope. a. On 19 sep 2005, at 17.27, Jamal Hadi Salim wrote: > On Mon, 2005-19-09 at 10:07 -0400, Joel M. Halpern wrote: > [..] > >> The configuration of information about relations with backup CEs >> could be >> the domain of the FEM, and therefore out of scope for the work for >> now. This would mean that backup CEs could not configure the >> heartbeat / >> liveness interval. >> >> > > Ok, could i get two more people to agree to this? > > cheers, > jamal > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 12:14:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHOHN-00071E-7g for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 12:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05323 for ; Mon, 19 Sep 2005 12:14:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHON0-0004qP-P3 for forces-archive@IETF.ORG; Mon, 19 Sep 2005 12:19:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010F336F@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 12:14:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85946608 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 12:14:02 -0400 Received: from 195.212.29.136 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 12:14:02 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j8JGEBHp284104 for ; Mon, 19 Sep 2005 17:14:11 +0100 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8JGE16u220262 for ; Mon, 19 Sep 2005 17:14:01 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j8JGE0gf000678 for ; Mon, 19 Sep 2005 17:14:00 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j8JGE0fj000670; Mon, 19 Sep 2005 17:14:00 +0100 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA46152; Mon, 19 Sep 2005 18:14:00 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> <6.2.1.2.0.20050918184031.02ccfcd0@localhost> <1127132390.29891.77.camel@localhost.localdomain> <6.2.1.2.0.20050919100618.02dc9ce0@localhost> <1127143620.6580.0.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.uk.ibm.com id j8JGEBHp284104 Approved-By: Robert Haas Message-ID: <432EE3C7.20300@zurich.ibm.com> Date: Mon, 19 Sep 2005 18:13:59 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: HA and Heartbeats Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127143620.6580.0.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable This would mean that when changing from the primary to the backup CE,=20 the FE would have to first setup an association with the backup CE. The=20 reason I say this is because I don't think an association without=20 liveliness checks (heartbeat excahnges) makes much sense. Regards, -Robert Jamal Hadi Salim wrote: >On Mon, 2005-19-09 at 10:07 -0400, Joel M. Halpern wrote: >[..] > =20 > >>The configuration of information about relations with backup CEs could = be=20 >>the domain of the FEM, and therefore out of scope for the work for=20 >>now. This would mean that backup CEs could not configure the heartbeat= /=20 >>liveness interval. >> >> =20 >> > >Ok, could i get two more people to agree to this? > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 12:11:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHOF3-0006fo-CF for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 12:11:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05199 for ; Mon, 19 Sep 2005 12:11:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHOKh-0004mL-0H for forces-archive@IETF.ORG; Mon, 19 Sep 2005 12:17:32 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010F3287@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 12:11:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85946106 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 12:11:36 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 12:11:35 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8JFPAXK048763; Mon, 19 Sep 2005 08:25:10 -0700 (PDT) References: <1126892814.24495.51.camel@localhost.localdomain> <432EE236.9050104@zurich.ibm.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127146293.6580.12.camel@localhost.localdomain> Date: Mon, 19 Sep 2005 12:11:33 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Multicast IDs Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <432EE236.9050104@zurich.ibm.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Robert, On Mon, 2005-19-09 at 18:07 +0200, Robert Haas wrote: > Jamal, > > > If I recall well, we are not going to use a VPN ID TLV. > So I suggest to drop the paragraph and only keep the alternative (below). > Regards, Sounds reasonable. Can i also change the term VPN to be group? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 12:12:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHOG1-0006oV-Ko for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 12:12:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05244 for ; Mon, 19 Sep 2005 12:12:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHOLg-0004ns-5K for forces-archive@IETF.ORG; Mon, 19 Sep 2005 12:18:32 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010F339B@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 12:12:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85946413 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 12:12:40 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 12:12:39 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8JFQEXK048773; Mon, 19 Sep 2005 08:26:14 -0700 (PDT) References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> <6.2.1.2.0.20050918184031.02ccfcd0@localhost> <1127132390.29891.77.camel@localhost.localdomain> <6.2.1.2.0.20050919100618.02dc9ce0@localhost> <1127143620.6580.0.camel@localhost.localdomain> <74B4B35E-537B-4AD5-815F-8A297054701D@psg.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127146357.6580.13.camel@localhost.localdomain> Date: Mon, 19 Sep 2005 12:12:37 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: HA and Heartbeats Comments: To: Avri Doria To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <74B4B35E-537B-4AD5-815F-8A297054701D@psg.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit On Mon, 2005-19-09 at 18:08 +0200, Avri Doria wrote: > I agree with the idea that FE should only configure and send HB to > the controlling CE. And that the backup CE should not be configuring/ > sending HB to the FEs. > > It is up to the CEs to have coordinated information. > The CE should have a means of communicating the state of the FE > under their care. Of course this work is not currently in scope. Thanks Avri - I think we have a hum; i will capture this. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 12:16:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHOJO-0007KX-D3 for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 12:16:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05449 for ; Mon, 19 Sep 2005 12:16:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHOP1-0004tp-Qp for forces-archive@IETF.ORG; Mon, 19 Sep 2005 12:22:01 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010F3308@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 12:16:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85946863 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 12:16:07 -0400 Received: from 195.212.29.136 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 12:16:07 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j8JGGCHp155268 for ; Mon, 19 Sep 2005 17:16:13 +0100 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8JGG26u221018 for ; Mon, 19 Sep 2005 17:16:02 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j8JGG2hX002936 for ; Mon, 19 Sep 2005 17:16:02 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j8JGG1CK002931; Mon, 19 Sep 2005 17:16:01 +0100 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA39076; Mon, 19 Sep 2005 18:16:01 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1126892814.24495.51.camel@localhost.localdomain> <432EE236.9050104@zurich.ibm.com> <1127146293.6580.12.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.uk.ibm.com id j8JGGCHp155268 Approved-By: Robert Haas Message-ID: <432EE440.30807@zurich.ibm.com> Date: Mon, 19 Sep 2005 18:16:00 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Multicast IDs Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127146293.6580.12.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Jamal Hadi Salim wrote: >Robert, > >On Mon, 2005-19-09 at 18:07 +0200, Robert Haas wrote: > =20 > >>Jamal, >> =20 >> > > =20 > >>If I recall well, we are not going to use a VPN ID TLV. >>So I suggest to drop the paragraph and only keep the alternative (below= ). >>Regards, >> =20 >> > >Sounds reasonable. >Can i also change the term VPN to be group? > =20 > sure. Regards, -Robert >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 12:19:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHOME-0000FI-U3 for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 12:19:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05664 for ; Mon, 19 Sep 2005 12:19:03 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHORt-0004yf-I5 for forces-archive@IETF.ORG; Mon, 19 Sep 2005 12:24:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010F32EF@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 12:19:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85947305 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 12:19:05 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 12:19:05 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8JFWdXK048852; Mon, 19 Sep 2005 08:32:39 -0700 (PDT) References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> <6.2.1.2.0.20050918184031.02ccfcd0@localhost> <1127132390.29891.77.camel@localhost.localdomain> <6.2.1.2.0.20050919100618.02dc9ce0@localhost> <1127143620.6580.0.camel@localhost.localdomain> <432EE3C7.20300@zurich.ibm.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127146742.6580.18.camel@localhost.localdomain> Date: Mon, 19 Sep 2005 12:19:02 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: HA and Heartbeats Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <432EE3C7.20300@zurich.ibm.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit On Mon, 2005-19-09 at 18:13 +0200, Robert Haas wrote: > This would mean that when changing from the primary to the backup CE, > the FE would have to first setup an association with the backup CE. The > reason I say this is because I don't think an association without > liveliness checks (heartbeat excahnges) makes much sense. > I think what you are saying also makes sense - even though unfortunately we are in a rush to close this issue. Could other people comment on this? Note, if one was to use a CEID that is multicast, then all these issues will disappear i.e some repsonsibilities shift to the TML; the FE is oblivious about who sends or receives HBs or which real CE was associated to. Of course this model is not disallowed by current setup. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 13:08:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHP8H-0006EH-Lr for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 13:08:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07826 for ; Mon, 19 Sep 2005 13:08:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHPDs-00067A-BR for forces-archive@IETF.ORG; Mon, 19 Sep 2005 13:14:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010F344A@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 13:08:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 85952218 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 13:08:33 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 13:08:33 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8JH8Wox027192 for ; Mon, 19 Sep 2005 17:08:32 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8JH8EMT018609 for ; Mon, 19 Sep 2005 17:08:32 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005091910073206044 for ; Mon, 19 Sep 2005 10:07:33 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 10:06:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Conference calls info for this week Thread-Index: AcW5B2y0R55iFFS6QDOUsFpXelbP5gD5g0XQAAAvpCA= X-OriginalArrivalTime: 19 Sep 2005 17:06:06.0912 (UTC) FILETIME=[6CB07C00:01C5BD3C] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06B76846@orsmsx408> Date: Mon, 19 Sep 2005 10:06:05 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Conference calls info for this week To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Here is the conference call info for this week...=20 Thursday, September 22, 2005 7:00 AM US Pacific Time=20 Where: 916-356-2663, Bridge: 2, Passcode: 6347732=20 Friday, September 23, 2005 7:00 AM US Pacific Time=20 Where: 916-356-2663, Bridge: 3, Passcode: 2310799=20 Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 19 22:43:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHY6w-0002hR-8R for forces-archive@megatron.ietf.org; Mon, 19 Sep 2005 22:43:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16278 for ; Mon, 19 Sep 2005 22:43:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHYCf-0005lI-Jn for forces-archive@IETF.ORG; Mon, 19 Sep 2005 22:49:54 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010F3B41@cherry.ease.lsoft.com>; Mon, 19 Sep 2005 22:43:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86004866 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Sep 2005 22:43:55 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Sep 2005 22:43:51 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Tue, 20 Sep 2005 11:19:29 +0800 (CST) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126885065.24495.32.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <005701c5bd8d$5d301dc0$1f12fea9@wwm1> Date: Tue, 20 Sep 2005 10:45:27 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: base64 SmFtYWwsDQoNCkknbSBzb3JyeSB0byByZXBseSBhIGJpdCBsYXRlLiBJJ20gYWN0dWFsbHkgdHJ5 aW5nIHRvIHVuZGVyc3RhbmQgeW91ciBtZWFuaW5nIG9mIEZFIE1VU1QgYW5kIENFIE1VU1QgZm9y IGhlYXJ0YmVhdCBnZW5lcmF0aW5nIGluIHlvdXIgcmVzcG9uc2UuIEkganVzdCBmb3VuZCBpdCBp cyBpbmNvbnNpc3RlbnQgaW4gc29tZSB3YXksIHRoZXJlZm9yZSBoYXJkIHRvIGZvbGxvdyB5b3Vy IG1lYW5pbmcuIEknbSBub3Qgc3VyZSBpZiB5b3UgYWN0dWFsbHkgbWVhbiAiRkUgTVVTVCBnZW5l cmF0ZSBIQnMiIGluc3RlYWQgb2YgIkNFIE1VU1QiLiBNeSBnZW5lcmFsIGNvbW1lbnQgaXMsIHRo ZSBzY2hlbWUgZm9yIGEgIm5vIGhlYXJ0YmVhdCIgb2YgZWl0aGVyIENFIG9yIEZFIHNob3VsZCBi ZSBhbGxvd2VkLCBzbyBhcyB0byBzdXBwb3J0IGEgdmVyeSBjb25maWRlbnQgc3lzdGVtLCB3aGVy ZSBpbXBsZW1lbnRvcnMgYmVsaWV2ZSB0aGV5IGRvbid0IG5lZWQgdGhlIEhCcyBhdCBhbGwgZm9y IHRoZSBsaXZlbmVzcyBjaGVjay4NCg0KSSBzZWUgdGhlIG1haW4gZGlmZmVyZW5jZSBseWluZyBi ZXR3ZWVuIHVzIGlzLCBpZiB5b3Ugbm93IGFncmVlIHRvIGFsbG93IHRoZSBIQiBzY2hlbWUgYXMg dGhlIEZFIGF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVzIEhCIG1lc3NhZ2VzIHJhdGhlciB0aGFuIGp1 c3QgcmVzb25zZSB0byBDRSBIQiBtZXNzYWdlcz8gDQoNCkkgY2FuIGFjdHVhbGx5IGFncmVlIHRv IGxldCB0aGUgc2NoZW1lIHlvdSBwcm9wb3NlZCBhcyBhIGRlZnVhbHQgc2NoZW1lLg0KDQpCYXNl ZCBvbiB5b3VyIGlkZWEgYW5kIG15IHRob3VnaHRzIGFib3ZlLCBJIHRyeSB0byBzdW1tYXJpemUg dGhlIHRleHQgYWdhaW4gYXMgYmVsb3csIHBscyBqdXN0IGNvbW1lbnRzIG1vcmU6DQoNCjxjaGFu Z2UgdG8+DQpGRSBQcm90b2NvbCBhdHRyaWJ1dGVzIChjYW4gYmUgcmVhZCBhbmQgc2V0KToNCi4u Lg0KKiBIZWFydGJlYXQgcG9saWN5IGFuZCBwYXJhbWV0ZXJzLCB3aGljaCBpbmNsdWRlcyBmaWVs ZHMgYXM6DQoNCiAgLiBDRSBoZWFydGJlYXQgcG9saWN5IC0gVGhpcyBwb2xpY3kgYWN0dWFsbHkg dGVsbHMgdGhlIEZFIGhvdyB0byBjaGVjayB0aGUgQ0UgbGl2ZW5lc3MuIHRvIHRlbGwgRkUgd2hp Y2ggaGVhcnRiZWF0IHBvbGljeSB0aGUgQ0UgY2hvb3Nlcywgc28gdGhhdCBGRSBjYW4gY2hlY2sg dGhlIENFIGxpdmVuZXNzIGJhc2VkIG9uIHRoaXMgcG9saWN5LiBUaGUgdmFsdWVzIGFyZToNCg0K ICAgICAgIDAoZGVmYXVsdCkgLSBUaGlzIHBvbGljeSBzcGVjaWZpZXMgdGhhdCBDRSB3aWxsIHNl bmQgYSBIZWFydGJlYXQgTWVzc2FnZSB0byBGRSB3aGVuZXZlciBDRSByZWFjaGVzIGEgdGltZSBp bnRlcnZhbCB3aXRoaW4gd2hpY2ggbm8gYW55IG90aGVyIG1lc3NhZ2VzIHdlcmUgc2VudCBmcm9t IENFIHRvIEZFLiBBc3NvY2lhdGVkIHdpdGggdGhpcyBwb2xpY3kgaXMgYSAnQ0UgaGVhcnRiZWF0 IGRlYWQgaW50ZXJ2YWwnIHBhcmFtZXRlciBhcyBkZXNjcmliZWQgYmVsb3cuIEZFIGNoZWNrIHRo ZSBDRSBsaXZlbmVzcyBqdXN0IGJ5IGNoZWNraW5nIGlmIGl0IGhhcyBvciBoYXMgbm90IHJlY2Vp dmVkIGFueSBtZXNzYWdlIChpbmNsdWRpbmcgSGVhcnRiZWF0IE1lc3NhZ2UpIGZvciB0aGUgJ0NF IGhlYXJ0YmVhdCBkZWFkIGludGVydmFsJyBwZXJpb2QuDQoNCiAgICAgICAxIC0gVGhpcyBwb2xp Y3kgc3BlY2lmaWVzIHRoYXQgQ0Ugd2lsbCBub3Qgc2VuZCBhbnkgSGVhcnRiZWF0IE1lc3NhZ2Ug dG8gRkUgaW4gYW55IGNhc2UuIFRoaXMgYWN0dWFsbHkgbWVhbnMgQ0UgZG9lcyBub3Qgd2FudCB0 byBhc2sgRkUgdG8gY2hlY2sgdGhlIENFIGxpdmVuZXNzLiANCg0KICAgICAgIE90aGVycyAtIHJl c2VydmVkLg0KDQogICAuIEZFIGhlYXJ0YmVhdCBwb2xpY3kgLSBUaGlzIHBvbGljeSB0ZWxscyBG RSBob3cgaXQgc2hvdWxkIGFjdCBzbyB0aGF0IENFIGNhbiBjaGVjayBpdHMgbGl2ZW5lc3MgYmFz ZWQgb24gdGhlIGFjdGlvbnMuIFRoZSB2YWx1ZXMgYXJlOg0KDQogICAgICAgMChkZWZhdWx0KSAt IFRoaXMgcG9saWN5IGFjdHVhbGx5IHNwZWNpZmllcyBubyBtb3JlIGFjdGlvbiBmb3IgRkUgaGVh cnRiZWF0IGdlbmVyYXRpb24uIFRvIGxldCBDRSBjaGVjayBpdHMgbGl2ZW5lc3MsIHRoZSBGRSBt YXkgb25seSBqdXN0IG1ha2UgcmVzcG9uc2VzIHRvIENFIHdoZW4gQ0Ugc2VuZHMgSGVhcnRiZWF0 IFJlcXVlc3QgTWVzc2FnZSAoYWxzbyBhIG5vcm1hbCBIQiBtZXNzYWdlLCBvbmx5IHdpdGggd2hv c2UgQUNLIGZsYWcgaXMgc2V0IHRvIEFsd2F5c0FDSykgd2l0aCBhIEhlYXJ0YmVhdCBSZXNwb25z ZSBNZXNzYWdlIChhbHNvIGEgbm9ybWFsIEhCIG1lc3NhZ2UsIG9ubHkgd2l0aCB3aG9zZSBBQ0sg ZmxhZyBpcyBzZXQgdG8gTm9BQ0spLiANCg0KICAgICAgIDEgLSBUaGlzIHBvbGljeSBzcGVjaWZp ZXMgdGhhdCBGRSBtdXN0IGFjdGl2ZWx5IHNlbmQgYSBIZWFydGJlYXQgTWVzc2FnZSBpZiBpdCBy ZWFjaGVzIGEgdGltZSBpbnRlcnZhbCwgd2l0aGluIHdoaWNoIG5vIGFueSBvdGhlciBtZXNzYWdl cyB3ZXJlIHNlbnQgZnJvbSBGRSB0byBDRS4gVGhlIHRpbWUgaW50ZXJ2YWwgaXMgY2FsbGVkIEZF IGhlYXJ0YmVhdCBpbnRlcnZhbCwgYW5kIGlzIHNldCBhcyBiZWxvdy4NCg0KICAgICAgIE90aGVy cyAtIFJlc2VydmVkLg0KDQogICAuIENFIGhlYXJ0YmVhdCBkZWFkIGludGVydmFsIC0gdG8gdGVs bCBGRSB0aGUgdGltZSBpbnRlcnZhbCB0aGUgQ0UgdXNlcyB0byBjaGVjayB0aGUgQ0UgbGl2ZW5l c3MuIElmIEZFIGhhcyBub3QgcmVjZWl2ZWQgYW55IG1lc3NhZ2VzIGZyb20gQ0UgZm9yIHRoaXMg dGltZSBpbnRlcnZhbCwgRkUgbWF5IG1ha2UgYSBjb25jbHVzaW9uIHRoYXQgdGhlIENFIGlzIGRl YWQgb3IgdGhlIGFzc29jaWF0aW9uIHRvIHRoZSBDRSBpcyBsb3N0LiBJZiBzZXQgdG8gMCwgaXQg bWVhbnMgdG8gY2hvb3NlIGEgZGVmYXVsdCB2YWx1ZS4gKENvbW1lbnRzOiBub3RlIHRoYXQgQ0Ug ZG9lcyBub3QgbmVlZCB0byB0ZWxsIEZFIHRoZSBDRSBoZWFydGJlYXQgaW50ZXJ2YWwgdGhlbi4p DQoNCiAgIC4gRkUgaGVhcnRiZWF0IGludGVydmFsIC0gdG8gY29tbWFuZCBGRSB0byB1c2UgdGhl IGludGVydmFsIGZvciB0aGUgRkUgSGVhcnRiZWF0IE1lc3NhZ2UgZ2VuZXJhdGlvbi4gSWYgc2V0 IHRvIDAsIGl0IG1lYW5zIEZFIG11c3QgY2hvb3NlIGEgZGVmYXVsdCB2YWx1ZS4gKENvbW1lbnRz OiBOb3RlIHRoYXQgQ0UgZG9lcyBub3QgbmVlZCB0byBzZXQgaGVhcnRiZWF0IGRlYWQgaW50ZXJ2 YWwgZm9yIEZFLikNCg0KPC9jaGFuZ2UgdG8+DQoNCkJhc2VkIG9uIGFib3ZlIHNvbHV0aW9uIHBy b2ZpbGUsIEkgdGhpbmsgdGhlIEZFIGNhcGFiaWxpdHkgZm9yIGhlYXJ0YmVhdCBnZW5lcmF0aW9u IGlzIHN0aWxsIG5lY2Vzc2FyeS4gTW9yZSBleHBsYWluYXRpb24gYXM6DQoNCiAgICogIEZFIGNh cGFiaWxpdHkgdG8gZ2VuZXJhdGUgSGVhdGJlYXRzOiBJbmNhcGFibGUgKHZhbHVlPTApb3IgQ2Fw YWJsZSh2YWx1ZT0xKS4gVGhpcyBjYXBhYmlsaXR5IGFjdHVhbGx5IHRlbGxzIENFIGlmIHRoZSBG RSBpcyBjYXBhYmxlIG9mIGFjdGl2ZWx5IGdlbmVyYXRpbmcgSGVhcnRiZWF0IE1lc3NhZ2VzIGF0 IGEgdGltZSBpbnRlcnZhbHMsIHdoaWNoIG1hdGNoZXMgdGhlIEZFIGhlYXJ0YmVhdCBwb2xpY3kg Y2FzZSAxLiBJZiBpbmNhcGFibGUsIHRoZSBGRSB3aWxsIG5vdCBiZSBhYmxlIHRvIHN1cHBvcnQg dGhpcyBwb2xpY3kuICAgICAgDQoNClRoYW5rcywNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4LmNvbT4N Cg0KPiBUbyBjbGFyaWZ5IHNvIHdlIGNhbiBjbG9zZS4NCj4gU29tZW9uZSBwbGVhc2UgYm91bmNl IHRoaXMgbWVzc2FnZSB0byBXZWltaW5nIGFzIHdlbGwgaW5jYXNlIGhlIGRvZXNudA0KPiBzZWUg aXQuIEkgc2VlIHRvIGhhdmUgcHJvYmxlbXMgc2VuZGluZyBlbWFpbHMgdG8gaGltIHNvbWV0aW1l cy4NCj4gDQo+ID4gT24gMTYgc2VwIDIwMDUsIGF0IDA2LjAyLCBXYW5nLFdlaW1pbmcgd3JvdGU6 DQo+ID4gDQo+ID4gPiBIaSwNCj4gPiA+DQo+ID4gPiBIZXJlIGlzIHRoZSB0ZXh0IHByb3Bvc2Vk IGZvciB0aGUgSEIuIFBscyBjb21tZW50cy4NCj4gPiA+DQo+ID4gPiBGb3IgRkUgY2FwYWJpbGl0 eSBmb3IgaGVhcnRiZWF0czoNCj4gPiA+DQo+ID4gPiA8b3JpZ2luYWw+DQo+ID4gPiAgbyAgRkUg UHJvdG9jb2wgY2FwYWJpbGl0aWVzIChyZWFkLW9ubHkpOg0KPiA+ID4NCj4gPiA+ICAgICAgICog IFN1cHBvcnRlZCBGb3JDRVMgcHJvdG9jb2wgdmVyc2lvbihzKSBieSB0aGUgRkUNCj4gPiA+DQo+ ID4gPiAgICAgICAqICBTdXBwb3J0ZWQgRm9yQ0VTIEZFIG1vZGVsKHMpIGJ5IHRoZSBGRQ0KPiA+ ID4NCj4gPiA+ICAgICAgICogIFNvbWUgVE1MIGNhcGFiaWxpdHkgZGVzY3JpcHRpb24ocykNCj4g PiA+IDwvb3JpZ2luYWw+DQo+ID4gPg0KPiA+ID4gPGNoYW5nZXRvPg0KPiA+ID4gIG8gIEZFIFBy b3RvY29sIGNhcGFiaWxpdGllcyAocmVhZC1vbmx5KToNCj4gPiA+DQo+ID4gPiAgICAgICAqICBT dXBwb3J0ZWQgRm9yQ0VTIHByb3RvY29sIHZlcnNpb24ocykgYnkgdGhlIEZFDQo+ID4gPg0KPiA+ ID4gICAgICAgKiAgU3VwcG9ydGVkIEZvckNFUyBGRSBtb2RlbChzKSBieSB0aGUgRkUNCj4gPiA+ DQo+ID4gPiAgICAgICAqICBTb21lIFRNTCBjYXBhYmlsaXR5IGRlc2NyaXB0aW9uKHMpDQo+ID4g Pg0KPiA+ID4gICAgICAgKiAgRkUgY2FwYWJpbGl0eSB0byBnZW5lcmF0ZSBIZWF0YmVhdHM6IENh cGFibGUgb3IgSW5jYXBhYmxlLg0KPiA+ID4gPC9jaGFuZ2V0bz4NCj4gPiA+DQo+IA0KPiBBcyBw ZXIgY29uY2FsLCB3ZSBhcmUgbm93IHNheWluZyB0aGUgRkUgTVVTVCBpbXBsZW1lbnQgaGVhcnRi ZWF0cyBidXQgQ0UNCj4gY2FuIHR1cm4gdGhlIGdlbmVyYXRpb24gb2YgaGVhcnRiZWF0cyBvZmYu IFdoaWNoIG1lYW5zIHdlIGRvbnQgbmVlZA0KPiBjYXBhYmlsaXR5IGFib3ZlLg0KPiANCj4gPiA+ IEZvciBGRSBhdHRyaWJ1dGVzIGZvciBoZWFydGJlYXRzOg0KPiA+ID4NCj4gPiA+IDxvcmlnaW5h bCBQLjQyPg0KPiA+ID4gRkUgUHJvdG9jb2wgYXR0cmlidXRlcyAoY2FuIGJlIHJlYWQgYW5kIHNl dCk6DQo+ID4gPiAuLi4NCj4gPiA+ICAgICAgICogIEhlYXJ0YmVhdCBJbnRlcnZhbC4gIERlZnVh bHQgVmFsdWUgPSAzMDAgbXNlYw0KPiA+ID4gPC9vcmlnaW5hbCBQLjQyPg0KPiA+ID4NCj4gPiA+ IDxjaGFuZ2UgdG8+DQo+ID4gPiBGRSBQcm90b2NvbCBhdHRyaWJ1dGVzIChjYW4gYmUgcmVhZCBh bmQgc2V0KToNCj4gPiA+IC4uLg0KPiA+ID4gICAgICAgKiBIZWFydGJlYXQgcG9saWN5IGFuZCBw YXJhbWV0ZXJzLCB3aGljaCBpbmNsdWRlcyBmaWVsZHMgYXM6DQo+ID4gPg0KPiA+ID4gICAgICAg ICAuIEhlYXJ0YmVhdCBwb2xpY3ksIHdoaWNoIGZ1cnRoZXIgaW5jbHVkZXMgdHdvIGZpZWxkczoN Cj4gPiA+DQo+ID4gPiAgICAgICAgICAgIENFIGhlYXJ0YmVhdCBwb2xpY3k6IHRvIHRlbGwgRkUg d2hpY2ggaGVhcnRiZWF0IHBvbGljeSAgDQo+ID4gPiB0aGUgQ0UgY2hvb3Nlcy4NCj4gPiA+DQo+ ID4gPiAgICAgICAgICAgICAwIC0gQ0Ugbm8gaGVhcnRiZWF0LiBJbiB0aGlzIGNhc2UsIENFIGRv ZXMgbm90IHNlbmQgYW55ICANCj4gPiA+IEhlYXJ0YmVhdCBtZXNzYWdlcyB0byBGRS4NCj4gPiA+ ICAgICAgICAgICAgIDEgLSBDRSBub3JtYWwgaGVhcnRiZWF0LiBJbiB0aGlzIGNhc2UsIENFIHNl bmRzICANCj4gPiA+IEhlYXJ0YmVhdCBtZXNzYWdlcyB0byBGRSBhdCB0aGUgdGltZSBpbnRlcnZh bHMgc3BlY2lmaWVkIGJ5IHRoZSBDRSAgDQo+ID4gPiBoZWFydGViZWF0IGludGVydmFsIHBhcmFt ZXRlciBhcyBiZWxvdy4NCj4gPiA+ICAgICAgICAgICAgIDIgLSBDRSBwaWdneS1iYWNraW5nIGhl YXJ0YmVhdC4gSW4gdGhpcyBjYXNlLCBDRSBzZW5kcyAgDQo+ID4gPiBIZWFydGJlYXQgbWVzc2Fn ZXMgdG8gRkUgb25seSB3aGVuIENFIHJlYWNoZXMgdGhlIHRpbWUgaW50ZXJ2YWwgIA0KPiA+ID4g d2l0aCBubyBvdGhlciBtZXNzYWdlIHRvIGJlIHNlbnQgaW4gdGhlIGludGVydmFsLg0KPiA+ID4g ICAgICAgICAgICAgMyAtIENFIHBpZ2d5LWJhY2tpbmcgaGVhcnRiZWF0IHdpdGggRkUgaGVhcnRi ZWF0ICANCj4gPiA+IHJlcXVlc3QuIEluIHRoaXMgY2FzZSwgYmVzaWRlcyBDRSBzZW5kcyBwaWdn eS1iYWNraW5nIGhlYXJ0YmVhdCwgQ0UgIA0KPiA+ID4gYWxzbyBzZW5kcyBIZWFydGJlYXQgcmVx dWVzdCBtZXNzYWdlIChhbHNvIGEgbm9ybWFsIEhCIG1lc3NhZ2UsICANCj4gPiA+IG9ubHkgd2hv c2UgQUNLIGZsYWcgYmVpbmcgc2V0IHRvIEFsd2F5c0FDSykgdG8gRkUgd2hlbiBDRSBoYXMgbm90 ICANCj4gPiA+IHJlY2VpdmVkIGFueSBtZXNzYWdlIGZyb20gRkUgZm9yIHRoZSBpbnRlcnZhbCBw ZXJpb2QuIFdoZW4gdGhpcyBDRSAgDQo+ID4gPiBoZWFydGJlYXQgcG9saWN5IGlzIGNob29zZW4s IHRoZSBGRSBoZWFydGJlYXQgcG9saWN5IGJlbG93IHNob3VsZCAgDQo+ID4gPiBiZSBzZXQgdG8g J0ZFIG5vIGhlYXJ0YmVhdCcuDQo+ID4gPg0KPiANCj4gDQo+IElmIHdlIHNheSB0aGUgQ0UgTVVT VCBzZW5kIGhlYXJ0YmVhdHMgdGhlbiB3ZSBkb250IG5lZWQgQ0UgaGVhcnRiZWF0DQo+IHBvbGlj eSBhbmQgd2UgY2FuIGdldCByaWQgb2YgYWJvdmUgImtub2JzIiBhbHRvZ2V0aGVyLg0KPiANCj4g PiA+ICAgICAgICAgICAgRkUgaGVhcnRiZWF0IHBvbGljeTogdG8gY29tbWFuZCB0aGUgRkUgdG8g dXNlIHRoZSAgDQo+ID4gPiBoZWFydGJlYXQgcG9saWN5Lg0KPiA+ID4NCj4gPiA+ICAgICAgICAg ICAgIDAgLSBGRSBubyBoZWFydGJlYXQuDQo+ID4gPiAgICAgICAgICAgICAxIC0gRkUgbm9ybWFs IGhlYXJ0YmVhdC4NCj4gPiA+ICAgICAgICAgICAgIDIgLSBGRSBwaWdneS1iYWNraW5nIGhlYXJ0 YmVhdC4gSW4gdGhpcyBjYXNlLCBGRSBzZW5kcyAgDQo+ID4gPiBoZWFydGJlYXQgbWVzc2FnZXMg dG8gRkUgb25seSB3aGVuIGl0IHJlYWNoZXMgdGhlIHRpbWUgaW50ZXJ2YWwgb2YgIA0KPiA+ID4g bm8gbWVzc2FnZSBzZW5kaW5nLg0KPiA+ID4NCj4gDQo+IElmIHdlIGFncmVlIHRoYXQgYXNzb2Np YXRpbmcgbGl2ZWxpbmVzcyBvZiB0aGUgQ0U8LT5GRSB3aXRoIGhlYXJ0YmVhdHMNCj4gKHdoYXQg aXMgcmVmZXJyZWQgdG8gYWJvdmUgYXMgcGlnZ3ktYmFja2luZykgaXMgYWx3YXlzIGdvaW5nIHRv IGJlDQo+IGltcGxlbWVudGVkIGkuZSBhIE1VU1QgdGhlbiAxMiBvbmx5IG5lZWQgb3B0aW9uIDAg b3IgMS4NCj4gDQo+IGNoZWVycywNCj4gamFtYWw= From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 20 08:44:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhUM-0006UT-KX for forces-archive@megatron.ietf.org; Tue, 20 Sep 2005 08:44:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26990 for ; Tue, 20 Sep 2005 08:44:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHha6-0003HB-0g for forces-archive@IETF.ORG; Tue, 20 Sep 2005 08:50:44 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010F423D@cherry.ease.lsoft.com>; Tue, 20 Sep 2005 8:44:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86048264 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 20 Sep 2005 08:44:32 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 20 Sep 2005 08:44:32 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id j8KCRtHC019983; Tue, 20 Sep 2005 14:27:55 +0200 References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> <6.2.1.2.0.20050918184031.02ccfcd0@localhost> <1127132390.29891.77.camel@localhost.localdomain> <6.2.1.2.0.20050919100618.02dc9ce0@localhost> <1127143620.6580.0.camel@localhost.localdomain> <432EE3C7.20300@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.734) Approved-By: Avri Doria Message-ID: <2C95B3D3-0ECB-46F0-9F92-19587418542F@psg.com> Date: Tue, 20 Sep 2005 14:44:25 +0200 Reply-To: Avri Doria Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: HA and Heartbeats Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <432EE3C7.20300@zurich.ibm.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Hi, I don't see why it doesn't make sense. It seems to me that the =20 association could be setup and be in a standby mode. This means that =20= when operating in an HA mode and contact is lost, then the CE that =20 becomes the new primary could immediately send a HB with request for =20 ACK. And likewise when an FE lost HB with its primary it would know =20 who to send a HB to, using a default HB mechanism. without preset associations, how would know where to make reparative =20 contact without going back to the still nonexistent CEM/FEM? a. On 19 sep 2005, at 18.13, Robert Haas wrote: > This would mean that when changing from the primary to the backup =20 > CE, the FE would have to first setup an association with the backup =20= > CE. The reason I say this is because I don't think an association =20 > without liveliness checks (heartbeat excahnges) makes much sense. > > Regards, > -Robert > > Jamal Hadi Salim wrote: > > >> On Mon, 2005-19-09 at 10:07 -0400, Joel M. Halpern wrote: >> [..] >> >> >>> The configuration of information about relations with backup CEs =20 >>> could be the domain of the FEM, and therefore out of scope for =20 >>> the work for now. This would mean that backup CEs could not =20 >>> configure the heartbeat / liveness interval. >>> >>> >>> >> >> Ok, could i get two more people to agree to this? >> >> cheers, >> jamal >> >> >> >> > > --=20 > Dr. Robert R. Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-44-724-8698 fax +41-44-724-8578 http://=20 > www.zurich.ibm.com/~rha > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 20 09:47:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHiSk-0008J7-R9 for forces-archive@megatron.ietf.org; Tue, 20 Sep 2005 09:47:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00762 for ; Tue, 20 Sep 2005 09:47:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHiYa-00057j-BI for forces-archive@IETF.ORG; Tue, 20 Sep 2005 09:53:13 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010F4614@cherry.ease.lsoft.com>; Tue, 20 Sep 2005 9:47:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86053984 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 20 Sep 2005 09:47:08 -0400 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 20 Sep 2005 09:47:08 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8KDl6OI128178 for ; Tue, 20 Sep 2005 13:47:06 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8KDl6uJ168282 for ; Tue, 20 Sep 2005 15:47:06 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8KDl6Qx022585 for ; Tue, 20 Sep 2005 15:47:06 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8KDl5Fw022576; Tue, 20 Sep 2005 15:47:06 +0200 Received: from [127.0.0.1] ([9.4.210.49]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA73902; Tue, 20 Sep 2005 15:47:05 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1126901337.24495.60.camel@localhost.localdomain> <6.2.1.2.0.20050916210542.02d7e298@localhost> <1126956608.6681.31.camel@localhost.localdomain> <6.2.1.2.0.20050917102320.02cc05d8@localhost> <1127049919.29891.9.camel@localhost.localdomain> <6.2.1.2.0.20050918184031.02ccfcd0@localhost> <1127132390.29891.77.camel@localhost.localdomain> <6.2.1.2.0.20050919100618.02dc9ce0@localhost> <1127143620.6580.0.camel@localhost.localdomain> <432EE3C7.20300@zurich.ibm.com> <2C95B3D3-0ECB-46F0-9F92-19587418542F@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id j8KDl6OI128178 Approved-By: Robert Haas Message-ID: <433012D8.3000604@zurich.ibm.com> Date: Tue, 20 Sep 2005 15:47:04 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: HA and Heartbeats Comments: To: Avri Doria To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <2C95B3D3-0ECB-46F0-9F92-19587418542F@psg.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Hi Avri, What if in addition to sending HBs for the first time to its backup CE,=20 the FE would have to setup the association first ? Then all that is=20 needed is the CE ID of the backup CE to be stored in the FEPO. I am not comfortable with a "dormant" type of association, i.e., an=20 association that has been setup (together with a working TML), but for=20 which no PL HB is flowing; the TML will be working anyway. So I'd prefer=20 that either we keep the association alive with PL HBs too, or we don't=20 set it at all before the switch to the backup CE occurs. Regards, -Robert Avri Doria wrote: > Hi, > > I don't see why it doesn't make sense. It seems to me that the =20 > association could be setup and be in a standby mode. This means that =20 > when operating in an HA mode and contact is lost, then the CE that =20 > becomes the new primary could immediately send a HB with request for =20 > ACK. And likewise when an FE lost HB with its primary it would know =20 > who to send a HB to, using a default HB mechanism. > > without preset associations, how would know where to make reparative =20 > contact without going back to the still nonexistent CEM/FEM? > > a. > > On 19 sep 2005, at 18.13, Robert Haas wrote: > >> This would mean that when changing from the primary to the backup =20 >> CE, the FE would have to first setup an association with the backup =20 >> CE. The reason I say this is because I don't think an association =20 >> without liveliness checks (heartbeat excahnges) makes much sense. >> >> Regards, >> -Robert >> >> Jamal Hadi Salim wrote: >> >> >>> On Mon, 2005-19-09 at 10:07 -0400, Joel M. Halpern wrote: >>> [..] >>> >>> >>>> The configuration of information about relations with backup CEs =20 >>>> could be the domain of the FEM, and therefore out of scope for the=20 >>>> work for now. This would mean that backup CEs could not configure=20 >>>> the heartbeat / liveness interval. >>>> >>>> >>>> >>> >>> Ok, could i get two more people to agree to this? >>> >>> cheers, >>> jamal >>> >>> >>> >>> >> >> --=20 >> Dr. Robert R. Haas >> IBM Zurich Research Laboratory >> S=E4umerstrasse 4 >> CH-8803 R=FCschlikon/Switzerland >> phone +41-44-724-8698 fax +41-44-724-8578 http://=20 >> www.zurich.ibm.com/~rha >> >> > > > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 20 12:31:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHl2E-0003KZ-Fi for forces-archive@megatron.ietf.org; Tue, 20 Sep 2005 12:31:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13193 for ; Tue, 20 Sep 2005 12:31:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHl81-00023g-DA for forces-archive@IETF.ORG; Tue, 20 Sep 2005 12:38:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010F4CCD@cherry.ease.lsoft.com>; Tue, 20 Sep 2005 12:31:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86073906 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 20 Sep 2005 12:31:36 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 20 Sep 2005 12:31:36 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8KFicXK060267; Tue, 20 Sep 2005 08:44:40 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <007f01c5b475$8bd850f0$1f12fea9@wwm1> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126885065.24495.32.camel@localhost.localdomain> <005701c5bd8d$5d301dc0$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127233875.6535.67.camel@localhost.localdomain> Date: Tue, 20 Sep 2005 12:31:15 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <005701c5bd8d$5d301dc0$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Weiming, On Tue, 2005-20-09 at 10:45 +0800, Weiming Wang wrote: > Jamal, > > I'm sorry to reply a bit late. I'm actually trying to understand > your meaning of FE MUST and CE MUST for heartbeat generating in > your response. I just found it is inconsistent in some way, therefore > hard to follow your meaning. I'm not sure if you actually mean "FE MUST > generate HBs" instead of "CE MUST". My general comment is, the scheme for > a "no heartbeat" of either CE or FE should be allowed, so as to support a > very confident system, where implementors believe they don't need the HBs > at all for the liveness check. > > I see the main difference lying between us is, if you now agree to allow > the HB scheme as the FE automatically generates HB messages rather than > just resonse to CE HB messages? > I look at your text below and the only thing is i thought we said that an FE MUST be able to generate HBs. i.e the capability is not needed. I dont mind having it there, but i thought thats the decision we reached, no? The CE MAY configure the FE to use the HB. When it doesnt, it MAY request for acknowledgement or never even send the HBs. The CE MUST be able to generate HBs, it MAY not generate them if configured so. We also said the "piggybacking" is a MUST. I think we need to describe this mechanism once somewhere - give it a name maybe and stop repeating its description everywhere (such as in the case you do in the CE/FE heartbeat policy). Other than that, i think we may need a FE Dead Interval as well to tell the FE when the CE will declare the FE dead. If you agree to this, please make changes to the HB section and send me the XML. Then we can close this issue and section 3 (but not yet the HA section until we fixup related things). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 20 14:01:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmQl-0003qt-80 for forces-archive@megatron.ietf.org; Tue, 20 Sep 2005 14:01:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19724 for ; Tue, 20 Sep 2005 14:01:21 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHmWc-0005Ap-QY for forces-archive@IETF.ORG; Tue, 20 Sep 2005 14:07:27 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010F4CE0@cherry.ease.lsoft.com>; Tue, 20 Sep 2005 14:01:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86081341 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 20 Sep 2005 14:01:12 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 20 Sep 2005 14:01:12 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8KHEVXK061153 for ; Tue, 20 Sep 2005 10:14:31 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-hRz1h0wC7AsrYhMLVOXS" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1127239269.6535.74.camel@localhost.localdomain> Date: Tue, 20 Sep 2005 14:01:08 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: section 5 changes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.0 (++) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b --=-hRz1h0wC7AsrYhMLVOXS Content-Type: text/plain Content-Transfer-Encoding: 7bit Again lots of changes here, so i am not gonna supply a diff. Please review closely - hopefully we can close before meeting. I will post the next thing once i see substantial activity on this one. Some of the changes made are: - New additional flags - lots of text rearrangement and cleanup cheers, jamal --=-hRz1h0wC7AsrYhMLVOXS Content-Disposition: attachment; filename=section5.txt Content-Type: text/plain; name=section5.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 5. Message encapsulation All PL layer PDUs start with a common header [Section 5.1] followed by a one or more TLVs [Section 5.2] which may nest other TLVs [Section 5.2.1]. 5.1. Common Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |version| rsvd | Message Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Common Header The message is 32 bit aligned. Version (4 bit): Version number. Current version is 1. rsvd (4 bit): Unused at this point. A receiver should not interpret this field. Senders SHOULD set it to zero. Message Type (8 bits): Commands are defined in Section 6. Length (16 bits): length of header + the rest of the message in DWORDS (4 byte increments). Source ID (32 bit): Doria (Ed.), et al. Expires February 2, 2006 [Page 23] Internet-Draft ForCES August 2005 Dest ID (32 bit): * Each of the source and Dest IDs are 32 bit IDs which are unique NE-wide and which recognize the termination points of a ForCES PL message. * IDs allow multi/broad/unicast addressing with the following approach: a. A split address space is used to distinguish FEs from CEs. Even though we can assume that in a large NE there are typically two or more orders of magnitude more FEs than CEs, the address space is split uniformly for simplicity. b. The address space allows up to 2^30 (over a billion) CEs and the same amount of FEs. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TS | sub-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: ForCES ID Format c. The 2 most significant bits called Type Switch (TS) are used to split the ID space as follows: A. TS Corresponding ID range Assignment B. -- ---------------------- ---------- C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) E. 0b10 0x80000000 to 0xBFFFFFFF reserved F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved H. 0b11 0xFFFFFFFD all CEs broadcast I. 0b11 0xFFFFFFFE all FEs broadcast Doria (Ed.), et al. Expires February 2, 2006 [Page 24] Internet-Draft ForCES August 2005 J. 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast * Multicast or broadcast IDs are used to group endpoints (such as CEs and FES). As an example one could group FEs in some functional group, by assigning a multicast ID. Likewise, subgroups of CEs that act, for instance, in a back-up mode may be assigned a multicast ID to hide them from the FE. * We donot discuss how a particular multicast ID is associated to a given group though we note that it could be done via configuration process. The list of IDs an FE owns or is part of are listed on the FE Object LFB. Correlator (32 bits) This field is used to correlate the ForCES Requests messages (typically sent from CE to FE) with the corresponding Response messages (typically sent from FE to CE). The correlator is handled transparently by the FE, i.e. for a particular Request message it will assign the same correlator value in the corresponding Response message. Sequence (32 bits) Like the Correlator the Sequence is set by the CE and echoed back by the FE. The CE could use the combination of the Correlator and Sequence to maintain transactional state although this is not enforced and so the CE is free to use these 2 fields as it pleases. Flags(32 bits): Identified so far: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | |ACK| Pri | EM|TP | Reserved | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ACK: ACK indicator(2 bit) The ACK indicator flag is only used by a Config Message sender to indicate the message receiver whether or not a config response is required by the sender. Note that all other messages than Config Message MUST ignore this flag. Doria (Ed.), et al. Expires February 2, 2006 [Page 25] Internet-Draft ForCES August 2005 The flag values are defined as below: 'NoACK' (00) - to indicate the message receiver not to send any response message back to this message sender. 'SuccessACK'(01) - to inidcate the message receiver to send a response message back only when the message has been successfully processed by the receiver. 'FailureACK'(10) - to indicate the message receiver to send a response message back only when there is any failure for the receiver to process(execute) the message. In other words, if the message can be processed successfully, the sender will not expect any response from the receiver. 'AlwaysACK' (11) - to indicate the message receiver to send a response message back in any case. Note that in above definitions, success means a complete execution without any failure of the message. Anything else than a complete successful execution is defined as a failure for the message processing. As a result, for the execution modes (defined in Section 3.3.1.1) like execute-all-or-none, execute-until-failure, and continue-execute-on-failure, if any single operation among several operations in the same message fails, it will be treated as a failure and result in a response if the ACK indicator has been set to 'FailureACK'. Also note that messages other than Config Message, whose requirements for responses are described by the message definitions in Section 6, we summarise the default requirements of these messages and the expected responses below. Detailed descriptions can be found in the individual message definitions: + Association Setup Message always expects a response. + Association Teardown Message, Packet Redirect Message, and Heartbeat Message never expect responses. + Query Message always expects a response. + Any kind of response messages never expect further responses. Doria (Ed.), et al. Expires February 2, 2006 [Page 26] Internet-Draft ForCES August 2005 - Pri: Priority (3 bits) ForCES protocol defines 8 different levels of priority (0-7). The priority level can be used to distinguish between different protocol message types as well as between the same message type. For example, the REDIRECT PACKET message could have different priorities to distinguish between Routing protocols packets and ARP packets being redirected from FE to CE. The Normal priority level is 1. - EM: Execution mode (2 bits) There are 3 execution modes refer to Section 3.3.1.1 for details. `execute-all-or-none` (01) `execute-until-failure` (10) `continue-execute-on-failure` (11) binary 00 is reserved - TP: Transaction phase (2 bits) A message from the CE to the FE within a transaction could be indicative of the different phases the transaction is in. Refer to Section 3.3.1.1.3 for details. `MOT (Middle of transaction)` (00) `SOT (start of transaction)` (01) `EOT (end of transaction)` (10) `ABT (abort)` (11) 5.2. Type Length Value Doria (Ed.), et al. Expires February 2, 2006 [Page 27] Internet-Draft ForCES August 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | variable TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (Data of size TLV length) | ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: TLV TLV Type (16): The TLV type field is two octets, and indicates the type of data encapsulated within the TLV. TLV Length (16): The TLV Length field is two octets, and indicates the length of this TLV including the TLV Type, TLV Length, and the TLV data. TLV Value (variable): The TLV Value field carries the data. For extensibility, the TLV value may infact be a TLV. TLVs must be 32 bit aligned. 5.2.1. Nested TLVs TLV values can be other TLVs. This provides the benefits of protocol flexibility (being able to add new extensions by introducing new TLVs when needed). The nesting feature also allows easy mapping between the XML LFB definitions to binary PL representation. 5.2.2. Scope of the T in TLV The "Type" value in TLV is of global scope. This means that wherever in the PDU hierachy a Type has global connotations. This is a design choice to ease debugging of the protocol. 5.3. ILV A slight variation of the TLV known as the ILV is introduced to allow to the "T" to be a 32-bit index that is a ForCES element ID. The Length part of the ILV is also 32 bits to allow of the referenced data to be arbitrarily large in size. Refer to Section 6.1.1.1.8 for discussions on usage of ILVs. Doria (Ed.), et al. Expires February 2, 2006 [Page 28] Internet-Draft ForCES August 2005 --=-hRz1h0wC7AsrYhMLVOXS-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 20 16:12:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHoTa-0000E4-Ad for forces-archive@megatron.ietf.org; Tue, 20 Sep 2005 16:12:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01327 for ; Tue, 20 Sep 2005 16:12:23 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHoZQ-0001VE-3t for forces-archive@IETF.ORG; Tue, 20 Sep 2005 16:18:31 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010F5081@cherry.ease.lsoft.com>; Tue, 20 Sep 2005 16:11:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86090778 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 20 Sep 2005 16:11:33 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 20 Sep 2005 16:11:33 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8KKBWS2007688; Tue, 20 Sep 2005 20:11:32 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8KK9xYk004642; Tue, 20 Sep 2005 20:11:31 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005092013112630797 ; Tue, 20 Sep 2005 13:11:27 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 13:11:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] section 5 changes Thread-Index: AcW+DWsffsQq9beFTwiUFHejOj35ogAEf3mQ X-OriginalArrivalTime: 20 Sep 2005 20:11:24.0138 (UTC) FILETIME=[797C4CA0:01C5BE1F] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06BFC545@orsmsx408> Date: Tue, 20 Sep 2005 13:11:22 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: section 5 changes Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Jamal, I briefly browsed thru this text and it looks good to me. Thanks Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Tuesday, September 20, 2005 11:01 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] section 5 changes Again lots of changes here, so i am not gonna supply a diff. Please review closely - hopefully we can close before meeting. I will post the next thing once i see substantial activity on this one. Some of the changes made are: - New additional flags - lots of text rearrangement and cleanup cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 20 21:18:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHtGA-0001iw-LB for forces-archive@megatron.ietf.org; Tue, 20 Sep 2005 21:18:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18641 for ; Tue, 20 Sep 2005 21:18:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHtLz-0000mk-5U for forces-archive@IETF.ORG; Tue, 20 Sep 2005 21:25:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010F54EA@cherry.ease.lsoft.com>; Tue, 20 Sep 2005 21:18:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86109047 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 20 Sep 2005 21:18:45 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 20 Sep 2005 21:18:42 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 21 Sep 2005 09:54:31 +0800 (CST) References: <1127239269.6535.74.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <003601c5be4a$a14aac10$1f12fea9@wwm1> Date: Wed, 21 Sep 2005 09:20:14 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: section 5 changes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: base64 SmFtYWwsDQoNClRoYXQncyByZWFsbHkgZ3JlYXQuIEl0IGxvb2tzIG11Y2ggYmV0dGVyIHRoYW4g YmVmb3JlLiANCg0KT25seSBvbmUgbW9yZSBjaGFuZ2UgaXMgbmVlZGVkLCAgdGhhdCBpcywgdGhl IHBhcnQgb24gQUNLIGZsYWcgdGhhdCBJIHByb3Bvc2VkLCBiZWNhdXNlIHdlIG5vdyBhZ3JlZSB0 byBhbGxvdyBIQiBtZXNzYWdlcyBhbHNvIHVzZSB0aGlzIGZsYWcuICBUaGUgcmVsYXRlZCBjaGFu Z2Ugb24gdGhlIEhCIG1lc3NhZ2UgZGVmaW5pdGlvbiAoc2VjdGlvbiA2LjkpIGlzIGFsc28gbmVl ZGVkIHRoZW4uIEkgY2FuIHRyeSB0byBtYWtlIHRoZSBzZWN0aW9uIDYuOSBjaGFuZ2UgYW5kIEkg aG9wZSB5b3UgbWFrZSB0aGUgY2hhbmdlIGluIHRoaXMgc2VjdGlvbiAzLCBpcyBpdCBhbGwgcmln aHQ/DQoNClRoYW5rcyBzbyBtdWNoLg0KV2VpbWluZw0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSGFkaSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQpUbzog PEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTT4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVy IDIxLCAyMDA1IDI6MDEgQU0NClN1YmplY3Q6IHNlY3Rpb24gNSBjaGFuZ2VzDQoNCg0KPiANCj4g QWdhaW4gbG90cyBvZiBjaGFuZ2VzIGhlcmUsIHNvIGkgYW0gbm90IGdvbm5hIHN1cHBseSBhIGRp ZmYuDQo+IFBsZWFzZSByZXZpZXcgY2xvc2VseSAtIGhvcGVmdWxseSB3ZSBjYW4gY2xvc2UgYmVm b3JlIG1lZXRpbmcuDQo+IEkgd2lsbCBwb3N0IHRoZSBuZXh0IHRoaW5nIG9uY2UgaSBzZWUgc3Vi c3RhbnRpYWwgYWN0aXZpdHkgb24gdGhpcyBvbmUuDQo+IA0KPiBTb21lIG9mIHRoZSBjaGFuZ2Vz IG1hZGUgYXJlOg0KPiAtIE5ldyBhZGRpdGlvbmFsIGZsYWdzDQo+IC0gbG90cyBvZiB0ZXh0IHJl YXJyYW5nZW1lbnQgYW5kIGNsZWFudXANCj4gDQo+IA0KPiBjaGVlcnMsDQo+IGphbWFsDQo+IA== From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 20 23:26:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHvFB-0002Jm-Oa for forces-archive@megatron.ietf.org; Tue, 20 Sep 2005 23:26:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23659 for ; Tue, 20 Sep 2005 23:25:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHvL8-0003Mp-2b for forces-archive@IETF.ORG; Tue, 20 Sep 2005 23:32:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010F5647@cherry.ease.lsoft.com>; Tue, 20 Sep 2005 23:25:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86115794 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 20 Sep 2005 23:25:59 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 20 Sep 2005 23:25:54 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 21 Sep 2005 12:01:24 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Wed, 21 Sep 2005 11:25:04 +0800 References: <1126115848.8422.47.camel@localhost.localdomain> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126885065.24495.32.camel@localhost.localdomain> <005701c5bd8d$5d301dc0$1f12fea9@wwm1> <1127233875.6535.67.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <009801c5be5b$fba76480$1152010a@Necom.hzic.edu.cn> Date: Wed, 21 Sep 2005 11:24:32 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0i IDxoYWRpQHpueXguY29tPg0KU3ViamVjdDogUmU6IENsb3N1cmUgbmVlZGVkIHBsZWFzZSBjb21t ZW50IFdBUyhSZTogU2VjdGlvbiA5OiBIZWFydGJlYXQgTWVzc2FnZXMNCg0KDQo+IA0KPiBJIGxv b2sgYXQgeW91ciB0ZXh0IGJlbG93IGFuZCB0aGUgb25seSB0aGluZyBpcyBpIHRob3VnaHQgd2Ug c2FpZCB0aGF0DQo+IGFuIEZFIE1VU1QgYmUgYWJsZSB0byBnZW5lcmF0ZSBIQnMuIGkuZSB0aGUg Y2FwYWJpbGl0eSBpcyBub3QgbmVlZGVkLg0KPiBJIGRvbnQgbWluZCBoYXZpbmcgaXQgdGhlcmUs IGJ1dCBpIHRob3VnaHQgdGhhdHMgdGhlIGRlY2lzaW9uIHdlDQo+IHJlYWNoZWQsIG5vPw0KSSBh bHNvIGRvbid0IG1pbmQgaGF2aW5nIGl0IG9yIG5vdCwgaS5lLiwgd2UgY2FuIGltcGxpY2l0bHkg YXNzdW1lIHRoYXQgRkUgbXVzdCBoYXZlIHRoZSBjYXBhYmlsaXR5IHRvIGFjdGl2ZWx5IGdlbmVy YXRlIEhCIG1lc3NhZ2VzIGF0IGludGVydmFscy4gTXkgZm9ybWFsIHVuZGVyc3RhbmRpbmcgd2Fz ICdGRSBNVVNUIHN1cHBvcnQgSGVhcnRiZWF0IG9wZXJhdGlvbnMnLCB0aGF0IEkgdGhvdWdodCBt ZWFudCBGRSBtdXN0IGJlIGFibGUgYXQgbGVhc3QgdG8gcmVzcG9uZCBIQiByZXF1ZXN0IG1lc3Nh Z2VzIGZyb20gQ0UuDQoNCj4gVGhlIENFIE1BWSBjb25maWd1cmUgdGhlIEZFIHRvIHVzZSB0aGUg SEIuIFdoZW4gaXQgZG9lc250LCBpdCBNQVkNCj4gcmVxdWVzdCBmb3IgYWNrbm93bGVkZ2VtZW50 IG9yIG5ldmVyIGV2ZW4gc2VuZCB0aGUgSEJzLg0KQWdyZWVkLiBJIHRoaW5rIHRoZSBnZW5lcmlj IG1lYW5pbmcgaGFzIGJlZW4gaW5jbHVkZWQgaW4gdGhlIHRleHQgd2l0aCB0aGUgRkUgaGVhcnRi ZWF0IHBvbGljeS4NCg0KPiBUaGUgQ0UgTVVTVCBiZSBhYmxlIHRvIGdlbmVyYXRlIEhCcywgaXQg TUFZIG5vdCBnZW5lcmF0ZSB0aGVtIGlmDQo+IGNvbmZpZ3VyZWQgc28uIA0KQWdyZWVkLCBhbmQg SSB0aGluayB0aGUgbWVhbmluZyBpcyBhbHNvIGluY2x1ZGVkLg0KDQo+IFdlIGFsc28gc2FpZCB0 aGUgInBpZ2d5YmFja2luZyIgaXMgYSBNVVNULiBJIHRoaW5rIHdlIG5lZWQgdG8gZGVzY3JpYmUN Cj4gdGhpcyBtZWNoYW5pc20gb25jZSBzb21ld2hlcmUgLSBnaXZlIGl0IGEgbmFtZSBtYXliZSBh bmQgc3RvcCByZXBlYXRpbmcNCj4gaXRzIGRlc2NyaXB0aW9uIGV2ZXJ5d2hlcmUgKHN1Y2ggYXMg aW4gdGhlIGNhc2UgeW91IGRvIGluIHRoZSBDRS9GRQ0KPiBoZWFydGJlYXQgcG9saWN5KS4NClN1 cmUsIEkgdHJ5IHRvIGFkZCBzb21lIHRleHQuDQoNCj4gDQo+IE90aGVyIHRoYW4gdGhhdCwgaSB0 aGluayB3ZSBtYXkgbmVlZCBhIEZFIERlYWQgSW50ZXJ2YWwgYXMgd2VsbCB0byB0ZWxsDQo+IHRo ZSBGRSB3aGVuIHRoZSBDRSB3aWxsIGRlY2xhcmUgdGhlIEZFIGRlYWQuDQpXaGF0IHRoZSBwYXJh bWV0ZXIgY2FuIGJlIHVzZWQgZm9yIGluIEZFIHRoZW4sIGkuZS4sIGFueSB1c2FnZSBmb3IgdGhl IHBhcmFtZXRlciBpbiBGRT8NCg0KPiANCj4gSWYgeW91IGFncmVlIHRvIHRoaXMsIHBsZWFzZSBt YWtlIGNoYW5nZXMgdG8gdGhlIEhCIHNlY3Rpb24gYW5kIHNlbmQgbWUNCj4gdGhlIFhNTC4gVGhl biB3ZSBjYW4gY2xvc2UgdGhpcyBpc3N1ZSBhbmQgc2VjdGlvbiAzIChidXQgbm90IHlldCB0aGUg SEENCj4gc2VjdGlvbiB1bnRpbCB3ZSBmaXh1cCByZWxhdGVkIHRoaW5ncykuIA0KT2ssIGFuZCBh Z3JlZWQuDQoNClRoYW5rcywNCldlaW1pbmcNCg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA== From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 21 00:14:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHvzt-0000Zq-P4 for forces-archive@megatron.ietf.org; Wed, 21 Sep 2005 00:14:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25801 for ; Wed, 21 Sep 2005 00:14:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHw5q-0004VT-0H for forces-archive@IETF.ORG; Wed, 21 Sep 2005 00:20:27 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010F57A3@cherry.ease.lsoft.com>; Wed, 21 Sep 2005 0:14:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86122342 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 21 Sep 2005 00:14:14 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 21 Sep 2005 00:14:12 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 21 Sep 2005 12:50:06 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Wed, 21 Sep 2005 12:13:46 +0800 References: <1126115848.8422.47.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126885065.24495.32.camel@localhost.localdomain> <005701c5bd8d$5d301dc0$1f12fea9@wwm1> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <009e01c5be62$c90cd120$1152010a@Necom.hzic.edu.cn> Date: Wed, 21 Sep 2005 12:13:13 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: A question on FE protocol attribute definitions To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGhhdmUgYSBnZW5lcmFsIHF1ZXN0aW9uIG9uIHRoZSBGRSBwcm90b2NvbCBM RkIgYW5kIGl0cyBhdHRyaWJ1dGVzIGRlZmluaXRpb25zIGluIHRoZSBwcm90b2NvbCBkcmFmdC4N Cg0KV2UgaGF2ZSBhbiBYTUwgaW4gdGhlIEFwcGVuZGl4LiBDYW4gd2UgdW5kZXJzdGFuZCB0aGF0 IHRoZSBhdHRyaWJ1dGVzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgU2VjdGlvbnMgYXJlIGp1c3Qg YSAgZGVzY3JpcHRpdmUgZXhwbGFpbmF0aW9uIG9uIHRoZSBYTUwgZGVmaW5pdGlvbnM/IFdpbGwg dGhlIFhNTCBnaXZlIHRoZSBhdHRyaWJ1dGUgdmFsdWUgZGVzY3JpcHRpb25zIGFsc28/DQoNCkkg cmFpc2UgdGhlIHF1ZXN0aW9uIGJlY2F1c2UgSSBmZWVsIGEgbGl0dGxlIHVuY29tZm9ydGFibGUg d2l0aCBjdXJyZW50IHdheSBpbiB0aGUgZHJhZnQgdG8gZGVzY3JpYmUgdGhlIGF0dHJpYnV0ZXMg bGlrZSB0aGUgQ0UvRkUgaGVhcnRiZWF0IHBvbGljeSBhbmQgQ0UvRkUgZmFpbG92ZXIgcG9saWN5 LiANCg0KVGhhbmtzLA0KV2VpbWluZw0KDQoNCiA= From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 21 06:23:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI1l6-0000q0-SX for forces-archive@megatron.ietf.org; Wed, 21 Sep 2005 06:23:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10103 for ; Wed, 21 Sep 2005 06:23:22 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI1r3-0005JD-7n for forces-archive@IETF.ORG; Wed, 21 Sep 2005 06:29:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010F5B11@cherry.ease.lsoft.com>; Wed, 21 Sep 2005 6:23:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86144544 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 21 Sep 2005 06:23:18 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 21 Sep 2005 06:23:17 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8L9ZoXK068399; Wed, 21 Sep 2005 02:35:52 -0700 (PDT) References: <1127239269.6535.74.camel@localhost.localdomain> <003601c5be4a$a14aac10$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127298158.6447.33.camel@localhost.localdomain> Date: Wed, 21 Sep 2005 06:22:38 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: section 5 changes Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003601c5be4a$a14aac10$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On Wed, 2005-21-09 at 09:20 +0800, Weiming Wang wrote: > Jamal, > > That's really great. It looks much better than before. > > Only one more change is needed, that is, the part on ACK flag > that I proposed, because we now agree to allow HB messages also > use this flag. Are you still talking about section 5? I looked at the ACK section and didnt find a good place to mention HB. > The related change on the HB message definition > (section 6.9) is also needed then. I can try to make the section > 6.9 change and I hope you make the change in this section 3, > is it all right? > Yes, indeed. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 21 06:28:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI1q1-0001Pj-6W for forces-archive@megatron.ietf.org; Wed, 21 Sep 2005 06:28:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10292 for ; Wed, 21 Sep 2005 06:28:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI1w0-0005QC-Ue for forces-archive@IETF.ORG; Wed, 21 Sep 2005 06:34:42 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010F5BD5@cherry.ease.lsoft.com>; Wed, 21 Sep 2005 6:28:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86144781 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 21 Sep 2005 06:28:06 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 21 Sep 2005 06:28:05 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8L9etXK068419; Wed, 21 Sep 2005 02:40:57 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <1126186227.6416.27.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126885065.24495.32.camel@localhost.localdomain> <005701c5bd8d$5d301dc0$1f12fea9@wwm1> <1127233875.6535.67.camel@localhost.localdomain> <009801c5be5b$fba76480$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127298463.6447.39.camel@localhost.localdomain> Date: Wed, 21 Sep 2005 06:27:43 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <009801c5be5b$fba76480$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit On Wed, 2005-21-09 at 11:24 +0800, Wang,Weiming wrote: > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages > > > > > > I look at your text below and the only thing is i thought we said that > > an FE MUST be able to generate HBs. i.e the capability is not needed. > > I dont mind having it there, but i thought thats the decision we > > reached, no? > I also don't mind having it or not, i.e., we can implicitly assume that FE > must have the capability to actively generate HB messages at intervals. This seemed to be the consensus at the concal. > My > formal understanding was 'FE MUST support Heartbeat operations', that I > thought meant FE must be able at least to respond HB request messages from CE. > Ok, my fault. Yes, formally if FE is able to respond or process HBs, what you are saying is included. So for simplicity lets still have 'FE MUST support Heartbeat operations' to mean supporting generation and responding to HBs by the FE. This means we are also reaching the consensus as per concal. Send me the text privately when ready and i will release it to the list. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 21 06:31:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI1sn-0002Ip-F5 for forces-archive@megatron.ietf.org; Wed, 21 Sep 2005 06:31:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10365 for ; Wed, 21 Sep 2005 06:31:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI1yn-0005Tb-Bi for forces-archive@IETF.ORG; Wed, 21 Sep 2005 06:37:34 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010F5B3A@cherry.ease.lsoft.com>; Wed, 21 Sep 2005 6:31:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86144864 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 21 Sep 2005 06:30:37 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 21 Sep 2005 06:30:36 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8L9hSXK068435; Wed, 21 Sep 2005 02:43:30 -0700 (PDT) References: <1126115848.8422.47.camel@localhost.localdomain> <00c701c5b481$3bb7f6a0$1f12fea9@wwm1> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126885065.24495.32.camel@localhost.localdomain> <005701c5bd8d$5d301dc0$1f12fea9@wwm1> <009e01c5be62$c90cd120$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127298616.6447.43.camel@localhost.localdomain> Date: Wed, 21 Sep 2005 06:30:16 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: A question on FE protocol attribute definitions Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <009e01c5be62$c90cd120$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Weiming, The XML is out-dated now that we have made changes to HB. Can you also make changes to it when you change the HB text to reflect more accurately reality? Also if you dont mind looking at the draft and making sure text on FEPO is consistent elsewhere on draft with these changes. cheers, jamal On Wed, 2005-21-09 at 12:13 +0800, Wang,Weiming wrote: > Hi all, > > I have a general question on the FE protocol LFB and its attributes > definitions in the protocol draft. > > We have an XML in the Appendix. Can we understand that the attributes > described in the draft Sections are just a descriptive explaination > on the XML definitions? Will the XML give the attribute value descriptions > also? > > I raise the question because I feel a little uncomfortable with current way > in the draft to describe the attributes like the CE/FE heartbeat policy and > CE/FE failover policy. > > Thanks, > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 21 10:53:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5yO-0004XH-CD for forces-archive@megatron.ietf.org; Wed, 21 Sep 2005 10:53:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25676 for ; Wed, 21 Sep 2005 10:53:22 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI64N-0004Ip-22 for forces-archive@IETF.ORG; Wed, 21 Sep 2005 10:59:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010F5ED8@cherry.ease.lsoft.com>; Wed, 21 Sep 2005 10:53:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86157781 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 21 Sep 2005 10:53:17 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 21 Sep 2005 10:53:14 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 21 Sep 2005 23:29:11 +0800 (CST) References: <1127239269.6535.74.camel@localhost.localdomain> <003601c5be4a$a14aac10$1f12fea9@wwm1> <1127298158.6447.33.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <006601c5bebc$6b840370$1f12fea9@wwm1> Date: Wed, 21 Sep 2005 22:54:50 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: section 5 changes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0i IDxoYWRpQHpueXguY29tPg0KDQo+IE9uIFdlZCwgMjAwNS0yMS0wOSBhdCAwOToyMCArMDgwMCwg V2VpbWluZyBXYW5nIHdyb3RlOg0KPiA+IEphbWFsLA0KPiA+IA0KPiA+IFRoYXQncyByZWFsbHkg Z3JlYXQuIEl0IGxvb2tzIG11Y2ggYmV0dGVyIHRoYW4gYmVmb3JlLiANCj4gPiANCj4gPiBPbmx5 IG9uZSBtb3JlIGNoYW5nZSBpcyBuZWVkZWQsICB0aGF0IGlzLCB0aGUgcGFydCBvbiBBQ0sgZmxh ZyANCj4gPiB0aGF0IEkgcHJvcG9zZWQsIGJlY2F1c2Ugd2Ugbm93IGFncmVlIHRvIGFsbG93IEhC IG1lc3NhZ2VzIGFsc28gDQo+ID4gdXNlIHRoaXMgZmxhZy4gIA0KPiANCj4gQXJlIHlvdSBzdGls bCB0YWxraW5nIGFib3V0IHNlY3Rpb24gNT8gSSBsb29rZWQgYXQgdGhlIEFDSyBzZWN0aW9uIGFu ZA0KPiBkaWRudCBmaW5kIGEgZ29vZCBwbGFjZSB0byBtZW50aW9uIEhCLg0KDQoNCiEgVGhlIDFz dCBwbGFjZSBpczogDQoNCiAgICAgICAtIEFDSzogQUNLIGluZGljYXRvcigyIGJpdCkNCiAgICAg ICAgICAgVGhlIEFDSyBpbmRpY2F0b3IgZmxhZyBpcyBvbmx5IHVzZWQgYnkgYSBDb25maWcgTWVz c2FnZQ0KICAgICAgICAgICBzZW5kZXIgdG8gaW5kaWNhdGUgdGhlIG1lc3NhZ2UgcmVjZWl2ZXIg d2hldGhlciBvciBub3QgYQ0KICAgICAgICAgICBjb25maWcgcmVzcG9uc2UgaXMgcmVxdWlyZWQg YnkgdGhlIHNlbmRlci4gIE5vdGUgdGhhdCBhbGwNCiAgICAgICAgICAgb3RoZXIgbWVzc2FnZXMg dGhhbiBDb25maWcgTWVzc2FnZSBNVVNUIGlnbm9yZSB0aGlzIGZsYWcuDQoNCiEgcHJvcG9zZSB0 byBjaGFuZ2UgdG86DQoNCi0gQUNLOiBBQ0sgaW5kaWNhdG9yKDIgYml0cykNClRoZSBBQ0sgaW5k aWNhdG9yIGZsYWcgaXMgb25seSB1c2VkIGJ5IGEgc2VuZGVyIG9mIENvbmZpZyBNZXNzYWdlIChT ZWN0aW9uIDYuNSkgb3IgSGVhcnRiZWF0IE1lc3NhZ2UgKFNlY3Rpb24gNi45KSB0byBpbmRpY2F0 ZSB0aGUgbWVzc2FnZSByZWNlaXZlciB3aGV0aGVyIG9yIG5vdCBhIHJlc3BvbnNlIGlzIHJlcXVp cmVkIGJ5IHRoZSBzZW5kZXIgZm9yIHRoZSBtZXNzYWdlLiAgTm90ZSB0aGF0IGFsbCBvdGhlciBt ZXNzYWdlcyBNVVNUIGlnbm9yZSB0aGlzIGZsYWcuDQoNCiEgVGhlIDJuZCBwbGFjZSBpczoNCg0K ICAgICAgICBBbHNvIG5vdGUgdGhhdCBtZXNzYWdlcyBvdGhlciB0aGFuIENvbmZpZyBNZXNzYWdl LCAuLi4NCg0KISBzaG91bGQgYmUgY2hhbmdlZCB0bzoNCg0KICAgICAgICBBbHNvIG5vdGUgdGhh dCBtZXNzYWdlcyBvdGhlciB0aGFuIENvbmZpZyBNZXNzYWdlIGFuZCBIZWFydGJlYXQgTWVzc2Fn ZSwgLi4uDQoNCiEgM3JkIHBsYWNlIGlzOg0KICAgICAgICAgICsgICBBc3NvY2lhdGlvbiBUZWFy ZG93biBNZXNzYWdlLCBQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSwNCiAgICAgICAgICAgICAgIGFu ZCBIZWFydGJlYXQgTWVzc2FnZSBuZXZlciBleHBlY3QgcmVzcG9uc2VzLg0KDQohIHNob3VsZCBj aGFuZ2UgdG86DQoNCiAgICAgICAgICArICAgQXNzb2NpYXRpb24gVGVhcmRvd24gTWVzc2FnZSBh bmQgUGFja2V0IFJlZGlyZWN0IE1lc3NhZ2UNCiAgICAgICAgICAgICAgbmV2ZXIgZXhwZWN0IHJl c3BvbnNlcy4NCg0KVGhhbmtzLA0KV2VpbWluZw0KDQo+IA0KPiA+IFRoZSByZWxhdGVkIGNoYW5n ZSBvbiB0aGUgSEIgbWVzc2FnZSBkZWZpbml0aW9uIA0KPiA+IChzZWN0aW9uIDYuOSkgaXMgYWxz byBuZWVkZWQgdGhlbi4gSSBjYW4gdHJ5IHRvIG1ha2UgdGhlIHNlY3Rpb24gDQo+ID4gNi45IGNo YW5nZSBhbmQgSSBob3BlIHlvdSBtYWtlIHRoZSBjaGFuZ2UgaW4gdGhpcyBzZWN0aW9uIDMsIA0K PiA+IGlzIGl0IGFsbCByaWdodD8NCj4gPiANCj4gDQo+IFllcywgaW5kZWVkLg0KPiANCj4gY2hl ZXJzLA0KPiBqYW1hbA== From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 21 13:02:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7z8-0000XA-Vt for forces-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:02:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04775 for ; Wed, 21 Sep 2005 13:02:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI85A-00005u-Py for forces-archive@IETF.ORG; Wed, 21 Sep 2005 13:08:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010F5EAF@cherry.ease.lsoft.com>; Wed, 21 Sep 2005 13:02:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86168568 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 21 Sep 2005 13:02:00 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 21 Sep 2005 13:01:52 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 22 Sep 2005 01:37:48 +0800 (CST) References: <1126115848.8422.47.camel@localhost.localdomain> <1126191810.6416.59.camel@localhost.localdomain> <00e401c5b48c$8c7535c0$1f12fea9@wwm1> <1126195602.6416.76.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126885065.24495.32.camel@localhost.localdomain> <005701c5bd8d$5d301dc0$1f12fea9@wwm1> <1127233875.6535.67.camel@localhost.localdomain> <009801c5be5b$fba76480$1152010a@Necom.hzic.edu.cn> <1127298463.6447.39.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <00a501c5bece$622046b0$1f12fea9@wwm1> Date: Thu, 22 Sep 2005 01:03:23 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 ----- Original Message ----- From: "Jamal Hadi Salim" > > Send me the text privately when ready and i will release it to the list. Jamal, I think it may be better for you to keep consistency with your XML file version maintainence by my sending you only the text instead of the XML. The text regarding the Heartbeat attributes in FEPO is just as below: Remove the following text in Section 6.2.1 on the FE Protocol Attributes paragraph: --- * Association Expiry Timer. Defualt Value = 900 msec * Heartbeat Interval. Defualt Value = 300 msec --- The reason to remove the Association Expiry Timer is, it can simply be replaced by the 'CE heartbeat dead interval', I think. Any comments ? Substitute it with the following text: --- * Heartbeat policy and parameters, which includes fields as: . CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' as described below, actually tells the FE how to check the CE liveness. The policy values with its meanings are listed as below: 0(default) - This policy specifies that CE will send a Heartbeat Message to FE whenever CE reaches a time interval within which no any other messages were sent from CE to FE (Heartbeat generated in this way is sometimes called Piggybacking-Heartbeat). A CE HDI parameter as described below is associated with this policy. FE checks the CE being alive or dead just by checking if it has or has not received any message (including Heartbeat Message itself) for the CE HDI period. Note that CE can freely choose the time interval to send Heartbeat messages and don't have to let FE know the interval, but definitely, the time interval choosen must be smaller than the CE HDI assigned. 1 - This policy specifies that CE will not send any Heartbeat Message to FE in any case. This actually means CE does not want to ask FE to check the CE liveness. Others - reserved. . FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat Interval (FE HI)', tells FE how it should act so that the CE it has associated with can check the liveness of the FE based on the actions. The policy values and the meanings are: 0(default) - This policy actually specifies no extra action for FE on its heartbeat generation. As a result, to let CE check its liveness, the FE may only just act by responding to CE whenever CE sends Heartbeat Request Message (also a normal HB message, only with whose ACK flag is set to AlwaysACK, see Section 6.9) with a Heartbeat Response Message (also a normal HB message, only with whose ACK flag is set to NoACK, see Section 6.9). 1 - This policy specifies that FE must actively send a Heartbeat Message if it reaches the time interval assigned by the FE HI followed, within which no any other messages were sent from FE to CE. Others - Reserved. . CE Heartbeat Dead Interval (CE HDI) - to tell FE the time interval the FE uses to check the CE liveness. If FE has not received any messages from CE for this time interval, FE may make a conclusion that the CE is dead or the association to the CE is lost. . FE Heartbeat Interval (FE HI) - to command FE to use the interval for the FE Heartbeat Message generation. If set to 0, it means FE must choose a default value. (Comments: Note that CE does not need to set heartbeat dead interval for FE.) --- Because of the change with the ACK flag usage in Heartbeat Message, Section 6.9 Heartbeat Message should also be changed. I propose the text as below: --- 6.9 Heartbeat Message The Heartbeat (HB) Message is used for one ForCES element (FE or CE) to asynchronously notify one or more other ForCES elements in the same ForCES NE on its liveness. A Heartbeat Message may be sent by CE or FE. The policies and the related parameters for CE or FE to generate and send Heartbeat Messages are defined as an attribute of FE protocol LFB, as described in Section 6.2.1 and also formally defined in Appendix C. A Heartbeat Message is, in its PDU, only composed of a common header, with the message body left empty. Detailed description of the message is as below. Message Transfer Direction: FE to CE, or CE to FE Message Header: The Message Type in the message header is set to MessageType = 'Heartbeat'. The ACK flag in the header can be set to the value of 'NoACK' or 'AlwaysACK' as defined in Section 5.1. The default behavior for the ACK flag that is set to any other value is defined just as the behavior of 'NoACK'. When set to 'NoACK', the message will not expect any response from the receiver. When set to 'AlwaysACK', the Heartbeat Message is then called a Heartbeat Request Message, and will then expect a response from its receiver. There is no a specific Heartbeat Response Message defined. A normal Heartbeat Message will act as a response to a Heartbeat Request Message by its correlator set to that of the responding Heartbeat Request Message and by its ACK flag always set to 'NoACK'. Current heartbeat policies as defined in Section 6.2.1 only allow a Heartbeat Request Message being sent from CE to FE rather than contrary. Message Body: The message body is empty for the Heartbeat Message. --- Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 22 09:53:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRVk-0003jQ-QH for forces-archive@megatron.ietf.org; Thu, 22 Sep 2005 09:53:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00854 for ; Thu, 22 Sep 2005 09:53:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIRbt-0001hF-EY for forces-archive@IETF.ORG; Thu, 22 Sep 2005 09:59:44 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010F700B@cherry.ease.lsoft.com>; Thu, 22 Sep 2005 9:53:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86257505 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 22 Sep 2005 09:53:07 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 22 Sep 2005 09:53:07 -0400 Received: from [162.83.99.86] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12550869; Thu, 22 Sep 2005 09:53:07 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1127239269.6535.74.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050922094543.02df5868@localhost> Date: Thu, 22 Sep 2005 09:53:02 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Minor comments on section 5 changes Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127239269.6535.74.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b I had thought we had agreed to a 64 bit correlator rather than a 32 bit correlator and a 32 b it sequence number (which is not defined as a sequence number, but still named that.) Should the paragraph after the table of ACK modes say that the failure results in an ACK if the ACK indicator has been set to 'FailureACK' or 'AlwaysACK'? I realize that if the indicator is set to 'AlwaysACK', the the ack will occur on success as well. I am just afraid that the wording may lead a lax coder to code the failure branch to only test for 'FailureACK'. The TLV nesting structure does not match the XML LFB definition structure. Nesting Path-DATA TLVs is an optimization, not a mapping of the XML. In the TLV diagram, the "variable" before "TLV Length" looks odd In the ILV section, we should note that the I values have only local scope, defined by the data declarations of the appropriate scope from the LFB definition. Otherwise a reader may expect ILVs to have global uniqueness, and they don't. Yours, Joel PS: Sorry I could not get to this earlier. At 02:01 PM 9/20/2005, Jamal Hadi Salim wrote: >Again lots of changes here, so i am not gonna supply a diff. >Please review closely - hopefully we can close before meeting. >I will post the next thing once i see substantial activity on this one. > >Some of the changes made are: >- New additional flags >- lots of text rearrangement and cleanup > > >cheers, >jamal > From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 22 10:22:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRxo-0004G5-Fg for forces-archive@megatron.ietf.org; Thu, 22 Sep 2005 10:22:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03322 for ; Thu, 22 Sep 2005 10:22:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIS3r-0002Sn-2g for forces-archive@IETF.ORG; Thu, 22 Sep 2005 10:28:44 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010F7022@cherry.ease.lsoft.com>; Thu, 22 Sep 2005 10:22:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86258604 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 22 Sep 2005 10:22:00 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 22 Sep 2005 10:21:58 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 22 Sep 2005 22:57:48 +0800 (CST) References: <1127239269.6535.74.camel@localhost.localdomain> <6.2.1.2.0.20050922094543.02df5868@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <006701c5bf81$2bf48a20$1f12fea9@wwm1> Date: Thu, 22 Sep 2005 22:23:12 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Minor comments on section 5 changes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Jamal, Thanks very much for the review. ----- Original Message ----- From: "Joel M. Halpern" > I had thought we had agreed to a 64 bit correlator rather than a 32 bit > correlator and a 32 b it sequence number (which is not defined as a > sequence number, but still named that.) Joel, I think the issue on 64bits correlator or 32-32 SN and correlator is still pending as in issue 47. In fact, the more I think it, the more I feel the necessity for the SN need. Just lets try to thik it inversely, if there is no such SN, we actually has removed any possibility for PL layer to order back messages. I just think such ordering may be necessary for some usages where some application layer of Redirected messages itself do not supply ordering back function while the order is important for the application. Note that redirect message application level is an open level, we may not be able to limit it to SNMP, RIP, etc, where ordering is not a problem, we may easily go to the point that ordering at ForCES layer is helpful for some applications in a very near future for ForCES deployment. > > Should the paragraph after the table of ACK modes say that the failure > results in an ACK if the ACK indicator has been set to 'FailureACK' or > 'AlwaysACK'? I realize that if the indicator is set to 'AlwaysACK', the > the ack will occur on success as well. I am just afraid that the wording > may lead a lax coder to code the failure branch to only test for 'FailureACK'. That makes it nice to programmers. Jamal, could you help to add some text? Thanks. > > The TLV nesting structure does not match the XML LFB definition > structure. Nesting Path-DATA TLVs is an optimization, not a mapping of the > XML. > > In the TLV diagram, the "variable" before "TLV Length" looks odd > > In the ILV section, we should note that the I values have only local scope, > defined by the data declarations of the appropriate scope from the LFB > definition. Otherwise a reader may expect ILVs to have global uniqueness, > and they don't. I agree. The I local scope should be mentioned in the text. Thanks, Weiming > > Yours, > Joel > > PS: Sorry I could not get to this earlier. > > At 02:01 PM 9/20/2005, Jamal Hadi Salim wrote: > > >Again lots of changes here, so i am not gonna supply a diff. > >Please review closely - hopefully we can close before meeting. > >I will post the next thing once i see substantial activity on this one. > > > >Some of the changes made are: > >- New additional flags > >- lots of text rearrangement and cleanup > > > > > >cheers, > >jamal > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 22 11:43:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EITEM-0003aE-Kv for forces-archive@megatron.ietf.org; Thu, 22 Sep 2005 11:43:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07683 for ; Thu, 22 Sep 2005 11:43:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EITKb-0004YN-KM for forces-archive@IETF.ORG; Thu, 22 Sep 2005 11:49:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010F711B@cherry.ease.lsoft.com>; Thu, 22 Sep 2005 11:43:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86262169 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 22 Sep 2005 11:43:23 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 22 Sep 2005 11:43:23 -0400 Received: from [162.83.99.86] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12551736; Thu, 22 Sep 2005 11:43:22 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1127239269.6535.74.camel@localhost.localdomain> <6.2.1.2.0.20050922094543.02df5868@localhost> <006701c5bf81$2bf48a20$1f12fea9@wwm1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050922113659.02d96c00@localhost> Date: Thu, 22 Sep 2005 11:43:17 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Minor comments on section 5 changes Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <006701c5bf81$2bf48a20$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Let me separate the issues a little. Redirect packets are, by definition, IP packets that are intended to flow over the internet. They are either packets arriving at the FE, which the FE concludes the CE should process, or packets the CE has handed to the FE for transmission. The Internet is not an order preserving media. There is clearly no requirement for order preservation either within the stream of redirect packets or between that stream and the control stream. [Clearly, gratuitious misordering is undesirable, but that is not what is being discussed.] For control, the TML is required to provide reliable transport. We have not required that it provide in order delivery. I would hope we won't put on such a requirement. Note that a correlator will allow the CE to locally reorder responses (if it chooses and needs to), since the CE can know what order it sent the requests to which the responses are being received. We could mandate a uni-directional sequence number for messages originated on either side. However, use of that would be a local matter to that side, as the receiver would never care about the order. As such, that is one possible use of the correlator. Finally, we could claim that we need to know the sequence of transmission between locally originated messages and responses (i.e. order between responses from the FE and notifications from the FE.) I do not belive the protocol needs this. And the text for the section as written does not provide this. We did discuss preserving the sequence number for this purpose, and the rough consensus I heard was that it was not needed. If we really need it, we can put it back. Please explain why it is needed. Yours, Joel M. Halpern At 10:23 AM 9/22/2005, Weiming Wang wrote: > > I had thought we had agreed to a 64 bit correlator rather than a 32 bit > > correlator and a 32 b it sequence number (which is not defined as a > > sequence number, but still named that.) >Joel, I think the issue on 64bits correlator or 32-32 SN and correlator is >still pending as in issue 47. In fact, the more I think it, the more I feel >the necessity for the SN need. Just lets try to thik it inversely, if >there is >no such SN, we actually has removed any possibility for PL layer to order back >messages. I just think such ordering may be necessary for some usages >where some >application layer of Redirected messages itself do not supply ordering back >function while the order is important for the application. Note that redirect >message application level is an open level, we may not be able to limit it to >SNMP, RIP, etc, where ordering is not a problem, we may easily go to the point >that ordering at ForCES layer is helpful for some applications in a very near >future for ForCES deployment. From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 22 18:01:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZ7r-0004zR-8K for forces-archive@megatron.ietf.org; Thu, 22 Sep 2005 18:01:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28327 for ; Thu, 22 Sep 2005 18:01:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIZE5-00060J-UO for forces-archive@IETF.ORG; Thu, 22 Sep 2005 18:07:38 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010F77C9@cherry.ease.lsoft.com>; Thu, 22 Sep 2005 18:00:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86294938 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 22 Sep 2005 18:00:50 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 22 Sep 2005 18:00:50 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8MM0omY014202; Thu, 22 Sep 2005 22:00:50 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8MM0oMV011224; Thu, 22 Sep 2005 22:00:50 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005092215004929428 ; Thu, 22 Sep 2005 15:00:49 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 15:00:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Minor comments on section 5 changes Thread-Index: AcW/fPuvmSfvSD4/Sh6Gdeu4mzXYhQAQ91kA X-OriginalArrivalTime: 22 Sep 2005 22:00:47.0035 (UTC) FILETIME=[161A68B0:01C5BFC1] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06C6F102@orsmsx408> Date: Thu, 22 Sep 2005 15:00:45 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Minor comments on section 5 changes Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Joel, Comments inline...=20 -----Original Message----- I had thought we had agreed to a 64 bit correlator rather than a 32 bit=20 correlator and a 32 b it sequence number (which is not defined as a=20 sequence number, but still named that.) [HK] I am pretty sure we said a 32 bit correlator & 32 bit seq no Should the paragraph after the table of ACK modes say that the failure=20 results in an ACK if the ACK indicator has been set to 'FailureACK' or=20 'AlwaysACK'? I realize that if the indicator is set to 'AlwaysACK', the the ack will occur on success as well. I am just afraid that the wording=20 may lead a lax coder to code the failure branch to only test for 'FailureACK'. [HK] Good point. Thanks for the review! Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 22 18:17:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZNS-0008UZ-AE for forces-archive@megatron.ietf.org; Thu, 22 Sep 2005 18:17:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29688 for ; Thu, 22 Sep 2005 18:17:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIZTk-0006KM-MT for forces-archive@IETF.ORG; Thu, 22 Sep 2005 18:23:45 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010F76CC@cherry.ease.lsoft.com>; Thu, 22 Sep 2005 18:17:11 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86296001 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 22 Sep 2005 18:17:10 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 22 Sep 2005 18:17:10 -0400 Received: from [162.84.74.92] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12553943 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 22 Sep 2005 18:17:10 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E06C6F102@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050922181524.02db1050@localhost> Date: Thu, 22 Sep 2005 18:17:08 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Minor comments on section 5 changes To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E06C6F102@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 But the text does not describe a sequence number. It describes an additional correlator. If we really want a sequence number, we need to spell out what it sequences, who sets it, and how it is to be used. Note that if we simply declare this to be an additional part of the correlator, the CE can use it as an echoed sequence number, or as part of a 32 bit pointer, or any other use the CE impementation wants to make. Yours, Joel At 06:00 PM 9/22/2005, Khosravi, Hormuzd M wrote: >I had thought we had agreed to a 64 bit correlator rather than a 32 bit >correlator and a 32 b it sequence number (which is not defined as a >sequence number, but still named that.) >[HK] I am pretty sure we said a 32 bit correlator & 32 bit seq no From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 23 13:43:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIraC-0000P3-Ug for forces-archive@megatron.ietf.org; Fri, 23 Sep 2005 13:43:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26880 for ; Fri, 23 Sep 2005 13:43:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIrge-0004K0-EU for forces-archive@IETF.ORG; Fri, 23 Sep 2005 13:50:18 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010F88A8@cherry.ease.lsoft.com>; Fri, 23 Sep 2005 13:43:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86356974 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 23 Sep 2005 13:43:30 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 23 Sep 2005 13:43:30 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8NGu7XK092628 for ; Fri, 23 Sep 2005 09:56:08 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-QGS9oFOVstFtUHNL2ACe" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1127497407.6353.25.camel@localhost.localdomain> Date: Fri, 23 Sep 2005 13:43:27 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: updated section 5 - please review To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.0 (++) X-Scan-Signature: eee8f8a810071652260f5b6c3a710e46 --=-QGS9oFOVstFtUHNL2ACe Content-Type: text/plain Content-Transfer-Encoding: 7bit Includes issues caught by Joel and Weiming as well as decisions on correlator field. I am attaching both a diff and the updated text. For people who dont know how to read diffs - the most important thing to observe in the diffs i send is the "+" indicates added lines and the "-" indicates deleted lines. cheers, jamal --=-QGS9oFOVstFtUHNL2ACe Content-Disposition: attachment; filename=sec5-diff.txt Content-Type: text/plain; name=sec5-diff.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit --- section5.txt 2005-09-20 11:59:59.000000000 -0400 +++ section5-update.txt 2005-09-23 13:39:04.000000000 -0400 @@ -1,3 +1,6 @@ +Internet-Draft ForCES August 2005 + + 5. Message encapsulation All PL layer PDUs start with a common header [Section 5.1] followed @@ -16,8 +19,7 @@ | Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlator | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Sequence Number | + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -43,9 +45,10 @@ Source ID (32 bit): + Dest ID (32 bit): - - + * Each of the source and Dest IDs are 32 bit IDs which are + unique NE-wide and which recognize the termination points of @@ -54,10 +57,6 @@ Internet-Draft ForCES August 2005 - Dest ID (32 bit): - - * Each of the source and Dest IDs are 32 bit IDs which are - unique NE-wide and which recognize the termination points of a ForCES PL message. * IDs allow multi/broad/unicast addressing with the following @@ -102,6 +101,10 @@ I. 0b11 0xFFFFFFFE all FEs broadcast + J. 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast + + + @@ -110,9 +113,6 @@ Internet-Draft ForCES August 2005 - J. 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast - - * Multicast or broadcast IDs are used to group endpoints (such as CEs and FES). As an example one could group FEs in some functional group, by assigning a multicast ID. Likewise, @@ -124,21 +124,19 @@ configuration process. The list of IDs an FE owns or is part of are listed on the FE Object LFB. - Correlator (32 bits) - This field is used to correlate the ForCES Requests messages - (typically sent from CE to FE) with the corresponding Response - messages (typically sent from FE to CE). The correlator is - handled transparently by the FE, i.e. for a particular Request - message it will assign the same correlator value in the - corresponding Response message. - + Correlator (64 bits) + This field is set by the CE to correlate ForCES Requests messages + with the corresponding Response messages from the Fe. + Essentially it is a cookie. The Correlator is handled + transparently by the FE, i.e. for a particular Request message it + will assign the same correlator value in the corresponding + Response message. In the case where the message from the CE does + not elicit a response, this field may not be useful. - Sequence (32 bits) - Like the Correlator the Sequence is set by the CE and echoed back - by the FE. The CE could use the combination of the Correlator - and Sequence to maintain transactional state although this is not - enforced and so the CE is free to use these 2 fields as it - pleases. + The Correlator field could be used in many ways by the CE. For + example, the CE could split the Correlator into a 32-bit + transactional identifier and 32-bit message sequence identifier. + Another example a 64 bit pointer to a context block. Flags(32 bits): Identified so far: @@ -152,10 +150,15 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ACK: ACK indicator(2 bit) - The ACK indicator flag is only used by a Config Message - sender to indicate the message receiver whether or not a - config response is required by the sender. Note that all - other messages than Config Message MUST ignore this flag. + The ACK indicator flag is only used by the CE when sending a + Config Message(Section 6.5.1) or a HB message (Section 6.9) + to indicate to the message receiver whether or not a config + response is required by the sender. Note that for all other + messages than Config Message this flag MUST be ignored. + + The flag values are defined as below: + + @@ -166,8 +169,6 @@ Internet-Draft ForCES August 2005 - The flag values are defined as below: - 'NoACK' (00) - to indicate the message receiver not to send any response message back to this message sender. @@ -185,18 +186,19 @@ 'AlwaysACK' (11) - to indicate the message receiver to send a response message back in any case. - Note that in above definitions, success means a complete - execution without any failure of the message. Anything else - than a complete successful execution is defined as a failure - for the message processing. As a result, for the execution - modes (defined in Section 3.3.1.1) like execute-all-or-none, - execute-until-failure, and continue-execute-on-failure, if - any single operation among several operations in the same - message fails, it will be treated as a failure and result in - a response if the ACK indicator has been set to 'FailureACK'. + Note that in above definitions, the term success implies a + complete execution without any failure of the message. + Anything else than a complete successful execution is defined + as a failure for the message processing. As a result, for + the execution modes (defined in Section 3.3.1.1) like + execute-all-or-none, execute-until-failure, and continue- + execute-on-failure, if any single operation among several + operations in the same message fails, it will be treated as a + failure and result in a response if the ACK indicator has + been set to 'FailureACK' or 'AlwaysACK'. - Also note that messages other than Config Message, whose - requirements for responses are described by the message + Also note that messages other than Config and HB Messages, + whose requirements for responses are described by the message definitions in Section 6, we summarise the default requirements of these messages and the expected responses below. Detailed descriptions can be found in the individual @@ -204,8 +206,8 @@ + Association Setup Message always expects a response. - + Association Teardown Message, Packet Redirect Message, - and Heartbeat Message never expect responses. + + Association Teardown Message, and Packet Redirect + Message, never expect responses. + Query Message always expects a response. @@ -217,6 +219,7 @@ + Doria (Ed.), et al. Expires February 2, 2006 [Page 26] Internet-Draft ForCES August 2005 @@ -258,7 +261,7 @@ -5.2. Type Length Value +5.2. Type Length Value(TLV) Structuring @@ -309,8 +312,9 @@ TLV values can be other TLVs. This provides the benefits of protocol flexibility (being able to add new extensions by introducing new TLVs - when needed). The nesting feature also allows easy mapping between - the XML LFB definitions to binary PL representation. + when needed). The nesting feature also allows for an conceptual + optimization with the XML LFB definitions to binary PL representation + (reperesented by nested TLVs). 5.2.2. Scope of the T in TLV @@ -325,10 +329,63 @@ Length part of the ILV is also 32 bits to allow of the referenced data to be arbitrarily large in size. - Refer to Section 6.1.1.1.8 for discussions on usage of ILVs. Doria (Ed.), et al. Expires February 2, 2006 [Page 28] Internet-Draft ForCES August 2005 + + + It should be noted that the "I" values are of local scope and are + defined by the data declarations from the LFB definition. Refer to + Section 6.1.1.1.8 for discussions on usage of ILVs. + --=-QGS9oFOVstFtUHNL2ACe Content-Disposition: attachment; filename=section5-update.txt Content-Type: text/plain; name=section5-update.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Internet-Draft ForCES August 2005 5. Message encapsulation All PL layer PDUs start with a common header [Section 5.1] followed by a one or more TLVs [Section 5.2] which may nest other TLVs [Section 5.2.1]. 5.1. Common Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |version| rsvd | Message Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlator | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Common Header The message is 32 bit aligned. Version (4 bit): Version number. Current version is 1. rsvd (4 bit): Unused at this point. A receiver should not interpret this field. Senders SHOULD set it to zero. Message Type (8 bits): Commands are defined in Section 6. Length (16 bits): length of header + the rest of the message in DWORDS (4 byte increments). Source ID (32 bit): Dest ID (32 bit): * Each of the source and Dest IDs are 32 bit IDs which are unique NE-wide and which recognize the termination points of Doria (Ed.), et al. Expires February 2, 2006 [Page 23] Internet-Draft ForCES August 2005 a ForCES PL message. * IDs allow multi/broad/unicast addressing with the following approach: a. A split address space is used to distinguish FEs from CEs. Even though we can assume that in a large NE there are typically two or more orders of magnitude more FEs than CEs, the address space is split uniformly for simplicity. b. The address space allows up to 2^30 (over a billion) CEs and the same amount of FEs. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TS | sub-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: ForCES ID Format c. The 2 most significant bits called Type Switch (TS) are used to split the ID space as follows: A. TS Corresponding ID range Assignment B. -- ---------------------- ---------- C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) E. 0b10 0x80000000 to 0xBFFFFFFF reserved F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved H. 0b11 0xFFFFFFFD all CEs broadcast I. 0b11 0xFFFFFFFE all FEs broadcast J. 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast Doria (Ed.), et al. Expires February 2, 2006 [Page 24] Internet-Draft ForCES August 2005 * Multicast or broadcast IDs are used to group endpoints (such as CEs and FES). As an example one could group FEs in some functional group, by assigning a multicast ID. Likewise, subgroups of CEs that act, for instance, in a back-up mode may be assigned a multicast ID to hide them from the FE. * We donot discuss how a particular multicast ID is associated to a given group though we note that it could be done via configuration process. The list of IDs an FE owns or is part of are listed on the FE Object LFB. Correlator (64 bits) This field is set by the CE to correlate ForCES Requests messages with the corresponding Response messages from the Fe. Essentially it is a cookie. The Correlator is handled transparently by the FE, i.e. for a particular Request message it will assign the same correlator value in the corresponding Response message. In the case where the message from the CE does not elicit a response, this field may not be useful. The Correlator field could be used in many ways by the CE. For example, the CE could split the Correlator into a 32-bit transactional identifier and 32-bit message sequence identifier. Another example a 64 bit pointer to a context block. Flags(32 bits): Identified so far: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | |ACK| Pri | EM|TP | Reserved | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ACK: ACK indicator(2 bit) The ACK indicator flag is only used by the CE when sending a Config Message(Section 6.5.1) or a HB message (Section 6.9) to indicate to the message receiver whether or not a config response is required by the sender. Note that for all other messages than Config Message this flag MUST be ignored. The flag values are defined as below: Doria (Ed.), et al. Expires February 2, 2006 [Page 25] Internet-Draft ForCES August 2005 'NoACK' (00) - to indicate the message receiver not to send any response message back to this message sender. 'SuccessACK'(01) - to inidcate the message receiver to send a response message back only when the message has been successfully processed by the receiver. 'FailureACK'(10) - to indicate the message receiver to send a response message back only when there is any failure for the receiver to process(execute) the message. In other words, if the message can be processed successfully, the sender will not expect any response from the receiver. 'AlwaysACK' (11) - to indicate the message receiver to send a response message back in any case. Note that in above definitions, the term success implies a complete execution without any failure of the message. Anything else than a complete successful execution is defined as a failure for the message processing. As a result, for the execution modes (defined in Section 3.3.1.1) like execute-all-or-none, execute-until-failure, and continue- execute-on-failure, if any single operation among several operations in the same message fails, it will be treated as a failure and result in a response if the ACK indicator has been set to 'FailureACK' or 'AlwaysACK'. Also note that messages other than Config and HB Messages, whose requirements for responses are described by the message definitions in Section 6, we summarise the default requirements of these messages and the expected responses below. Detailed descriptions can be found in the individual message definitions: + Association Setup Message always expects a response. + Association Teardown Message, and Packet Redirect Message, never expect responses. + Query Message always expects a response. + Any kind of response messages never expect further responses. Doria (Ed.), et al. Expires February 2, 2006 [Page 26] Internet-Draft ForCES August 2005 - Pri: Priority (3 bits) ForCES protocol defines 8 different levels of priority (0-7). The priority level can be used to distinguish between different protocol message types as well as between the same message type. For example, the REDIRECT PACKET message could have different priorities to distinguish between Routing protocols packets and ARP packets being redirected from FE to CE. The Normal priority level is 1. - EM: Execution mode (2 bits) There are 3 execution modes refer to Section 3.3.1.1 for details. `execute-all-or-none` (01) `execute-until-failure` (10) `continue-execute-on-failure` (11) binary 00 is reserved - TP: Transaction phase (2 bits) A message from the CE to the FE within a transaction could be indicative of the different phases the transaction is in. Refer to Section 3.3.1.1.3 for details. `MOT (Middle of transaction)` (00) `SOT (start of transaction)` (01) `EOT (end of transaction)` (10) `ABT (abort)` (11) 5.2. Type Length Value(TLV) Structuring Doria (Ed.), et al. Expires February 2, 2006 [Page 27] Internet-Draft ForCES August 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | variable TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (Data of size TLV length) | ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: TLV TLV Type (16): The TLV type field is two octets, and indicates the type of data encapsulated within the TLV. TLV Length (16): The TLV Length field is two octets, and indicates the length of this TLV including the TLV Type, TLV Length, and the TLV data. TLV Value (variable): The TLV Value field carries the data. For extensibility, the TLV value may infact be a TLV. TLVs must be 32 bit aligned. 5.2.1. Nested TLVs TLV values can be other TLVs. This provides the benefits of protocol flexibility (being able to add new extensions by introducing new TLVs when needed). The nesting feature also allows for an conceptual optimization with the XML LFB definitions to binary PL representation (reperesented by nested TLVs). 5.2.2. Scope of the T in TLV The "Type" value in TLV is of global scope. This means that wherever in the PDU hierachy a Type has global connotations. This is a design choice to ease debugging of the protocol. 5.3. ILV A slight variation of the TLV known as the ILV is introduced to allow to the "T" to be a 32-bit index that is a ForCES element ID. The Length part of the ILV is also 32 bits to allow of the referenced data to be arbitrarily large in size. Doria (Ed.), et al. Expires February 2, 2006 [Page 28] Internet-Draft ForCES August 2005 It should be noted that the "I" values are of local scope and are defined by the data declarations from the LFB definition. Refer to Section 6.1.1.1.8 for discussions on usage of ILVs. Doria (Ed.), et al. Expires February 2, 2006 [Page 29] --=-QGS9oFOVstFtUHNL2ACe-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Sep 25 12:58:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJZpj-0006c8-WF for forces-archive@megatron.ietf.org; Sun, 25 Sep 2005 12:58:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16726 for ; Sun, 25 Sep 2005 11:56:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJYyl-0000Uq-JF for forces-archive@IETF.ORG; Sun, 25 Sep 2005 12:03:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010FA407@cherry.ease.lsoft.com>; 25 Sep 2005 11:56:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86473958 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 25 Sep 2005 11:56:37 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 25 Sep 2005 11:56:36 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id j8PFcgHC029805; Sun, 25 Sep 2005 17:38:53 +0200 References: <1127497407.6353.25.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Approved-By: Avri Doria Message-ID: <0079D296-1898-4F99-B722-4EE1B5E25623@psg.com> Date: Sun, 25 Sep 2005 17:55:59 +0200 Reply-To: Avri Doria Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: updated section 5 - please review Comments: To: Jamal Hadi Salim To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127497407.6353.25.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Hi, so if i understand, the correlator is now an opaque field with not even a sequence number being required. i am concerned that this may interfere with interoperability of CE and FE systems from different vendors. Additionally I thought that the sequence number would be needed for ordering multipart messages. thanks a. On 23 sep 2005, at 19.43, Jamal Hadi Salim wrote: > > Includes issues caught by Joel and Weiming as well as decisions on > correlator field. > > I am attaching both a diff and the updated text. > For people who dont know how to read diffs - the most important > thing to > observe in the diffs i send is the "+" indicates added lines and the > "-" indicates deleted lines. > > cheers, > jamal > > > > From owner-forces@PEACH.EASE.LSOFT.COM Sun Sep 25 13:04:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJZuy-0007t7-Lu for forces-archive@megatron.ietf.org; Sun, 25 Sep 2005 13:04:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19953 for ; Sun, 25 Sep 2005 13:03:49 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJa1h-0002HX-Hp for forces-archive@IETF.ORG; Sun, 25 Sep 2005 13:10:59 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010FA3CF@cherry.ease.lsoft.com>; 25 Sep 2005 13:03:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86475973 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 25 Sep 2005 13:03:48 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 25 Sep 2005 13:03:48 -0400 Received: from [162.84.81.90] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12581842; Sun, 25 Sep 2005 13:03:47 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1127497407.6353.25.camel@localhost.localdomain> <0079D296-1898-4F99-B722-4EE1B5E25623@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050925130229.02d038a8@localhost> Date: Sun, 25 Sep 2005 13:03:42 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated section 5 - please review Comments: To: Avri Doria To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <0079D296-1898-4F99-B722-4EE1B5E25623@psg.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b You may have an interesting point with regard to the multi-message transactions. With regard to interoperability, it should actually be easier with this approach. The FE is required to always send the correlator it receives on a request back to the CE on the response. Yours, Joel At 11:55 AM 9/25/2005, Avri Doria wrote: >Hi, > >so if i understand, the correlator is now an opaque field with not >even a sequence number being required. > >i am concerned that this may interfere with interoperability of CE >and FE systems from different vendors. Additionally I thought that >the sequence number would be needed for ordering multipart messages. > >thanks >a. > >On 23 sep 2005, at 19.43, Jamal Hadi Salim wrote: > >> >>Includes issues caught by Joel and Weiming as well as decisions on >>correlator field. >> >>I am attaching both a diff and the updated text. >>For people who dont know how to read diffs - the most important >>thing to >>observe in the diffs i send is the "+" indicates added lines and the >>"-" indicates deleted lines. >> >>cheers, >>jamal >> >> >> From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 26 01:12:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJlHZ-0005QF-K1 for forces-archive@megatron.ietf.org; Mon, 26 Sep 2005 01:12:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21039 for ; Mon, 26 Sep 2005 01:12:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJlOT-0001B4-LL for forces-archive@IETF.ORG; Mon, 26 Sep 2005 01:19:18 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010FAEA9@cherry.ease.lsoft.com>; Mon, 26 Sep 2005 1:11:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86502469 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 26 Sep 2005 01:11:53 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 26 Sep 2005 01:11:53 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8Q5BoEg006206; Mon, 26 Sep 2005 05:11:50 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8Q5Bm77015820; Mon, 26 Sep 2005 05:11:50 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005092522115025827 ; Sun, 25 Sep 2005 22:11:50 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 22:11:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] updated section 5 - please review Thread-Index: AcXAZlXsSrwFhUvCQ9OJTbfI0CjucgB8hAgg X-OriginalArrivalTime: 26 Sep 2005 05:11:50.0216 (UTC) FILETIME=[CCFFE480:01C5C258] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06CEAA62@orsmsx408> Date: Sun, 25 Sep 2005 22:11:48 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: updated section 5 - please review Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable I am not sure why the correlator field was changed to 64 bits or why the sequence number was removed. I though we discussed this for several weeks before we reached a consensus on 2 fields, one for SN, one for corr...32 bits each. I don't agree with this change, atleast till I understand the reason for the change at this stage. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, September 23, 2005 10:43 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] updated section 5 - please review Includes issues caught by Joel and Weiming as well as decisions on correlator field. I am attaching both a diff and the updated text. For people who dont know how to read diffs - the most important thing to observe in the diffs i send is the "+" indicates added lines and the "-" indicates deleted lines. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 26 08:18:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJrwg-0007mA-N3 for forces-archive@megatron.ietf.org; Mon, 26 Sep 2005 08:18:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22901 for ; Mon, 26 Sep 2005 08:18:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJs3f-0003FA-6C for forces-archive@IETF.ORG; Mon, 26 Sep 2005 08:26:15 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010FB0DB@cherry.ease.lsoft.com>; Mon, 26 Sep 2005 8:18:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86516742 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 26 Sep 2005 08:18:47 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 26 Sep 2005 08:18:46 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8QBUjXK017713; Mon, 26 Sep 2005 04:30:45 -0700 (PDT) References: <1127497407.6353.25.camel@localhost.localdomain> <0079D296-1898-4F99-B722-4EE1B5E25623@psg.com> <6.2.1.2.0.20050925130229.02d038a8@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127737123.6215.311.camel@localhost.localdomain> Date: Mon, 26 Sep 2005 08:18:43 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated section 5 - please review Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050925130229.02d038a8@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit On Sun, 2005-25-09 at 13:03 -0400, Joel M. Halpern wrote: > You may have an interesting point with regard to the multi-message > transactions. > The current text says: "This field is set by the CE to correlate ForCES Requests messages with the corresponding Response messages from the Fe." That applies to Multipart messages as well i.e the corresponding request to M of N messages is message M. Do we need to be more explicit? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 26 10:13:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJtj8-0006op-Ra for forces-archive@megatron.ietf.org; Mon, 26 Sep 2005 10:13:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29502 for ; Mon, 26 Sep 2005 10:12:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJtpz-0006Pp-E6 for forces-archive@IETF.ORG; Mon, 26 Sep 2005 10:20:16 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010FB390@cherry.ease.lsoft.com>; Mon, 26 Sep 2005 10:12:51 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86524281 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 26 Sep 2005 10:12:49 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 26 Sep 2005 10:12:49 -0400 Received: from [162.84.81.90] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12588859; Mon, 26 Sep 2005 10:12:49 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E06CEAA62@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050926101015.02faef08@localhost> Date: Mon, 26 Sep 2005 10:12:43 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated section 5 - please review Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E06CEAA62@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 There are two issues: 1) I thought the discussions on the list and face to face had agreed that making it a single 64 bit correlator (which can be subdivided by the CE any way it wants) was the rough consensus. -- among the interesting points in favor was that this meant that the sender could use the correlator as a raw pointer even if it used 64 bit pointers. 2) The text as provided does not describe a sequence number. It does not describe somehting that solves the one open question, which is if / how to get order right for multi-part transactions. Yours, Joel At 01:11 AM 9/26/2005, Khosravi, Hormuzd M wrote: >I am not sure why the correlator field was changed to 64 bits or why the >sequence number was removed. I though we discussed this for several >weeks before we reached a consensus on 2 fields, one for SN, one for >corr...32 bits each. > >I don't agree with this change, atleast till I understand the reason for >the change at this stage. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim >Sent: Friday, September 23, 2005 10:43 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] updated section 5 - please review > > >Includes issues caught by Joel and Weiming as well as decisions on >correlator field. > >I am attaching both a diff and the updated text. >For people who dont know how to read diffs - the most important thing to >observe in the diffs i send is the "+" indicates added lines and the >"-" indicates deleted lines. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 26 10:14:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJtkQ-00072M-Ql for forces-archive@megatron.ietf.org; Mon, 26 Sep 2005 10:14:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29653 for ; Mon, 26 Sep 2005 10:14:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJtrU-0006RP-SS for forces-archive@IETF.ORG; Mon, 26 Sep 2005 10:21:45 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010FB36F@cherry.ease.lsoft.com>; Mon, 26 Sep 2005 10:14:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86524356 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 26 Sep 2005 10:14:19 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 26 Sep 2005 10:14:19 -0400 Received: from [162.84.81.90] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12588871; Mon, 26 Sep 2005 10:14:18 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1127497407.6353.25.camel@localhost.localdomain> <0079D296-1898-4F99-B722-4EE1B5E25623@psg.com> <6.2.1.2.0.20050925130229.02d038a8@localhost> <1127737123.6215.311.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050926101256.02faf198@localhost> Date: Mon, 26 Sep 2005 10:14:12 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated section 5 - please review Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127737123.6215.311.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 The question that occurred to me when I read Avri's note was "how does a receiver know it has received and processed all the messages in a transaction if they may come out of order and do not have a sequence number? Yours, Joel At 08:18 AM 9/26/2005, Jamal Hadi Salim wrote: >On Sun, 2005-25-09 at 13:03 -0400, Joel M. Halpern wrote: > > You may have an interesting point with regard to the multi-message > > transactions. > > > >The current text says: > >"This field is set by the CE to correlate ForCES Requests messages >with the corresponding Response messages from the Fe." > >That applies to Multipart messages as well i.e the corresponding request >to M of N messages is message M. >Do we need to be more explicit? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 26 11:06:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuZD-0005cc-4P for forces-archive@megatron.ietf.org; Mon, 26 Sep 2005 11:06:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05801 for ; Mon, 26 Sep 2005 11:06:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJugE-0000Pj-29 for forces-archive@IETF.ORG; Mon, 26 Sep 2005 11:14:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010FB4E1@cherry.ease.lsoft.com>; Mon, 26 Sep 2005 11:06:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86527869 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 26 Sep 2005 11:06:49 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 26 Sep 2005 11:06:49 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8QEIkXK019149 for ; Mon, 26 Sep 2005 07:18:47 -0700 (PDT) References: <1127497407.6353.25.camel@localhost.localdomain> <0079D296-1898-4F99-B722-4EE1B5E25623@psg.com> <6.2.1.2.0.20050925130229.02d038a8@localhost> <1127737123.6215.311.camel@localhost.localdomain> <6.2.1.2.0.20050926101256.02faf198@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127747206.6185.8.camel@localhost.localdomain> Date: Mon, 26 Sep 2005 11:06:46 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated section 5 - please review To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050926101256.02faf198@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Mon, 2005-26-09 at 10:14 -0400, Joel M. Halpern wrote: > The question that occurred to me when I read Avri's note was "how does a > receiver know it has received and processed all the messages in a > transaction if they may come out of order and do not have a sequence number? > My take on this: - An atomic transaction is marked by a SOT, zero or more MOT and terminated by EOT i.e. we have a beginning and ending. Nothing gets processed (executed is more fitting) until all are assembled and only when the CE says so. So ordering is not a big concern as long as reliability requirement is met i.e TCP as a TML should be good enough. - Anything that is not Atomic and sends multi-part messages should not care about ordering. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 26 12:09:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvXW-0007Ww-SY for forces-archive@megatron.ietf.org; Mon, 26 Sep 2005 12:09:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21478 for ; Mon, 26 Sep 2005 12:09:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJvea-0006m3-Ic for forces-archive@IETF.ORG; Mon, 26 Sep 2005 12:16:33 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010FB7D0@cherry.ease.lsoft.com>; Mon, 26 Sep 2005 12:09:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86536311 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 26 Sep 2005 12:09:06 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 26 Sep 2005 12:09:06 -0400 Received: from [162.84.81.90] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12590174; Mon, 26 Sep 2005 12:08:59 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1127497407.6353.25.camel@localhost.localdomain> <0079D296-1898-4F99-B722-4EE1B5E25623@psg.com> <6.2.1.2.0.20050925130229.02d038a8@localhost> <1127737123.6215.311.camel@localhost.localdomain> <6.2.1.2.0.20050926101256.02faf198@localhost> <1127747206.6185.8.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050926120354.02e2b3e0@localhost> Date: Mon, 26 Sep 2005 12:08:53 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated section 5 - please review Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127747206.6185.8.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 The unanswered question though is how the received all the intermediate components. If a middle and the end could be swapped, the receiver might try the transaction while missing a piece. My guess is that transactional support will require a sequence number. My current suggestion, if I have understood the problem properly, is that for a transaction, all requests within a transaction shall use the same 32 bit correlator, and the sequence number applies within the transaction. This also helps handle the case of two interleaved transactions. For individual messages that are not part of a multi-message transaction, the sequence number should be treated as an additional correlator. This gives up the 64 bit pointer for multi-message transaction. (Which suggests that one would never try to use the 64 bit pointer directly. Oh well.) Yours, At 11:06 AM 9/26/2005, Jamal Hadi Salim wrote: >On Mon, 2005-26-09 at 10:14 -0400, Joel M. Halpern wrote: > > The question that occurred to me when I read Avri's note was "how does a > > receiver know it has received and processed all the messages in a > > transaction if they may come out of order and do not have a sequence > number? > > > >My take on this: > >- An atomic transaction is marked by a SOT, zero or more MOT and >terminated by EOT i.e. we have a beginning and ending. Nothing >gets processed (executed is more fitting) until all are assembled and >only when the CE says so. >So ordering is not a big concern as long as reliability requirement is >met i.e TCP as a TML should be good enough. > >- Anything that is not Atomic and sends multi-part messages should not >care about ordering. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 26 13:08:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJwT7-0002Xn-Lm for forces-archive@megatron.ietf.org; Mon, 26 Sep 2005 13:08:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24423 for ; Mon, 26 Sep 2005 13:08:43 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJwaC-0008Jr-3I for forces-archive@IETF.ORG; Mon, 26 Sep 2005 13:16:05 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010FBB1A@cherry.ease.lsoft.com>; Mon, 26 Sep 2005 13:08:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86541595 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 26 Sep 2005 13:08:41 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 26 Sep 2005 13:08:41 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j8QGKbXK020529 for ; Mon, 26 Sep 2005 09:20:38 -0700 (PDT) References: <1127497407.6353.25.camel@localhost.localdomain> <0079D296-1898-4F99-B722-4EE1B5E25623@psg.com> <6.2.1.2.0.20050925130229.02d038a8@localhost> <1127737123.6215.311.camel@localhost.localdomain> <6.2.1.2.0.20050926101256.02faf198@localhost> <1127747206.6185.8.camel@localhost.localdomain> <6.2.1.2.0.20050926120354.02e2b3e0@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1127754519.6185.50.camel@localhost.localdomain> Date: Mon, 26 Sep 2005 13:08:39 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated section 5 - please review To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050926120354.02e2b3e0@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On Mon, 2005-26-09 at 12:08 -0400, Joel M. Halpern wrote: > The unanswered question though is how the received all the intermediate > components. > If a middle and the end could be swapped, the receiver might try the > transaction while missing a piece. > > My guess is that transactional support will require a sequence number. > > My current suggestion, if I have understood the problem properly, is that > for a transaction, all requests within a transaction shall use the same 32 > bit correlator, and the sequence number applies within the > transaction. This also helps handle the case of two interleaved transactions. > Indeed - with a caveat: Note that: ordering depends on the TML as well and in theory it is the TMLs responsibility. No guarantees with TCP but I think TIPC and SCTP both can guarantee ordering. > For individual messages that are not part of a multi-message transaction, > the sequence number should be treated as an additional correlator. > We do state this as an example. Do you think we need more text than whats already there? > This gives up the 64 bit pointer for multi-message transaction. (Which > suggests that one would never try to use the 64 bit pointer directly. Oh > well.) > One could still add an extra TLV at the top level for this. If you see the need for more text, let me know. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 26 13:35:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJwt4-0002mY-At for forces-archive@megatron.ietf.org; Mon, 26 Sep 2005 13:35:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25398 for ; Mon, 26 Sep 2005 13:35:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJx03-0000SA-Sl for forces-archive@IETF.ORG; Mon, 26 Sep 2005 13:42:54 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010FBCFF@cherry.ease.lsoft.com>; Mon, 26 Sep 2005 13:29:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86543453 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 26 Sep 2005 13:29:08 -0400 Received: from 207.152.136.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 26 Sep 2005 13:29:08 -0400 Received: from [162.84.81.90] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12590904; Mon, 26 Sep 2005 13:29:07 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1127497407.6353.25.camel@localhost.localdomain> <0079D296-1898-4F99-B722-4EE1B5E25623@psg.com> <6.2.1.2.0.20050925130229.02d038a8@localhost> <1127737123.6215.311.camel@localhost.localdomain> <6.2.1.2.0.20050926101256.02faf198@localhost> <1127747206.6185.8.camel@localhost.localdomain> <6.2.1.2.0.20050926120354.02e2b3e0@localhost> <1127754519.6185.50.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050926132817.02fa64d8@localhost> Date: Mon, 26 Sep 2005 13:29:01 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated section 5 - please review Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1127754519.6185.50.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 You do suggest the other alternative. We could require that the TML provide in-order delivery. This would not bother me personally, since I prefer TCP / SCTP, which do provide in-order delivery. Yours, Joel At 01:08 PM 9/26/2005, Jamal Hadi Salim wrote: >On Mon, 2005-26-09 at 12:08 -0400, Joel M. Halpern wrote: > > The unanswered question though is how the received all the intermediate > > components. > > If a middle and the end could be swapped, the receiver might try the > > transaction while missing a piece. > > > > My guess is that transactional support will require a sequence number. > > > > My current suggestion, if I have understood the problem properly, is that > > for a transaction, all requests within a transaction shall use the same 32 > > bit correlator, and the sequence number applies within the > > transaction. This also helps handle the case of two interleaved > transactions. > > > >Indeed - with a caveat: > >Note that: ordering depends on the TML as well and in theory it is the >TMLs responsibility. No guarantees with TCP but I think TIPC and SCTP >both can guarantee ordering. > > > For individual messages that are not part of a multi-message transaction, > > the sequence number should be treated as an additional correlator. > > > >We do state this as an example. >Do you think we need more text than whats already there? > > > This gives up the 64 bit pointer for multi-message transaction. (Which > > suggests that one would never try to use the 64 bit pointer directly. Oh > > well.) > > > >One could still add an extra TLV at the top level for this. >If you see the need for more text, let me know. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 26 20:20:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK3DK-0007Lp-UT for forces-archive@megatron.ietf.org; Mon, 26 Sep 2005 20:20:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20492 for ; Mon, 26 Sep 2005 20:20:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK3KU-0003Xv-3g for forces-archive@IETF.ORG; Mon, 26 Sep 2005 20:28:18 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010FC224@cherry.ease.lsoft.com>; Mon, 26 Sep 2005 20:20:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86570626 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 26 Sep 2005 20:20:52 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 26 Sep 2005 20:20:52 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j8R0KpBV028360; Tue, 27 Sep 2005 00:20:51 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j8R0Ji7o030692; Tue, 27 Sep 2005 00:20:49 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005092617134126838 ; Mon, 26 Sep 2005 17:13:44 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 17:12:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] updated section 5 - please review Thread-Index: AcXCpGS9nc4S8UdwS4CAMZI2kwi5HAAUwxug X-OriginalArrivalTime: 27 Sep 2005 00:12:53.0458 (UTC) FILETIME=[34459320:01C5C2F8] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06D2A131@orsmsx408> Date: Mon, 26 Sep 2005 17:12:52 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: updated section 5 - please review Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable I would prefer 2 32 bit fields, 1 SN, 1 corr with functionality clearly called out. This would make it much easier to implement & interoperate. There were several other reasons for maintaining a SN which I don't want to reiterate in this email, you can check the archive. Also, I don't buy the 64 bit pointer argument, cause I don't know of any protocols out there that have designed their fields to accommodate this. However, if the decision has already been made about a single 64 bit field, I can live with it. I am a bit surprised about rough consensus around this at the IETF meeting, cause the rough consensus on the mailing list was different. Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Monday, September 26, 2005 7:13 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] updated section 5 - please review There are two issues: 1) I thought the discussions on the list and face to face had agreed that=20 making it a single 64 bit correlator (which can be subdivided by the CE any=20 way it wants) was the rough consensus. -- among the interesting points in favor was that this meant that the=20 sender could use the correlator as a raw pointer even if it used 64 bit=20 pointers. 2) The text as provided does not describe a sequence number. It does not=20 describe somehting that solves the one open question, which is if / how to=20 get order right for multi-part transactions. Yours, Joel At 01:11 AM 9/26/2005, Khosravi, Hormuzd M wrote: >I am not sure why the correlator field was changed to 64 bits or why the >sequence number was removed. I though we discussed this for several >weeks before we reached a consensus on 2 fields, one for SN, one for >corr...32 bits each. > >I don't agree with this change, atleast till I understand the reason for >the change at this stage. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim >Sent: Friday, September 23, 2005 10:43 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] updated section 5 - please review > > >Includes issues caught by Joel and Weiming as well as decisions on >correlator field. > >I am attaching both a diff and the updated text. >For people who dont know how to read diffs - the most important thing to >observe in the diffs i send is the "+" indicates added lines and the >"-" indicates deleted lines. > >cheers, >jamal From PattyBritt@eati.co.uk Fri Sep 30 21:05:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELVp5-0001eK-8M for forces-archive@megatron.ietf.org; Fri, 30 Sep 2005 21:05:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02046 for ; Fri, 30 Sep 2005 21:05:53 -0400 (EDT) Received: from [222.115.204.112] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELVwt-0004lu-Tb for forces-archive@ietf.org; Fri, 30 Sep 2005 21:14:09 -0400 Received: from Azt@localhost by EutL.int (8.11.6/8.11.6); Sat, 01 Oct 2005 06:40:34 +0400 Message-ID: From: "Tori Alexander" Reply-To: "Tori Alexander" To: forces-archive@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 Adobe Date: Fri, 30 Sep 2005 21:31:34 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: PattyBritt@eati.co.uk Content-Type: multipart/mixed; boundary="--oKWXDFA1L5WMlFC" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 7OZ ----oKWXDFA1L5WMlFC Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Q
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: 0l03N78Ss
 

Sales = Rank: #1
System requirements  |  Other Versions
Date Coupon Expires:= August 31st, 2005
Average Customer R= eview:3D"5 Based on 1547 reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 <= /td>

<= img height=3D150 src=3Dhttp://images.amazon.com/images/P/B00081I6JI.01._PE= 7_SCMZZZZZZZ_.jpg width=3D144 align=3Dleft border=3D0 name=3Dprod_image>

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: e53HGWhgF
 = ;

Sales Rank: #2
System requirements&nbs= p; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 12292= 1 reviews. Write a review.

<= p>Microsoft Windows XP Professional or Longhorn Edition
Microsoft<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sti= cker/newest_version.gif width=3D82 height=3D14>

Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)



Ava= ilability: Available for INSTANT download!
Coupon Code: r8P= q6
 

Sales Rank: #3=
System requirem= ents  |  Other Versions
Date Coupon Expires: August 31st, 2= 005
Average Customer Review:3D"5 = Based on 192726 reviews. Write a review<= /a>.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: HtOh0Lu8
 =

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 11822= reviews. Write a review.

=

<= /form> ----oKWXDFA1L5WMlFC--