From owner-forces@PEACH.EASE.LSOFT.COM  Wed May  1 20:40:16 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01471
	for <forces-archive@IETF.ORG>; Wed, 1 May 2002 20:40:16 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.005E8A45@cherry.ease.lsoft.com>; Wed, 1 May 2002 20:40:14 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 17334766 for FORCES@PEACH.EASE.LSOFT.COM;
          Wed, 1 May 2002 20:40:14 -0400
Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Wed, 1 May 2002 20:40:14 -0400
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by
          hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.42 2002/04/26
          23:25:13 root Exp $) with ESMTP id g420f1H02947 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 2 May 2002 00:41:07 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com
          [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.17 2002/04/27 00:24:04 root Exp $) with SMTP id
          g420cLx03322 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 2 May 2002
          00:38:21 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by
          fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002050117392405816 for <FORCES@PEACH.EASE.LSOFT.COM>; Wed, 01 May
          2002 17:39:24 -0700
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <J8XW03H1>; Wed, 1 May 2002 17:40:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Khosravi, Hormuzd M" <hormuzd.m.khosravi@INTEL.COM>
Message-ID:  <D9223EB959A5D511A98F00508B68C20C0596CDA5@ORSMSX108>
Date:         Wed, 1 May 2002 17:39:59 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
Subject:      Re: I-D ACTION:draft-ietf-forces-requirements-03.txt
To: FORCES@PEACH.EASE.LSOFT.COM

The design team has put together the new revision of the Requirements draft.
We have tried to incorporate all the comments that we received for the last
version. I think the draft is in good shape and would like to last call it.
Any comments ?

Hormuzd
-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, April 30, 2002 4:15 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: [FORCES] I-D ACTION:draft-ietf-forces-requirements-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Forwarding and Control Element Separation
Working Group of the IETF.

        Title           : Requirements for Separation of IP Control and
                          Forwarding
        Author(s)       : T. Anderson et al.
        Filename        : draft-ietf-forces-requirements-03.txt
        Pages           : 15
        Date            : 29-Apr-02

This document introduces the ForCES architecture and defines a set
of associated terminology.  This document also defines a set of
architectural, modeling, and protocol requirements to logically
separate the control and data forwarding planes of an IP (IPv4,
IPv6, etc.) networking device.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-forces-requirements-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-forces-requirements-03.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May  2 09:06:00 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21559
	for <forces-archive@IETF.ORG>; Thu, 2 May 2002 09:05:59 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.005E9CF9@cherry.ease.lsoft.com>; Thu, 2 May 2002 9:06:00 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 17386184 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 2 May 2002 09:05:59 -0400
Received: from 209.238.9.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 2 May 2002 09:05:58 -0400
Received: from 208.55.110.97 (208.55.110.97) by mail07a.vwh1.net (RS ver
          1.0.63s) with SMTP id 022941 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu,
          2 May 2002 09:05:57 -0400 (EDT)
Received: from 192.168.0.116 ([192.168.0.116]) by mail (WinRoute Pro 4.1.27)
          with SMTP; Thu, 2 May 2002 08:50:06 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Loop-Detect: 1
Approved-By:  Vip Sharma <vsharma@ZAGROSNETWORKS.COM>
Message-ID:  <002401c1f1d8$f2dd1690$7400a8c0@zagrosnetworks.com>
Date:         Thu, 2 May 2002 08:57:43 -0400
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Vip Sharma <vsharma@zagrosnetworks.com>
Subject:      Re: I-D ACTION:draft-ietf-forces-requirements-03.txt
To: FORCES@PEACH.EASE.LSOFT.COM
In-Reply-To:  <D9223EB959A5D511A98F00508B68C20C0596CDA5@ORSMSX108>
Content-Transfer-Encoding: 7bit

Hormuzd,
        I agree with your summarry of the reqmnt. Draft... That it is
ready for last call..

vip

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Khosravi, Hormuzd M
Sent: Wednesday, May 01, 2002 8:40 PM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: I-D ACTION:draft-ietf-forces-requirements-03.txt


The design team has put together the new revision of the Requirements
draft.
We have tried to incorporate all the comments that we received for the
last
version. I think the draft is in good shape and would like to last call
it.
Any comments ?

Hormuzd
-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, April 30, 2002 4:15 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: [FORCES] I-D ACTION:draft-ietf-forces-requirements-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Forwarding and Control Element
Separation
Working Group of the IETF.

        Title           : Requirements for Separation of IP Control and
                          Forwarding
        Author(s)       : T. Anderson et al.
        Filename        : draft-ietf-forces-requirements-03.txt
        Pages           : 15
        Date            : 29-Apr-02

This document introduces the ForCES architecture and defines a set
of associated terminology.  This document also defines a set of
architectural, modeling, and protocol requirements to logically
separate the control and data forwarding planes of an IP (IPv4,
IPv6, etc.) networking device.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.tx
t

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-forces-requirements-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-forces-requirements-03.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail
readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


From owner-forces@PEACH.EASE.LSOFT.COM  Mon May  6 12:12:21 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25088
	for <forces-archive@IETF.ORG>; Mon, 6 May 2002 12:12:20 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.005F379E@cherry.ease.lsoft.com>; Mon, 6 May 2002 12:12:20 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 17704197 for FORCES@PEACH.EASE.LSOFT.COM;
          Mon, 6 May 2002 12:12:20 -0400
Received: from 134.134.248.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Mon, 6 May 2002 12:12:19 -0400
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com
          [192.168.65.206]) by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v
          1.37 2002/05/03 22:08:52 root Exp $) with SMTP id g46GCIc17479 for
          <forces@peach.ease.lsoft.com>; Mon, 6 May 2002 16:12:18 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by
          orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002050609195427001 for <forces@peach.ease.lsoft.com>; Mon, 06 May
          2002 09:19:54 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id
          <KHX2KC0C>; Mon, 6 May 2002 09:12:18 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1F518.CA395620"
Approved-By:  "Putzolu, David" <david.putzolu@INTEL.COM>
Message-ID:  <FD2423AA68A7D511A5A20002A50729E1027246E3@orsmsx115.jf.intel.com>
Date:         Mon, 6 May 2002 09:12:16 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Putzolu, David" <david.putzolu@intel.com>
Subject:      ForCES Supplemental Home Page Revamped
To: FORCES@PEACH.EASE.LSOFT.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F518.CA395620
Content-Type: text/plain

All,

The ForCES supplemental home page has been revamped to include
significantly more information about the state of various documents
related to ForCES.  I will be updating this page regularly with a list of
working open issues and draft status.  URL:

http://www.sstanamera.com/~forces/index.html
<http://www.sstanamera.com/~forces/index.html>

This page is also now linked to by the IETF ForCES charter webpage.

Cheers,
David Putzolu

------_=_NextPart_001_01C1F518.CA395620
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>ForCES Supplemental Home Page Revamped</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The ForCES supplemental home page has =
been revamped to include</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">significantly more information about =
the state of various documents</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">related to ForCES.&nbsp; I will be =
updating this page regularly with a list of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">working open issues and draft =
status.&nbsp; URL:</FONT>
</P>

<P><A HREF=3D"http://www.sstanamera.com/~forces/index.html"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.sstanamera.com/~forces/index.html</FONT></U></=
A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This page is also now linked to by the =
IETF ForCES charter webpage.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">David Putzolu</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F518.CA395620--


From owner-forces@PEACH.EASE.LSOFT.COM  Mon May  6 12:14:57 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25237
	for <forces-archive@IETF.ORG>; Mon, 6 May 2002 12:14:56 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.005F379A@cherry.ease.lsoft.com>; Mon, 6 May 2002 12:15:02 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 17704311 for FORCES@PEACH.EASE.LSOFT.COM;
          Mon, 6 May 2002 12:14:41 -0400
Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Mon, 6 May 2002 12:14:41 -0400
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by
          hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.45 2002/05/03
          22:11:31 root Exp $) with ESMTP id g46GFUg25252 for
          <forces@peach.ease.lsoft.com>; Mon, 6 May 2002 16:15:30 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com
          [132.233.48.108]) by talaria.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.18 2002/05/02 20:17:19 root Exp $) with SMTP id
          g46GHFq04173 for <forces@peach.ease.lsoft.com>; Mon, 6 May 2002
          16:17:15 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by
          fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002050609140222249 for <forces@peach.ease.lsoft.com>; Mon, 06 May
          2002 09:14:02 -0700
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <KG0TM70V>; Mon, 6 May 2002 09:14:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1F519.1EB01BD0"
Approved-By:  "Putzolu, David" <david.putzolu@INTEL.COM>
Message-ID:  <FD2423AA68A7D511A5A20002A50729E1027246E4@orsmsx115.jf.intel.com>
Date:         Mon, 6 May 2002 09:14:38 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Putzolu, David" <david.putzolu@intel.com>
Subject:      Requirements Issue Summary: High Availability
To: FORCES@PEACH.EASE.LSOFT.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F519.1EB01BD0
Content-Type: text/plain

All,

The topic of high availability has been discussed over the
last few weeks on the mailing list and by the requirements
design team. URLs:

http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0204&L=forces#4
<http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0204&L=forces#4>
http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0203&L=forces#5
<http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0203&L=forces#5>

The design team has responded in version 03 of the
requirements by removing the vague wording and replacing it
with text about CE redundancy and failover support.
Section 5 item 7 and section 7 of the requirements where
revved and this rev was uploaded last week.  These changes
reflect the consensus of the design team and the
discussions on the list, so I am moving it to "closed" status
on the web page barring any last comments. URL:

http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt
<http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt>

Cheers,
David

------_=_NextPart_001_01C1F519.1EB01BD0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Requirements Issue Summary: High Availability</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The topic of high availability has =
been discussed over the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">last few weeks on the mailing list =
and by the requirements</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">design team. URLs:</FONT>
</P>

<P><A =
HREF=3D"http://peach.ease.lsoft.com/scripts/wa.exe?A1=3Dind0204%26L=3Dfo=
rces#4"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://peach.ease.lsoft.com/scripts/wa.exe?A1=3Dind0204&a=
mp;L=3Dforces#4</FONT></U></A>
<BR><A =
HREF=3D"http://peach.ease.lsoft.com/scripts/wa.exe?A1=3Dind0203%26L=3Dfo=
rces#5"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://peach.ease.lsoft.com/scripts/wa.exe?A1=3Dind0203&a=
mp;L=3Dforces#5</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The design team has responded in =
version 03 of the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">requirements by removing the vague =
wording and replacing it </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with text about CE redundancy and =
failover support.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Section 5 item 7 and section 7 of the =
requirements where </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">revved and this rev was uploaded last =
week.&nbsp; These changes </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">reflect the consensus of the design =
team and the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">discussions on the list, so I am =
moving it to &quot;closed&quot; status </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">on the web page barring any last =
comments. URL:</FONT>
</P>

<P><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-forces-requiremen=
ts-03.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-forces-req=
uirements-03.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">David</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F519.1EB01BD0--


From owner-forces@PEACH.EASE.LSOFT.COM  Mon May  6 13:24:29 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28360
	for <forces-archive@IETF.ORG>; Mon, 6 May 2002 13:24:29 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.005F3911@cherry.ease.lsoft.com>; Mon, 6 May 2002 13:24:36 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 17707381 for FORCES@PEACH.EASE.LSOFT.COM;
          Mon, 6 May 2002 13:24:00 -0400
Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Mon, 6 May 2002 13:23:59 -0400
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by
          caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.45 2002/05/03
          22:11:31 root Exp $) with ESMTP id g46HMvR26653 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Mon, 6 May 2002 17:22:57 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com
          [132.233.48.108]) by talaria.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.18 2002/05/02 20:17:19 root Exp $) with SMTP id
          g46HQSu25273 for <FORCES@PEACH.EASE.LSOFT.COM>; Mon, 6 May 2002
          17:26:28 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by
          fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002050610231417584 for <FORCES@PEACH.EASE.LSOFT.COM>; Mon, 06 May
          2002 10:23:14 -0700
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <KG0TNJTF>; Mon, 6 May 2002 10:23:52 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Approved-By:  "Putzolu, David" <david.putzolu@INTEL.COM>
Message-ID:  <FD2423AA68A7D511A5A20002A50729E1027246E7@orsmsx115.jf.intel.com>
Date:         Mon, 6 May 2002 10:23:51 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Putzolu, David" <david.putzolu@intel.com>
Subject:      URL weirdness (was: RE: [FORCES] Requirements Issue Summary: High
              Availability)
To: FORCES@PEACH.EASE.LSOFT.COM

All,

I just learned of some weirdness with this email.
If you are using Microsoft OutlookXP and WindowsXP,
and you click on the lsoft URLs below, you will get
an error.  However, if you copy the URL, then paste
it into your browser, the URL works fine.

Can't explain it, but if anyone is scratching their
heads trying to get to those URLs, just cut-and-paste
the URL into your browser and it should work.

Cheers,
David


-----Original Message-----
From: Putzolu, David [mailto:david.putzolu@intel.com]
Sent: Monday, May 06, 2002 9:15 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: [FORCES] Requirements Issue Summary: High Availability


All,
The topic of high availability has been discussed over the
last few weeks on the mailing list and by the requirements
design team. URLs:
http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0204&L=forces#4
http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0203&L=forces#5
The design team has responded in version 03 of the
requirements by removing the vague wording and replacing it
with text about CE redundancy and failover support.
Section 5 item 7 and section 7 of the requirements where
revved and this rev was uploaded last week.  These changes
reflect the consensus of the design team and the
discussions on the list, so I am moving it to "closed" status
on the web page barring any last comments. URL:
http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt
Cheers,
David


