Subject: RE: [Policy] Re: IP Protocol value range

From: "Robert Moore" <[email-masked]>
Date: Thu, 7 Feb 2002 10:28:24 -0500

Somehow I seem to be the only person here without a copy of the relevant
802.2 spec.  So I have no way of deciding between Ron's OID proposal and
Joel's OUI one.  I agree with Mircea that the most important thing here is
to state, very clearly and unambiguously, the contents of each of our
variable classes.  I'm just not in a position to do that myself.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

                      "Ron Cohen"                                                                          
                      <[email-masked]>         To:       "'Joel M. Halpern'" <[email-masked]>,      
                                                Robert Moore/Raleigh/IBM@IBMUS                             
                      02/06/02 05:37 AM        cc:       <[email-masked]>, "'Mircea Pana'"             
                                                <[email-masked]>, "'IETF Policy'" <policy@ietf.  
                                                org>, <[email-masked]>                              
                                               Subject:  RE: [Policy] Re: IP Protocol value range          

I agree. I think that we should add an OID variable as well. I think
that this would answer the remarks by Mircea as well as the
input/solution proposed by Andrew. I'm assuming that we don't need to
support the 40 bit OIU (see Andrew's email).

How about the following definition:

NAME PolicySNAPOIDVariable
DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP)
field for 802.2 SNAP encapsulation.
The value 00-00-00 indicates the standard SNAP encapsulation (RFC 1042).
OID value 00-00-F8 indicates the bridged ethertype (IEEE
802.1H)

ALLOWED VALUE TYPES:
 - PolicyBitStringValue (24 bit)

DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)

Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Joel M. Halpern
> Sent: Tuesday, February 05, 2002 10:52 PM
> To: Robert Moore; Ron Cohen
> Cc: [email-masked]; 'Mircea Pana'; 'IETF Policy';
> [email-masked]
> Subject: RE: [Policy] Re: IP Protocol value range
>
>
> If we are going to do that, we should add a PolicySNAPOIDVariable as
> well.  If you are looking at SNAP/SAP encapsulated
> information, you must
> check the OID for 0 before you can treat the last two bytes
> as an etherType.
> Yours,
> Joel M. Halpern
>
> At 12:56 PM 2/5/02 -0500, Robert Moore wrote:
> >Let me propose an update to the PCIMe text. If this isn't
> exactly right,
> >it should at least be specific enough for people to comment on.
> >It's a complete replacement for section 5.12.19:
> >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the
> Sub-Network Access
> >Protocol                     (SNAP) Type field for 802.2
> SNAP encapsulation.
> >
> >ALLOWED VALUE TYPES:  - PolicyIntegerValue (0..65535)  -
> >PolicyBitStringValue (16 bit)
> >
> >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE  PROPERTIES(none)
> >
> >
> >Regards,
> >Bob
> >
> >Bob Moore
> >Advanced Design and Technology
> >Application Integration Middleware Division
> >IBM Software Group
> >+1-919-254-4436
> >[email-masked]
> >
> >d821c.jpg"Ron Cohen" <[email-masked]>
> >
> >
> >d8356.jpg
> >d836d.jpg
> >"Ron Cohen" <[email-masked]>
> >
> >02/05/02 06:54 AM
> >
> >d8380.jpg
> >
> >To:"'Mircea Pana'" <[email-masked]>, Robert
> Moore/Raleigh/IBM@IBMUS
> >cc:<[email-masked]>, "'IETF Policy'" <[email-masked]>,
> ><[email-masked]>
> >Subject:RE: [Policy] Re: IP Protocol value range
> >
> >
> >Mircea, Bob
> >
> >
> >PCIMe defines:
> >
> >PolicySNAPVariable: The protocol number over a Sub-Network Access
> >Protocol (SNAP) SAP encapsulation.
> >
> >Explanation:
> >
> >IEEE 802.2 defines two encapsulations, following the Ethernet length
> >field:
> >
> >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are
> represented
> >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable.
> >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes,
> >where the last two bytes are called the SNAP type. This is the
> >equivalent of the Ethernet Type. The intention was that the
> >PolicySNAPVariable would represent this two byte SNAP type field.
> >
> >I suggest that we rename this variable to PolicySNAPTypeVriable and
> >remove the current ambiguity.
> >
> >
> >Ron
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Mircea Pana
> > > Sent: Monday, February 04, 2002 5:36 PM
> > > To: Robert Moore
> > > Cc: [email-masked]; IETF Policy; [email-masked]
> > > Subject: Re: [Policy] Re: IP Protocol value range
> > >
> > >
> > > ...and just to add to my confusion, RFC1042 defines the
> *same* SNAP
> > > header as
> > > "an extension of the LLC header called the Sub-Network
> Access Protocol
> > > (SNAP)" :-0
> > >
> > > So, a reference to the actual definitions (RFC, IEEE
> etc.) may help if
> > > added in PCIMe. IMO, it is less important what exactly
> this (or other)
> > > PolicyVariable represents, more important is to define it
> > > unambiguously.
> > >
> > > Regards,
> > > Mircea.
> > >
> > >
> > > Robert Moore wrote:
> > > >
> > > > >SNAP actually stands for "IEEE 802.1a SubNetwork
> Attachment Point".
> > > > See
> > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for
> > > > Routed
> > > > >Protocols" for example. The SNAP header includes two
> fields: OUI (3
> > > > >octets) and PID (2 octets).
> > > > >
> > > > >I have two comments here:
> > > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access
> > > > >Protocol".
> > > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to
> > > > represent
> > > > >only the PID part of the SNAP header (2 octets)? Or should
> > > it reflect
> > > > >the entire header: OUI+PID (5 octets).
> > > >
> > > > To be honest, I don't know what we meant to refer to with
> > > > PolicySNAPVariable. (I think this class came from Cisco - in
> > > > any case, I know it didn't come from IBM.) Some possibilities:
> > > >
> > > > Currently in PCIMe: Sub-Network Access Protocol.
> > > >
> > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point.
> > > >
> > > > On acronymfinder.com: Subnetwork Access Protocol,
> > > > Standard Network Access Protocol (in bold, for some
> > > > reason), Small Network Access Package, and a bunch
> > > > of other options that are plainly not what we're
> > > > talking about.
> > > >
> > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell
> > > > us what we meant when we defined PolicySNAPVariable.
> > > > And maybe they'll even agree! :-)
> > > >
> > > > Regards,
> > > > Bob
> > > >
> > > > Bob Moore
> > > > Advanced Design and Technology
> > > > Application Integration Middleware Division
> > > > IBM Software Group
> > > > +1-919-254-4436
> > > > [email-masked]
> > >
> > > _______________________________________________
> > > Policy mailing list
> > > [email-masked]
> > >
> >
> <https://www1.ietf.org/mailman/listinfo/policy>https://www1.ie
tf.org/mailm
> an/listinfo/policy

---

From: "Andrew Smith" <[email-masked]>
Date: Thu, 7 Feb 2002 10:09:25 -0800

Bob,

How about this for the Type variable:

"NAME PolicySNAPTypeVariable
DESCRIPTION The value of the 4th and 5th octets of the Sub-Network Access
Protocol (SNAP) Protocol Identifier field for IEEE 802 SNAP encapsulation
when the PolicySNAPOUIVariable
indicates one of the two Encapsulated Ethernet frame formats. This value is
undefined for other values of PolicySNAPOUIVariable.

ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535)

PROPERTIES (none)"

Does this "language" have REFERENCE clauses? That would be a good place to
put the appropriate RFCs and IEEE documents.

I'm still a bit unclear on Ron's proposal: if we don't allow the OUI to be
other than 00-00-00 or 00-00-F8 then shouldn't there be some type of
enumerated list of these "allowed values"? Or is this language not that
formal? Otherwise we have to add something like "Other values of OUI are not
supported".

