[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: authors 48 hours: RFC 3318 <draft-ietf-rap-frameworkpib-09.tx t> NOW AVAILABLE

My vote on this topic is to keep it as-is in Framework PIB
(using Integer32 (-1 | 1..4094) ).
The reasoning is as follows:
1. The -1 value does not gets into the data packet being forwarded by the
network device, it is used in the management plane only.
Using the -1 value will just be as good as using 4095 from that prospective.
2. The -1 value allow it to be more distinct from the normal legal on the wire
IEEE value of 1 to 4094, hence it is cleaner to use -1.
3. The DSCP and IPv6 FlowLabel is already using the -1 or "OrAny" concepts,
hence keeping it as -1 will be more beneficial.

Thanks!
-- Kwok Ho Chan --


At 06:03 PM 2/28/03 +0100, Wijnen, Bert (Bert) wrote:
W.r.t. The VLAN ID.

I had proposed (to the bridgmib WG and mibs mailing list) a
set of TCs that would be inline with your use, as follows:

  VlanId            ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS        current
      DESCRIPTION  "A 12-bit VLAN ID used in the VLAN Tag header."
      SYNTAX        Integer32 (1..4094)
      REFERENCE    "Draft Standard for Virtual Bridged Local Area
                    Networks, P802.1Q/D10, chapter 3.13
                   "

  VlanIdOrAny       ::= TEXTUAL CONVENTION
      DISPLAY-HINT "d"
      STATUS        current
      DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN.
                    The value of -1 is used to indicate a wildcard,
                    i.e. any value.
                   "
      SYNTAX        Integer32 (-1 | 1..4094)


The latter one, would have been inline with your use in

  frwk802FilterVlanId OBJECT-TYPE
      SYNTAX         Integer32 (-1 | 1..4094)
      STATUS         current
      DESCRIPTION
          "The VLAN ID (VID) that uniquely identifies a VLAN
          within the device. This VLAN may be known or unknown
          (i.e., traffic associated with this VID has not yet
          been seen by the device) at the time this entry
          is instantiated.

          Setting the frwk802FilterVlanId object to -1 indicates that
          VLAN data should not be considered during traffic
          classification."
      ::= { frwk802FilterEntry 5 }

But afte someone objected to a negative value for 'any, and
based on Andrew's input I believe, people are now discussing

  VlanIdOrAny       ::= TEXTUAL CONVENTION
      DISPLAY-HINT "d"
      STATUS        current
      DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN.
                    The value of 4095 is not a vlaid VLAN ID and
                    is used to indicate a wildcard, i.e. any value.
                   "
      SYNTAX        INTEGER (1..4095)

That would be conflicting with your definition, and I might later
ask you to deprecate your object and define a new one that
aligns with the generic VLAN ID as defined by the bridgemib WG.
Unfortunately, they are not sure yet, Bridgemib WG chair is
taking it to IEEE and they will discuss it in week of March 9th,
So it will take a while before we know for sure.

So I am inclined to let you go with what you have, or to redefine
it as       SYNTAX        INTEGER (1..4095).
In the latter case, pls again do a quick pseudo WG Last Call
for the change.


Please let me know how you want to proceeed.
Bert