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

From: Maarten Vissers <[email-masked]>
Date: Thu, 18 Apr 2002 10:52:39 +0200

Claude,

Let me add another case to the ones described by you so far (one that will be
addressed also in next weeks MEF meeting):

         customer network 1 
                |
               CE1
                |
              sdhPE1
                |
     Ethernet over SDH/SONET A
                |
              sdhPE2
                |
             mplsPE1
                |
	Ethernet over MPLS ---- mplsPE3 --- CE3 --- customer network 3
                |
             mplsPE2
                |
              sdhPE3
                |
     Ethernet over SDH/SONET B
                |
              sdhPE4
                |
               CE2
                |
          customer network 2

The EoS networks can be considered as ethernet access networks and the EoMPLS
network is then operating as the ethernet core network, interconnecting multiple
EoS networks.

In the Ethernet over SDH/SONET (EoS) networks, VLAN technology is used to create
ethernet VPNs. The (in sdhPE1) incoming MAC frame (with/without customer owned
VLAN tag) is extended with (a second) VLAN tag of which the VLAN ID identifies
the customer within the EoS network (i.e. it is a VPN ID). Assume there is a 1:1
relation between customer and port; the VLAN ID is now assigned on a per port
basis to all incoming MAC frames.

As the EoS A network will connect many customers, the sdhPE2 to mplsPE1
interface will most efficiently be an aggregate interface (traffic of multiple
customers is carried over it). The VLAN IDs added in the ingress sdhPE network
elements will be carried over the sdhPE2 to mplsPE1 interface and will have to
be translated into MPLS VC labels in the mplsPE1 network element. 

At the MPLS network's egress node (mplsPE2) the MPLS VC label must be translated
into a VLAN ID (applicable within the EoS B network; may differ from VLAN ID in
EoS A network) to allow forwarding of the MAC frame through the EoS B network
towards the customer network 2. This VLAN ID is removed in the sdhPE4 egress
port and the original MAC frame (possibly including a customer owned VLAN tag)
is handed of to the CE2.

In addition, the user priority (UP) bits in the in EoS A network added VLAN tag
should be forwarded to the EoS B network (i.e. from mplsPE1 to mplsPE2) via the
EXP bits in the MPLS VC label (possibly including translation).

In this application, the incoming ethernet interface in to the MPLS network is
an aggregate interface and the mplsPE1 node must forward MAC frames on a per
VLAN basis.
If you would connect customer network 3 via CE3 to mplsPE3 in a 1:1 relation,
you will be able to forward the incoming MAC frames on a per port basis.
In all cases, the PE ports (and any intermediate ethernet nodes in e.g. the EoS
networks) should  perform MAC learning and base their forwarding on this
information as well (especially important in multi-point connections).

Triggered by the Vach's email, I re-read the martini-ethernet draft once more
and noticed that this mode (agregation interface) in which you terminate one
level of VLAN and forward the UP information is not described. As there is the
need to support VLAN ID translation and UP bits forwarding we may have to add an
additional section 4.3 describing interworking between EoS and EoMPLS networks.
Or, as suggested by Eric, it might be more appropriate to add such interworking
section in the L2VPN document. I.e. the encapsulation described in the martini
draft doesn't change when EoS - EoMPLS interworking is taking place.

Regards,

Maarten

