headers
Putzolu, David | 10 Jun 2004 16:20
Picon
Favicon

ForCES Protocol process update

All,

The Forces protocol design team has missed the June 2
milestone for distributing an early draft of their
proposal.  However, the team has informed me that they 
will have the a draft sent to the IETF for WG review by 
June 15th.  The design team has been making good
progress so I believe that this date will be met.

I have also been informed that the author of the original
FACT proposal, Alex Audu, will be submitting a separate
proposal based on FACT.

In order to make timely progress I will be asking the
working group to review the proposals and, if appropriate,
accept one as the official working group proposal by the 
meeting in San Diego in early August.

Cheers,
David Putzolu
Permalink | Reply | 1 comment |
headers
Jamal Hadi Salim | 10 Jun 2004 17:04

Re: ForCES Protocol process update

On Thu, 2004-06-10 at 10:20, Putzolu, David wrote:

> I have also been informed that the author of the original
> FACT proposal, Alex Audu, will be submitting a separate
> proposal based on FACT.

I sincerely hope that Hormuzd and Ram will ensure their names are not on
that draft. Otherwise, we should stop the protocol merger discussion
now.

cheers,
jamal
Permalink | Reply | 0 comments |
headers
Khosravi, Hormuzd M | 10 Jun 2004 18:54
Picon
Favicon

Re: ForCES Protocol process update

Jamal,

I am not even aware of this effort, I don't think Ram is either

regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
Sent: Thursday, June 10, 2004 8:05 AM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] ForCES Protocol process update

On Thu, 2004-06-10 at 10:20, Putzolu, David wrote:

> I have also been informed that the author of the original
> FACT proposal, Alex Audu, will be submitting a separate
> proposal based on FACT.

I sincerely hope that Hormuzd and Ram will ensure their names are not on
that draft. Otherwise, we should stop the protocol merger discussion
now.

cheers,
jamal
Permalink | Reply | 0 comments |
headers
Robert Haas | 11 Jun 2004 10:27
Picon
Favicon

Meaning of FEStatus and roles in the model

Hi,
I'd like to understand more precisely the meaning of FEStatus as 
specified in

 http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt

 5.2.2.1. FEStatus 

    This attribute carries the overall state of the FE.  For now, it is 
    restricted to the strings AdminDisable, OperDisable and OperEnable. 

Is FEStatus meant to be an attribute that can be set from the CE in 
order to activate/deactivate the datapath processing of the FE ?

What is the distinction between Admin(istrator) and Oper(ator) ?  Is a 
role-based authentication expected ?

Thanks,

--

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
Permalink | Reply | 3 comments |
headers
Joel M. Halpern | 11 Jun 2004 15:53

Re: Meaning of FEStatus and roles in the model

The distinction between Admin and Oper status comes out of other network 
management work.  sorry I was not more clear.
AdminDisable means that network management (maybe the CE via Forces if we 
choose to allow it, but more usually CLI or SNMP or ...) has disabled the 
device so it will not perform its function.  It is still active, and so may 
be discovered by a CE and might participate in ForCES.
OperDisable means that the FE thinks it ought to be operating, but has run 
into an operational difficulty that has caused it to cease performing its 
function.  For a single-ported FE, this might mean a port failure.  It 
might mean that some critical part internally has been detected to have 
failed.  It might just mean that the device is restarting and is not 
currently in a state to perform its functions.
OperEnable is the normal operational status.

This is not intended to be a comprehensive management diagnostic, but just 
enough information that the CE can know whether the FE is useable.  I added 
it because I did not want "ForCES reachable" to be assumed equal to 
"operationally available" since in reality the two are not always 
interchangeable.

Yours,
Joel

At 10:27 AM 6/11/2004 +0200, Robert Haas wrote:
>Hi,
>I'd like to understand more precisely the meaning of FEStatus as specified in
>
>http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt
>
>5.2.2.1. FEStatus
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Haas | 11 Jun 2004 17:18
Picon
Favicon

Re: Meaning of FEStatus and roles in the model

