Subject: Re: new rev of framework draft, please comment

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 15 Oct 2002 20:20:41 -0700

Robert -- 
I didn't mean to restrict the off-loaded functions to routing. It is just
that this particular paragraph is under section 5.6."Application Layer --
Routing Protocols" and so it is only concerned with the routing protocols in
particular. Since this comes up as a general issue of deciding which
functions go to CE and which go to FE, I might need to state something more
general up front. The architecture should not in any way restrict what can
or should be off-loaded in the future as long as mechanism (=FE model)
exists to communicate that to ensure interoperability. I will fix the draft
along that line. Does it make sense?

thanks,
Lily

-----Original Message-----
From: Robert Haas [mailto:[email-masked]]
Sent: Saturday, October 12, 2002 12:32 AM
To: [email-masked]
Subject: Re: new rev of framework draft, please comment

Lily,
I see you added some text regarding "Off-loaded functions" into section 5.6.
"Application Layer -- Routing Protocols". This restricts the purpose of
off-loaded
functions to routing, i.e. OSPF Hello processing. In fact, as suggested in
my
previous note, parts of ICMP or TCP processing could as well be off-loaded
into the
FE. Could you please update the draft to make sure that no such restriction
is placed
on the type of off-loaded functions ?

Thanks,
-Robert

"Yang, Lily L" wrote:

> Hi, all
>
> After hearing back from the list, I've incorporated most of the comments
> into this new version. Please take a look and provide feedback. I will
wait
> a bit before submitting this version.
>
> Summary of changes since ver02:
> 1) Per suggestion from Jamal, the following is added at the end of Section
3
> (Introduction):
>         "Whenever necessary, this document uses many examples to
illustrate
> the issues and/or possible solutions in ForCES. These examples are
intended
> to be just examples, and should not be taken as the only or definite ways
of
> doing certain things. It is expected that separate document will be
produced
> by the ForCES working group to specify the ForCES protocol(s)."
>
> 2) Per suggestion from Jeelani and others about the "off-loaded
functions",
> the following is added at the end of Section 3 (Introduction):
>         "For performance or scalability reasons, portions of the control
> plane functions that need faster response may be moved from the CEs and
> off-loaded onto the FEs. For example in OSPF, the Hello protocol packets
are
> generated and processed periodically. When done at CEs, the inbound Hello
> packets have to traverse from the external interfaces at the FEs to the
CEs
> via the internal CE-FE channel. Similarly, the outbound Hello packets have
> to go from the CEs to the FEs and to the external interfaces. Frequent
Hello
> updates place heavy processing overhead on the CEs and can overwhelm the
> CE-FE channel as well. Since typically there are far more FEs than CEs in
a
> router, when off-loaded, the Hello packets are processed in a much more
> distributed and scalable fashion.
>
>         Once off-loaded onto the forwarding plane, such CE functions, even
> though logically belong to the control plane, now become part of the FE
> logical functions. Just like the other logical functions performed by FEs
> (e.g., IPv4 forwarding, classification, etc.), such off-loaded functions
> must be expressed as part of the FE model so that the CEs can take
advantage
> of these off-loaded functions when present on the FEs."
>
> 3) Per suggestion from Ram Gopal, the explicit security exchange is
deleted
> from the message exchange example (Fig 9) in Section 4.2.2.
>
> 4) More editorial changes here and there. All minor.
>
> Thanks,
> Lily
>
>  <<draft-ietf-forces-framework-03.txt>>
>
>   ------------------------------------------------------------------------
>                                          Name:
draft-ietf-forces-framework-03.txt
>    draft-ietf-forces-framework-03.txt    Type: Plain Text (text/plain)
>                                      Encoding: quoted-printable

--
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: Robert Haas <[email-masked]>
Date: Wed, 16 Oct 2002 09:59:27 +0200

Lily,
Yes, it makes perfect sense to have a more general statement upfront (under "5.
Applicability to RFC1812" ), and possibly give examples of such off-loading in
the following subsections.
Thanks,
-Robert