Subject: Re: [alto] ALTO Operations and Management

From: Richard Alimi <[email-masked]>
Date: Wed, 1 Aug 2012 14:58:02 -0700

We discussed this during the meeting, and the suggestion was to get a
discussion going on the list for exactly which aspects of RFC5706
should be discussed in draft-ietf-alto-protocol.  I would very much
like to avoid revisiting what should and shouldn't be included at a
later date.  Thus, consider it started :)

I'll get the ball rolling:
- Logging
  - Use syslog
  - Minimum set of events that SHOULD be logged
    - Request logs (may already be provided by HTTP server implementation)
    - ALTO Map updates (version tag, cost mode, cost type, size in
both entries and encoded bytes)
    - Changes to runtime configuration (e.g., data source
configuration, security parameters)
    - Failure to update served ALTO information (e.g., failure to
contact a data source used to compute ALTO info)

Installation and Initial Setup
- By default an ALTO Server may be configured with a single PID
containing all IPv4/IPv6 addresses and a Cost Map with no entries.
Something more interesting should be configured explicitly (either
dynamically or statically).

Migration Path
- Applications making use of other data sources for network
information should consider ALTO an additional source of information,
but ALTO need not be the sole source of network information.
Therefore, it can be incorporated incrementally into applications.

Requirements on Other Protocols and Functional Components
- Protocol-wise, ALTO assumes standard HTTP and JSON implementations exist.
- Functional-wise: An ALTO Server assumes that it can gather
sufficient information to populate Network and Cost maps.  "Sufficient
information" is dependent on the information being exposed, but likely
includes information such as IGP and EGP RIBs (more details in Section
2.2 of draft-ietf-alto-protocol-12).  Extension documents may provide
specific mechanisms.

Impact on Network Operation
- Operators should consider impacts on (or integration with) Traffic
Engineering, since ALTO may shift traffic patterns.
- Privacy considerations for ISPs (see 10.1 of draft-ietf-alto-protocol-12)
- Impact of incorrect/faked guidance (see 10.3 of
draft-ietf-alto-deployments-04)

Anything else?

Thanks,
Rich