From owner-forces@PEACH.EASE.LSOFT.COM  Tue May  7 12:15:42 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14239
	for <forces-archive@IETF.ORG>; Tue, 7 May 2002 12:15:42 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.005F619B@cherry.ease.lsoft.com>; Tue, 7 May 2002 12:15:44 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 17799815 for FORCES@PEACH.EASE.LSOFT.COM;
          Tue, 7 May 2002 12:15:42 -0400
Received: from 134.134.248.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Tue, 7 May 2002 12:15:42 -0400
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com
          [192.168.65.206]) by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v
          1.37 2002/05/03 22:08:52 root Exp $) with SMTP id g47GFe609946 for
          <forces@peach.ease.lsoft.com>; Tue, 7 May 2002 16:15:40 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by
          orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002050709231800684 for <forces@peach.ease.lsoft.com>; Tue, 07 May
          2002 09:23:18 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id
          <KHX2QDJ5>; Tue, 7 May 2002 09:15:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Approved-By:  "Putzolu, David" <david.putzolu@INTEL.COM>
Message-ID:  <FD2423AA68A7D511A5A20002A50729E1027246F0@orsmsx115.jf.intel.com>
Date:         Tue, 7 May 2002 09:15:35 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Putzolu, David" <david.putzolu@intel.com>
Subject:      FW: IEEE T-SMC CFP: Technologies that promote computational intel
              ligence,
              openness and programmability in networks and Internet services
To: FORCES@PEACH.EASE.LSOFT.COM

Forwarded as potentially relevant to ForCES.

Cheers,
David


> -----Original Message-----
> From: S. Karnouskos [mailto:karnouskos@fokus.fhg.de]
> Sent: Tuesday, May 07, 2002 3:49 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: IEEE T-SMC CFP: Technologies that promote
> computational intelligence, openness and programmability in
> networks and Internet services
>
>
>
> Dear Ladies and Gentlemen,
>
> This might be of interest to ForCES WG members.
> We are looking for papers for the following CFP.
> Please feel free to further forward it to people you think
> might be interested in it.
>
> Best Regards,
> Stamatis Karnouskos
>
>
> --------------------------------------------------------------
> --------------
>
>
>       IEEE - Transactions on Systems, Man and Cybernetics
>
>                 Call for Papers - Special Issue on
>
>      Technologies that promote computational intelligence,
> openness and
>              programmability in networks and Internet services
>
>
>
>
> Guest Editors:
>
>    * W. Pedrycz (Univ. of Alberta, Canada),
>    * A. Vasilakos (Hellenic Aerospace Industry,S.A.),
>    * S. Karnouskos (Fraunhofer-FOKUS, Germany)
>
>  Publication: Winter 2002
>
> The Internet has witnessed the last years a rapid increase in
> its popularity, by offering new services to its users.
> However the increased complexity of the systems, the growing
> needs for flexibility, fault-tolerance, higher quality of
> service, interoperability, security, reduced time-to-market
> service introduction and personalization, demand the
> development of sophisticated technologies that are capable of
> dealing effectively with these challenges.
>
> Active and programmable networking aims at easing the
> introduction of new network services by adding dynamic
> programmability to network devices and making aspects of the
> programmability accessible to third-party vendors and users
> via open interfaces. Open and programmable network elements
> are redefining network software architectures and move
> control and management systems away from traditional
> closed/rigid solutions.
>
> Computational Intelligence (CI) is viewed as a synergy of
> technologies of granular computing (especially fuzzy sets),
> neural networks and evolutionary computing has become an
> ideal design vehicle supporting the design of intelligent
> systems. In this capacity, the role of CI in the development
> of the sophisticated network architectures is profound. The
> main objective of this special issue of the IEEE T-SMC
> Journal is to act as a channel that brings the ideas of CI to
> the network area in a systematic, coherent and comprehensive fashion.
>
> Authors are encouraged to submit high-quality original papers
> dealing with various theoretical and practical issues dealing
> with Computational Intelligence, active networking,
> intelligent mobile agents,
> openness/portability/interoperability of services, middleware
> for intelligent service creation, deployment and management
> of new network applications etc.
>
>
> Within the context of this special issue, topics of
> particular interest include but are not limited to:
>
>         *  Active and Programmable Networks
>         *  Service creation platforms and enabling technologies
>         *  Telecommunication Network Architectures
>         *  Communications Security, Privacy and Manageability
>         *  Integrated Services
>         *  Dynamic, data-driven application systems
>         *  Service dissemination and discovery protocols
>         *  Programming paradigms, applications, and requirements for
>            active grids
>         *  Nomadic User Support and management
>         *  Web based systems and services
>         *  Global Service Portability
>         *  Emerging Technologies and directions
>         *  Internet & Telecom applications and services
>         *  Neural Networks
>         *  Fuzzy Logic
>         *  Genetic Algorithms & Programming
>         *  Data Mining Techniques
>         *  Adaptive Computing Systems
>         *  Knowledge Based Systems
>         *  Hybrid Intelligent Systems
>
> IMPORTANT DATES
>
>          Submission:  1st  July 2002
>  Acceptance decision: 30th  Oct 2002
>     Final paper due:  31st   Dec 2002
>    Publication date:  Winter 2002
>
> SUBMISSION GUIDELINES
>
> Authors are invited to submit full papers, following the
> templates available from the publisher in electronic form
> (PDF preferred) to the Guest Editor at the following address:
>
>      Prof. Witold Pedrycz
>      Department of Electrical & Computer Engineering
>      University of Alberta
>      Edmonton T6R 2G7 Canada
>
> Or to send an electronic copy via e-mail or the URL from
> where the file can be downloaded, to any of the guest editors:
>
>    *  W. Pedrycz  pedrycz@ee.ualberta.ca,
>    *  A. Vasilakos  vasilako@ath.forthnet.gr,
>    *  S. Karnouskos karnouskos@fokus.fhg.de.
>
> Please include keywords identifying the main topic of your
> paper. Full details of submission or further information are
> available from the journal's web site
> http://www.isye.gatech.edu/ieee-smc.
>
> This CFP is also
> available in HTML, PDF and plain
> text  format from
> http://www.fokus.fhg.de/usr/karnouskos/private> /cfp/smc/
>
>
>
>
>
> ----------------------------------------------------------
>  Stamatis Karnouskos  - Fraunhofer FOKUS
>  Research Institute for Open Communication Systems
>
 mailto:karnouskos@fokus.fhg.de   http://www.fokus.fhg.de
 Phone: +49-30-34637172           FAX: +49-30-34638172
----------------------------------------------------------


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May  9 18:44:18 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12411
	for <forces-archive@IETF.ORG>; Thu, 9 May 2002 18:44:17 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.005FB7C6@cherry.ease.lsoft.com>; Thu, 9 May 2002 18:44:20 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18035102 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 9 May 2002 18:44:19 -0400
Received: from 134.134.248.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 9 May 2002 18:44:18 -0400
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com
          [192.168.65.206]) by ganymede.or.intel.com (8.11.6/8.11.6/d:
          solo.mc,v 1.38 2002/05/09 18:12:41 root Exp $) with SMTP id
          g49MiH800916 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 9 May 2002
          22:44:17 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by
          orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002050915515820298 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 09 May
          2002 15:51:58 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id
          <KHX20T3Z>; Thu, 9 May 2002 15:44:17 -0700
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Approved-By:  "Putzolu, David" <david.putzolu@INTEL.COM>
Message-ID:  <FD2423AA68A7D511A5A20002A50729E102724714@orsmsx115.jf.intel.com>
Date:         Thu, 9 May 2002 15:44:12 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Putzolu, David" <david.putzolu@intel.com>
Subject:      WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 10-24
To: FORCES@PEACH.EASE.LSOFT.COM

All,

This message marks the beginning of a last call
for the ForCES requirements document.

The last call period begins immediately and lasts
until Friday, May 24th, 2002, at midnight GMT.

Document URL:
http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt

Thanks,
David


From owner-forces@PEACH.EASE.LSOFT.COM  Wed May 15 05:27:46 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22737
	for <forces-archive@IETF.ORG>; Wed, 15 May 2002 05:27:45 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00606548@cherry.ease.lsoft.com>; Wed, 15 May 2002 5:27:45 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18497267 for FORCES@PEACH.EASE.LSOFT.COM;
          Wed, 15 May 2002 05:27:45 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Wed, 15 May 2002 05:27:45 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <KG6F8CK7>; Wed, 15 May 2002 05:23:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  Shyam prasad <shyamp@NETPLANE.COM>
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A32842B24F@india_exch.hyderabad.mindspeed.com>
Date:         Wed, 15 May 2002 05:27:31 -0400
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Shyam prasad <shyamp@netplane.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1
              0-24
To: FORCES@PEACH.EASE.LSOFT.COM

Hi all,

I have a few questions/comments on the draft. I am new to this group. Sorry
if the questions are elementary ones.

1. Are CEs and FEs expected to be part of a single system? If the answer is
yes, isn't implementing security mechanisms such as IPSec/IKE for ForCES
protocol an overkill?

2. The requirements draft does not mention FE redundancy and failover. I
think FE redundancy support would involve certain amount of CE-FE control
messaging if CE is viewed as the master and FE, the slave.

3. Section 5, point #6 says that an FE MUST be able to asynchronously inform
the CE an increase/decrease in available resources or capabilities on the
FE. Can this requirement be extended to enable FEs to notify failures (port
failure, internal fault, etc.)?

Thanks.
Shyam


> -----Original Message-----
> From: Putzolu, David [mailto:david.putzolu@intel.com]
> Sent: Friday, May 10, 2002 4:14 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> 10-24
> Importance: High
>
>
> All,
>
> This message marks the beginning of a last call
> for the ForCES requirements document.
>
> The last call period begins immediately and lasts
> until Friday, May 24th, 2002, at midnight GMT.
>
> Document URL:
> http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem
ents-03.txt

Thanks,
David


From owner-forces@PEACH.EASE.LSOFT.COM  Wed May 15 07:21:27 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26130
	for <forces-archive@IETF.ORG>; Wed, 15 May 2002 07:21:26 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006065EE@cherry.ease.lsoft.com>; Wed, 15 May 2002 7:21:39 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18504326 for FORCES@PEACH.EASE.LSOFT.COM;
          Wed, 15 May 2002 07:21:31 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Wed, 15 May 2002 07:11:31 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA25612; Wed, 15 May 2002 07:11:17
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Approved-By:  nsyracus@CNRI.RESTON.VA.US
Message-ID:  <200205151111.HAA25612@ietf.org>
Date:         Wed, 15 May 2002 07:11:16 -0400
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      I-D ACTION:draft-anderson-forces-arch-01.txt
To: FORCES@PEACH.EASE.LSOFT.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : ForCES Architectural Framework
        Author(s)       : T. Anderson, L. Yang, R. Dantu
        Filename        : draft-anderson-forces-arch-01.txt
        Pages           : 20
        Date            : 14-May-02

This document defines the architectural framework for ForCES network
elements (NE), associated entities and the interaction among them.
The architecture defined herein is intended to satisfy the
requirements specified in the ForCES requirements draft [FORCES-
REQ].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-anderson-forces-arch-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-anderson-forces-arch-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20020514141822.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-anderson-forces-arch-01.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-anderson-forces-arch-01.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20020514141822.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-forces@PEACH.EASE.LSOFT.COM  Wed May 15 17:07:36 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22239
	for <forces-archive@IETF.ORG>; Wed, 15 May 2002 17:07:36 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00607813@cherry.ease.lsoft.com>; Wed, 15 May 2002 17:07:49 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18546933 for FORCES@PEACH.EASE.LSOFT.COM;
          Wed, 15 May 2002 17:07:45 -0400
Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d)
          with TCP; Wed, 15 May 2002 17:07:44 -0400
Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com
          (8.10.2/8.10.2) with ESMTP id g4FL7iP02575 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Wed, 15 May 2002 16:07:44 -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A32842B24F@india_exch.hyderabad.mindspeed.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Alex Audu <Alex.Audu@ALCATEL.COM>
Message-ID:  <3CE2CE30.EB6FDC17@alcatel.com>
Date:         Wed, 15 May 2002 16:08:00 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Alex Audu <Alex.Audu@alcatel.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
              10-24
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 7bit

Shyam,

See below for  comments that may answer some of your questions.

Regards,
Alex.

Shyam prasad wrote:

> Hi all,
>
> I have a few questions/comments on the draft. I am new to this group. Sorry
> if the questions are elementary ones.
>
> 1. Are CEs and FEs expected to be part of a single system? If the answer is
> yes, isn't implementing security mechanisms such as IPSec/IKE for ForCES
> protocol an overkill?
>

Section 7.4 (Multihop)  states that CE and FE may be seperated by more than
one hop. This may justify use of IPSec/IKE.

>
> 2. The requirements draft does not mention FE redundancy and failover. I
> think FE redundancy support would involve certain amount of CE-FE control
> messaging if CE is viewed as the master and FE, the slave.
>

See section 7.8 (CE Redundancy or CE Failover). I think this section also covers

FE redundancy/failover.

>
> 3. Section 5, point #6 says that an FE MUST be able to asynchronously inform
> the CE an increase/decrease in available resources or capabilities on the
> FE. Can this requirement be extended to enable FEs to notify failures (port
> failure, internal fault, etc.)?
>
> Thanks.
> Shyam
>
> > -----Original Message-----
> > From: Putzolu, David [mailto:david.putzolu@intel.com]
> > Sent: Friday, May 10, 2002 4:14 AM
> > To: FORCES@PEACH.EASE.LSOFT.COM
> > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> > 10-24
> > Importance: High
> >
> >
> > All,
> >
> > This message marks the beginning of a last call
> > for the ForCES requirements document.
> >
> > The last call period begins immediately and lasts
> > until Friday, May 24th, 2002, at midnight GMT.
> >
> > Document URL:
> > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem
> ents-03.txt
>
> Thanks,
> David


From owner-forces@PEACH.EASE.LSOFT.COM  Wed May 15 17:37:23 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23031
	for <forces-archive@IETF.ORG>; Wed, 15 May 2002 17:37:23 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0060784F@cherry.ease.lsoft.com>; Wed, 15 May 2002 17:37:37 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18549165 for FORCES@PEACH.EASE.LSOFT.COM;
          Wed, 15 May 2002 17:37:36 -0400
Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Wed, 15 May 2002 17:37:35 -0400
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by
          hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09
          18:12:26 root Exp $) with ESMTP id g4FLc6S29145 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Wed, 15 May 2002 21:38:06 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com
          [132.233.48.108]) by talaria.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id
          g4FLeJ926075 for <FORCES@PEACH.EASE.LSOFT.COM>; Wed, 15 May 2002
          21:40:21 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by
          fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002051514362700980 for <FORCES@PEACH.EASE.LSOFT.COM>; Wed, 15 May
          2002 14:36:27 -0700
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <K8BTWA11>; Wed, 15 May 2002 14:37:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Khosravi, Hormuzd M" <hormuzd.m.khosravi@INTEL.COM>
Message-ID:  <D9223EB959A5D511A98F00508B68C20C0C694F80@orsmsx108.jf.intel.com>
Date:         Wed, 15 May 2002 14:37:00 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - May
              10-24
To: FORCES@PEACH.EASE.LSOFT.COM

Thanks for the comments, Alex.
I'll try to answer the 3rd question below.

Hormuzd

Shyam prasad wrote:

> Hi all,
>
> I have a few questions/comments on the draft. I am new to this group.
Sorry
> if the questions are elementary ones.
>
> 1. Are CEs and FEs expected to be part of a single system? If the answer
is
> yes, isn't implementing security mechanisms such as IPSec/IKE for ForCES
> protocol an overkill?
>

Section 7.4 (Multihop)  states that CE and FE may be seperated by more than
one hop. This may justify use of IPSec/IKE.

>
> 2. The requirements draft does not mention FE redundancy and failover. I
> think FE redundancy support would involve certain amount of CE-FE control
> messaging if CE is viewed as the master and FE, the slave.
>

See section 7.8 (CE Redundancy or CE Failover). I think this section also
covers

FE redundancy/failover.

>
> 3. Section 5, point #6 says that an FE MUST be able to asynchronously
inform
> the CE an increase/decrease in available resources or capabilities on the
> FE. Can this requirement be extended to enable FEs to notify failures
(port
> failure, internal fault, etc.)?
>
[HK] This requirement & section 7 #13 is suppose to cover any failure
notification
by the FE. The example talks about change in the number of ports (port down
event).

> Thanks.
> Shyam
>


From owner-forces@PEACH.EASE.LSOFT.COM  Wed May 15 17:40:07 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23123
	for <forces-archive@IETF.ORG>; Wed, 15 May 2002 17:40:07 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00607889@cherry.ease.lsoft.com>; Wed, 15 May 2002 17:40:21 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18549284 for FORCES@PEACH.EASE.LSOFT.COM;
          Wed, 15 May 2002 17:40:20 -0400
Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Wed, 15 May 2002 17:40:20 -0400
Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com
          (8.10.2/8.10.2) with ESMTP id g4FLeK404541 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Wed, 15 May 2002 16:40:20 -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Alex Audu <Alex.Audu@ALCATEL.COM>
Message-ID:  <3CE2D5D4.3243FF52@alcatel.com>
Date:         Wed, 15 May 2002 16:40:36 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Alex Audu <Alex.Audu@alcatel.com>
Subject:      WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1 0-24
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 7bit

David,

I am new to this mailing list, though I have been following the FORCes
effort for a while
and I have the comments about the requirements draft.

Section 6 (FE Model Requirements) . Since the logical functions of the
FE can be programmed
or selected by the CE,  it also makes sense to allow the capabilities of
those logical functions
to be programmed by the CE.  That way, it may not be necessary for the
CE to querry for the
capabilities of the FE before using it (since it already knows this by
virtue of being the programmer).
Can you add language here to clarify this?

Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also
specify a minimum set of
functional/logical blocks every FE must contain? This will be akin to a
minimum toolset that
could be cobbled together to implement any of the main set of  packet
handling behaviors in a FE.

Also, are there any unique CE Model Requirements  identifiable?

Regards,
Alex.

> -----Original Message-----
> From: Putzolu, David [mailto:david.putzolu@intel.com]
> Sent: Friday, May 10, 2002 4:14 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> 10-24
> Importance: High
>
>
> All,
>
> This message marks the beginning of a last call
> for the ForCES requirements document.
>
> The last call period begins immediately and lasts
> until Friday, May 24th, 2002, at midnight GMT.
>
> Document URL:
> http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem
ents-03.txt

Thanks,
David


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 16 02:12:50 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14018
	for <forces-archive@IETF.ORG>; Thu, 16 May 2002 02:12:50 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00608C97@cherry.ease.lsoft.com>; Thu, 16 May 2002 2:13:03 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18585445 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 16 May 2002 02:13:01 -0400
Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 16 May 2002 02:13:01 -0400
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by
          caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09
          18:12:26 root Exp $) with ESMTP id g4G6BiH18417 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 16 May 2002 06:11:44 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com
          [132.233.48.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id
          g4G6B3o17375 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 16 May 2002
          06:11:03 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by
          fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002051523115511688 for <FORCES@PEACH.EASE.LSOFT.COM>; Wed, 15 May
          2002 23:11:55 -0700
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <K7DJCYCN>; Wed, 15 May 2002 23:12:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1FCA0.B57C3E70"
Approved-By:  "Yang, Lily L" <lily.l.yang@INTEL.COM>
Message-ID:  <D9223EB959A5D511A98F00508B68C20C07FDE4BC@orsmsx108.jf.intel.com>
Date:         Wed, 15 May 2002 23:12:51 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Yang, Lily L" <lily.l.yang@intel.com>
Subject:      FW: I-D ACTION:draft-anderson-forces-arch-01.txt
To: FORCES@PEACH.EASE.LSOFT.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C1FCA0.B57C3E70
Content-Type: text/plain;
        charset="iso-8859-1"

Hi, all --
We submitted version 01 of the framework draft last week after a major
rewrite:
* added more description and diagrams to illustrate different physical
configuration examples of ForCES CE/FE.
* added examples of FE topology.
* restructure the text to focus more on ForCES operation phases (pre- and
post- association, reestablishment, etc.)
* added examples to illustrate the handshake between CE and FE during these
operational phases.

please let us know what you think -- are these examples/diagrams useful?
Have we missed anything important? Any comments on the draft are welcome!

Thanks,
Lily

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, May 15, 2002 4:11 AM
Cc: forces@peach.ease.lsoft.com
Subject: I-D ACTION:draft-anderson-forces-arch-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title           : ForCES Architectural Framework
        Author(s)       : T. Anderson, L. Yang, R. Dantu
        Filename        : draft-anderson-forces-arch-01.txt
        Pages           : 20
        Date            : 14-May-02

This document defines the architectural framework for ForCES network
elements (NE), associated entities and the interaction among them.
The architecture defined herein is intended to satisfy the
requirements specified in the ForCES requirements draft [FORCES-
REQ].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-anderson-forces-arch-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-anderson-forces-arch-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------_=_NextPart_000_01C1FCA0.B57C3E70
Content-Type: message/rfc822

To: 
Subject: 
Date: Wed, 15 May 2002 23:12:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
        boundary="----_=_NextPart_002_01C1FCA0.B57C3E70"


------_=_NextPart_002_01C1FCA0.B57C3E70
Content-Type: text/plain



------_=_NextPart_002_01C1FCA0.B57C3E70
Content-Type: application/octet-stream;
        name="ATT25595"
Content-Disposition: attachment;
        filename="ATT25595"

Content-type: message/external-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20020514141822.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-anderson-forces-arch-01.txt

------_=_NextPart_002_01C1FCA0.B57C3E70
Content-Type: message/external-body;
        site="internet-drafts";
        dir="draft-anderson-forces-arch-01.txt";
        mode="ftp.ietf.org";
        access-type="anon-ftp"


------_=_NextPart_002_01C1FCA0.B57C3E70--

------_=_NextPart_000_01C1FCA0.B57C3E70--


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 16 02:29:19 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14229
	for <forces-archive@IETF.ORG>; Thu, 16 May 2002 02:29:18 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00608F49@cherry.ease.lsoft.com>; Thu, 16 May 2002 2:29:31 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18585793 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 16 May 2002 02:29:30 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 16 May 2002 02:29:29 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id <KG6F81SF>; Thu, 16 May 2002 02:25:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  Shyam prasad <shyamp@NETPLANE.COM>
Message-ID:  <E7E13AAF2F3ED41197C100508BD6A32842B258@india_exch.hyderabad.mindspeed.com>
Date:         Thu, 16 May 2002 02:29:11 -0400
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Shyam prasad <shyamp@netplane.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - May
              10-24
To: FORCES@PEACH.EASE.LSOFT.COM

Alex and Hormuzd,

Thanks for your responses. Please see my comments below:

> -----Original Message-----
> From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]
> Sent: Thursday, May 16, 2002 3:07 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t -
> May 10-24
>
>
> Thanks for the comments, Alex.
> I'll try to answer the 3rd question below.
>
> Hormuzd
>
> Shyam prasad wrote:
>
> > Hi all,
> >
> > I have a few questions/comments on the draft. I am new to
> this group.
> Sorry
> > if the questions are elementary ones.
> >
> > 1. Are CEs and FEs expected to be part of a single system?
> If the answer
> is
> > yes, isn't implementing security mechanisms such as
> IPSec/IKE for ForCES
> > protocol an overkill?
> >
>
> Section 7.4 (Multihop)  states that CE and FE may be
> seperated by more than
> one hop. This may justify use of IPSec/IKE.
>

The basic doubt still remains. CEs and FEs could be multiple hops away, they
could reside on multiple cards but are they components within a single box??


> >
> > 2. The requirements draft does not mention FE redundancy
> and failover. I
> > think FE redundancy support would involve certain amount of
> CE-FE control
> > messaging if CE is viewed as the master and FE, the slave.
> >
>
> See section 7.8 (CE Redundancy or CE Failover). I think this
> section also
> covers
>
> FE redundancy/failover.

Here's the text under 7.8 :
"The ForCES protocol MUST support mechanisms for CE redundancy or CE
   failover. This includes the ability for CEs and FEs to determine
   when there is a loss of association between them, ability to restore
   association and efficient state (re)synchronization mechanisms. This
   also includes the ability to preset the actions an FE will take in
   reaction to loss of association to its CE e.g., whether the FE will
   continue to forward packets or whether it will halt operations."

Even if this section is intended to include the FE redundancy requirement,
it's not so obvious. Can it be stated explicitly? Or could you add another
section for FE redundancy?

>
> >
> > 3. Section 5, point #6 says that an FE MUST be able to
> asynchronously
> inform
> > the CE an increase/decrease in available resources or
> capabilities on the
> > FE. Can this requirement be extended to enable FEs to
> notify failures
> (port
> > failure, internal fault, etc.)?
> >
> [HK] This requirement & section 7 #13 is suppose to cover any failure
> notification
> by the FE. The example talks about change in the number of
> ports (port down
> event).

Great! But can the verbiage be changed to explicitly state that all failure
notifications are supported and not just "increase/decrease in available
resources".

Thanks.
Shyam


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 16 10:02:55 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25276
	for <forces-archive@IETF.ORG>; Thu, 16 May 2002 10:02:55 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0060971B@cherry.ease.lsoft.com>; Thu, 16 May 2002 10:02:43 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18606799 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 16 May 2002 10:02:42 -0400
Received: from 208.2.156.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 16 May 2002 10:02:42 -0400
Received: from jzny.localdomain ([208.2.156.157]) by rollsroyce.znyx.com (Lotus
          Domino Release 5.0.7) with SMTP id 2002051607043200:1427 ; Thu, 16
          May 2002 07:04:32 -0700
X-Mailer: KMail [version 1.2]
References: <E7E13AAF2F3ED41197C100508BD6A32842B258@india_exch.hyderabad.mindspeed.com>
MIME-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on rollsroyce/Znyx(Release 5.0.7 |March 21,
             2001) at 05/16/2002 07:04:32 AM,
             Serialize by Router on rollsroyce/Znyx(Release 5.0.7 |March 21,
             2001) at 05/16/2002 07:04:34 AM
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  Jamal Hadi Salim <hadi@ZNYX.COM>
Message-ID:  <02051608044200.01153@jzny.localdomain>
Date:         Thu, 16 May 2002 08:04:42 -0400
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: Znyx Networks
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - May
              10-24
Comments: To: Shyam prasad <shyamp@netplane.com>
To: FORCES@PEACH.EASE.LSOFT.COM
In-Reply-To:  <E7E13AAF2F3ED41197C100508BD6A32842B258@india_exch.hyderabad.mindspeed.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA25276

On Thursday 16 May 2002 02:29, Shyam prasad wrote:

> >
> > Section 7.4 (Multihop)  states that CE and FE may be
> > seperated by more than
> > one hop. This may justify use of IPSec/IKE.
>
> The basic doubt still remains. CEs and FEs could be multiple hops away,
> they could reside on multiple cards but are they components within a single
> box??
>

I may have misunderstood what you are saying, but:
Do you see anything in the draft that precludes an NE being a single box? 


