Re: Scope, Profiles

[George Jones <gmj@pobox.com>]

On Mon, 24 Jun 2003 ericb@digitaljunkyard.net wrote:

> This document is aimed at two separate entities:
>
> 1) Vendors.  They must provide the knobs and dials to tweak.  Perhaps
>    also with sane defaults, depending on the outcome of several
>    religious debates.
>
> 2) Users.  These range from kinda clueful to really lost.  (Clueful
>    users are either working on this document, or unemployed)
>
> So the capabilities that must exist are addressed to the vendors and
> purchasers of devices.
>
> How to twist those knobs and dials is addressed at the network
> engineers who actually design, deploy and manage the devices.
>
> gmj> or "include this group of capabilities" ?   I can see groupings like
>
> gmj>   Edge Device
> gmj>      1. Filtering of traffic trough the device
> gmj>      2. Filtering of traffic to the device
> gmj>      3. Support rate-limiting
>
> gmj>   Core Device
> gmj>      1. Filtering of traffic to the device
>
> These would fall into the "more advanced requirements" section.
>
> So you have:
>
> Baseline requirements
>         Device provides service (IP addr, packet forwarding, etc),
>         device must provide capability (IP filtering TO, AAA, etc)
>
> Advanced requirements
>         Device is used in a certain profile (customer aggregation,
>         CPE, core router), device must provide this (filtering
>         THROUGH, etc)
>
> Configuration guidelines
>         Given a device with certain baseline and advanced
>         capabilities, you, the user, should configure it thusly.  This
>         section will further act as justification for the requirements
>         above.  Here, we'll describe why the knobs should be turned
>         just so.
>
> Basically, I like the idea of profiles, I just think that the common
> requirements and config bits should be factored out.  Common
> requirements (baseline) are a strong line to hold, things we can push
> for from vendors with serious effort.  Maybe filtering THROUGH at
> OC192 isn't possible, but you'd BETTER implement filtering TO.

OK.   I've been chewing on this, and I think the following
restructuring of the doc would improve clarity and achieve
what you're driving at (as well as incorporating some useful
feedback from Neal):

The current structure is something like:

  2. Long list of BCP reqs
  3. Long list of non-BCP reqs
  A. Profiles ( == lists of reqs from 2 and 3)
  A.1 Minimum Reqs Profile
  A.2 L3 Core
  A.3 L3 Edge

I think it would make sense to move somewhat closer to what
you were suggesting

  2. Profiles (still list reqs, but now forward references listing
     descriptive name of req)

  2.1  Baseline (for all devices implementing IP, the "hard line")
  2.2  L3 Edge
  2.2  L3 Core
  ...
  2.N  SOHO
  2.N+1  Wireless

  3. List of reqs
  3.1 Functional
  3.2 Assurance
  3.3 Documentation

  4. Configuration Guidance (corresponding to section 2).
  4.1  Baseline
  4.2  L3 Edge

This accomplishes the following things:

  * It creates a telescoping effect, so you're not reading
    "the device must support OoB management" in a vacuum
    before getting to the end and finding out that it is
    not included in the SOHO and Wireless profiles.
    You see, up front, in bullet form, what the basic
    reqs are and what the groupings/profiles discussed are.

  * It breaks out functional, assurance and documentation items
    per Neal's suggestion.

It has the following down-sides

  * Forward references (Neal, you indicated that you thought
    these were a problem)

  * It moves profiles into the body of the doc.  The profiles
    that we can write for device classes today will become
    dated and will, by definition, be incomplete.  The idea
    of profiles was that the doc would provide a few common
    ones and specify mechanisms for users to create their
    own profiles as their needs dictated and as times change.

  * I'm not sure about including guidance.  This has really
    not been a focus up to now...the working assumption was
    that given the knobs, operators could/would/should make
    their own choices.  I'm not opposed to including guidance,
    but I think it might be better as a seperate or companion
    doc.

Eric, does this work for you ?  Neal ?  Others ?

---George