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

From: "John Fischer" <[email-masked]>
Date: 22 Apr 2002 08:59:02 -0400

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

If the pseudo-wire represents an ethernet port, VLAN tagging MUST not
be removed.  If it is, there is no way to reconstruct the packet
flows.

If the pseudo-wire represents an ethernet VLAN, there are more
options to consider: VLAN tags removed/replaced, VLAN tags left
intact or others.

Unless tagged/untagged packets are always left as is, knowing the
pseudo-wire type is definitely important at both ends of the
pseudo-wire.
John

Matt Squire wrote:
> 
> 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
> 
> >-----Original Message-----
> >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
> >
> >
> >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"
> >=================================================================
> >
> >
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Keith Knightson <[email-masked]>
Date: Mon, 22 Apr 2002 12:21:15 -0400

>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

---

From: Giles Heron <[email-masked]>
Date: 22 Apr 2002 17:25:09 +0000

> needs further discussion.

I'm not sure that's what Matt is proposing (though I'll leave it to him
to comment...)

> be removed.  If it is, there is no way to reconstruct the packet

agreed.

> options to consider: VLAN tags removed/replaced, VLAN tags left

yes.  But these aren't really a function of the encapsulation (i.e. PWE3
scope).  They are more a function of the signalling (i.e. PPVPN scope).

In some ways I think we should have specified only one ethernet
encapsulation in draft-martini (but with two VC types in the signalling
draft - one for the single VLAN case and one for the port to port case).

> pseudo-wire type is definitely important at both ends of the

I'm not sure of your logic here?

I think you always need to know what the type is.  If packets are always
left as is, and one end is tagged and the other untagged then you need
to know that at one end there is a tag to strip and that at the other
end there is a tag to add on?

Giles

---

From: Giles Heron <[email-masked]>
Date: 22 Apr 2002 17:33:34 +0000

> at the receiving CE for proper onwards bridging?

it depends on whether the receiving PE can put the tag back in before
sending the packet to the CE.

> Conversely, under what circumstances must they be present?

in draft-martini a VLAN tag is ALWAYS carried in the "Ethernet VLAN"
mode, whilst in the "Ethernet" mode there MAY be VLAN tags (basically
whatever the CE sends to the PE will be sent to the far end PE and from
there to the far end CE.)

> and/or a single link (logical or physical) between CE and PE? Yes, No?

yes.

In draft-martini this is the "Ethernet" mode, whereas the "Ethernet
VLAN" mode ALWAYS carries a single VLAN. 

Giles

---

From: Eric Rosen <[email-masked]>
Date: Mon, 22 Apr 2002 12:47:55 -0400

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?