Subject: Re: Requirements

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Sep 2003 07:25:30 -0400

I do not agree that all FEs have this (inter-FE topology information).  I
have agreed that some FEs may have it.  And that having standard FE
attributes to represent this is probably useful.
I do not agree that there is value in the requirement.  It will not help us
choose among protocols.  It has already demonstrated a drive to cause
protocol elements that are not needed.

However, I have said enough for a while.  The working group nee3ds to decide
a) whether to fix the requirement in the I-D
b) whether to clarify some other way what is needed / wanted to meet the
requirement
or whether the group actively likes the requirement.

Yours,
Joel M. Halpern

At 10:50 PM 9/22/2003 -0700, you wrote:
>Hi Joel
>
>I understand your concern regarding the architectural requirement (sec
>5, #10) and I think we could clarify the text there, if still
>possible...or may be use the Framework draft to clarify this? Lily, any
>ideas?
>However, I believe that the protocol requirement text is fine and it
>should remain. From what I have heard so far, you agree that a) all FEs
>have this info, b) some FEs might acquire this thru some inter-FE
>discovery protocol or via FE manager and they should not be precluded
>from ForCES, c) CE needs this info. If you agree with a, b & c then it
>is natural to have some protocol mechanism to support this (whether it
>is a general or special mechanism is a separate issue)...unless you want
>to have a non-standard way to do this, which defeats the purpose of
>ForCES. You have also agreed that it is ok to have some optional
>mechanism for this. Now if you were in the Requirements team, which
>unfortunately you were not :), would you rather define optional
>requirements or mandatory ones ? This has a direct impact on the
>protocol design and interoperability.
>
>Also, I don't remember there having been any arguments or big
>discussions around this requirement before atleast in the design team.
>The only feeback we had received was from the IESG was to clarify the
>text in the Protocol Req section 7, which we did.
>
>I hope you will understand my point of view.
>Thanks a lot
>Hormuzd
>
>-----Original Message-----
>From: Forwarding and Control Element Separation
>[mailto:[email-masked]] On Behalf Of Joel M. Halpern
>Sent: Saturday, September 20, 2003 5:57 PM
>To: [email-masked]
>Subject: Re: [FORCES] Requirements
>
>A large part of my problem with this requirement is that it leads
>sensible
>implementors (such as yourself) to think that they need special protocol
>mechanisms to support this.  It also leads sensible FE implementors to
>think that they are somehow required to provide this implementation.
>
>1) FE's better not be required to provide inter-FE topology information.
>
>2) Allowing FEs which have such information to provide it does not
>require
>special protocol mechanisms in any reasonably designed protocol.  CEs
>will
>need to ask FEs for many pieces of FE level information.  If we must
>have a
>requirement in this area at all, it should be a requirement that the set
>of
>FE information a CE can query should include support for optional
>information about inter-FE connectivity.  (A CE should not be required
>to
>ask about this, an FE should not be required to provide this, and it
>really
>should not be treated as special information requiring special protocol
>support mechanisms.
>
>Another way of looking at this is that there are many kinds of
>information
>that an FE might be able to provide that might or might not be
>communicable
>in the initial set of information mandated for CE-FE querying.  For lots
>of
>reasons, the protocol MUST be extensible.  Making support of this
>information important relative to selecting / defining the protocol
>seems a
>serious mistake.
>
>Yours,
>Joel M. Halpern
>
>At 05:35 PM 9/20/2003 -0700, you wrote:
> >The text for this requirement has always been inter-FE topology (since
> >v-02).
> >I am pretty sure but I'll check with Todd anyways on this.
> >
> >If we do not provide protocol mechanisms to support this, then there
> >will
> >have to be non-standard ways to obtain this information from the FEs
> >which
> >provide this info, which we would like to avoid.
> >
> >Thanks
> >Hormuzd

---

From: Avri Doria <[email-masked]>
Date: Wed, 24 Sep 2003 09:15:39 +0900

> a) whether to fix the requirement in the I-D

There are actually two requirements in the ID

> 5. Architectural Requirements
>
>    The following are the architectural requirements:
...
>
>    10) In a ForCES NE, the FEs MUST be able to provide their topology
>    information (topology by which the FEs in the NE are connected) to
>    the CE(s).
>

and

> 7. ForCES Protocol Requirements

>    10)Topology Exchange
>    The ForCES protocol MUST allow the FEs to provide their topology
>    information (topology by which the FEs in the NE are connected) to
>    the CE(s). (refer to section 5, requirement# 10)

So far, I have mostly been arguing about the second item, the protocol
requirement.  I don't believe it needs to be fixed.  Though i would not
disagree with a should instead of a MUST.  Though i am not sure there
is effectively any real difference in an informational draft.  (RFC2119
language does not really pertain to Informational requirements except
in so far as the WG continues to support that language and its intent.)

I still think that any ForCES protocol should support the ability to
report information about the inter-fe topology, especially if it was
configured via a management interface to have this information.

On the other hand, the architectural requirement is probably more of an
issue.  While I do think that the FE should have the information about
its connectivity to other FEs, I can see how this might not always be
possible unless an inter-FE discovery protocol where to be used.  Again
I am not sure what the force of an architectural requirement is, though
I am sure that defining an inter-FE discovery protocol, while perhaps a
good idea, is not in the charter for this group at this time.  So this
may be a moot point, i.e it may not really matter what it says, except
perhaps as an incentive to people to think about the problems and ways
to engineer solutions to them.

> b) whether to clarify some other way what is needed / wanted to meet

I am fine with leaving it as is, but as i mentioned have not objection
to bumping the protocol requirement down to a lowercase should.

> or whether the group actively likes the requirement.

I believe that the architectural requirements  is functionality that a
fully capable FE should have, and that ForCES protocol should have the
ability to convey that information.  So, to answer the question, I
actively like the requirement.

a.