> > FE redundancy/failover.
>
> Here's the text under 7.8 :
> "The ForCES protocol MUST support mechanisms for CE redundancy or CE
>    failover. This includes the ability for CEs and FEs to determine
>    when there is a loss of association between them, ability to restore
>    association and efficient state (re)synchronization mechanisms. This
>    also includes the ability to preset the actions an FE will take in
>    reaction to loss of association to its CE e.g., whether the FE will
>    continue to forward packets or whether it will halt operations."
>
> Even if this section is intended to include the FE redundancy requirement,
> it's not so obvious. Can it be stated explicitly? Or could you add another
> section for FE redundancy?
>

Stating it explicitly opens a lot of rat holes, thats why it was taken away.
(look at the earlier drafts)
When protocol drafts show up, it will be stated explicitly.
Does the above generic text miss any failover mechanisms?

> > [HK] This requirement & section 7 #13 is suppose to cover any failure
> > notification
> > by the FE. The example talks about change in the number of
> > ports (port down
> > event).
>
> Great! But can the verbiage be changed to explicitly state that all failure
> notifications are supported and not just "increase/decrease in available
> resources".
>

Can you be more specific? 

cheers,
jamal


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 16 11:13:18 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27773
	for <forces-archive@IETF.ORG>; Thu, 16 May 2002 11:13:18 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006099F1@cherry.ease.lsoft.com>; Thu, 16 May 2002 11:13:23 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18620933 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 16 May 2002 11:13:22 -0400
Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 16 May 2002 11:13:22 -0400
Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com
          (8.10.2/8.10.2) with ESMTP id g4GFDLx12089 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 16 May 2002 10:13:21 -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A32842B258@india_exch.hyderabad.mindspeed.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Alex Audu <Alex.Audu@ALCATEL.COM>
Message-ID:  <3CE3CC99.32543DFD@alcatel.com>
Date:         Thu, 16 May 2002 10:13:29 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Alex Audu <Alex.Audu@alcatel.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t -
              May10-24
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 7bit

Shyam,

Once a FE and its controlling CE are distributed in such a way that you need a
transport
protocol to carry the FORCes protocol messages between them, then you run the
risk of
exposing that comunication link to security attacks.  The risk grows with
physical separation
between the two.  But you are right; if  both CE and FE are in the same box,
then you may
not need an elaborate security scheme (section 7.4). However, there is nothing
that says they
must be in the same box. Remember, this is a "distributed" architecture.

Alex.

Shyam prasad wrote:

> Alex and Hormuzd,
>
> Thanks for your responses. Please see my comments below:
>
> > -----Original Message-----
> > From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]
> > Sent: Thursday, May 16, 2002 3:07 AM
> > To: FORCES@PEACH.EASE.LSOFT.COM
> > Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t -
> > May 10-24
> >
> >
> > Thanks for the comments, Alex.
> > I'll try to answer the 3rd question below.
> >
> > Hormuzd
> >
> > Shyam prasad wrote:
> >
> > > Hi all,
> > >
> > > I have a few questions/comments on the draft. I am new to
> > this group.
> > Sorry
> > > if the questions are elementary ones.
> > >
> > > 1. Are CEs and FEs expected to be part of a single system?
> > If the answer
> > is
> > > yes, isn't implementing security mechanisms such as
> > IPSec/IKE for ForCES
> > > protocol an overkill?
> > >
> >
> > Section 7.4 (Multihop)  states that CE and FE may be
> > seperated by more than
> > one hop. This may justify use of IPSec/IKE.
> >
>
> The basic doubt still remains. CEs and FEs could be multiple hops away, they
> could reside on multiple cards but are they components within a single box??
>
> > >
> > > 2. The requirements draft does not mention FE redundancy
> > and failover. I
> > > think FE redundancy support would involve certain amount of
> > CE-FE control
> > > messaging if CE is viewed as the master and FE, the slave.
> > >
> >
> > See section 7.8 (CE Redundancy or CE Failover). I think this
> > section also
> > covers
> >
> > FE redundancy/failover.
>
> Here's the text under 7.8 :
> "The ForCES protocol MUST support mechanisms for CE redundancy or CE
>    failover. This includes the ability for CEs and FEs to determine
>    when there is a loss of association between them, ability to restore
>    association and efficient state (re)synchronization mechanisms. This
>    also includes the ability to preset the actions an FE will take in
>    reaction to loss of association to its CE e.g., whether the FE will
>    continue to forward packets or whether it will halt operations."
>
> Even if this section is intended to include the FE redundancy requirement,
> it's not so obvious. Can it be stated explicitly? Or could you add another
> section for FE redundancy?
>
> >
> > >
> > > 3. Section 5, point #6 says that an FE MUST be able to
> > asynchronously
> > inform
> > > the CE an increase/decrease in available resources or
> > capabilities on the
> > > FE. Can this requirement be extended to enable FEs to
> > notify failures
> > (port
> > > failure, internal fault, etc.)?
> > >
> > [HK] This requirement & section 7 #13 is suppose to cover any failure
> > notification
> > by the FE. The example talks about change in the number of
> > ports (port down
> > event).
>
> Great! But can the verbiage be changed to explicitly state that all failure
> notifications are supported and not just "increase/decrease in available
> resources".
>
> Thanks.
> Shyam


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 16 15:06:30 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06696
	for <forces-archive@IETF.ORG>; Thu, 16 May 2002 15:06:29 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0060A07D@cherry.ease.lsoft.com>; Thu, 16 May 2002 15:06:43 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18641564 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 16 May 2002 15:06:42 -0400
Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 16 May 2002 15:06:42 -0400
Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com
          (8.10.2/8.10.2) with ESMTP id g4GJ6f414922 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 16 May 2002 14:06:41 -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <D9223EB959A5D511A98F00508B68C20C07FDE4BC@orsmsx108.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Alex Audu <Alex.Audu@ALCATEL.COM>
Message-ID:  <3CE40348.EB6ABA08@alcatel.com>
Date:         Thu, 16 May 2002 14:06:48 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Alex Audu <Alex.Audu@alcatel.com>
Subject:      Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 7bit

Hi Lily,

The current version is much improved. Great job! However, I'd like to point
out that when you distribute CEs and FEs, you create  CE<->CE, CE<->FE
and FE<->FE communication interfaces. ForCES  specifies CE<->FE
interface.  It will be nice if we also specify CE<->CE interface (could use
ForCES here too). This becomes improtant when you have different
CE boxes from different vendors controlling different FEs from also various
vendors in a provider's network, and these boxes have to  inter-operate.
(Sections  4.1 and 4.2)

Regards,
Alex.


"Yang, Lily L" wrote:

> Hi, all --
> We submitted version 01 of the framework draft last week after a major
> rewrite:
> * added more description and diagrams to illustrate different physical
> configuration examples of ForCES CE/FE.
> * added examples of FE topology.
> * restructure the text to focus more on ForCES operation phases (pre- and
> post- association, reestablishment, etc.)
> * added examples to illustrate the handshake between CE and FE during these
> operational phases.
>
> please let us know what you think -- are these examples/diagrams useful?
> Have we missed anything important? Any comments on the draft are welcome!
>
> Thanks,
> Lily
>
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Wednesday, May 15, 2002 4:11 AM
> Cc: forces@peach.ease.lsoft.com
> Subject: I-D ACTION:draft-anderson-forces-arch-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>         Title           : ForCES Architectural Framework
>         Author(s)       : T. Anderson, L. Yang, R. Dantu
>         Filename        : draft-anderson-forces-arch-01.txt
>         Pages           : 20
>         Date            : 14-May-02
>
> This document defines the architectural framework for ForCES network
> elements (NE), associated entities and the interaction among them.
> The architecture defined herein is intended to satisfy the
> requirements specified in the ForCES requirements draft [FORCES-
> REQ].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-anderson-forces-arch-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         mailserv@ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-anderson-forces-arch-01.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>   ------------------------------------------------------------------------
>
> Subject:
> Date: Wed, 15 May 2002 23:12:54 -0700
>
>   ------------------------------------------------------------------------
>
>    ATT25595Name: ATT25595
>            Type: unspecified type (application/octet-stream)
>
>                 Access-Type: anon-ftp
>  Document Info:        Site: internet-drafts
>                        Mode: ftp.ietf.org


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 16 15:20:36 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07307
	for <forces-archive@IETF.ORG>; Thu, 16 May 2002 15:20:35 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0060A0B6@cherry.ease.lsoft.com>; Thu, 16 May 2002 15:20:49 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18643148 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 16 May 2002 15:20:21 -0400
Received: from 65.119.52.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 16 May 2002 15:20:20 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic:      Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt
Thread-Index: AcH9DNBMT+6E4Q9cToiiVqw+h/rjbwAAC31w
Approved-By:  Ram Dantu <ramd@NETRAKE.COM>
Message-ID:  <7E06D3212981524CA10D2A114937C414073CEF@NREXCH.netrake.net>
Date:         Thu, 16 May 2002 14:20:17 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Ram Dantu <ramd@netrake.com>
Subject:      Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA07307

Alex,
Thanks for the input. See my comments

Regards
Ram Dantu

-----Original Message-----
From: Alex Audu [mailto:Alex.Audu@alcatel.com]
Sent: Thursday, May 16, 2002 2:07 PM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt


Hi Lily,

The current version is much improved. Great job! However, I'd like to point
out that when you distribute CEs and FEs, you create  CE<->CE, CE<->FE
and FE<->FE communication interfaces. ForCES  specifies CE<->FE
interface.  It will be nice if we also specify CE<->CE interface (could use
ForCES here too). This becomes improtant when you have different
CE boxes from different vendors controlling different FEs from also various
vendors in a provider's network, and these boxes have to  inter-operate.
(Sections  4.1 and 4.2)

[RD.start] Specifying the CE<-->CE interface in ForCES framework may not be
appropriate place. However, we can mention several other functions of this 
interface (other than Section 4.2) in the framework document. 
Specifying a detailed specification may be beyond the scope of ForCES. 
Working Group Chair may have some comments on this.
[RD.End]
[]

Regards,
Alex.


"Yang, Lily L" wrote:

> Hi, all --
> We submitted version 01 of the framework draft last week after a major
> rewrite:
> * added more description and diagrams to illustrate different physical
> configuration examples of ForCES CE/FE.
> * added examples of FE topology.
> * restructure the text to focus more on ForCES operation phases (pre- and
> post- association, reestablishment, etc.)
> * added examples to illustrate the handshake between CE and FE during these
> operational phases.
>
> please let us know what you think -- are these examples/diagrams useful?
> Have we missed anything important? Any comments on the draft are welcome!
>
> Thanks,
> Lily
>
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Wednesday, May 15, 2002 4:11 AM
> Cc: forces@peach.ease.lsoft.com
> Subject: I-D ACTION:draft-anderson-forces-arch-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>         Title           : ForCES Architectural Framework
>         Author(s)       : T. Anderson, L. Yang, R. Dantu
>         Filename        : draft-anderson-forces-arch-01.txt
>         Pages           : 20
>         Date            : 14-May-02
>
> This document defines the architectural framework for ForCES network
> elements (NE), associated entities and the interaction among them.
> The architecture defined herein is intended to satisfy the
> requirements specified in the ForCES requirements draft [FORCES-
> REQ].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-anderson-forces-arch-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         mailserv@ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-anderson-forces-arch-01.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>   ------------------------------------------------------------------------
>
> Subject:
> Date: Wed, 15 May 2002 23:12:54 -0700
>
>   ------------------------------------------------------------------------
>
>    ATT25595Name: ATT25595
>            Type: unspecified type (application/octet-stream)
>
>                 Access-Type: anon-ftp
>  Document Info:        Site: internet-drafts
>                        Mode: ftp.ietf.org


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 16 16:06:04 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09379
	for <forces-archive@IETF.ORG>; Thu, 16 May 2002 16:06:03 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0060A26D@cherry.ease.lsoft.com>; Thu, 16 May 2002 16:06:15 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18646933 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 16 May 2002 16:06:14 -0400
Received: from 65.119.52.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 16 May 2002 16:06:14 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic:      WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
                   1 0-24
Thread-Index: AcH8WRvrJNQYHix3Qu66gPJWZtM9AgAui64g
Approved-By:  Ram Dantu <ramd@NETRAKE.COM>
Message-ID:  <7E06D3212981524CA10D2A114937C414073CF1@NREXCH.netrake.net>
Date:         Thu, 16 May 2002 15:06:11 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Ram Dantu <ramd@netrake.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1
              0-24
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA09379

Alex,
Please see my comments below.

Regards
Ram Dantu

-----Original Message-----
From: Alex Audu [mailto:Alex.Audu@alcatel.com]
Sent: Wednesday, May 15, 2002 4:41 PM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1
0-24


David,

I am new to this mailing list, though I have been following the FORCes
effort for a while
and I have the comments about the requirements draft.

Section 6 (FE Model Requirements) . Since the logical functions of the
FE can be programmed
or selected by the CE,  it also makes sense to allow the capabilities of
those logical functions
to be programmed by the CE.  That way, it may not be necessary for the
CE to querry for the
capabilities of the FE before using it (since it already knows this by
virtue of being the programmer).
Can you add language here to clarify this?

[RD.Start] I assume that these queries happen during ForCES initialization
as well as due to changes in FE resources.
[RD.End]

Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also
specify a minimum set of
functional/logical blocks every FE must contain? This will be akin to a
minimum toolset that
could be cobbled together to implement any of the main set of  packet
handling behaviors in a FE.
[RD.start] Imposing a minimal set may be a controversial subject. However,
we can say forwarding function is the minimum function. In the framework/architecture
document, we have mentioned some FE and CE functions.
[RD.End]

Also, are there any unique CE Model Requirements  identifiable?

[RD.Start] Each CE shall have to support one or more functions
that are related to controlling a particular FE. These functions
have to identified on a FE by FE basis by the FE/CE managers.
[RD.End]

Regards,
Alex.

