From CindyAdair@lookcarbone.com Sat Jul 02 18:05:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Doq7U-0000R3-Ci for forces-archive@megatron.ietf.org; Sat, 02 Jul 2005 18:05: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 SAA03798 for ; Sat, 2 Jul 2005 18:05:49 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoqXh-0001Cy-8j for forces-archive@ietf.org; Sat, 02 Jul 2005 18:33:00 -0400 Received: from [221.229.203.223] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Doq7B-0003zH-Ux for forces-archive@ietf.org; Sat, 02 Jul 2005 18:05:36 -0400 Received: from 2kFP@localhost by Enkf.int (8.11.6/8.11.6); Sat, 02 Jul 2005 20:56:34 -0200 Message-ID: From: "Weston Hutchins" Reply-To: "Weston Hutchins" To: lupe.goff@ietf.org, forces-archive@ietf.org Subject: AutoCAD Products available for Download Date: Sun, 03 Jul 2005 00:52:34 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: CindyAdair@lookcarbone.com Content-Type: multipart/mixed; boundary="--7w6TrKWSAtpTFa70C6" X-Spam-Score: 4.8 (++++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 kIA ----7w6TrKWSAtpTFa70C6 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable g
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH

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

TOP 10 NEW TITLES

<= /td>
5

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Window= s XP Pro
 3 Adobe Cre= ative Suite Premium
 4 Norton Antivirus 2005
  Flash MX 2004
 6 Corel Draw 12
 7 Adobe = Acrobat 7.0
 8 Window= s 2003 Server
 9 Alias = Maya 6 Wavefrt
 10 Adobe = Premiere
  See more= by this manufacturer
 <= /td>  Microsoft<= /td>
   Apple Software
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...
<= /td>



Microsoft Offi= ce Professional Edition *2003*
Microsoft
Choose= :
&= nbsp;
=
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze= and manage business information using Access databases
  • Exchange data with other systems using enhance= d XML technology
  • Control inf= ormation sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters a= nd printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: Int= ernational/US or via instant download
Date Coupon Expires: June= 30th, 2005
Average Customer Review: = 3D"5 Based on 1,768 reviews. Write a= review.
Microsoft Windows XP Professional or = Longhorn Edition
Microsoft =
Choose:
<= /td> <= /a>

List Price:$279.00
Price:$49.99
You Save:<= /td>$229.01 (= 85%)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Desi= gned for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt f= iles and folders
  • Built-in vo= ice, video, and instant messaging support
  • <= font size=3D1>Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Co= upon Expires: June 30th, 2005
Average= Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9= 0
Adobe=
Choose:=
 

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



= Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |&nb= sp; Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.=

----7w6TrKWSAtpTFa70C6-- From NorahHackett@wildnativesnursery.net Sun Jul 03 00:18:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dovvw-0005e2-52 for forces-archive@megatron.ietf.org; Sun, 03 Jul 2005 00:18: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 AAA01925 for ; Sun, 3 Jul 2005 00:18: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.33) id 1DowM8-00077Q-SL for forces-archive@ietf.org; Sun, 03 Jul 2005 00:45:31 -0400 Received: from [60.171.139.137] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DovuH-0005EE-4R for forces-archive@ietf.org; Sun, 03 Jul 2005 00:16:46 -0400 Received: from ywg@localhost by aTA.int (8.11.6/8.11.6); Sun, 03 Jul 2005 11:29:49 +0600 Message-ID: From: "Vivian Rogers" Reply-To: "Vivian Rogers" To: lupe.goff@ietf.org Subject: 80 % Discount on All Systemworks Titles Date: Sun, 03 Jul 2005 08:27:49 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NorahHackett@wildnativesnursery.net Content-Type: multipart/mixed; boundary="--saXuQukVKHYiHcHX0btQ" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 W03 ----saXuQukVKHYiHcHX0btQ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 3
Opt-in Email Special Offer &n= bsp;   unsubscribe me=
= = List Price:
SEARCH

TOP 10 NEW TITLES

= =

 = ON SALE NOW!

 1 Office Pro 2003
 2 W= indows XP Pro
 3 Adob= e Creative Suite Premium
 4<= a href=3Dhttp://vitriolware.com/?w> Norton Antivirus 2005
 = 5 Flash MX 2004
 6 Corel Draw 12
 7= Adobe Acrobat 7.0
 8 Windows 2003 Server
 = ;9 Alias Maya 6 Wavefrt
&= nbsp;10 Adobe Premiere
&= nbsp; See more by this manufacturer
   Microsoft
   Apple Softwar= e
  Customers also b= ought
   these other items...



Microsoft Office Professional Edition *2003*
Microsoft
Choose:
 
$899.00
Price:$69.99
You Save= :$830.01 (92%)



Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
Media: CD-ROM / Download

System re= quirements  |  Accessori= es  |  Other Versions

Features:

  • Analyze and manage business inform= ation using Access databases
  • Exchange data with other systems using enhanced XML technology
  • Control information sharing rules with= enhanced IRM technology
  • Eas= y-to-use wizards to create e-mail newsletters and printed marketing materi= als
  • More than 20 preformatte= d business reports
Sales Ra= nk: #1
Shipping: International/US or via insta= nt download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 re= views. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
<= span class=3Dsmall>Microsoft
Choose:
 = ;

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



Availability: Available for = INSTANT download!
Coupon Code: ISe229
Media: CD-ROM = / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for = businesses of all sizes
  • Mana= ge digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and f= olders
  • Built-in voice, video= , and instant messaging support
  • Integration with Windows servers and management solutions

    • Sales Rank: #2
    Shippin= g: International/US or via instant download
    Date Coupon Expires= : June 30th, 2005
    Average Customer Re= view: 3D"5 Based on 868 reviews. Write a review.

    Adobe Photoshop CS2 V 9.0
    = Adobe
    =
    Choose:
     

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


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements = ; |  Accessories  | = ; Other Versions

    <= font size=3D1>Features:

    • Customized workspace; save personalized workspace= and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production tasks wi= th built-in or customized scripts
    • Improved file management, new design possibilities, and a more intui= tive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-square pixel= s
    • Create or modify photos us= ing painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 498 reviews. Write = a review.

----saXuQukVKHYiHcHX0btQ-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jul 05 20:14:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpxWo-0007Kr-15 for forces-archive@megatron.ietf.org; Tue, 05 Jul 2005 20:12: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 UAA23072 for ; Tue, 5 Jul 2005 20:07:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpxhg-0008Lh-3u for forces-archive@IETF.ORG; Tue, 05 Jul 2005 20:23: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 <23.0109BA7C@cherry.ease.lsoft.com>; Tue, 5 Jul 2005 19:56:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78096649 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 5 Jul 2005 19:56:02 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Jul 2005 19:55:57 -0400 Received: from [162.83.102.184] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11273803 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 05 Jul 2005 19:55:57 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 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.20050705195058.02f3d148@localhost> Date: Tue, 5 Jul 2005 19:55:49 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: New model DRAFT To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d I have completed an editing pass on the model document. I have added aliases, properties, and events. I have added an example to try to explain how some of this works. Jamal has very helpfully posted the draft at: ftp://ftp.znyx.com/users/hadi/private/forces/ Note, this is the word document. It has change tracking turned on, so you should easily be able to tell what I did. Ellen will be working this document over when she gets back from vacation, and we will submit that to the I-D respository. The XML Schema passes XMLSpy's validity test. The two LFBs validate against that schema. I believe the example is indented badly. Sorry. I can not get word to cooperate on it. One note on the Schema. I do not have the tools to usefully validate the Key / KeyRef declarations. And while my tool uses them, I think it uses them wrong because I get mysterious errors. If someone who understands Key / KeyRef could look at them, I am happy to fix them up. I am sure there are many other errors. And probably places that need clarification even if they are not wrong. Please, Please, Please read the draft. Send comments. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 06 02:24:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq3KE-0007vW-UC for forces-archive@megatron.ietf.org; Wed, 06 Jul 2005 02:24: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 CAA29858 for ; Wed, 6 Jul 2005 02:24:01 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq3l5-0002ce-Fd for forces-archive@IETF.ORG; Wed, 06 Jul 2005 02:51: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 <14.0109C13F@cherry.ease.lsoft.com>; Wed, 6 Jul 2005 2:23:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78120028 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 6 Jul 2005 02:23:55 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Jul 2005 02:23:55 -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 j666Ns14030808 for ; Wed, 6 Jul 2005 06:23:54 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 j666Nnxi022915 for ; Wed, 6 Jul 2005 06:23:54 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 M2005070523235413719 for ; Tue, 05 Jul 2005 23:23:54 -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); Tue, 5 Jul 2005 23:23:53 -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_01C581F3.47B44823" Thread-Topic: issues tracker updated for issues 22, 32, 47, 53, 54 thread-index: AcWB80aWwIB+BAf9QGuRs+o+hQ13sQ== X-OriginalArrivalTime: 06 Jul 2005 06:23:53.0375 (UTC) FILETIME=[47EE1AF0:01C581F3] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05E08B27@orsmsx408> Date: Tue, 5 Jul 2005 23:23:51 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: issues tracker updated for issues 22, 32, 47, 53, 54 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b This is a multi-part message in MIME format. ------_=_NextPart_001_01C581F3.47B44823 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have updated the ForCES issues tracker to reflect the discussion and resolution we had for the following issues last week... # 22, 32, 47, 53, 54 =20 The draft needs to be updated accordingly. Pls let me know if there are any comments. =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C581F3.47B44823 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have updated the ForCES issues tracker to reflect = the discussion and resolution we had for the following issues last = week…

# 22, 32, 47, 53, 54

 

The draft needs to be updated accordingly. Pls let me = know if there are any comments.

 

Thanks

Hormuzd

 

------_=_NextPart_001_01C581F3.47B44823-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 06 10:55:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBJ5-0004Ek-63 for forces-archive@megatron.ietf.org; Wed, 06 Jul 2005 10:55: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 KAA06015 for ; Wed, 6 Jul 2005 10:55:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqBbd-0006Ex-KB for forces-archive@IETF.ORG; Wed, 06 Jul 2005 11: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 <4.0109C74B@cherry.ease.lsoft.com>; Wed, 6 Jul 2005 10:46:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78130892 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 6 Jul 2005 10:46:37 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Jul 2005 10:46:35 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Wed, 6 Jul 2005 23:24:31 +0800 (CST) References: <6.2.1.2.0.20050630104547.02f12a50@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: <002e01c58239$6f9500f0$1f12fea9@wwm1> Date: Wed, 6 Jul 2005 22:44:47 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: base64 Sm9lbCwNCg0KSSB0ZW5kIHRvIGFncmVlIHdpdGggeW91ciBpZGVhIGJlbG93IGV4Y2VwdCB0aGUg aW5kZXguICBDb3VsZCB5b3UgZ2l2ZSBtb3JlIGRldGFpbHMgb24gaXRzIG5lY2Vzc2l0eT8gVGhh bmtzLg0KQXMgYSByZXN1bHQsIHRoZSBhZ3JlZWFibGUgZm9ybWF0IHRvIG1lIHNlZW1zIGxpa2U6 DQoNClJlZGlyZWN0IFRMViwgd2hpdGggY29udGFpbnMNCiAgICBMRkIgY2xhc3MgSUQNCiAgICBM RkIgaW5zdGFuY2UgSUQNCiAgICBvcGVyYXRpb24gVExWIChSRVBPUlQpLCB3aGljaCBjb250YWlu cyBQYXRoLURhdGENCiAgICBQYWNrZXQgVExWDQoNCldlIGZ1cnRoZXIgZGVmaW5lIHRoYXQgdGhh dCBQYXRoLURhdGEgc2hvdWxkIHN1cHBseSBlbm91Z2ggaW5mb3JtYXRpb24gZm9yIHRoZSBmb2xs b3dlZCBwYWNrZXQuIEF0IGxlYXN0IGl0IHNob3VsZCBpbmNsdWRlIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBwb3J0IG51bWJlciB0aGUgcmVkaXJlY3QgcGFja2V0IGlzIGlucHV0KHNpbmsgTEZCKSBv ciBpcyBvdXRwdXQgKHNvdXJjZSBMRkIpLCBhbmQgdGhlIHJlZGlyZWN0IHBhY2tldCB0eXBlLiBI b3cgdGhpcyBpcyBkZWZpbmVkIGlzIGxlZnQgdG8gbW9kZWwgd2hlcmUgcmVkaXJlY3QgTEZCcyBh bmQgdGhlIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQuDQoNCldlIG5lZWQgdG8gc29sdmUgdGhpcyBh IGxpdHRsZSBzb29uZXIuDQoNCnRob3VnaHRzPyANCg0KVGhhbmtzLA0KV2VpbWluZw0KDQotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvZWwgTS4gSGFscGVybiIgPGpvZWxA c3RldmVjcm9ja2VyLmNvbT4NClN1YmplY3Q6IFJlZGlyZWN0IE1lc3NhZ2UNCg0KDQo+IEJhc2Vk IG9uIGRpc2N1c3Npb24sIGFuZCBiYXNlZCBvbiBteSBlYXJsaWVyIG1lc3NhZ2UgdGhhdCBzcGVj aWZpYyBwcm90b2NvbCANCj4gbWVzc2FnZXMgbWF5IGhhdmUgZGlmZmVyZW50IHRvcCBsZXZlbCBU TFZzLCBoZXJlIGlzIGEgZGVzY3JpcHRpb24gb2YgdGhlIA0KPiBjb250ZW50cyBvZiBhIHJlZGly ZWN0IG1lc3NhZ2UuDQo+IA0KPiBBIHJlZGlyZWN0IG1lc3NhZ2Ugd2lsbCBjb250YWluIGEgcmVk aXJlY3QgVExWLg0KPiBBIHJlZGlyZWN0IFRMViBjb25zaXN0cyBvZiB0aHJlZSBmaXhlZCBmaWVs ZHMsIGFuZCBtZXRhLWRhdGEgVExWLCBhbmQgdGhlIA0KPiBwYWNrZXQuDQo+IFRoZSBmaXhlZCBm aWVsZHMgYXJlDQo+IG8gdGhlIExGQiBDbGFzcyBJRCBvZiB0aGUgcmVkaXJlY3Qgc291cmNlIG9y IHJlZGlyZWN0IHNpbmsgTEZCIG9uIHRoZSBGRSANCj4gYXNzb2NpYXRlZCB3aXRoIHRoaXMgcGFj a2V0DQo+IG8gdGhlIExGQiBJbnN0YW5jZSBJRCBvZiB0aGUgcmVkaXJlY3Qgc291cmNlIG9yIHJl ZGlyZWN0IHNpbmsgTEZCIG9uIHRoZSBGRSANCj4gYXNzb2NpYXRlZCB3aXRoIHRoaXMgcGFja2V0 DQo+IG8gYW4gaW5kZXggd2l0aGluIHRoYXQgTEZCIHRvIGlkZW50aWZ5IGNvbmZpZ3VyZWQgcHJv cGVydGllcyBvZiB0aGUgcGFja2V0Lg0KPiANCj4gVGhlIG1ldGEtZGF0YSBUTFYgY29udGFpbnMg ZHluYW1pYyBpbmZvcm1hdGlvbiBuZWVkZWQgYnkgdGhlIEZFIG9yIENFIHRvIA0KPiBwcm9jZXNz IHRoZSBwYWNrZXQuICBUaGlzIHdpbGwgbmVlZCB0byBiZSBzcGVsbGVkIG91dCBpbiBtb3JlIGRl dGFpbC4gIEl0IA0KPiBtYXkgbmVlZCB0byB1c2UgcGF0aCBlbmNvZGluZy4NCj4gDQo+IEZvbGxv d2luZyB0aGlzIHdpbGwgYmUgdGhlIHBhY2tldC4NCj4gDQo+IFlvdXJzLA0KPiBKb2Vs From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 06 16:10:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGDo-0003ao-Qt for forces-archive@megatron.ietf.org; Wed, 06 Jul 2005 16:10: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 QAA17806 for ; Wed, 6 Jul 2005 16:10:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqGel-00060l-9F for forces-archive@IETF.ORG; Wed, 06 Jul 2005 16:38:14 -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.0109CC15@cherry.ease.lsoft.com>; Wed, 6 Jul 2005 16:10:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78155151 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 6 Jul 2005 16:10:00 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Jul 2005 16:10:00 -0400 Received: from [12.58.128.11] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11288454; Wed, 06 Jul 2005 16:10:01 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050630104547.02f12a50@localhost> <002e01c58239$6f9500f0$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.20050706160833.02dd3310@localhost> Date: Wed, 6 Jul 2005 16:09:57 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <002e01c58239$6f9500f0$1f12fea9@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c After some discussion, the operational data may be simpler than I had been thinking. We can simply attach (in some reasonable TLV format) all the meta-data. So packets from the CE come with meta-data, and the CE gets all the meta-data from the FE associated with a packet. That ensures that all the necessary information is available, without making the redirect LFBs complex. Yours, Joel At 10:44 AM 7/6/2005, Weiming Wang wrote: >Joel, > >I tend to agree with your idea below except the index. Could you give >more details on its necessity? Thanks. >As a result, the agreeable format to me seems like: > >Redirect TLV, whith contains > LFB class ID > LFB instance ID > operation TLV (REPORT), which contains Path-Data > Packet TLV > >We further define that that Path-Data should supply enough information for >the followed packet. At least it should include information about the port >number the redirect packet is input(sink LFB) or is output (source LFB), >and the redirect packet type. How this is defined is left to model where >redirect LFBs and the attributes are defined. > >We need to solve this a little sooner. > >thoughts? > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Redirect Message > > > > Based on discussion, and based on my earlier message that specific > protocol > > messages may have different top level TLVs, here is a description of the > > contents of a redirect message. > > > > A redirect message will contain a redirect TLV. > > A redirect TLV consists of three fixed fields, and meta-data TLV, and the > > packet. > > The fixed fields are > > o the LFB Class ID of the redirect source or redirect sink LFB on the FE > > associated with this packet > > o the LFB Instance ID of the redirect source or redirect sink LFB on > the FE > > associated with this packet > > o an index within that LFB to identify configured properties of the packet. > > > > The meta-data TLV contains dynamic information needed by the FE or CE to > > process the packet. This will need to be spelled out in more detail. It > > may need to use path encoding. > > > > Following this will be the packet. > > > > Yours, > > Joel From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 06 22:39:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqMI5-00006G-IS for forces-archive@megatron.ietf.org; Wed, 06 Jul 2005 22:39: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 WAA26973 for ; Wed, 6 Jul 2005 22: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 1DqMiw-0007ff-V6 for forces-archive@IETF.ORG; Wed, 06 Jul 2005 23:07: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 <15.0109D086@cherry.ease.lsoft.com>; Wed, 6 Jul 2005 22:38:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78179121 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 6 Jul 2005 22:38:47 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Jul 2005 22:38:47 -0400 Received: from [71.240.224.169] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11292848 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 06 Jul 2005 22:38:44 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050630104547.02f12a50@localhost> <002e01c58239$6f9500f0$1f12fea9@wwm1> <6.2.1.2.0.20050706160833.02dd3310@localhost> <003f01c5829b$656d2280$1152010a@Necom.hzic.edu.cn> 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.20050706223256.02dcd900@localhost> Date: Wed, 6 Jul 2005 22:38:27 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003f01c5829b$656d2280$1152010a@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 There is a whole section on meta-data in the model document. I would expect most meta-data fields to be 32 bits. The CE can choose to use a meta-data classifier and multiple meta-data fields in order to steer the packet to the right LFB. And the CE will know what meta-data field the LFB will use for selecting among its ports. This relates to a larger question for the list... We NEED an LFB library. Please! To do this, we need folks to actually write definitions of LFBs. (I think we have an editor who is likely to be willing to pull things together. At least I hope so.) There are a lot of LFBs that need writing. If this WG doesn't start producing them, it won't happen. To get back to your question Weiming, given a set of LFB definitions and the meta-data they use, I can better specify what the CE will send / receive. But in an abstract sense, since it will be information flowing between the redirect LFB and the eventual interface LFB, the way the model prescribes to carry that information is as meta-data. This is the same meta-data that will need, for example, to come out of longest-prefix-match and next-hop resolution LFBs. After all, they need to be able to direct packets to be shipped out specific interfaces, with specific headers, etc. Yours, Joel At 10:27 PM 7/6/2005, Wang,Weiming wrote: >A very simple question then, how many bits we then can assign to the >meta-data like the port number ? > >thanks, >weiming > > >----- Original Message ----- >From: "Joel M. Halpern" >To: "Weiming Wang" ; >Sent: Thursday, July 07, 2005 4:09 AM >Subject: Re: [issue32] Packet Redirect > > > > After some discussion, the operational data may be simpler than I had been > > thinking. > > We can simply attach (in some reasonable TLV format) all the meta-data. > > So packets from the CE come with meta-data, and the CE gets all the > > meta-data from the FE associated with a packet. > > That ensures that all the necessary information is available, without > > making the redirect LFBs complex. > > > > Yours, > > Joel > > > > At 10:44 AM 7/6/2005, Weiming Wang wrote: > > >Joel, > > > > > >I tend to agree with your idea below except the index. Could you give > > >more details on its necessity? Thanks. > > >As a result, the agreeable format to me seems like: > > > > > >Redirect TLV, whith contains > > > LFB class ID > > > LFB instance ID > > > operation TLV (REPORT), which contains Path-Data > > > Packet TLV > > > > > >We further define that that Path-Data should supply enough information > for > > >the followed packet. At least it should include information about the > port > > >number the redirect packet is input(sink LFB) or is output (source LFB), > > >and the redirect packet type. How this is defined is left to model where > > >redirect LFBs and the attributes are defined. > > > > > >We need to solve this a little sooner. > > > > > >thoughts? > > > > > >Thanks, > > >Weiming > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >Subject: Redirect Message > > > > > > > > > > Based on discussion, and based on my earlier message that specific > > > protocol > > > > messages may have different top level TLVs, here is a description > of the > > > > contents of a redirect message. > > > > > > > > A redirect message will contain a redirect TLV. > > > > A redirect TLV consists of three fixed fields, and meta-data TLV, > and the > > > > packet. > > > > The fixed fields are > > > > o the LFB Class ID of the redirect source or redirect sink LFB on > the FE > > > > associated with this packet > > > > o the LFB Instance ID of the redirect source or redirect sink LFB on > > > the FE > > > > associated with this packet > > > > o an index within that LFB to identify configured properties of the > packet. > > > > > > > > The meta-data TLV contains dynamic information needed by the FE or > CE to > > > > process the packet. This will need to be spelled out in more > detail. It > > > > may need to use path encoding. > > > > > > > > Following this will be the packet. > > > > > > > > Yours, > > > > Joel > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 06 23:17:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqMtL-000898-Gt for forces-archive@megatron.ietf.org; Wed, 06 Jul 2005 23:17: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 XAA29032 for ; Wed, 6 Jul 2005 23:17:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqNKS-0006JC-8Y for forces-archive@IETF.ORG; Wed, 06 Jul 2005 23:45: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 <9.0109D172@cherry.ease.lsoft.com>; Wed, 6 Jul 2005 23:17:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78181625 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 6 Jul 2005 23:17:33 -0400 Received: from 205.150.200.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Jul 2005 23:07:33 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3782F16D00 for ; Wed, 6 Jul 2005 23:07:13 -0400 (EDT) Approved-By: aland@NITROS9.ORG Message-ID: <20050707030713.3782F16D00@mail.nitros9.org> Date: Wed, 6 Jul 2005 23:07:13 -0400 Reply-To: Alan DeKok Sender: Forwarding and Control Element Separation From: Alan DeKok Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Wed, 06 Jul 2005 22:38:27 EDT." <6.2.1.2.0.20050706223256.02dcd900@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c "Joel M. Halpern" wrote: > There is a whole section on meta-data in the model document. > I would expect most meta-data fields to be 32 bits. > The CE can choose to use a meta-data classifier and multiple meta-data > fields in order to steer the packet to the right LFB. And the CE will know > what meta-data field the LFB will use for selecting among its ports. Sounds good to me. > There are a lot of LFBs that need writing. > If this WG doesn't start producing them, it won't happen. This WG isn't alone in that respect. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 06 23:35:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNB1-0007sz-4e for forces-archive@megatron.ietf.org; Wed, 06 Jul 2005 23:35: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 XAA29910 for ; Wed, 6 Jul 2005 23:35:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqNc1-0001l7-Gt for forces-archive@IETF.ORG; Thu, 07 Jul 2005 00:03: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 <19.0109D129@cherry.ease.lsoft.com>; Wed, 6 Jul 2005 23:35:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78182765 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 6 Jul 2005 23:35:42 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Jul 2005 23:35:42 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005070620385063:67682 ; Wed, 6 Jul 2005 20:38:50 -0700 References: <6.2.1.2.0.20050630104547.02f12a50@localhost> <002e01c58239$6f9500f0$1f12fea9@wwm1> <6.2.1.2.0.20050706160833.02dd3310@localhost> <003f01c5829b$656d2280$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050706223256.02dcd900@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/06/2005 08:38:50 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/06/2005 08:38:52 PM, Serialize complete at 07/06/2005 08:38:52 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1120707338.13774.69.camel@localhost.localdomain> Date: Wed, 6 Jul 2005 23:35:38 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050706223256.02dcd900@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit On Wed, 2005-06-07 at 22:38 -0400, Joel M. Halpern wrote: > > This relates to a larger question for the list... > We NEED an LFB library. > Please! > To do this, we need folks to actually write definitions of LFBs. > (I think we have an editor who is likely to be willing to pull things > together. At least I hope so.) > There are a lot of LFBs that need writing. > If this WG doesn't start producing them, it won't happen. I was going to ask for a slot to present a couple of the LFBs (Port and IPv4) that Steve B. and I were supposed to be working on. I figured this is the only way to get people to pay attention. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 07 02:06:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPWw-0003CU-JF for forces-archive@megatron.ietf.org; Thu, 07 Jul 2005 02:06: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 CAA15542 for ; Thu, 7 Jul 2005 02:06:37 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqPy0-0003Y1-Le for forces-archive@IETF.ORG; Thu, 07 Jul 2005 02:34: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 <23.0109D492@cherry.ease.lsoft.com>; Thu, 7 Jul 2005 2:06:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78189989 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 7 Jul 2005 02:06:31 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Jul 2005 02:06:31 -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 j6766UGR015709; Thu, 7 Jul 2005 06:06:30 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 j6766UVd003360; Thu, 7 Jul 2005 06:06:30 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 M2005070623063006616 ; Wed, 06 Jul 2005 23:06:30 -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); Wed, 6 Jul 2005 23:05:49 -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] LFB library draft thread-index: AcWCnQR1WMRhuv36TVGtNsUrMPJASwAHDQxw X-OriginalArrivalTime: 07 Jul 2005 06:05:49.0492 (UTC) FILETIME=[EC4C6F40:01C582B9] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05E6D2D5@orsmsx408> Date: Wed, 6 Jul 2005 23:05:46 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: LFB library draft Comments: To: "Joel M. Halpern" Comments: cc: "Yang, Lily L" , "Deleganes, Ellen M" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Joel, If I remember correctly the original FE Model draft that Lily was editing did have a bunch of LFB definitions, an initial LFB library of sorts. The plan was to move this content to a different draft and add more details to it. Do you have the starting draft with the content from the original FE Model draft? That would be a good starting point and then the WG/authors can start refining the content...but a starting draft would be helpful. Let me know if I am off track here, Thanks Hormuzd -----Original Message----- This relates to a larger question for the list... We NEED an LFB library. Please! To do this, we need folks to actually write definitions of LFBs. (I think we have an editor who is likely to be willing to pull things=20 together. At least I hope so.) There are a lot of LFBs that need writing. If this WG doesn't start producing them, it won't happen. Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 07 08:03:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqV6f-0007ke-CU for forces-archive@megatron.ietf.org; Thu, 07 Jul 2005 08:03: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 IAA28997 for ; Thu, 7 Jul 2005 08:03:51 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqVXp-00056g-GW for forces-archive@IETF.ORG; Thu, 07 Jul 2005 08:31:58 -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.0109D537@cherry.ease.lsoft.com>; Thu, 7 Jul 2005 8:03:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78240002 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 7 Jul 2005 08:03:43 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Jul 2005 08:03:42 -0400 Received: from [71.240.224.169] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11300975 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 07 Jul 2005 08:03:35 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E05E6D2D5@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.20050707080151.02e03298@localhost> Date: Thu, 7 Jul 2005 08:03:29 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB library draft To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05E6D2D5@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb There were descriptions for several LFBs. None of them were definitions. Some of them were wrong. Some were probably the wrong thing. Some were right. I would recommend that rather than going back and digging those out, we start a process to get a good set of definitions. We will need to make a list of ones we want. I am sure that will rapidly be larger than we can deliver. Yours, Joel At 02:05 AM 7/7/2005, Khosravi, Hormuzd M wrote: >Joel, > >If I remember correctly the original FE Model draft that Lily was >editing did have a bunch of LFB definitions, an initial LFB library of >sorts. The plan was to move this content to a different draft and add >more details to it. > >Do you have the starting draft with the content from the original FE >Model draft? That would be a good starting point and then the WG/authors >can start refining the content...but a starting draft would be helpful. > >Let me know if I am off track here, > >Thanks >Hormuzd > >-----Original Message----- >This relates to a larger question for the list... >We NEED an LFB library. >Please! >To do this, we need folks to actually write definitions of LFBs. >(I think we have an editor who is likely to be willing to pull things >together. At least I hope so.) >There are a lot of LFBs that need writing. >If this WG doesn't start producing them, it won't happen. > > >Yours, >Joel From owner-forces@PEACH.EASE.LSOFT.COM Fri Jul 08 20:12:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2x0-0003mF-Qh for forces-archive@megatron.ietf.org; Fri, 08 Jul 2005 20:12: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 UAA19139 for ; Fri, 8 Jul 2005 20:12:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr3OQ-0003qe-TE for forces-archive@IETF.ORG; Fri, 08 Jul 2005 20:40: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 <18.0109F6FD@cherry.ease.lsoft.com>; Fri, 8 Jul 2005 20:12:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78420799 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 8 Jul 2005 20:12:03 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 8 Jul 2005 20:12:02 -0400 Received: from [162.84.111.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11327462 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 08 Jul 2005 20:12:02 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_358645==_" Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050708201027.02cd7b48@localhost> Date: Fri, 8 Jul 2005 20:11:55 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Fwd: Re: DataRaw? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af --=====================_358645==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Jamal and I have been batting back and forth ideas for how the contents of the dataraw TLV should be constructed, so as to cope with complex circumstances lake arrays with holes and structures with optional elements. The attachment is our current best suggestion. Please take a look and let us know. Thanks, Joel --=====================_358645==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="packed-dataraw1.txt" A Data TLV has a 16 bit Type = DATARAW or PACKED-DATARAW, and a 16bit Length followed by the data value/contents. In the case of the DATARAW (note: not packed) each DATA element in the Value part will be further encapsulated in an ILV. An ILV is like a TLV except it has a 32 bit Index (or element ID) and a 32 bit Length field. The rationale behind ILVs is to make it easier to encapsulate optionaly appearing Data elements (which are expected to be the way of life in Forces). Rules: 1) Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD be padded to achieve the alignement. 2) Packed-Dataraw TLV may be used at a particular path only if every element at that path level is present. This requirement holds whether the fields are fixed or variable length, mandatory or optional. 3) An assumed optimization is that the encoder(sender) and the decoder(receiver) both understand the definition of the data elements being shipped. a) If a Packed-Dataraw TLV is used, the encoder MUST layout data for each element ordered by the order in which the data was defined. This ensures the decoder is guaranteed to retrieve the data. b) In the case of a non-packed Dataraw we dont need to order since the I in the ILV uniquely identifies the element. 4) Inside a Packed-Dataraw TLV a) the values for atomic, fixed-length fields are given without any TLV or ILV encapsulation. b) the values for atomic, variable-length fields are given inside Dataraw TLVs. 5) Inside a Dataraw TLV (not packed) -> the values for atomic fields may be given with ILVs (32-bit index, 32-bit length) 6) Any of the Dataraws can contain a ILV but an ILV cannot contain a DATARAW. This is because it is hard to disambiguate ILV since an I is 32 bit and a T is 16 bit. 7) A DATARAW can also contain a DATARAW for variable sized elements. The decoding disambiguation is assumed from rule #3 above. We give a few examples below but dont show the padding. ========== Example 1: ========== Structure with three fixed-length, mandatory fields. struct S { uint16 a uint16 b uint16 c } (a) Describing all fields using DATARAW with ILVs (index/length values) Path to an instance of S ... Dataraw TLV ILV: ElementID(a), length(a), value(a) ILV: ElementID(b), length(b), value(b) ILV: ElementID(c), length(c), value(c) (b) Describing a subset of fields Path-Data TLV to an instance of S ... Dataraw TLV ILV ElementID(a), length(a), value(a) ILV: ElementID(c), length(c), value(c) Note: Even though we have non-optional elements in structure S, since we can uniquely identify elements, we can selectively send element of structure S (eg in the case of an update from CE to FE). (c) Describing all fields using a Packed-Dataraw TLV Path to an instance of S ... Packed-Dataraw TLV value(a) value(b) value(c) ========== Example 2: ========== Structure with three fixed-length fields, one mandatory, two optional. struct T { uint16 a uint16 b (optional) uint16 c (optional) } This example is identical to Example 1, as illustrated below. (a) Describing all fields using ILVs (index/length values) Path to an instance of T ... Dataraw TLV ILV: ElementID(a), length(a) value(a) ILV: ElementID(b), length(b) value(b) ILV: ElementID(c), length(c) value(c) (b) Describing a subset of fields using ILVs (index/length values) Path to an instance of T ... Dataraw TLV ILV (ElementID a, length, value of a) ILV (ElementID c, length, value of c) (c) Describing all fields using a Packed-Dataraw TLV Path to an instance of T ... Packed-Dataraw TLV (value of a) (value of b) (value of c) Note: Packed-Dataraw TLV _cannot_ be used unless all fields are being described. ========== Example 3: ========== Structure with a mix of fixed-length and variable-length fields, some mandatory, some optional (would be a good idea to show unions maybe). struct U { uint16 a string b (optional) uint16 c (optional) } (a) Describing all fields using ILVs Path to an instance of U ... Dataraw TLV ILV (ElementID a, length, value of a) ILV (ElementID b, length, value of b) ILV (ElementID c, length, value of c) (b) Describing a subset of fields using ILVs Path to an instance of U ... Dataraw TLV ILV (ElementID a, length, value of a) ILV (ElementID c, length, value of c) (c) Describing all fields using a Packed-Dataraw TLV Path to an instance of U ... Packed-Dataraw TLV (value of a) Packed-Dataraw TLV (value of b) (value of c) Note: The variable-length field requires the addition of a TLV withing the packed data. ========== Example 4: ========== Structure containing an array of another structure type. struct V { uint32 x uint32 y struct U z[] } (a): Describing all fields of V using ILVs, with two instances of z[], also described with ILVs, assuming only the 10th and 15th subscript of z[]. path to instance of V ... Dataraw TLV ILV (ElementID x, length, value of x) ILV (ElementID y, length, value of y) ILV (ElementID z) ILV (index = 10) ILV (ElementID a, length, value of a) ILV (ElementID b, length, value of b) ILV (ElementID c, length, value of c) ILV (index = 15 ) ILV (ElementID a, length, value of a) ILV (ElementID c, length, value of c) Note the holes in the elements of z (10 followed by 15). Also note the gap in index 15 with only elements a and c appearing but not b. --=====================_358645==_-- From JenniferGrayson@hangable.com Sat Jul 09 17:12:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrMcX-0001sC-Ey for forces-archive@megatron.ietf.org; Sat, 09 Jul 2005 17:12: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 RAA25277 for ; Sat, 9 Jul 2005 17:12:18 -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 1DrN4C-00037g-Et for forces-archive@ietf.org; Sat, 09 Jul 2005 17:40:57 -0400 Received: from 178.81.100-84.rev.gaoland.net ([84.100.81.178]) by mx2.foretec.com with smtp (Exim 4.24) id 1DrMcQ-0005St-UO for forces-archive@ietf.org; Sat, 09 Jul 2005 17:12:15 -0400 Received: from 6nVU@localhost by 0FH.int (8.11.6/8.11.6); Sun, 10 Jul 2005 02:24:25 +0400 Message-ID: From: "Cathy Connelly" Reply-To: "Cathy Connelly" To: lupe.goff@ietf.org, forces-archive@ietf.org Subject: Re: OEM Microsoft, Macromedia, & Windows on Sale Now Date: Sun, 10 Jul 2005 00:28:25 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JenniferGrayson@hangable.com Content-Type: multipart/mixed; boundary="--fvls1QVvrjRu7mP1wHMM" X-Spam-Score: 0.2 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 HPyf ----fvls1QVvrjRu7mP1wHMM Content-Type: text/html; Content-Transfer-Encoding: quoted-printable A
Opt-in Email Special Offer &n= bsp;   unsubscribe me=
= = List Price:
SEARCH

