Yang, Lily L | 10 Oct 02:10 2002
Picon

Please consider last call on draft-ietf-forces-framework-02.txt

Hi,
We just submitted a new version of the ForCES framework draft.
Several people on the list have given us comments on the previous (ver01)
draft and we've incorporated all into this version.

Most of the change are minor, including:
        1) fixing Fig 6 (a) to make it really full mesh
        2) Moving the Abstract and Table of Contents to the front.
        3) Other editorial changes to improve clarity throughout the draft

A more significant modification is in section  5.7. "Application Layer --
Network Management Protocol". Per comments from T. Sridhar, when we talk
about how SNMP is supported in ForCES, we suggest that "AgentX framework
defined in RFC2741 may be applied here such that CEs act in the role of
master agent to process SNMP protocol messages while FEs act in the role of
subagent to provide access to the MIB objects residing on FEs. AgentX
protocol messages between the master agent (CE) and the subagent (FE) are
encapsulated and transported via ForCES, just like data packets from any
other application layer protocols."

Accordingly, a new reference to RFC2741 is also added in the "normative
reference" section.

As always, comments are welcome.

The co-authors feel that this framework draft has been through several
iterations and seems pretty stable now. So we would like the working group
chairs to consider last call on this version.

Thanks,
(Continue reading)

Putzolu, David | 10 Oct 02:15 2002
Picon

ForCES Requirements Status Update, 10/09/2002

All,

Our area directors have provided feedback on the
requirements draft - see below for a summary.  The
requirements design team is going to respond to the
feedback and post a new revision for the WG to
review.  This new rev will have a brief last call
comment period (one week), and then will be returned
to the IESG for review for publication.

Cheers,
David & Patrick, co-chairs, ForCES WG

--- AD Feedback ---

Section 6.5 Requirement 5) Vendor-Specific Functions

The ADs believe that the IESG will be very hesitant to
approve this part of the draft as worded.  This is due
to a concern that vendors would simply use the
extensibility mechanisms in the protocol to do everything
in a proprietary fashion, including "common" functions.

The ADs suggested rewording the section to talk about
extensibility to support new, currently unknown functions.
Make sure that it is clear that one is *not* compliant
with ForCES if one controls all the standard/common
functions in a proprietary manner.

Section 7 Requirement 6) Reliability
(Continue reading)

Syed, Jeelani | 10 Oct 15:55 2002
Picon

Re: Please consider last call on draft-ietf-forces-framework-02.t xt

Hi,

Sometimes you may have to run protocol counterparts(agents) on
FEs for protocols running on CEs to avoid packet latencies and
increase scalability. This draft doesn't talk abt that,
Is it because its too soon to talk abt it?

regards,

-jeelani.sm

-----Original Message-----
From: Yang, Lily L [mailto:lily.l.yang <at> intel.com]
Sent: Wednesday, October 09, 2002 8:11 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Please consider last call on draft-ietf-forces-framework-02.txt

Hi,
We just submitted a new version of the ForCES framework draft.
Several people on the list have given us comments on the previous (ver01)
draft and we've incorporated all into this version.

Most of the change are minor, including:
        1) fixing Fig 6 (a) to make it really full mesh
        2) Moving the Abstract and Table of Contents to the front.
        3) Other editorial changes to improve clarity throughout the draft

A more significant modification is in section  5.7. "Application Layer --
Network Management Protocol". Per comments from T. Sridhar, when we talk
about how SNMP is supported in ForCES, we suggest that "AgentX framework
(Continue reading)

Patrick Droz | 10 Oct 16:08 2002
Picon

Re: Please consider last call on draft-ietf-forces-framework-02.t xt

Jeelani,

there are some statments about this in the requirements
draft.
http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-06.txt
Section 6.5.  Point 8) Off-load Functions

Regards,
Patrick

Syed, Jeelani wrote:
> Hi,
>
> Sometimes you may have to run protocol counterparts(agents) on
> FEs for protocols running on CEs to avoid packet latencies and
> increase scalability. This draft doesn't talk abt that,
> Is it because its too soon to talk abt it?
>
> regards,
>
> -jeelani.sm
>
> -----Original Message-----
> From: Yang, Lily L [mailto:lily.l.yang <at> intel.com]
> Sent: Wednesday, October 09, 2002 8:11 PM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: Please consider last call on draft-ietf-forces-framework-02.txt
>
>
> Hi,
(Continue reading)

Syed, Jeelani | 10 Oct 16:26 2002
Picon

Re: Please consider last call on draft-ietf-forces-framew ork-02.t xt

Yep that's exactly what i was gettin at, Thanx Patrick.
Don't you think that the section  "5.6. Application Layer -- Routing
Protocols"
in framework draft is missing or ignoring that requirement. Just a concern.

Regards
-jeelani.sm

-----Original Message-----
From: Patrick Droz [mailto:dro <at> zurich.ibm.com]
Sent: Thursday, October 10, 2002 10:08 AM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: Please consider last call on
draft-ietf-forces-framework-02.t xt

Jeelani,

there are some statments about this in the requirements
draft.
http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-06.txt
Section 6.5.  Point 8) Off-load Functions

Regards,
Patrick

Syed, Jeelani wrote:
> Hi,
>
> Sometimes you may have to run protocol counterparts(agents) on
> FEs for protocols running on CEs to avoid packet latencies and
(Continue reading)

Yang, Lily L | 10 Oct 18:29 2002
Picon

Re: Please consider last call on draft-ietf-forces-framew ork-02.t xt

