Subject: Re: ForCES model - other thoughts

From: "Yang, Lily L" <[email-masked]>
Date: Sun, 16 Nov 2003 17:30:48 -0800

Alistair -- 

On terminology: I agree with you we should use the same terminology
between ForCES and NPF when it is appropriate. In the specific case of
"resources" vs. "attributes", I would suggest NPF people (Zsolt, Steve
etc.) adopt "attributes" in their NPF document, since we've discussed
this before in the model team. 
 
On metadata pass through: The model team discussed this last week at
Minneapolis and the consensus was that it is NOT needed for ForCES. So
it will disappear soon from our draft.

I am not sure I follow exactly what you meant when you talk about
dynamic reconfiguration and the connection with metadata pass thru. Did
you mean LFB topology reconfiguration? The mailing list had just
witnessed some very active and healthy discussion on this very subject
in the last 2-3 weeks and the consensus seems to suggest that, yes, the
topology reconfiguration is considered useful and so the FE model will
support it. Again, in case it is not obvious, it does not mean that
every FE has to be capable of doing dynamic reconfiguration of its LFB
topology.

You should see all these comments being incorporated into the new v02
draft that the team is currently working on.

Thank you very much for your comments. I agree it is important to keep
NPF and ForCES aligned and anyone who is involved in both forums has to
shoulder that responsibility.

Lily

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Alistair Munro
Sent: Monday, November 10, 2003 3:32 AM
To: [email-masked]
Subject: ForCES model - other thoughts

Hi All,

I'm writing to express my opinion about the ForCES model draft in my
role
as editor of the corresponding document in the Network Processing Forum.
There are only two points that I can tease out as separate from the
ongoing
discussion threads.

First, the main gripe I have right now is about terminology. The
requirements and purpose of the NPF and IETF models overlap sufficiently
well that we can use the same names for things. Specifically, at present
NPF uses "resources" as a term where the IETF text refers to
"attributes".
Neither is good enough right now - NPF probably doesn't qualify
resources
enough, while the ITEF text has at least three categories of attribute.
It
would be good to get this aligned.

My point: several of the IETF editors are also present and contributing
in
the NPF, so it shouldn't be too hard.

Second, as a general comment, there are several parts of the draft that
I
would find too constraining because they seem to imply [assumptions
about]
implementation behaviour. For example, section 4.4.4: metadata pass
through
limitations, metadata CONSUME/PROPAGATE mode selector. I think this
comes
about because of the dynamic reconfiguration capability that the model
is
apparently intended to support, which  requires a very specific
operational
model and semantics if it is to be invoked at a fine grain by the CE.

My point: this capability isn't, as far as I can tell, a ForCES
requirement
on the model. Or am I mistaken?

Regards,

Alistair

--
Alistair Munro,
Principal Engineer, U4EA Technologies Ltd.
City Point, Temple Gate, Bristol, BS1 6PL, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-373-6751
Web: http://www.u4eagroup.com

---

From: Alistair Munro <[email-masked]>
Date: Mon, 17 Nov 2003 10:57:05 -0000

Hi Lily,

> you mean LFB topology reconfiguration?

It was a general observation about topology reconfiguration, not about
specific attributes which I mentioned only as examples.

Putting my comments another way, if you have a reconfigurable topology then
you need a bunch of non-functional attributes to adjust the behaviour of
the LFB instances after you have moved them around the FE. In my opinion,
if you follow this line of thinking through, then you need to say a lot
more about what an LFB implementation does and how it does it. Usually this
means constraints on implementers, but this sort of thing doesn't come for
free.

Notwithstanding the discussion or whether it is actually a model
requirement, I don't think incremental topology reconfiguration is useful
or usable but so long as I can ignore it I have nothing against it. I hope
my reply to David's consensus question clarified this.

The next thing I would worry about is the length of time it will take to
define, and agree on, the root LFB classes. Maybe your V.02 will clarify
this.

Regards,

Alistair

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 17 Nov 2003 09:34:27 -0500

Lily> Thank you very much for your comments. I agree it is important to
Lily> keep NPF and ForCES aligned and anyone who is involved in both
Lily> forums has to shoulder that responsibility.

The NPF connection bothers me. AFAIK, the NPF has no liason with the
IETF. Their documents other than ones which are complete are only
accessible to members. Unfortunatley, docs which make more sense
have not completed that level yet.
Granted some people attending the NPF also attend the IETF, but it is
extremely difficult to follow arguements based on some closed documents.
Either the NPF makes exception or i strongly recommend we stop refering
to them at ForCES.
I am willing to keep the docs to myself and not redistribute it if an
exception is made.

cheers,
jamal

---

From: John Renwick <[email-masked]>
Date: Tue, 18 Nov 2003 04:44:07 -0600

Jamal,

As a representative to NP Forum, please let me try to answer you.  First, we
can ask the NPF board if there's a way we can make some of our Functional
API
(FAPI) drafts public for the purpose of liaison with ForCES, but they may
say
no.  Second, if you saw the NPF drafts, you might be "underwhelmed."  In
many
ways they are in a rougher state than the ForCES drafts.  Third, while we
could
establish a formal liaison, what's actually happening is much more effective
than that: common authorship.  Some of the people and companies making the
strongest contributions to the ForCES model and protocol proposals are
making
the same or compatible proposals in NPF, even taking the lead there.  This
is
the best way to ensure that ForCES and FAPI work well together, which is
what
we all want.  ForCES is not being led in some sinister way down a path
decided
by NPF in secret.  Rather, the same people are openly influencing both
groups
in the same directions, and their names are listed in the ForCES drafts as
authors.  Some NPF drafts that we thought were ready for approval are
actually
being held in the FAPI task group now, waiting for consensus to arrive in
ForCES
so that they can be adjusted to agree with ForCES details if necessary.

I don't mean to suggest that you should join NPF, but if you were to
participate
there, you would see pretty much the same thing you're seeing in ForCES,
many
of the same people, and some of the same debates.  As Lily said, the ForCES
work
stands on its own; the drafts are being worked on openly, not influenced or
constrained in any way by things you can't see going on in NPF.

Best Regards,

John

--
John Renwick                          Agere Systems
Software Technical Manager            1230 Northland Drive
Phone: (651) 675-2986                 Mendota Heights, MN 55120
FAX:   (707) 897-7928                 Cell:  (612) 669-9397
mailto:[email-masked]             http://www.agere.com

> [mailto:[email-masked]]On Behalf Of Jamal Hadi Salim
> Sent: Monday, November 17, 2003 8:34 AM
> Subject: NPF WAS (Re: ForCES model - other thoughts
>
>