Subject: Re: Ethernet Circuit Types

From: Giles Heron <[email-masked]>
Date: 24 Jul 2002 19:23:41 +0000

On Wed, 2002-07-24 at 15:48, Eric Rosen wrote:
> >From the minutes: 
> 
> > ??? - Why two modes?  One strips vlan from packet before sending on the
> >       tunnel and one keeps VLAN tag
> 
> > Luca - Most vendors use VLAN tag mode since it is easy to implement on
> >        routers. 
> >        The goal is to produce encapsulations that most vendors are able
> >        to implement 
> 
> > Stewart and Mark Townsley - use principle of minimal intervention and
> >       keep VLAN tag, don't strip the VLAN tag
> 
> > Scott - at minimum we should have one required mode
> 
> This was  discussed on  the list  last April, and  I think  the issue  is as
> follows.  (There  are probably some inaccuracies below,  as my understanding
> of VLAN  tagging is a bit hazy.)   When an ethernet frame  is received, "the
> VLAN tag" may have one of two different meanings:
> 
> - Customer tag:  the tag  may have  been imposed by  some piece  of customer
>   equipment, because the customer happens to have VLANs. 
> 
>   You might be  assigning all the customer frames to one  PW.  In this case,
>   you definitely want to send across  the VLAN tag, which might or might not
>   have to be rewritten.  If the  VLAN tags need to be rewritten, there needs
>   to  be some agreement  between the  two PW  endpoints as  to who  does the
>   rewriting. 

Yes, if you are assigning all customer frames to one PW then you need to
send any VLAN tag across the PW.

I'm not sure there is much of a requirement for rewriting VLAN tags on a
PW carrying multiple VLANs though...
 
>   Alternatively, you might  be using the VLAN tag to map  frames to PWs.  If
>   the latter,  the VLAN tags might  need to be stripped  or rewritten before
>   the frames are sent  out by the egress PE.  Again, there  needs to be some
>   agreement between  the two PW  endpoints as to  who does the  stripping or
>   rewriting. 

yes

> - SP  tag: It  may  have been  imposed  by some  piece  of service  provider
>   equipment, because the SP is sharing an ethernet among multiple customers,
>   and is using a VLAN tag to distinguish the customers.  This is referred to
>   as a "service delimiting tag" in some of the VPLS documents. 

To my mind a tag used by a customer to select a PW is also service
delimiting.

>   The SP tag has only local significance, and need not be passed along.

again, the same would be true of a tag used by a customer to select a
PW.
 
>   It  is  possible that  there  is  a Customer  Tag  underneath  the SP  tag
>   ("q-in-q").  If  so, I  think the  customer tag needs  to be  passed along
>   transparently. 
>
>   If we stick to the principle of minimum intervention, we'd pass along both
>   tags, and  the remote end  would have to  strip one.  That means  that the
>   receiving end needs to know whether  the transmitting end is making use of
>   SP tags or not. 
>
>   If the  receiving endpoint is using SP  tags, and the procedure  is for SP
>   tags to be sent on the PW,  then the receiving endpoint has to now whether
>   the transmitting endpoint is using SP tags, so it knows whether to rewrite
>   the tag or whether to impose a new tag.

yes.

> Anyway, it  seems that if VLAN  tags are sent along,  the receiving endpoint
> needs to know  the significance of those tags  at the transmitting endpoint,
> so that it (the receiving endpoint) knows how to handle them properly.  

agreed.

> I don't  see though how having  two different ethernet  circuit types really
> helps here  though.  Since the two  endpoints of a  PW may not be  using the
> same VLAN  tagging procedures, it doesn't seem  to make any sense  to have a
> VLAN circuit type and a non-VLAN circuit type.
> 
> So  I think  we need  only one  circuit type,  but possibly  some additional
> signaling. 

which is pretty much the same having multiple circuit types?
 
> Actually, I think  this works out simplest if we have  one circuit type, and
> adopt the rule that (contrary  to the principle of minimum intervention) the
> service delimiting  tags should never be  sent.  But I think  Luca is saying
> that not all hardware supports this.

yes, I think it would be preferable if we always stripped the service
delimiting tags.  But yes, I think there is hardware that doesn't
support this :(

> I'd really like to see this issue hashed out and settled once and for all. 

indeed.

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 24 Jul 2002 22:55:39 -0700

>that not all hardware supports this.

Yes, all we need is one circuit type - e.g., raw mode Ethernet VC type as 
defined in
http://www.ietf.org/internet-drafts/draft-martini-ethernet-encap-mpls-01.txt 
with the rule of NOT sending service delimiting tags over the PW but 
sending customers' tags that are not service delimiting across the PW.

-Ali

>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 Jul 2002 10:55:11 +0100

I think that there may be some scoping issues that lie
at the heart of the problem here.

The purpose of SP imposed VLAN tags (and customer imposed
VLAN tags intended to provide PW addressing) is surely
a L2VPN function. L2VPN operation is being defined by the PPVPN
team. Within the PWE3 architecture the L2VPN functionality 
is executed in the NSP and the forwarder. L2VPN functionality
is not defined by PWE3. 

By contrast the PWE3 WG is defining the transport of
the payloads found on a wire, and does not concern itself
with why the application wants any bag of bits sent to any
particular location. 

If an implementation wants to merge the functions of L2VPN
and PWE3, that is a matter of local optimisation, and should
have no bearing on the architectural definition of either
PWE3 or PPVPN subsystem.

So unless there is an over-riding PPVPN architectural issue,
which requires a pseudo wire to provide a more complex service
(or an over-riding implementation issue), it would seem that
PWE3 only needs a single generic Ethernet type.

Does PPVPN need a more complex connection type as a service?

If so, what is the definition of that service?

Stewart