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

From: "Ron Cohen" <[email-masked]>
Date: Tue, 5 Feb 2002 13:54:33 +0200

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
> 

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

---

From: "Andrew Smith" <[email-masked]>
Date: Tue, 5 Feb 2002 10:30:00 -0800

Ron,

But Mircea's original point was that that this definition for
PolicySNAPVariable does not include the 24-bit/3-octet O.U.I. field. I think
you are assuming that the only interesting O.U.I. is 00-00-00 which is the
one specified by IEEE 802 Overview and Architecture (the doc that I
referenced before - this was first defined in RFC 1042 but that is
superceded by IEEE 802, at least that's what IEEE says) for encoding an
Ethertype over IEEE 802.2 LLC layers. If that is the intent then the
description should say something about the 00-00-00 being implicit. BTW,
this encaps is often called "SNAP RFC 1042".

But you might also want to include that other pesky encapsulation (from IEEE
802.1H) which uses O.U.I. 00-00-F8 for carrying a "Bridged Ethertype" (this
isn't the place to go into the usage scenarios for this encaps - see 802.1H
for that) which does occur still. This encaps is often called "SNAP 802.1H".

And then there's the full SNAP 40-bit/5-octet usage but I think that's
probably not worth including (does anyone here still use private SNAP
protocols? I think perhaps some of the big vendors are still shipping stuff
encapsulated that way - we got a lot of pressure, even 2 years ago when
doing IEEE 802.1v-2001, to include this encapsulation).

Suggestion: names like Policy1042EthertypeVariable,
Policy8021hEthertypeVariable and PolicySNAPPidVariable might be more
descriptive.

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Ron Cohen
Sent: Tuesday, February 05, 2002 3:55 AM
To: 'Mircea Pana'; 'Robert Moore'
Cc: [email-masked]; 'IETF Policy'; [email-masked]
Subject: RE: [Policy] Re: IP Protocol value range

Mircea, Bob

PCIMe defines:

Explanation:

Ron