Subject: Re: ForCES MIB: 1st draft

From: Tom Petch <[email-masked]>
Date: Fri, 4 Nov 2005 18:33:43 +0100

Another issue occurred to me.

A MIB module, such as ForCES MIB, normally sits alongside other MIB modules,
even if that is only mib-2.  Is that the case here? eg if you have a ForCES MIB
module per CE, one of the options below, would you then have a mib-2 in each CE?

Tom Petch

----- Original Message -----
From: "Robert Haas" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 13, 2005 3:33 PM
Subject: Re: ForCES MIB: 1st draft

> All,
>
> Below is the 1st draft, which raises a few issues.
>
> Regards,
> -Robert
>
>
>
> ForCES MIB
>
> (draft version 00-a)
>
> 0. Abstract
>
> This document specifies the ForCES MIB.
>
>
> 1. Introduction
>
> The ForCES MIB is a read-only MIB that captures information related to
> the ForCES protocol. This includes state information about the
> associations between CE(s) and FE(s) in the NE.
> [Note: anything else besides associations that the MIB should include?]
>
> The ForCES MIB does not include information that is specified in other
> MIBs, such as packet counters for interfaces, etc.
>
> The information in the ForCES MIB relative to associations includes more
> specifically:
>
> - identifiers of the elements in the association
> - state of the association
> - configuration parameters of the association
> - statistics of the association
>
> The relevant references from the ForCES requirements and architecture
> documents are repeated below:
>
> Requirements RFC 3654 http://www.ietf.org/rfc/rfc3654.txt
> Section 4, point 4:
>    4) A NE MUST support the appearance of a single functional device.
>    For example, in a router, the TTL of the packet should be decremented
>    only once as it traverses the NE regardless of how many FEs through
>    which it passes.  However, external entities (e.g., FE managers and
>    CE managers) MAY have direct access to individual ForCES protocol
>    elements for providing information to transition them from the pre-
>    association to post-association phase.
>
> Section 4, point 14:
> 1. The ability for a management tool (e.g., SNMP) to be used to read
>       (but not change) the state of FE SHOULD NOT be precluded.
> 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to
>       change the state of a FE in a manner that affects overall NE
>       behavior without the CE being notified.
>
> Architecture RFC 3746 http://www.ietf.org/rfc/rfc3746.txt
> Section 3.3:
> CE managers may be physically and logically separate
>    entities that configure the CE with FE information via such
>    mechanisms as COPS-PR [7] or SNMP [5].
>
> Section 5.7:
> 5.7.  Application Layer -- Network Management Protocol
>
>    RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP".
>    In general, for the post-association phase, most external management
>    tasks (including SNMP) should be done through interaction with the CE
>    in order to support the appearance of a single functional device.
>    Therefore, it is recommended that an SNMP agent be implemented by CEs
>    and that the SNMP messages received by FEs be redirected to their
>    CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here
>    such that CEs act in the role of master agent to process SNMP
>    protocol messages while FEs act in the role of subagent to provide
>    access to the MIB objects residing on FEs.  AgentX protocol messages
>    between the master agent (CE) and the subagent (FE) are encapsulated
>    and transported via ForCES, just like data packets from any other
>    application layer protocols.
>
>
>
> 2. Design of ForCES MIB
>
> As state information is distributed across FEs and CEs, the following
> alternatives may be considered:
>
> 1) CE MIBs
> Each CE in the NE implements a CE MIB. The external SNMP-based
> management tool must therefore be aware of each CE in order to obtain a
> complete view of the NE by collecting state information obtained from
> each CE MIB.
> [Note: this may or may not comply with requirement #4 ("A NE MUST
> support the appearance of a single functional device")]
>
> 2) single NE MIB
> An entity in the NE implements an NE MIB that aggregates state
> information collected from each CE (CEs are possibly from various
> vendors). This requires a standard protocol in order to support
> multi-vendor environment. AgentX with the NE as the master and the CE(s)
> as the agent(s) may be considered here.
> [Note: comments on the suitability of AgentX ?]
>
> [Note: none of the two alternatives are ideal ...]
>
> 3. Capturing State Before Association Establishment
>
> The ForCES protocol may be used by the CE to query the FE Protocol LFB
> about some of the configuration parameters. But such queries may
> obviously be issued only once the association is established.
>
> In the ForCES protocol, the FE first issues an Association Setup Request
> message to the CE which in turns responds with an Association Setup
> Response message. It may be useful to capture in the MIB in which state
> the association is seen from each of the FE and the CE sides, as a means
> to detect PL-level communication anomalies. For instance, from the FE
> side, the association is in the ATTEMPT state as long as no response to
> the Association Setup message has been received from the CE. Similarly,
> the association is in the ESTABLISHING state as long as no message has
> been received from the FE after the CE has issued a positive Association
> Setup Response message (this is because configuration mistakes in the FE
> may cause messages from the CE to be ignored, and the MIB could help in
> tracing such errors).
>
> The transient state in the FE until the association is established
> cannot be queried using ForCES.
> [Note: If such information is critical, then an FE MIB has to be
> provided that can be queried separately]
>
>
> 4. MIB Definition(s)
>
> For each association identified by the pair CE ID and FE ID, the
> following information is included in the MIB:
>
> [Note: the MIB includes all associations for the particular CE in the
> case of a CE MIB, same for FE MIBs (if any), or all associations in the
> NE in the case of a NE MIB]
>
> - Current state of the association:
>
>   UP:   the CE(s) indicated by the CE ID and FE(s) indicated by
> the FE ID are associated.
>   ESTABLISHING/ATTEMPT: transient state unitl the association is
> established. See section 3 above for details.
>
> Note that associations that are not UP and for which no association
> setup is in progress are NOT listed in the MIB.
> [Note: otherwise how do we decide which old associations to remove from
> the MIB ?]
>
> - Hearbeat timers values of the FE and CE for this association.
>
> - Heartbeat timer settings of the FE and CE for this association:
>
>   ENABLED:  hearbeats are transmitted (by default virtual piggybacking
> is used)
>   DISABLED: heartbeats are not transmitted
>
> - Backup information: the FE(s)/CE(s) that are configured to work as
> backups for this association.
> [Note: is this necessary, useful ?]
>
> - Association statistics:
>   Date/time when the association came to the UP state.
> [Note: what about the Number of commands executed or some indications of
> the ForCES control traffic ?]
>
>
> TBD: actual MIB specification.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 5 Nov 2005 00:36:18 -0500

