Subject: Issue Summary: Inter-FE Topology requirements

From: "Putzolu, David" <[email-masked]>
Date: Thu, 25 Sep 2003 20:39:33 -0700

All,

Thanks for the discussion on the topic of inter-FE topology.
There are two sections of the requirements document that have 
caused discussion here - Section 5 #10, which is an 
architectural requirement, and Section 7 #10, which is a 
protocol requirement.  

Patrick & I have followed the list discussion and conferred 
with the ADs.  We suggest resolving this issue as follows:

Issue #1: The architecture requirement (S5#10) says that FE's 
must be able to provide to CEs the topology by which the FEs 
in the NE are connected.  We suggest rolling this back to 
what the requirement was in requirements-01:

   10) In a ForCES NE, the CE(s) MUST be able to learn the topology by
   which the FEs in the NE are connected.

This is suggested because it is possible for CEs to learn 
topology information without the FEs having to provide
it, and there are real systems that operate in such a fashion.

Issue #2: The protocol requirement (S7#10) says that the ForCES 
protocol must provide a mechanism to carry inter-FE topology 
info to the CE.  Given the resolution to issue#1, it is clear
that a mechanism to deliver topology information is not always
used in the Fp reference point (because the element providing
topology information might not be a FE).  As such, we recommend
changing S7#10 from a MUST to a MAY.  If a protocol author 
believes that topology information is sufficiently important, 
then they may include it in their protocol.  However,
if a protocol author believes it is not necessary then they may
omit it.   It will be up to the WG as a whole to determine during
protocol selection the incremental value from including such
mechanisms (for those protocols that choose to do so).

Finally, there is also a procedural issue, in that this document
is in the RFC editor's queue and as such it is a strange
time to be changing the contents.  Patrick & I believe the
necessary changes can be made during the author's 48 hour 
period, which has not started yet.

We believe that the above recommendations are consistent
with the statements and general consensus of the list. 
If anyone has an objection to this resolution, or would like
to suggest different replacement text, please make this known.

Thanks,
David and Patrick

---

From: Avri Doria <[email-masked]>
Date: Fri, 26 Sep 2003 13:15:11 +0900

I am fine with the first change (architecture) but uncomfortable with
the second (protocol).

I believe the protocol, as designed, should be able to carry.  That
would the protocol requirement.

I believe it may or may not be called on to do so. That is an
implementation detail.

a.