Subject: Washington Issue 1 - Audit of Ephemerals at start up

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Nov 1999 10:13:05 -0500

A number of issues were raised in the Washington meeting that were "send to
the
list".  This is one of these issues, with the problem and my suggested fix.

Problem: When you boot, before you create any ephemeral terminations, how do
you know what the MG can do.  For example, how do you know if the MG has,
say
an IP interface, an ATM interface, an MPLS interface or a Frame Relay
interface for the bearers, or some combination of them.

If you could audit something, you could look at the "network" value in
LocalControl.  That would tell you.  There are several similar problems.
The question is, how would you audit?

Proposed Solution:
There are two aspects.  How do you find out the names of terminations when
you start, and then, how do you audit to find out the values when a specific
termination does not exist yet.  This message addresses the first issue

For the former, we propose a property defined in the base root package
called
"TerminationNamePattern" This is a read only property, of type string.
The value is of the form "<pattern>,<pattern>,...,<pattern>"
Each pattern describes the form of a name for a group of terminations that
have
the same packages implemented on them.  The format of the pattern is a
string
of characters:
        a-z,A-Z,0-9, and "/" - the actual character in the name
        ?0 - any digit
        ?a - any alpha
        ?x - any hex digit
        [n,n,..,n] - alternatives, one of the alternatives listed,
                        n can be a substring of alphas or digits
        [n-n] - range, any number in the range, n can be a number or
                        an alpha, for example [00-27] or [a-e]
        Note, mixing of alternatives or ranges is allowed, as in:
                [0,3-5,8]
As an example, consider an MG that had 2 OC-3s, and an Ethernet interface.
Its TerminationNamePattern might be:
"N77G15B/[0-2]/[00-27]/[00-23],N78G22C/[0-2]/[00-27]/[00-23],R?x?x?x?x"
A simple residential gateway with an analog loop and two possible rtp
ephemerals might be
"AL,RTP1,RTP2"

Please note that in most cases, the string is a CONSTANT, or possibly
something trivially derived from a constant and provisioning data at the
MG.

In addition to the name pattern, we need the "Controlling Audit Response"
capability, which is the subject of another message.

Brian

---

From: Abdallah Rayhan <[email-masked]>
Date: Mon, 15 Nov 1999 14:13:04 -0500

Brian,

This sounds a good proposal. However, we need to tie few things to make
it easier to handle. I don't see any reason for hex, let x means alphanumeric
(digit or alpha). Furthermore, we need to agree on how to use "*". I propose
that "*" to be between "/" only and match till end of string. Also, "*" is a
trailing
wildcard, e.g., things like rtp*2 are not allowed but rtp* is. Things like
double "*"
are not allowed.

Using your example,

1- RTP1* : match one alphanumeric char
2- RTP*   : match one or two alphanumeric chars
3- RT*     : match one, two, or three alphanumeric chars
4- N77G15B/*/11/1* : return all terminations where the first * matches
"0,1,2" and 2nd * matches [0,1,2...,9].

In addition to that, ipaddress can appear at the end of the termination,
whether
wildcarded or not, but the ipaddresses can not be wildcarded. That is they are
either
fully qualified or not there.

I believe that we need to define these semantics to avoid any ambiguous
behavior
in referring to terminations and simplify processing.

Abdallah Rayhan

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Nov 1999 16:14:39 +0100

G'Day Brian,

Having thought about this alittle more I think there are a few issues:

1. The property for the structure may be very complex. Currently we are
limited to in the ABNF/ASN to 64? bytes for the length of a property.
In a complex trunking gateway this will not be enough to handle the
whole tree.
Segmentation of properties????? I don't want to go down there.

2. How is this described for the binary syntax? Binary scheme needs to
be developed.

3. Potentially this scheme has to have mechanism to describe both levels
and sets (different lengths). Must describe every path through
termination schema leading to large amount of information.

Thus I think that to do this properly then this could be one for CS2.
Names in CS1 can be pre-provisioned. The MGC can audit with these
pre-provisioned names. This is something that if we're serious about
plug and play needs to be looked at in the border scope.

This type of description doesn't sound new. It sounds like a university
research paper. Does anyone know of an existing tree description
language?

Cheers, Christian