TOP 10 NEW TITLES

= =

 = ON SALE NOW!

 1 Office Pro 2003
 2 W= indows XP Pro
 3 Adob= e Creative Suite Premium
 4<= a href=3Dhttp://vitriolware.com/?B> Norton Antivirus 2005
 = 5 Flash MX 2004
 6 Corel Draw 12
 7= Adobe Acrobat 7.0
 8 Windows 2003 Server
 = ;9 Alias Maya 6 Wavefrt
&= nbsp;10 Adobe Premiere
&= nbsp; See more by this manufacturer
   Microsoft
   Apple Softwar= e
  Customers also b= ought
   these other items...



Microsoft Office Professional Edition *2003*
Microsoft
Choose:
 
$899.00
Price:$69.99
You Save= :$830.01 (92%)



Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
Media: CD-ROM / Download

System re= quirements  |  Accessori= es  |  Other Versions

Features:

  • Analyze and manage business inform= ation using Access databases
  • Exchange data with other systems using enhanced XML technology
  • Control information sharing rules with= enhanced IRM technology
  • Eas= y-to-use wizards to create e-mail newsletters and printed marketing materi= als
  • More than 20 preformatte= d business reports
Sales Ra= nk: #1
Shipping: International/US or via insta= nt download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 re= views. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
<= span class=3Dsmall>Microsoft
Choose:
 = ;

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



Availability: Available for = INSTANT download!
Coupon Code: ISe229
Media: CD-ROM = / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for = businesses of all sizes
  • Mana= ge digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and f= olders
  • Built-in voice, video= , and instant messaging support
  • Integration with Windows servers and management solutions

    • Sales Rank: #2
    Shippin= g: International/US or via instant download
    Date Coupon Expires= : June 30th, 2005
    Average Customer Re= view: 3D"5 Based on 868 reviews. Write a review.

    Adobe Photoshop CS2 V 9.0
    = Adobe
    =
    Choose:
     

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


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements = ; |  Accessories  | = ; Other Versions

    <= font size=3D1>Features:

    • Customized workspace; save personalized workspace= and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production tasks wi= th built-in or customized scripts
    • Improved file management, new design possibilities, and a more intui= tive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-square pixel= s
    • Create or modify photos us= ing painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 498 reviews. Write = a review.

----fvls1QVvrjRu7mP1wHMM-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Jul 09 20:02:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrPH5-0003uF-33 for forces-archive@megatron.ietf.org; Sat, 09 Jul 2005 20:02: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 UAA03803 for ; Sat, 9 Jul 2005 20:02:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrPih-00006C-Iq for forces-archive@IETF.ORG; Sat, 09 Jul 2005 20:31: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 <13.010A0473@cherry.ease.lsoft.com>; Sat, 9 Jul 2005 20:02:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78514914 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 9 Jul 2005 20:02:15 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 9 Jul 2005 20:02:15 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j6A02EbA031916; Sun, 10 Jul 2005 00:02:14 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 j6A02D5B016912; Sun, 10 Jul 2005 00:02:14 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 M2005070917021316138 ; Sat, 09 Jul 2005 17:02:13 -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); Sat, 9 Jul 2005 17:02:12 -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] LFB library draft-reuse of NPF FAPI library thread-index: AcWC7BeTNpRXOgb5Qji7FzyiJNaGlAB8p3Tw X-OriginalArrivalTime: 10 Jul 2005 00:02:12.0958 (UTC) FILETIME=[9FDEC7E0:01C584E2] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05EE050B@orsmsx408> Date: Sat, 9 Jul 2005 17:02:07 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: LFB library draft-reuse of NPF FAPI library Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Hi Joel, One suggestion...several members of this working group, (Alistair Munroe, John Renwick, others) including FE Model team members (Steve, Zsolt, Ellen, Lily, Alan, others) have contributed over last several years to define a bunch of Functional APIs (FAPI) library in the NPF (Network Processing Forum). A lot of those are now standardized and available as implementation agreements (IAs) to the public. It would be wise to reuse the LFB definitions from these FAPIs, atleast for the ones that are available. This would also chime well with our WG charter to coordinate with other related standards groups. Ellen is currently active in the NPF and can provide you with any more info in this regard. The FAPIs are available at the following website... http://www.npforum.org/techinfo/approved-chronological.shtml The FAPIs currently available as IAs... IPv4 Prefix LFB and Functional API (February 2005) Generic Classifier LFB and Functional API (December 2004) Topology Manager Functional API (December 2004) Messaging LFB (September 2004) ATM Configuration Manager Functional API (March 2005) ATM Header Generator LFB and Functional API (March 2005) ATM Header Classifier LFB and Functional API (March 2005) Next-Hop LFB and Functional API - should be available anytime now (approved) Rate Meter LFB and Functional API - should be available in sometime Let me know if you have any questions in this regard, Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, July 07, 2005 5:03 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] LFB library draft There were descriptions for several LFBs. None of them were=20 definitions. Some of them were wrong. Some were probably the wrong=20 thing. Some were right. I would recommend that rather than going back and digging those out, we=20 start a process to get a good set of definitions. We will need to make a list of ones we want. I am sure that will rapidly be larger than we can deliver. Yours, Joel At 02:05 AM 7/7/2005, Khosravi, Hormuzd M wrote: >Joel, > >If I remember correctly the original FE Model draft that Lily was >editing did have a bunch of LFB definitions, an initial LFB library of >sorts. The plan was to move this content to a different draft and add >more details to it. > >Do you have the starting draft with the content from the original FE >Model draft? That would be a good starting point and then the WG/authors >can start refining the content...but a starting draft would be helpful. > >Let me know if I am off track here, > >Thanks >Hormuzd > >-----Original Message----- >This relates to a larger question for the list... >We NEED an LFB library. >Please! >To do this, we need folks to actually write definitions of LFBs. >(I think we have an editor who is likely to be willing to pull things >together. At least I hope so.) >There are a lot of LFBs that need writing. >If this WG doesn't start producing them, it won't happen. > > >Yours, >Joel From owner-forces@PEACH.EASE.LSOFT.COM Sat Jul 09 22:36:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrRgT-0004tv-J1 for forces-archive@megatron.ietf.org; Sat, 09 Jul 2005 22:36: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 WAA12222 for ; Sat, 9 Jul 2005 22:36:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrS81-0005gY-OY for forces-archive@IETF.ORG; Sat, 09 Jul 2005 23:05: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 <10.010A06D7@cherry.ease.lsoft.com>; Sat, 9 Jul 2005 22:36:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78520795 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 9 Jul 2005 22:36:15 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 9 Jul 2005 22:36:15 -0400 Received: from [162.84.111.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11343846 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 09 Jul 2005 22:36:14 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E05EE050B@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.20050709223407.02f36280@localhost> Date: Sat, 9 Jul 2005 22:36:07 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB library draft-reuse of NPF FAPI library To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05EE050B@orsmsx408> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 These FAPI definitions sound like good starting points for defining the LFBs. I am not sure we will have separate configuration manager LFBs, given the way things are working. But we can see once we have some proposed definitions. Yours, Joel M. Halpern At 08:02 PM 7/9/2005, Khosravi, Hormuzd M wrote: >Hi Joel, > >One suggestion...several members of this working group, (Alistair >Munroe, John Renwick, others) including FE Model team members (Steve, >Zsolt, Ellen, Lily, Alan, others) have contributed over last several >years to define a bunch of Functional APIs (FAPI) library in the NPF >(Network Processing Forum). A lot of those are now standardized and >available as implementation agreements (IAs) to the public. > >It would be wise to reuse the LFB definitions from these FAPIs, atleast >for the ones that are available. This would also chime well with our WG >charter to coordinate with other related standards groups. Ellen is >currently active in the NPF and can provide you with any more info in >this regard. > >The FAPIs are available at the following website... >http://www.npforum.org/techinfo/approved-chronological.shtml > >The FAPIs currently available as IAs... > >IPv4 Prefix LFB and Functional API (February 2005) >Generic Classifier LFB and Functional API (December 2004) >Topology Manager Functional API (December 2004) >Messaging LFB (September 2004) >ATM Configuration Manager Functional API (March 2005) >ATM Header Generator LFB and Functional API (March 2005) >ATM Header Classifier LFB and Functional API (March 2005) > >Next-Hop LFB and Functional API - should be available anytime now >(approved) >Rate Meter LFB and Functional API - should be available in sometime > >Let me know if you have any questions in this regard, > >Thanks >Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Sat Jul 09 23:55:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrSuF-0002t1-PC for forces-archive@megatron.ietf.org; Sat, 09 Jul 2005 23:55:03 -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 XAA14777 for ; Sat, 9 Jul 2005 23:55:00 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrTLs-0008Ih-FT for forces-archive@IETF.ORG; Sun, 10 Jul 2005 00:23: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 <20.010A080A@cherry.ease.lsoft.com>; Sat, 9 Jul 2005 23:54:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78525342 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 9 Jul 2005 23:54:53 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 9 Jul 2005 23:54:53 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005070920580142:71355 ; Sat, 9 Jul 2005 20:58:01 -0700 References: <468F3FDA28AA87429AD807992E22D07E05EE050B@orsmsx408> <6.2.1.2.0.20050709223407.02f36280@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/09/2005 08:58:01 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/09/2005 08:58:03 PM, Serialize complete at 07/09/2005 08:58:03 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1120967692.7498.18.camel@localhost.localdomain> Date: Sat, 9 Jul 2005 23:54:51 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB library draft-reuse of NPF FAPI library Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050709223407.02f36280@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit I am glad you used the term "starting" point as opposed to "reusing", Joel. Lets not shoot ourselves in the big toe just so the NPF APIs can look as if they are being endorsed by the IETF. Didnt we go over this discussion several times already over the last year or so? cheers, jamal On Sat, 2005-09-07 at 22:36 -0400, Joel M. Halpern wrote: > These FAPI definitions sound like good starting points for defining the LFBs. > I am not sure we will have separate configuration manager LFBs, given the > way things are working. But we can see once we have some proposed definitions. > Yours, > Joel M. Halpern > > At 08:02 PM 7/9/2005, Khosravi, Hormuzd M wrote: > >Hi Joel, > > > >One suggestion...several members of this working group, (Alistair > >Munroe, John Renwick, others) including FE Model team members (Steve, > >Zsolt, Ellen, Lily, Alan, others) have contributed over last several > >years to define a bunch of Functional APIs (FAPI) library in the NPF > >(Network Processing Forum). A lot of those are now standardized and > >available as implementation agreements (IAs) to the public. > > > >It would be wise to reuse the LFB definitions from these FAPIs, atleast > >for the ones that are available. This would also chime well with our WG > >charter to coordinate with other related standards groups. Ellen is > >currently active in the NPF and can provide you with any more info in > >this regard. > > > >The FAPIs are available at the following website... > >http://www.npforum.org/techinfo/approved-chronological.shtml > > > >The FAPIs currently available as IAs... > > > >IPv4 Prefix LFB and Functional API (February 2005) > >Generic Classifier LFB and Functional API (December 2004) > >Topology Manager Functional API (December 2004) > >Messaging LFB (September 2004) > >ATM Configuration Manager Functional API (March 2005) > >ATM Header Generator LFB and Functional API (March 2005) > >ATM Header Classifier LFB and Functional API (March 2005) > > > >Next-Hop LFB and Functional API - should be available anytime now > >(approved) > >Rate Meter LFB and Functional API - should be available in sometime > > > >Let me know if you have any questions in this regard, > > > >Thanks > >Hormuzd From DewayneValentin@bankfull.net Mon Jul 11 06:19:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrvNg-0003b5-WF for forces-archive@megatron.ietf.org; Mon, 11 Jul 2005 06:19: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 GAA27515 for ; Mon, 11 Jul 2005 06:19:18 -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 1Drvpf-0007pB-Dg for forces-archive@ietf.org; Mon, 11 Jul 2005 06:48:16 -0400 Received: from [66.168.177.213] (helo=66-168-177-213.dhcp.clmb.ga.charter.com) by mx2.foretec.com with smtp (Exim 4.24) id 1DrvNV-00020K-Np for forces-archive@ietf.org; Mon, 11 Jul 2005 06:19:10 -0400 Received: from Zk0@localhost by U8P.int (8.11.6/8.11.6); Mon, 11 Jul 2005 04:06:13 -0700 Message-ID: From: "Kelvin Haas" Reply-To: "Kelvin Haas" To: lupe.goff@ietf.org Subject: Re: OEM AutoCAD, Macromedia, & XP on Sale Now Date: Mon, 11 Jul 2005 07:08:13 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: DewayneValentin@bankfull.net Content-Type: multipart/mixed; boundary="--chUhNRkxoCGcurtmr6Ha" X-Spam-Score: 0.3 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Vs7 ----chUhNRkxoCGcurtmr6Ha Content-Type: text/html; Content-Transfer-Encoding: quoted-printable B
Opt-in Email Special Offer &n= bsp;   unsubscribe me=
= = List Price:
SEARCH

TOP 10 NEW TITLES

= =

 = ON SALE NOW!

 1 Office Pro 2003
 2 W= indows XP Pro
 3 Adob= e Creative Suite Premium
 4<= a href=3Dhttp://playoffsoft.com/?a> Norton Antivirus 2005
 = 5 Flash MX 2004
 6 Corel Draw 12
 7= Adobe Acrobat 7.0
 8 Windows 2003 Server
 = ;9 Alias Maya 6 Wavefrt
&= nbsp;10 Adobe Premiere
&= nbsp; See more by this manufacturer
   Microsoft
   Apple Softwar= e
  Customers also b= ought
   these other items...



Microsoft Office Professional Edition *2003*
Microsoft
Choose:
 
$899.00
Price:$69.99
You Save= :$830.01 (92%)



Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
Media: CD-ROM / Download

System re= quirements  |  Accessori= es  |  Other Versions

Features:

  • Analyze and manage business inform= ation using Access databases
  • Exchange data with other systems using enhanced XML technology
  • Control information sharing rules with= enhanced IRM technology
  • Eas= y-to-use wizards to create e-mail newsletters and printed marketing materi= als
  • More than 20 preformatte= d business reports
Sales Ra= nk: #1
Shipping: International/US or via insta= nt download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 re= views. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
<= span class=3Dsmall>Microsoft
Choose:
 = ;

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



Availability: Available for = INSTANT download!
Coupon Code: ISe229
Media: CD-ROM = / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for = businesses of all sizes
  • Mana= ge digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and f= olders
  • Built-in voice, video= , and instant messaging support
  • Integration with Windows servers and management solutions

    • Sales Rank: #2
    Shippin= g: International/US or via instant download
    Date Coupon Expires= : June 30th, 2005
    Average Customer Re= view: 3D"5 Based on 868 reviews. Write a review.

    Adobe Photoshop CS2 V 9.0
    = Adobe
    =
    Choose:
     

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


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements = ; |  Accessories  | = ; Other Versions

    <= font size=3D1>Features:

    • Customized workspace; save personalized workspace= and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production tasks wi= th built-in or customized scripts
    • Improved file management, new design possibilities, and a more intui= tive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-square pixel= s
    • Create or modify photos us= ing painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 498 reviews. Write = a review.

