Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08512;
9 May 95 15:23 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08508;
9 May 95 15:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14475;
9 May 95 15:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08426;
9 May 95 15:23 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08422;
9 May 95 15:20 EDT
Received: from shiva.com by CNRI.Reston.VA.US id aa14351; 9 May 95 15:20 EDT
Received: (jas@localhost) by shiva.shiva.com (8.6.9/8.6.4) id PAA10188; Tue, 9 May 1995 15:20:50 -0400
Date: Tue, 9 May 1995 15:20:50 -0400
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Shriver
Message-Id: <199505091920.PAA10188@shiva.shiva.com>
To: cbrown@wellfleet.com, charles@acc.com, fred@cisco.com
CC: iplpdn@CNRI.Reston.VA.US
Subject: comments on draft-ietf-iplpdn-frmib-dte-04.txt
The object:
frDlcmiState OBJECT-TYPE
SYNTAX INTEGER {
noLmiConfigured (1),
lmiRev1 (2),
ansiT1_617_D (3), -- ANSI T1.617 Annex D
ansiT1_617_B (4), -- ANSI T1.617 Annex B
ccitt_933_A (5) -- CCITT Q933 Annex A
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable states which Data Link Connec-
tion Management scheme is active (and by impli-
cation, what DLCI it uses) on the Frame Relay
interface."
REFERENCE
"Draft American National Standard T1.617-1991"
::= { frDlcmiEntry 2 }
Is missing one value, in my reckoning. ANSI T1.617a-1994 revises
Annex D in an incompatible way. (Thanks, ANSI! The "element
identifier" of "Link integrity verification information element" is
changed from 0x19 to 0x03.)
I'd say it should be revised to:
frDlcmiState OBJECT-TYPE
SYNTAX INTEGER {
noLmiConfigured (1),
lmiRev1 (2), -- Interim LMI Revision 1
ansiT1_617_D (3), -- ANSI T1.617-1991 Annex D
ansiT1_617_B (4), -- ANSI T1.617-1991 Annex B
ccitt_933_A (5), -- CCITT Q933 Annex A
ansiT1_617_1994_D (6) -- ANSI T1.617a-1994 Annex D
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable states which Data Link Connec-
tion Management scheme is active (and by impli-
cation, what DLCI it uses) on the Frame Relay
interface."
REFERENCE
"American National Standard T1.617-1991.
American National Standard T1.617a-1994.
ITU-T Recommendation Q.933 (03/93)."
(Note also that many of the ANSI standard references are outdated.)
(Keep me in the CC:'s, I'm not normally reading this list.)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08782;
9 May 95 15:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08778;
9 May 95 15:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14764;
9 May 95 15:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08762;
9 May 95 15:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08758;
9 May 95 15:34 EDT
Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa14750;
9 May 95 15:34 EDT
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id MAA28975; Tue, 9 May 1995 12:33:55 -0700
X-Sender: fred@stilton.cisco.com
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 9 May 1995 12:33:59 -0700
To: John Shriver
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker
Subject: Re: comments on draft-ietf-iplpdn-frmib-dte-04.txt
Cc: cbrown@wellfleet.com, carvalho@cisco.com, iplpdn@CNRI.Reston.VA.US
At 3:20 PM 5/9/95, John Shriver wrote:
>The object:
>
> frDlcmiState OBJECT-TYPE
> SYNTAX INTEGER {
> noLmiConfigured (1),
> lmiRev1 (2),
> ansiT1_617_D (3), -- ANSI T1.617 Annex D
> ansiT1_617_B (4), -- ANSI T1.617 Annex B
> ccitt_933_A (5) -- CCITT Q933 Annex A
> }
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "This variable states which Data Link Connec-
> tion Management scheme is active (and by impli-
> cation, what DLCI it uses) on the Frame Relay
> interface."
> REFERENCE
> "Draft American National Standard T1.617-1991"
> ::= { frDlcmiEntry 2 }
>
>Is missing one value, in my reckoning. ANSI T1.617a-1994 revises
>Annex D in an incompatible way. (Thanks, ANSI! The "element
>identifier" of "Link integrity verification information element" is
>changed from 0x19 to 0x03.)
What idiot did that? Did they do anything useful with the protocol (tell
you the Bc/Be/throughput values, perhaps) that would justify implementing
it?
>I'd say it should be revised to:
>
> frDlcmiState OBJECT-TYPE
> SYNTAX INTEGER {
> noLmiConfigured (1),
> lmiRev1 (2), -- Interim LMI Revision 1
> ansiT1_617_D (3), -- ANSI T1.617-1991 Annex D
> ansiT1_617_B (4), -- ANSI T1.617-1991 Annex B
> ccitt_933_A (5), -- CCITT Q933 Annex A
> ansiT1_617_1994_D (6) -- ANSI T1.617a-1994 Annex D
> }
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "This variable states which Data Link Connec-
> tion Management scheme is active (and by impli-
> cation, what DLCI it uses) on the Frame Relay
> interface."
> REFERENCE
> "American National Standard T1.617-1991.
> American National Standard T1.617a-1994.
> ITU-T Recommendation Q.933 (03/93)."
>
>(Note also that many of the ANSI standard references are outdated.)
Caralyn, Charles, your opinions? Anyone else?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
computers run on smoke, it if leaks out they won't run
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08912;
9 May 95 15:41 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08908;
9 May 95 15:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14918;
9 May 95 15:41 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08885;
9 May 95 15:41 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08881;
9 May 95 15:40 EDT
Received: from shiva.com by CNRI.Reston.VA.US id aa14899; 9 May 95 15:40 EDT
Received: (jas@localhost) by shiva.shiva.com (8.6.9/8.6.4) id PAA10785; Tue, 9 May 1995 15:40:20 -0400
Date: Tue, 9 May 1995 15:40:20 -0400
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Shriver
Message-Id: <199505091940.PAA10785@shiva.shiva.com>
To: cbrown@wellfleet.com, charles@acc.com, fred@cisco.com
CC: iplpdn@CNRI.Reston.VA.US
Subject: query on draft-ietf-iplpdn-frmib-dte-04.txt
How does one uses this draft MIB (or RFC 1315) to express things like:
1. Novell's model of each Frame Relay DLCI is one IPX network.
2. Cisco's implementation of "subinterfaces" on a Frame Relay
interface, allowing multiple IP nets for various aggregations of
DLCI's.
It looks like the MIB evolved in the old model of "one Frame Relay
interface :== one network layer interface :== one SNMP interface".
The description of:
frCircuitIfIndex OBJECT-TYPE
SYNTAX Index
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex Value of the ifEntry this virtual
circuit is layered onto."
::= { frCircuitEntry 1 }
only binds it to the underlying FR interface. It doesn't provide that
this entry may be all (or part of) an SNMP interface as seen by the
network protocols.
In either of these, the most "RFC 1573 way" would seem to be to have
one SNMP "interface" for each of these DLCI's or DLCI clusters. (Somewhat
like the way PPP runs over RS-232. Yeah, I don't enjoy that either.)
Although, RFC 1573 admits:
Several of the sub-layers for which media-specific MIB modules have
been defined are connection oriented (e.g., Frame Relay, X.25).
Experience has shown that each effort to define such a MIB module
revisits the question of whether separate conceptual rows in the
ifTable are needed for each virtual circuit. Most, if not all, of
these efforts to date have decided to have all virtual circuits
reference a single conceptual row in the ifTable.
On the other hand, RFC 1573 says:
3.2.4. Virtual Circuits
This memo strongly recommends that connection-oriented sub-layers do
not have a conceptual row in the ifTable for each virtual circuit.
This avoids the proliferation of conceptual rows, especially those
which have considerable redundant information. (Note, as a
comparison, that connection-less sub-layers do not have conceptual
rows for each remote address.) There may, however, be circumstances
under which it is appropriate for a virtual circuit of a connection-
oriented sub-layer to have its own conceptual row in the ifTable; an
example of this might be PPP over an X.25 virtual circuit. The MIB
in section 6 of this memo supports such circumstances.
If a media-specific MIB wishes to assign an entry in the ifTable to
each virtual circuit, the MIB designer must present the rationale for
this decision in the media-specific MIB's specification.
I'm opening a can of worms, aren't I? (Or did Novell open it first?)
Even RFC 1490 doesn't really talk about this issue. I did look at
back archives of the list first. Nothing there on this issue in
1994-95.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09354;
9 May 95 16:06 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09350;
9 May 95 16:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15484;
9 May 95 16:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09327;
9 May 95 16:06 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09323;
9 May 95 16:05 EDT
Received: from shiva.com by CNRI.Reston.VA.US id aa15467; 9 May 95 16:05 EDT
Received: (jas@localhost) by shiva.shiva.com (8.6.9/8.6.4) id QAA11636; Tue, 9 May 1995 16:05:36 -0400
Date: Tue, 9 May 1995 16:05:36 -0400
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Shriver
Message-Id: <199505092005.QAA11636@shiva.shiva.com>
To: fred@cisco.com
CC: cbrown@wellfleet.com, carvalho@cisco.com, iplpdn@CNRI.Reston.VA.US
In-reply-to: (fred@cisco.com)
Subject: Re: comments on draft-ietf-iplpdn-frmib-dte-04.txt
Date: Tue, 9 May 1995 12:33:59 -0700
To: John Shriver
From: fred@cisco.com (Fred Baker)
Subject: Re: comments on draft-ietf-iplpdn-frmib-dte-04.txt
Cc: cbrown@wellfleet.com, carvalho@cisco.com, iplpdn@cnri.reston.va.us
At 3:20 PM 5/9/95, John Shriver wrote:
>Is missing one value, in my reckoning. ANSI T1.617a-1994 revises
>Annex D in an incompatible way. (Thanks, ANSI! The "element
>identifier" of "Link integrity verification information element" is
>changed from 0x19 to 0x03.)
What idiot did that? Did they do anything useful with the protocol (tell
you the Bc/Be/throughput values, perhaps) that would justify implementing
it?
No idea which idiot. The 20 "idiots" of working group T1S1.2 are
listed on page vii...
There is no change in the coding of this IE. My only guess is that
someone else in another ANSI working group allocated EI 0x19 in the
ANSI codeset (shift 5 in US), so that they had to resolve the
conflict. There's no conflict in T1.607-1990, the only codeset 5 EI
there is 0x1d for "operator system access IE". However, I don't have
ANSI T1.608, which also is noted to allocate EI's in codeset 5.
I don't know why they stuck with codeset 5 here. So long as they were
changing it, they could have used the ITU-T EI of 0x93 in codeset 0.
However, there is a meaningful change in the ANSI 1994 LMI. They
added a "delete" bit in the "PVC status" IE. However, they DIDN'T
change the EI for that, it's still 0x07 (codeset 5). Maybe that's why
they changed the other EI?! Strange way to flag the change!!
(acronyms: EI :== element identifier, IE :== information element).
Far as I know, most FR switches are still provisioned for Interim LMI.
All these other ones are just a nuisance to implementors, adding no
value over Interim LMI. Still, some fool will setup a network
somewhere with the ANSI 1994 one, then it's back to the grindstone...
Remember, it could be worse, we could be writing the 50 flavors of
full ISDN call control (DSS1), with codesets 5, 6, and 7, different on
every switch vendor in every country in every operating authority!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09475;
9 May 95 16:12 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09468;
9 May 95 16:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15630;
9 May 95 16:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09429;
9 May 95 16:12 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09425;
9 May 95 16:11 EDT
Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa15612;
9 May 95 16:11 EDT
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id NAA29915; Tue, 9 May 1995 13:11:30 -0700
X-Sender: fred@stilton.cisco.com
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 9 May 1995 13:11:33 -0700
To: John Shriver
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker
Subject: Re: query on draft-ietf-iplpdn-frmib-dte-04.txt
Cc: cbrown@wellfleet.com, carvalho@cisco.com, iplpdn@CNRI.Reston.VA.US
At 3:40 PM 5/9/95, John Shriver wrote:
>How does one uses this draft MIB (or RFC 1315) to express things like:
>
>1. Novell's model of each Frame Relay DLCI is one IPX network.
You have two choices: you can associate an ifEntry with each circuit, or
you can layer the network directly on the underlying frame relay physical
interface much as you layer IP subnets on an Ethernet interface. In a
certain IPX implementation I was involved with, we did the latter, much as
one might layer several IP subnets on one interface. Both models are
allowed for in 1573, and the latter is encouraged.
Let's not confuse the network using the interface with the interface...
>2. Cisco's implementation of "subinterfaces" on a Frame Relay
>interface, allowing multiple IP nets for various aggregations of
>DLCI's.
I would suggest that you layer the subinterface on the Frame Relay
interface, and make an attribute of the subinterface be the list of
relevant DLCIs.
>It looks like the MIB evolved in the old model of "one Frame Relay
>interface :== one network layer interface :== one SNMP interface".
No, it came rather directly from the model that one frame relay interface
correlated to one physical interface, and that some number of circuits
(perhaps SVCs) were layered on that, as in X.25. We didn't want to
externalize the DLCs to the upper layers directly, as we were concerned
that they might be ephemeral.
>The description of:
>
> frCircuitIfIndex OBJECT-TYPE
> SYNTAX Index
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The ifIndex Value of the ifEntry this virtual
> circuit is layered onto."
> ::= { frCircuitEntry 1 }
>
>only binds it to the underlying FR interface. It doesn't provide that
>this entry may be all (or part of) an SNMP interface as seen by the
>network protocols.
Huh? Why can an IP subnet or whatever not be layered onto it? How do you
handle multiple IP subnets on the same physical Ethernet interface? Take as
a corollary an X.25 interface - you certainly don't want an ifIndex value
per virtual circuit, as the VC only exists during a call. You layer the
network layer object on the X.25 interface, and deal with VCs within the
X.25 packet layer.
>In either of these, the most "RFC 1573 way" would seem to be to have
>one SNMP "interface" for each of these DLCI's or DLCI clusters. (Somewhat
>like the way PPP runs over RS-232. Yeah, I don't enjoy that either.)
As I read the text you have quoted following, I would say you have it
exactly backwards. RFC 1573 "strongly recommends that connection-oriented
sub-layers do NOT have a conceptual row in the ifTable for each virtual
circuit." It mentions the assignment of ifIndex values to DLCIs as an
option, but requires that if this is done "the MIB designer must present
the rationale for this decision in the media-specific MIB's specification."
It points out that it is making this decision modelled on the use of LAN
interfaces: On an Ethernet, you don't have a network per point-to-point
relationship with LAN neighbors (you don't have an interface per
ipNetToMedia Entry) and it is unreasonable to have an interface per X.25
call open, ATM neighbor, SMDS neighbor, or Frame Relay DLC.
>Although, RFC 1573 admits:
>
> Several of the sub-layers for which media-specific MIB modules have
> been defined are connection oriented (e.g., Frame Relay, X.25).
> Experience has shown that each effort to define such a MIB module
> revisits the question of whether separate conceptual rows in the
> ifTable are needed for each virtual circuit. Most, if not all, of
> these efforts to date have decided to have all virtual circuits
> reference a single conceptual row in the ifTable.
>On the other hand, RFC 1573 says:
>
>3.2.4. Virtual Circuits
>
> This memo strongly recommends that connection-oriented sub-layers do
> not have a conceptual row in the ifTable for each virtual circuit.
> This avoids the proliferation of conceptual rows, especially those
> which have considerable redundant information. (Note, as a
> comparison, that connection-less sub-layers do not have conceptual
> rows for each remote address.) There may, however, be circumstances
> under which it is appropriate for a virtual circuit of a connection-
> oriented sub-layer to have its own conceptual row in the ifTable; an
> example of this might be PPP over an X.25 virtual circuit. The MIB
> in section 6 of this memo supports such circumstances.
> If a media-specific MIB wishes to assign an entry in the ifTable to
> each virtual circuit, the MIB designer must present the rationale for
> this decision in the media-specific MIB's specification.
>
>
>I'm opening a can of worms, aren't I?
No, you're asking a question that we thought about long and hard and came
to the place we did for a very specific set of reasons.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
computers run on smoke, it if leaks out they won't run
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10568;
9 May 95 17:17 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10564;
9 May 95 17:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16771;
9 May 95 17:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10543;
9 May 95 17:17 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10539;
9 May 95 17:17 EDT
Received: from shiva.com by CNRI.Reston.VA.US id aa16738; 9 May 95 17:17 EDT
Received: (jas@localhost) by shiva.shiva.com (8.6.9/8.6.4) id RAA13327; Tue, 9 May 1995 17:17:19 -0400
Date: Tue, 9 May 1995 17:17:19 -0400
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Shriver
Message-Id: <199505092117.RAA13327@shiva.shiva.com>
To: fred@cisco.com
CC: cbrown@wellfleet.com, carvalho@cisco.com, iplpdn@CNRI.Reston.VA.US
In-reply-to: (fred@cisco.com)
Subject: Re: query on draft-ietf-iplpdn-frmib-dte-04.txt
I suppose the primary restriction of modeling a FR interface as one
SNMP interface is that, for instance, in MIB-II you can't correlate
which IP address is assigned to a particular DLCI (or DLCI's), since
they include one ipAdEndIfIndex. (I presume the same applies to
Novell's IPX MIB, someone borrowed my NLSP standard yesterday.)
The similar restriction applies to ipRouteIfIndex. There is a loss of
information.
Now, maybe our conceptual problem (at Shiva) is that we didn't read
the description below correctly:
frCircuitIfIndex OBJECT-TYPE
SYNTAX Index
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex Value of the ifEntry this virtual
circuit is layered onto."
::= { frCircuitEntry 1 }
Does this mean that frCircuitIfIndex must be one of the values of
frDlcmiIfIndex? Or can it be a whole row in the SNMP interface table,
distinct from any value of frDlcmiIfIndex, and you figure out what
physical interface it is by the RFC 1573 ifStackTable. Perhaps that
is where we went astray reading the RFC & I-D here.
If this is the case, two examples and some text in the RFC might make
things much more obvious:
Case 1: One ifEntry per FR interface:
frDlcmiIfIndex ...
1
2
frCircuitIndex frCircuitDlci ...
1 88
1 201
1 222
2 72
2 99
(No need for ifStackTable.)
Case 2: One ifEntry per FR circuit (or circuits):
frDlcmiIfIndex ...
1
2
frCircuitIndex frCircuitDlci ...
10 88
11 201
12 222
12 223
12 224
20 72
21 99
ifStackHigherLayer ifStackLowerLayer
10 1
11 1
12 1
20 2
21 2
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04196;
10 May 95 10:37 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04192;
10 May 95 10:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07520;
10 May 95 10:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04164;
10 May 95 10:37 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04160;
10 May 95 10:35 EDT
Received: from ncnoc.ncren.net by CNRI.Reston.VA.US id aa07429;
10 May 95 10:35 EDT
Received: from chaos.wg.com by ncnoc.ncren.net (5.65/tas-ncren/may94)
id AA03340; Wed, 10 May 95 10:33:23 -0400
Received: from speedy.wg.com by wg.com (4.1/SMI-4.1)
id AA02724; Wed, 10 May 95 10:33:19 EDT
Received: from rocky.looneytunes by speedy.wg.com (4.1/SMI-4.1)
id AA25182; Wed, 10 May 95 10:33:39 EDT
Date: Wed, 10 May 95 10:33:39 EDT
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rick Cornetti
Message-Id: <9505101433.AA25182@speedy.wg.com>
To: fred@cisco.com, jas@shiva.com
Subject: Re: comments on draft-ietf-iplpdn-frmib-dte-04.txt
Cc: cbrown@wellfleet.com, carvalho@cisco.com, iplpdn@CNRI.Reston.VA.US
>
> >Is missing one value, in my reckoning. ANSI T1.617a-1994 revises
> >Annex D in an incompatible way. (Thanks, ANSI! The "element
> >identifier" of "Link integrity verification information element" is
> >changed from 0x19 to 0x03.)
>
> What idiot did that? Did they do anything useful with the protocol (tell
> you the Bc/Be/throughput values, perhaps) that would justify implementing
> it?
>
> No idea which idiot. The 20 "idiots" of working group T1S1.2 are
> listed on page vii...
>
>
> There is no change in the coding of this IE. My only guess is that
> someone else in another ANSI working group allocated EI 0x19 in the
> ANSI codeset (shift 5 in US), so that they had to resolve the
> conflict. There's no conflict in T1.607-1990, the only codeset 5 EI
> there is 0x1d for "operator system access IE". However, I don't have
> ANSI T1.608, which also is noted to allocate EI's in codeset 5.
>
> I don't know why they stuck with codeset 5 here. So long as they were
> changing it, they could have used the ITU-T EI of 0x93 in codeset 0.
>
> However, there is a meaningful change in the ANSI 1994 LMI. They
> added a "delete" bit in the "PVC status" IE. However, they DIDN'T
> change the EI for that, it's still 0x07 (codeset 5). Maybe that's why
> they changed the other EI?! Strange way to flag the change!!
>
>
> (acronyms: EI :== element identifier, IE :== information element).
>
>
> Far as I know, most FR switches are still provisioned for Interim LMI.
> All these other ones are just a nuisance to implementors, adding no
> value over Interim LMI. Still, some fool will setup a network
> somewhere with the ANSI 1994 one, then it's back to the grindstone...
>
> Remember, it could be worse, we could be writing the 50 flavors of
> full ISDN call control (DSS1), with codesets 5, 6, and 7, different on
> every switch vendor in every country in every operating authority!
>
I noted this discrepancy too. Here is the response from the frame relay list:
----- Begin Included Message -----
From owner-frame-relay@stone.ucs.indiana.edu Mon Jan 9 12:43:55 1995
Date: Mon, 9 Jan 95 09:25:00 PST
From: art@doelztc.timeplex.com (Art Biesiada)
Subject: FR: RE: Annex D LIV IE -- which is correct
To: frame-relay@stone.ucs.indiana.edu
Sender: owner-frame-relay@stone.ucs.indiana.edu
Reply-To: comp.dcom.frame-relay@indiana.edu
X-Info1: submissions to comp.dcom.frame-relay@indiana.edu
X-Info2: [Un]Subscribe requests to frame-relay-request@indiana.edu
X-Info3: example- unsubscribe frame-relay somebody@somewhere.com
X-Info4: archives (soon to be announced)
Content-Length: 697
I have a copy of ANSI T1-617a-1994, where it states on page 6:
"In D.3.2, change Link integrity verification information element identifier
from "00011001" to "00000011" ...
So the correct ID is 0x03.
Art Biesiada
Ascom Timeplex
> Author: NAME: cornetti@wg.com
>
> I have detected a discrepancy in T1.617 Annex D in the
> Link Integrity Verification IE.
>
> In T1.617 "Draft for T1 Default Ballot" (T1S1/91-352),
> the LIV IE ID (octet 1) is shown as 0x03. In the published
> ANSI T1.617-1991, Annex D, the LIV IE ID is shown as 0x19.
>
> Which is correct?
>
> Thanks in advance.
>
> Rick Cornetti
> Wandel & Goltermann, Inc.
> RTP, NC, USA, 27709
----- End Included Message -----
So it appears that there was a "typo" in ANSI T1.617-1991, Annex D and that
ANSI fixed it in the 1994 version.
Regards,
Rick Cornetti
Network Systems
Wandel & Goltermann
RTP, NC, USA
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13250;
10 May 95 18:55 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13246;
10 May 95 18:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19264;
10 May 95 18:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13222;
10 May 95 18:55 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13218;
10 May 95 18:54 EDT
Received: from lobster.wellfleet.com by CNRI.Reston.VA.US id aa19220;
10 May 95 18:54 EDT
Received: from BayNetworks.com (pobox) by lobster (4.1/SMI-4.1)
id AA15972; Wed, 10 May 95 18:53:33 EDT
Received: from godiva.wellfleet by BayNetworks.com (4.1/SMI-4.1)
id AA28167; Wed, 10 May 95 18:58:18 EDT
Date: Wed, 10 May 95 18:58:18 EDT
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Caralyn Brown
Message-Id: <9505102258.AA28167@BayNetworks.com>
Received: by godiva.wellfleet (4.1/SMI-4.1)
id AA28559; Wed, 10 May 95 18:53:21 EDT
To: Fred Baker
Cc: John Shriver , cbrown@baynetworks.com, carvalho@cisco.com,
iplpdn@CNRI.Reston.VA.US
Subject: Re: comments on draft-ietf-iplpdn-frmib-dte-04.txt
In-Reply-To:
References:
On Tue, 9 May, Fred Baker (fred@cisco.com) wrote:
> At 3:20 PM 5/9/95, John Shriver wrote:
> >The object:
> >
> > frDlcmiState OBJECT-TYPE
> > SYNTAX INTEGER {
> > noLmiConfigured (1),
> > lmiRev1 (2),
> > ansiT1_617_D (3), -- ANSI T1.617 Annex D
> > ansiT1_617_B (4), -- ANSI T1.617 Annex B
> > ccitt_933_A (5) -- CCITT Q933 Annex A
> > }
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION
> > "This variable states which Data Link Connec-
> > tion Management scheme is active (and by impli-
> > cation, what DLCI it uses) on the Frame Relay
> > interface."
> > REFERENCE
> > "Draft American National Standard T1.617-1991"
> > ::= { frDlcmiEntry 2 }
> >
> >Is missing one value, in my reckoning. ANSI T1.617a-1994 revises
> >Annex D in an incompatible way. (Thanks, ANSI! The "element
> >identifier" of "Link integrity verification information element" is
> >changed from 0x19 to 0x03.)
>
> What idiot did that? Did they do anything useful with the protocol (tell
> you the Bc/Be/throughput values, perhaps) that would justify implementing
> it?
>
> >I'd say it should be revised to:
> >
> > frDlcmiState OBJECT-TYPE
> > SYNTAX INTEGER {
> > noLmiConfigured (1),
> > lmiRev1 (2), -- Interim LMI Revision 1
> > ansiT1_617_D (3), -- ANSI T1.617-1991 Annex D
> > ansiT1_617_B (4), -- ANSI T1.617-1991 Annex B
> > ccitt_933_A (5), -- CCITT Q933 Annex A
> > ansiT1_617_1994_D (6) -- ANSI T1.617a-1994 Annex D
> > }
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION
> > "This variable states which Data Link Connec-
> > tion Management scheme is active (and by impli-
> > cation, what DLCI it uses) on the Frame Relay
> > interface."
> > REFERENCE
> > "American National Standard T1.617-1991.
> > American National Standard T1.617a-1994.
> > ITU-T Recommendation Q.933 (03/93)."
> >
> >(Note also that many of the ANSI standard references are outdated.)
>
> Caralyn, Charles, your opinions? Anyone else?
>
Looks like I fell a little behind on my email. Sorry. Anyway, I think I
agree that if ansi changed their coding, we probably need to address it in
the mib. Let's add the new type as suggested. I assume it's not too late
with the latest revision still pending.
c
--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Caralyn Brown Voice: 508-436-3835
Bay Networks Internet: cbrown@wellfleet.com
2 Federal Street
Billerica, MA 01821
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13682;
10 May 95 19:32 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13678;
10 May 95 19:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19813;
10 May 95 19:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13673;
10 May 95 19:32 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13669;
10 May 95 19:32 EDT
Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa19806;
10 May 95 19:32 EDT
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id QAA08784; Wed, 10 May 1995 16:32:13 -0700
X-Sender: fred@stilton.cisco.com
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 10 May 1995 16:32:16 -0700
To: Caralyn Brown
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker
Subject: Re: comments on draft-ietf-iplpdn-frmib-dte-04.txt
Cc: John Shriver , jhalpern@newbridge.com, carvalho@cisco.com,
iplpdn@CNRI.Reston.VA.US
At 6:58 PM 5/10/95, Caralyn Brown wrote:
>Looks like I fell a little behind on my email. Sorry. Anyway, I think I
>agree that if ansi changed their coding, we probably need to address it in
>the mib. Let's add the new type as suggested. I assume it's not too late
>with the latest revision still pending.
OK, you have the latest files; please update the MIB and post it. You can,
BTW, change Charles' address while you're at it. If all you do is
substitute his enumeration, there should be no point in syntax checking the
MIB again. You might update the references to point to the 1994 spec...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
computers run on smoke, it if leaks out they won't run