> -----Original Message-----
> From: Putzolu, David [mailto:david.putzolu@intel.com]
> Sent: Friday, May 10, 2002 4:14 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> 10-24
> Importance: High
>
>
> All,
>
> This message marks the beginning of a last call
> for the ForCES requirements document.
>
> The last call period begins immediately and lasts
> until Friday, May 24th, 2002, at midnight GMT.
>
> Document URL:
> http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem
ents-03.txt

Thanks,
David


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 16 20:12:06 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15306
	for <forces-archive@IETF.ORG>; Thu, 16 May 2002 20:12:05 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0060A9EB@cherry.ease.lsoft.com>; Thu, 16 May 2002 20:12:16 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18665279 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 16 May 2002 20:12:12 -0400
Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 16 May 2002 20:12:12 -0400
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by
          caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09
          18:12:26 root Exp $) with ESMTP id g4H0B0E01800 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Fri, 17 May 2002 00:11:00 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com
          [132.233.48.108]) by talaria.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id
          g4H0FBk27971 for <FORCES@PEACH.EASE.LSOFT.COM>; Fri, 17 May 2002
          00:15:11 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by
          fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002051617103406322 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 16 May
          2002 17:10:34 -0700
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <K8BT7QFQ>; Thu, 16 May 2002 17:11:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Approved-By:  "Putzolu, David" <david.putzolu@INTEL.COM>
Message-ID:  <FD2423AA68A7D511A5A20002A50729E10272475F@orsmsx115.jf.intel.com>
Date:         Thu, 16 May 2002 17:11:11 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Putzolu, David" <david.putzolu@intel.com>
Subject:      Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt
To: FORCES@PEACH.EASE.LSOFT.COM

From: Ram Dantu [mailto:ramd@netrake.com]
> [RD.start] Specifying the CE<-->CE interface in ForCES
> framework may not be appropriate place. However, we can
> mention several other functions of this
> interface (other than Section 4.2) in the framework document.
> Specifying a detailed specification may be beyond the scope
> of ForCES.
> Working Group Chair may have some comments on this.
> [RD.End]

[chair hat on]
The problem of solving CE <--> FE communication is
already a pretty tough problem, so the CE <--> CE
problem is not currently part of our charter.  The
framework document gives a rough description of that
interface and names it (Fr), but we probably should
not go a lot further than that.
[chair hat off]

Personal comments:

I don't think CE <--> CE interface (Fr in the framework
doc) is same problem as CE <-> FE (Fp).

Fr involves issues such as how to distribute or
partition calculations such as routing to enable
CE scalability, maintaining coherency of state
between CEs to prevent FE misconfiguration, CE
fault detection and response, sharing decision making
procedures, etc.  This seems like a peer to peer
relationship (although master-slave approaches are
also possible).

Fp involves communicating forwarding and other tables
(resulting from the calculations mentioned above) to
FEs and monitoring the statistics and state of FEs.
This is a master-slave relationship.

I personally think the CE <--> CE problem is a really
interesting one, but it seems to me to be different
enough that it would probably require its own WG.

Cheers,
David


From owner-forces@PEACH.EASE.LSOFT.COM  Fri May 17 10:47:20 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16218
	for <forces-archive@IETF.ORG>; Fri, 17 May 2002 10:47:19 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0060C13D@cherry.ease.lsoft.com>; Fri, 17 May 2002 10:47:22 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18727896 for FORCES@PEACH.EASE.LSOFT.COM;
          Fri, 17 May 2002 10:47:15 -0400
Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d)
          with TCP; Fri, 17 May 2002 10:47:15 -0400
Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com
          (8.10.2/8.10.2) with ESMTP id g4HElEP29155 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Fri, 17 May 2002 09:47:14 -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <7E06D3212981524CA10D2A114937C414073CF1@NREXCH.netrake.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Alex Audu <Alex.Audu@ALCATEL.COM>
Message-ID:  <3CE517F9.39109831@alcatel.com>
Date:         Fri, 17 May 2002 09:47:21 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Alex Audu <Alex.Audu@alcatel.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
              10-24
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 7bit

Ram,

My comments were intended to try to reconcile the spirit of ForCES with that
expressed in P1520 (IEEE Programmable Interface for Network Elements).
In P1520, some resource building blocks are identified (e.g. classifiers, meters,
scheduler, queue, marker, dropper, shapper, counter, multiplexor,..), from
which services can be built. These allign with the logical functions identified in the
FE model.  We can definitly identify some minimum set of logical functions necessary
to realize a viable forwarding function in an FE.  May be some langauage can be
added to recommend a minimum set?

>[RD.Start] Each CE shall have to support one or more functions
>that are related to controlling a particular FE. These functions
>have to identified on a FE by FE basis by the FE/CE managers.
>[RD.End]

Can we then add a CE Model Requirements section to the draft and
identify CE's requirements there?

Regards,
Alex.

Ram Dantu wrote:

> Alex,
> Please see my comments below.
>
> Regards
> Ram Dantu
>
> -----Original Message-----
> From: Alex Audu [mailto:Alex.Audu@alcatel.com]
> Sent: Wednesday, May 15, 2002 4:41 PM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1
> 0-24
>
> David,
>
> I am new to this mailing list, though I have been following the FORCes
> effort for a while
> and I have the comments about the requirements draft.
>
> Section 6 (FE Model Requirements) . Since the logical functions of the
> FE can be programmed
> or selected by the CE,  it also makes sense to allow the capabilities of
> those logical functions
> to be programmed by the CE.  That way, it may not be necessary for the
> CE to querry for the
> capabilities of the FE before using it (since it already knows this by
> virtue of being the programmer).
> Can you add language here to clarify this?
>
> [RD.Start] I assume that these queries happen during ForCES initialization
> as well as due to changes in FE resources.
> [RD.End]
>
> Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also
> specify a minimum set of
> functional/logical blocks every FE must contain? This will be akin to a
> minimum toolset that
> could be cobbled together to implement any of the main set of  packet
> handling behaviors in a FE.
> [RD.start] Imposing a minimal set may be a controversial subject. However,
> we can say forwarding function is the minimum function. In the framework/architecture
> document, we have mentioned some FE and CE functions.
> [RD.End]
>
> Also, are there any unique CE Model Requirements  identifiable?
>
> [RD.Start] Each CE shall have to support one or more functions
> that are related to controlling a particular FE. These functions
> have to identified on a FE by FE basis by the FE/CE managers.
> [RD.End]
>
> Regards,
> Alex.
>
> > -----Original Message-----
> > From: Putzolu, David [mailto:david.putzolu@intel.com]
> > Sent: Friday, May 10, 2002 4:14 AM
> > To: FORCES@PEACH.EASE.LSOFT.COM
> > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> > 10-24
> > Importance: High
> >
> >
> > All,
> >
> > This message marks the beginning of a last call
> > for the ForCES requirements document.
> >
> > The last call period begins immediately and lasts
> > until Friday, May 24th, 2002, at midnight GMT.
> >
> > Document URL:
> > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem
> ents-03.txt
>
> Thanks,
> David


From owner-forces@PEACH.EASE.LSOFT.COM  Fri May 17 11:13:04 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16981
	for <forces-archive@IETF.ORG>; Fri, 17 May 2002 11:13:04 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0060C42D@cherry.ease.lsoft.com>; Fri, 17 May 2002 11:13:18 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18729868 for FORCES@PEACH.EASE.LSOFT.COM;
          Fri, 17 May 2002 11:12:59 -0400
Received: from 65.119.52.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Fri, 17 May 2002 11:12:59 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt -
                   May             10-24
Thread-Index: AcH9scAt5YlYcVuqQrKzEDOc3BgYUwAAIuTw
Approved-By:  Ram Dantu <ramd@NETRAKE.COM>
Message-ID:  <7E06D3212981524CA10D2A114937C414073CF5@NREXCH.netrake.net>
Date:         Fri, 17 May 2002 10:12:55 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Ram Dantu <ramd@netrake.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
              10-24
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA16981

Alex,

In Section 6.5, there is a list of logical functions in FE 
(This section defines a minimal set of logical functions 
 that any FE model MUST support.  This minimal set DOES NOT imply 
 that all FEs must provide this functionality).
We can provide an example on how to achieve a forwarding function with these functions.
I think this can go in the framework document or FE model document.

Also, I think every ForCES requirement mandates a corresponding
function to be present in the FE and CE. So, I assume
CE should support all ForCES requirements. May be
you can give some examples with reference to some section ?

Thanks
Ram Dantu
-----Original Message-----
From: Alex Audu [mailto:Alex.Audu@alcatel.com]
Sent: Friday, May 17, 2002 9:47 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
10-24


Ram,

My comments were intended to try to reconcile the spirit of ForCES with that
expressed in P1520 (IEEE Programmable Interface for Network Elements).
In P1520, some resource building blocks are identified (e.g. classifiers, meters,
scheduler, queue, marker, dropper, shapper, counter, multiplexor,..), from
which services can be built. These allign with the logical functions identified in the
FE model.  We can definitly identify some minimum set of logical functions necessary
to realize a viable forwarding function in an FE.  May be some langauage can be
added to recommend a minimum set?

>[RD.Start] Each CE shall have to support one or more functions
>that are related to controlling a particular FE. These functions
>have to identified on a FE by FE basis by the FE/CE managers.
>[RD.End]

Can we then add a CE Model Requirements section to the draft and
identify CE's requirements there?

Regards,
Alex.

Ram Dantu wrote:

> Alex,
> Please see my comments below.
>
> Regards
> Ram Dantu
>
> -----Original Message-----
> From: Alex Audu [mailto:Alex.Audu@alcatel.com]
> Sent: Wednesday, May 15, 2002 4:41 PM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1
> 0-24
>
> David,
>
> I am new to this mailing list, though I have been following the FORCes
> effort for a while
> and I have the comments about the requirements draft.
>
> Section 6 (FE Model Requirements) . Since the logical functions of the
> FE can be programmed
> or selected by the CE,  it also makes sense to allow the capabilities of
> those logical functions
> to be programmed by the CE.  That way, it may not be necessary for the
> CE to querry for the
> capabilities of the FE before using it (since it already knows this by
> virtue of being the programmer).
> Can you add language here to clarify this?
>
> [RD.Start] I assume that these queries happen during ForCES initialization
> as well as due to changes in FE resources.
> [RD.End]
>
> Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also
> specify a minimum set of
> functional/logical blocks every FE must contain? This will be akin to a
> minimum toolset that
> could be cobbled together to implement any of the main set of  packet
> handling behaviors in a FE.
> [RD.start] Imposing a minimal set may be a controversial subject. However,
> we can say forwarding function is the minimum function. In the framework/architecture
> document, we have mentioned some FE and CE functions.
> [RD.End]
>
> Also, are there any unique CE Model Requirements  identifiable?
>
> [RD.Start] Each CE shall have to support one or more functions
> that are related to controlling a particular FE. These functions
> have to identified on a FE by FE basis by the FE/CE managers.
> [RD.End]
>
> Regards,
> Alex.
>
> > -----Original Message-----
> > From: Putzolu, David [mailto:david.putzolu@intel.com]
> > Sent: Friday, May 10, 2002 4:14 AM
> > To: FORCES@PEACH.EASE.LSOFT.COM
> > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> > 10-24
> > Importance: High
> >
> >
> > All,
> >
> > This message marks the beginning of a last call
> > for the ForCES requirements document.
> >
> > The last call period begins immediately and lasts
> > until Friday, May 24th, 2002, at midnight GMT.
> >
> > Document URL:
> > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem
> ents-03.txt
>
> Thanks,
> David