----chUhNRkxoCGcurtmr6Ha-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jul 12 04: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 1DsGZg-0006vK-Oy for forces-archive@megatron.ietf.org; Tue, 12 Jul 2005 04: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 EAA02584 for ; Tue, 12 Jul 2005 04:57:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsH1p-0002PT-BT for forces-archive@IETF.ORG; Tue, 12 Jul 2005 05: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 <7.010A2B60@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 4:56:51 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78774487 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 04:56:50 -0400 Received: from 195.212.29.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 04:56:49 -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 j6C8umTh147956 for ; Tue, 12 Jul 2005 08:56:48 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/VER6.6) with ESMTP id j6C8umvo154286 for ; Tue, 12 Jul 2005 10:56:48 +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 j6C8um3q005318 for ; Tue, 12 Jul 2005 10:56:48 +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 j6C8ulAH005315; Tue, 12 Jul 2005 10:56:47 +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 KAA66816; Tue, 12 Jul 2005 10:56:47 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6.2.1.2.0.20050708201027.02cd7b48@localhost> 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 j6C8umTh147956 Approved-By: Robert Haas Message-ID: <42D385CB.6080901@zurich.ibm.com> Date: Tue, 12 Jul 2005 10:56:43 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Fwd: Re: DataRaw? Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050708201027.02cd7b48@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Content-Transfer-Encoding: quoted-printable Joel, Jamal, The syntax looks ok to me. But I am not sure though how optional=20 elements are the way of life in ForCES as some aspects are still unclear=20 to me, for instance: Do we assume that default values are returned for optional elements=20 unless they are explicitely set, or is there a reserved value ? Does the default value appear in the LFB definition for each optional=20 element ? What do we mean by "optional LFB element" exactly ? Does it mean that from the LFB definition perspective, all optional=20 elements MUST be supported by the FE and they MAY be used by the CE ? Or can we have optional elements of an LFB that a particular FE=20 implementation does not support ? Regards, -Robert Joel M. Halpern wrote: > Jamal and I have been batting back and forth ideas for how the=20 > contents of the dataraw TLV should be constructed, so as to cope with=20 > complex circumstances lake arrays with holes and structures with=20 > optional elements. > The attachment is our current best suggestion. > > Please take a look and let us know. > Thanks, > Joel > >------------------------------------------------------------------------ > > >A Data TLV has a 16 bit Type =3D DATARAW or PACKED-DATARAW, and a 16bit = Length >followed by the data value/contents. >In the case of the DATARAW (note: not packed) each DATA element in the=20 >Value part will be further encapsulated in an ILV. An ILV is like a=20 >TLV except it has a 32 bit Index (or element ID) and a 32 bit Length fie= ld. >The rationale behind ILVs is to make it easier to encapsulate optionaly >appearing Data elements (which are expected to be the way of life in For= ces). > >Rules: > >1) Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD be pad= ded >to achieve the alignement. > >2) Packed-Dataraw TLV may be used at a particular path only if=20 >every element at that path level is present. This requirement=20 >holds whether the fields are fixed or variable length, mandatory or opti= onal. > >3) An assumed optimization is that the encoder(sender) and the decoder(r= eceiver) >both understand the definition of the data elements being shipped. > >a) If a Packed-Dataraw TLV is used, the encoder MUST layout data for eac= h=20 >element ordered by the order in which the data was defined. This ensures >the decoder is guaranteed to retrieve the data. > >b) In the case of a non-packed Dataraw we dont need to order since the >I in the ILV uniquely identifies the element. > >4) Inside a Packed-Dataraw TLV > a) the values for atomic, fixed-length fields are given without any = TLV or > ILV encapsulation. > b) the values for atomic, variable-length fields are given inside=20 > Dataraw TLVs. > >5) Inside a Dataraw TLV (not packed) > -> the values for atomic fields may be given with ILVs (32-bit index= ,=20 > 32-bit length) > >6) Any of the Dataraws can contain a ILV but an ILV cannot contain a DA= TARAW. >This is because it is hard to disambiguate ILV since an I is 32 >bit and a T is 16 bit. > >7) A DATARAW can also contain a DATARAW for variable sized elements.=20 >The decoding disambiguation is assumed from rule #3 above. > > >We give a few examples below but dont show the padding. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Example 1: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Structure with three fixed-length, mandatory fields. > > >struct S { > uint16 a > uint16 b > uint16 c >} > > >(a) Describing all fields using DATARAW >with ILVs (index/length values) > >Path to an instance of S ... > Dataraw TLV > ILV: ElementID(a), length(a),=20 > value(a) > ILV: ElementID(b), length(b), > value(b) > ILV: ElementID(c), length(c), > value(c) > >(b) Describing a subset of fields=20 > >Path-Data TLV to an instance of S ... > Dataraw TLV > ILV ElementID(a), length(a),=20 > value(a) > ILV: ElementID(c), length(c), > value(c) > >Note: Even though we have non-optional elements in structure S, since >we can uniquely identify elements, we can selectively send element of >structure S (eg in the case of an update from CE to FE). > >(c) Describing all fields using a Packed-Dataraw TLV > >Path to an instance of S ... > Packed-Dataraw TLV > value(a) > value(b) > value(c) > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Example 2: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Structure with three fixed-length fields, one mandatory, two optional. > > >struct T { > uint16 a > uint16 b (optional) > uint16 c (optional) >} > >This example is identical to Example 1, as illustrated below. > > >(a) Describing all fields using ILVs (index/length values) > >Path to an instance of T ... > Dataraw TLV > ILV: ElementID(a), length(a) > value(a) > ILV: ElementID(b), length(b) > value(b) > ILV: ElementID(c), length(c) > value(c) > >(b) Describing a subset of fields using ILVs (index/length values) > >Path to an instance of T ... > Dataraw TLV > ILV (ElementID a, length, value of a) > ILV (ElementID c, length, value of c) > >(c) Describing all fields using a Packed-Dataraw TLV > >Path to an instance of T ... > Packed-Dataraw TLV > (value of a) > (value of b) > (value of c) > >Note: Packed-Dataraw TLV _cannot_ be used unless all=20 >fields are being described. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Example 3: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Structure with a mix of fixed-length and variable-length fields,=20 >some mandatory, some optional (would be a good idea to show unions maybe= ). > > >struct U { > uint16 a > string b (optional) > uint16 c (optional) >} > > >(a) Describing all fields using ILVs > >Path to an instance of U ... > Dataraw TLV > ILV (ElementID a, length, value of a) > ILV (ElementID b, length, value of b) > ILV (ElementID c, length, value of c) > > >(b) Describing a subset of fields using ILVs > >Path to an instance of U ... > Dataraw TLV > ILV (ElementID a, length, value of a) > ILV (ElementID c, length, value of c) > > >(c) Describing all fields using a Packed-Dataraw TLV > >Path to an instance of U ... > Packed-Dataraw TLV=20 > (value of a) > Packed-Dataraw TLV (value of b) > (value of c) > >Note: The variable-length field requires the addition of a TLV withing t= he >packed data. > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Example 4: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Structure containing an array of another structure type. > > >struct V { > uint32 x > uint32 y > struct U z[] >} > > >(a): Describing all fields of V using ILVs, with two instances of z[], a= lso >described with ILVs, assuming only the 10th and 15th subscript of z[]. > >path to instance of V ... > Dataraw TLV > ILV (ElementID x, length, value of x) > ILV (ElementID y, length, value of y) > ILV (ElementID z) > ILV (index =3D 10) > ILV (ElementID a, length, value of a) > ILV (ElementID b, length, value of b) > ILV (ElementID c, length, value of c) > ILV (index =3D 15 ) > ILV (ElementID a, length, value of a) > ILV (ElementID c, length, value of c) > >Note the holes in the elements of z (10 followed by 15). Also note the >gap in index 15 with only elements a and c appearing but not b. > > =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 Tue Jul 12 05:14:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsGqi-00040C-K5 for forces-archive@megatron.ietf.org; Tue, 12 Jul 2005 05:14:44 -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 FAA03775 for ; Tue, 12 Jul 2005 05:14:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsHIt-00038D-C3 for forces-archive@IETF.ORG; Tue, 12 Jul 2005 05:43: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 <18.010A2996@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 5:14:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78775040 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 05:14:42 -0400 Received: from 195.212.29.134 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 05:14:41 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6C9DjJP007046 for ; Tue, 12 Jul 2005 09:13:59 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6C9DjPc265684 for ; Tue, 12 Jul 2005 10:13:45 +0100 Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j6C9DjlI006183 for ; Tue, 12 Jul 2005 10:13:45 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j6C9Dilo006172 for ; Tue, 12 Jul 2005 10:13:44 +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 LAA63508 for ; Tue, 12 Jul 2005 11:13:44 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6.2.1.2.0.20050708201027.02cd7b48@localhost> <42D385CB.6080901@zurich.ibm.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.uk.ibm.com id j6C9DjJP007046 Approved-By: Robert Haas Message-ID: <42D389C4.6010008@zurich.ibm.com> Date: Tue, 12 Jul 2005 11:13:40 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Fwd: Re: DataRaw? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42D385CB.6080901@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: quoted-printable Searching through the new model draft I have found answers to some of my=20 previous questions: I wrote: > Joel, Jamal, > The syntax looks ok to me. But I am not sure though how optional=20 > elements are the way of life in ForCES as some aspects are still=20 > unclear to me, for instance: > > Do we assume that default values are returned for optional elements=20 > unless they are explicitely set, or is there a reserved value= ? There is no value defined, apparently. > Does the default value appear in the LFB definition for each optional=20 > element ? Not clear if a default value MUST appear for each optional element though. > > What do we mean by "optional LFB element" exactly ? > Does it mean that from the LFB definition perspective, all optional=20 > elements MUST be supported by the FE and they MAY be used by the CE ? > Or can we have optional elements of an LFB that a particular FE=20 > implementation does not support ? According to the model draft, it is the latter (a particular LFB=20 instance in a FE implementation does not have to support all optional=20 elements). This makes sense, although using too many of these optional=20 elements will lead to complex CE software if the software wants to=20 benefit from whatever optional elements are provided. > > Regards, > -Robert > > Joel M. Halpern wrote: > >> Jamal and I have been batting back and forth ideas for how the=20 >> contents of the dataraw TLV should be constructed, so as to cope with=20 >> complex circumstances lake arrays with holes and structures with=20 >> optional elements. >> The attachment is our current best suggestion. >> >> Please take a look and let us know. >> Thanks, >> Joel >> >> ----------------------------------------------------------------------= -- >> >> >> A Data TLV has a 16 bit Type =3D DATARAW or PACKED-DATARAW, and a 16bi= t=20 >> Length >> followed by the data value/contents. >> In the case of the DATARAW (note: not packed) each DATA element in=20 >> the Value part will be further encapsulated in an ILV. An ILV is like=20 >> a TLV except it has a 32 bit Index (or element ID) and a 32 bit=20 >> Length field. >> The rationale behind ILVs is to make it easier to encapsulate optional= y >> appearing Data elements (which are expected to be the way of life in=20 >> Forces). >> >> Rules: >> >> 1) Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD be=20 >> padded >> to achieve the alignement. >> >> 2) Packed-Dataraw TLV may be used at a particular path only if every=20 >> element at that path level is present. This requirement holds=20 >> whether the fields are fixed or variable length, mandatory or optional. >> >> 3) An assumed optimization is that the encoder(sender) and the=20 >> decoder(receiver) >> both understand the definition of the data elements being shipped. >> >> a) If a Packed-Dataraw TLV is used, the encoder MUST layout data for=20 >> each element ordered by the order in which the data was defined. This=20 >> ensures >> the decoder is guaranteed to retrieve the data. >> >> b) In the case of a non-packed Dataraw we dont need to order since the >> I in the ILV uniquely identifies the element. >> >> 4) Inside a Packed-Dataraw TLV >> a) the values for atomic, fixed-length fields are given without=20 >> any TLV or >> ILV encapsulation. >> b) the values for atomic, variable-length fields are given inside=20 >> Dataraw TLVs. >> >> 5) Inside a Dataraw TLV (not packed) >> -> the values for atomic fields may be given with ILVs (32-bit=20 >> index, 32-bit length) >> >> 6) Any of the Dataraws can contain a ILV but an ILV cannot contain a=20 >> DATARAW. >> This is because it is hard to disambiguate ILV since an I is 32 >> bit and a T is 16 bit. >> >> 7) A DATARAW can also contain a DATARAW for variable sized elements.=20 >> The decoding disambiguation is assumed from rule #3 above. >> >> >> We give a few examples below but dont show the padding. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Example 1: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Structure with three fixed-length, mandatory fields. >> >> >> struct S { >> uint16 a >> uint16 b >> uint16 c >> } >> >> >> (a) Describing all fields using DATARAW >> with ILVs (index/length values) >> >> Path to an instance of S ... >> Dataraw TLV >> ILV: ElementID(a), length(a), value(a) >> ILV: ElementID(b), length(b), >> value(b) >> ILV: ElementID(c), length(c), >> value(c) >> >> (b) Describing a subset of fields >> Path-Data TLV to an instance of S ... >> Dataraw TLV >> ILV ElementID(a), length(a), value(a) >> ILV: ElementID(c), length(c), >> value(c) >> >> Note: Even though we have non-optional elements in structure S, since >> we can uniquely identify elements, we can selectively send element of >> structure S (eg in the case of an update from CE to FE). >> >> (c) Describing all fields using a Packed-Dataraw TLV >> >> Path to an instance of S ... >> Packed-Dataraw TLV >> value(a) >> value(b) >> value(c) >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Example 2: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Structure with three fixed-length fields, one mandatory, two optional. >> >> >> struct T { >> uint16 a >> uint16 b (optional) >> uint16 c (optional) >> } >> >> This example is identical to Example 1, as illustrated below. >> >> >> (a) Describing all fields using ILVs (index/length values) >> >> Path to an instance of T ... >> Dataraw TLV >> ILV: ElementID(a), length(a) >> value(a) >> ILV: ElementID(b), length(b) >> value(b) >> ILV: ElementID(c), length(c) >> value(c) >> >> (b) Describing a subset of fields using ILVs (index/length values) >> >> Path to an instance of T ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >> (c) Describing all fields using a Packed-Dataraw TLV >> >> Path to an instance of T ... >> Packed-Dataraw TLV >> (value of a) >> (value of b) >> (value of c) >> >> Note: Packed-Dataraw TLV _cannot_ be used unless all fields are being=20 >> described. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Example 3: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Structure with a mix of fixed-length and variable-length fields, some=20 >> mandatory, some optional (would be a good idea to show unions maybe). >> >> >> struct U { >> uint16 a >> string b (optional) >> uint16 c (optional) >> } >> >> >> (a) Describing all fields using ILVs >> >> Path to an instance of U ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID b, length, value of b) >> ILV (ElementID c, length, value of c) >> >> >> (b) Describing a subset of fields using ILVs >> >> Path to an instance of U ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >> >> (c) Describing all fields using a Packed-Dataraw TLV >> >> Path to an instance of U ... >> Packed-Dataraw TLV (value of a) >> Packed-Dataraw TLV (value of b) >> (value of c) >> >> Note: The variable-length field requires the addition of a TLV=20 >> withing the >> packed data. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Example 4: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Structure containing an array of another structure type. >> >> >> struct V { >> uint32 x >> uint32 y >> struct U z[] >> } >> >> >> (a): Describing all fields of V using ILVs, with two instances of=20 >> z[], also >> described with ILVs, assuming only the 10th and 15th subscript of z[]. >> >> path to instance of V ... >> Dataraw TLV >> ILV (ElementID x, length, value of x) >> ILV (ElementID y, length, value of y) >> ILV (ElementID z) >> ILV (index =3D 10) >> ILV (ElementID a, length, value of a) >> ILV (ElementID b, length, value of b) >> ILV (ElementID c, length, value of c) >> ILV (index =3D 15 ) >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >> Note the holes in the elements of z (10 followed by 15). Also note the >> gap in index 15 with only elements a and c appearing but not b. >> >> =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 Tue Jul 12 07:41:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJ94-0008NK-EF for forces-archive@megatron.ietf.org; Tue, 12 Jul 2005 07:41: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 HAA12733 for ; Tue, 12 Jul 2005 07:41:49 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsJb8-000065-GP for forces-archive@IETF.ORG; Tue, 12 Jul 2005 08: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 <13.010A2B72@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 7:41:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78822228 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 07:41:34 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 07:41:33 -0400 Received: from [162.84.111.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11377267; Tue, 12 Jul 2005 07:41:32 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050708201027.02cd7b48@localhost> <42D385CB.6080901@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050712073849.02e11888@localhost> Date: Tue, 12 Jul 2005 07:41:31 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Fwd: Re: DataRaw? Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42D385CB.6080901@zurich.ibm.com> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Content-Transfer-Encoding: quoted-printable An optional element is a component (LFB attribute, part of a structure,=20 ...) that an FE is not required to support. A request to GET the component will return an error (= =20 or equivalent.). GETting the whole structure will return the supported=20 fields, and not the unsupported fields. A SET request which includes=20 writing that field will return an error. A not supported optional element is not the same as a read-only element=20 with a defaul value. Yours, Joel At 04:56 AM 7/12/2005, Robert Haas wrote: >Joel, Jamal, >The syntax looks ok to me. But I am not sure though how optional elements= =20 >are the way of life in ForCES as some aspects are still unclear to me, for= =20 >instance: > >Do we assume that default values are returned for optional elements unless= =20 >they are explicitely set, or is there a reserved value ? >Does the default value appear in the LFB definition for each optional=20 >element ? > >What do we mean by "optional LFB element" exactly ? >Does it mean that from the LFB definition perspective, all optional=20 >elements MUST be supported by the FE and they MAY be used by the CE ? >Or can we have optional elements of an LFB that a particular FE=20 >implementation does not support ? > >Regards, >-Robert > >Joel M. Halpern wrote: > >>Jamal and I have been batting back and forth ideas for how the contents=20 >>of the dataraw TLV should be constructed, so as to cope with complex=20 >>circumstances lake arrays with holes and structures with optional= elements. >>The attachment is our current best suggestion. >> >>Please take a look and let us know. >>Thanks, >>Joel >> >>------------------------------------------------------------------------ >> >> >>A Data TLV has a 16 bit Type =3D DATARAW or PACKED-DATARAW, and a 16bit= Length >>followed by the data value/contents. >>In the case of the DATARAW (note: not packed) each DATA element in the=20 >>Value part will be further encapsulated in an ILV. An ILV is like a TLV=20 >>except it has a 32 bit Index (or element ID) and a 32 bit Length field. >>The rationale behind ILVs is to make it easier to encapsulate optionaly >>appearing Data elements (which are expected to be the way of life in= Forces). >> >>Rules: >> >>1) Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD be= padded >>to achieve the alignement. >> >>2) Packed-Dataraw TLV may be used at a particular path only if every=20 >>element at that path level is present. This requirement holds whether=20 >>the fields are fixed or variable length, mandatory or optional. >> >>3) An assumed optimization is that the encoder(sender) and the=20 >>decoder(receiver) >>both understand the definition of the data elements being shipped. >> >>a) If a Packed-Dataraw TLV is used, the encoder MUST layout data for each= =20 >>element ordered by the order in which the data was defined. This ensures >>the decoder is guaranteed to retrieve the data. >> >>b) In the case of a non-packed Dataraw we dont need to order since the >>I in the ILV uniquely identifies the element. >> >>4) Inside a Packed-Dataraw TLV >> a) the values for atomic, fixed-length fields are given without any=20 >> TLV or >> ILV encapsulation. >> b) the values for atomic, variable-length fields are given=20 >> inside Dataraw TLVs. >> >>5) Inside a Dataraw TLV (not packed) >> -> the values for atomic fields may be given with ILVs (32-bit=20 >> index, 32-bit length) >> >>6) Any of the Dataraws can contain a ILV but an ILV cannot contain a=20 >>DATARAW. >>This is because it is hard to disambiguate ILV since an I is 32 >>bit and a T is 16 bit. >> >>7) A DATARAW can also contain a DATARAW for variable sized elements. The= =20 >>decoding disambiguation is assumed from rule #3 above. >> >> >>We give a few examples below but dont show the padding. >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Example 1: >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Structure with three fixed-length, mandatory fields. >> >> >>struct S { >> uint16 a >> uint16 b >> uint16 c >>} >> >> >>(a) Describing all fields using DATARAW >>with ILVs (index/length values) >> >>Path to an instance of S ... >> Dataraw TLV >> ILV: ElementID(a), length(a), value(a) >> ILV: ElementID(b), length(b), >> value(b) >> ILV: ElementID(c), length(c), >> value(c) >> >>(b) Describing a subset of fields >>Path-Data TLV to an instance of S ... >> Dataraw TLV >> ILV ElementID(a), length(a), value(a) >> ILV: ElementID(c), length(c), >> value(c) >> >>Note: Even though we have non-optional elements in structure S, since >>we can uniquely identify elements, we can selectively send element of >>structure S (eg in the case of an update from CE to FE). >> >>(c) Describing all fields using a Packed-Dataraw TLV >> >>Path to an instance of S ... >> Packed-Dataraw TLV >> value(a) >> value(b) >> value(c) >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Example 2: >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Structure with three fixed-length fields, one mandatory, two optional. >> >> >>struct T { >> uint16 a >> uint16 b (optional) >> uint16 c (optional) >>} >> >>This example is identical to Example 1, as illustrated below. >> >> >>(a) Describing all fields using ILVs (index/length values) >> >>Path to an instance of T ... >> Dataraw TLV >> ILV: ElementID(a), length(a) >> value(a) >> ILV: ElementID(b), length(b) >> value(b) >> ILV: ElementID(c), length(c) >> value(c) >> >>(b) Describing a subset of fields using ILVs (index/length values) >> >>Path to an instance of T ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >>(c) Describing all fields using a Packed-Dataraw TLV >> >>Path to an instance of T ... >> Packed-Dataraw TLV >> (value of a) >> (value of b) >> (value of c) >> >>Note: Packed-Dataraw TLV _cannot_ be used unless all fields are being=20 >>described. >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Example 3: >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Structure with a mix of fixed-length and variable-length fields, some=20 >>mandatory, some optional (would be a good idea to show unions maybe). >> >> >>struct U { >> uint16 a >> string b (optional) >> uint16 c (optional) >>} >> >> >>(a) Describing all fields using ILVs >> >>Path to an instance of U ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID b, length, value of b) >> ILV (ElementID c, length, value of c) >> >> >>(b) Describing a subset of fields using ILVs >> >>Path to an instance of U ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >> >>(c) Describing all fields using a Packed-Dataraw TLV >> >>Path to an instance of U ... >> Packed-Dataraw TLV (value of a) >> Packed-Dataraw TLV (value of b) >> (value of c) >> >>Note: The variable-length field requires the addition of a TLV withing the >>packed data. >> >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Example 4: >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Structure containing an array of another structure type. >> >> >>struct V { >> uint32 x >> uint32 y >> struct U z[] >>} >> >> >>(a): Describing all fields of V using ILVs, with two instances of z[],= also >>described with ILVs, assuming only the 10th and 15th subscript of z[]. >> >>path to instance of V ... >> Dataraw TLV >> ILV (ElementID x, length, value of x) >> ILV (ElementID y, length, value of y) >> ILV (ElementID z) >> ILV (index =3D 10) >> ILV (ElementID a, length, value of a) >> ILV (ElementID b, length, value of b) >> ILV (ElementID c, length, value of c) >> ILV (index =3D 15 ) >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >>Note the holes in the elements of z (10 followed by 15). Also note the >>gap in index 15 with only elements a and c appearing but not b. >> >> > >-- >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/~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Jul 12 10:55:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsMAk-00045V-KU for forces-archive@megatron.ietf.org; Tue, 12 Jul 2005 10:55: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 KAA00424 for ; Tue, 12 Jul 2005 10:55:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsMcq-00086O-2n for forces-archive@IETF.ORG; Tue, 12 Jul 2005 11: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 <17.010A2EE5@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 10:55:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78834107 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 10:55:23 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 10:55:22 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Tue, 12 Jul 2005 23:34:58 +0800 (CST) References: <6.2.1.2.0.20050708201027.02cd7b48@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: <004301c586f1$b3b2b180$1f12fea9@wwm1> Date: Tue, 12 Jul 2005 22:55:09 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: DataRaw? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: base64 Sm9lbCwgYW5kIEphbWFsLA0KDQpJJ20gZ2xhZCB0byBzZWUgdGhhdCBhbiBJTFYgaXMgdXNlZCB3 aGljaCBkaXJlY3RseSB1c2VzIElEIGFzIHRoZSBpbmRleCBmb3IgZWxlbWVudCwgd2hpY2ggbWF0 Y2hlcyBteSB2ZXJ5IGVhcmx5IHRob3VnaHQgdGhhdCB3ZSB1c2UgYXR0cmlidXRlIElEIGZvciBp bmRleCBkaXJlY3RseSByYXRoZXIgdGhhbiBhIHBhdGguIA0KDQpJIGxpa2UgdGhpcyBleGFtcGxl Og0KDQogIERhdGFyYXcgVExWDQogICAgSUxWIChFbGVtZW50SUQgeCwgbGVuZ3RoLCB2YWx1ZSBv ZiB4KQ0KICAgIElMViAoRWxlbWVudElEIHksIGxlbmd0aCwgdmFsdWUgb2YgeSkNCiAgICBJTFYg KEVsZW1lbnRJRCB6KQ0KICAgICAgSUxWIChpbmRleCA9IDEwKQ0KICAgICAgICBJTFYgKEVsZW1l bnRJRCBhLCBsZW5ndGgsIHZhbHVlIG9mIGEpDQogICAgICAgIElMViAoRWxlbWVudElEIGIsIGxl bmd0aCwgdmFsdWUgb2YgYikNCiAgICAgICAgSUxWIChFbGVtZW50SUQgYywgbGVuZ3RoLCB2YWx1 ZSBvZiBjKQ0KICAgICAgSUxWIChpbmRleCA9IDE1ICkNCiAgICAgICAgSUxWIChFbGVtZW50SUQg YSwgbGVuZ3RoLCB2YWx1ZSBvZiBhKQ0KICAgICAgICBJTFYgKEVsZW1lbnRJRCBjLCBsZW5ndGgs IHZhbHVlIG9mIGMpDQoNCkJ5IHVzaW5nIHN1Y2ggbmVzdGQgSUxWIGZvcm1hdCwgYWdhaW4sIG15 IHF1ZXN0aW9uIGlzLCBkbyB3ZSBuZWVkIHRoZSBQYXRoIGZvcm1hdCBhbnltb3JlPyANCg0KVGhh bmsgeW91Lg0KV2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IkpvZWwgTS4gSGFscGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NClRvOiA8Rk9SQ0VTQFBF QUNILkVBU0UuTFNPRlQuQ09NPg0KU2VudDogU2F0dXJkYXksIEp1bHkgMDksIDIwMDUgODoxMSBB TQ0KU3ViamVjdDogRndkOiBSZTogRGF0YVJhdz8NCg0KDQo+IEphbWFsIGFuZCBJIGhhdmUgYmVl biBiYXR0aW5nIGJhY2sgYW5kIGZvcnRoIGlkZWFzIGZvciBob3cgdGhlIGNvbnRlbnRzIG9mIA0K PiB0aGUgZGF0YXJhdyBUTFYgc2hvdWxkIGJlIGNvbnN0cnVjdGVkLCBzbyBhcyB0byBjb3BlIHdp dGggY29tcGxleCANCj4gY2lyY3Vtc3RhbmNlcyBsYWtlIGFycmF5cyB3aXRoIGhvbGVzIGFuZCBz dHJ1Y3R1cmVzIHdpdGggb3B0aW9uYWwgZWxlbWVudHMuDQo+IFRoZSBhdHRhY2htZW50IGlzIG91 ciBjdXJyZW50IGJlc3Qgc3VnZ2VzdGlvbi4NCj4gDQo+IFBsZWFzZSB0YWtlIGEgbG9vayBhbmQg bGV0IHVzIGtub3cuDQo+IFRoYW5rcywNCj4gSm9lbA== From owner-forces@PEACH.EASE.LSOFT.COM Tue Jul 12 15:02:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQ16-0006Ch-4A for forces-archive@megatron.ietf.org; Tue, 12 Jul 2005 15:02: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 PAA24190 for ; Tue, 12 Jul 2005 15:02:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsQTI-0002JC-6P for forces-archive@IETF.ORG; Tue, 12 Jul 2005 15:31: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 <2.010A37D2@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 15:01:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78862565 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 15:01:53 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 15:01:53 -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 j6CJ1qGT004922; Tue, 12 Jul 2005 19:01:52 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 j6CJ1iD0014162; Tue, 12 Jul 2005 19:01:51 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 M2005071212015112961 ; Tue, 12 Jul 2005 12:01:51 -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, 12 Jul 2005 12:01:18 -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] LFB library draft thread-index: AcWCnQR1WMRhuv36TVGtNsUrMPJASwAHDQxwARanVlA= X-OriginalArrivalTime: 12 Jul 2005 19:01:18.0146 (UTC) FILETIME=[159A5A20:01C58714] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05F5C0FF@orsmsx408> Date: Tue, 12 Jul 2005 12:02:11 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: LFB library draft Comments: To: "Khosravi, Hormuzd M" , "Joel M. Halpern" Comments: cc: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable I pulled out the LFB definitions out of the current model document and gave them to Jamal as a starting point. I still have that version if you need it. Unfortunately, Steven Blake wasn't able to get much further than this. Ellen -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Wednesday, July 06, 2005 11:06 PM To: Joel M. Halpern; FORCES@PEACH.EASE.LSOFT.COM Cc: Yang, Lily L; Deleganes, Ellen M Subject: RE: [FORCES] LFB library draft Joel, If I remember correctly the original FE Model draft that Lily was editing did have a bunch of LFB definitions, an initial LFB library of sorts. The plan was to move this content to a different draft and add more details to it. Do you have the starting draft with the content from the original FE Model draft? That would be a good starting point and then the WG/authors can start refining the content...but a starting draft would be helpful. Let me know if I am off track here, Thanks Hormuzd -----Original Message----- This relates to a larger question for the list... We NEED an LFB library. Please! To do this, we need folks to actually write definitions of LFBs. (I think we have an editor who is likely to be willing to pull things=20 together. At least I hope so.) There are a lot of LFBs that need writing. If this WG doesn't start producing them, it won't happen. Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Tue Jul 12 17:22:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSCZ-00073j-A2 for forces-archive@megatron.ietf.org; Tue, 12 Jul 2005 17:22:03 -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 RAA09174 for ; Tue, 12 Jul 2005 17:22:00 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsSeo-000292-IO for forces-archive@IETF.ORG; Tue, 12 Jul 2005 17:51: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 <12.010A3E05@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 17:21:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78875426 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 17:21:59 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 17:21:58 -0400 Received: from [162.84.111.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11384250; Tue, 12 Jul 2005 17:21:53 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050708201027.02cd7b48@localhost> <004301c586f1$b3b2b180$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.20050712172036.02e459d8@localhost> Date: Tue, 12 Jul 2005 17:21:45 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: DataRaw? Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <004301c586f1$b3b2b180$1f12fea9@wwm1> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca We still need paths for selecting which element is wanted. If we always wanted to get or set the whole LFB, we would not need paths. One way to think of this is that the path represent a sequence of I fields from ILVs where the lengths would be redundant and the V is just the single next ILV. Yours, Joel At 10:55 AM 7/12/2005, Weiming Wang wrote: >Joel, and Jamal, > >I'm glad to see that an ILV is used which directly uses ID as the index >for element, which matches my very early thought that we use attribute ID >for index directly rather than a path. > >I like this example: > > Dataraw TLV > ILV (ElementID x, length, value of x) > ILV (ElementID y, length, value of y) > ILV (ElementID z) > ILV (index = 10) > ILV (ElementID a, length, value of a) > ILV (ElementID b, length, value of b) > ILV (ElementID c, length, value of c) > ILV (index = 15 ) > ILV (ElementID a, length, value of a) > ILV (ElementID c, length, value of c) > >By using such nestd ILV format, again, my question is, do we need the Path >format anymore? > >Thank you. >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >To: >Sent: Saturday, July 09, 2005 8:11 AM >Subject: Fwd: Re: DataRaw? > > > > Jamal and I have been batting back and forth ideas for how the contents of > > the dataraw TLV should be constructed, so as to cope with complex > > circumstances lake arrays with holes and structures with optional elements. > > The attachment is our current best suggestion. > > > > Please take a look and let us know. > > Thanks, > > Joel From owner-forces@PEACH.EASE.LSOFT.COM Tue Jul 12 19:40:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUMB-0001Pu-KO for forces-archive@megatron.ietf.org; Tue, 12 Jul 2005 19:40: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 TAA08255 for ; Tue, 12 Jul 2005 19:40:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsUoO-0004as-TU for forces-archive@IETF.ORG; Tue, 12 Jul 2005 20:09: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 <16.010A4216@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 19:40:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78884186 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 19:40:00 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 19:39:59 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Wed, 13 Jul 2005 08:19:39 +0800 (CST) References: <6.2.1.2.0.20050708201027.02cd7b48@localhost> <004301c586f1$b3b2b180$1f12fea9@wwm1> <6.2.1.2.0.20050712172036.02e459d8@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: <002301c5873a$fd1b60d0$1f12fea9@wwm1> Date: Wed, 13 Jul 2005 07:39:47 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: DataRaw? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: base64 Sm9lbCwNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhh bHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQpUbzogIldlaW1pbmcgV2FuZyIgPHdtd2Fu Z0BtYWlsLnpqZ3N1LmVkdS5jbj47IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQoNCj4g V2Ugc3RpbGwgbmVlZCBwYXRocyBmb3Igc2VsZWN0aW5nIHdoaWNoIGVsZW1lbnQgaXMgd2FudGVk LiAgSWYgd2UgYWx3YXlzIA0KPiB3YW50ZWQgdG8gZ2V0IG9yIHNldCB0aGUgd2hvbGUgTEZCLCB3 ZSB3b3VsZCBub3QgbmVlZCBwYXRocy4NCj4gDQo+IE9uZSB3YXkgdG8gdGhpbmsgb2YgdGhpcyBp cyB0aGF0IHRoZSBwYXRoIHJlcHJlc2VudCBhIHNlcXVlbmNlIG9mIEkgZmllbGRzIA0KPiBmcm9t IElMVnMgd2hlcmUgdGhlIGxlbmd0aHMgd291bGQgYmUgcmVkdW5kYW50IGFuZCB0aGUgViBpcyBq dXN0IHRoZSBzaW5nbGUgDQo+IG5leHQgSUxWLg0KDQpUaGUgSUxWcyB3aXRoIGxlbmd0aCA9MCBh dCB0aGUgdGVybWluYWwgY2FuICByZXBzZW50IHRoZSBwYXRoIGZ1bmN0aW9uIHdlbGwgaW4gYSBn ZXQgb3BlcmF0aW9uLiANCkFzIGZvciBlZmZpY2llbmN5LCByZXByZXNlbnRhdGlvbiBvZiBwYXRo cyBsZXNzIHRoYW4gMyBsYXllcnMgKGUuZy4gMS4yLjMpIGlzIG5vdCBhcyBlZmZpY2llbnQgYXMg bmVzdGVkIElMViBmb3JtYXQuDQoNCkFub3RoZXIgdmVyeSBpbXBvcnRhbnQgZmVhdHVyZSBmb3Ig SUxWIGZvcm1hdCBpcywgd2UgbWF5IHVzZSB0aGUgZm9sbG93aW5nIGZvcm1hdCB0byAsIGUuZy4s IHF1ZXJ5IGEgbnVtYmVyIG9mIGZpZWxkcyBmb3IgdmFsdWVzIGF0IG9uY2UsIGxpa2U6DQoNCj4g PiAgIERhdGFyYXcgVExWDQo+ID4gICAgIElMViAoRWxlbWVudElEIHgsIGxlbmd0aD0wKQ0KPiA+ ICAgICBJTFYgKEVsZW1lbnRJRCB5LCBsZW5ndGg9MCkNCj4gPiAgICAgSUxWIChFbGVtZW50SUQg eikNCj4gPiAgICAgICBJTFYgKGluZGV4ID0gMTApDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJ RCBhLCBsZW5ndGg9MCkNCj4gPiAgICAgICAgIElMViAoRWxlbWVudElEIGIsIGxlbmd0aD0wKQ0K PiA+ICAgICAgIElMViAoaW5kZXggPSAxNSApDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJRCBh LCBsZW5ndGg9MCkNCj4gPiAgICAgICAgIElMViAoRWxlbWVudElEIGMsIGxlbmd0aD0wKQ0KDQpU aGUgZ2V0LXJlc3BvbnNlIGlzIHRoZW4gc2ltcGxpZmllZCB0byBmaWxsIG91dCBhbGwgdGhlIHZh bHVlIHBhcnQgaW4gdGhlIElMVnMuDQoNClRoYW5rcywNCldlaW1pbmcNCg0KPiANCj4gWW91cnMs DQo+IEpvZWwNCj4gDQo+IEF0IDEwOjU1IEFNIDcvMTIvMjAwNSwgV2VpbWluZyBXYW5nIHdyb3Rl Og0KPiA+Sm9lbCwgYW5kIEphbWFsLA0KPiA+DQo+ID5JJ20gZ2xhZCB0byBzZWUgdGhhdCBhbiBJ TFYgaXMgdXNlZCB3aGljaCBkaXJlY3RseSB1c2VzIElEIGFzIHRoZSBpbmRleCANCj4gPmZvciBl bGVtZW50LCB3aGljaCBtYXRjaGVzIG15IHZlcnkgZWFybHkgdGhvdWdodCB0aGF0IHdlIHVzZSBh dHRyaWJ1dGUgSUQgDQo+ID5mb3IgaW5kZXggZGlyZWN0bHkgcmF0aGVyIHRoYW4gYSBwYXRoLg0K PiA+DQo+ID5JIGxpa2UgdGhpcyBleGFtcGxlOg0KPiA+DQo+ID4gICBEYXRhcmF3IFRMVg0KPiA+ ICAgICBJTFYgKEVsZW1lbnRJRCB4LCBsZW5ndGgsIHZhbHVlIG9mIHgpDQo+ID4gICAgIElMViAo RWxlbWVudElEIHksIGxlbmd0aCwgdmFsdWUgb2YgeSkNCj4gPiAgICAgSUxWIChFbGVtZW50SUQg eikNCj4gPiAgICAgICBJTFYgKGluZGV4ID0gMTApDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJ RCBhLCBsZW5ndGgsIHZhbHVlIG9mIGEpDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJRCBiLCBs ZW5ndGgsIHZhbHVlIG9mIGIpDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJRCBjLCBsZW5ndGgs IHZhbHVlIG9mIGMpDQo+ID4gICAgICAgSUxWIChpbmRleCA9IDE1ICkNCj4gPiAgICAgICAgIElM ViAoRWxlbWVudElEIGEsIGxlbmd0aCwgdmFsdWUgb2YgYSkNCj4gPiAgICAgICAgIElMViAoRWxl bWVudElEIGMsIGxlbmd0aCwgdmFsdWUgb2YgYykNCj4gPg0KPiA+QnkgdXNpbmcgc3VjaCBuZXN0 ZCBJTFYgZm9ybWF0LCBhZ2FpbiwgbXkgcXVlc3Rpb24gaXMsIGRvIHdlIG5lZWQgdGhlIFBhdGgg DQo+ID5mb3JtYXQgYW55bW9yZT8NCj4gPg0KPiA+VGhhbmsgeW91Lg0KPiA+V2VpbWluZw0KPiA+ DQo+ID4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID5Gcm9tOiAiSm9lbCBNLiBIYWxw ZXJuIiA8am9lbEBzdGV2ZWNyb2NrZXIuY29tPg0KPiA+VG86IDxGT1JDRVNAUEVBQ0guRUFTRS5M U09GVC5DT00+DQo+ID5TZW50OiBTYXR1cmRheSwgSnVseSAwOSwgMjAwNSA4OjExIEFNDQo+ID5T dWJqZWN0OiBGd2Q6IFJlOiBEYXRhUmF3Pw0KPiA+DQo+ID4NCj4gPiA+IEphbWFsIGFuZCBJIGhh dmUgYmVlbiBiYXR0aW5nIGJhY2sgYW5kIGZvcnRoIGlkZWFzIGZvciBob3cgdGhlIGNvbnRlbnRz IG9mDQo+ID4gPiB0aGUgZGF0YXJhdyBUTFYgc2hvdWxkIGJlIGNvbnN0cnVjdGVkLCBzbyBhcyB0 byBjb3BlIHdpdGggY29tcGxleA0KPiA+ID4gY2lyY3Vtc3RhbmNlcyBsYWtlIGFycmF5cyB3aXRo IGhvbGVzIGFuZCBzdHJ1Y3R1cmVzIHdpdGggb3B0aW9uYWwgZWxlbWVudHMuDQo+ID4gPiBUaGUg YXR0YWNobWVudCBpcyBvdXIgY3VycmVudCBiZXN0IHN1Z2dlc3Rpb24uDQo+ID4gPg0KPiA+ID4g UGxlYXNlIHRha2UgYSBsb29rIGFuZCBsZXQgdXMga25vdy4NCj4gPiA+IFRoYW5rcywNCj4gPiA+ IEpvZWwNCj4g From owner-forces@PEACH.EASE.LSOFT.COM Tue Jul 12 20:22:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsV15-0008SN-CO for forces-archive@megatron.ietf.org; Tue, 12 Jul 2005 20:22: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 UAA10940 for ; Tue, 12 Jul 2005 20:22:22 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsVTO-0005po-Bm for forces-archive@IETF.ORG; Tue, 12 Jul 2005 20:51: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.010A430F@cherry.ease.lsoft.com>; Tue, 12 Jul 2005 20:22:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78886592 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Jul 2005 20:22:21 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 12 Jul 2005 20:22:20 -0400 Received: from [162.84.111.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11386212; Tue, 12 Jul 2005 20:22:20 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050708201027.02cd7b48@localhost> <004301c586f1$b3b2b180$1f12fea9@wwm1> <6.2.1.2.0.20050712172036.02e459d8@localhost> <002301c5873a$fd1b60d0$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.20050712201935.02e7d818@localhost> Date: Tue, 12 Jul 2005 20:22:18 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: DataRaw? Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <002301c5873a$fd1b60d0$1f12fea9@wwm1> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f a) In my opinion, it is helpful to have a clear sesparation between "this is the thing I am interested in" (path) and "this is the value of the thing I am interested in" (dataraw or packed-dataraw). b) We could use just the ILV in Set Request and Get Response messages. However, if there is any depth there will be a lot of redundant length fields and more complex parsing to realize that there are not additional elements at each level. c) We could use the ILV with length 0 in GET requests to indicate "this is the field I want to get", but that seems a very misleading encoding of a very natural concept. Basically, the path structure gives us a clear and compact representation of an important concept in the protocol activity. Yours, Joel At 07:39 PM 7/12/2005, Weiming Wang wrote: >Joel, > >----- Original Message ----- >From: "Joel M. Halpern" >To: "Weiming Wang" ; > > > We still need paths for selecting which element is wanted. If we always > > wanted to get or set the whole LFB, we would not need paths. > > > > One way to think of this is that the path represent a sequence of I fields > > from ILVs where the lengths would be redundant and the V is just the > single > > next ILV. > >The ILVs with length =0 at the terminal can repsent the path function >well in a get operation. >As for efficiency, representation of paths less than 3 layers (e.g. 1.2.3) >is not as efficient as nested ILV format. > >Another very important feature for ILV format is, we may use the following >format to , e.g., query a number of fields for values at once, like: > > > > Dataraw TLV > > > ILV (ElementID x, length=0) > > > ILV (ElementID y, length=0) > > > ILV (ElementID z) > > > ILV (index = 10) > > > ILV (ElementID a, length=0) > > > ILV (ElementID b, length=0) > > > ILV (index = 15 ) > > > ILV (ElementID a, length=0) > > > ILV (ElementID c, length=0) > >The get-response is then simplified to fill out all the value part in the >ILVs. > >Thanks, >Weiming > > > > > Yours, > > Joel > > > > At 10:55 AM 7/12/2005, Weiming Wang wrote: > > >Joel, and Jamal, > > > > > >I'm glad to see that an ILV is used which directly uses ID as the index > > >for element, which matches my very early thought that we use attribute ID > > >for index directly rather than a path. > > > > > >I like this example: > > > > > > Dataraw TLV > > > ILV (ElementID x, length, value of x) > > > ILV (ElementID y, length, value of y) > > > ILV (ElementID z) > > > ILV (index = 10) > > > ILV (ElementID a, length, value of a) > > > ILV (ElementID b, length, value of b) > > > ILV (ElementID c, length, value of c) > > > ILV (index = 15 ) > > > ILV (ElementID a, length, value of a) > > > ILV (ElementID c, length, value of c) > > > > > >By using such nestd ILV format, again, my question is, do we need the > Path > > >format anymore? > > > > > >Thank you. > > >Weiming > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >To: > > >Sent: Saturday, July 09, 2005 8:11 AM > > >Subject: Fwd: Re: DataRaw? > > > > > > > > > > Jamal and I have been batting back and forth ideas for how the > contents of > > > > the dataraw TLV should be constructed, so as to cope with complex > > > > circumstances lake arrays with holes and structures with optional > elements. > > > > The attachment is our current best suggestion. > > > > > > > > Please take a look and let us know. > > > > Thanks, > > > > Joel > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 13 05:17:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdMa-0007Uv-0U for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 05:17: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 FAA17446 for ; Wed, 13 Jul 2005 05:17:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsdot-0006rb-H1 for forces-archive@IETF.ORG; Wed, 13 Jul 2005 05:46: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 <10.010A5149@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 5:16:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78916035 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 05:16:53 -0400 Received: from 213.97.128.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 05:16:53 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------noqwaykivwnmjufoqmpw" Approved-By: "David.Putzolu" Message-ID: Date: Wed, 13 Jul 2005 10:16:05 +0000 Reply-To: "David.Putzolu" Sender: Forwarding and Control Element Separation From: "David.Putzolu" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----------noqwaykivwnmjufoqmpw Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Music_MP3.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/13/2005 09:10 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------noqwaykivwnmjufoqmpw Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


