[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Randy, you wrote:
>cc: email@example.com (Les Bell/GB/3Com)
>Subject: Re: [Bridge-mib] VLAN-ID
>I think it would be better if the "any" value in the *OrAny TC were
>a non-negative value so that the type could be used to define an
>index. There may not be a need today, but thinking ahead to
>representing policy-like things wouldn't hurt.
As far as I can tell, you seem to be the only one sofar who
has spoken up on the idea of not having a negative value
for the "any" for the VlanIdOrAny TC that I proposed.
You do not claim an immediate need, but a possible future
So if there are any other people who feel that this makes sense,
please speak up soon.
We already have (rfc3289)
DscpOrAny ::= TEXTUAL-CONVENTION
"The IP header Differentiated Services Code-Point that may be
used for discriminating among traffic streams. The value -1 is
used to indicate a wild card i.e. any value."
"RFC 2474, RFC 2780"
SYNTAX Integer32 (-1 | 0..63)
Based on that, we also got to (draft-ietf-ops-ipv6-flowlabel-00.txt)
IPv6FlowLabelOrAny ::= TEXTUAL-CONVENTION
DESCRIPTION "The flow identifier or Flow Label in an IPv6
packet header that may be used to discriminate
traffic flows. The value of -1 is used to
indicate a wildcard, i.e. any value.
SYNTAX Integer32 (-1 | 0..1048575)
And so now we were going down the same path
VlanIdOrAny ::= TEXTUAL CONVENTION
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)
So that seems consistent, no?
If we do so, we can bypass that discussion about if it is valid
to use value 4095 to mean "any"... I suspect that discussion may
take a while and we may need to check with IEEE 802 people/docs.
Or are you telling us we better change all of the above to
use a positive number for "any".