Thanks for the clarification. Is the FEStatus attribute read-only, or 
read-write ? I.e., can I activate the FE by setting its FEstatus to 
OperEnable, and deactivate it by setting it to AdminDisable ? NB, by 
activate/deactivate, I mean enable/disable the processing of data 
packets through the FE, i.e., enable/disable operation of all LFBs. Or 
is there another attribute for this ?

Regards,
-Robert

Joel M. Halpern wrote:

> The distinction between Admin and Oper status comes out of other 
> network management work.  sorry I was not more clear.
> AdminDisable means that network management (maybe the CE via Forces if 
> we choose to allow it, but more usually CLI or SNMP or ...) has 
> disabled the device so it will not perform its function.  It is still 
> active, and so may be discovered by a CE and might participate in ForCES.
> OperDisable means that the FE thinks it ought to be operating, but has 
> run into an operational difficulty that has caused it to cease 
> performing its function.  For a single-ported FE, this might mean a 
> port failure.  It might mean that some critical part internally has 
> been detected to have failed.  It might just mean that the device is 
> restarting and is not currently in a state to perform its functions.
> OperEnable is the normal operational status.
>
> This is not intended to be a comprehensive management diagnostic, but 
> just enough information that the CE can know whether the FE is 
> useable.  I added it because I did not want "ForCES reachable" to be 
> assumed equal to "operationally available" since in reality the two
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Audu | 11 Jun 2004 20:02
Picon

Re: Meaning of FEStatus and roles in the model

Simply put, an FE in AdminDisable status means the FE was removed by a management
entity (or manually by the craft person).  OperDisable'd  FE is an FE that was
removed
automatically by the fault-isolation program in the system.  In the latter case,
the system
will try to recover by for example, removing the FE, testing it, and then if OK,
restoring
it back to service.  Else, it is kept out of service.  In the AdminDisable
(manual) case,
the FE just stays out of service, and it shouldn't particiapte actively in
handling packets.

Cheers,
Alex.

"Joel M. Halpern" wrote:

> The distinction between Admin and Oper status comes out of other network
> management work.  sorry I was not more clear.
> AdminDisable means that network management (maybe the CE via Forces if we
> choose to allow it, but more usually CLI or SNMP or ...) has disabled the
> device so it will not perform its function.  It is still active, and so may
> be discovered by a CE and might participate in ForCES.
> OperDisable means that the FE thinks it ought to be operating, but has run
> into an operational difficulty that has caused it to cease performing its
> function.  For a single-ported FE, this might mean a port failure.  It
> might mean that some critical part internally has been detected to have
> failed.  It might just mean that the device is restarting and is not
> currently in a state to perform its functions.
> OperEnable is the normal operational status.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Putzolu, David | 16 Jun 2004 14:58
Picon
Favicon

Update on ForCES Protocol Design Team Activities

All,

The ForCES protocol design team was scheduled to post a 
draft of their proposed merged protocol on June 15th.

The team has the draft nearly ready and is in the
process of reviewing it.  I expect that it should be
posted for to the IETF for WG review by the end of 
the week.

Cheers,
David
Permalink | Reply | 1 comment |
headers
Alex Audu | 21 Jun 2004 17:23
Picon

Lucent proposes Soft Router concept.

Lucent tables proposal to separate forwading from routing at the NGN.
They call the
idea the Soft Router concept.

Follow this link for further details.
.....................................................................................................................................

The Softrouter Concept and the Proposal for the Study of Separation of
Forwarding and Routing in the Next Generation Network
http://www.itu.int/ITU-T/ngn/fgngn/docs/FGNGN-004-June04.doc
......................................................................................................................................

Regards,
Alex.
Permalink | Reply | 0 comments |
headers
avri | 23 Jun 2004 06:26

First draft of ForCES protocol from the protocol design team

Hi,

I have just sent our first draft of a "ForCES Protocol Specification" 
to the Internet Drafts editor.

In the meantime, it can be found at:

http://psg.com/~avri/forces/draft-fpteam-forces-protocol-00.txt

a.

For the ForCES protocol design team:
       Ligang Dong
       Avri Doria
       Ram Gopal
       Robert Haas
       Jamal Hadi Salim
       Hormuzd M Khosravi
       Weiming Wang
Permalink | Reply | 15 comments |

Gmane