----------noqwaykivwnmjufoqmpw-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 13 11:46:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjRM-00079x-4P for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 11:46:32 -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 LAA25482 for ; Wed, 13 Jul 2005 11:46:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsjti-0008M4-Sy for forces-archive@IETF.ORG; Wed, 13 Jul 2005 12:15: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 <20.010A58B1@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 11:46:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78977386 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 11:46:21 -0400 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 11:46:20 -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 j6DFkJmE152626 for ; Wed, 13 Jul 2005 15:46:19 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/VER6.6) with ESMTP id j6DFkJRd128918 for ; Wed, 13 Jul 2005 17:46:19 +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 j6DFkJNA012352 for ; Wed, 13 Jul 2005 17:46:19 +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 j6DFkIdm012333; Wed, 13 Jul 2005 17:46:18 +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 RAA68488; Wed, 13 Jul 2005 17:46:18 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1118394934.33.0.63678359005.issue52@mip4.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id j6DFkJmE152626 Approved-By: Robert Haas Message-ID: <42D53749.1090003@zurich.ibm.com> Date: Wed, 13 Jul 2005 17:46:17 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue52] Association Setup Response Message: unclear use of SHOW Comments: cc: tracker-forces@mip4.org To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118394934.33.0.63678359005.issue52@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Content-Transfer-Encoding: quoted-printable Here is how we should resolve this issue. I provided new text below. One=20 last thing is what happens to the Result field in the Association Setup=20 Response message (I'll open another tracker issue for that one and other=20 results in general). The Association Setup message (from FE to CE) may contain unsolicited=20 GET-RESPONSE operations. The reason is to let the FE declare what its=20 configuration paramaters are. The Association Setup Response message (from CE to FE) may contain SET=20 operations. The reason is to let the CE modifiy, for instance, the=20 configuration parameters that the FE declared. Only the FE Protocol LFB and the FE LFB may be targeted in the=20 Association Setup messages, as the CE must first find out what are the=20 available LFBs. Proposed new text (changes highlighted with ">"): 6.4.1 Association Setup Message This message is sent by the FE to the CE to setup a ForCES association between them. This message could also be used by CEs to join a ForCES NE, however CE-to-CE communication is not covered by this protocol. Message transfer direction: FE to CE Message Header: The Message Type in the header is set MessageType=3D 'Association Setup'. The ACK flag in the header is ignored, because the setup message will always expect to get a response from the message receiver (CE) whether the setup is successful or not. The Src ID (FE ID) may be set to O in the header which means that the FE would like the CE to assign a FE ID for the FE in the setup response message. Message body: > The LFB selection may point to the FE Object and/or FE Protocol L= FBs > and more than one attribute may be announced in this message using > GET-REPONSE to let the FE declare its configuration parameters in > an unsolicited manner. The layout is: main hdr (eg type =3D Association setup) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D FE object | | | | | +-- LFBInstance =3D 0x1 | | > | +--- T =3D Operation =3D GET-RESPONSE | | | +-- Path-data to one or more attibutes | including FE NAME +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol object | | +-- LFBInstance =3D 0x1 | > +--- T =3D Operation =3D GET-RESPONSE | +-- Path-data to one or more attibutes including suggested HB parameters 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID =3D FE Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D operation GET-REPONSE | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Attributes path and data ~ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID =3D FE Protocol Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D operation GET-REPONSE | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ Attributes path and data ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 Type (16 bits): LFB Select Length (16 bits): Length of the TLV including the T and L fields, in bytes. FE Object and Protocol LFBs: These contains the FE parameters e.g. HBI will be exchanged with the CE using the FE Protocol LFB. 6.4.2 Association Setup Response Message This message is sent by the CE to the FE in response to the Setup message. It indicates to the FE whether the setup is successful or not, i.e. whether an association is established. Message transfer direction: CE to FE Message Header: The Message Type in the header is set MessageType=3D 'Setup Response'. The ACK flag in the header is always ignored, because the setup response message will never expect to get any more response from the message receiver (FE). The Dst ID in the header will be set to some FE ID value assigned by the CE if the FE had requested that in the setup message (by SrcID =3D 0). Message body: > The LFB selection may point to the FE Object and/or FE Protocol LF= Bs > and more than one attribute may be announced in this message. The lay= out > is: main hdr (eg type =3D Association setup response) | | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D FE object | | | | | +-- LFBInstance =3D 0x1 | | > | +--- T =3D Operation =3D SET | | | +-- Path-data to one or more attibutes | including FE NAME >[line removed] +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol object | | +-- LFBInstance =3D 0x1 | > +--- T =3D Operation =3D SET | +-- Path-data to one or more attibutes eg HB parameters >[line removed] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID =3D FE Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D operation SET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Attributes path and data ~ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID =3D FE Protocol Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D operation SET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ Attributes path and data ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 Type (16 bits): LFB Select Length (16 bits): Length of the TLV including the T and L fields, in bytes. FE Object LFB: The FE parameters e.g. HBI may be exchanged using this LFB. Result (16 bits): This indicates whether the setup msg was successful or whether the FE request was rejected by the CE. Robert Haas wrote: >New submission from Robert Haas : > >6.4.2 Association Setup Response Message > > >I don't see why the CE has to SHOW attributes of the FE object/protocol=20 >object. Are we really expecting a RESULT for the SHOW command of the FE-= CE=20 >message ? > >Message from CE to FE: > > main hdr (eg type =3D Association setup response) > | > | > | > +--- T =3D LFBselect > | | > | +-- LFBCLASSID =3D FE object > | | > | | > | +-- LFBInstance =3D 0x1 > | | > | +--- T =3D Operation =3D SHOW > | | > | +-- Path-data to one or more attibutes > | including FE NAME > | May contain RESULT TLVs > +--- T =3D LFBselect > | > +-- LFBCLASSID =3D FE Protocol object > | > | > +-- LFBInstance =3D 0x1 > | > +--- T =3D Operation =3D SHOW > | > +-- Path-data to one or more attibutes > eg HB parameters > May contain RESULT TLVs > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 109 >nosy: rha >priority: Should fix >status: No discussion >title: Association Setup Response Message: unclear use of SHOW > >___________________________________________________ >Forces issue tracker > >___________________________________________________ > > > =20 > --=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 Wed Jul 13 11:48:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjTX-00012D-NB for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 11:48: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 LAA25654 for ; Wed, 13 Jul 2005 11:48:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsjvu-0008R1-I1 for forces-archive@IETF.ORG; Wed, 13 Jul 2005 12:18:07 -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.010A58AA@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 11:48:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78977491 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 11:48:28 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 11:48:28 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j6DFmR7v032453 for ; Wed, 13 Jul 2005 15:48:27 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 j6DFlxpD021324 for ; Wed, 13 Jul 2005 15:48:26 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 M2005071308482609589 for ; Wed, 13 Jul 2005 08:48:26 -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, 13 Jul 2005 08:48:26 -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: [issue32] Packet Redirect thread-index: AcWHubcLXeS7cBwfQpmAYWWkEzJkaAABaIpgAACr9EA= X-OriginalArrivalTime: 13 Jul 2005 15:48:26.0655 (UTC) FILETIME=[4EDEB2F0:01C587C2] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05F96F7D@orsmsx408> Date: Wed, 13 Jul 2005 08:48:24 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: FW: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.8 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable FYI...format of the Redirect TLV on which we seem to be reaching a concensus. -----Original Message----- I agree with this format for Redirect TLV as well. Should we consider this issue closed? Any other comments on this? Thanks Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.zjgsu.edu.cn]=20 Sent: Wednesday, July 13, 2005 7:43 AM To: Robert Haas; Khosravi, Hormuzd M; avri doria; Putzolu, David; Patrick Droz; donglg@mail.zjgsu.edu.cn; hadi@znyx.com; Joel M. Halpern Subject: Re: [issue32] Packet Redirect Are you supposing the format as: Redirect TLV LFB class ID LFB Insatnce ID Meta-Data TLV Redirct Data TLV I can agree with this well. The only thing is then how the meta-Data TLV should be defined here? Still using Path-Data format or using constant fields ? If constant fields, then it seems quite identical to that was showed below.=20 Sorry to all, I'v to go first. Thanks, Weiming ----- Original Message -----=20 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect > I think the Packet Data TLV you have here is the wrapper to carry the=20 > packet meta-data? > If so, the only question I have is whether it might be simpler and more=20 > general to just treat the port as part of the meta-data rather than=20 > assigning it a separate field. After all, that information will generally=20 > be used / provided by some other LFB than the redirect LFB. >=20 > Yours, > Joel >=20 > At 10:00 AM 7/13/2005, Wang,Weiming wrote: > >Sorry, the following LFB Type should be Type =3D Redirect instead of LFBselect. > > > >----- Original Message ----- > >From: Wang,Weiming > >To: Robert Haas ;=20 > >Khosravi, Hormuzd M ;=20 > >avri doria ; Joel M.=20 > >Halpern ; Putzolu, David ;=20 > >Patrick Droz ;=20 > >donglg@mail.zjgsu.edu.cn ;=20 > >hadi@znyx.com > >Sent: Wednesday, July 13, 2005 9:58 PM > >Subject: Re: [issue32] Packet Redirect > > > >Hi all, > > > >I may only have half an hour for the meeting owing to some urgent=20 > >business. I ask to take first > >some minutes of the call meeting to discuss the packet redirect message=20 > >and try to solve it quickly? > > > >After quite a lot discussion, I try to summary it as in the following > >format for packet redirect message: > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type =3D LFBselect | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LFB Class ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LFB Instance ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > . . > > | Packet Data TLV | > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Packet Data TLV > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type =3D Packet TYpe | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > . . > > | Packet Data | > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >Thanks, > >Weiming > > >=20 From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 13 12:05:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsjjj-0007Cv-Br for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 12:05: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 MAA27090 for ; Wed, 13 Jul 2005 12:05:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DskCA-0000fj-9h for forces-archive@IETF.ORG; Wed, 13 Jul 2005 12:34: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 <7.010A5A53@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 12:05:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78979129 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 12:05:25 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 12:05:25 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j6DG5N7v002686; Wed, 13 Jul 2005 16:05:23 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 j6DG54p4001574; Wed, 13 Jul 2005 16:05:23 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 M2005071309052212477 ; Wed, 13 Jul 2005 09:05:23 -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, 13 Jul 2005 09:05:23 -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] Fwd: Re: DataRaw? thread-index: AcWEGttprWUN0QtiRmmU9mJRH+ly9QDqa6XA X-OriginalArrivalTime: 13 Jul 2005 16:05:23.0447 (UTC) FILETIME=[ACECD870:01C587C4] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05F97011@orsmsx408> Date: Wed, 13 Jul 2005 09:05:21 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Fwd: Re: DataRaw? Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable This looks like a simple and efficient way to encapsulate the data. Thanks for the good work guys! I am fine with this format. Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, July 08, 2005 5:12 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Fwd: Re: DataRaw? Jamal and I have been batting back and forth ideas for how the contents of=20 the dataraw TLV should be constructed, so as to cope with complex=20 circumstances lake arrays with holes and structures with optional elements. The attachment is our current best suggestion. Please take a look and let us know. Thanks, Joel From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 13 12:36:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskE3-0006YQ-Ti for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 12:36: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 MAA01687 for ; Wed, 13 Jul 2005 12:36:45 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DskgV-0002Ki-CT for forces-archive@IETF.ORG; Wed, 13 Jul 2005 13:06: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 <3.010A5A19@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 12:36:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78981798 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 12:36:40 -0400 Received: from 81.228.9.182 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 12:36:40 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 53C4837EBC; Wed, 13 Jul 2005 18:34:18 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id B677B37E57 for ; Wed, 13 Jul 2005 18:34:17 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A045B37E42 for ; Wed, 13 Jul 2005 18:36:38 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DskDs-000795-UT for forces@peach.ease.lsoft.com; Wed, 13 Jul 2005 18:36:37 +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, MIME_QP_LONG_LINE,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: Robert Haas Message-ID: <1121272596.61.0.0291483779144.issue56@mip4.org> Date: Wed, 13 Jul 2005 16:36:36 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue56] Result TLV and result codes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : We haven't specified the following results values yet:=20 in the Association Setup Response - add an Association-Result TLV, with specific error codes describing why t= he=20 association setup failed. The defined values are: 0 =3D success 1 =3D FE ID invalid 2 =3D too many associations 3 =3D permission denied on the other hand, if we don't want to give a precise reason for the failur= e,=20 then the RESULT TLV proposed by Joel would be fine. in the Config Response message:=20 - assign a meaning for Operation Result (i.e., all attributes successfully=20 set, some errors, all errors, or what else ?) ---------- category: Technical draft: draft-ietf-forces-protocol messages: 210 nosy: rha priority: Must fix status: No discussion title: Result TLV and result codes ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 13 12:59:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dska2-0001dL-RP for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 12:59: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 MAA03486 for ; Wed, 13 Jul 2005 12:59:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsl2T-0003CY-E2 for forces-archive@IETF.ORG; Wed, 13 Jul 2005 13:28: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 <20.010A59EF@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 12:59:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78982965 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 12:59:23 -0400 Received: from 81.228.9.183 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 12:59:23 -0400 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 1004437E8E; Wed, 13 Jul 2005 18:59:22 +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 D654337E5C for ; Wed, 13 Jul 2005 18:59:21 +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 C1CCF37E44 for ; Wed, 13 Jul 2005 18:59:21 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DskZs-0001F4-Cd for forces@peach.ease.lsoft.com; Wed, 13 Jul 2005 18:59:21 +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.6 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: Robert Haas Message-ID: <1121273957.01.0.00265356372321.issue57@mip4.org> Date: Wed, 13 Jul 2005 16:59:17 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue57] Inconsistent operation types To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : We need to agree on the operation types (still inconsistent in the draft): for Configuration messages: set, delete, add, update, replace, del-all, cancel (are all these operatio= ns=20 applicable ?) event-subscribe, event-unsubscribe for Configuration-Response messages: the same operations but with *-response (set-reponse, del-response, etc) for Query messages: get for Query-Response messages: get-response for Event-Notification messages: report for Event-Notification-Response messages report-response for Packet-Redirect messages: no operation (currently we have "payload" TLV) Also the draft is inconsistent at many places, for instance, use of SET=20 instead of SET-RESPONSE, etc. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 211 nosy: rha priority: Must fix status: No discussion title: Inconsistent operation types ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 13 13:08:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dskir-0006ii-Sn for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 13:08: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 NAA04348 for ; Wed, 13 Jul 2005 13:08:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DslBF-0003YG-IG for forces-archive@IETF.ORG; Wed, 13 Jul 2005 13: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 <2.010A5B9F@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 13:08:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78984631 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 13:08:32 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 13:08:32 -0400 Received: from [162.84.111.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11398472; Wed, 13 Jul 2005 13:08:31 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1121273957.01.0.00265356372321.issue57@mip4.org> 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.20050713130709.02fbb468@localhost> Date: Wed, 13 Jul 2005 13:08:24 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue57] Inconsistent operation types Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1121273957.01.0.00265356372321.issue57@mip4.org> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 event-subscribe and event-unsubscribe will use Set. We need Set, Get, Set-Response, Get-Response, and notification. I don't think we need add or update operations. I am not sure about delete / del-all. At 12:59 PM 7/13/2005, Robert Haas wrote: >New submission from Robert Haas : > >We need to agree on the operation types (still inconsistent in the draft): > >for Configuration messages: > set, delete, add, update, replace, del-all, cancel (are all these > operations >applicable ?) > event-subscribe, event-unsubscribe > >for Configuration-Response messages: > the same operations but with *-response (set-reponse, del-response, etc) > >for Query messages: > get > >for Query-Response messages: > get-response > >for Event-Notification messages: > report > >for Event-Notification-Response messages > report-response > >for Packet-Redirect messages: > no operation (currently we have "payload" TLV) > >Also the draft is inconsistent at many places, for instance, use of SET >instead of SET-RESPONSE, etc. > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 211 >nosy: rha >priority: Must fix >status: No discussion >title: Inconsistent operation types > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 13 14:22:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslsH-0005EF-4z for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 14:22:25 -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 OAA08774 for ; Wed, 13 Jul 2005 14:22:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsmKj-0005xk-66 for forces-archive@IETF.ORG; Wed, 13 Jul 2005 14:51: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 <13.010A5B45@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 14:22:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78989289 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 14:22:20 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 14:22:20 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j6DIMJ7v027036; Wed, 13 Jul 2005 18:22:19 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 j6DIMHoq011500; Wed, 13 Jul 2005 18:22:18 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 M2005071309311228634 ; Wed, 13 Jul 2005 09:31:12 -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); Wed, 13 Jul 2005 09:30: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] Result TLV thread-index: AcV9pos+3Xw9HozAQCmAGRDA3h4CzAKHip1g X-OriginalArrivalTime: 13 Jul 2005 16:30:50.0519 (UTC) FILETIME=[3B218A70:01C587C8] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05F970D1@orsmsx408> Date: Wed, 13 Jul 2005 09:30:47 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Result TLV Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Again a reasonable and simple approach to provide the Results. To put some more context around it, is this how it would look like in a Config Response message? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (SET-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (DEL-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pls do clarify, No path-data tlv in this format? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, June 30, 2005 12:04 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Result TLV The following is what I suggest for handling results of operations. SET and GET Requests do not have result information (they are requests). SET and GET Responses have result information. SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. For a GET responses, individual gets which succeed will have DATARAW TLVs=20 added to the leaf paths to carry the requested data. For GET elements that=20 fail, instead of the DATARAW TLV there will be a RESULT TLV. For a SET response, each DATARAW TLV in the original request will be=20 replace with a RESULT TLV in the response. If the request was for Ack-fail, then only those items which failed will appear in the response. If the request was for ack-all, then all elements=20 of the request will appear in the response with RESULT TLVs. A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 byte)=20 value. The defined values are 0 =3D success 1 =3D no such object 2 =3D permission denied 3 =3D invalid value (the dataraw could not validly be stored in the field) 4 =3D invalid array creation (when the subscript in an array create = is not=20 allowed) 255 =3D unspecified error (for when the FE can not decide what went wrong) We may need a few more values to cover other errors. Note that if a SET request with a structure in a DATARAW is issued, and=20 some field in the structure is invalid, the FE will not attempt to indicate=20 which field was invalid, but rather will indicate that the operation failed. Note further that if there are multiple errors in a single leaf path-data /=20 DATARAW, the FE can select which error it chooses to return. So if a=20 DATARAW for a SET of a structure attempts to write one field which is read=20 only, and attempts to set another field to an invalid value, the FE can=20 return whatever error it likes. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 13 15:23:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsmpQ-0004X1-2U for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 15:23:32 -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 PAA13987 for ; Wed, 13 Jul 2005 15:23:30 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsnHs-0007wj-J1 for forces-archive@IETF.ORG; Wed, 13 Jul 2005 15:52: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 <14.010A5B97@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 15:23:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78994259 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 15:23:25 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 15:23:25 -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 j6DJNN3E011047; Wed, 13 Jul 2005 19:23:23 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 j6DJKKq8025382; Wed, 13 Jul 2005 19:23:20 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 M2005071310595105174 ; Wed, 13 Jul 2005 10:59:53 -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, 13 Jul 2005 10:59:41 -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] Result TLV thread-index: AcV9pos+3Xw9HozAQCmAGRDA3h4CzAKHip1gAAP3bQA= X-OriginalArrivalTime: 13 Jul 2005 17:59:41.0387 (UTC) FILETIME=[A49371B0:01C587D4] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05F973E1@orsmsx408> Date: Wed, 13 Jul 2005 10:59:38 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Result TLV Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Resending since I haven't seen this post yet... -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Wednesday, July 13, 2005 9:31 AM To: 'Joel M. Halpern'; FORCES@PEACH.EASE.LSOFT.COM Subject: RE: [FORCES] Result TLV Again a reasonable and simple approach to provide the Results. To put some more context around it, is this how it would look like in a Config Response message? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (SET-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (DEL-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pls do clarify, No path-data tlv in this format? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, June 30, 2005 12:04 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Result TLV The following is what I suggest for handling results of operations. SET and GET Requests do not have result information (they are requests). SET and GET Responses have result information. SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. For a GET responses, individual gets which succeed will have DATARAW TLVs=20 added to the leaf paths to carry the requested data. For GET elements that=20 fail, instead of the DATARAW TLV there will be a RESULT TLV. For a SET response, each DATARAW TLV in the original request will be=20 replace with a RESULT TLV in the response. If the request was for Ack-fail, then only those items which failed will appear in the response. If the request was for ack-all, then all elements=20 of the request will appear in the response with RESULT TLVs. A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 byte)=20 value. The defined values are 0 =3D success 1 =3D no such object 2 =3D permission denied 3 =3D invalid value (the dataraw could not validly be stored in the field) 4 =3D invalid array creation (when the subscript in an array create = is not=20 allowed) 255 =3D unspecified error (for when the FE can not decide what went wrong) We may need a few more values to cover other errors. Note that if a SET request with a structure in a DATARAW is issued, and=20 some field in the structure is invalid, the FE will not attempt to indicate=20 which field was invalid, but rather will indicate that the operation failed. Note further that if there are multiple errors in a single leaf path-data /=20 DATARAW, the FE can select which error it chooses to return. So if a=20 DATARAW for a SET of a structure attempts to write one field which is read=20 only, and attempts to set another field to an invalid value, the FE can=20 return whatever error it likes. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 13 15:34:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsn07-0001Te-28 for forces-archive@megatron.ietf.org; Wed, 13 Jul 2005 15:34: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 PAA14550 for ; Wed, 13 Jul 2005 15:34:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsnSY-0008Nd-Qh for forces-archive@IETF.ORG; Wed, 13 Jul 2005 16:04: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 <2.010A5D57@cherry.ease.lsoft.com>; Wed, 13 Jul 2005 15:34:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78994948 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Jul 2005 15:33:51 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 13 Jul 2005 15:33:51 -0400 Received: from [162.84.111.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11400274; Wed, 13 Jul 2005 15:33:50 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E05F970D1@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.20050713153003.02fd9958@localhost> Date: Wed, 13 Jul 2005 15:33:47 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Result TLV Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05F970D1@orsmsx408> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e I would expect there to be path-data at least some of the time. Assuming abbreviated responses (which are probably the norm) then for success it might suffice to just have one Result TLV, with no path-data. I had not thought about allowing that. If there are errors, there must at least be the path-data (possibly several nested path-data TLVs) that identify the target of the operation which failed, to provide context for the error code in the Result TLV. (Remember that there can be multiple path-data in the request, so the CE needs to know which thing failed.. If we are in the try-all-operations mode, then at least each operation which failed will need its path-data. And if we instead use verbose responses, then I expect the response to have all the path-data from the request, with result TLVs for each one indicating success or failure. Basically, I am just putting the Result-TLV into the path-data where the data-raw would have gone. Yours, Joel At 12:30 PM 7/13/2005, Khosravi, Hormuzd M wrote: >Again a reasonable and simple approach to provide the Results. > >To put some more context around it, is this how it would look like in a >Config Response message? > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = LFB select | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (SET-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (DEL-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Pls do clarify, No path-data tlv in this format? > >Thanks >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Thursday, June 30, 2005 12:04 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Result TLV > >The following is what I suggest for handling results of operations. > >SET and GET Requests do not have result information (they are requests). >SET and GET Responses have result information. >SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. > >For a GET responses, individual gets which succeed will have DATARAW >TLVs >added to the leaf paths to carry the requested data. For GET elements >that >fail, instead of the DATARAW TLV there will be a RESULT TLV. > >For a SET response, each DATARAW TLV in the original request will be >replace with a RESULT TLV in the response. >If the request was for Ack-fail, then only those items which failed will > >appear in the response. If the request was for ack-all, then all >elements >of the request will appear in the response with RESULT TLVs. > >A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 >byte) >value. >The defined values are > 0 = success > 1 = no such object > 2 = permission denied > 3 = invalid value (the dataraw could not validly be stored in the >field) > 4 = invalid array creation (when the subscript in an array create is >not >allowed) > 255 = unspecified error (for when the FE can not decide what went >wrong) > >We may need a few more values to cover other errors. >Note that if a SET request with a structure in a DATARAW is issued, and >some field in the structure is invalid, the FE will not attempt to >indicate >which field was invalid, but rather will indicate that the operation >failed. >Note further that if there are multiple errors in a single leaf >path-data / >DATARAW, the FE can select which error it chooses to return. So if a >DATARAW for a SET of a structure attempts to write one field which is >read >only, and attempts to set another field to an invalid value, the FE can >return whatever error it likes. > >Yours, >Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 14 00:58:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsvnx-00084u-Vv for forces-archive@megatron.ietf.org; Thu, 14 Jul 2005 00:58: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 AAA10501 for ; Thu, 14 Jul 2005 00:58:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DswGV-0006rC-Q0 for forces-archive@IETF.ORG; Thu, 14 Jul 2005 01:28: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 <23.010A6546@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 0:58:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79030929 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 00:58:35 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 00:58:34 -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 j6E4wYhv024840; Thu, 14 Jul 2005 04:58:34 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 j6E4wYVV018966; Thu, 14 Jul 2005 04:58:34 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 M2005071321583314494 ; Wed, 13 Jul 2005 21:58: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); Wed, 13 Jul 2005 21:58:33 -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] Result TLV thread-index: AcWH4dG0j3rmLEQQQ6+WEjNiKsY7mAATAG/Q X-OriginalArrivalTime: 14 Jul 2005 04:58:33.0795 (UTC) FILETIME=[AFBA3130:01C58830] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05FCC439@orsmsx408> Date: Wed, 13 Jul 2005 21:58:30 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Result TLV Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Thanks for the clarification, Joel! That's completely fine with me. So it looks like.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (SET-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-data TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (DEL-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-data TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is more granular and makes sense to me (what I would have expected to see in the response). Therefore I asked for the clarification below. Regards Hormuzd -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 Sent: Wednesday, July 13, 2005 12:34 PM To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM Subject: RE: [FORCES] Result TLV I would expect there to be path-data at least some of the time. Assuming abbreviated responses (which are probably the norm) then for=20 success it might suffice to just have one Result TLV, with no path-data. I=20 had not thought about allowing that. If there are errors, there must at least be the path-data (possibly several=20 nested path-data TLVs) that identify the target of the operation which=20 failed, to provide context for the error code in the Result TLV. (Remember=20 that there can be multiple path-data in the request, so the CE needs to=20 know which thing failed.. If we are in the try-all-operations mode, then at least each operation=20 which failed will need its path-data. And if we instead use verbose responses, then I expect the response to have=20 all the path-data from the request, with result TLVs for each one=20 indicating success or failure. Basically, I am just putting the Result-TLV into the path-data where the data-raw would have gone. Yours, Joel At 12:30 PM 7/13/2005, Khosravi, Hormuzd M wrote: >Again a reasonable and simple approach to provide the Results. > >To put some more context around it, is this how it would look like in a >Config Response message? > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D LFB select | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (SET-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (DEL-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Pls do clarify, No path-data tlv in this format? > >Thanks >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Thursday, June 30, 2005 12:04 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Result TLV > >The following is what I suggest for handling results of operations. > >SET and GET Requests do not have result information (they are requests). >SET and GET Responses have result information. >SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. > >For a GET responses, individual gets which succeed will have DATARAW >TLVs >added to the leaf paths to carry the requested data. For GET elements >that >fail, instead of the DATARAW TLV there will be a RESULT TLV. > >For a SET response, each DATARAW TLV in the original request will be >replace with a RESULT TLV in the response. >If the request was for Ack-fail, then only those items which failed will > >appear in the response. If the request was for ack-all, then all >elements >of the request will appear in the response with RESULT TLVs. > >A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 >byte) >value. >The defined values are > 0 =3D success > 1 =3D no such object > 2 =3D permission denied > 3 =3D invalid value (the dataraw could not validly be stored in the >field) > 4 =3D invalid array creation (when the subscript in an array create is >not >allowed) > 255 =3D unspecified error (for when the FE can not decide what went >wrong) > >We may need a few more values to cover other errors. >Note that if a SET request with a structure in a DATARAW is issued, and >some field in the structure is invalid, the FE will not attempt to >indicate >which field was invalid, but rather will indicate that the operation >failed. >Note further that if there are multiple errors in a single leaf >path-data / >DATARAW, the FE can select which error it chooses to return. So if a >DATARAW for a SET of a structure attempts to write one field which is >read >only, and attempts to set another field to an invalid value, the FE can >return whatever error it likes. > >Yours, >Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 14 07:36:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt20z-0004fn-TU for forces-archive@megatron.ietf.org; Thu, 14 Jul 2005 07:36: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 HAA01059 for ; Thu, 14 Jul 2005 07:36:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt2Ta-0005vI-7n for forces-archive@IETF.ORG; Thu, 14 Jul 2005 08:06:03 -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.010A6758@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 7:36:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79081835 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 07:36:25 -0400 Received: from 195.212.29.136 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 07:36:24 -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 j6EBaN5T329556 for ; Thu, 14 Jul 2005 11:36:24 GMT 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/VER6.6) with ESMTP id j6EBaNKN142706 for ; Thu, 14 Jul 2005 12:36:24 +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 j6EBaNrc002443 for ; Thu, 14 Jul 2005 12:36:23 +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 j6EBaN4Z002434; Thu, 14 Jul 2005 12:36:23 +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 NAA58522; Thu, 14 Jul 2005 13:36:22 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1118434140.53.0.769267160607.issue55@mip4.org> <6.2.1.2.0.20050610205518.02d91f98@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Robert Haas Message-ID: <42D64E2B.9050201@zurich.ibm.com> Date: Thu, 14 Jul 2005 13:36:11 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue55] Execution text replacement Comments: cc: tracker-forces@mip4.org To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050610205518.02d91f98@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Here is some text to resolve the issue wrt "fast recovery" of pending transactions across association tear-down and reestablishment. Please comment. Associations may be taken down either due to heartbeat timeout, or an explicit teardown message. The first question is: what do we do with all the state in the FE after the association is down ? 1) if it is due to a heartbeat timeout, then the "CE failover and restart policy" attribute in the FE Protocol LFB indicates if the FE should continue operation even though the CE is gone. 2) if the association was taken down explicitely with a teardown message, then we can assume that operation of the FE must be stopped. OK ? The next question is: what do we do with all the "old" FE state when the association is reestablished ? 1) if the association was taken down explicitely, then all the "old" state in the FE is gone. The CE must restore all necessary state. OK ? 2) if the association timed out, then unless the FE Protocol LFB keeps a state that indicates how the last association went down, the FE cannot remember if association was lost due to timeout or explicit message, hence the same treatment as 1) above is expected. If we agree on the above, then a new association means starting from scratch (all state in the FE must first be restored by the CE) so that no "fast" recovery of a transaction in intermediate state can occur. OK ? So we would have to change the text in section 3.3.1.1.1.3 "Recovery": "When the associations are re-established, the CE will discover a transaction in an intermediate state." and instead say: "Whenever an association is established (whether the association is new or it is recovered from a previous association), the CE MUST NOT expect that any state from the previous association has been kept in the FE." OK ? Regards, -Robert From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 14 07:52:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt2GP-0003y7-E0 for forces-archive@megatron.ietf.org; Thu, 14 Jul 2005 07:52:25 -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 HAA01965 for ; Thu, 14 Jul 2005 07:52:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt2ix-0006Nb-M3 for forces-archive@IETF.ORG; Thu, 14 Jul 2005 08:21: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 <23.010A67D3@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 7:52:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79082477 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 07:52:19 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 07:52:19 -0400 Received: from [162.84.111.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11409014; Thu, 14 Jul 2005 07:52:18 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1118434140.53.0.769267160607.issue55@mip4.org> <6.2.1.2.0.20050610205518.02d91f98@localhost> <42D64E2B.9050201@zurich.ibm.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.20050714074414.030cc650@localhost> Date: Thu, 14 Jul 2005 07:52:10 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue55] Execution text replacement Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42D64E2B.9050201@zurich.ibm.com> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 I disagree with the last part. The FE clearly can remember if it has been reset or not. Let me separate the question into two parts. The first part, which we discussed on the call, is what happens to pending transactions that have not been fully committed when the FE loses association with the CE. In my opinion, no matter what the reason for the lose of association, such transactions MUST be unwound. The second part is what state / operation the FE is permitted to retain when it does not have an association. Robert distinguishes three cases: 1) When the FE is switching to the backup CE, 2) When the FE has lost heartbeat with the CE, but does not have a backup, and 3) When the association was explicitly terminated by the CE. Clearly, when switching from primary to secondary CE, the FE should keep its state, and keep forwarding packets according to that state, until the new CE tells it otherwise. The new CE may or may not already have knowledge of that state. Even if it does not have such knowledge, it can read the state from the FE. So, the question is what the FE "should" do when it loses association and does not have a backup CE or can not associate with it. My answer is roughly "what ever it wants". There is no reason for the FE to delete its state. After all, we permit FEs with fixed state (or fixed portions of state), so whenever it does associate the CE will need to fetch that state anyway. In terms of practical effect, once the CE is no longer advertising for the FE, after a time the other folks will stop sending it packets. Until routing has expired the information about the FE, it is better for it to keep forwarding packets according to the old table, rather than black-holing them. So for at least 90 seconds, it should keep operating. However, if a particular FE implementation has a reason to clear state and bring down interfaces, that should not be prohibited. Yours, Joel At 07:36 AM 7/14/2005, Robert Haas wrote: >Here is some text to resolve the issue wrt "fast recovery" of pending >transactions across association tear-down and reestablishment. Please comment. > >Associations may be taken down either due to heartbeat timeout, or an >explicit teardown message. > >The first question is: what do we do with all the state in the FE after >the association is down ? >1) if it is due to a heartbeat timeout, then the "CE failover and restart >policy" attribute in the FE Protocol LFB indicates if the FE should >continue operation even though the CE is gone. >2) if the association was taken down explicitely with a teardown message, >then we can assume that operation of the FE must be stopped. OK ? > >The next question is: what do we do with all the "old" FE state when the >association is reestablished ? >1) if the association was taken down explicitely, then all the "old" state >in the FE is gone. The CE must restore all necessary state. OK ? >2) if the association timed out, then unless the FE Protocol LFB keeps a >state that indicates how the last association went down, the FE cannot >remember if association was lost due to timeout or explicit message, hence >the same treatment as 1) above is expected. > >If we agree on the above, then a new association means starting from >scratch (all state in the FE must first be restored by the CE) so that no >"fast" recovery of a transaction in intermediate state can occur. > >OK ? > >So we would have to change the text in section 3.3.1.1.1.3 "Recovery": >"When the associations are re-established, the CE will discover a >transaction in an intermediate state." and instead say: "Whenever an >association is established (whether the association is new or it is >recovered from a previous association), the CE MUST NOT expect that any >state from the previous association has been kept in the FE." > >OK ? > >Regards, >-Robert From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 14 08:32:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt2tT-0007Me-T1 for forces-archive@megatron.ietf.org; Thu, 14 Jul 2005 08:32: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 IAA04571 for ; Thu, 14 Jul 2005 08:32:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3Lz-0007ip-Ot for forces-archive@IETF.ORG; Thu, 14 Jul 2005 09:02: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 <6.010A6852@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 8:32:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79084243 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 08:32:21 -0400 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 08:32:21 -0400 Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1Dt2sw-00078M-Vg; Thu, 14 Jul 2005 13:32:21 +0100 Received: from s182-3.nomadic.bris.ac.uk ([137.222.182.3] helo=een5134.een.bris.ac.uk) by isis.bris.ac.uk with esmtp (Exim 4.51) id 1Dt2s9-0003Lk-UF; Thu, 14 Jul 2005 13:31:30 +0100 References: <1118434140.53.0.769267160607.issue55@mip4.org> <6.2.1.2.0.20050610205518.02d91f98@localhost> <42D64E2B.9050201@zurich.ibm.com> <6.2.1.2.0.20050714074414.030cc650@localhost> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- Approved-By: Alistair Munro Message-ID: <7957B4FE7534BBC0BB02DECA@[10.0.0.69]> Date: Thu, 14 Jul 2005 13:31:34 +0100 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: [issue55] Execution text replacement Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050714074414.030cc650@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Hi All, Now that we are back on transactionality again... > I disagree with the last part. > The FE clearly can remember if it has been reset or not. Yes, and if not reset then it can remember what its configuration is. > Let me separate the question into two parts. > The first part, which we discussed on the call, is what happens to > pending transactions that have not been fully committed when the FE loses > association with the CE. In my opinion, no matter what the reason for > the lose of association, such transactions MUST be unwound. We could go for finer granularity but that just makes recovery a real pain. Let's go for this simple level of rollback. Do we also say that it is the CE that is the recovery master? Can the FE initiate the rollback/recovery? I agree with the rest of Joel's comments; furthermore, Robert wrote: >> Associations may be taken down either due to heartbeat timeout, or an >> explicit teardown message. This suggests an ordered world out there. Maybe the heartbeat takes care of most disasters, but it could fail too. The recovery model should provide for a failure where the loss of association is not guaranteed to be reported. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 14 09:51:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt484-000393-WD for forces-archive@megatron.ietf.org; Thu, 14 Jul 2005 09:51: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 JAA09661 for ; Thu, 14 Jul 2005 09:51:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4ah-0001xi-1X for forces-archive@IETF.ORG; Thu, 14 Jul 2005 10:21: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 <8.010A67BE@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 9:51:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79087659 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 09:51:54 -0400 Received: from 195.212.29.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 09:51:53 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6EDpqSk345170 for ; Thu, 14 Jul 2005 13:51:52 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6EDpqKN253366 for ; Thu, 14 Jul 2005 14:51:52 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j6EDpq1M021478 for ; Thu, 14 Jul 2005 14:51:52 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j6EDppJh021448; Thu, 14 Jul 2005 14:51:52 +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 PAA60856; Thu, 14 Jul 2005 15:51:51 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1118434140.53.0.769267160607.issue55@mip4.org> <6.2.1.2.0.20050610205518.02d91f98@localhost> <42D64E2B.9050201@zurich.ibm.com> <6.2.1.2.0.20050714074414.030cc650@localhost> <7957B4FE7534BBC0BB02DECA@[10.0.0.69]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.uk.ibm.com id j6EDpqSk345170 Approved-By: Robert Haas Message-ID: <42D66DF6.2010008@zurich.ibm.com> Date: Thu, 14 Jul 2005 15:51:50 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue55] Execution text replacement Comments: To: Alistair Munro To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <7957B4FE7534BBC0BB02DECA@[10.0.0.69]> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Alistair Munro wrote: > Hi All, > > Now that we are back on transactionality again... > >> I disagree with the last part. >> The FE clearly can remember if it has been reset or not. > > > Yes, and if not reset then it can remember what its configuration is. Although the FE can remember what its configuration is between two=20 associations, the CE cannot make any assumption about this. So the CE=20 must check the configuration state of any newly associated FE. > >> Let me separate the question into two parts. >> The first part, which we discussed on the call, is what happens to >> pending transactions that have not been fully committed when the FE=20 >> loses >> association with the CE. In my opinion, no matter what the reason for >> the lose of association, such transactions MUST be unwound. > > > We could go for finer granularity but that just makes recovery a real=20 > pain. Let's go for this simple level of rollback. Do we also say that=20 > it is the CE that is the recovery master? Can the FE initiate the=20 > rollback/recovery? I agree that the FE MUST rollback by itself any unfinished transactions=20 whenever the association is lost. But what about this case: if the DONE-ACK (message from FE to CE to=20 signal that the FE has completed the transaction) is lost due to=20 association breakdown, the FE won't rollback anything (it just can't=20 know that the DONE-ACK message did not make it to the CE). But from the=20 CE viewpoint, it is unclear whether the transaction was completed. As the association is reestablished, the CE will have to figure out what=20 happened to that last transaction. Two ways of doing this: - fetch all necessary FE state and double-check, or - introduce an attribute in the FE Protocol LFB that indicates the ID of=20 the last completed transaction (from the FE viewpoint). The CE will read=20 this attribute as the association is reestablished. What do you think ? > > I agree with the rest of Joel's comments; furthermore, Robert wrote: > >>> Associations may be taken down either due to heartbeat timeout, or an >>> explicit teardown message. >> > > This suggests an ordered world out there. Maybe the heartbeat takes=20 > care of most disasters, but it could fail too. The recovery model=20 > should provide for a failure where the loss of association is not=20 > guaranteed to be reported. > Then I don't follow you: by definition, as association goes down either=20 because heartbeats are not received for a period of time, or the=20 teardown procedure was followed. The FSM does not consider any other=20 event as a cause to bring the association down. Regards, -Robert > Regards, > > Alistair > > --=20 > Alistair Munro, > Principal Engineer, U4EA Technologies Ltd. > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > E-mail: Alistair.Munro@u4eatech.com > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > +44-7974-922-442; > Fax: +44-117-373-6751 > Web: http://www.u4eatech.com > > --=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 Thu Jul 14 16:55:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtAjg-0003Mt-1Q for forces-archive@megatron.ietf.org; Thu, 14 Jul 2005 16:55: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 QAA10794 for ; Thu, 14 Jul 2005 16:55:09 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtBCA-0001Sm-3t for forces-archive@IETF.ORG; Thu, 14 Jul 2005 17:24: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 <1.010A6E98@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 16:54:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79126956 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 16:54:56 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 16:54:56 -0400 Received: from [12.58.128.11] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11416518 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 16:54:55 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1118434140.53.0.769267160607.issue55@mip4.org> <6.2.1.2.0.20050610205518.02d91f98@localhost> <42D64E2B.9050201@zurich.ibm.com> <6.2.1.2.0.20050714074414.030cc650@localhost> <7957B4FE7534BBC0BB02DECA@[10.0.0.69]> <42D66DF6.2010008@zurich.ibm.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.20050714131908.02e2eb10@localhost> Date: Thu, 14 Jul 2005 16:54:47 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue55] Execution text replacement To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42D66DF6.2010008@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Given that the CE has no way to know what may have happened to the FE since they were last talking, the CE should always reload the FE state when an association is established by talking to the FE. Yours, Joel At 09:51 AM 7/14/2005, you wrote: >I agree that the FE MUST rollback by itself any unfinished transactions >whenever the association is lost. >But what about this case: if the DONE-ACK (message from FE to CE to signal >that the FE has completed the transaction) is lost due to association >breakdown, the FE won't rollback anything (it just can't know that the >DONE-ACK message did not make it to the CE). But from the CE viewpoint, it >is unclear whether the transaction was completed. > >As the association is reestablished, the CE will have to figure out what >happened to that last transaction. Two ways of doing this: >- fetch all necessary FE state and double-check, or >- introduce an attribute in the FE Protocol LFB that indicates the ID of >the last completed transaction (from the FE viewpoint). The CE will read >this attribute as the association is reestablished. > >What do you think ? From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 14 18:26:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtCA8-0002ti-MW for forces-archive@megatron.ietf.org; Thu, 14 Jul 2005 18:26: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 SAA14051 for ; Thu, 14 Jul 2005 18:26:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtCcl-0004gR-8m for forces-archive@IETF.ORG; Thu, 14 Jul 2005 18:56: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.010A7028@cherry.ease.lsoft.com>; Thu, 14 Jul 2005 18:26:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79131966 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 14 Jul 2005 18:26:29 -0400 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 14 Jul 2005 18:26:29 -0400 Received: from seis.bris.ac.uk ([137.222.10.93]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1DtC9v-0001Ag-N0; Thu, 14 Jul 2005 23:26:28 +0100 Received: from s182-6.nomadic.bris.ac.uk ([137.222.182.6] helo=een5134.een.bris.ac.uk) by seis.bris.ac.uk with esmtp (Exim 4.51) id 1DtC8y-00001p-VY; Thu, 14 Jul 2005 23:25:31 +0100 References: <1118434140.53.0.769267160607.issue55@mip4.org> <6.2.1.2.0.20050610205518.02d91f98@localhost> <42D64E2B.9050201@zurich.ibm.com> <6.2.1.2.0.20050714074414.030cc650@localhost> <7957B4FE7534BBC0BB02DECA@[10.0.0.69]> <42D66DF6.2010008@zurich.ibm.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- Approved-By: Alistair Munro Message-ID: <4F1E514A9B3A7EFC00B9F64C@[192.168.0.4]> Date: Thu, 14 Jul 2005 23:25:29 +0100 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: [issue55] Execution text replacement Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42D66DF6.2010008@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Hi Robert, Thank you for your response. Apologies for a long reply, which may not make much sense... > Although the FE can remember what its configuration is between two > associations, the CE cannot make any assumption about this. So the CE > must check the configuration state of any newly associated FE. I would like some time to think about this, but I am sure we have gone through the thought processes before and please remind me of the outcome if I'm repeating the obvious. The FE may have valid next-hop and prefix tables for 10000's of routes and hundred of interfaces. Given an arbitrary disconnect between the CE and FE, what should we do to reconcile any differences? Probably transactional recovery is not enough but it might be the best case for brief interruptions. A newly associated FE (a blade I just plugged in for example) might have no state. But it has no transactions to recover. >> >>> Let me separate the question into two parts. >>> The first part, which we discussed on the call, is what happens to >>> pending transactions that have not been fully committed when the FE >>> loses >>> association with the CE. In my opinion, no matter what the reason for >>> the lose of association, such transactions MUST be unwound. >> >> >> We could go for finer granularity but that just makes recovery a real >> pain. Let's go for this simple level of rollback. Do we also say that >> it is the CE that is the recovery master? Can the FE initiate the >> rollback/recovery? > > I agree that the FE MUST rollback by itself any unfinished transactions > whenever the association is lost. > But what about this case: if the DONE-ACK (message from FE to CE to > signal that the FE has completed the transaction) is lost due to > association breakdown, the FE won't rollback anything (it just can't know > that the DONE-ACK message did not make it to the CE). But from the CE > viewpoint, it is unclear whether the transaction was completed. I didn't mean that the FE could autonomously roll transactions back. Recovery processes have a master and the assumption of shared state is the worst-case knowledge of the master - I'm assuming this is the CE but am I wrong? If the CE is the master then all the FE can do is tell it that it has uncommitted transaction IDs (no commit request received), or committed transaction IDs (either acknowledged - it did them, or unacknowledged - it doesn't know). If the FE sent DONE-ACKs then it knows what it did - but if the CE has no recollection of receiving the DONE-ACK then, in principle, it doesn't know what happened. In that case we should go for presumed-abort, rolling back to the last confirmed transaction. But this will sometimes be inconsistent with recently received routing table/adjacency updates. To avoid doubt, I'm confident that the protocol is good. It is the actions that may need to be examined. We should possibly aim to give estimates of uncertainty? Apart from this, I agree with what you say, but this is the usual situation with transactional protocols - the certainty is only the last confirmed action that was executed. By way of an opinion on how I think it works, I believe the protocol gives rollback responsibility to the CE. The FE can go for presumed abort, i.e. it notifies the CE of incomplete transactions and undoes them if the CE knows it received confirmation of them having been done (even if the FE did them). Recoveries are usually acknowledged so this should be safe even if the association fails during the recovery - as it tends to do. As noted above, I thought the handshaking was OK so far, but I'll check again. > > As the association is reestablished, the CE will have to figure out what > happened to that last transaction. Two ways of doing this: > - fetch all necessary FE state and double-check, or > - introduce an attribute in the FE Protocol LFB that indicates the ID of > the last completed transaction (from the FE viewpoint). The CE will read > this attribute as the association is reestablished. > > What do you think ? You are starting to define a more complex recovery protocol. I think we must minimise the complexity but I have to admit I don't know how right now. >> >> This suggests an ordered world out there. Maybe the heartbeat takes >> care of most disasters, but it could fail too. The recovery model >> should provide for a failure where the loss of association is not >> guaranteed to be reported. >> > Then I don't follow you: by definition, as association goes down either > because heartbeats are not received for a period of time, or the teardown > procedure was followed. The FSM does not consider any other event as a > cause to bring the association down. Yes, this is what has been defined but the definition is possibly too optimistic. Busy CEs may not deliver heartbeats. My position is that there is *no* certainty in this kind of system, only minimising the extent and duration of inconsistency. It's not a flaw in the concept but maybe it is a guideline for users about how much they can load their CEs? If you got this far, thanks for reading this long and probably confusing message! Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Fri Jul 15 08:33:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPO3-0005yL-Ve for forces-archive@megatron.ietf.org; Fri, 15 Jul 2005 08:33: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 IAA00985 for ; Fri, 15 Jul 2005 08:33:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtPqs-0006wq-Cz for forces-archive@IETF.ORG; Fri, 15 Jul 2005 09:03: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 <22.010A7A40@cherry.ease.lsoft.com>; Fri, 15 Jul 2005 8:33:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79216901 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Jul 2005 08:33:44 -0400 Received: from 195.212.29.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 15 Jul 2005 08:33:44 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6FCXdSk043734 for ; Fri, 15 Jul 2005 12:33:39 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6FCXdD0264146 for ; Fri, 15 Jul 2005 13:33:39 +0100 Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j6FCXdkk018035 for ; Fri, 15 Jul 2005 13:33:39 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j6FCXct6018026; Fri, 15 Jul 2005 13:33:38 +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 OAA57060; Fri, 15 Jul 2005 14:33:38 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6.2.1.2.0.20050705195058.02f3d148@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.uk.ibm.com id j6FCXdSk043734 Approved-By: Robert Haas Message-ID: <42D7AD1D.9010209@zurich.ibm.com> Date: Fri, 15 Jul 2005 14:33:33 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: New model DRAFT Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050705195058.02f3d148@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: quoted-printable Joel, Great work ! I tried to read the whole draft in one shot to detect=20 discrepancies and so on. Here is a first list of specific comments. Regards, -Robert [Editorial] Sec 3.1 FE Capability Model and State Model: The FE capability and the FE state are both represented by two levels.=20 The text says this only for the FE State model ? [Technical] Sec 3.3.2 Configuring the LFB Topology Note that LFB topology constraints are also expressed by the Packet=20 Types on ports (output-input matching) and required metadata (an LFB may=20 require certain metadata, hence an upstream LFB must produce it). [Technical] Sec 4.7.4 Element to Define LFB Operational Attributes =93While the capabilities will frequently indicate this non-existence, CE= s=20 may attempt to reference non-existent or non-permitted attributes=20 anyway. The FORCES protocol mechanisms should include appropriate error=20 indicators for this case=94. This is still missing in the protocol. We need special Result-TLV codes=20 for this. [Technical] Sec 4.7.5 Element to Define LFB Capability=20 Attributes In the example (copied below), nothing except the synopsis relates=20 limitBar to the bar attribute. I'd like to have sth so that the machine=20 can figure out from the LFB what is the maximum size of some the LFB=20 arrays (forwarding table, etc). So we would need sth comparable to the=20 events semantics (i.e., greater, lower, etc), and a field that maps the=20 capability to its element (if applicable). limitBar Maximum value of the "bar" attribute. uint16 [Editorial] Sec 4.7.6: incomplete sentence end of 2nd paragraph =93In a derived LFB (i.e. one=20 with a element) the baseID must not.=94 [Technical] 4.8 LFB Properties This is still missing in the protocol. We need special Result-TLV codes=20 to signal that the writing of a property element failed. [Editorial] (check in the entire document) typo OctetSting, or octetstring. [Technical] Sec 5.5. FE Attributes and Capabilities In the of the FEObject (copied below), LFBTopology is the=20 current topology of LFBs in the FE, but the synopsis says :the table of=20 known Topologies" ? If the FE has a list of allowed "fixed" working topologies, shouldn't=20 this be a field in the , i.e., an array of arrays ? Core LFB: FE Object 1.0 LFBTopology the table of known Topologies LFBLinkType [Technical] Sec 7.7. Using the FE model in the ForCES Protocol "Among the seven types of payload information the ForCES protocol=20 carries between CEs and FEs, the FE model covers all of them except item=20 1), which concerns the inter-FE topology. The FE model focuses on the=20 LFB and LFB topology within a single FE. Since the information related=20 to item 1) requires global knowledge about all of the FEs and their=20 inter-connection with each other, this exchange is part of the ForCES=20 base protocol instead of the FE model." I think that as the FEObject has an array of FEConfiguredNeighborType,=20 exchange (1) to dicsover the inter-FE topology consists simply of=20 reading this LFB attribute. So I would not say that (1) is "part of the=20 ForCES base protocol instead of the FE model." . Also check in Fig. 9. [Technical] Sec 7.2.7.2 FE Capability Declarations " FEs will have many types of limitations. Some of the limitations must=20 be expressed to the CEs as part of the capability model. The CEs must be=20 able to query these capabilities on a per-FE basis. Examples: Metadata=20 passing capabilities of the FE. Understanding these capabilities will=20 help the CE to evaluate the feasibility of LFB topologies, and hence to=20 determine the availability of certain services." I think that metadata is sth LFB-specific and does not belong to the FE=20 capabilities. The FEObject does not have any attribute about this. [Technical] 7.4 LFB Capability Declarations "Also, the LFB class definitions will probably contain very few=20 quantitative limits (e.g., size of tables), since these limits are=20 typically imposed by the implementation. Therefore, quantitative=20 limitations should always be expressed by capability arguments." Although both capabilities now defined for the FEObject are optional, I=20 expect that we will have LFB classes with capabilities that are=20 mandatory to define: for instance, the maximum routing table size should=20 be a capability that every vendor must specify. [Technical] Sec 7.6.7.6 LFB Attribute Manipulation "(Editor's note: It remains an open issue as to whether or not other=20 methods are needed in addition to "get attribute" and "set attribute"=20 (such as multi-attribute transactions). If the answer to that question=20 is yes, it is not clear whether such methods should be supported by the=20 FE model itself or the ForCES protocol.)" Multi-attribute setting or getting is in fact allowed by the protocol.=20 If the FE has a problem with it, it will return an error (for instance,=20 two attributes that are set to mutually incompatible values) [Technical] Sec 8.3 Capabilities "The capability information for this LFB includes whether the underlying=20 interface is operational". The example XML is: OperationalState whther the port over all is operational PortStatusValues I doubt that interface state should belong to the capabilities. It is an=20 attribute, no ? Joel M. Halpern wrote: > I have completed an editing pass on the model document. > I have added aliases, properties, and events. > I have added an example to try to explain how some of this works. > > Jamal has very helpfully posted the draft at: > ftp://ftp.znyx.com/users/hadi/private/forces/ > > Note, this is the word document. It has change tracking turned on, so=20 > you should easily be able to tell what I did. > Ellen will be working this document over when she gets back from=20 > vacation, and we will submit that to the I-D respository. > > The XML Schema passes XMLSpy's validity test. The two LFBs validate=20 > against that schema. > I believe the example is indented badly. Sorry. I can not get word to=20 > cooperate on it. > > One note on the Schema. I do not have the tools to usefully validate=20 > the Key / KeyRef declarations. And while my tool uses them, I think it=20 > uses them wrong because I get mysterious errors. If someone who=20 > understands Key / KeyRef could look at them, I am happy to fix them up. > > I am sure there are many other errors. > And probably places that need clarification even if they are not wrong. > > Please, Please, Please read the draft. Send comments. > > Yours, > Joel M. Halpern > > --=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 Fri Jul 15 10: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 1DtQmG-0000TW-8N for forces-archive@megatron.ietf.org; Fri, 15 Jul 2005 10: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 KAA07246 for ; Fri, 15 Jul 2005 10:02:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtRF5-0001X7-Ge for forces-archive@IETF.ORG; Fri, 15 Jul 2005 10:32: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 <3.010A7AB8@cherry.ease.lsoft.com>; Fri, 15 Jul 2005 10:02:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79221813 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Jul 2005 10:02:49 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 15 Jul 2005 10:02:49 -0400 Received: from [12.58.128.11] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11427194; Fri, 15 Jul 2005 10:02:49 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050630104547.02f12a50@localhost> <002e01c58239$6f9500f0$1f12fea9@wwm1> <6.2.1.2.0.20050706160833.02dd3310@localhost> <003f01c5829b$656d2280$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050706223256.02dcd900@localhost> <072601c58940$af810e30$1152010a@Necom.hzic.edu.cn> 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.20050715100020.02e60210@localhost> Date: Fri, 15 Jul 2005 10:02:48 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <072601c58940$af810e30$1152010a@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de This looks good to me. My only quibble (minor difference) is with the description that the identifier portion of the meta-data ILV is assigned by the model. We have not worked this out, but I think that the identifiers are probably going to end up assigned by the CE. (The implication of this is that if one CE takes over for another, it may have to do some analysis to get the meanings for the meta-data identifiers. But it should be simple to find the LFBs where the meta-data is created, and determine what ID is configured to be used for it. And this needs to be described somewhere in either the model or the protocol document. I think it will go in the meta-data portion of the model draft.) Yours, Joel At 09:25 AM 7/15/2005, Wang,Weiming wrote: >Hi all, > >I tried to compose a text for the update of the redirect message part in >the attachment, based on our current discussions . Pls send coments on. > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >To: >Sent: Thursday, July 07, 2005 10:38 AM >Subject: Re: [issue32] Packet Redirect > > > > There is a whole section on meta-data in the model document. > > I would expect most meta-data fields to be 32 bits. > > The CE can choose to use a meta-data classifier and multiple meta-data > > fields in order to steer the packet to the right LFB. And the CE will > know > > what meta-data field the LFB will use for selecting among its ports. > > > > > > This relates to a larger question for the list... > > We NEED an LFB library. > > Please! > > To do this, we need folks to actually write definitions of LFBs. > > (I think we have an editor who is likely to be willing to pull things > > together. At least I hope so.) > > There are a lot of LFBs that need writing. > > If this WG doesn't start producing them, it won't happen. > > > > > > To get back to your question Weiming, given a set of LFB definitions and > > the meta-data they use, I can better specify what the CE will send / > > receive. But in an abstract sense, since it will be information flowing > > between the redirect LFB and the eventual interface LFB, the way the model > > prescribes to carry that information is as meta-data. This is the same > > meta-data that will need, for example, to come out of longest-prefix-match > > and next-hop resolution LFBs. After all, they need to be able to direct > > packets to be shipped out specific interfaces, with specific headers, etc. > > > > Yours, > > Joel > > > > At 10:27 PM 7/6/2005, Wang,Weiming wrote: > > >A very simple question then, how many bits we then can assign to the > > >meta-data like the port number ? > > > > > >thanks, > > >weiming > > > > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >To: "Weiming Wang" ; > > > >Sent: Thursday, July 07, 2005 4:09 AM > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > After some discussion, the operational data may be simpler than I > had been > > > > thinking. > > > > We can simply attach (in some reasonable TLV format) all the meta-data. > > > > So packets from the CE come with meta-data, and the CE gets all the > > > > meta-data from the FE associated with a packet. > > > > That ensures that all the necessary information is available, without > > > > making the redirect LFBs complex. > > > > > > > > Yours, > > > > Joel > > > > > > > > At 10:44 AM 7/6/2005, Weiming Wang wrote: > > > > >Joel, > > > > > > > > > >I tend to agree with your idea below except the index. Could you give > > > > >more details on its necessity? Thanks. > > > > >As a result, the agreeable format to me seems like: > > > > > > > > > >Redirect TLV, whith contains > > > > > LFB class ID > > > > > LFB instance ID > > > > > operation TLV (REPORT), which contains Path-Data > > > > > Packet TLV > > > > > > > > > >We further define that that Path-Data should supply enough > information > > > for > > > > >the followed packet. At least it should include information about the > > > port > > > > >number the redirect packet is input(sink LFB) or is output (source > LFB), > > > > >and the redirect packet type. How this is defined is left to model > where > > > > >redirect LFBs and the attributes are defined. > > > > > > > > > >We need to solve this a little sooner. > > > > > > > > > >thoughts? > > > > > > > > > >Thanks, > > > > >Weiming > > > > > > > > > >----- Original Message ----- > > > > >From: "Joel M. Halpern" > > > > >Subject: Redirect Message > > > > > > > > > > > > > > > > Based on discussion, and based on my earlier message that specific > > > > > protocol > > > > > > messages may have different top level TLVs, here is a description > > > of the > > > > > > contents of a redirect message. > > > > > > > > > > > > A redirect message will contain a redirect TLV. > > > > > > A redirect TLV consists of three fixed fields, and meta-data TLV, > > > and the > > > > > > packet. > > > > > > The fixed fields are > > > > > > o the LFB Class ID of the redirect source or redirect sink LFB on > > > the FE > > > > > > associated with this packet > > > > > > o the LFB Instance ID of the redirect source or redirect sink > LFB on > > > > > the FE > > > > > > associated with this packet > > > > > > o an index within that LFB to identify configured properties of > the > > > packet. > > > > > > > > > > > > The meta-data TLV contains dynamic information needed by the FE or > > > CE to > > > > > > process the packet. This will need to be spelled out in more > > > detail. It > > > > > > may need to use path encoding. > > > > > > > > > > > > Following this will be the packet. > > > > > > > > > > > > Yours, > > > > > > Joel > > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jul 15 10:16:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQzI-0007Jw-Ag for forces-archive@megatron.ietf.org; Fri, 15 Jul 2005 10:16: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 KAA08718 for ; Fri, 15 Jul 2005 10:16:21 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtRS4-0001uB-GE for forces-archive@IETF.ORG; Fri, 15 Jul 2005 10:46: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 <5.010A7AD0@cherry.ease.lsoft.com>; Fri, 15 Jul 2005 10:16:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79222766 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Jul 2005 10:16:18 -0400 Received: from 219.150.144.124 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 15 Jul 2005 10:16:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [issue32] Packet Redirect Thread-Index: AcWJRpxd5oXxdFxRTr23dbgffAgKawAAGGrQ Approved-By: =?gb2312?B?vNa377j5?= Message-ID: <7A7A7A38134E244784EDAC428C538AE901F1329A@mail.ndsc.com.cn> Date: Fri, 15 Jul 2005 22:19:51 +0800 Reply-To: =?gb2312?B?vNa377j5?= Sender: Forwarding and Control Element Separation From: =?gb2312?B?vNa377j5?= Subject: =?gb2312?Q?=B4=F0=B8=B4:?= [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: quoted-printable I'm totally agree with Joel, in fact we are actually implementing this = and it works well. I think the control plane portion of forces should = assigned the port number according to the FE association sequence, and = the other meta data are determined by the model group.And I think the = force protocol should define how the LFB ID is defined by the arriving = of the association message. Fenggen Jia -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C215=C8=D5 22:03 =CA=D5=BC=FE=C8=CB: FORCES@PEACH.EASE.LSOFT.COM =D6=F7=CC=E2: Re: [issue32] Packet Redirect This looks good to me. My only quibble (minor difference) is with the description that the=20 identifier portion of the meta-data ILV is assigned by the model. We = have=20 not worked this out, but I think that the identifiers are probably going = to=20 end up assigned by the CE. (The implication of this is that if one CE takes over for another, it = may=20 have to do some analysis to get the meanings for the meta-data=20 identifiers. But it should be simple to find the LFBs where the = meta-data=20 is created, and determine what ID is configured to be used for it. And=20 this needs to be described somewhere in either the model or the protocol = document. I think it will go in the meta-data portion of the model = draft.) Yours, Joel At 09:25 AM 7/15/2005, Wang,Weiming wrote: >Hi all, > >I tried to compose a text for the update of the redirect message part = in=20 >the attachment, based on our current discussions . Pls send coments on. > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >To: >Sent: Thursday, July 07, 2005 10:38 AM >Subject: Re: [issue32] Packet Redirect > > > > There is a whole section on meta-data in the model document. > > I would expect most meta-data fields to be 32 bits. > > The CE can choose to use a meta-data classifier and multiple = meta-data > > fields in order to steer the packet to the right LFB. And the CE = will=20 > know > > what meta-data field the LFB will use for selecting among its ports. > > > > > > This relates to a larger question for the list... > > We NEED an LFB library. > > Please! > > To do this, we need folks to actually write definitions of LFBs. > > (I think we have an editor who is likely to be willing to pull = things > > together. At least I hope so.) > > There are a lot of LFBs that need writing. > > If this WG doesn't start producing them, it won't happen. > > > > > > To get back to your question Weiming, given a set of LFB definitions = and > > the meta-data they use, I can better specify what the CE will send / > > receive. But in an abstract sense, since it will be information = flowing > > between the redirect LFB and the eventual interface LFB, the way the = model > > prescribes to carry that information is as meta-data. This is the = same > > meta-data that will need, for example, to come out of = longest-prefix-match > > and next-hop resolution LFBs. After all, they need to be able to = direct > > packets to be shipped out specific interfaces, with specific = headers, etc. > > > > Yours, > > Joel > > > > At 10:27 PM 7/6/2005, Wang,Weiming wrote: > > >A very simple question then, how many bits we then can assign to = the > > >meta-data like the port number ? > > > > > >thanks, > > >weiming > > > > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >To: "Weiming Wang" ;=20 > > > >Sent: Thursday, July 07, 2005 4:09 AM > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > After some discussion, the operational data may be simpler than = I=20 > had been > > > > thinking. > > > > We can simply attach (in some reasonable TLV format) all the = meta-data. > > > > So packets from the CE come with meta-data, and the CE gets all = the > > > > meta-data from the FE associated with a packet. > > > > That ensures that all the necessary information is available, = without > > > > making the redirect LFBs complex. > > > > > > > > Yours, > > > > Joel > > > > > > > > At 10:44 AM 7/6/2005, Weiming Wang wrote: > > > > >Joel, > > > > > > > > > >I tend to agree with your idea below except the index. Could = you give > > > > >more details on its necessity? Thanks. > > > > >As a result, the agreeable format to me seems like: > > > > > > > > > >Redirect TLV, whith contains > > > > > LFB class ID > > > > > LFB instance ID > > > > > operation TLV (REPORT), which contains Path-Data > > > > > Packet TLV > > > > > > > > > >We further define that that Path-Data should supply enough=20 > information > > > for > > > > >the followed packet. At least it should include information = about the > > > port > > > > >number the redirect packet is input(sink LFB) or is output = (source=20 > LFB), > > > > >and the redirect packet type. How this is defined is left to = model=20 > where > > > > >redirect LFBs and the attributes are defined. > > > > > > > > > >We need to solve this a little sooner. > > > > > > > > > >thoughts? > > > > > > > > > >Thanks, > > > > >Weiming > > > > > > > > > >----- Original Message ----- > > > > >From: "Joel M. Halpern" > > > > >Subject: Redirect Message > > > > > > > > > > > > > > > > Based on discussion, and based on my earlier message that = specific > > > > > protocol > > > > > > messages may have different top level TLVs, here is a = description > > > of the > > > > > > contents of a redirect message. > > > > > > > > > > > > A redirect message will contain a redirect TLV. > > > > > > A redirect TLV consists of three fixed fields, and meta-data = TLV, > > > and the > > > > > > packet. > > > > > > The fixed fields are > > > > > > o the LFB Class ID of the redirect source or redirect sink = LFB on > > > the FE > > > > > > associated with this packet > > > > > > o the LFB Instance ID of the redirect source or redirect = sink=20 > LFB on > > > > > the FE > > > > > > associated with this packet > > > > > > o an index within that LFB to identify configured properties = of=20 > the > > > packet. > > > > > > > > > > > > The meta-data TLV contains dynamic information needed by the = FE or > > > CE to > > > > > > process the packet. This will need to be spelled out in = more > > > detail. It > > > > > > may need to use path encoding. > > > > > > > > > > > > Following this will be the packet. > > > > > > > > > > > > Yours, > > > > > > Joel > > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jul 15 10:29:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtRBj-0007QH-N1 for forces-archive@megatron.ietf.org; Fri, 15 Jul 2005 10:29: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 KAA10078 for ; Fri, 15 Jul 2005 10:29:13 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtReZ-0002HF-8G for forces-archive@IETF.ORG; Fri, 15 Jul 2005 10:59:03 -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.010A7A7F@cherry.ease.lsoft.com>; Fri, 15 Jul 2005 10:29:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79223770 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Jul 2005 10:29:13 -0400 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 15 Jul 2005 10:29:12 -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 j6FETC4w172068 for ; Fri, 15 Jul 2005 14:29:12 GMT 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/VER6.6) with ESMTP id j6FETCD0288340 for ; Fri, 15 Jul 2005 15:29:12 +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 j6FETCrr007694 for ; Fri, 15 Jul 2005 15:29:12 +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 j6FETBJ3007680; Fri, 15 Jul 2005 15:29:11 +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 QAA52668; Fri, 15 Jul 2005 16:29:11 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1118434140.53.0.769267160607.issue55@mip4.org> <6.2.1.2.0.20050610205518.02d91f98@localhost> <42D64E2B.9050201@zurich.ibm.com> <6.2.1.2.0.20050714074414.030cc650@localhost> <7957B4FE7534BBC0BB02DECA@[10.0.0.69]> <42D66DF6.2010008@zurich.ibm.com> <4F1E514A9B3A7EFC00B9F64C@[192.168.0.4]> 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 j6FETC4w172068 Approved-By: Robert Haas Message-ID: <42D7C836.1040808@zurich.ibm.com> Date: Fri, 15 Jul 2005 16:29:10 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue55] Execution text replacement Comments: To: Alistair Munro To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4F1E514A9B3A7EFC00B9F64C@[192.168.0.4]> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Hi Alistair, > The FE may have valid next-hop and prefix tables for 10000's of routes=20 > and hundred of interfaces. Given an arbitrary disconnect between the=20 > CE and FE, what should we do to reconcile any differences? So let's see first what we should do in a simple case: the association=20 breaks while there is NO transaction underway. The FE had 250k routes=20 stored. When the association is reestablished, the CE MUST either: - delete all the routes in the FE, and set the new routes. - get all routes in the FE and modify/delete/add routes as necessary Or do you propose something else ? Joel says that the CE should reload=20 the entire FE state (by doing either of the two above). Regards, -Robert --=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 Sun Jul 17 01:48:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du20p-0007fY-5y for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 01:48: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 BAA22006 for ; Sun, 17 Jul 2005 01:48:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du2Tv-0001Yu-1C for forces-archive@IETF.ORG; Sun, 17 Jul 2005 02:18: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 <11.010A97D3@cherry.ease.lsoft.com>; 17 Jul 2005 1:48:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79370006 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 01:48:12 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 01:48:11 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j6H5lRmV016898; Sun, 17 Jul 2005 05:47:27 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 j6H5lRAX010711; Sun, 17 Jul 2005 05:47:27 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 M2005071622472617575 ; Sat, 16 Jul 2005 22:47: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); Sat, 16 Jul 2005 22:47:26 -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] Result TLV thread-index: AcWJNyeXCzQVlnBBT1SvwA/S4dD/BgBW6hSQ X-OriginalArrivalTime: 17 Jul 2005 05:47:26.0817 (UTC) FILETIME=[032F1510:01C58A93] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0603A417@orsmsx408> Date: Sat, 16 Jul 2005 22:47:22 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Result TLV Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable Sure, not a problem. I would request Avri to take care of this in her editorial updates to the draft. So I guess this issue can be closed as well. That's good. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, July 15, 2005 5:14 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Result TLV Hormuzd, I highly suggest to separate the Operation TLV figure from the whole LFB select TLV figure in the config message, like what shown in the Qeury message. The reason is, with the following figure shown, it may be easily lead to an ambiguity that the Operation TLV is parallel with LFBselect TLV rather than being a nested TLV. This also saves some space, for you otherwise need to duplicates the text, and it also makes the text more consistent with other messages in look. Thanks, Weiming ----- Original Message -----=20 From: "Khosravi, Hormuzd M" To: Sent: Thursday, July 14, 2005 12:58 PM Subject: Re: Result TLV Thanks for the clarification, Joel! That's completely fine with me. So it looks like.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (SET-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-data TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (DEL-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-data TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is more granular and makes sense to me (what I would have expected to see in the response). Therefore I asked for the clarification below. Regards Hormuzd -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 Sent: Wednesday, July 13, 2005 12:34 PM To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM Subject: RE: [FORCES] Result TLV I would expect there to be path-data at least some of the time. Assuming abbreviated responses (which are probably the norm) then for=20 success it might suffice to just have one Result TLV, with no path-data. I=20 had not thought about allowing that. If there are errors, there must at least be the path-data (possibly several=20 nested path-data TLVs) that identify the target of the operation which=20 failed, to provide context for the error code in the Result TLV. (Remember=20 that there can be multiple path-data in the request, so the CE needs to=20 know which thing failed.. If we are in the try-all-operations mode, then at least each operation=20 which failed will need its path-data. And if we instead use verbose responses, then I expect the response to have=20 all the path-data from the request, with result TLVs for each one=20 indicating success or failure. Basically, I am just putting the Result-TLV into the path-data where the data-raw would have gone. Yours, Joel At 12:30 PM 7/13/2005, Khosravi, Hormuzd M wrote: >Again a reasonable and simple approach to provide the Results. > >To put some more context around it, is this how it would look like in a >Config Response message? > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D LFB select | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (SET-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (DEL-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Pls do clarify, No path-data tlv in this format? > >Thanks >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Thursday, June 30, 2005 12:04 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Result TLV > >The following is what I suggest for handling results of operations. > >SET and GET Requests do not have result information (they are requests). >SET and GET Responses have result information. >SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. > >For a GET responses, individual gets which succeed will have DATARAW >TLVs >added to the leaf paths to carry the requested data. For GET elements >that >fail, instead of the DATARAW TLV there will be a RESULT TLV. > >For a SET response, each DATARAW TLV in the original request will be >replace with a RESULT TLV in the response. >If the request was for Ack-fail, then only those items which failed will > >appear in the response. If the request was for ack-all, then all >elements >of the request will appear in the response with RESULT TLVs. > >A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 >byte) >value. >The defined values are > 0 =3D success > 1 =3D no such object > 2 =3D permission denied > 3 =3D invalid value (the dataraw could not validly be stored in the >field) > 4 =3D invalid array creation (when the subscript in an array create is >not >allowed) > 255 =3D unspecified error (for when the FE can not decide what went >wrong) > >We may need a few more values to cover other errors. >Note that if a SET request with a structure in a DATARAW is issued, and >some field in the structure is invalid, the FE will not attempt to >indicate >which field was invalid, but rather will indicate that the operation >failed. >Note further that if there are multiple errors in a single leaf >path-data / >DATARAW, the FE can select which error it chooses to return. So if a >DATARAW for a SET of a structure attempts to write one field which is >read >only, and attempts to set another field to an invalid value, the FE can >return whatever error it likes. > >Yours, >Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 01:54:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du26y-0001TK-Gs for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 01:54: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 BAA22177 for ; Sun, 17 Jul 2005 01:54:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du2a8-0001qq-So for forces-archive@IETF.ORG; Sun, 17 Jul 2005 02: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 <10.010A9987@cherry.ease.lsoft.com>; 17 Jul 2005 1:54:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79370259 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 01:54:46 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 01:54:46 -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 j6H5shrS032043; Sun, 17 Jul 2005 05:54:43 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 j6H5sfAX012215; Sun, 17 Jul 2005 05:54:43 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 M2005071622544017888 ; Sat, 16 Jul 2005 22:54: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); Sat, 16 Jul 2005 22:54:40 -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] [issue32] Packet Redirect thread-index: AcWJReqyzysXBw04QaGihH5EaD+IjABTbn8A X-OriginalArrivalTime: 17 Jul 2005 05:54:40.0936 (UTC) FILETIME=[05F06280:01C58A94] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0603A418@orsmsx408> Date: Sat, 16 Jul 2005 22:54:38 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Joel, I am not sure I understand why the Identifiers will be assigned by the CE? Isnt this just another Type that will be defined in the Model...e.g. Id=3DPort, metadata value=3Dport_id Let me know what I am missing here, Thanks Hormuzd -----Original Message----- This looks good to me. My only quibble (minor difference) is with the description that the=20 identifier portion of the meta-data ILV is assigned by the model. We have=20 not worked this out, but I think that the identifiers are probably going to=20 end up assigned by the CE. (The implication of this is that if one CE takes over for another, it may=20 have to do some analysis to get the meanings for the meta-data=20 identifiers. But it should be simple to find the LFBs where the meta-data=20 is created, and determine what ID is configured to be used for it. And=20 this needs to be described somewhere in either the model or the protocol document. I think it will go in the meta-data portion of the model draft.) Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 02:04:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du2GX-0004Qk-8L for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 02:04: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 CAA27260 for ; Sun, 17 Jul 2005 02:04:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du2jg-0002FA-U0 for forces-archive@IETF.ORG; Sun, 17 Jul 2005 02:34: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.010A9938@cherry.ease.lsoft.com>; 17 Jul 2005 2:04:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79370686 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 02:04:38 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 02:04:38 -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 j6H64HmV021844; Sun, 17 Jul 2005 06:04:17 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 j6H64FYF022491; Sun, 17 Jul 2005 06:04:17 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 M2005071623041620391 ; Sat, 16 Jul 2005 23:04:16 -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); Sat, 16 Jul 2005 23:04:17 -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] [issue32] Packet Redirect thread-index: AcWJQSd57wLjLidmQHmiLQyyu0Er0QBU/3Zg X-OriginalArrivalTime: 17 Jul 2005 06:04:17.0037 (UTC) FILETIME=[5D526BD0:01C58A95] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0603A41A@orsmsx408> Date: Sat, 16 Jul 2005 23:04:14 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: quoted-printable Weiming, This looks very good to me. Except for the one detail being discussed with Joel, this issue looks closed to me. Thanks for the good work! Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, July 15, 2005 6:26 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue32] Packet Redirect Hi all, I tried to compose a text for the update of the redirect message part in the attachment, based on our current discussions . Pls send coments on.=20 Thanks, Weiming ----- Original Message -----=20 From: "Joel M. Halpern" To: Sent: Thursday, July 07, 2005 10:38 AM Subject: Re: [issue32] Packet Redirect > There is a whole section on meta-data in the model document. > I would expect most meta-data fields to be 32 bits. > The CE can choose to use a meta-data classifier and multiple meta-data > fields in order to steer the packet to the right LFB. And the CE will know=20 > what meta-data field the LFB will use for selecting among its ports. >=20 >=20 > This relates to a larger question for the list... > We NEED an LFB library. > Please! > To do this, we need folks to actually write definitions of LFBs. > (I think we have an editor who is likely to be willing to pull things=20 > together. At least I hope so.) > There are a lot of LFBs that need writing. > If this WG doesn't start producing them, it won't happen. >=20 >=20 > To get back to your question Weiming, given a set of LFB definitions and=20 > the meta-data they use, I can better specify what the CE will send /=20 > receive. But in an abstract sense, since it will be information flowing=20 > between the redirect LFB and the eventual interface LFB, the way the model=20 > prescribes to carry that information is as meta-data. This is the same=20 > meta-data that will need, for example, to come out of longest-prefix-match=20 > and next-hop resolution LFBs. After all, they need to be able to direct=20 > packets to be shipped out specific interfaces, with specific headers, etc. >=20 > Yours, > Joel >=20 > At 10:27 PM 7/6/2005, Wang,Weiming wrote: > >A very simple question then, how many bits we then can assign to the=20 > >meta-data like the port number ? > > > >thanks, > >weiming > > > > > >----- Original Message ----- > >From: "Joel M. Halpern" > >To: "Weiming Wang" ; > >Sent: Thursday, July 07, 2005 4:09 AM > >Subject: Re: [issue32] Packet Redirect > > > > > > > After some discussion, the operational data may be simpler than I had been > > > thinking. > > > We can simply attach (in some reasonable TLV format) all the meta-data. > > > So packets from the CE come with meta-data, and the CE gets all the > > > meta-data from the FE associated with a packet. > > > That ensures that all the necessary information is available, without > > > making the redirect LFBs complex. > > > > > > Yours, > > > Joel > > > > > > At 10:44 AM 7/6/2005, Weiming Wang wrote: > > > >Joel, > > > > > > > >I tend to agree with your idea below except the index. Could you give > > > >more details on its necessity? Thanks. > > > >As a result, the agreeable format to me seems like: > > > > > > > >Redirect TLV, whith contains > > > > LFB class ID > > > > LFB instance ID > > > > operation TLV (REPORT), which contains Path-Data > > > > Packet TLV > > > > > > > >We further define that that Path-Data should supply enough information=20 > > for > > > >the followed packet. At least it should include information about the=20 > > port > > > >number the redirect packet is input(sink LFB) or is output (source LFB), > > > >and the redirect packet type. How this is defined is left to model where > > > >redirect LFBs and the attributes are defined. > > > > > > > >We need to solve this a little sooner. > > > > > > > >thoughts? > > > > > > > >Thanks, > > > >Weiming > > > > > > > >----- Original Message ----- > > > >From: "Joel M. Halpern" > > > >Subject: Redirect Message > > > > > > > > > > > > > Based on discussion, and based on my earlier message that specific > > > > protocol > > > > > messages may have different top level TLVs, here is a description=20 > > of the > > > > > contents of a redirect message. > > > > > > > > > > A redirect message will contain a redirect TLV. > > > > > A redirect TLV consists of three fixed fields, and meta-data TLV,=20 > > and the > > > > > packet. > > > > > The fixed fields are > > > > > o the LFB Class ID of the redirect source or redirect sink LFB on=20 > > the FE > > > > > associated with this packet > > > > > o the LFB Instance ID of the redirect source or redirect sink LFB on > > > > the FE > > > > > associated with this packet > > > > > o an index within that LFB to identify configured properties of the=20 > > packet. > > > > > > > > > > The meta-data TLV contains dynamic information needed by the FE or=20 > > CE to > > > > > process the packet. This will need to be spelled out in more=20 > > detail. It > > > > > may need to use path encoding. > > > > > > > > > > Following this will be the packet. > > > > > > > > > > Yours, > > > > > Joel > > > From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 05:35:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du5YV-00042F-T5 for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 05:35: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 FAA22106 for ; Sun, 17 Jul 2005 05:35:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du61Y-0001mU-5q for forces-archive@IETF.ORG; Sun, 17 Jul 2005 06:05: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 <3.010A9A3B@cherry.ease.lsoft.com>; 17 Jul 2005 5:35:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79376233 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 05:35:15 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 05:35:13 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Sun, 17 Jul 2005 18:15:48 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sun, 17 Jul 2005 17:32:40 +0800 References: <7A7A7A38134E244784EDAC428C538AE901F1329A@mail.ndsc.com.cn> 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Approved-By: "Wang,Weiming" Message-ID: <07ee01c58ab2$637e4ac0$1152010a@Necom.hzic.edu.cn> Date: Sun, 17 Jul 2005 17:32:02 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 4.0 (++++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: base64 SGkgSm9lbCwgYW5kIEZlbmdnZW4sIA0KDQpJIGFsc28gaGF2ZSB0aGUgc2FtZSBjb25jZXJuIGFz IEhvcm11emQgdGhhdCB3aHkgbWV0YS1kYXRhIElEIHNob3VsZCBiZSBhc3NpZ25lZCBieSBDRT8g SWYgdGhlIElEIGlzIGFzc2lnbmVkIGJ5IENFLCBpdCBhY3R1YWxseSBpbXBsaWVzIHRoZSBJRCBp cyBkeW5hbWljLCByYXRoZXIgdGhhbiBzdGF0aWMuIEkgc3VwcG9zZSB0aGUgSUQgaXMgc3RhdGlj LCBpLmUuLCBMRkIgZGVmaW5pdGlvbnMgc3RhdGljYWxseSBhc3NpZ24gaXQuIE9idmlvdXNseSwg bWV0YS1kYXRhIHJlY2VpdmVkIGJ5IGEgcmVkaXJlY3Qgc2luayBMRkIgd2lsbCBoYXZlIG1ldGEt ZGF0YSBkZWZpbml0aW9uIG9mIHRoZSBMRkIgdGhlIHJlZGlyZWN0IHBhY2tldCBpcyBmcm9tLCB3 aGlsZSBtZXRhLWRhdGEgc2VudCBmcm9tIENFIHRvIGEgcmVkaXJlY3Qgc291cmNlIExGQiB3aWxs IGJlIHRyZWF0ZWQgYXMgYSBtZXRhLWRhdGEgb2YgdGhlIHJlZGlyZWN0IHNvdWNlIExGQidzIG1l dGEtZGF0YSwgd2hpY2ggaXMgZGVmaW5lZCBieSB0aGUgTEZCLg0KDQpBbnl3YXksIEkgc3VwcG9z ZSB3ZSBtYXkgY2xvc2UgdGhlICMzMiBpc3N1ZSBvbiB0aGUgd2hvbGUsIG9ubHkgbGVhdmluZyBh Ym92ZSBxdWVzdGlvbiBmb3Igc29tZSBtb3JlIGRpc2N1c3Npb24uDQoNClRoYW5rcywNCldlaW1p bmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCjxqZmdAbmRzYy5jb20uY24+Og0K DQpJJ20gdG90YWxseSBhZ3JlZSB3aXRoIEpvZWwsIGluIGZhY3Qgd2UgYXJlIGFjdHVhbGx5IGlt cGxlbWVudGluZyB0aGlzIGFuZCBpdCB3b3JrcyB3ZWxsLiBJIHRoaW5rIHRoZSBjb250cm9sIHBs YW5lIHBvcnRpb24gb2YgZm9yY2VzIHNob3VsZCBhc3NpZ25lZCB0aGUgcG9ydCBudW1iZXIgYWNj b3JkaW5nIHRvIHRoZSBGRSBhc3NvY2lhdGlvbiBzZXF1ZW5jZSwgYW5kIHRoZSBvdGhlciBtZXRh IGRhdGEgYXJlIGRldGVybWluZWQgYnkgdGhlIG1vZGVsIGdyb3VwLkFuZCBJIHRoaW5rIHRoZSBm b3JjZSBwcm90b2NvbCBzaG91bGQgZGVmaW5lIGhvdyB0aGUgTEZCIElEIGlzIGRlZmluZWQgYnkg dGhlIGFycml2aW5nIG9mIHRoZSBhc3NvY2lhdGlvbiBtZXNzYWdlLg0KRmVuZ2dlbiBKaWENCg0K Sm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am9lbEBzdGV2ZWNyb2NrZXIuY29tXToNCg0KVGhpcyBs b29rcyBnb29kIHRvIG1lLg0KTXkgb25seSBxdWliYmxlIChtaW5vciBkaWZmZXJlbmNlKSBpcyB3 aXRoIHRoZSBkZXNjcmlwdGlvbiB0aGF0IHRoZSANCmlkZW50aWZpZXIgcG9ydGlvbiBvZiB0aGUg bWV0YS1kYXRhIElMViBpcyBhc3NpZ25lZCBieSB0aGUgbW9kZWwuICBXZSBoYXZlIA0Kbm90IHdv cmtlZCB0aGlzIG91dCwgYnV0IEkgdGhpbmsgdGhhdCB0aGUgaWRlbnRpZmllcnMgYXJlIHByb2Jh Ymx5IGdvaW5nIHRvIA0KZW5kIHVwIGFzc2lnbmVkIGJ5IHRoZSBDRS4NCihUaGUgaW1wbGljYXRp b24gb2YgdGhpcyBpcyB0aGF0IGlmIG9uZSBDRSB0YWtlcyBvdmVyIGZvciBhbm90aGVyLCBpdCBt YXkgDQpoYXZlIHRvIGRvIHNvbWUgYW5hbHlzaXMgdG8gZ2V0IHRoZSBtZWFuaW5ncyBmb3IgdGhl IG1ldGEtZGF0YSANCmlkZW50aWZpZXJzLiAgQnV0IGl0IHNob3VsZCBiZSBzaW1wbGUgdG8gZmlu ZCB0aGUgTEZCcyB3aGVyZSB0aGUgbWV0YS1kYXRhIA0KaXMgY3JlYXRlZCwgYW5kIGRldGVybWlu ZSB3aGF0IElEIGlzIGNvbmZpZ3VyZWQgdG8gYmUgdXNlZCBmb3IgaXQuICBBbmQgDQp0aGlzIG5l ZWRzIHRvIGJlIGRlc2NyaWJlZCBzb21ld2hlcmUgaW4gZWl0aGVyIHRoZSBtb2RlbCBvciB0aGUg cHJvdG9jb2wgDQpkb2N1bWVudC4gIEkgdGhpbmsgaXQgd2lsbCBnbyBpbiB0aGUgbWV0YS1kYXRh IHBvcnRpb24gb2YgdGhlIG1vZGVsIGRyYWZ0LikNCg0KWW91cnMsDQpKb2VsDQoNCkF0IDA5OjI1 IEFNIDcvMTUvMjAwNSwgV2FuZyxXZWltaW5nIHdyb3RlOg0KPkhpIGFsbCwNCj4NCj5JIHRyaWVk IHRvIGNvbXBvc2UgYSB0ZXh0IGZvciB0aGUgdXBkYXRlIG9mIHRoZSByZWRpcmVjdCBtZXNzYWdl IHBhcnQgaW4gDQo+dGhlIGF0dGFjaG1lbnQsIGJhc2VkIG9uIG91ciBjdXJyZW50IGRpc2N1c3Np b25zIC4gUGxzIHNlbmQgY29tZW50cyBvbi4NCj4NCj5UaGFua3MsDQo+V2VpbWluZw0KPg0KIA0K From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 17:25:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuGe3-0000Uu-1Y for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 17:25: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 RAA27373 for ; Sun, 17 Jul 2005 17:25:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuH76-0008F0-J8 for forces-archive@IETF.ORG; Sun, 17 Jul 2005 17:56: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 <16.010A9FC1@cherry.ease.lsoft.com>; 17 Jul 2005 17:25:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79440578 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 17:25:37 -0400 Received: from 207.69.195.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 17:25:37 -0400 Received: from user-2ivf95d.dsl.mindspring.com ([165.247.164.173] helo=JMHLap3.stevecrocker.com) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DuGdY-0005yV-00; Sun, 17 Jul 2005 17:25:31 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0603A418@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.20050717171834.02e65ff8@localhost> Date: Sun, 17 Jul 2005 17:25:01 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0603A418@orsmsx408> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This was a topic of major discussion within the model team. The cases which drive it get complex. Firstly, there is the simple case of a meta-data classfiier. This accepts packets on its input, looks at their meta-data, and selects the output. Clearly, such an LFB must have a selectable meta-data usage, so that you can use if after the port-id, or after the DSCP selection, or ... Then, we get into more complex situations. SUppse that we want to have the output port of an LFB selected by a piece of meta-data. We could try to assign globally unique IDs, and define the meta-data ID that this LFB uses. At the same time we have the LPM lfb which produces an extress interface, possibly a port, and possibly some next hope identifying information. We could try to define which of those correspond with the output port Identifier. And we could ensure it was different from the input port identifier. But then someone defines a new LFB that sometimes wants to use next-hop ID and sometimes wants to use port-ID (maybe to cope differently with p-to-p interfaces). And gradually we add more LFBs, and they want different meta-data values to match, etc. We would (and may eventually anyway) need to create a meta-data rewireter that by configuration copies values from certain meta-data items to certain other meta-data items. That will work. Or we take the approach that the identifier (not the semantics, just the identifier) of the meta-data item used or produced by each LFB needs to be configured. This whole issue is finessed in the model. My own feeling is that since some items will necessarily require configurable meta-data handling, it seems much simpler to always se configurable meta-data selection. Yours, Joel PS: I Steve, Zsolt, and Alan did more thinking on this than I, but their thinking never got into the document. They probably have a better idea of what is really needed and why. At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: >Joel, > >I am not sure I understand why the Identifiers will be assigned by the >CE? >Isnt this just another Type that will be defined in the Model...e.g. >Id=Port, metadata value=port_id > >Let me know what I am missing here, > >Thanks >Hormuzd > >-----Original Message----- > >This looks good to me. >My only quibble (minor difference) is with the description that the >identifier portion of the meta-data ILV is assigned by the model. We >have >not worked this out, but I think that the identifiers are probably going >to >end up assigned by the CE. >(The implication of this is that if one CE takes over for another, it >may >have to do some analysis to get the meanings for the meta-data >identifiers. But it should be simple to find the LFBs where the >meta-data >is created, and determine what ID is configured to be used for it. And >this needs to be described somewhere in either the model or the protocol > >document. I think it will go in the meta-data portion of the model >draft.) > >Yours, >Joel From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 18:09:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuHK2-0000wM-R0 for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 18:09: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 SAA29745 for ; Sun, 17 Jul 2005 18:09:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuHnH-0002Ms-OM for forces-archive@IETF.ORG; Sun, 17 Jul 2005 18:39: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 <1.010AA05E@cherry.ease.lsoft.com>; 17 Jul 2005 18:09:13 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79441832 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 18:08:59 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 18:08:58 -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 j6HM8sCX015792; Sun, 17 Jul 2005 22:08:54 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 j6HM8dAf006688; Sun, 17 Jul 2005 22:08:53 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 M2005071715085307919 ; Sun, 17 Jul 2005 15:08:53 -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, 17 Jul 2005 15:08: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] [issue32] Packet Redirect thread-index: AcWKsuAtPe+oBoiqRUecGE4u5OzkOgAaSOhQ X-OriginalArrivalTime: 17 Jul 2005 22:08:53.0685 (UTC) FILETIME=[1E7E0E50:01C58B1C] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0603A4BE@orsmsx408> Date: Sun, 17 Jul 2005 15:08:44 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Yes, that sounds good to me. Thanks Hormuzd -----Original Message----- Anyway, I suppose we may close the #32 issue on the whole, only leaving above question for some more discussion. Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 19:27:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuIXH-0008GI-US for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 19:27: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 TAA04324 for ; Sun, 17 Jul 2005 19:27:00 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuJ0X-0006jp-2P for forces-archive@IETF.ORG; Sun, 17 Jul 2005 19:57: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 <5.010AA04C@cherry.ease.lsoft.com>; 17 Jul 2005 19:26:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79444300 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 19:26:57 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 19:26:57 -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 j6HNQurS006768 for ; Sun, 17 Jul 2005 23:26:56 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 j6HNQsAZ026748 for ; Sun, 17 Jul 2005 23:26:56 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 M2005071716265511788 for ; Sun, 17 Jul 2005 16:26:55 -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, 17 Jul 2005 16:26:55 -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_01C58B27.0504254C" Thread-Topic: issues 6, 41 udpated in the tracker thread-index: AcWLJwQ8KMSyQaNAR1qaT/x3PfB0Jg== X-OriginalArrivalTime: 17 Jul 2005 23:26:55.0705 (UTC) FILETIME=[05319C90:01C58B27] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0603A4E9@orsmsx408> Date: Sun, 17 Jul 2005 16:26:54 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: issues 6, 41 udpated in the tracker To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.2 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B27.0504254C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have updated issues 6, 41 in the tracker (as per the protocol team's discussions). Unfortunately the updates don't seem to be coming directly to this list, hence this message. =20 6 - data encapsulation in protocol - Text has been provided by Joel, Jamal on the ForCES mailing list (dataraw tlv). There is a rough consensus on this on the mailing list. =20 =20 41 - CE LFB Events - explicit subsction - Remove this text from the draft since the CE LFB is being removed...closed =20 =20 regards Hormuzd ------_=_NextPart_001_01C58B27.0504254C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have updated issues 6, 41 in the tracker (as per = the protocol team’s discussions). Unfortunately the updates don’t seem to = be coming directly to this list, hence this message.

 

6 - data =
encapsulation in protocol - Text has been provided by =
Joel, Jamal on the ForCES mailing list (dataraw tlv). There is a rough =
consensus on this on the mailing list.

 

 

41 - CE LFB Events =
- explicit subsction - Remove this text from the =
draft since the CE LFB is being removed...closed

 

 

regards

Hormuzd

------_=_NextPart_001_01C58B27.0504254C-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 19: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 1DuIbI-0000GZ-SQ for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 19: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 TAA04500 for ; Sun, 17 Jul 2005 19:31:09 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuJ4c-0006vS-HW for forces-archive@IETF.ORG; Sun, 17 Jul 2005 20:01: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 <16.010AA0F4@cherry.ease.lsoft.com>; 17 Jul 2005 19:31:11 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79444474 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 19:31:10 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 19:31:10 -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 j6HNV9iS017546 for ; Sun, 17 Jul 2005 23:31:09 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 j6HNV9YD030079 for ; Sun, 17 Jul 2005 23:31:09 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 M2005071716310901489 for ; Sun, 17 Jul 2005 16:31:09 -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, 17 Jul 2005 16:31:09 -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_01C58B27.9C3140E6" Thread-Topic: text for issue 36 thread-index: AcWLJ5tuIaNFxqfNTIOB9IutLztg0A== X-OriginalArrivalTime: 17 Jul 2005 23:31:09.0317 (UTC) FILETIME=[9C5BBB50:01C58B27] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0603A4EA@orsmsx408> Date: Sun, 17 Jul 2005 16:31:07 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: text for issue 36 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B27.9C3140E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the text supplied for this... =20 * FE failover and restart policy - This specifies the behavior of the FE during a CE failure and restart time interval. For example, this would specify if the FE should continue running or stop operation during a CE failure in the NE. =20 * CE failover and restart policy - This specifies the behavior of the CE during a FE failure and restart time interval. For example, this would specify if the CE should continue running or stop operation during a FE failure in the NE. =20 Hormuzd =20 ------_=_NextPart_001_01C58B27.9C3140E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the text = supplied for this…

 

*  FE failover = and restart policy - This specifies the behavior of the FE during a CE failure and = restart time interval. For example, this would specify if the FE should continue running or stop operation during a CE failure in the = NE.

 

*  CE failover = and restart policy - This specifies the behavior of the CE during a FE failure and = restart time interval. For example, this would specify if the CE should continue running or stop operation during a FE failure in the = NE.

 

Hormuzd

 

------_=_NextPart_001_01C58B27.9C3140E6-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 19:32:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuIca-0000TP-GT for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 19:32:32 -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 TAA04608 for ; Sun, 17 Jul 2005 19:32:29 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuJ5u-000741-3f for forces-archive@IETF.ORG; Sun, 17 Jul 2005 20:02: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 <13.010AA049@cherry.ease.lsoft.com>; 17 Jul 2005 19:32:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79444733 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 19:32:30 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 19:32:30 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j6HNWTiS017715 for ; Sun, 17 Jul 2005 23:32:29 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 j6HNWQAb028436 for ; Sun, 17 Jul 2005 23:32:29 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 M2005071716322912119 for ; Sun, 17 Jul 2005 16:32:29 -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, 17 Jul 2005 16:32:29 -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_01C58B27.CBFD495A" Thread-Topic: text for issue 34 thread-index: AcWLJ8s6uv72cZxIQzyiGevN4h113g== X-OriginalArrivalTime: 17 Jul 2005 23:32:29.0490 (UTC) FILETIME=[CC252920:01C58B27] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0603A4EB@orsmsx408> Date: Sun, 17 Jul 2005 16:32:27 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: text for issue 34 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B27.CBFD495A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable - 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. =20 Hormuzd ------_=_NextPart_001_01C58B27.CBFD495A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

Hormuzd

------_=_NextPart_001_01C58B27.CBFD495A-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 19:34:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuIeu-00013P-D0 for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 19:34: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 TAA04839 for ; Sun, 17 Jul 2005 19:34:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuJ8E-0007FL-0W for forces-archive@IETF.ORG; Sun, 17 Jul 2005 20:05:14 -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.010AA19B@cherry.ease.lsoft.com>; 17 Jul 2005 19:34:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79444881 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 19:34:54 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 19:34:54 -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 j6HNYrCX008365 for ; Sun, 17 Jul 2005 23:34:53 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 j6HNYrYD031073 for ; Sun, 17 Jul 2005 23:34:53 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 M2005071716345201788 for ; Sun, 17 Jul 2005 16:34:52 -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); Sun, 17 Jul 2005 16:34:53 -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_01C58B28.21996C72" Thread-Topic: text for issue 26 thread-index: AcWLKCDSQa53vdBcRjKcZy5BlcnFsA== X-OriginalArrivalTime: 17 Jul 2005 23:34:53.0288 (UTC) FILETIME=[21DAFE80:01C58B28] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0603A4EC@orsmsx408> Date: Sun, 17 Jul 2005 16:34:51 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: text for issue 26 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B28.21996C72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the text for 26... =20 =20 Teardown TLV =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D Teardown reason | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Teardown reason (32 bits): This indicates the reason why the association is being terminated. Several reason codes are defined as follows. 0 - normal teardown by administrator 1 - error - out of memory 2 - error - application crash 255 - error - other or unspecified =20 =20 Hormuzd =20 ------_=_NextPart_001_01C58B28.21996C72 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the text = for 26...

 

 

