Re: comments on draft-ietf-iplpdn-frmib-dte-04.txt

John Shriver <jas@shiva.com> Tue, 09 May 1995 20:06 UTC

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, 09 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 <jas@shiva.com>
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: <v02120c12abd573106e49@[171.69.128.114]> (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 <jas@shiva.com>
   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!