On Sun, Jul 29, 2012 at 11:43 PM, Richard Alimi <[email-masked]> wrote:
> Hi All,
>
> As you probably know, one of the new requirements on the protocol is:
>    An ALTO client protocol MUST provide adequate
>    mechanisms for operations and management support, as outlined in RFC
>    5706 [RFC5706].
>
> The points raised by RFC5706 are very good and should indeed be
> solved. What I'm missing currently is a clear picture of exactly what
> this requirement dictates for draft-ietf-alto-protocol.  In
> particular, the scope of RFC5706 is *huge* - to address every
> suggested point fully would take another couple of years (e.g.,
> specify a management API for ALTO Servers, a configuration language,
> techniques for verifying end-to-end operation, etc).
>
> I'll suggest a way forwards - please provide feedback if you have a
> chance.  I'd really like to get something mostly complete by the end
> of IETF week if possible.
>
> Proposal:
>
> If we separate Operations (RFC5706, Section 2) from Management
> (RFC5706, Section 3), I can make the following general observation:
> - Operations: the protocol draft seems like a fine place to document
> these, with the exception of 2.6 ("Verifying Correct Operation") which
> is covered in Section 6.3 of draft-ietf-alto-deployments-04
> - Management: draft-ietf-alto-deployments seems to already cover some
> of this, and could probably be expanded to cover the rest (well, the
> rest that we intend to solve) to keep the related information
> together.  That seems preferable than copying a bunch of content from
> draft-ietf-alto-deployments into draft-ietf-alto-protocol when we had
> intentionally kept them separate in the first place.  The exception to
> this might be dictating which protocols to use for some functions that
> we know would be needed (syslog, IPFIX), which seem fine to have in
> draft-ietf-alto-protocol.
>
> Thoughts on that?  The intent isn't to just punt this over to another
> draft, but rather to avoid duplicating text between different
> documents and finish the protocol draft in a reasonable amount of
> time.
>
> If that *does* sound reasonable, I can write up some more concrete
> text for the Operations section with a pointer indicating that
> Management considerations are being documented in
> draft-ietf-alto-deployments (seems like an Informative reference, so
> that should be fine?)
>
> If that *doesn't* sound reasonable, I'd really like to hear from
> people what should be documented in the ALTO Protocol draft itself to
> support Operations and Management.  Below my signature, I've included
> some quick notes below about what I think *could* be discussed for
> most of the points raised by RFC5706.  I don't think the authors of
> the new requirement envisioned all of that to be included in
> draft-ietf-alto-protocol, but I'd need some help in defining where to
> draw the line.
>
> Thanks,
> Rich
>
> -- Operations --
>
> (1) Installation and Initial Setup
> - By default an ALTO Server may be configured with a single PID
> containing all IPv4/IPv6 addresses and a Cost Map with no entries.
> Something more interesting should be configured explicitly (either
> dynamically or statically).
> - Specifications for underlying protocols (e.g., TCP, HTTP) should be
> consulted for their available settings/defaults.
>
> (2) Migration Path
> - No migration path for ALTO Servers since there is no previous
> protocol providing same functionality.
> - Client-side: Applications making use of other data sources for
> network information should consider ALTO an additional source of
> information, but ALTO need not be the sole source of network
> information.
>
> (3) Requirements on Other Protocols and Functional Components
> - Protocol-wise, ALTO assumes standard HTTP and JSON implementations exist.
> - Functional-wise: An ALTO Server assumes that it can gather
> sufficient information to populate Network and Cost maps.  "Sufficient
> information" is dependent on the information being exposed, but likely
> includes information such as IGP and EGP RIBs (more details in Section
> 2.2 of draft-ietf-alto-protocol-12).  Specific mechanisms have been
> suggested in the past as extensions (e.g.,
> draft-medved-alto-svr-apis-00).
>
> (4) Impact on Network Operation
> - Operators should consider impacts on (or integration with) Traffic
> Engineering, since ALTO may shift traffic patterns.
> - Privacy considerations for ISPs (see 10.1 of draft-ietf-alto-protocol-12)
> - Impact of incorrect/faked guidance (see 10.3 of
> draft-ietf-alto-deployments-04)
>
> (5) Verifying Correct Operation
> - For ALTO-specific monitoring and metrics, see 6.3 of
> draft-ietf-alto-deployments-04
>
> -- Management --
>
> (1) Interoperability
> - A common management API would be desirable given that ALTO Servers
> may typically be configured with dynamic data from various sources,
> and ALTO Servers are intended to scale horizontally for
> fault-tolerance and reliability
>   - management protocol should operate semantically at the level of
> ALTO maps or other exposed information
> - Entities that compute dynamic maps/guidance and entities that
> measure ALTO's effects should use IPFIX information elements
> - ALTO Servers should use syslog to log events.
>
> (2) Management Information
> - Informational Model
>   - Data Sources - the set of data sources made available to an ALTO Server
>   - Information Resource Directory - the set of ALTO Information
> exposed by an ALTO Server
>   - Section 4 and 5 of draft-ietf-alto-protocol-12 describe Network
> Map, PIDs and Cost Maps, which are central entities of the
> informational model.
>   - ALTO guidance: ALTO Server may use internal logic/algorithms to
> generate responses to ALTO Clients (map and endpoint-based queries);
> may be customized to a particular deployment environment, so not
> standardized (as long as responses follow protocol spec). May use
> Network Map and Cost Map to answer queries, or may use custom logic.
>
> (3) Fault Management
> - To be discussed in 6.3 of draft-ietf-alto-deployments
>
> (4) Configuration Management
> - ALTO Server requires at least the following (high-level) logical inputs:
>   - Data Sources (raw network , or explicitly-provided ALTO-level
> information such as a Network Map and Cost Map)
>   - Security policies
> - Configuration interface should use ALTO data structures (as
> specified in the ALTO Protocol itself) wherever possible to configure
> the ALTO information exposed by an ALTO Server.  Specific syntax may
> differ if porting to a language that is not JSON, but structures
> should remain consistent.
> - Specify standard configuration language and interface for interoperability
> - Multiple ALTO Servers my be deployed for horizontal scalability. A
> centralized configuration database may be used to ensure they are
> providing the desired ALTO information with appropriate security
> controls.  The ALTO information (e.g., Network Maps and Cost Maps)
> being served by each ALTO Server, as well as security policies (HTTP
> authentication, SSL/TLS client/server authentication, SSL/TLS
> encryption parameters) intended to serve the same information should
> be monitored for consistency.
> - Verifying Correct Operation: Discussed in 6.3 of
> draft-ietf-alto-deployments (and future revisions)
>
> (5) Accounting Management
> - Discussed in 6.3 of draft-ietf-alto-deployments (and future revisions)
>
> (6) Performance Management
> - List interesting counters
>   - e.g., Number of requests for each service, responses, bytes
> in/out, CPU utilization, ALTO map/guidance updates, number of PIDs,
> map sizes (bytes, number of entries), etc
> - Interesting data accessible by IPFIX
>   - e.g., bytes per src/dst IP
> - network devices
>   - link utilization
>
> (7) Security Management
> - Readers should refer to documentation on HTTP and SSL/TLS.
> - ALTO Servers will typically receive a large number of requests.
> Intrusion Detection Systems that can separate malicious attacks from
> noise are suggested when generating alerts.
>
>
> Thanks,
> Rich