Teardown = TLV

 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

    = |  Type =3D Teardown reason       = |            =    = Length          = |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

    = |            =           Teardown = Reason           &= nbsp;           &n= bsp;  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

  Teardown = reason (32 bits):

       This indicates the reason why the association is being

       terminated. Several reason codes are defined as follows.

0 - normal teardown = by administrator

1 - error - out of = memory

2 - error - = application crash

255 - error - other = or unspecified

 

 

Hormuzd

 

------_=_NextPart_001_01C58B28.21996C72-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 17 19:42:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuIm4-000360-SM for forces-archive@megatron.ietf.org; Sun, 17 Jul 2005 19:42: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 TAA05233 for ; Sun, 17 Jul 2005 19:42:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuJFN-0007eR-F1 for forces-archive@IETF.ORG; Sun, 17 Jul 2005 20:12: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 <13.010AA053@cherry.ease.lsoft.com>; 17 Jul 2005 19:42:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79445297 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 17 Jul 2005 19:42:16 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 17 Jul 2005 19:42:16 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j6HNgFmV008400 for ; Sun, 17 Jul 2005 23:42:15 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 j6HNg5Af031141 for ; Sun, 17 Jul 2005 23:42:15 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 M2005071716421412659 for ; Sun, 17 Jul 2005 16:42:14 -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, 17 Jul 2005 16:42:15 -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_01C58B29.29200AA6" Thread-Topic: text for issue 37, 39 thread-index: AcWLKSf+kO3Y/MiZQ0yKtSg54IrcjQ== X-OriginalArrivalTime: 17 Jul 2005 23:42:15.0351 (UTC) FILETIME=[29587470:01C58B29] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0603A4F7@orsmsx408> Date: Sun, 17 Jul 2005 16:42:13 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: text for issue 37, 39 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.2 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B29.29200AA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I volunteered to do this since no one is assigned. =20 Issue 37 resolution -=20 FE Protocol LFB Attributes will be moved to a separate document. This means we remove the requirement for a FE Protocol LFB. and indicate that there MAY be an FE=20 Protocol LFB. Will need to include default values for all attributes. [Avri - will MAYify references to FE Protocol LFB, include Association messages] [need parameters to define all necessary global default values -=20 timer and timer intervals others to be determined as the document gets reviewed.] =20 Text-=20 The default value for the Heart Beat Interval is 300 milliseconds. The default value for the Association Expiry timer is 900 milliseconds, i.e. an association expires after 3 heart beats have been missed. =20 This text has been added to section 6 for this rev of the draft. If the working group has any comments based on implementation experience, etc pls feel free to discuss. These values can be updated in the next rev of the draft. =20 =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C58B29.29200AA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I volunteered to do = this since no one is assigned.

 

Issue 37 resolution = - 

FE Protocol LFB Attributes will be moved to a separate =
document.
This means we remove the =
requirement for a FE Protocol LFB. and indicate that there MAY be an FE =

Protocol =
LFB.
Will need to include default =
values for all attributes.
[Avri - will MAYify references to =
FE Protocol LFB, include Association =
messages]
[need parameters to define all =
necessary global default values - 
    timer and =
timer intervals
    others to be =
determined as the document gets reviewed.]

 

Text- =

The default value = for the Heart Beat Interval is 300 milliseconds.

The default value = for the Association Expiry timer is 900 milliseconds, i.e. an association = expires after 3 heart beats have been missed.

 

This text has been = added to section 6 for this rev of the draft. If the working group has any = comments based on implementation experience, etc pls feel free to discuss. These = values can be updated in the next rev of the draft.

 

 

Thanks

Hormuzd

 

------_=_NextPart_001_01C58B29.29200AA6-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jul 18 04:13:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuQkY-0000Ut-Ri for forces-archive@megatron.ietf.org; Mon, 18 Jul 2005 04:13: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 EAA19533 for ; Mon, 18 Jul 2005 04:13:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuRDu-00046c-Va for forces-archive@IETF.ORG; Mon, 18 Jul 2005 04:43: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.010AA6C6@cherry.ease.lsoft.com>; Mon, 18 Jul 2005 4:13:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79466947 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 18 Jul 2005 04:13:01 -0400 Received: from 213.97.128.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 18 Jul 2005 04:13:00 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xesbzbrtdqkmmuhqzgle" Approved-By: "David.Putzolu" Message-ID: Date: Mon, 18 Jul 2005 09:12:09 +0000 Reply-To: "David.Putzolu" Sender: Forwarding and Control Element Separation From: "David.Putzolu" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----------xesbzbrtdqkmmuhqzgle Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Dog.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/18/2005 08:05 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------xesbzbrtdqkmmuhqzgle Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Animals