From owner-forces@PEACH.EASE.LSOFT.COM  Fri May 17 18:33:01 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09916
	for <forces-archive@IETF.ORG>; Fri, 17 May 2002 18:33:01 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0060D1D4@cherry.ease.lsoft.com>; Fri, 17 May 2002 18:33:17 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 18771114 for FORCES@PEACH.EASE.LSOFT.COM;
          Fri, 17 May 2002 18:33:15 -0400
Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Fri, 17 May 2002 18:33:15 -0400
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by
          caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09
          18:12:26 root Exp $) with ESMTP id g4HMW2S10913 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Fri, 17 May 2002 22:32:02 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com
          [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id
          g4HMaHG19381 for <FORCES@PEACH.EASE.LSOFT.COM>; Fri, 17 May 2002
          22:36:17 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by
          fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002051715375416915 for <FORCES@PEACH.EASE.LSOFT.COM>; Fri, 17 May
          2002 15:37:55 -0700
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <KG0P0VD0>; Fri, 17 May 2002 15:33:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Approved-By:  "Putzolu, David" <david.putzolu@INTEL.COM>
Message-ID:  <FD2423AA68A7D511A5A20002A50729E102724768@orsmsx115.jf.intel.com>
Date:         Fri, 17 May 2002 15:33:07 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Putzolu, David" <david.putzolu@intel.com>
Subject:      Reminder: WG LAST CALL of draft-ietf-forces-requirements-03.txt -
              May 10-24
To: FORCES@PEACH.EASE.LSOFT.COM

Reminder - the ForCES requirements document started
working group last call a week ago and there is one
week left in the last call period, which completes
on Friday May 24 2002.

Cheers,
David

> -----Original Message-----
> From: Putzolu, David [mailto:david.putzolu@intel.com]
> Sent: Thursday, May 09, 2002 3:44 PM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: [FORCES] WG LAST CALL of
> draft-ietf-forces-requirements-03.txt - May 10-24
> Importance: High
>
>
> All,
>
> This message marks the beginning of a last call
> for the ForCES requirements document.
>
> The last call period begins immediately and lasts
> until Friday, May 24th, 2002, at midnight GMT.
>
> Document URL:
> http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt

Thanks,
David


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 23 11:43:57 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15203
	for <forces-archive@IETF.ORG>; Thu, 23 May 2002 11:43:56 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00619DEF@cherry.ease.lsoft.com>; Thu, 23 May 2002 11:43:51 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19214301 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 23 May 2002 11:43:51 -0400
Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 23 May 2002 11:43:50 -0400
Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com
          (8.10.2/8.10.2) with ESMTP id g4NFhn424711 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May 2002 10:43:49 -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <7E06D3212981524CA10D2A114937C414073CF5@NREXCH.netrake.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Alex Audu <Alex.Audu@ALCATEL.COM>
Message-ID:  <3CED0E41.F741965A@alcatel.com>
Date:         Thu, 23 May 2002 10:44:02 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Alex Audu <Alex.Audu@alcatel.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt -
              May10-24
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 7bit

Hello Ram,

Sorry for the delay in responding to your last request. You are right; the ForCES protocol
requirement
section  also implies the responsibilities of CE.  However, is it a requirement that CE
should handle control
and signalling functions?  Then we should so state in the document, though it is implied in
the draft.

Also, can we add language that FoCES protocol should support State Monitoring/Management
and Error
Reporting?

Regards,
Alex.

Ram Dantu wrote:

> Alex,
>
> In Section 6.5, there is a list of logical functions in FE
> (This section defines a minimal set of logical functions
>  that any FE model MUST support.  This minimal set DOES NOT imply
>  that all FEs must provide this functionality).
> We can provide an example on how to achieve a forwarding function with these functions.
> I think this can go in the framework document or FE model document.
>
> Also, I think every ForCES requirement mandates a corresponding
> function to be present in the FE and CE. So, I assume
> CE should support all ForCES requirements. May be
> you can give some examples with reference to some section ?
>
> Thanks
> Ram Dantu
> -----Original Message-----
> From: Alex Audu [mailto:Alex.Audu@alcatel.com]
> Sent: Friday, May 17, 2002 9:47 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> 10-24
>
> Ram,
>
> My comments were intended to try to reconcile the spirit of ForCES with that
> expressed in P1520 (IEEE Programmable Interface for Network Elements).
> In P1520, some resource building blocks are identified (e.g. classifiers, meters,
> scheduler, queue, marker, dropper, shapper, counter, multiplexor,..), from
> which services can be built. These allign with the logical functions identified in the
> FE model.  We can definitly identify some minimum set of logical functions necessary
> to realize a viable forwarding function in an FE.  May be some langauage can be
> added to recommend a minimum set?
>
> >[RD.Start] Each CE shall have to support one or more functions
> >that are related to controlling a particular FE. These functions
> >have to identified on a FE by FE basis by the FE/CE managers.
> >[RD.End]
>
> Can we then add a CE Model Requirements section to the draft and
> identify CE's requirements there?
>
> Regards,
> Alex.
>
> Ram Dantu wrote:
>
> > Alex,
> > Please see my comments below.
> >
> > Regards
> > Ram Dantu
> >
> > -----Original Message-----
> > From: Alex Audu [mailto:Alex.Audu@alcatel.com]
> > Sent: Wednesday, May 15, 2002 4:41 PM
> > To: FORCES@PEACH.EASE.LSOFT.COM
> > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1
> > 0-24
> >
> > David,
> >
> > I am new to this mailing list, though I have been following the FORCes
> > effort for a while
> > and I have the comments about the requirements draft.
> >
> > Section 6 (FE Model Requirements) . Since the logical functions of the
> > FE can be programmed
> > or selected by the CE,  it also makes sense to allow the capabilities of
> > those logical functions
> > to be programmed by the CE.  That way, it may not be necessary for the
> > CE to querry for the
> > capabilities of the FE before using it (since it already knows this by
> > virtue of being the programmer).
> > Can you add language here to clarify this?
> >
> > [RD.Start] I assume that these queries happen during ForCES initialization
> > as well as due to changes in FE resources.
> > [RD.End]
> >
> > Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also
> > specify a minimum set of
> > functional/logical blocks every FE must contain? This will be akin to a
> > minimum toolset that
> > could be cobbled together to implement any of the main set of  packet
> > handling behaviors in a FE.
> > [RD.start] Imposing a minimal set may be a controversial subject. However,
> > we can say forwarding function is the minimum function. In the framework/architecture
> > document, we have mentioned some FE and CE functions.
> > [RD.End]
> >
> > Also, are there any unique CE Model Requirements  identifiable?
> >
> > [RD.Start] Each CE shall have to support one or more functions
> > that are related to controlling a particular FE. These functions
> > have to identified on a FE by FE basis by the FE/CE managers.
> > [RD.End]
> >
> > Regards,
> > Alex.
> >
> > > -----Original Message-----
> > > From: Putzolu, David [mailto:david.putzolu@intel.com]
> > > Sent: Friday, May 10, 2002 4:14 AM
> > > To: FORCES@PEACH.EASE.LSOFT.COM
> > > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> > > 10-24
> > > Importance: High
> > >
> > >
> > > All,
> > >
> > > This message marks the beginning of a last call
> > > for the ForCES requirements document.
> > >
> > > The last call period begins immediately and lasts
> > > until Friday, May 24th, 2002, at midnight GMT.
> > >
> > > Document URL:
> > > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem
> > ents-03.txt
> >
> > Thanks,
> > David


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 23 12:21:04 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16862
	for <forces-archive@IETF.ORG>; Thu, 23 May 2002 12:21:04 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00619EC3@cherry.ease.lsoft.com>; Thu, 23 May 2002 12:21:23 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19217083 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 23 May 2002 12:21:22 -0400
Received: from 65.119.52.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 23 May 2002 12:21:22 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - 
                   May10-24
Thread-Index: AcICcJ7mmkA1k82lSViDKG+45ADOUwAA2W+g
Approved-By:  Ram Dantu <ramd@NETRAKE.COM>
Message-ID:  <7E06D3212981524CA10D2A114937C414073CFE@NREXCH.netrake.net>
Date:         Thu, 23 May 2002 11:21:13 -0500
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Ram Dantu <ramd@netrake.com>
Subject:      Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt -
              May10-24
To: FORCES@PEACH.EASE.LSOFT.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16862

Alex,

Please see my comments.

Regards
Ram Dantu

-----Original Message-----
From: Alex Audu [mailto:Alex.Audu@alcatel.com]
Sent: Thursday, May 23, 2002 10:44 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt -
May10-24


Hello Ram,

Sorry for the delay in responding to your last request. You are right; the ForCES protocol
requirement
section  also implies the responsibilities of CE.  However, is it a requirement that CE
should handle control
and signalling functions?  Then we should so state in the document, though it is implied in
the draft.
[RD] Start
Please see definition of control element in Section 2. It reads
"CEs handle functionality such as the execution of control 
 and signaling protocols."  I hope this clarifies your question
[RD] End

Also, can we add language that FoCES protocol should support State Monitoring/Management
and Error
Reporting?

[RD] There is some text in items 13 and 14 of Section 7 (querying stats, and asynchronous 
notifications). We shall add text for error reporting and monitoring.

Regards,
Alex.

Ram Dantu wrote:

> Alex,
>
> In Section 6.5, there is a list of logical functions in FE
> (This section defines a minimal set of logical functions
>  that any FE model MUST support.  This minimal set DOES NOT imply
>  that all FEs must provide this functionality).
> We can provide an example on how to achieve a forwarding function with these functions.
> I think this can go in the framework document or FE model document.
>
> Also, I think every ForCES requirement mandates a corresponding
> function to be present in the FE and CE. So, I assume
> CE should support all ForCES requirements. May be
> you can give some examples with reference to some section ?
>
> Thanks
> Ram Dantu
> -----Original Message-----
> From: Alex Audu [mailto:Alex.Audu@alcatel.com]
> Sent: Friday, May 17, 2002 9:47 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> 10-24
>
> Ram,
>
> My comments were intended to try to reconcile the spirit of ForCES with that
> expressed in P1520 (IEEE Programmable Interface for Network Elements).
> In P1520, some resource building blocks are identified (e.g. classifiers, meters,
> scheduler, queue, marker, dropper, shapper, counter, multiplexor,..), from
> which services can be built. These allign with the logical functions identified in the
> FE model.  We can definitly identify some minimum set of logical functions necessary
> to realize a viable forwarding function in an FE.  May be some langauage can be
> added to recommend a minimum set?
>
> >[RD.Start] Each CE shall have to support one or more functions
> >that are related to controlling a particular FE. These functions
> >have to identified on a FE by FE basis by the FE/CE managers.
> >[RD.End]
>
> Can we then add a CE Model Requirements section to the draft and
> identify CE's requirements there?
>
> Regards,
> Alex.
>
> Ram Dantu wrote:
>
> > Alex,
> > Please see my comments below.
> >
> > Regards
> > Ram Dantu
> >
> > -----Original Message-----
> > From: Alex Audu [mailto:Alex.Audu@alcatel.com]
> > Sent: Wednesday, May 15, 2002 4:41 PM
> > To: FORCES@PEACH.EASE.LSOFT.COM
> > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1
> > 0-24
> >
> > David,
> >
> > I am new to this mailing list, though I have been following the FORCes
> > effort for a while
> > and I have the comments about the requirements draft.
> >
> > Section 6 (FE Model Requirements) . Since the logical functions of the
> > FE can be programmed
> > or selected by the CE,  it also makes sense to allow the capabilities of
> > those logical functions
> > to be programmed by the CE.  That way, it may not be necessary for the
> > CE to querry for the
> > capabilities of the FE before using it (since it already knows this by
> > virtue of being the programmer).
> > Can you add language here to clarify this?
> >
> > [RD.Start] I assume that these queries happen during ForCES initialization
> > as well as due to changes in FE resources.
> > [RD.End]
> >
> > Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also
> > specify a minimum set of
> > functional/logical blocks every FE must contain? This will be akin to a
> > minimum toolset that
> > could be cobbled together to implement any of the main set of  packet
> > handling behaviors in a FE.
> > [RD.start] Imposing a minimal set may be a controversial subject. However,
> > we can say forwarding function is the minimum function. In the framework/architecture
> > document, we have mentioned some FE and CE functions.
> > [RD.End]
> >
> > Also, are there any unique CE Model Requirements  identifiable?
> >
> > [RD.Start] Each CE shall have to support one or more functions
> > that are related to controlling a particular FE. These functions
> > have to identified on a FE by FE basis by the FE/CE managers.
> > [RD.End]
> >
> > Regards,
> > Alex.
> >
> > > -----Original Message-----
> > > From: Putzolu, David [mailto:david.putzolu@intel.com]
> > > Sent: Friday, May 10, 2002 4:14 AM
> > > To: FORCES@PEACH.EASE.LSOFT.COM
> > > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May
> > > 10-24
> > > Importance: High
> > >
> > >
> > > All,
> > >
> > > This message marks the beginning of a last call
> > > for the ForCES requirements document.
> > >
> > > The last call period begins immediately and lasts
> > > until Friday, May 24th, 2002, at midnight GMT.
> > >
> > > Document URL:
> > > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem
> > ents-03.txt
> >
> > Thanks,
> > David


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 23 12:44:57 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17631
	for <forces-archive@IETF.ORG>; Thu, 23 May 2002 12:44:55 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00619D7E@cherry.ease.lsoft.com>; Thu, 23 May 2002 12:45:10 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19218086 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 23 May 2002 12:45:08 -0400
Received: from 134.134.248.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 23 May 2002 12:45:08 -0400
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com
          [192.168.65.206]) by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v
          1.39 2002/05/13 20:36:23 root Exp $) with SMTP id g4NGj7h01539 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May 2002 16:45:07 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by
          orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002052309531319636 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May
          2002 09:53:13 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id
          <LPV7BPWN>; Thu, 23 May 2002 09:45:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Yang, Lily L" <lily.l.yang@INTEL.COM>
Message-ID:  <D9223EB959A5D511A98F00508B68C20C07FDE4F9@orsmsx108.jf.intel.com>
Date:         Thu, 23 May 2002 09:44:59 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Yang, Lily L" <lily.l.yang@intel.com>
Subject:      Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt
To: FORCES@PEACH.EASE.LSOFT.COM

Alex --
Thanks for the feedback!
Sorry that I didn't repond earlier, I am still digging my way out of my
inbox pile ...
You are right that in the ideal world, to get the full inter-operabilities
of all possible mix and match of CEs and FEs from different vendors, all
three communication interfaces have to be standardized. But we live in the
real world and it is probably better if we do only one thing at a time. So
the one thing we choose to do in ForCES is to separate CE from FE first and
standardize the CE-FE interface. This of course is only the first step
toward the ideal goal. This would give you inter-operability for the case
when CE and FE are from different vendor, but not in the case as you
described. Maybe limited, but still very useful as first step. So I think
that is ok. We don't intend to solve all problems by one WG.
As David Putzolu pointed out, and I agree, that CE-FE is master-slave
protocol, while CE-CE and FE-FE are more of peer to peer protocols.

Lily

> -----Original Message-----
> From: Alex Audu [mailto:Alex.Audu@alcatel.com]
> Sent: Thursday, May 16, 2002 12:07 PM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt
>
>
> Hi Lily,
>
> The current version is much improved. Great job! However, I'd
> like to point
> out that when you distribute CEs and FEs, you create  CE<->CE, CE<->FE
> and FE<->FE communication interfaces. ForCES  specifies CE<->FE
> interface.  It will be nice if we also specify CE<->CE
> interface (could use
> ForCES here too). This becomes improtant when you have different
> CE boxes from different vendors controlling different FEs
> from also various
> vendors in a provider's network, and these boxes have to
> inter-operate.
> (Sections  4.1 and 4.2)
>
> Regards,
> Alex.
>
>
> "Yang, Lily L" wrote:
>
> > Hi, all --
> > We submitted version 01 of the framework draft last week
> after a major
> > rewrite:
> > * added more description and diagrams to illustrate
> different physical
> > configuration examples of ForCES CE/FE.
> > * added examples of FE topology.
> > * restructure the text to focus more on ForCES operation
> phases (pre- and
> > post- association, reestablishment, etc.)
> > * added examples to illustrate the handshake between CE and
> FE during these
> > operational phases.
> >
> > please let us know what you think -- are these
> examples/diagrams useful?
> > Have we missed anything important? Any comments on the
> draft are welcome!
> >
> > Thanks,
> > Lily
> >
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Wednesday, May 15, 2002 4:11 AM
> > Cc: forces@peach.ease.lsoft.com
> > Subject: I-D ACTION:draft-anderson-forces-arch-01.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >         Title           : ForCES Architectural Framework
> >         Author(s)       : T. Anderson, L. Yang, R. Dantu
> >         Filename        : draft-anderson-forces-arch-01.txt
> >         Pages           : 20
> >         Date            : 14-May-02
> >
> > This document defines the architectural framework for ForCES network
> > elements (NE), associated entities and the interaction among them.
> > The architecture defined herein is intended to satisfy the
> > requirements specified in the ForCES requirements draft [FORCES-
> > REQ].
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt
> >
> > To remove yourself from the IETF Announcement list, send a
> message to
> > ietf-announce-request with the word unsubscribe in the body
> of the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >         "get draft-anderson-forces-arch-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >         mailserv@ietf.org.
> > In the body type:
> >         "FILE /internet-drafts/draft-anderson-forces-arch-01.txt".
> >
> > NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before
> the "FILE"
> >         command.  To decode the response(s), you will need
> "munpack" or
> >         a MIME-compliant mail reader.  Different
> MIME-compliant mail readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which
> have been split
> >         up into multiple messages), so check your local
> documentation on
> >         how to manipulate these messages.
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
> --------------------------------------------------------------
> ----------
> >
> > Subject:
> > Date: Wed, 15 May 2002 23:12:54 -0700
> >
> >
> --------------------------------------------------------------
> ----------
> >
> >    ATT25595Name: ATT25595
> >            Type: unspecified type (application/octet-stream)
> >
> >                 Access-Type: anon-ftp
> >  Document Info:        Site: internet-drafts
> >                        Mode: ftp.ietf.org
>


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 23 12:53:26 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17882
	for <forces-archive@IETF.ORG>; Thu, 23 May 2002 12:53:26 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00619EA1@cherry.ease.lsoft.com>; Thu, 23 May 2002 12:53:44 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19218416 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 23 May 2002 12:53:43 -0400
Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 23 May 2002 12:53:42 -0400
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by
          hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09
          18:12:26 root Exp $) with ESMTP id g4NGsHe13155 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May 2002 16:54:17 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com
          [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id
          g4NGuvv24052 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May 2002
          16:56:57 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by
          fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002052309582711792 ; Thu, 23 May 2002 09:58:27 -0700
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <KG0QXSQ4>; Thu, 23 May 2002 09:53:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Yang, Lily L" <lily.l.yang@INTEL.COM>
Message-ID:  <D9223EB959A5D511A98F00508B68C20C07FDE4FA@orsmsx108.jf.intel.com>
Date:         Thu, 23 May 2002 09:53:34 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Yang, Lily L" <lily.l.yang@intel.com>
Subject:      request for WG doc
Comments: To: "dro@zurich.ibm.com" <dro@zurich.ibm.com>,
          "Putzolu, David" <david.putzolu@intel.com>
To: FORCES@PEACH.EASE.LSOFT.COM

Patrick, David and all --

On behalf of my co-authors Ram Dantu, Todd Anderson and myself, I would like
to request the WG review this framework draft and consider accepting it as a
WG document.

Lily

> -----Original Message-----
> From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM]
> Sent: Wednesday, May 15, 2002 11:13 PM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt
>
>
> Hi, all --
> We submitted version 01 of the framework draft last week after a major
> rewrite:
> * added more description and diagrams to illustrate different physical
> configuration examples of ForCES CE/FE.
> * added examples of FE topology.
> * restructure the text to focus more on ForCES operation
> phases (pre- and
> post- association, reestablishment, etc.)
> * added examples to illustrate the handshake between CE and
> FE during these
> operational phases.
>
> please let us know what you think -- are these
> examples/diagrams useful?
> Have we missed anything important? Any comments on the draft
> are welcome!
>
> Thanks,
> Lily
>
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Wednesday, May 15, 2002 4:11 AM
> Cc: forces@peach.ease.lsoft.com
> Subject: I-D ACTION:draft-anderson-forces-arch-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : ForCES Architectural Framework
>         Author(s)       : T. Anderson, L. Yang, R. Dantu
>         Filename        : draft-anderson-forces-arch-01.txt
>         Pages           : 20
>         Date            : 14-May-02
>
> This document defines the architectural framework for ForCES network
> elements (NE), associated entities and the interaction among them.
> The architecture defined herein is intended to satisfy the
> requirements specified in the ForCES requirements draft [FORCES-
> REQ].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body
> of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-anderson-forces-arch-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         mailserv@ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-anderson-forces-arch-01.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need
> "munpack" or
>         a MIME-compliant mail reader.  Different
> MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have
> been split
>         up into multiple messages), so check your local
> documentation on
>         how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 23 16:01:32 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24704
	for <forces-archive@IETF.ORG>; Thu, 23 May 2002 16:01:31 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0061A62C@cherry.ease.lsoft.com>; Thu, 23 May 2002 16:01:50 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19230112 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 23 May 2002 16:01:13 -0400
Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d)
          with TCP; Thu, 23 May 2002 16:01:13 -0400
Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM
          (CommuniGate Pro SMTP 3.3) with ESMTP id 3004563 for
          FORCES@PEACH.EASE.LSOFT.COM; Thu, 23 May 2002 16:01:13 -0400
X-Sender: joel@stevecrocker.com@mail.stevecrocker.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Approved-By:  "Joel M. Halpern" <joel@STEVECROCKER.COM>
Message-ID:  <5.1.0.14.0.20020523155236.0181a690@mail.stevecrocker.com>
Date:         Thu, 23 May 2002 16:00:59 -0400
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject:      Requirements Document - Capabilities Model
To: FORCES@PEACH.EASE.LSOFT.COM

In reviewing the Requirements document and the proposed Architecture (or
framework) document, I realized that from my perspective there is an
additional piece of the puzzle that should be discussed along with the FE
model in the requirements document.

The requirements document describes an FE model, and indicates that it is a
capabilities model.  A capabilities model is a representation of what kinds
of operations something can perform, and frequently includes resource
availability (since resources have a direct effect on capability).
However, to control an FE, a CE needs to know more than just what it is
capable of.  It needs to know what the current configuration (state) of the
device is.  For example, if the CE is adding another filter, and wants to
cause traffic that matches that filter to be directed to an existing meter
or marker, then the CE must know how to refer to that meter or marker, and
the FE must understand that reference properly.  Therefore, there is a
shared model of the actual current state of the FE, which the CE
manipulates and the FE uses to manipulate its actual behavior.
The DiffServ conceptual model (and MIB / PIB) which have been mentioned as
starting points for the capabilities model are actually state models, not
capabilities models.  There is no way to tell from these models how many
filters a device can handle, or whether it is capable of
metering.  However, you can tell at any given time exactly what filters it
has, how they connect to markers, meters, queues, etc.  When you want to
configure additional processing elements into the processing path, you
reference the elements of this model.

Thus, the requirements document should call out the need for both a
capabilities model and a state model.

Yours,
Joel M. Halpern

PS: I am sorry that I am bringing this issue up in last call.  Fortunately,
not much text is required to resolve this.


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 23 16:33:31 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26188
	for <forces-archive@IETF.ORG>; Thu, 23 May 2002 16:33:31 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0061A64A@cherry.ease.lsoft.com>; Thu, 23 May 2002 16:33:50 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19231827 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 23 May 2002 16:33:50 -0400
Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 23 May 2002 16:33:49 -0400
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by
          caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09
          18:12:26 root Exp $) with ESMTP id g4NKWU611522 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May 2002 20:32:30 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com
          [132.233.48.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id
          g4NKVpf24474 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May 2002
          20:31:51 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by
          fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002052313324820585 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May
          2002 13:32:48 -0700
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <K7DJJAF8>; Thu, 23 May 2002 13:33:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Khosravi, Hormuzd M" <hormuzd.m.khosravi@INTEL.COM>
Message-ID:  <D9223EB959A5D511A98F00508B68C20C0C694FCB@orsmsx108.jf.intel.com>
Date:         Thu, 23 May 2002 13:33:36 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
Subject:      Re: Requirements Document - Capabilities Model
To: FORCES@PEACH.EASE.LSOFT.COM

Hi Joel

Thanks for the comments. If I understand you correctly, you
are saying that we need a Capabilities Model which expresses
all the possible caps and then an Instance Model which
specifies the instances of those caps on the FE. I think
the DiffServ model has both these, the MIB/PIB defines all
the possible caps and has place holder for instance Ids which
are used in the protocol at run-time. Do correct me if I am
wrong.

Anyways I think we already imply that we need both these in
the Requirements. Is there any particular text that you think
implies otherwise ??

regards
Hormuzd
-----Original Message-----
From: Joel M. Halpern [mailto:joel@stevecrocker.com]
Sent: Thursday, May 23, 2002 1:01 PM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: [FORCES] Requirements Document - Capabilities Model


In reviewing the Requirements document and the proposed Architecture (or
framework) document, I realized that from my perspective there is an
additional piece of the puzzle that should be discussed along with the FE
model in the requirements document.

The requirements document describes an FE model, and indicates that it is a
capabilities model.  A capabilities model is a representation of what kinds
of operations something can perform, and frequently includes resource
availability (since resources have a direct effect on capability).
However, to control an FE, a CE needs to know more than just what it is
capable of.  It needs to know what the current configuration (state) of the
device is.  For example, if the CE is adding another filter, and wants to
cause traffic that matches that filter to be directed to an existing meter
or marker, then the CE must know how to refer to that meter or marker, and
the FE must understand that reference properly.  Therefore, there is a
shared model of the actual current state of the FE, which the CE
manipulates and the FE uses to manipulate its actual behavior.
The DiffServ conceptual model (and MIB / PIB) which have been mentioned as
starting points for the capabilities model are actually state models, not
capabilities models.  There is no way to tell from these models how many
filters a device can handle, or whether it is capable of
metering.  However, you can tell at any given time exactly what filters it
has, how they connect to markers, meters, queues, etc.  When you want to
configure additional processing elements into the processing path, you
reference the elements of this model.

Thus, the requirements document should call out the need for both a
capabilities model and a state model.

Yours,
Joel M. Halpern

PS: I am sorry that I am bringing this issue up in last call.  Fortunately,
not much text is required to resolve this.


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 23 16:44:26 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26546
	for <forces-archive@IETF.ORG>; Thu, 23 May 2002 16:44:25 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0061A7D7@cherry.ease.lsoft.com>; Thu, 23 May 2002 16:44:42 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19233941 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 23 May 2002 16:44:18 -0400
Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d)
          with TCP; Thu, 23 May 2002 16:44:17 -0400
Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM
          (CommuniGate Pro SMTP 3.3) with ESMTP id 3004657 for
          FORCES@PEACH.EASE.LSOFT.COM; Thu, 23 May 2002 16:44:16 -0400
X-Sender: joel@stevecrocker.com@mail.stevecrocker.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Approved-By:  "Joel M. Halpern" <joel@STEVECROCKER.COM>
Message-ID:  <5.1.0.14.0.20020523164005.0182c040@mail.stevecrocker.com>
Date:         Thu, 23 May 2002 16:44:02 -0400
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject:      Re: Requirements Document - Capabilities Model
To: FORCES@PEACH.EASE.LSOFT.COM
In-Reply-To:  <D9223EB959A5D511A98F00508B68C20C0C694FCB@orsmsx108.jf.inte l.com>

The DiffServ model is definitely not a capabilities model.  There is no way
to express the fact that a given implementation is or is not capable of
having more than one queue, more than 0 markers, more than 0 meters, etc,
much less the number and kinds of meters, markers, queues, etc that it can
have.

There are places where the Requirements document implies that the model is
both a capability and a state model.  However, section 6 FE Model
explicitly states that the model is a capabilities model.

Yours,
Joel M. Halpern

PS: In other modeling work in and around the IETF it is referred to as a
state model(or sometimes a configuration model), not an instance model.  I
don't much care exactly what words we use to seaparte the two kinds of
models, but they are different, and need to be distinguished.

At 01:33 PM 5/23/2002 -0700, Khosravi, Hormuzd M wrote:
>Hi Joel
>
>Thanks for the comments. If I understand you correctly, you
>are saying that we need a Capabilities Model which expresses
>all the possible caps and then an Instance Model which
>specifies the instances of those caps on the FE. I think
>the DiffServ model has both these, the MIB/PIB defines all
>the possible caps and has place holder for instance Ids which
>are used in the protocol at run-time. Do correct me if I am
>wrong.
>
>Anyways I think we already imply that we need both these in
>the Requirements. Is there any particular text that you think
>implies otherwise ??
>
>regards
>Hormuzd
>-----Original Message-----
>From: Joel M. Halpern [mailto:joel@stevecrocker.com]
>Sent: Thursday, May 23, 2002 1:01 PM
>To: FORCES@PEACH.EASE.LSOFT.COM
>Subject: [FORCES] Requirements Document - Capabilities Model
>
>
>In reviewing the Requirements document and the proposed Architecture (or
>framework) document, I realized that from my perspective there is an
>additional piece of the puzzle that should be discussed along with the FE
>model in the requirements document.
>
>The requirements document describes an FE model, and indicates that it is a
>capabilities model.  A capabilities model is a representation of what kinds
>of operations something can perform, and frequently includes resource
>availability (since resources have a direct effect on capability).
>However, to control an FE, a CE needs to know more than just what it is
>capable of.  It needs to know what the current configuration (state) of the
>device is.  For example, if the CE is adding another filter, and wants to
>cause traffic that matches that filter to be directed to an existing meter
>or marker, then the CE must know how to refer to that meter or marker, and
>the FE must understand that reference properly.  Therefore, there is a
>shared model of the actual current state of the FE, which the CE
>manipulates and the FE uses to manipulate its actual behavior.
>The DiffServ conceptual model (and MIB / PIB) which have been mentioned as
>starting points for the capabilities model are actually state models, not
>capabilities models.  There is no way to tell from these models how many
>filters a device can handle, or whether it is capable of
>metering.  However, you can tell at any given time exactly what filters it
>has, how they connect to markers, meters, queues, etc.  When you want to
>configure additional processing elements into the processing path, you
>reference the elements of this model.
>
>Thus, the requirements document should call out the need for both a
>capabilities model and a state model.
>
>Yours,
>Joel M. Halpern
>
>PS: I am sorry that I am bringing this issue up in last call.  Fortunately,
>not much text is required to resolve this.


From owner-forces@PEACH.EASE.LSOFT.COM  Thu May 23 18:13:29 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29137
	for <forces-archive@IETF.ORG>; Thu, 23 May 2002 18:13:28 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0061A9C7@cherry.ease.lsoft.com>; Thu, 23 May 2002 18:12:28 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19239397 for FORCES@PEACH.EASE.LSOFT.COM;
          Thu, 23 May 2002 18:12:26 -0400
Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Thu, 23 May 2002 18:12:26 -0400
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by
          caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09
          18:12:26 root Exp $) with ESMTP id g4NMB7r24783 for
          <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May 2002 22:11:07 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com
          [132.233.48.109]) by talaria.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id
          g4NMFhd23057 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May 2002
          22:15:43 GMT
Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by
          fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002052315123519616 for <FORCES@PEACH.EASE.LSOFT.COM>; Thu, 23 May
          2002 15:12:35 -0700
Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <KHAZFT98>; Thu, 23 May 2002 15:12:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Yang, Lily L" <lily.l.yang@INTEL.COM>
Message-ID:  <D9223EB959A5D511A98F00508B68C20C07FDE505@orsmsx108.jf.intel.com>
Date:         Thu, 23 May 2002 15:12:22 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Yang, Lily L" <lily.l.yang@intel.com>
Subject:      Re: Requirements Document - Capabilities Model
To: FORCES@PEACH.EASE.LSOFT.COM

Since the motivation of an FE model is to allow CEs later to control and
configure FEs' behavior via ForCES protocol, it becomes essential to examine
and understand what kind of control and configuration CEs might do to FEs.
Maybe we can categorize them into 3 kinds.

The first kind of control and configuration is the simplest of all. It
assumes that each FE's capability is already given and remains static in its
lifetime, and CEs can only control its behavior by manipulating its state.
For example, an FE may provide a certain QoS function consisting of one
classifier with 3 filters, connected to fixed number of meters, markers,
queues etc. But the way these blocks connected is fixed and given. If such a
configuration remains static during FE's lifetime, then all CE can control
is the parameters associated with each block. But CE can not reconfigure the
topology (among classifiers, meters, markers, queues, etc.)  dynamically,
such as adding another meter or queue onto the FE on the fly. For this kind
of control and configuration purpose, the useful FE model is consisted of
the state information that FEs allow CEs to manipulate and the statistics
and events that FEs can collect and report back to CEs. Such a state model
doesn't need to describe a lot of other information, like the packet formats
supported between a particular meter and a particular counter, for example.
Because that is fixed and given.

The second kind of control and configuration builds on top of the first
category by allowing "dynamic FE" control and configuration. Therefore, an
FE state model is not sufficient now. A more powerful and flexible
capability model is required to convey information such as "This FE can
support one classifier with N filters, M meters, X queues, etc." It also
becomes necessary to model the capability of the building blocks like
classifiers, filters, meters etc. so that CE can configure them correctly.
For example, it becomes necessary to describe the packet formats supported
at each input and output of each block, because CEs need to have that
information to allow correct reconfiguration of the graph. Therefore, both
the FE state model and capability model become necessary for such dynamic
control and configuration.

The third kind of control and configuration is even more powerful and future
looking. In addition to dynamic configuration, CEs might be even allowed to
download a given functionality onto FEs. I am not sure how we model that
yet. But we probably can get by without too concerned with this.

My personal take on this is that we definetely MUST support the first kind
of "static FE" control and configuraiton, and we MAY also allow the second
kind of "dynamic FE". Therefore, a state model is a must and some flavor of
a capability model would also be good.

I guess when the requirement draft was written, this distinction was
probably not made explicitly. I believe the requirements regarding the model
in the document are still valid, except a few wording might need to be made
more explicit, esp. when we say "FE capabilities".

Lily

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> Sent: Thursday, May 23, 2002 1:44 PM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: Re: Requirements Document - Capabilities Model
>
>
> The DiffServ model is definitely not a capabilities model.
> There is no way
> to express the fact that a given implementation is or is not
> capable of
> having more than one queue, more than 0 markers, more than 0
> meters, etc,
> much less the number and kinds of meters, markers, queues,
> etc that it can
> have.
>
> There are places where the Requirements document implies that
> the model is
> both a capability and a state model.  However, section 6 FE Model
> explicitly states that the model is a capabilities model.
>
> Yours,
> Joel M. Halpern
>
> PS: In other modeling work in and around the IETF it is
> referred to as a
> state model(or sometimes a configuration model), not an
> instance model.  I
> don't much care exactly what words we use to seaparte the two kinds of
> models, but they are different, and need to be distinguished.
>
> At 01:33 PM 5/23/2002 -0700, Khosravi, Hormuzd M wrote:
> >Hi Joel
> >
> >Thanks for the comments. If I understand you correctly, you
> >are saying that we need a Capabilities Model which expresses
> >all the possible caps and then an Instance Model which
> >specifies the instances of those caps on the FE. I think
> >the DiffServ model has both these, the MIB/PIB defines all
> >the possible caps and has place holder for instance Ids which
> >are used in the protocol at run-time. Do correct me if I am
> >wrong.
> >
> >Anyways I think we already imply that we need both these in
> >the Requirements. Is there any particular text that you think
> >implies otherwise ??
> >
> >regards
> >Hormuzd
> >-----Original Message-----
> >From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> >Sent: Thursday, May 23, 2002 1:01 PM
> >To: FORCES@PEACH.EASE.LSOFT.COM
> >Subject: [FORCES] Requirements Document - Capabilities Model
> >
> >
> >In reviewing the Requirements document and the proposed
> Architecture (or
> >framework) document, I realized that from my perspective there is an
> >additional piece of the puzzle that should be discussed
> along with the FE
> >model in the requirements document.
> >
> >The requirements document describes an FE model, and
> indicates that it is a
> >capabilities model.  A capabilities model is a
> representation of what kinds
> >of operations something can perform, and frequently includes resource
> >availability (since resources have a direct effect on capability).
> >However, to control an FE, a CE needs to know more than just
> what it is
> >capable of.  It needs to know what the current configuration
> (state) of the
> >device is.  For example, if the CE is adding another filter,
> and wants to
> >cause traffic that matches that filter to be directed to an
> existing meter
> >or marker, then the CE must know how to refer to that meter
> or marker, and
> >the FE must understand that reference properly.  Therefore,
> there is a
> >shared model of the actual current state of the FE, which the CE
> >manipulates and the FE uses to manipulate its actual behavior.
> >The DiffServ conceptual model (and MIB / PIB) which have
> been mentioned as
> >starting points for the capabilities model are actually
> state models, not
> >capabilities models.  There is no way to tell from these
> models how many
> >filters a device can handle, or whether it is capable of
> >metering.  However, you can tell at any given time exactly
> what filters it
> >has, how they connect to markers, meters, queues, etc.  When
> you want to
> >configure additional processing elements into the processing
> path, you
> >reference the elements of this model.
> >
> >Thus, the requirements document should call out the need for both a
> >capabilities model and a state model.
> >
> >Yours,
> >Joel M. Halpern
> >
> >PS: I am sorry that I am bringing this issue up in last
> call.  Fortunately,
> >not much text is required to resolve this.
>


From owner-forces@PEACH.EASE.LSOFT.COM  Fri May 24 16:40:34 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13720
	for <forces-archive@IETF.ORG>; Fri, 24 May 2002 16:40:34 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0061D200@cherry.ease.lsoft.com>; Fri, 24 May 2002 16:40:54 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19316067 for FORCES@PEACH.EASE.LSOFT.COM;
          Fri, 24 May 2002 16:40:39 -0400
Received: from 134.134.248.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Fri, 24 May 2002 16:40:39 -0400
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com
          [192.168.65.206]) by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v
          1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g4OKeck27059 for
          <forces@peach.ease.lsoft.com>; Fri, 24 May 2002 20:40:38 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by
          orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002052413484606710 for <forces@peach.ease.lsoft.com>; Fri, 24 May
          2002 13:48:46 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id
          <LRCG3Y9S>; Fri, 24 May 2002 13:40:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Approved-By:  "Putzolu, David" <david.putzolu@INTEL.COM>
Message-ID:  <FD2423AA68A7D511A5A20002A50729E1064BF206@orsmsx115.jf.intel.com>
Date:         Fri, 24 May 2002 13:40:35 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Putzolu, David" <david.putzolu@intel.com>
Subject:      Accept Framework individual contrib as WG doc?
To: FORCES@PEACH.EASE.LSOFT.COM

All,

A new version of the ForCES Framework individual
contribution was submitted last week and the authors
have requested that it be accepted as a working
group document. This document is intended to satisfy
the charter deliverable of "An architectural framework
defining the entities comprising a ForCES network
element and identifying the interactions between
them."

Patrick and I would like the list to review and
comment whether this draft is ready to be accepted
as a ForCES working group document.  Note that
acceptance as a working group document associates
this document with the ForCES WG.  It does not grant
formal standards status to the document and the document
will remain open to change or removal.

Please submit your comments and recommendation to the
mailing list by Friday, May 31, 2002.

URL:
http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt

Thanks,
David


Lily Yang wrote:
>Patrick, David and all --
>
>On behalf of my co-authors Ram Dantu,
>Todd Anderson and myself, I would like
>to request the WG review this framework
>draft and consider accepting it as a
>WG document.
>
>Lily

> -----Original Message-----
> From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM]
> Sent: Wednesday, May 15, 2002 11:13 PM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt
>
>
> Hi, all --
> We submitted version 01 of the framework draft last week after a major
> rewrite:
> * added more description and diagrams to illustrate different physical
> configuration examples of ForCES CE/FE.
> * added examples of FE topology.
> * restructure the text to focus more on ForCES operation
> phases (pre- and
> post- association, reestablishment, etc.)
> * added examples to illustrate the handshake between CE and
> FE during these
> operational phases.
>
> please let us know what you think -- are these
> examples/diagrams useful?
> Have we missed anything important? Any comments on the draft
> are welcome!
>
> Thanks,
> Lily


From owner-forces@PEACH.EASE.LSOFT.COM  Wed May 29 19:17:40 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07080
	for <forces-archive@IETF.ORG>; Wed, 29 May 2002 19:17:40 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00629DA0@cherry.ease.lsoft.com>; Wed, 29 May 2002 19:17:02 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
          release 1.8d) with spool id 19657615 for FORCES@PEACH.EASE.LSOFT.COM;
          Wed, 29 May 2002 19:17:01 -0400
Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with
          TCP; Wed, 29 May 2002 19:17:01 -0400
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by
          caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24
          00:39:04 root Exp $) with ESMTP id g4TNFZA00874 for
          <forces@peach.ease.lsoft.com>; Wed, 29 May 2002 23:15:35 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com
          [132.233.48.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d:
          inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id
          g4TNEx122982 for <forces@peach.ease.lsoft.com>; Wed, 29 May 2002
          23:14:59 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by
          fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id
          M2002052916160108939 for <forces@peach.ease.lsoft.com>; Wed, 29 May
          2002 16:16:01 -0700
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id
          <K7DSS90K>; Wed, 29 May 2002 16:17:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Approved-By:  "Putzolu, David" <david.putzolu@INTEL.COM>
Message-ID:  <FD2423AA68A7D511A5A20002A50729E1064BF22B@orsmsx115.jf.intel.com>
Date:         Wed, 29 May 2002 16:16:58 -0700
Reply-To: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Putzolu, David" <david.putzolu@intel.com>
Subject:      ForCES Requirements Last Call issue resolution
To: FORCES@PEACH.EASE.LSOFT.COM

All,

Based on the list feedback and the responses of the
design team please find below the proposed issue
resolution for the ForCES Requirements last call
that just completed.

The design team has been asked to issue a new rev of
the requirements that incorporates the changes
proposed below.  Once that is available, a short
(1 week) last call will be held to review the changes
before this document is forwarded to the ADs.

If any issues were missed or the resolutions are not
properly documented please post a note to the list
ASAP.

Thanks,
David

--- cut here ---

Issue: Need for both a capabilities model and a state model
Resolution: Include in new rev of requirements. Lily Yang
has proposed some text that may be useful.

Issue: All failure notifications should be supported not
just "increase/decrease in available resources."
Resolution: Include in new rev. of requirements.

Issue: Should the requirements specify a minimal set of
functions?
Resolution: New rev. will include forwarding function
as the minimum.

Issue: Are there CE model requirements that need to be
included?
Resolution: Each requirement on the FE probably has a
corresponding control function on the CE - issue addressed.

Issue: FE should also be required to support error reporting
and monitoring.
Resolution: Include in new rev of requirements.