RE: issue in draft-martini-ethernet-encap-mpls-00.txt

"Yaron Raz" <yaron_raz@atrica.com> Thu, 25 April 2002 08:16 UTC

From: Yaron Raz <yaron_raz@atrica.com>
Subject: RE: issue in draft-martini-ethernet-encap-mpls-00.txt
Date: Thu, 25 Apr 2002 11:16:17 +0300
Lines: 54
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Class: urn:content-classes:message
Thread-Topic: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt
thread-index: AcHqGTdnyVonkzE8R3CBGvwuD0ezEACEr2lQ
To: Keith Knightson <kgk@igs.net>, John Fischer <john.fischer@alcatel.com>, pwe3@ietf.org
X-OriginalArrivalTime: 25 Apr 2002 08:16:17.0904 (UTC) FILETIME=[797F8F00:01C1EC31]
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA16525
Errors-To: pwe3-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
X-BeenThere: pwe3@ietf.org
Status: O
X-Message-ID:
Message-ID: <20140418091557.2560.6589.ARCHIVE@ietfa.amsl.com>

I agree that we should only have one PW type for carrying Eth, and this is what the standard should deal with.
The question of VLAN handling is not relevant to the PW itself, and is actually what is defined by draft-bryant-pwe3-protocol-layer-01.txt as Native Service Procesing (NSP). This NSP is not part of the PW itself, and SHOULD NOT be standardized as part of the PW.

The following explanation, is therefore just to clear the possible usage of the VLAN, and its treatment:

Eth VLAN may be used in 3 different scenarios:
1. By the customer of the SP for its "traditional" use
2. As a service selector field between the SP and his customer. this means the customer would use VLAN X for selecting one service/connection, VLAN Y for selecting another service/connection etc.
3. By the SP as a connection segregation technology over Eth. In that case, the VLAN is logically extending the PW from the PW end-point to the customer connection end-point.

Note that the two sides of the PW may not have the same scenario, for example: one side may be connected directly to a customer, while the other is connected to an Eth wire of the SP utilizing scenario 3.

When used in scenario 1, the VLAN is part of the customer data, and should be transported as is.
When used in scenario 2, the VLAN has only significance at that specific point where the customer is conected to the SP. at the ingress, once it was used to select the correct PW, it has completed its purpose and should therefore be stripped. At the egress direction OF THAT SAME POINT (not the other side of the PSN) it should be added based on the PW.
When used in scenario 3, again the VLAN is used to select the right PW, and has no meaning on the other side of the PW There may a cutomer port directly connected at the other side of the PW, or another SP VLAN. It should therefore be treated the same way as in scenario 2.

Hope this clears things rather than raise more issues,

Yaron

-----Original Message-----
From: Keith Knightson [mailto:kgk@igs.net]
Sent: Monday, April 22, 2002 7:21 PM
To: John Fischer; pwe3@ietf.org
Subject: Re: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt


At 8:59 AM -0400 4/22/02, John Fischer wrote:
>I think the proposal to always remove VLAN tags on the pseudowire
>needs further discussion.
>
Guys,

I must be missing something.

Under what circumstances can these tags be removed?  Aren't they need 
at the receiving CE for proper onwards bridging?

Conversely, under what circumstances must they be present?

I assume that several VLANs can share a single given LSP in the core 
and/or a single link (logical or physical) between CE and PE? Yes, No?

Regards

Keith


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
*************************************************
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.