Subject: Re: Requirements

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 20 Sep 2003 17:35:08 -0700

Jamal,

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
-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Saturday, September 20, 2003 4:57 PM
To: [email-masked]
Subject: Re: [FORCES] Requirements

Hormuzd,

Talk to Todd - i think he was the one who added this. And i think
it was meant to imply intra-FE  not inter-FE topology.
Either it should be clarified to be intra-FE (which i agree is LFB
specific) or totaly removed. I dont think we should stop anyone from
implementing it if they wish but it should not be on a protocol check
list.

cheers,
jamal

On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote:

> The intent of this requirement was not to mandate all FEs to have this
> information, as is suggested in section 5 # 10,
> but to support protocol mechanisms to obtain this information from FEs
> if it is available, as is stated in section 7 # 10.
> I agree that the text in section 5 # 10 needs to be modified to bring
> out the correct intent, which is stated in section 7 # 10.
> As for the history, this requirement has been around since version 02
of
> the draft back in Feb 2002.
>
> Since the Requirements is already in the RFC queue, I was wondering if
> it is possible to make any edits at this point
> without causing a lot of delays. Any advise David, Patrick ??
>
> Thanks
> Hormuzd
>
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of Deleganes, Ellen M
> Sent: Friday, September 19, 2003 10:39 AM
> To: [email-masked]
> Subject: Re: [FORCES] Requirements
>
>
>
> I agree with those who have stated the architecture requirement in
> section 5, #10 (shown below) puts an unnecessary burden on the FEs and
> is not required in order to perform topology discovery. I also agree
> that other solutions are available that do not require this
> functionality of the FE (e.g. the CE could perform the discovery, it
> might be entered manually, some other manager could do the discovery).
>
>
>
> 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).
>
>
>
> I suspect based on a protocol requirement #10 (shown below) that the
> intent was that some mechanism to report topology information from the
> FE to the CE must exist. However, nowhere in the document does it
state
> that that FE functionality is optional. I believe that clarification
> should be added.
>
>
>
> 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)
>
>
>
> One suggestion is to rewrite requirement #10 in section 5 to be
similar
> to item 10) Topology Exchange and perhaps add the qualifier that the
FEs
> are NOT REQUIRED to be able to provide topology information to the
CEs.
> Regards,
> Ellen Deleganes

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 20 Sep 2003 17:47:51 -0700

Hormuzd,

Can you provide an example - maybe that will clarify it for me.
Is the information you refer to not available at the CE or what
does having it at the FE buy you? Could the CE teach the FE?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 20 Sep 2003 20:58:20 -0400

One important aspect here is that the CE need never teach the FE about the
topology between FEs.  The FE needs to know which exist to send a packet
out, with what headers.  The FE does not care "who" is receiving that
packet.  The CE cares a great deal.

Yours,
Joel M. Halpern

---

From: Alex Audu <[email-masked]>
Date: Mon, 22 Sep 2003 11:49:36 -0500

Not if the behavior of a group of FEs depends on their connectivity! If CE can
configure that behavior, then the CE better be able to teach each FE in that
group their connectivity information.

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Mon, 22 Sep 2003 11:57:25 -0500

Jamal,

Don't forget that the CE may lose this information by it going out of service.

It is possible this information may have been stored in a more persistent
storage
from which the CE could refresh the lost information. But there is no
guarrantee
that will be most current. The best place to get the most current information
is from the element whose current behavior is determined by this information.
And that is
the FE.

Regards,
Alex.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Sep 2003 14:23:03 -0400

I disagree.
It is quite likely that the desired behavior depends upon the topology.
The CE determines the Topology
The CE selects the Desired Behavior
The CE teaches (directs) the FE in how to behave.

The CE never tells the FE what the topology is, because that does not
matter to the FE.  What matters to the FE is how it should
behave.  Provided from the CE.

Yours,
Joel M. Halpern

---

From: Alex Audu <[email-masked]>
Date: Mon, 22 Sep 2003 17:02:04 -0500

How would the CE best direct the behavior of FEs if not through topology
configuration? The control of the inter-FE topology and its consequences
should not be too different from those of the intra-FE topology. In the latter,
the CE could set the LFBs up in ways to achieve certain behaviors. We could
take a different tack for inter-FE topology,.. but why?

Regards,
Alex.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Sep 2003 20:07:16 -0400

I am sorry, but I am afraid I am misunderstanding you.
The CE uses the FORCES (Fp) protocol to direct the FE.
It uses the knowledge of the inter-FE topology which it gleans from a
combination of configuration and discovery protocols (of which there are
many).  Such discovery protocols are the kinds of things CEs run (they send
the packets out through and receive response from the FE, but the CE has
the protocol machinery.

While there may be devices where inter-FE topology is controllable, such
control is outside of the scope of FORCES.  We are controlling individual
FEs.
[It is possible that there will be LFBs that can be used to assist in such
functions.  It is possible that there will be other protocols that are
supported by the CEs or FEs to do such things.  However, that is not the
domain of FORCES.]
In contrast, the intra-FE operations are the domain of FORCES.  Some folks
actually asked that we leave control of intra-FE topology out of the
work.  We have decided that intra-FE topology is within scope.  (With the
caveat that not all FEs will support that, and that even FEs which support
reconfigurable intra-FE topology will have restrictions on what can be set up.)

Other than static configuration (which is highly error prone) there is no
obvious way for FEs to know their inter-FE topology.  You suggested earlier
that FEs should have this static configuration rather than CEs.  I think it
is more reasonable to put that on the CE, but that is something reasonable
folks can differ on.

Part of what causes me concern about this protocol requirement is that as
written it has prompted several protocol proposals to include explicit
mechanisms for addressing this "need".  I do not object to including in the
set of attributes an FE might have optional attributes about known FE
adjacency.  However,
a) that needs to be optional, and the current wording makes it look mandatory
b) it should be worded in a way that does not encourage the creation of
special protocol mechanisms.  By this I mean that the wording should be
about the system / solution enabling the transfer of the information, not
about the protocol having the ability to carry it.  (And no, that
distinction should not matter.  It observably does matter since two
different proposals have fallen into this trap.  And at least one responded
that they need to keep the special mechanism to meet the requirements when
I questioned the authors about it.)

Yours,
Joel M. Halpern

---

From: Alex Audu <[email-masked]>
Date: Tue, 23 Sep 2003 09:43:07 -0500

I think I see where the problem is. Our use of the term "topology" may need
to be put in the proper context.

A network of routers has a topology to it. We can break this up into
cooperating Autonomous Systems (ASs) with each AS consisting of
a set of routers controlled by a single administrative authority.  Routers
withing an AS can run neighbor discovery protocols to determine the
topology of the AS.  This is inter-router connectivity whithin an AS.

The ASs also run discovery protocols (e.g EGP) to discover neighboring
ASs. This is inter-AS topology discovery.

The ForCEs specification has allowed us to take an NE ( e.g. a router) and
distribute its control and forwarding elements over a local area network.
One of the driving forces for this is scalability. A resulting benefit is that we
can group a set of forwarding elements (in an NE) to cooperate in solving
a problem or providing some service. There is a topology involved here.
The FEs should know how to forward the packets to the next FE in this
cooperating unit to achieve the set goal. This topology is configured, *not*
discovered. This is the topology I think the ForCEs requirement is talking
about.

Regards,
Alex.