Subject: I-D ACTION:draft-anderson-forces-arch-01.txt

From: [email-masked]
Date: Wed, 15 May 2002 07:11:16 -0400

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:
        [email-masked].
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: Ram Dantu <[email-masked]>
Date: Thu, 16 May 2002 14:20:17 -0500

Alex,
Thanks for the input. See my comments

Regards
Ram Dantu

-----Original Message-----
From: Alex Audu [mailto:[email-masked]]
Sent: Thursday, May 16, 2002 2:07 PM
To: [email-masked]
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: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 15, 2002 4:11 AM
> Cc: [email-masked]
> Subject: I-D ACTION:draft-anderson-forces-arch-01.txt
>
>   ------------------------------------------------------------------------
>
> 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: "Putzolu, David" <[email-masked]>
Date: Thu, 16 May 2002 17:11:11 -0700

From: Ram Dantu [mailto:[email-masked]]
> [RD.start] Specifying the CE<-->CE interface in ForCES
> framework may not be appropriate place. However, we can
> mention several other functions of this

[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: "Yang, Lily L" <[email-masked]>
Date: Thu, 23 May 2002 09:44:59 -0700

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

> Sent: Thursday, May 16, 2002 12:07 PM