Jeelani --
That is a very good point. I have been thinking about it lately. The concept
and practice of "off-loading CE functions onto FE" or "split control plane"
challenge ForCES's way of defining FE and CE -- our terminology has been
that FE and CE are both "logical" entities -- but what really is the
boundary here? Is it logical boundary or physical boundary? Our goal is to
strive for physical sepration. So I think it is actually the physical
boundary that defines CE and FE. Maybe we should revise the definition to
reflect this. What do people think?

I was keenly aware of the fact that this was not addressed in the framework.
I was not sure where this should be addressed. I think you just point out a
good place to me.
I will get that fixed soon.

Thank you for your comment,
Lily

> -----Original Message-----
> From: Syed, Jeelani [mailto:jsyed <at> juniper.net]
> Sent: Thursday, October 10, 2002 7:27 AM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: Re: Please consider last call on draft-ietf-forces-framew
> ork-02.t xt
>
>
> Yep that's exactly what i was gettin at, Thanx Patrick.
> Don't you think that the section  "5.6. Application Layer -- Routing
> Protocols"
> in framework draft is missing or ignoring that requirement.
(Continue reading)

(Ram Gopal | 10 Oct 21:25 2002
Picon

Re: Please consider last call on draft-ietf-forces-framew ork-02.t xt

Greetings,

In my view off-loading part of  CE's functions  to line card is considered as part of CE 
and not part of FE. In this case a line card is capable of performing both forwarding 
functions and  control functions and provides both CE and FE logical endpoint.  
In other words,  the line card has capability to act as  CE as well as FE.   
FE represents forwarding plane entities only.  The logical separation of FE and CE should not mixed
with physical processing capability of hardware.  IMHO it is should treated as another CE endpoint 
contained in the line card rather than a function inside a FE.  

Regards
Ramg

 
> -----Original Message-----
> From: ext Yang, Lily L [mailto:lily.l.yang <at> intel.com]
> Sent: Thursday, October 10, 2002 12:29 PM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: Re: Please consider last call on draft-ietf-forces-framew
> ork-02.t xt
> 
> 
> Jeelani --
> That is a very good point. I have been thinking about it 
> lately. The concept
> and practice of "off-loading CE functions onto FE" or "split 
> control plane"
> challenge ForCES's way of defining FE and CE -- our 
> terminology has been
> that FE and CE are both "logical" entities -- but what really is the
(Continue reading)

Syed, Jeelani | 10 Oct 21:39 2002
Picon

Re: Please consider last call on draft-ietf-forces-framew ork-02.t xt

Yes I agree, but there is a whole set of interactions between CE and FE's
"CE logical end point" that needs to
be standardized in order to acheive the phyiscal seperation of CE & FE.

Regards

-jeelani.sm

-----Original Message-----
From: (Ram Gopal ) [mailto:ram.gopal <at> nokia.com]
Sent: Thursday, October 10, 2002 3:26 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: Please consider last call on draft-ietf-forces-framew
ork-02.t xt

Greetings,

In my view off-loading part of  CE's functions  to line card is considered
as part of CE
and not part of FE. In this case a line card is capable of performing both
forwarding
functions and  control functions and provides both CE and FE logical
endpoint.
In other words,  the line card has capability to act as  CE as well as FE.

FE represents forwarding plane entities only.  The logical separation of FE
and CE should not mixed
with physical processing capability of hardware.  IMHO it is should treated
as another CE endpoint
contained in the line card rather than a function inside a FE.
(Continue reading)

Alex Vasquez | 10 Oct 21:31 2002

Re: Please consider last call on draft-ietf-forces-framew ork-02.t xt

All,
I do not think we should be mixing logical entities with physical ones.
There should not be off-loading CE functions onto FE, this contradicts
current CE and FE definitions.  CE and FE  are logical entities with
concrete responsibilities. I can see that one can off-load a CE function
into a physical entity that can perform that CE functions. I can also see
that the same physical entity performing FE functions. Both, CE and FE,
running in the same physical entity should interact similarly as if they
were running in different physical entities. Thoughts?

Cheers,

Alex

> The information contained in this e-mail is LVL7
> Confidential.  Any use except that authorized by LVL7 is
> prohibited. If you get this in error, please notify sender
>         and delete this e-mail.
>

-----Original Message-----
From: Yang, Lily L [mailto:lily.l.yang <at> intel.com]
Sent: Thursday, October 10, 2002 12:29 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: Please consider last call on draft-ietf-forces-framew
ork-02.t xt

Jeelani --
That is a very good point. I have been thinking about it lately. The concept
and practice of "off-loading CE functions onto FE" or "split control plane"
(Continue reading)

Alex Vasquez | 10 Oct 21:37 2002

Re: Please consider last call on draft-ietf-forces-framew ork-02.t xt

Jeelani,

It seems to me that one should be able to use the ForCes messaging
regardless where the CE and FE are physically located.  Am I missing
something?

Cheers,

Alex

-----Original Message-----
From: Syed, Jeelani [mailto:jsyed <at> juniper.net]
Sent: Thursday, October 10, 2002 3:40 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: Please consider last call on draft-ietf-forces-framew
ork-02.t xt

Yes I agree, but there is a whole set of interactions between CE and FE's
"CE logical end point" that needs to
be standardized in order to acheive the phyiscal seperation of CE & FE.

Regards

-jeelani.sm

-----Original Message-----
From: (Ram Gopal ) [mailto:ram.gopal <at> nokia.com]
Sent: Thursday, October 10, 2002 3:26 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: Please consider last call on draft-ietf-forces-framew
(Continue reading)


Gmane