Subject: Protocol draft

From: Furquan Ansari <[email-masked]>
Date: Fri, 2 Jul 2004 15:03:42 -0400

Hi All,

    I am new to this mailing list and am not sure if some of these
things have already been
discussed before, but I had some questions/comments on the force
protocol draft recently released.
(draft-fpteam-forces-protocol-00.txt)

1) The definition, functionality and the operations of the CEM and FEM
described in the
draft are unclear. The definition and the operation do not reconcile in
the text.
    For example, it is mentioned that an FEM/CEM is a logical entity and
can be physcically
part of  FEs or CEs.
    a) Does this mean that there can be multiple FEM/CEM per NE?
    b) If so, the architecural diagram seems to suggest otherwise (along
with text)
    c) If not, then how would a FEM physically residing on a particular
FE have the knowledge of all the
    other FEs in the NE - which is required during the pre-association
phase (figure 5) to exchange the
    list with the CEM.

    There seems to be some kind of disconnect there......

2) Assigning of IDs, security exchange etc. These operations are totally
punted in the draft and only
cursory references are made, in addition to being inconsistent at
various places.
    a) The draft does not explain how a security exchange takes place.
Does the identities of the elements
    be known before a security association is formed (which, I think,
should be the case). If so, what are
    these identities. Is it that the security association between the
FEM and FE made with respect to the FEM-ID
    and FE-ID? or is it something else....(not mentioned in the draft)
    b) If so, then how is it that the CE allowed to change the FEID as
part of a protocol message during the
    association phase. This would inherently break the existing security
association between the FEM and FE.

    c) Figure 4, suggests that during the pre-association phase and
after the security exchange, the FE provides
    its FEID and attributes. If this is a "MUST" requirement, then FEID
already exists and CE should not be allowed
    to set FEID during association setup phase. If it is not a
requirement, then figure 4 is incorrect - but then what
    is it exactly that FE and FEM exchanging?
        - I think, dynamically assigning an FEID to any device hooked up
by the CE would be a security flaw, since you             don't know who
that entity is to begin with (I guess it boils down to my previous
question - i.e. what is the ID
        used to identify yourself as, during the security association
phase).

3) The draft mentions the the ID should be "fundamentally unique"...
    - Does this mean that they should be globally unique, domain-wide
unique or NE-wide unique.
    - I think, the CE IDs should be network wide unique but the FEIDs
need only be NE wide unique and the same
    IDs can be reused by other FEs in different NEs, since they are
fundamentally seen as a single entiry from the
    network's perspective.

There are more comments, but I think I should stop here.... Would be
glad to hear the  responses.

Thanks,

--
Furquan Ansari
Bell Labs Research                      Ph : 732-949-5249
Holmdel, NJ                             Fax: 732-949-4556

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 2 Jul 2004 22:13:32 -0400

>     For example, it is mentioned that an FEM/CEM is a logical entity and

There were some assumptions about prior knowledge of the architecture.
Read the framework document.

>     a) Does this mean that there can be multiple FEM/CEM per NE?

Yes. Think of it as a configuration plane if you may.
A simple FEM for example could be a static confoig file.
Another simple one would be based on the FE getting all its boot
parameters from DHCP.
The reason that was left out of scope is because there may be vendors
who may have their own proprietary configuration protocols.

>     b) If so, the architecural diagram seems to suggest otherwise (along

Good point. It should show ecery CE/FE with an CEM/FEM.
Unfortunately it was cutnpasted from the framework which is now RFC.

>     There seems to be some kind of disconnect there......

If its not clear lets discuss.

> cursory references are made, in addition to being inconsistent at

The idea was to have an initial capture and cleanup/more meat after. The
bigger challenge was to merge the three proposals into one.

>     and FE-ID? or is it something else....(not mentioned in the draft)

The other authors may respond; but in regards to an FE - The FEID may be
configured based on something as simple as a geographical location of a
FE blade within a chasis/rack. This is something that would be known
in the preassociation phase.

> association between the FEM and FE.

I will let other coauthors respond - but one area you may want the FEID
changed is when theres conflict.

>         used to identify yourself as, during the security association

My beliefe is FEID should be known by the time Forces protocol boots up.
I will let other people respond.

> fundamentally seen as a single entiry from the

Makes sense. I would actually think both can be looked at as UUIDs.
Maybe this needs mentioning in the draft?

> glad to hear the  responses.

Please shoot.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Mon, 5 Jul 2004 17:40:40 +0200

Hi Furquan,
Thanks for your comments.

As Ram has also mentioned, the requirement is that IDs are unique within 
the Network Element (NE), so that the ForCES protocol can operate correctly.

Please explain why you think it is necessary that CE IDs are universally 
unique IDs (i.e., network-wide unique).

My opinion is that the parts within the NE (FEs and CEs) should NOT be 
individually addressable from outside the NE otherwise we wouldn't 
follow the black-box perspective.

IDs could have geographical meaning (rack #2, blade #5) as Jamal 
suggested. But the semantic of the ID is orthogonal to the protocol.

> fundamentally seen as a single entiry from the

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: Alex Audu <[email-masked]>
Date: Tue, 6 Jul 2004 14:51:23 -0500

I agree.  Requiring a universaly unique IDs  also implies requiring a way to
register
those IDs to guarantee non-collision and uniqueness.   IP addresses already
serve
this purpose, and I don't  think we need another such globally unique
identifier.

Regards,
Alex.