Re: [MIB-DOCTORS] draft-ietf-pwe3-pw-tc-mib-14.txt [was Preliminary agenda for the 8/14 IESG Telechat]

"Bert Wijnen \(IETF\)" <bertietf@bwijnen.net> Sat, 09 August 2008 14:01 UTC

Return-Path: <mib-doctors-bounces@ietf.org>
X-Original-To: mib-doctors-archive@optimus.ietf.org
Delivered-To: ietfarch-mib-doctors-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B35C28C0DF; Sat, 9 Aug 2008 07:01:43 -0700 (PDT)
X-Original-To: mib-doctors@core3.amsl.com
Delivered-To: mib-doctors@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2F228C0DF for <mib-doctors@core3.amsl.com>; Sat, 9 Aug 2008 07:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKbFHg8epuKI for <mib-doctors@core3.amsl.com>; Sat, 9 Aug 2008 07:01:40 -0700 (PDT)
Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 2F46028C101 for <mib-doctors@ietf.org>; Sat, 9 Aug 2008 07:01:38 -0700 (PDT)
Received: (qmail 56749 invoked from network); 9 Aug 2008 14:01:09 -0000
Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 9 Aug 2008 14:01:09 -0000
Message-ID: <49AE4F72E6BA4243A63C8B622979F3A0@BertLaptop>
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
References: <EDC652A26FB23C4EB6384A4584434A04E8E8C4@307622ANEX5.global.avaya.com> <FCE5AEA3C96943B4944F556B4B072440@BertLaptop> <EDC652A26FB23C4EB6384A4584434A04E8E8D8@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04E8E8D8@307622ANEX5.global.avaya.com>
Date: Sat, 09 Aug 2008 16:00:42 +0200
Organization: Consultant
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
x-mimeole: Produced By Microsoft MimeOLE V6.0.6001.18000
Cc: Orly Nicklass <orlyn@radvision.com>
Subject: Re: [MIB-DOCTORS] draft-ietf-pwe3-pw-tc-mib-14.txt [was Preliminary agenda for the 8/14 IESG Telechat]
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mib-doctors>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mib-doctors-bounces@ietf.org
Errors-To: mib-doctors-bounces@ietf.org

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@avaya.com>
To: "Bert Wijnen" <bwijnen@bwijnen.net>; "MIB Doctors (E-mail)" 
<mib-doctors@ietf.org>
Cc: "Orly Nicklass" <orlyn@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@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@avaya.com>
> To: <ops-dir@ietf.org>; "MIB Doctors (E-mail)"
> <mib-doctors@ietf.org>; "IETF DNS Directorate"
> <dns-dir@ietf.org>; <aaa-doctors@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@ietf.org
> > https://www.ietf.org/mailman/listinfo/mib-doctors
> >
> >
>
>
>



_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors