headers
Wang,Weiming | 1 Jul 2004 02:38
Picon

Fw: First draft of ForCES protocol from the protocol design team

From: "Wang,Weiming" <wmwang <at> mail.hzic.edu.cn>

> Hi Sridhar,
>
> Yes, it is an editorial error made by my carelessness. It  should be
> . Inter FE topology
> . Intra FE topology, i.e., LFB topology.
> I'm sorry for the carelessness,  and will correct it.
>
> Thank you so much.
> Weiming
>
> ----- Original Message -----
> From: "T. Sridhar" <sridhar <at> futsoft.com>
> To: "Khosravi, Hormuzd M" <hormuzd.m.khosravi <at> intel.com>; "Wang,Weiming"
> <wmwang <at> MAIL.HZIC.EDU.CN>
> Sent: Tuesday, June 29, 2004 2:22 PM
> Subject: RE: [FORCES] First draft of ForCES protocol from the protocol design
> team
>
>
> > Yes, Hormuzd & Weimang,  they are primarily editorial.
> >
> >  I thought that the Intra FE Topology is really the LFB topology, so it
> > looks like an editorial problem. Same with Packet Redirect - my nit is that
> > CE to FE traffic for packets to be sent out of the NE are not really
> > redirects. However, it is a nit and I am OK if it stays the same.
> >
> > Thanks,
> > Sridhar
(Continue reading)

Permalink | Reply | 0 comments |
headers
Furquan Ansari | 2 Jul 2004 21:03
Picon
Favicon

Protocol draft

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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Khosravi, Hormuzd M | 3 Jul 2004 00:24
Picon
Favicon

Re: Protocol draft

Hi Furquan,

Thanks for your comments. You have raised some good questions.
Pls see my comments below... 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Furquan Ansari

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.
[HK] Yes, I think there are some inconsistencies between what has been
described in the pre-association phase, and the post-association (forces
protocol) regarding assigning FE IDs. This is something that needs to be
discussed further by the team. Any thoughts ?

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
[HK] I agree, this is my thinking as well.

Thanks
Hormuzd
Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 3 Jul 2004 04:13

Re: Protocol draft

On Fri, 2004-07-02 at 15:03, Furquan Ansari wrote:
> 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.

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Khosravi, Hormuzd M | 3 Jul 2004 04:44
Picon
Favicon

Re: Protocol draft

Jamal, 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim

>     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)

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.
[HK] I have a slightly different understanding, I believe the FEID is
assigned by the CE during ForCES association setup, which is
post-association (you have mentioned one reason for it below). But I
know the draft is not very clear on this, I am glad Furquan brought this
up. Lets discuss this one. Any other thoughts on this? Weiming, Robert,
Ram, others ?

Regards
Hormuzd

>     b) If so, then how is it that the CE allowed to change the FEID as
> part of a protocol message during the
(Continue reading)

Permalink | Reply | 0 comments |
headers
(Ram Gopal | 5 Jul 2004 00:17
Picon

Re: Protocol draft

Hello All,

Comments are inline...

<... > 
> 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.

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

<RamG>
We need to make sure the scope of such uniqueness wehterh NE wide or 
topology(AS) wide.
<RamG>

Regards
Ramg
Permalink | Reply | 0 comments |
headers
(Ram Gopal | 5 Jul 2004 16:42
Picon

FW: Protocol draft

resending this email it bounced back for me.

-----Original Message-----
From: Gopal Ram (Nokia-NRC/Boston) 
Sent: Sunday, July 04, 2004 6:13 PM
To: 'Furquan Ansari'; FORCES <at> PEACH.EASE.LSOFT.COM
Subject: RE: Protocol draft

Hello Furquan Ansari,

Comments are inline....

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM]On Behalf Of ext Furquan Ansari
Sent: Friday, July 02, 2004 3:04 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Protocol draft

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Haas | 5 Jul 2004 17:40
Picon
Favicon

Re: Protocol draft

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.

Furquan Ansari wrote:

>
> 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.

Regards,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Putzolu, David | 6 Jul 2004 21:04
Picon
Favicon

Call for Agenda Items, ForCES WG meeting <at> IETF 60

All,

The ForCES working group is scheduled to meet
from 1300-1500 on Monday, August 2nd at IETF 60.

Please send agenda time requests to myself 
(david.putzolu <at> intel.com) and Patrick 
(dro <at> zurich.ibm.com) by Friday, July 23 
at 5:00pm ET. All agenda requests should
include the following:

Required: Presentation title
Required: Presenter
Required: Requested duration
Optional: Name of related IETF draft
Optional: Slides or other presentation materials

Thanks,
David and Patrick
Permalink | Reply | 0 comments |
headers
Alex Audu | 6 Jul 2004 21:51
Picon

Re: Protocol draft

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.

Robert Haas wrote:

> 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.
>
> Furquan Ansari wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane