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

From: "Yang, Lily L" <[email-masked]>
Date: Thu, 10 Oct 2002 13:55:45 -0700

(a)Physical boundary view:
+--------------+
|    CE        |
+--------------+
        |
+------------------+
|    +-----------+ |
|    |CE offload | |
|    +-----------+ |
|  FE              |
+------------------+

(b)Logical boundary view:
+------------------+
|  CE              |
|    +-----------+ |
|    |CE offload | |
|    +-----------+ |
+------------------+
        |
+--------------+
|    FE        |
+--------------+

Conceptually, I like to stick with the "logical" boundary view and consider
the CE offload as a case of CE-CE coordination for load sharing. But it is
still a special kind of CE-CE coordination because it directly gets into our
way of achieving the grand vision of "physical separation". And because this
CE offload function really resides on the FE, we have to use CE-FE interface
to carry this "CE-CE" communication messages. It is in this sense that I
think the "physical" view actually reflects more accurately the impact on
the architecture. ForCES needs to encapsulate a lot of things any way, so I
don't see why it can't encapsulate this CE-CE messages. But this kind of go
against the statement that "ForCES is for CE-FE only" and it also means
CE-CE interaction now gets into the picture of interoperability. Say a line
card (FE) from vendor X can tell a control card (CE) from vendor Y that "I
can do OSPF hello offload". Now a bit more extra need to be in place before
these two cards (physical entieis) can interoperate. That is some kind of
CE-CE interface for OSPF hello offloading.

All I am trying to get to is an understanding of how much ForCES can or
cannot enable by itself in such scenario if we insist on the logical view.
Framework draft calls out things like "if you want to do CE redundancy, you
need CE-CE in addition to ForCES". Now similarly, I would say "if you want
to do CE offloading, you also need more than ForCES". Is that a right thing
to say?

Or, alternatively, we can take the physical boundary view and say "CE
offload" is part of FE. Then ForCES is still exclusively used for CE-FE. And
as requirement draft already points out, FE model need to be able to express
such capability. Does it mean "OSPF Hello offload" is a functional block
just like a "classifier" or "IPv4 Forwarder"?

Lily

> -----Original Message-----
> From: Syed, Jeelani [mailto:[email-masked]]
> Sent: Thursday, October 10, 2002 12:59 PM
> To: [email-masked]
> Subject: Re: Please consider last call on draft-ietf-forces-framew
> ork-02.t xt
>
>
> Good point, Then off-loading CE functions" should be
> considered as a CE-CE interaction, which is nothing
> but load-sharing. CEs can load-share responsibilities
> among themselves within protocol itself, for ex: Within
> OSPF one of them will take care of running SPF and other
> responding to Hellos.
>
> Regards
> -jeelani.sm
>
> -----Original Message-----
> From: Alex Vasquez [mailto:[email-masked]]
> Sent: Thursday, October 10, 2002 3:31 PM
> To: [email-masked]
> Subject: 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:[email-masked]]
> Sent: Thursday, October 10, 2002 12:29 PM
> To: [email-masked]
> 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
> 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:[email-masked]]
> > Sent: Thursday, October 10, 2002 7:27 AM
> > To: [email-masked]
> > 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.
> > Just a concern.
> >
> > Regards
> > -jeelani.sm
> >
> > -----Original Message-----
> > From: Patrick Droz [mailto:[email-masked]]
> > Sent: Thursday, October 10, 2002 10:08 AM
> > To: [email-masked]
> > 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-requirem
> > ents-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:[email-masked]]
> > > Sent: Wednesday, October 09, 2002 8:11 PM
> > > To: [email-masked]
> > > 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
> > > 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,
> > > Lily
> > >
> > >
> > >  <<draft-ietf-forces-framework-02.txt>>
> > >
> > >
> >
> >
> > --
> >    Dr. Patrick Droz                     | [email-masked]
> >    IBM Zurich Research Laboratory       |
> > http://www.zurich.ibm.com/~dro
> >    Saumerstrasse 4                      | Tel.
> +41-1-724-85-25 CH-8803
> >    Rueschlikon/Switzerland              | Fax. +41-1-724-85-78
> >
>

---

From: Robert Haas <[email-masked]>
Date: Fri, 11 Oct 2002 13:38:00 +0200

Lily, Jeelani,

"Syed, Jeelani" wrote [excerpt]:

> I see a drawback with first approach(CE offload is beyond ForCES), a
> vendor making a forwarding plane have to take care of all
> control plane vendors that are compatible with it for offloading.

> just like a "classifier" or "IPv4 Forwarder"?

Short answer: you are right.

Long answer:

The debate boils down to: what are today functions that we envision as "FE
functions" ? Is generating an ICMP error message something that an FE could do ?
Obviously yes. Then the FE has to model this for the CE to be able to drive this
function. In this case, the CE would simply tell the FE: "please take care of
ICMP processing locally ( and don't bother me with this noise )".

The same argument holds for TCP termination or OSPF-Hellos state machine: to
ensure interoperability between FE vendors that incorporate such functions and
CE vendors, we must make sure ForCES defines the appropriate semantics for the
CE to drive these functions in the FEs.

So it's up to us to decide what we think are useful functions that FEs could
perform, and then ensure that ForCES has the semantics to allow the CE to
drive/control such functions. That was the reason why I suggested the addition
of the "Off-loaded Functions" section into the requirements draft, and this
should be reflected into the framework draft somehow.

Regards,
--
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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 11 Oct 2002 08:20:39 -0400

I am confused by the excitement. 

There is functionality which resides on the FE - some block. Its controller
resides in the CE and tells the block how to behave via forces....
Some event: either a packet arrival or timer makes this block behave in 
a certain manner (as directed by its controller); 
Why should it matter whether it cooks, dices, meters packets, terminates or 
emits ospf hellos?
The model already takes care of this (havent read the model draft in a while, 
so if it doesnt then it should). 

cheers,
jamal