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

From: Giles Heron <[email-masked]>
Date: 18 Apr 2002 18:02:43 +0000

On Thu, 2002-04-18 at 16:51, Claude Kawa wrote:
> Why can't we include in the draft explanations similar  to those in Eric's
> email so that the readers and implementators are aware of the different
> possibilities. I did not try to be exhaustive in my email. 

I'm not against giving examples - as long as they don't give the
impression that this is specifying a list of options.
 
> One important thing to include is about the VLAN ID exchanged between a CE
> and PE, is it a local identifier, is it sent to the PE-CE,  is it used
> behind the CE in the customer network. This information will help a lot.  

that depends (and is again a purely an issue between the SP and the
customer).

Where I have customers connecting to my network with a router the VLAN
ID is purely a local identifier.

But where I have customers connecting to my network with an Ethernet
switch the VLAN ID is used in the customer network.

Giles

> claude
> 
> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 10:27 AM
> To: Kawa, Claude [CAR:CS49:EXCH]
> Cc: [email-masked]
> Subject: Re: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt 
> 
> 
> 
> Claude> If CE1 and CE2 are  not bridges/switches (e.g. if they are routers),
> Claude> they terminate the (bridged) LANs and the VLAN id used behind CE1 or
> Claude> CE2 do not have to be propagated from one CE to the other.
> 
> Claude> Therefore  between a  CE  and  PE we  can  use VLAN  id  as a  local
> Claude> identifier.
> 
> Okay so far. 
> 
> Note that as the VLAN id in this case is a local identifier, its function is
> subject to agreement between the customer and the service provider. 
> 
> Claude> A PE will use  the VLAN id carried in the frames  it received from a
> Claude> CE to select  the correct PE-PE LSP for  shipping Ethernet/PW frames
> Claude> to the other PE-CE pair. 
> 
> Not necessarily.   If a VPLS service is  being offered, the VLAN  id will be
> used to select  a particular VPN's forwarding table;  the correct pseudowire
> will then be selected by looking up the frame's DA in the forwarding table. 
> 
> If Internet access  is also being provided, then a  particular VLAN id value
> might be interpreted  by the PE as meaning "extract the  IP packet from this
> frame and forward it according to the Internet routing table".  
> 
> If L3VPN  service is also  being provided, then  a particular VLAN  id value
> might be interpreted by the PE  as meaninng "extract the IP packet form this
> frame and forward it according to a particular VRF". 
> 
> Claude> We cannot say this is an issue between the customer and provider and
> Claude> not subject to standardization.  
> 
> I don't see how we can say anything else. 
> 
> Claude> Different vendors may do different things. 
> 
> I don't quite understand.   For a device to be useful as  a CE device it may
> need to allow itself to be configured so that different VLAN ids are used to
> represent different services.  What else needs to be said? 
> 
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 18 Apr 2002 15:13:14 -0400

I just want to second the sanity of Giles and Eric on this whole thread (so I guess I'm at least third'ing it).  

There are not multiple types of Ethernet, there is one.  There is no need for multiple types of Ethernet pseudowire.  Whether a wire or pseudowire carries tagged or untagged packets is a matter of configuration, not a matter of protocol.  

Can people screw this up?  Certainly.  They can screw it up on an physical Ethernet link as or more easily than they can over a pseudo-Ethernet link.  Get over it.  

VLANs, in general, have existed for many years before VLAN tagging.  We defined VLANs based on ports, MAC addresses, protocols, IP subnets, etc.  How these are defined and how they get mapped to a wire or pseudowire is an issue for configuration above the wire, and shouldn't come into play for anything in PWE3.

- Matt

>From: Giles Heron [mailto:[email-masked]]
>Sent: Thursday, April 18, 2002 2:03 PM
>To: Claude Kawa
>Cc: [email-masked]
>Subject: RE: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt
>
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 22 Apr 2002 12:51:14 -0400

>
>I think the proposal to always remove VLAN tags on the pseudowire
>needs further discussion.
>

Noone ever said always remove VLAN tags.  

My position was that an Ethernet pseudowire is like an Ethernet wire.  Whether the wire carries tagged or untagged packets (or both) is a matter of configuration above the wire itself.  The wire doesn't care and shouldn't know.  Its a problem outside the scope of PWs.  

VLAN tags can be used on a PW just like they can be used on a Ethernet link.  No more, no less.  

- Matt

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 22 Apr 2002 20:22:02 +0200

Eric,
I agree with your interpretation of the proposal.
I also think that it is the right thing to do: PEs can add/remove
VLAN tags as needed, and the PW should not be aware of
this functionality. I do not see any use case for two separate
PW types.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> Sent: Monday, April 22, 2002 6:48 PM
> To: John Fischer
> Cc: [email-masked]
> John> I  think the proposal  to always  remove VLAN  tags on  
> the pseudowire
> John> needs further discussion.  
> 
> I didn't think that  was the proposal.  I think the proposal  
> is to have one
> type of ethernet  pseudowire, on which the "customer  frame" 
> is carried.  It
> is the responsibility of the ingress PE to extract the 
> "customer frame" from
> what it received on the wire.  The customer frame may or may 
> not have a VLAN
> tag.  If it does, the VLAN tag is passed through.
> 
> Each PE must know what it has to  do to extract a customer 
> frame from (or to
> send a  customer frame to) a  given interface.  But  as long 
> as the  PW only
> carries the customer  frame, I don't see that either  
> endpoint needs to know
> what the  other endpoint is going  to do.  If  that is 
> correct, there  is no
> need for signaling to carry such information. 
> 
> John> If the pseudo-wire represents an  ethernet port, VLAN 
> tagging MUST not
> John> be removed. 
> 
> Correct,  because in  the "ethernet  port" case,  all frames  
> are considered
> customer frames to be passed transparently. 
> 
> John> Unless  tagged/untagged packets  are always  left as  
> is,  knowing the
> John> pseudo-wire  type  is  definitely   important  at  both 
>  ends  of  the
> John> pseudo-wire. 
> 
> Not  quite.  On  a  given ethernet  port, the  SP  might be  
> using VLANs  to
> distinguish different customers.   The VLAN tag which is  
> meaningful only to
> the SP, and not to the customer  can be stripped off.  At the 
> other end, the
> SP may  or may not  be using VLANs  to distinguish different  
> customers, but
> that is a local matter which need not be visible to the other end. 
> 
> At least that is my understanding.  Is this wrong? 
> 
> 
> 
>

---

From: "Yaron Raz" <[email-masked]>
Date: Thu, 25 Apr 2002 11:16:17 +0300

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:[email-masked]]
Sent: Monday, April 22, 2002 7:21 PM
To: John Fischer; [email-masked]
Subject: Re: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt

>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
[email-masked]
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.