> Claude Kawa wrote:
> 
> I am not sure I understood Vach proposal entirely. There are various VLAN id
> in a PWE3 environment. We need to clarify a couple of things about VLAN and
> VID first:
> 
> According to 802.1Q, VLAN id have a significance within one bridged LAN. In
> the case of PWE3 architecture, where the bridged LAN terminates?
> 
> With PWE3 architecture we can have:
> 
> customer network 1 (e.g.
> LAN1)----CE1---PE1-------PSN-------PE2---CE2----customer network 2
> 
> With this architecture we can have the following LANs:
> 
> 1-One bridged LAN behind CE1
> 2-Another bridged LAN behind CE2
> 3-A LAN between CE1-PE1
> 4-A LAN between CE2-PE2
> 
> If CE1 and CE2 are not bridges/switches (e.g. if they are routers), they
> terminate the (bridged) LANs and the VLAN id used behind CE1 or CE2 do not
> have to be propagated from one CE to the other.
> 
> Therefore between a CE and PE we can use VLAN id as a local identifier. A PE
> will use the VLAN id carried in the frames it received from a CE to select the
> correct PE-PE LSP for shipping Ethernet/PW frames to the other PE-CE pair.
> This use of VLAN id is not specified in any standard to my knowledge and the
> behavior of routers with regard to VLAN ID reception and transmission is not
> specified anywhere too.
> 
> However if CE1 and CE2 are considered to be bridges/switches and the
> PE1-PSN-PE2 is used for remote bridging, the VLAN id used behind the CEs have
> to be propagated from one LAN to the other. What does a PE use in this case to
> select the LSP? VLAN ID used in the customer networks?
> 
> It is important to understand and solve this complicated issue so that CEs and
> PEs behave correctly. We cannot say this is an issue between the customer and
> provider and not subject to standardization. Different vendors may do
> different things. We need to provide at least minimum information addressing
> this issue in ethernet/PWE3 draft.
> 
> Claude Kawa
> 
> -----Original Message-----
> From: Vach Kompella [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 2:15 PM
> To: [email-masked]; Kawa, Claude [CAR:CS49:EXCH]
> Cc: [email-masked]
> Subject: RE: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt
> 
> I kind of agree with Eric.  However, the martini draft does not allow this
> flexibility.  Otherwise there would be no need to define a VLAN-aware and a
> VLAN-unaware encap.
> 
> Suppose customer A has two sites connected via an L2 ethernet PW.  At one end,
> 
> the customer comes in through an aggregation device, and has to be
> distinguished
> by VLAN.  At the other end, the customer is assigned a physical port.  Now,
> should the *signaling* have to be aware of this difference?  I would say, no.
> With the martini signaling the way it is, we have to either define it as VLAN
> at
> both ends or Ethernet at both ends, and signal the PW accordingly.  And since
> the VLAN tag is necessary on the one end, it is imposed at the other end too.
> 
> The VLAN tag is only locally significant when used as a customer service
> delimiter.  So I would rather see the encap behavior be: strip the (locally
> significant) VLAN tag off, and send the ethernet frame without preamble or
> FCS,
> and re-generate at the far end.  That gives the flexibility to either use a
> customer specific tag or a physical port at either end without regard to what
> happens at the either end.
> 
> Note that I am not talking about VLAN tags used by the customer for internal
> reasons.  These should be passed through untouched.
> 
> -Vach
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
> > Rosen
> > Sent: Wednesday, April 17, 2002 9:26 AM
> > To: Claude Kawa
> > Cc: [email-masked]'
> > Subject: Re: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt
> >
> >
> >
> > Claude> It is  unspecified in draft-martini-ethernet-encap-mpls-00.txt) what
> 
> > Claude> piece(s)  of protocol  control information  received in  an Ethernet
> 
> > Claude> frame from a CE, a PE will use to select the right PE-PE LSP.
> >
> > This must definitely NOT be specified.
> >
> > When a  PE receives a frame  from a CE, it  clearly must use  some method to
> 
> > determine the  pseudowire on  which that frame  should be  transmitted.  The
> 
> > method  used is  a matter  of  agreement between  a service  provider and  a
> 
> > customer, and must not be specified by the protocol.
> >
> > The use of pseudowires to provide  various kinds of service is really within
> 
> > the province  of the L2VPN work being  done by the PPVPN  WG.  For instance,
> 
> > ethernet service pseudowires can be  used to provide either a point-to-point
> 
> > service or a transparent LAN service.  This difference is really a matter of
> 
> > just how to  determine the PW for a particular  frame.  PWE3 mechanisms must
> 
> > support both services.
> >
> >
> >
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Eric Rosen <[email-masked]>
Date: Thu, 18 Apr 2002 10:27:26 -0400

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?