[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIB-DOCTORS] draft-ietf-pwe3-pw-tc-mib-14.txt [was Preliminary agenda for the 8/14 IESG Telechat]
You probably mean RFC4363 all over ....
> -----Original Message-----
> From: Bert Wijnen (IETF) [mailto:bertietf at bwijnen.net]
> Sent: Saturday, August 09, 2008 5:01 PM
> To: Romascanu, Dan (Dan); MIB Doctors (E-mail)
> Cc: Orly Nicklass
> Subject: Re: draft-ietf-pwe3-pw-tc-mib-14.txt [was
> [MIB-DOCTORS] Preliminary agenda for the 8/14 IESG Telechat]
>
> Well....
>
> > "VLAN configuration for Ethernet PW.
> > Values between 0 and 4095 indicate the actual VLAN field
> > value.
> > A value of 4096 indicates that the object refers to
> > untagged frames, i.e., frames without a 802.1Q field.
> > A value of 4097 indicates that the object is not
> > relevant."
>
>
> First of all, if I understand 802.1 well enough, then the
> values 0 and 4095 are NOT permitted in the VLAN-ID field in
> 802.1 PDUs. Not sure if they are allowed in Ethernet PW. But
> for my gut feeling, it seems better to stay in sync with real
> VLAN technology and NOT allow the values zero and 4095.
>
> Further, in the IEEE8021-TC-MIB we see in the
> IEEE8021VlanIndexOrWildcard TC that values 4096, 4097 and
> further can be used as indices and represent VLANs with local
> scope (whereas 1-2094 are of glovbal scope). So I can see
> risks that in the future these values 4096 and 4097 might
> cause trouble.
>
> If we look at RFC4364, we see TCs for VlanId, VlanIdOrAny and
> VlanIdOrAnyOrNone.
> It seems to me that the VlanIdOrAnyOrNone would be a GOOD TC
> for PWE3 to use where they make 0 to mean Untagged and 4095
> to mean object is not relevant.
> But this is just my opinion after a quick check/scan of the
> various documents.
>
> Bert
>
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <dromasca at avaya.com>
> To: "Bert Wijnen" <bwijnen at bwijnen.net>; "MIB Doctors (E-mail)"
> <mib-doctors at ietf.org>
> Cc: "Orly Nicklass" <orlyn at radvision.com>
> Sent: Saturday, August 09, 2008 10:38 AM
> Subject: RE: draft-ietf-pwe3-pw-tc-mib-14.txt [was
> [MIB-DOCTORS] Preliminary agenda for the 8/14 IESG Telechat]
>
>
> Bert,
>
> Hmmmm ... I am not crazy about it, but it may be acceptable
> as there is no exact equivalent in the Bridge or IEEE 802.1
> MIB TCs or I did not find it. Did you? The PWE3 folks use
> 4097 as a special value for 16bit VLAN range. Sure, one may
> ask what 'object is not relevant means'. And it certainly
> would be better to have all VLAN-related TCs in one place, but ...
>
> Dan
>
>
> > -----Original Message-----
> > From: Bert Wijnen [mailto:bwijnen at bwijnen.net]
> > Sent: Saturday, August 09, 2008 12:52 AM
> > To: Romascanu, Dan (Dan); MIB Doctors (E-mail)
> > Subject: draft-ietf-pwe3-pw-tc-mib-14.txt [was [MIB-DOCTORS]
> > Preliminary agenda for the 8/14 IESG Telechat]
> >
> > Dan, I only did a very very quick scan of
> > draft-ietf-pwe3-pw-tc-mib-14.txt
> >
> >
> > ANd I found this:
> >
> > PwVlanCfg ::= TEXTUAL-CONVENTION
> > DISPLAY-HINT "d"
> > STATUS current
> > DESCRIPTION
> > "VLAN configuration for Ethernet PW.
> > Values between 0 and 4095 indicate the actual VLAN field
> > value.
> > A value of 4096 indicates that the object refers to
> > untagged frames, i.e., frames without a 802.1Q field.
> > A value of 4097 indicates that the object is not
> > relevant."
> > SYNTAX Unsigned32 (0..4097)
> >
> >
> > I wonder how that co-exists/conflicts with the VLAN TCs
> that we have
> > in our BRIDGEMIB documents and those in the new 802.1ap MIB
> > modules????
> >
> > Bert
> >
> > ----- Original Message -----
> > From: "Romascanu, Dan (Dan)" <dromasca at avaya.com>
> > To: <ops-dir at ietf.org>; "MIB Doctors (E-mail)"
> > <mib-doctors at ietf.org>; "IETF DNS Directorate"
> > <dns-dir at ietf.org>; <aaa-doctors at ietf.org>
> > Sent: Friday, August 08, 2008 6:55 PM
> > Subject: [MIB-DOCTORS] Preliminary agenda for the 8/14 IESG Telechat
> >
> >
> > > Please find below the preliminary agenda of the 8/14 IESG
> telechat.
> > > Please send me your questions, concerns and comments
> until 8/13 COB
> > > the latest.
> > >
> > > Thanks and Regards,
> > >
> > > Dan
> > >
> > > 2. Protocol Actions
> > > Reviews should focus on these questions: "Is this document a
> > > reasonable basis on which to build the salient part of
> the Internet
> > > infrastructure? If not, what changes would make it so?"
> > >
> > > 2.1 WG Submissions
> > > 2.1.1
> > >
> > > - Information Model and XML Data Model for Traceroute
> Measurements
> > > (Proposed Standard) - draft-ietf-ippm-storetraceroutes-10.txt
> > > - Transport Mapping for Syslog (Proposed Standard) -
> > > draft-ietf-syslog-transport-tls-13.txt
> > > - Definitions of Textual Conventions for Pseudowires (PW)
> > Management
> > > (Proposed Standard) - draft-ietf-pwe3-pw-tc-mib-14.txt
> > > - Guidelines for Application Designers on Using Unicast
> UDP (BCP) -
> > > draft-ietf-tsvwg-udp-guidelines-09.txt
> > > - Simple Network Management Protocol (SNMP) Context
> > EngineID Discovery
> > > (Proposed Standard) -
> > draft-ietf-opsawg-snmp-engineid-discovery-03.txt
> > > - Internet Message Store Events (Proposed Standard) -
> > > draft-ietf-lemonade-msgevent-06.txt
> > >
> > > 2.1.2 Returning Item
> > >
> > > - A Two-way Active Measurement Protocol (TWAMP) (Proposed
> > Standard) -
> > > draft-ietf-ippm-twamp-09.txt
> > >
> > > 2.2 Individual Submissions
> > > 2.2.1 New Item
> > >
> > > - IANA Considerations for the IPv4 and IPv6 Router Alert Option
> > > (Proposed Standard) - draft-manner-router-alert-iana-03.txt
> > > - Extensions to the IODEF-Document Class for Reporting Phishing,
> > > Fraud, and Other Crimeware (Proposed Standard) -
> > > draft-cain-post-inch-phishingextns-05.txt
> > >
> > > 3. Document Actions
> > >
> > > 3.2 Individual Submissions Via AD
> > > Reviews should focus on these questions: "Is this document a
> > > reasonable contribution to the area of Internet engineering
> > which it
> > > covers? If not, what changes would make it so?"
> > >
> > > 3.2.1 New Item
> > >
> > > - Basic Password Exchange within the Flexible Authentication via
> > > Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
> > > (Informational)
> > > - draft-zhou-emu-fast-gtc-04.txt
> > > - Dynamic Provisioning using Flexible Authentication via Secure
> > > Tunneling Extensible Authentication Protocol (EAP-FAST)
> > > (Informational)
> > > - draft-cam-winget-eap-fast-provisioning-09.txt
> > > - Media Gateway Control Protocol Fax Package (Informational) -
> > > draft-andreasen-mgcp-fax-08.txt
> > >
> > > _______________________________________________
> > > MIB-DOCTORS mailing list
> > > MIB-DOCTORS at ietf.org
> > > https://www.ietf.org/mailman/listinfo/mib-doctors
> > >
> > >
> >
> >
> >
>
>
>
>
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS at ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors