[PWE3] once upon an erratum
Yaakov Stein <yaakov_s@rad.com> Tue, 08 May 2012 10:59 UTC
Return-Path: <yaakov_s@rad.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7718221F84A1 for <pwe3@ietfa.amsl.com>; Tue, 8 May 2012 03:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.47
X-Spam-Level:
X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1N11I1Ji2qQ for <pwe3@ietfa.amsl.com>; Tue, 8 May 2012 03:59:39 -0700 (PDT)
Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7A921F8491 for <pwe3@ietf.org>; Tue, 8 May 2012 03:59:38 -0700 (PDT)
Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 8 May 2012 13:40:49 +0300
Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Tue, 8 May 2012 13:59:25 +0300
From: Yaakov Stein <yaakov_s@rad.com>
To: Stewart Bryant <stbryant@cisco.com>, "pwe3@ietf.org" <pwe3@ietf.org>
Thread-Topic: once upon an erratum
Thread-Index: Ac0tCaGewFO+Y9uSQqeRIjYDpnZDmw==
Date: Tue, 08 May 2012 10:59:25 +0000
Message-ID: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.17.140.53]
Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9043C64FBEXRAD5adradcoil_"
MIME-Version: 1.0
X-Commtouch-Refid: str=0001.0A020201.4FA8FC8E.006C,ss=1,fgs=0
Subject: [PWE3] once upon an erratum
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 May 2012 10:59:40 -0000
Stewart and all, RFC 4448 has an erratum marked "Held for Document Update by Stewart Bryant". This erratum (penned by Alfred Hoenes) deals with several issues, from a "subtle typo" to the misleading figure label. However, there is one issue with which I agree and which I think is important; but regarding which I don't recall discussion on the list. With the entire group of comments marked as "held for document update" rather than as "approved", I am not sure whether this issue has been agreed upon. The text in question is this : When the PE receives an Ethernet frame, and the frame has a VLAN tag, we can distinguish two cases: 1. The tag is service-delimiting. This means that the tag was placed on the frame by some piece of service provider-operated equipment, and the tag is used by the service provider to distinguish the traffic. For example, LANs from different customers might be attached to the same service provider switch, which applies VLAN tags to distinguish one customer's traffic from another's, and then forwards the frames to the PE. 2. The tag is not service-delimiting. This means that the tag was placed in the frame by a piece of customer equipment, and is not meaningful to the PE. Alfred states that The term, "service delimiting", apparently here is defined by the origin of the tag, not by its function. I understand where the original text comes from. In the provider provisioned model the SP doesn't trust the customer to properly tag the frames, and so doesn't look at tags inserted by CE devices. However, other groups (e.g., MEF) assume careful prior negotiation (of the legal kind, not the protocol kind) between customer and SP, and so the C-tag may indeed be service delimiting. More specifically, one can make the distinction between three "bundling" types based on the C-tag. *All-to-one means that all C-tags are taken as one "flow" or "EVC" or whatever, and thus the mapping to PW is independent of this tag. So here the C-tag is NOT service delimiting. *One-to-one means that each C-tag is mapped to a single EVC. So the C-tag determines the PW, and is thus service delimiting. *Arbitrary bundling means we have a general mapping of C-tags to EVCs (and so includes the previous two). In general the C-tag here too is service delimiting. (NOTE: the arbitrary and One-to-one cases are lumped together in MEF as the "bundling" case.) Do you agree with this analysis, and thus with the need to remove the caveat in 4448 that states that C-tags can not be service delimiting ? Y(J)S
- [PWE3] once upon an erratum Yaakov Stein
- Re: [PWE3] once upon an erratum Alexander Vainshtein
- Re: [PWE3] once upon an erratum Stewart Bryant
- Re: [PWE3] once upon an erratum Alexander Vainshtein
- Re: [PWE3] once upon an erratum Yaakov Stein
- Re: [PWE3] once upon an erratum Alexander Vainshtein
- Re: [PWE3] once upon an erratum Yaakov Stein
- Re: [PWE3] once upon an erratum Yaakov Stein
- Re: [PWE3] once upon an erratum Alexander Vainshtein
- Re: [PWE3] once upon an erratum Stewart Bryant
- Re: [PWE3] once upon an erratum Raymond Key