I would certainly expect each CE to support other MIB modules.  The ForCES 
working group does not need to mandate which ones are supported, except in 
so far as we choose to reference them for some reason.  For example, I 
would expect that the CE will provide the MIBs for each routing protocol it 
is running.

We may want to (should?) write a document that describes how the ForCES CE 
and the FEs that it manages show up in the existing MIBs.  (What should a 
CE report in its IFTable? etc)  I am not sure where that would go, but it 
would not be in the ForCES MIB.

Yours,
Joel

At 12:33 PM 11/4/2005, Tom Petch wrote:
>-

---

From: Tom Petch <[email-masked]>
Date: Mon, 7 Nov 2005 09:50:40 +0100

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 05, 2005 6:36 AM
Subject: Re: ForCES MIB: 1st draft

> would not be in the ForCES MIB.

Agree on all points.  Something like an

OAM for ForCES?

Tom Petch

---

From: Avri Doria <[email-masked]>
Date: Mon, 7 Nov 2005 20:39:40 -0800

Hi,

this seems important to me as well.

and given the, currently voluntary, goal in the Routing Area to  
include a manageability section for all protocols it seems like  
something we should do.

at one point I had thought this should go in the protocol spec, but  
given the way we have divided up the work into multiple documents i  
am wondering whether this doesn't belong in an applicability RFC (info).

speaking of which, didn't we have one at one point that was put on  
hold until the work saw further progress?  is that document still  
alive?  should it be revived at this point?

a.

---

From: Robert Haas <[email-masked]>
Date: Tue, 8 Nov 2005 23:33:10 +0100

Hi All,

Attached are the slides shown today at the ForCES wg meeting, and below 
are some issues raised during my presentation. The draft is at:
http://www.ietf.org/internet-drafts/draft-haas-forces-mib-00.txt

- A MIB per CE appears to be preferrable to a single NE MIB. But, if 
necessary, one may implement a NE MIB on top of multiple CE MIBs. Note 
that it is not clear where in the NE such a NE MIB would reside. This 
draft standardizes the CE MIBs only.

- Associations in the DOWN state MAY be listed in the MIB. But there is 
no obligation for the MIB to include FE IDs it does not know of (i.e., 
FEs with which the CE has never been associated with). How long DOWN 
associations are kept in the MIB remains (needs?) to be defined.

Regards,
-Robert

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-44-724-8698  fax +41-44-724-8578  http://www.zurich.ibm.com/~rha