And one other wrinkle is that people who live in what is often known as
"IBM-endian" land might interprete 00-00-F8 in a different way to those
hailing from "Ethernet-land" (I can't remember which is "Big-" and which is
"Little-" endian - people tend to call them "Ethernet order" and "Token-Ring
order"). The official IEEE chapter and verse on this is (from the the book
of "IEEE 802 Overview and Architecture"):

"3.8 Hexadecimal Representation: The representation of a sequence of octet
values in which the values of the individual octets are displayed in order
from left to right with each octet value represented as a two-digit
hexadecimal numeral, and with the resulting pairs of hexadecimal digits
separated by hyphens. The order of the hexadecimal digits in each pair, and
the mapping between the hexadecimal digits and the bits of the octet value,
are derived by interpreting the bits of the octet value as a binary numeral
using the normal mathemat-ical rules for digit significance."

as opposed to

"3.2 bit-reversed representation: The representation of a sequence of octet
values in which the values of the individual octets are displayed in order
from left to right with each octet value represented as a two-digit
hexadecimal numeral, and with the resulting pairs of hexadecimal digits
separated by colons. The order of the hexadecimal digits in each pair, and
the mapping between the hexadecimal digits and the bits of the octet value,
are derived by reversing the order of the bits in the octet value and
interpreting the resulting bit sequence as a binary numeral using the normal
mathematical rules for digit significance.
NOTE- The bit-reversed representation is applicable to LAN MAC addresses for
use in a Token Ring (IEEE 802.5) or FDDI environment. See Figure 8 for a
comparative example of Bit-reversed and Hexadecimal Representation.

In other words, 00-00-F8 is supposed to unequivocably mean "Ethernet order"
as opposed to 00:00:EF which means the same thing in Token-Ring land. Not a
lot of people know that. But if we write things like 00-00-F8 in the Policy
document, we've got to reference this convention. So how about the following
revision of Ron's proposal for the OUI variable:

"NAME PolicySNAPOUIVariable
DESCRIPTION The value of the first three octets of the Sub-Network Access
Protocol (SNAP)
Protocol Identifier field for 802.2 SNAP encapsulation, containing an
O.U.I..
The value 00-00-00 indicates the encapsulation of Ethernet frames (RFC
1042).
OID value 00-00-F8 indicates the special encapsulation of Ethernet frames by
certain types of bridge (IEEE 802.1H). Other values are not supported. These
O.U.I. values are to be interpreted according to the endian-notation
conventions of IEEE 802. For either of these encapsulations, the remainder
of the Protocol Identified field is indicated by PolicySNAPTypeVariable.

ALLOWED VALUE TYPES:
- PolicyBitStringValue (24 bit) ***

PROPERTIES (none)"

Note ***: is there such thing as a "PolicyOctetStringValue (3 octet)" type?
Using BitString leads to additional interpretation problems unless it is
clearly defined somewhere else what endian order is implied.

I'd suggest that the OUI variable precede the Type one in the document.
That's my 2 cents - take this message as an I.O.U. :-)

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Robert Moore
Sent: Thursday, February 07, 2002 7:28 AM
To: Ron Cohen
Cc: [email-masked]; 'Joel M. Halpern'; 'Mircea Pana'; 'IETF Policy';
[email-masked]
Subject: RE: [Policy] Re: IP Protocol value range

Somehow I seem to be the only person here without a copy of the relevant
802.2 spec. So I have no way of deciding between Ron's OID proposal and
Joel's OUI one. I agree with Mircea that the most important thing here is to
state, very clearly and unambiguously, the contents of each of our variable
classes. I'm just not in a position to do that myself.

Regards,
Bob

Bob Moore

02/06/02 05:37 AM

To: "'Joel M. Halpern'" <[email-masked]>, Robert
Moore/Raleigh/IBM@IBMUS
cc: <[email-masked]>, "'Mircea Pana'" <[email-masked]>, "'IETF
Policy'" <[email-masked]>, <[email-masked]>
Subject: RE: [Policy] Re: IP Protocol value range

ALLOWED VALUE TYPES:

Ron

tf.org/mailm

_______________________________________________
Policy mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/policy