----------xesbzbrtdqkmmuhqzgle-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 20 08:34:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvDme-0002DC-Bj for forces-archive@megatron.ietf.org; Wed, 20 Jul 2005 08:34:44 -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 IAA11274 for ; Wed, 20 Jul 2005 08:34:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvEGP-00074h-TS for forces-archive@IETF.ORG; Wed, 20 Jul 2005 09:05: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 <10.010ADD19@cherry.ease.lsoft.com>; Wed, 20 Jul 2005 8:34:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79806524 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 20 Jul 2005 08:34:37 -0400 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 20 Jul 2005 08:34:34 -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 j6KCYXmE130466 for ; Wed, 20 Jul 2005 12:34:33 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 j6KCYXv3186464 for ; Wed, 20 Jul 2005 14:34:33 +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 j6KCYWWi011523 for ; Wed, 20 Jul 2005 14:34:33 +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 j6KCYWfB011520; Wed, 20 Jul 2005 14:34:32 +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 OAA49662; Wed, 20 Jul 2005 14:34:31 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 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 j6KCYXmE130466 Approved-By: Robert Haas Message-ID: <42DE44D5.5060307@zurich.ibm.com> Date: Wed, 20 Jul 2005 14:34:29 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: meeting agenda: slot request Comments: To: "Putzolu, David" , Patrick Droz To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable David, Patrick, I'd like to have a 20 min slot at our next meeting to present details=20 about the architecture design of the Flexinet ForCES-based control point=20 (EU project effort). All, Deadline for the meeting agenda is Monday ! I expect that we should also have discussions about the model and the=20 protocol updates. Who is planning to attend and present ? Regards, -Robert --=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 Jul 20 09:34:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvEix-000794-Gz for forces-archive@megatron.ietf.org; Wed, 20 Jul 2005 09:34: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 JAA14827 for ; Wed, 20 Jul 2005 09:34:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvFCZ-0002S8-EB for forces-archive@IETF.ORG; Wed, 20 Jul 2005 10: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 <12.010ADCC4@cherry.ease.lsoft.com>; Wed, 20 Jul 2005 9:34:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79811583 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 20 Jul 2005 09:34:43 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 20 Jul 2005 09:34:43 -0400 Received: from [12.58.128.11] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11499887 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 20 Jul 2005 09:34:42 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <42DE44D5.5060307@zurich.ibm.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.20050720093355.02fdf3c8@localhost> Date: Wed, 20 Jul 2005 09:34:41 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: meeting agenda: slot request To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42DE44D5.5060307@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Good point on the schedule / agenda. I will be at the meeting, and would be happy to spend 10 minutes talking about the model draft. Yours, Joel At 08:34 AM 7/20/2005, Robert Haas wrote: >David, Patrick, >All, > >Deadline for the meeting agenda is Monday ! >I expect that we should also have discussions about the model and the >protocol updates. Who is planning to attend and present ? > >Regards, >-Robert > >-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jul 20 10:08:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFFQ-0008B5-Hb for forces-archive@megatron.ietf.org; Wed, 20 Jul 2005 10:08:32 -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 KAA18099 for ; Wed, 20 Jul 2005 10:08:30 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvFjF-0004jz-2L for forces-archive@IETF.ORG; Wed, 20 Jul 2005 10:39: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 <15.010ADE0E@cherry.ease.lsoft.com>; Wed, 20 Jul 2005 10:08:28 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79813542 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 20 Jul 2005 10:08:19 -0400 Received: from 198.24.6.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 20 Jul 2005 10:08:19 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id j6KE8InX028348 for ; Wed, 20 Jul 2005 09:08:18 -0500 Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Jul 2005 09:08:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Jon Maloy (QB/EMC)" Message-ID: <1068F9D378B09943A35970BF8F930A7A0229DC31@lmc37-nb.lmc.ericsson.se> Date: Wed, 20 Jul 2005 09:08:18 -0500 Reply-To: "Jon Maloy (QB/EMC)" Sender: Forwarding and Control Element Separation From: "Jon Maloy (QB/EMC)" Subject: Re: meeting agenda: slot request To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea David, Patrick, I would also like to have a slot of 20 minutes, to present the TIPC/TML draft. Thanks ///jon From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 21 06:08:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvXyS-0003KE-Vb for forces-archive@megatron.ietf.org; Thu, 21 Jul 2005 06:08: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 GAA16533 for ; Thu, 21 Jul 2005 06:08:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvYSO-0003cT-74 for forces-archive@IETF.ORG; Thu, 21 Jul 2005 06:39: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 <18.010AEF46@cherry.ease.lsoft.com>; Thu, 21 Jul 2005 6:08:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 79887161 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 21 Jul 2005 06:08:06 -0400 Received: from 195.212.29.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 21 Jul 2005 06:02:44 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6LA1uSk054824 for ; Thu, 21 Jul 2005 10:02:00 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6LA1u0C261396 for ; Thu, 21 Jul 2005 11:01:56 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j6LA1uqn019042 for ; Thu, 21 Jul 2005 11:01:56 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j6LA1tUF019019; Thu, 21 Jul 2005 11:01:55 +0100 Received: from [127.0.0.1] (dhcp71-58.zurich.ibm.com [9.4.71.58]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA73228; Thu, 21 Jul 2005 12:01:55 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050403000404050201010203" Approved-By: Patrick Droz Message-ID: <42DF728A.90805@zurich.ibm.com> Date: Thu, 21 Jul 2005 12:01:46 +0200 Reply-To: Patrick Droz Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Division Subject: tentative agenda for ForCES WG, IETF 63 Comments: cc: David Putzolu , rha To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a cryptographically signed message in MIME format. --------------ms050403000404050201010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit attached is a tentative agenda for the forthcoming meeting in Paris. I personally will not make it to this meeting and Robert Haas will by chairing for me. Please let me know if you need changes to the agenda. Regards, Patrick Forwarding and Control Element Separation (ForCES) Agenda, IETF 63, Paris Monday, August 1st, 2005, 10:30-12:30 ================================= CHAIRS: David Putzolu Patrick Droz ADs: Alex Zinin Bill Fenner AGENDA: 10 min - WG status & Agenda Bash - chairs 20 min Architecture of the Flexinet ForCES-based Control Point (EU project) Robert Haas 25 min - ForCES Protocol Draft Updates Robert Haas and Jamal Salim draft-forces-protocol-04.txt 25 min - ForCES Forwarding Element Model Joel Halpern draft-ietf-forces-model-04.txt 15 min - Examples of Logical Function Blocks (LFBs) Jamal Salim 15 min - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol Jon Maloy draft-khosravi-forces-tcptml-00.txt 10 min - TIPC based TML (Transport Mapping Layer) for ForCES protocol Jon Maloy draft-maloy-tipc-tml-00.txt (Updated July 21, 2005) -- Dr. Robert R. Haas IBM Zurich Research Laboratory Säumerstrasse 4 CH-8803 Rüschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha --------------ms050403000404050201010203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAe3eMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDQwOTA4MDgyOTEwWhcNMDUwOTIyMDgyOTEwWjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCMCH7XfNWjsk4/JLer GkIF+4NOltUEjJ5tpFUpAznm3q1gLpks5Hq9AiZ0NROrS/leyppP29dNJsUEVnO9dwyfQUWh Hk3VlPDuNneKhbvfDoYyJRxhp+Lpnw5uBtLpvm0RXKttbw3XCUPCcyMs046Y1m5+XunUotEF 7Fvci8/n8QIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFD/OrZ9kTj9WbmJ+g8txJM0UxO3hMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQAXIgUJHKxCg7P4f12BKKBShLMk+9LWTKoYj0J/txL+A8XNM2EFSKQpbQJKmnh5 lmAUaMd64LC0OokYfRWh4WFazM0nNfGFAHto6glO15GtPgIzRJY3gD18AvwiKuaWED7N1aLI P2/hfbLBrG++uh6agT2wLtTLdrFTHOwKTsPGRTCCAyQwggKNoAMCAQICAwHt3jANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTA0MDkwODA4MjkxMFoXDTA1MDkyMjA4MjkxMFowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAjAh+13zVo7JOPyS3qxpC BfuDTpbVBIyebaRVKQM55t6tYC6ZLOR6vQImdDUTq0v5XsqaT9vXTSbFBFZzvXcMn0FFoR5N 1ZTw7jZ3ioW73w6GMiUcYafi6Z8ObgbS6b5tEVyrbW8N1wlDwnMjLNOOmNZufl7p1KLRBexb 3IvP5/ECAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBQ/zq2fZE4/Vm5ifoPLcSTNFMTt4TAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAFyIFCRysQoOz+H9dgSigUoSzJPvS1kyqGI9Cf7cS/gPFzTNhBUikKW0CSpp4eZZg FGjHeuCwtDqJGH0VoeFhWszNJzXxhQB7aOoJTteRrT4CM0SWN4A9fAL8IirmlhA+zdWiyD9v 4X2ywaxvvroemoE9sC7Uy3axUxzsCk7DxkUxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA3MjEx MDAxNDZaMCMGCSqGSIb3DQEJBDEWBBRJi7NeeNbQ7d6GB+7I12PlwwGTajBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwHt3jANBgkqhkiG9w0BAQEFAASBgBXUSx/t7z0RqQt8rfkX+VO2gCbbCQaYmOF1 IRbF0wdv7WWF/pqJ5btLvZXcOlYEqyaFqihAJ6QIrlVPbBWdUeIMbUIpYRQh0+GNzYogf3W5 eZRpC5jf3Gs5+7ZUFZCiIiBv7A89Z3Y9/gX5M7TzFeHhJaYVtQIn/v9NogvJtNT6AAAAAAAA --------------ms050403000404050201010203-- From FredrickCullen@kaorn.org Thu Jul 21 23:48:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvoWi-0003JE-Kd for forces-archive@megatron.ietf.org; Thu, 21 Jul 2005 23:48: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 XAA17250 for ; Thu, 21 Jul 2005 23:48:36 -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 1Dvp0Z-0006lF-Ra for forces-archive@ietf.org; Fri, 22 Jul 2005 00:19:49 -0400 Received: from [220.91.150.196] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DvoWD-0004XM-Ei for forces-archive@ietf.org; Thu, 21 Jul 2005 23:48:14 -0400 Received: from Z6tZ@localhost by eMH8.int (8.11.6/8.11.6); Thu, 21 Jul 2005 21:36:23 -0700 Message-ID: From: "Mayra Hobson" Reply-To: "Mayra Hobson" To: forces-archive@ietf.org Cc: ujuyjyht@ietf.org, katherine.lange@ietf.org Subject: 80 % Discount on All AutoCAD Titles Date: Fri, 22 Jul 2005 08:35:23 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: FredrickCullen@kaorn.org Content-Type: multipart/mixed; boundary="--JphA5oxn6z9AcOZQXbX7" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 TNrm ----JphA5oxn6z9AcOZQXbX7 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable H
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: aUEhemiQ
 

Sales R= ank: #1
System requirements  |  Other Versions
Date Coupon Expires:<= /b> August 31st, 2005
Average Customer Re= view:3D"5 Based on 1487 reviews. Write 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: uXUJTKc
 <= /p>

Sales Rank: #2
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 16916= 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: JGm= gqkQn
 

Sales Rank: #3
System requi= rements  |  Other Versions=
Date Coupon Expires: August 31st= , 2005
Average Customer Review:3D"5 Based on 1425 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: 3YYiu
 

Sales Rank: #4
System requirements  |=   Other Versions
Date Coupon Expires: August 31st, 2005
<= font class=3Dtiny>Average Customer Review:3D"5= Based on 18429 r= eviews. Write a review.

<= /font>

