Subject: Re: Must LFBs be used for all functionality

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 10 Nov 2003 21:27:15 -0800

Now that you explained it, I think I was mistaken you then. 
I was more thinking of the problem of whether or not internal ports to
CE has to be modeled as LFBs as well -- my intuition is no. Because you
want to get ForCES running first before you get any LFBs instantiated.
But DoS doesn't come in the picture at the bootstrap time (there is not
data plane traffic at the time yet) as you explained. 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, November 10, 2003 5:43 PM
To: [email-masked]
Subject: Re: Must LFBs be used for all functionality

Actually, the examples you list are things that do belong in the ForCES
protocol and I do not object to them being in GRMP. (Security meaning
integrity, confidentiality, and related properties. I have indicated to
multiple sets of authors and when I was at the mike that I am happy to
see
the protocol providing for the expility separation of the control and
data
channels.)

What I was objecting to was specifically the protection against DoS.
DoS
protection is needed.  It applies to the traffic that needs to be
forwarded
from the FE data plane to the CE.  (There is no need to apply DoS
protection to traffic originated by the control entity on the FE.  If
that
traffic is attempting to DoS the CE, it will also bypass the
protections.  And management of the traffic rate for that traffic is
easily
accomplished by simpler mechanism inside the FE control logic.)

 From this, it follows that the traffic that needs to be monitored /
controlled is coming from the data plane, it is traversing a sequence of
LFBs.  An LFB has decided to divert it to the CE.

At that point, it is easy and natural to add relevant LFBs (chosen by
the
CE) to that data path.
By using LFBs, we gain several nice advantages.
1) If there is a limited FE that can only do a simple job, it can do
that
2) We do not need to add extra mechanisms to the control protocol for
this
problem
3) If we later on come up with better mechanisms, those FEs which
support
them can have them invoked by the CE with no protocol change.

Yours,
Joel M. Halpern

At 03:35 PM 11/10/2003 -0600, you wrote:
>Hi Joel,
>
>During the meeting you seemed to be objecting to the point that GRMP
>had some mechanisms, such as security and channels between the CE and
>FE, built in as protocol entities as opposed to being deployed with
>LFBs.
>
>I guess I don't understand your point.  There are various features that
>the protocol must have as defined by the requirements.  Is the LFB is
>the only tool that can be used to achieve these features?  I actually
>find some value in having some of the required elements, like security
>and channels between CE and FE built in, not that I am adamantly
>against using LFBs for this purpose if it can be done reliably - though
>I believe there may be a bootstrapping problem in using LFB for these
>purposes.
>
>But perhaps I misunderstand your objections.
>
>Thanks
>
>a.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 11 Nov 2003 07:34:00 -0800

Model them as LFBs with flags that they are also management
ports. This works quiet well.
I think you may also be thinking these ports are dedicated for
such work. This may not always be true.

cheers,
jamal