----JphA5oxn6z9AcOZQXbX7-- From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Fri Jul 22 05:28:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvtpy-0000i8-M9 for forces-archive@megatron.ietf.org; Fri, 22 Jul 2005 05:28: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 FAA25656 for ; Fri, 22 Jul 2005 05:28:56 -0400 (EDT) Received: from grape.ease.lsoft.com ([209.119.1.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvuKA-0004AW-1P for forces-archive@IETF.ORG; Fri, 22 Jul 2005 06:00:12 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <4.00587A09@grape.ease.lsoft.com>; Fri, 22 Jul 2005 5:28:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80010730 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 22 Jul 2005 05:28:53 -0400 Received: from 195.212.29.134 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 22 Jul 2005 05:28:52 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6M9SGJP049604 for ; Fri, 22 Jul 2005 09:28:21 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6M9R2uE203248 for ; Fri, 22 Jul 2005 10:27:02 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j6M9R1kh000966 for ; Fri, 22 Jul 2005 10:27:01 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j6M9R1QT000957; Fri, 22 Jul 2005 10:27:01 +0100 Received: from [127.0.0.1] (dhcp69-182.zurich.ibm.com [9.4.69.182]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA26712; Fri, 22 Jul 2005 11:27:00 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020703050004000001010504" Approved-By: Patrick Droz Message-ID: <42E0BBE5.3070009@zurich.ibm.com> Date: Fri, 22 Jul 2005 11:27:01 +0200 Reply-To: Patrick Droz Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Division Subject: Agenda for ForCES WG, IETF 63 Comments: To: agenda@ietf.org Comments: cc: Alex Zinin , Bill Fenner To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a cryptographically signed message in MIME format. --------------ms020703050004000001010504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Forwarding and Control Element Separation (ForCES) Agenda, IETF 63, Paris Monday, August 1st, 2005, 10:30-12:30 ================================= CHAIRS: David Putzolu Patrick Droz ADs: Alex Zinin Bill Fenner AGENDA: 10 min - WG status & Agenda Bash - chairs 20 min Architecture of the Flexinet ForCES-based Control Point (EU project) Robert Haas 25 min - ForCES Protocol Draft Updates Robert Haas and Jamal Hadi Salim draft-forces-protocol-04.txt 25 min - ForCES Forwarding Element Model Joel Halpern draft-ietf-forces-model-04.txt 15 min - Examples of Logical Function Blocks (LFBs) Jamal Hadi Salim 15 min - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol Jon Maloy draft-khosravi-forces-tcptml-00.txt 10 min - TIPC based TML (Transport Mapping Layer) for ForCES protocol Jon Maloy draft-maloy-tipc-tml-00.txt (Updated July 22, 2005) --------------ms020703050004000001010504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAe3eMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDQwOTA4MDgyOTEwWhcNMDUwOTIyMDgyOTEwWjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCMCH7XfNWjsk4/JLer GkIF+4NOltUEjJ5tpFUpAznm3q1gLpks5Hq9AiZ0NROrS/leyppP29dNJsUEVnO9dwyfQUWh Hk3VlPDuNneKhbvfDoYyJRxhp+Lpnw5uBtLpvm0RXKttbw3XCUPCcyMs046Y1m5+XunUotEF 7Fvci8/n8QIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFD/OrZ9kTj9WbmJ+g8txJM0UxO3hMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQAXIgUJHKxCg7P4f12BKKBShLMk+9LWTKoYj0J/txL+A8XNM2EFSKQpbQJKmnh5 lmAUaMd64LC0OokYfRWh4WFazM0nNfGFAHto6glO15GtPgIzRJY3gD18AvwiKuaWED7N1aLI P2/hfbLBrG++uh6agT2wLtTLdrFTHOwKTsPGRTCCAyQwggKNoAMCAQICAwHt3jANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTA0MDkwODA4MjkxMFoXDTA1MDkyMjA4MjkxMFowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAjAh+13zVo7JOPyS3qxpC BfuDTpbVBIyebaRVKQM55t6tYC6ZLOR6vQImdDUTq0v5XsqaT9vXTSbFBFZzvXcMn0FFoR5N 1ZTw7jZ3ioW73w6GMiUcYafi6Z8ObgbS6b5tEVyrbW8N1wlDwnMjLNOOmNZufl7p1KLRBexb 3IvP5/ECAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBQ/zq2fZE4/Vm5ifoPLcSTNFMTt4TAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAFyIFCRysQoOz+H9dgSigUoSzJPvS1kyqGI9Cf7cS/gPFzTNhBUikKW0CSpp4eZZg FGjHeuCwtDqJGH0VoeFhWszNJzXxhQB7aOoJTteRrT4CM0SWN4A9fAL8IirmlhA+zdWiyD9v 4X2ywaxvvroemoE9sC7Uy3axUxzsCk7DxkUxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA3MjIw OTI3MDFaMCMGCSqGSIb3DQEJBDEWBBRCdduULjFZGzxPCHpr20xbTvVIWzBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwHt3jANBgkqhkiG9w0BAQEFAASBgCLxzxKqDmczM9VYzfNc88MMKU6ggcojmqwQ xNJoT0wGodbEu0uCC6BYRWxWjzt2U+4bxxTowd4exYa/KrdhZ3b8NrLWmfZl7Xd8laQB39Cy OK5LLGi2dGEUrwXEFP+gjHXgK2FO//p63iu5PpCyAvgClTPG5GJzZkW2lFkTcp/vAAAAAAAA --------------ms020703050004000001010504-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Jul 23 11:28:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwLvX-0007jY-7k for forces-archive@megatron.ietf.org; Sat, 23 Jul 2005 11:28: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 LAA02925 for ; Sat, 23 Jul 2005 11:28:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwMQ0-0000Ry-3J for forces-archive@IETF.ORG; Sat, 23 Jul 2005 12:00: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 <21.010B162A@cherry.ease.lsoft.com>; Sat, 23 Jul 2005 11:28:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80171809 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 23 Jul 2005 11:28:17 -0400 Received: from 64.12.137.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 23 Jul 2005 11:28:17 -0400 Received: from Aaudu2000@aol.com by imo-m28.mx.aol.com (mail_out_v38_r1.7.) id j.14.49c4ee21 (15703); Sat, 23 Jul 2005 11:28:12 -0400 (EDT) Received: from mblk-d40 (mblk-d40.mblk.aol.com [205.188.212.224]) by air-id05.mx.aol.com (v106.2) with ESMTP id MAILINID54-3d5742e2620c2a9; Sat, 23 Jul 2005 11:28:12 -0400 References: <468F3FDA28AA87429AD807992E22D07E0603A4EC@orsmsx408> Received: from 71.96.170.167 by mblk-d40.sysops.aol.com (205.188.212.224) with HTTP (WebMailUI); Sat, 23 Jul 2005 11:28:12 -0400 X-MB-Message-Source: WebUI X-MB-Message-Type: User X-Mailer: AOL WebMail 1.1.0.13071 Content-Type: multipart/alternative; boundary="--------MailBlocks_8C75DB245C5CDAC_8BC_A22F_mblk-d40.sysops.aol.com" MIME-Version: 1.0 X-AOL-IP: 205.188.212.224 Approved-By: aaudu2000@AOL.COM Message-ID: <8C75DB245CA9262-8BC-A62B@mblk-d40.sysops.aol.com> Date: Sat, 23 Jul 2005 11:28:12 -0400 Reply-To: aaudu2000@aol.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: text for issue 26 Comments: To: hormuzd.m.khosravi@intel.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0603A4EC@orsmsx408> Precedence: list X-Spam-Score: 1.0 (+) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f ----------MailBlocks_8C75DB245C5CDAC_8BC_A22F_mblk-d40.sysops.aol.com Content-Type: text/plain; charset="us-ascii" Hi Hormuzd, Can you also tear down an association as a result of the heart-beat expiring?..bandwidth limitation?.. So may be we could use the following error codes: 0 - normal teardown by administrator 1 - error - loss of heart-beat 2 - error - out of bandwidth resource 3 - error - out of memory resource 4 - error - application crash .. 255 - error - other or unspecified Error 2 may signal the system's reaction to DOS attack. I have also arranged them according to severity levels,..the crash being most severe. I am not sure if the ordering matters much though. Cheers, Alex. -----Original Message----- From: Khosravi, Hormuzd M To: FORCES@PEACH.EASE.LSOFT.COM Sent: Sun, 17 Jul 2005 16:34:51 -0700 Subject: text for issue 26 Here is the text for 26... Teardown TLV +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Teardown reason | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Teardown reason (32 bits): This indicates the reason why the association is being terminated. Several reason codes are defined as follows. 0 - normal teardown by administrator 1 - error - out of memory 2 - error - application crash 255 - error - other or unspecified Hormuzd ----------MailBlocks_8C75DB245C5CDAC_8BC_A22F_mblk-d40.sysops.aol.com Content-Type: text/html; charset="us-ascii"
 Hi Hormuzd,
 
Can you also tear down an association as a result of the heart-beat expiring?..bandwidth limitation?..
So may be we could use the following error codes:
 
0 - normal teardown by administrator
1 - error - loss of heart-beat
2 - error - out of bandwidth resource
3 - error - out of memory resource
4 - error - application crash
..
255 - error - other or unspecified
 
Error 2 may signal the system's reaction to DOS attack.  I have also arranged them
according to severity levels,..the crash being most severe. I am not sure if the
ordering matters much though.
 
Cheers,
Alex.
 
 
 
-----Original Message-----
From: Khosravi, Hormuzd M <hormuzd.m.khosravi@intel.com>
To: FORCES@PEACH.EASE.LSOFT.COM
Sent: Sun, 17 Jul 2005 16:34:51 -0700
Subject: text for issue 26

Here is the text for 26...
 
 
Teardown TLV
 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type = Teardown reason       |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Teardown Reason                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
  Teardown reason (32 bits):
       This indicates the reason why the association is being
       terminated. Several reason codes are defined as follows.
0 - normal teardown by administrator
1 - error - out of memory
2 - error - application crash
255 - error - other or unspecified
 
 
Hormuzd
 
----------MailBlocks_8C75DB245C5CDAC_8BC_A22F_mblk-d40.sysops.aol.com-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Jul 23 16:18:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwQS1-00053t-LL for forces-archive@megatron.ietf.org; Sat, 23 Jul 2005 16:18: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 QAA18674 for ; Sat, 23 Jul 2005 16:18:23 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwQwS-00085H-Pm for forces-archive@IETF.ORG; Sat, 23 Jul 2005 16:49: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 <22.010B19C4@cherry.ease.lsoft.com>; Sat, 23 Jul 2005 16:18:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80184632 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 23 Jul 2005 16:18:18 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 23 Jul 2005 16:18:17 -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 j6NKIFFK023465; Sat, 23 Jul 2005 20:18:15 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 j6NKI8Qd029925; Sat, 23 Jul 2005 20:18:15 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 M2005072313181418929 ; Sat, 23 Jul 2005 13:18:14 -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); Sat, 23 Jul 2005 13:18:14 -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_01C58FC3.A79BE7D3" Thread-Topic: [FORCES] text for issue 26 thread-index: AcWPmypQ7FziDlbtRLCHbLkLY+lJbgAKGx+A X-OriginalArrivalTime: 23 Jul 2005 20:18:14.0812 (UTC) FILETIME=[A7E4EDC0:01C58FC3] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0618E308@orsmsx408> Date: Sat, 23 Jul 2005 13:18:11 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: text for issue 26 Comments: To: aaudu2000@aol.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.2 (/) X-Scan-Signature: dca2c88691a8375e57f430691ee256fd This is a multi-part message in MIME format. ------_=_NextPart_001_01C58FC3.A79BE7D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alex =20 Good suggestion. I'll make the change to the draft. =20 Thanks Hormuzd =20 ________________________________ From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu Sent: Saturday, July 23, 2005 8:28 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] text for issue 26 =20 Hi Hormuzd, =20 Can you also tear down an association as a result of the heart-beat expiring?..bandwidth limitation?.. So may be we could use the following error codes: =20 0 - normal teardown by administrator 1 - error - loss of heart-beat 2 - error - out of bandwidth resource 3 - error - out of memory resource 4 - error - application crash .. 255 - error - other or unspecified =20 Error 2 may signal the system's reaction to DOS attack. I have also arranged them according to severity levels,..the crash being most severe. I am not sure if the=20 ordering matters much though. =20 Cheers, Alex. =20 =20 =20 -----Original Message----- From: Khosravi, Hormuzd M To: FORCES@PEACH.EASE.LSOFT.COM Sent: Sun, 17 Jul 2005 16:34:51 -0700 Subject: text for issue 26 Here is the text for 26... =20 =20 Teardown TLV =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D Teardown reason | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Teardown reason (32 bits): This indicates the reason why the association is being terminated. Several reason codes are defined as follows. 0 - normal teardown by administrator 1 - error - out of memory 2 - error - application crash 255 - error - other or unspecified =20 =20 Hormuzd =20 ------_=_NextPart_001_01C58FC3.A79BE7D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alex

 

Good suggestion. I’ll make = the change to the draft.

 

Thanks

Hormuzd

 

From: = Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu
Sent: Saturday, July 23, = 2005 8:28 AM
To: = FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] = text for issue 26

 

 Hi Hormuzd,

 

Can you also tear down an association as a result of the heart-beat expiring?..bandwidth = limitation?..

So may be we could use the following error = codes:

 

0 - normal teardown by = administrator

1 - error - loss of = heart-beat

2 - error - out of bandwidth = resource

3 - error - out of memory = resource

4 - error - application = crash

..

255 - error - other or = unspecified

 

Error 2 may signal the = system's reaction to DOS attack.  I have also arranged them

according to severity levels,..the crash = being most severe. I am not sure if the

ordering matters much = though.

 

Cheers,

Alex.

 

 

 
-----Original Message-----
From: Khosravi, Hormuzd M <hormuzd.m.khosravi@intel.com>
To: FORCES@PEACH.EASE.LSOFT.COM
Sent: Sun, 17 Jul 2005 16:34:51 -0700
Subject: text for issue 26

Here is the text for 26...

 

 

Teardown TLV

 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

    |  Type =3D Teardown reason       |            =    Length          = |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

    |            =           Teardown Reason           &= nbsp;           &n= bsp;  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

  Teardown reason (32 = bits):

       This = indicates the reason why the association is being

       = terminated. Several reason codes are defined as follows.

0 - normal teardown by = administrator

1 - error - out of memory

2 - error - application = crash

255 - error - other or = unspecified

 

 

Hormuzd

 

------_=_NextPart_001_01C58FC3.A79BE7D3-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Jul 23 16:40:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwQn0-0001lC-MN for forces-archive@megatron.ietf.org; Sat, 23 Jul 2005 16:40: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 QAA19447 for ; Sat, 23 Jul 2005 16:40:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwRHW-0008WV-DH for forces-archive@IETF.ORG; Sat, 23 Jul 2005 17:11: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 <16.010B19DE@cherry.ease.lsoft.com>; Sat, 23 Jul 2005 16:40:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80185706 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 23 Jul 2005 16:40:04 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 23 Jul 2005 16:40:04 -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 j6NKe1FK028817; Sat, 23 Jul 2005 20:40:01 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 j6NKdwQZ003060; Sat, 23 Jul 2005 20:40:01 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 M2005072313395817256 ; Sat, 23 Jul 2005 13:39:58 -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); Sat, 23 Jul 2005 13:39:58 -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] [issue32] Packet Redirect thread-index: AcWLFhdEHW0Org9ySoSFfeHOkYdD6AEr6YtA X-OriginalArrivalTime: 23 Jul 2005 20:39:58.0625 (UTC) FILETIME=[B1070110:01C58FC6] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0618E30A@orsmsx408> Date: Sat, 23 Jul 2005 13:39:55 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Joel, I did some thinking on this and I couldn't see how having configurable meta-data would make things simpler for the protocol or model. Having unique meta-data IDs per LFB is a much more simpler approach IMHO. I don't think this list will be very large and this way seems to be more manageable to me...its in line with our common philosophy of keeping things simple atleast for the 1st rev of the protocol/model. My 2 cents Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Sunday, July 17, 2005 2:25 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue32] Packet Redirect This was a topic of major discussion within the model team. The cases which drive it get complex. Firstly, there is the simple case of a meta-data classfiier. This accepts=20 packets on its input, looks at their meta-data, and selects the output. Clearly, such an LFB must have a selectable meta-data usage, so that you can use if after the port-id, or after the DSCP selection, or ... Then, we get into more complex situations. SUppse that we want to have the=20 output port of an LFB selected by a piece of meta-data. We could try to assign globally unique IDs, and define the meta-data ID that this LFB uses. At the same time we have the LPM lfb which produces an extress interface,=20 possibly a port, and possibly some next hope identifying information. We=20 could try to define which of those correspond with the output port Identifier. And we could ensure it was different from the input port identifier. But then someone defines a new LFB that sometimes wants to use next-hop ID=20 and sometimes wants to use port-ID (maybe to cope differently with p-to-p=20 interfaces). And gradually we add more LFBs, and they want different meta-data values to=20 match, etc. We would (and may eventually anyway) need to create a meta-data rewireter=20 that by configuration copies values from certain meta-data items to certain=20 other meta-data items. That will work. Or we take the approach that the identifier (not the semantics, just the identifier) of the meta-data item used or produced by each LFB needs to be=20 configured. This whole issue is finessed in the model. My own feeling is that since some items will necessarily require configurable meta-data handling, it=20 seems much simpler to always se configurable meta-data selection. Yours, Joel PS: I Steve, Zsolt, and Alan did more thinking on this than I, but their thinking never got into the document. They probably have a better idea of=20 what is really needed and why. At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: >Joel, > >I am not sure I understand why the Identifiers will be assigned by the >CE? >Isnt this just another Type that will be defined in the Model...e.g. >Id=3DPort, metadata value=3Dport_id > >Let me know what I am missing here, > >Thanks >Hormuzd > >-----Original Message----- > >This looks good to me. >My only quibble (minor difference) is with the description that the >identifier portion of the meta-data ILV is assigned by the model. We >have >not worked this out, but I think that the identifiers are probably going >to >end up assigned by the CE. >(The implication of this is that if one CE takes over for another, it >may >have to do some analysis to get the meanings for the meta-data >identifiers. But it should be simple to find the LFBs where the >meta-data >is created, and determine what ID is configured to be used for it. And >this needs to be described somewhere in either the model or the protocol > >document. I think it will go in the meta-data portion of the model >draft.) > >Yours, >Joel From owner-forces@PEACH.EASE.LSOFT.COM Sat Jul 23 17:17:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwRMu-0002cd-Tk for forces-archive@megatron.ietf.org; Sat, 23 Jul 2005 17:17: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 RAA20529 for ; Sat, 23 Jul 2005 17:17:09 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwRrC-0000lB-1T for forces-archive@IETF.ORG; Sat, 23 Jul 2005 17:48: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 <7.010B1B5A@cherry.ease.lsoft.com>; Sat, 23 Jul 2005 17:16:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80187307 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 23 Jul 2005 17:16:56 -0400 Received: from 207.69.195.66 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 23 Jul 2005 17:16:56 -0400 Received: from user-2ivepph.dialup.mindspring.com ([165.247.103.49] helo=JMHLap3.stevecrocker.com) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DwRMc-0003JR-00 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 23 Jul 2005 17:16:54 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0618E30A@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.20050723171357.02ecd3a8@localhost> Date: Sat, 23 Jul 2005 17:16:48 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0618E30A@orsmsx408> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 It is certainly attractive to simply define for a given LFB what meta-data ID it uses / produces. If we want to take that approach, then we are going to frequently need to make use of meta-data transcoders whose only function is to take meta-data of ID x and turn it into meta-data of ID y. This comes up because one could easily have a classifier that uses "port" (say ID 12), but a tunnel processor that produces "tunnel-id" (say id 34). And the CE wants the classifier to use the tunnel ID as the port for its work. If we believe that the significant majority of the time we can get the IDs right, then the LFB definition can include the meta-data ID. I am doubtful. Yours, Joel At 04:39 PM 7/23/2005, Khosravi, Hormuzd M wrote: >Joel, > >I did some thinking on this and I couldn't see how having configurable >meta-data would make things simpler for the protocol or model. Having >unique meta-data IDs per LFB is a much more simpler approach IMHO. I >don't think this list will be very large and this way seems to be more >manageable to me...its in line with our common philosophy of keeping >things simple atleast for the 1st rev of the protocol/model. > >My 2 cents >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Sunday, July 17, 2005 2:25 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue32] Packet Redirect > >This was a topic of major discussion within the model team. >The cases which drive it get complex. > >Firstly, there is the simple case of a meta-data classfiier. This >accepts >packets on its input, looks at their meta-data, and selects the output. >Clearly, such an LFB must have a selectable meta-data usage, so that you > >can use if after the port-id, or after the DSCP selection, or ... > >Then, we get into more complex situations. SUppse that we want to have >the >output port of an LFB selected by a piece of meta-data. We could try to > >assign globally unique IDs, and define the meta-data ID that this LFB >uses. >At the same time we have the LPM lfb which produces an extress >interface, >possibly a port, and possibly some next hope identifying information. >We >could try to define which of those correspond with the output port >Identifier. >And we could ensure it was different from the input port identifier. >But then someone defines a new LFB that sometimes wants to use next-hop >ID >and sometimes wants to use port-ID (maybe to cope differently with >p-to-p >interfaces). >And gradually we add more LFBs, and they want different meta-data values >to >match, etc. >We would (and may eventually anyway) need to create a meta-data >rewireter >that by configuration copies values from certain meta-data items to >certain >other meta-data items. >That will work. > >Or we take the approach that the identifier (not the semantics, just the > >identifier) of the meta-data item used or produced by each LFB needs to >be >configured. > >This whole issue is finessed in the model. My own feeling is that since > >some items will necessarily require configurable meta-data handling, it >seems much simpler to always se configurable meta-data selection. > >Yours, >Joel > >PS: I Steve, Zsolt, and Alan did more thinking on this than I, but their > >thinking never got into the document. They probably have a better idea >of >what is really needed and why. > >At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: > >Joel, > > > >I am not sure I understand why the Identifiers will be assigned by the > >CE? > >Isnt this just another Type that will be defined in the Model...e.g. > >Id=Port, metadata value=port_id > > > >Let me know what I am missing here, > > > >Thanks > >Hormuzd > > > >-----Original Message----- > > > >This looks good to me. > >My only quibble (minor difference) is with the description that the > >identifier portion of the meta-data ILV is assigned by the model. We > >have > >not worked this out, but I think that the identifiers are probably >going > >to > >end up assigned by the CE. > >(The implication of this is that if one CE takes over for another, it > >may > >have to do some analysis to get the meanings for the meta-data > >identifiers. But it should be simple to find the LFBs where the > >meta-data > >is created, and determine what ID is configured to be used for it. And > >this needs to be described somewhere in either the model or the >protocol > > > >document. I think it will go in the meta-data portion of the model > >draft.) > > > >Yours, > >Joel From owner-forces@PEACH.EASE.LSOFT.COM Sat Jul 23 17:33:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwRd7-0006fR-GH for forces-archive@megatron.ietf.org; Sat, 23 Jul 2005 17:33: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 RAA21097 for ; Sat, 23 Jul 2005 17:33:54 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwS7d-00017R-Ni for forces-archive@IETF.ORG; Sat, 23 Jul 2005 18:05: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 <8.010B1A42@cherry.ease.lsoft.com>; Sat, 23 Jul 2005 17:33:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80188411 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 23 Jul 2005 17:33:55 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 23 Jul 2005 17:33:54 -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 j6NLXrFK009864; Sat, 23 Jul 2005 21:33:53 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 j6NLXmkd017676; Sat, 23 Jul 2005 21:33:53 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 M2005072314335219628 ; Sat, 23 Jul 2005 14:33:52 -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); Sat, 23 Jul 2005 14:33:52 -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] [issue32] Packet Redirect thread-index: AcWPy+G6i/Emn2YRTuacg5VYypbxCAAAgp7w X-OriginalArrivalTime: 23 Jul 2005 21:33:52.0757 (UTC) FILETIME=[38B86250:01C58FCE] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0618E310@orsmsx408> Date: Sat, 23 Jul 2005 14:33:49 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable My thinking would be the latter (below). We should strive to keep the model, lfb library, etc relatively simple atleast for the first rev...we can add more flexibility for the second rev as we learn more from different usage scenarios and implementation experiences. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Saturday, July 23, 2005 2:17 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue32] Packet Redirect It is certainly attractive to simply define for a given LFB what meta-data=20 ID it uses / produces. If we want to take that approach, then we are going to frequently need to=20 make use of meta-data transcoders whose only function is to take meta-data=20 of ID x and turn it into meta-data of ID y. This comes up because one could easily have a classifier that uses "port"=20 (say ID 12), but a tunnel processor that produces "tunnel-id" (say id=20 34). And the CE wants the classifier to use the tunnel ID as the port for=20 its work. If we believe that the significant majority of the time we can get the IDs=20 right, then the LFB definition can include the meta-data ID. I am doubtful. Yours, Joel At 04:39 PM 7/23/2005, Khosravi, Hormuzd M wrote: >Joel, > >I did some thinking on this and I couldn't see how having configurable >meta-data would make things simpler for the protocol or model. Having >unique meta-data IDs per LFB is a much more simpler approach IMHO. I >don't think this list will be very large and this way seems to be more >manageable to me...its in line with our common philosophy of keeping >things simple atleast for the 1st rev of the protocol/model. > >My 2 cents >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Sunday, July 17, 2005 2:25 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue32] Packet Redirect > >This was a topic of major discussion within the model team. >The cases which drive it get complex. > >Firstly, there is the simple case of a meta-data classfiier. This >accepts >packets on its input, looks at their meta-data, and selects the output. >Clearly, such an LFB must have a selectable meta-data usage, so that you > >can use if after the port-id, or after the DSCP selection, or ... > >Then, we get into more complex situations. SUppse that we want to have >the >output port of an LFB selected by a piece of meta-data. We could try to > >assign globally unique IDs, and define the meta-data ID that this LFB >uses. >At the same time we have the LPM lfb which produces an extress >interface, >possibly a port, and possibly some next hope identifying information. >We >could try to define which of those correspond with the output port >Identifier. >And we could ensure it was different from the input port identifier. >But then someone defines a new LFB that sometimes wants to use next-hop >ID >and sometimes wants to use port-ID (maybe to cope differently with >p-to-p >interfaces). >And gradually we add more LFBs, and they want different meta-data values >to >match, etc. >We would (and may eventually anyway) need to create a meta-data >rewireter >that by configuration copies values from certain meta-data items to >certain >other meta-data items. >That will work. > >Or we take the approach that the identifier (not the semantics, just the > >identifier) of the meta-data item used or produced by each LFB needs to >be >configured. > >This whole issue is finessed in the model. My own feeling is that since > >some items will necessarily require configurable meta-data handling, it >seems much simpler to always se configurable meta-data selection. > >Yours, >Joel > >PS: I Steve, Zsolt, and Alan did more thinking on this than I, but their > >thinking never got into the document. They probably have a better idea >of >what is really needed and why. > >At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: > >Joel, > > > >I am not sure I understand why the Identifiers will be assigned by the > >CE? > >Isnt this just another Type that will be defined in the Model...e.g. > >Id=3DPort, metadata value=3Dport_id > > > >Let me know what I am missing here, > > > >Thanks > >Hormuzd > > > >-----Original Message----- > > > >This looks good to me. > >My only quibble (minor difference) is with the description that the > >identifier portion of the meta-data ILV is assigned by the model. We > >have > >not worked this out, but I think that the identifiers are probably >going > >to > >end up assigned by the CE. > >(The implication of this is that if one CE takes over for another, it > >may > >have to do some analysis to get the meanings for the meta-data > >identifiers. But it should be simple to find the LFBs where the > >meta-data > >is created, and determine what ID is configured to be used for it. And > >this needs to be described somewhere in either the model or the >protocol > > > >document. I think it will go in the meta-data portion of the model > >draft.) > > > >Yours, > >Joel From owner-forces@PEACH.EASE.LSOFT.COM Sat Jul 23 22:05:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwVs1-0002zM-VF for forces-archive@megatron.ietf.org; Sat, 23 Jul 2005 22:05: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 WAA04126 for ; Sat, 23 Jul 2005 22:05:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwWMa-0007Ks-JA for forces-archive@IETF.ORG; Sat, 23 Jul 2005 22:37: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 <8.010B1DA0@cherry.ease.lsoft.com>; Sat, 23 Jul 2005 22:05:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80198063 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 23 Jul 2005 22:05:34 -0400 Received: from 207.69.195.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 23 Jul 2005 22:05:34 -0400 Received: from user-2ivf91a.dsl.mindspring.com ([165.247.164.42] helo=JMHLap3.stevecrocker.com) by pop-gadwall.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DwVrw-0007B3-00 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 23 Jul 2005 22:05:33 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0618E310@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.20050723220254.02ed04e8@localhost> Date: Sat, 23 Jul 2005 22:05:28 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0618E310@orsmsx408> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 I suppose as long as we define a configurable meta-data transcoder, I can live with making the meta-data IDs fixed by the LFB definition. Just for completeness, I do have one other concern. If we make the meta-data ID fixed, then the LFB designer has to figure out what id makes sense for any meta-data he generates, and what ids are assigned for meta-data he wants. This means that the process of defining an LFB is now intertwined much more tightly with the definition of other existing or new LFB definitions. Yours, Joel At 05:33 PM 7/23/2005, Khosravi, Hormuzd M wrote: >My thinking would be the latter (below). We should strive to keep the >model, lfb library, etc relatively simple atleast for the first rev...we >can add more flexibility for the second rev as we learn more from >different usage scenarios and implementation experiences. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Saturday, July 23, 2005 2:17 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue32] Packet Redirect > >It is certainly attractive to simply define for a given LFB what >meta-data >ID it uses / produces. >If we want to take that approach, then we are going to frequently need >to >make use of meta-data transcoders whose only function is to take >meta-data >of ID x and turn it into meta-data of ID y. >This comes up because one could easily have a classifier that uses >"port" >(say ID 12), but a tunnel processor that produces "tunnel-id" (say id >34). And the CE wants the classifier to use the tunnel ID as the port >for >its work. > >If we believe that the significant majority of the time we can get the >IDs >right, then the LFB definition can include the meta-data ID. I am >doubtful. > >Yours, >Joel > >At 04:39 PM 7/23/2005, Khosravi, Hormuzd M wrote: > >Joel, > > > >I did some thinking on this and I couldn't see how having configurable > >meta-data would make things simpler for the protocol or model. Having > >unique meta-data IDs per LFB is a much more simpler approach IMHO. I > >don't think this list will be very large and this way seems to be more > >manageable to me...its in line with our common philosophy of keeping > >things simple atleast for the 1st rev of the protocol/model. > > > >My 2 cents > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Sunday, July 17, 2005 2:25 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue32] Packet Redirect > > > >This was a topic of major discussion within the model team. > >The cases which drive it get complex. > > > >Firstly, there is the simple case of a meta-data classfiier. This > >accepts > >packets on its input, looks at their meta-data, and selects the output. > >Clearly, such an LFB must have a selectable meta-data usage, so that >you > > > >can use if after the port-id, or after the DSCP selection, or ... > > > >Then, we get into more complex situations. SUppse that we want to have > >the > >output port of an LFB selected by a piece of meta-data. We could try >to > > > >assign globally unique IDs, and define the meta-data ID that this LFB > >uses. > >At the same time we have the LPM lfb which produces an extress > >interface, > >possibly a port, and possibly some next hope identifying information. > >We > >could try to define which of those correspond with the output port > >Identifier. > >And we could ensure it was different from the input port identifier. > >But then someone defines a new LFB that sometimes wants to use next-hop > >ID > >and sometimes wants to use port-ID (maybe to cope differently with > >p-to-p > >interfaces). > >And gradually we add more LFBs, and they want different meta-data >values > >to > >match, etc. > >We would (and may eventually anyway) need to create a meta-data > >rewireter > >that by configuration copies values from certain meta-data items to > >certain > >other meta-data items. > >That will work. > > > >Or we take the approach that the identifier (not the semantics, just >the > > > >identifier) of the meta-data item used or produced by each LFB needs to > >be > >configured. > > > >This whole issue is finessed in the model. My own feeling is that >since > > > >some items will necessarily require configurable meta-data handling, it > >seems much simpler to always se configurable meta-data selection. > > > >Yours, > >Joel > > > >PS: I Steve, Zsolt, and Alan did more thinking on this than I, but >their > > > >thinking never got into the document. They probably have a better idea > >of > >what is really needed and why. > > > >At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: > > >Joel, > > > > > >I am not sure I understand why the Identifiers will be assigned by >the > > >CE? > > >Isnt this just another Type that will be defined in the Model...e.g. > > >Id=Port, metadata value=port_id > > > > > >Let me know what I am missing here, > > > > > >Thanks > > >Hormuzd > > > > > >-----Original Message----- > > > > > >This looks good to me. > > >My only quibble (minor difference) is with the description that the > > >identifier portion of the meta-data ILV is assigned by the model. We > > >have > > >not worked this out, but I think that the identifiers are probably > >going > > >to > > >end up assigned by the CE. > > >(The implication of this is that if one CE takes over for another, it > > >may > > >have to do some analysis to get the meanings for the meta-data > > >identifiers. But it should be simple to find the LFBs where the > > >meta-data > > >is created, and determine what ID is configured to be used for it. >And > > >this needs to be described somewhere in either the model or the > >protocol > > > > > >document. I think it will go in the meta-data portion of the model > > >draft.) > > > > > >Yours, > > >Joel From owner-forces@PEACH.EASE.LSOFT.COM Sun Jul 24 01:27:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwZ11-00058L-Ec for forces-archive@megatron.ietf.org; Sun, 24 Jul 2005 01:27: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 BAA12675 for ; Sun, 24 Jul 2005 01:27:06 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwZVX-0003VB-Sc for forces-archive@IETF.ORG; Sun, 24 Jul 2005 01:58: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 <14.010B221D@cherry.ease.lsoft.com>; 24 Jul 2005 1:27:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80207341 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 24 Jul 2005 01:27:00 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 24 Jul 2005 01:27:00 -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 j6O5R0pV018622; Sun, 24 Jul 2005 05:27:00 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 j6O5QvOA018489; Sun, 24 Jul 2005 05:27:00 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 M2005072322265710884 ; Sat, 23 Jul 2005 22:26:57 -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); Sat, 23 Jul 2005 22:26:57 -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] [issue32] Packet Redirect thread-index: AcWP9DI8JBYPQ39KQZ+h8qWCSS47pQAG1AFA X-OriginalArrivalTime: 24 Jul 2005 05:26:57.0600 (UTC) FILETIME=[4F67B400:01C59010] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0618E33F@orsmsx408> Date: Sat, 23 Jul 2005 22:26:56 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Yes, absolutely. LFB design cannot be done in seclusion, the designer has to think about other LFBs in the system that will work in conjunction with each other to provide a certain functionality. As per the ForCES charter, for the first rev of the model, lfb library, we should target LFBs to provide IPv4 forwarding and QoS functionality. We had discussed this long time back at the NPF and even at an IETF meeting I remember and Steve/Zsolt had a list of about 20 LFBs that were needed for this (IPv4 forwarding, Diffserv, Packet redirection, Ports, etc). regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Just for completeness, I do have one other concern. If we make the=20 meta-data ID fixed, then the LFB designer has to figure out what id makes=20 sense for any meta-data he generates, and what ids are assigned for=20 meta-data he wants. This means that the process of defining an LFB is now=20 intertwined much more tightly with the definition of other existing or new=20 LFB definitions. Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Thu Jul 28 11:32:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyANE-0006uN-BC for forces-archive@megatron.ietf.org; Thu, 28 Jul 2005 11:32: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 LAA05850 for ; Thu, 28 Jul 2005 11:32:37 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyAsi-0000dV-Dn for forces-archive@IETF.ORG; Thu, 28 Jul 2005 12:05: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 <5.010B774D@cherry.ease.lsoft.com>; Thu, 28 Jul 2005 11:32:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 80777382 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 28 Jul 2005 11:32:35 -0400 Received: from 195.212.29.134 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 28 Jul 2005 11:32:35 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6SFWYJP215582 for ; Thu, 28 Jul 2005 15:32:34 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 j6SFWYiw282604 for ; Thu, 28 Jul 2005 16:32:34 +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 j6SFWXhX017371 for ; Thu, 28 Jul 2005 16:32:33 +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 j6SFWXkT017360; Thu, 28 Jul 2005 16:32:33 +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 RAA50848; Thu, 28 Jul 2005 17:32:33 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E05FCC439@orsmsx408> 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.uk.ibm.com id j6SFWYJP215582 Approved-By: Robert Haas Message-ID: <42E8FA90.8030806@zurich.ibm.com> Date: Thu, 28 Jul 2005 17:32:32 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Result TLV Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05FCC439@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Hormuzd, Also, mention that the format is not necessarily one Path-data TLV and=20 one Result TLV: there could be multiple. Regards, -Robert Khosravi, Hormuzd M wrote: >Thanks for the clarification, Joel! That's completely fine with me. >So it looks like.... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D LFB select | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (SET-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path-data TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (DEL-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path-data TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >This is more granular and makes sense to me (what I would have expected >to see in the response). Therefore I asked for the clarification below. > >Regards >Hormuzd > >-----Original Message----- >From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 >Sent: Wednesday, July 13, 2005 12:34 PM >To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM >Subject: RE: [FORCES] Result TLV > >I would expect there to be path-data at least some of the time. >Assuming abbreviated responses (which are probably the norm) then for=20 >success it might suffice to just have one Result TLV, with no path-data. >I=20 >had not thought about allowing that. >If there are errors, there must at least be the path-data (possibly >several=20 >nested path-data TLVs) that identify the target of the operation which=20 >failed, to provide context for the error code in the Result TLV. >(Remember=20 >that there can be multiple path-data in the request, so the CE needs to=20 >know which thing failed.. >If we are in the try-all-operations mode, then at least each operation=20 >which failed will need its path-data. > >And if we instead use verbose responses, then I expect the response to >have=20 >all the path-data from the request, with result TLVs for each one=20 >indicating success or failure. > >Basically, I am just putting the Result-TLV into the path-data where the > >data-raw would have gone. > >Yours, >Joel > >At 12:30 PM 7/13/2005, Khosravi, Hormuzd M wrote: > =20 > >>Again a reasonable and simple approach to provide the Results. >> >>To put some more context around it, is this how it would look like in a >>Config Response message? >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type =3D LFB select | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | LFB Class ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | LFB Instance ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Operations (SET-RESP) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Result TLV | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Operations (DEL-RESP) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Result TLV | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >>Pls do clarify, No path-data tlv in this format? >> >>Thanks >>Hormuzd >> >>-----Original Message----- >>From: Forwarding and Control Element Separation >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >>Sent: Thursday, June 30, 2005 12:04 PM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: [FORCES] Result TLV >> >>The following is what I suggest for handling results of operations. >> >>SET and GET Requests do not have result information (they are >> =20 >> >requests). > =20 > >>SET and GET Responses have result information. >>SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. >> >>For a GET responses, individual gets which succeed will have DATARAW >>TLVs >>added to the leaf paths to carry the requested data. For GET elements >>that >>fail, instead of the DATARAW TLV there will be a RESULT TLV. >> >>For a SET response, each DATARAW TLV in the original request will be >>replace with a RESULT TLV in the response. >>If the request was for Ack-fail, then only those items which failed >> =20 >> >will > =20 > >>appear in the response. If the request was for ack-all, then all >>elements >>of the request will appear in the response with RESULT TLVs. >> >>A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 >>byte) >>value. >>The defined values are >> 0 =3D success >> 1 =3D no such object >> 2 =3D permission denied >> 3 =3D invalid value (the dataraw could not validly be stored in the >>field) >> 4 =3D invalid array creation (when the subscript in an array create >> =20 >> >is > =20 > >>not >>allowed) >> 255 =3D unspecified error (for when the FE can not decide what went >>wrong) >> >>We may need a few more values to cover other errors. >>Note that if a SET request with a structure in a DATARAW is issued, and >>some field in the structure is invalid, the FE will not attempt to >>indicate >>which field was invalid, but rather will indicate that the operation >>failed. >>Note further that if there are multiple errors in a single leaf >>path-data / >>DATARAW, the FE can select which error it chooses to return. So if a >>DATARAW for a SET of a structure attempts to write one field which is >>read >>only, and attempts to set another field to an invalid value, the FE can >>return whatever error it likes. >> >>Yours, >>Joel M. Halpern >> =20 >> > > > =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