Subject: Ethernet Circuit Types

From: Eric Rosen <[email-masked]>
Date: Wed, 24 Jul 2002 11:48:00 -0400

>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. 

  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. 

- 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. 

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

  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.

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.  

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. 

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.

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

---

From: Eric Rosen <[email-masked]>
Date: Wed, 24 Jul 2002 14:35:46 -0400

Eric> So I think we need only one circuit type, but possibly some additional
Eric> signaling.

Giles> which is pretty much the same having multiple circuit types? 

No.  Perhaps what one needs to know  is whether one is going to be receiving
frames that  have a service delimiting  tag which needs to  be stripped.  As
this  can  be  different  at each  end  of  the  PW,  and  as the  PW  is  a
bidirectional circuit  of a single type,  the information one  needs to know
cannot really be represented as a circuit type.  

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

Yes, I think so.

---

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

> cannot really be represented as a circuit type.  

good point.

Though you could argue that the only reason you would ever see a service
delimiting tag that needs to be stripped is that the other end is
incapable of stripping it.  In which case the other end is highly
unlikely to be able to add it on egress - so you would need to add the
same service delimiting tag when sending in the reverse direction?

So really PWs divide into two classes:

1.  those which carry a service delimiting tag.

2.  those which don't.

Isn't this what we have today?

Giles

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

---

From: Eric Rosen <[email-masked]>
Date: Wed, 24 Jul 2002 15:11:41 -0400

Giles> Though you  could argue  that the  only reason you  would ever  see a
Giles> service delimiting  tag that needs to  be stripped is  that the other
Giles> end is  incapable of stripping  it.  In which  case the other  end is
Giles> highly unlikely to be able to add it on egress - so you would need to
Giles> add  the same  service delimiting  tag  when sending  in the  reverse
Giles> direction?

For the sake of argument, let's  consider this scenario, and look at the two
ends.  

Ex hypothesi, one end is  incapable of stripping/adding tags.  The other end
has to be  configured with the service delimiting tags to  add, and it knows
by virtue of this configuration that it has to add/strip tags. 

So what's the point of signaling two different circuit types?  Each endpoint
does what it is configured to do (or is capable of doing), the signaling has
nothing to do with it.

---

From: David Zelig <[email-masked]>
Date: Thu, 25 Jul 2002 10:57:10 +0200

Ali,

> 
> 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-enc
>ap-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.

What will you do if they are both? If the user want to connect to multiple
sites from a single Ethernet port, so it marks it with VLANs but want in the
same time that the VLAN to be transparent in provider networks since it is
depends on it's internal LAN scheme?. In this case you need to carry the
VLAN even if it used by one peer as service delineator.

I believe that the issue of stripping tags, removing the nested VLAN in one
end or not is really the function of the NSP, and given that anyway you need
to configure both peers for a service to come up, and all the operations
mentioned can be done at one peer while the other can be kept simple, the
only motivation to signal different type of PW for VLAN is for cases you
want to make sure between the peers that there is no configuration error. An
example to it is VLAN change between edges, where because a change is done
sometimes blindly, you want to make sure the peer is not  configured to send
you multiple VLANs since then you'll "merge" them all. Carrying the VLAN
field (except from support of old H/W) has the benefit of carrying the
user's PRI bits transparently.

I think the following definition will cover all cases:
- use raw mode whenever more than one VLAN or the whole port independent of
the VLAN scheme is associated to the PW.
- The NSP can strip/add VLAN fields and may forward from the same physical
port to different PW on whatever scheme he wants.
- Use VLAN mode when you carry only one VLAN, and carry the VLAN field
inside. The internal value of the VLAN field may be dependant on the
capabilities of the peers.
(no one prevent you from using raw mode to carry one VLAN only, but it is
the provider selection if he want the extra configuration coordination
between the sites).

David

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 25 Jul 2002 04:42:05 -0700

>VLAN even if it used by one peer as service delineator.

Since in your example, the customer VLAN is used to select different PW for 
connectivity to different sites, then the customer VLANs are not 
transparent to the SP and thus they are used as service delimiters. And if 
we are talking about VPLS, then customer VLANs are not used for site 
selection and thus they are passed transparently via the PW.

>want to make sure between the peers that there is no configuration error.

I would agree with Eric that this is basically a configuration issue and 
not a signaling issue (please refer to his email threads).

>  An

User PRI bits can be mapped to PW QoS bits at the ingress PE and vise versa 
at the egress PE.

>the provider selection if he want the extra configuration coordination

Still all you need is just a raw mode since with the raw mode you can do 
what ever you could do with VLAN mode. Lets remind ourselves that we are 
talking about the VC type in here and not the operations performed at the NSP.

-Ali

---

From: David Zelig <[email-masked]>
Date: Thu, 25 Jul 2002 15:06:36 +0200

Ali,
I fully agree that if you keep all in the hand of configuration we can have
only one type, the only question is the balance between signaling # of modes
and configurations error, and there is no clear cut here.

> Carrying the VLAN
And who will make sure of consistency? In addition, in most cases the PW QoS
bits represent the service bought by the customer which is usually  a subset
(i.e. less granularity) of the user marking scheme or own QoS handling in
it's own network. The fact that the VC is hidden in most of the network path
does not help you here because of PHP.

David

---

From: Eric Rosen <[email-masked]>
Date: Thu, 25 Jul 2002 10:43:03 -0400

Giles> agreed - you don't necessarily need to signal anything if you have it
Giles> configured. 

And since you have to have it configured ...

Giles> I think one argument was that signalling helps you to catch
Giles> configuration errors. 

Giles> I suppose an analogue for this is the MTU parameter in draft-martini. 
Giles> You could argue that there is no need for this - both ends should just
Giles> configure the correct MTU size and be done with it.  However as an SP
Giles> it's nice to know that a link which is "up" will work. 

If there is some particular parameter which must be set to the same value at
both  ends,  there's no  harm  in  sending that  parameter  as  part of  the
signaling; a simple "does x equal y" check doesn't complicate things much. 

The situation we  are now discussing is very different.  There  are a lot of
different  actions  either side  might  take  with  respect to  imposing  or
replacing or rewriting  VLAN tags, and for any  arbitrary combination, there
seems  to be some  situation in  which it  is valid.   If we  complicate the
signaling  simply  in  order   to  do  configuration  validity  checks,  the
inevitable result  is that there  will be perfectly valid  configurations in
which the link doesn't come  up, simply because those configurations weren't
anticipated by the original protocol designers and implementors.

I know  for a fact  that implementors are  already suffering the  effects of
over-complication  as they  try to  figure out  which circuit  types  to use
when.

---

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

On Thu, 2002-07-25 at 14:43, Eric Rosen wrote:
[snip]
> anticipated by the original protocol designers and implementors.

I'm not sure this is necessarily the case.

I think we can keep the options pretty simple:

1.  This PW carries the (single) service delimiting VLAN tag (because
one or both ends can't add/strip tags).

2.  This PW doesn't carry a service delimiting VLAN tag (but may or may
not carry other VLAN tags).

and as I say in the first case it might be good to signal the tag you
send and the tag you expect to receive - for the benefit of
implementations that don't rewrite tags.  In fact I hit this today in
the lab doing interop testing (between one box that can rewrite tags,
and one that can't).  I was configuring something up in a hurry and my
circuit only worked in one direction.  After a bit of head-scratching I
realised that the two ends had different VLAN tags configured...

To be honest these don't have to be different circuit types.  We could
collapse everything into one circuit type, and then have optional
parameters to signal the service delimiting tags that we send/expect to
receive which are only sent in the "legacy" endpoint case.

Alternatively we just leave the VLAN mode of draft-martini there as
"legacy" and encourage vendors to switch to the ethernet mode, except
when interoperating with legacy nodes.  The fact that it is harder to
screw up the ethernet mode should encourage people to migrate?

> over-complication  as they  try to  figure out  which circuit  types  to use

yes - I know some implementors have been confused by the two circuit
types :(

Giles

---

From: "Andrew Smith" <[email-masked]>
Date: Thu, 25 Jul 2002 13:56:48 -0700

Luca,

Ethernet and 802.1 packet formats such as 802.1Q VLANs offer a single,
self-describing encapsulation, not two different ones (much of the IEEE
802 architecture depends on this self-describing packet principle - be
*very* careful if you mess with it for all manner of entertaining things
could happen and you'll probably end up re-inventing the IEEE 802
protocols, in a slightly different form, if you do). You may have two
different "usages" of that single format in mind but it is wrong to call
them separate encapsulations and signal them as such. These two "usages"
are something that could be signalled or known a priori but they are not
discernable just from the (currently defined) packet format: I'd suggest
that is the debate we should be having on this issue.

There is always a tradeoff between information that is carried in every
packet and that which is set up ahead of time - each has its advantages
in different situations. I haven't yet seen the justification, for this
particular case, in having this information be known a priori.

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Luca
Martini
Sent: Thursday, July 25, 2002 1:34 PM
To: [email-masked]
Cc: Giles Heron; [email-masked]
Subject: Re: [PWE3] Ethernet Circuit Types

Eric Rosen wrote:

> Giles> Though you  could argue  that the  only reason you  would ever

> Giles> see a service delimiting  tag that needs to  be stripped is  
> Giles> that the other end is  incapable of stripping  it.  In which  
> Giles> case the other  end is highly unlikely to be able to add it on 
> Giles> egress - so you would need to add  the same  service delimiting

> Giles> tag  when sending  in the  reverse direction?
> 
> For the sake of argument, let's  consider this scenario, and look at 
> the two ends.
> 

that "end" should be redesigned. >:-)

> has to be  configured with the service delimiting tags to  add, and it

> knows by virtue of this configuration that it has to add/strip tags.
> 
> So what's the point of signaling two different circuit types?  Each 
> endpoint does what it is configured to do (or is capable of doing), 
> the signaling has nothing to do with it.
> 

it is 2 different encapsulations. same as ATM with VPI/VCI or ATM
without VPI/VCI. I do not see this as a signaling requirement. the
packet comes in with a tag , 
it should be transmitted  as is. ( + encapsulation )
The remote end then can either have an NSP function ( or switch function
), or 
just transmit the decapsulated packet out to the CE.

Ethernet, unlike ATM, has a special case where tags can be absent from
the packet. I think that this is a special encapsulation , not just
another "tag number". A pure Ethernet ( no tag ) mode is necessary for
those cases where tag are not 
desirable, such as VPLS.

Luca

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

---

From: Shahram Davari <[email-masked]>
Date: Thu, 25 Jul 2002 15:53:38 -0700

Luca,

One needs different encapsulation modes, when:

1) they can't be differentiated from each other, such as ATM cell mode and Frame mode. While the Ethernet VLAN tag can be parsed using the octet after the MAC addresses (If it is x8100, then there is a VLAN tag). or

2) when they may be multiplexed in the same VC-LSP and therefore one can't
use signaling to convey the treatment information for all PWs.

Which one is the case here?

-Shahram

> From: Luca Martini [mailto:[email-masked]]
> Sent: Thursday, July 25, 2002 4:34 PM
> To: [email-masked]
> it is 2 different encapsulations. same as ATM with VPI/VCI or 
> ATM without VPI/VCI.
> I do not see this as a signaling requirement. the packet 
> comes in with a tag , 
> The remote end then can either have an NSP function ( or 
> switch function ), or 
> Ethernet, unlike ATM, has a special case where tags can be 
> absent from the packet.
> I think that this is a special encapsulation , not just 
> another "tag number".
> A pure Ethernet ( no tag ) mode is necessary for those cases 
> where tag are not 
> desirable, such as VPLS.
> 
> Luca
> 
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Fri, 26 Jul 2002 10:20:09 -0400

Giles> (and also Ethernet VPLS of course). 

There is no need for the ethernet VPLS circuit type either.

---

From: Giles Heron <[email-masked]>
Date: 26 Jul 2002 15:33:53 +0000

> There is no need for the ethernet VPLS circuit type either. 

I wasn't saying that there was.

I was just pointing out that we *currently* have 3 VC types which all
map to the same encapsulation.

The alternative appears to be to have one VC type and then to either:

1) rely on configuration to get things right (which SPs, or at least
this SP, won't accept)

2) signal optional parameters instead of a different VC type (i.e.
change the syntax but retain the semantics?)

which are you proposing?

Giles

---

From: Heiles Juergen <[email-masked]>
Date: Fri, 26 Jul 2002 16:45:36 +0200

When Ethernet is transported over SONET/SDH using for example GFP the use of VLAN or not is not an issue. The SONET/SDH transport and GFP mapping is transparent to it. The two end systems may terminate or generate a VLAN, but that is outside the scope of the SONET/SDH transport and happens at the MAC layer.
I would expect the same behavior from Ethernet transport over a packet network.

Regards

Juergen

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 4:12 PM
> To: Luca Martini
> Cc: Ali Sajassi; David Zelig; [email-masked]
> Luca> I totally disagree. raw mode is not sufficient. On what 
> grounds do you
> Luca> arbitrarily discard the 802.1P bits ? 
> 
> Luca, I'm not  sure you're paying attention.  The proposal  
> is that there be
> one circuit  type, and what  you send on  it is whatever the  
> NSP determines
> needs to be sent.  No one has ever suggested arbitrarily 
> discarding anything.
> 
> Luca> Vlan  mode  makes  the  PW  transparent,  why  would  
> we  reduce  this
> Luca> transparency ? 
> 
> No one has suggested reducing any transparency.
> 
> Luca> I would have to change my network architecture, and 
> reduce the service
> Luca> offered without the VLAN mode.
> 
> No, the point is  that you could do exactly the same  thing 
> with one mode as
> you can do with two, except more simply. 
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Fri, 26 Jul 2002 11:06:37 -0400

Giles> The alternative appears to be to have one VC type and then to either:

Giles> 1) rely on configuration to get things right (which SPs, or at least
Giles> this SP, won't accept)

Giles> 2) signal optional parameters instead of a different VC type (i.e.
Giles> change the syntax but retain the semantics?)

Giles> which are you proposing?

Well, I would say 3: 

        Where a PW won't operate unless the two endpoints have 
        compatible configuration parameters, the signaling may
        carry those parameters, and the PW may be kept down if
        the parameters are incompatible.  Signaling may also be
        used to negotiate parameters, if appropriate.

I don't agree that this "changes  the syntax but retains the semantics", I'd
say rather that it provides the semantics you hoped you would get but didn't
really get ;-)

By carrying  these configuration checks as parameters  rather than embedding
them  into  the  circuit  type,  we  get  a  more  flexible  and  extensible
configuration checking  mechanism, with less  impact on the  basic signaling
procedures. Conceptually, we  might say that the parameters  just get passed
to the NSP, which may decide whether to accept or reject the circuit.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 26 Jul 2002 12:23:54 -0400

Giles> I'm  not  sure how  different  the semantics  between  a  VC type  of
Giles> "Ethernet  VPLS"  and an  optional  parameter  saying "this  Ethernet
Giles> circuit is being used for VPLS" are? 

How would you  use such a parameter and what  configuration errors would you
expect it to detect?

---

From: Giles Heron <[email-masked]>
Date: 26 Jul 2002 17:53:02 +0000

> How would you  use such a parameter and what  configuration errors would you

you would use this to decide whether to run split horizon between this
VC and others in the same VPLS (i.e. with the same VC ID).

inconsistency in this could result in packets endlessly recirculating
through the VPLS.  Granted misconfiguration at both ends of two or more
VCs can still create this problem - but it is twice as hard to do.

Giles

---

From: "Vach Kompella" <[email-masked]>
Date: Fri, 26 Jul 2002 10:11:40 -0700

Ali (cisco) has been asking for a single VC type for all ethernet connectivity
(VLAN, ethernet, VPLS).  I have been balking because I think there's more to a
VPLS VC type than just NSP function.  If we agree to make the VC type define the
L2 type (i.e., ethernet), and signal the NSP functions, we could reduce the
three VC types to one for p2p and one for p2mp.

As Giles pointed out, there are several attributes associated with the VPLS VC
type (that I don't think are quite NSP functions):
1. single VCID across the provider network (I didn't mind having different ones,
as long as we signaled something that referred to a collection of these VCs that
logically created a service, e.g., VPLS) - signaling issue
2. learning - relating MAC to the outbound VC based on which inbound VC it was
seen on
3. split horizon on forwarding - forwarding issue
4. full mesh, with a different VC label per peer (which could be avoided by
having a sender ID inserted by the NSP, if agreed by both ends) - topology issue

-Vach

> From: Giles Heron [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 10:53 AM
> To: [email-masked]
> Cc: Vach Kompella; Shahram Davari; 'Luca Martini'; [email-masked]

---

From: Eric Rosen <[email-masked]>
Date: Fri, 26 Jul 2002 13:44:12 -0400

Vach> As Giles pointed out, there are several attributes associated with the
Vach> VPLS VC type (that I don't think are quite NSP functions): 

Vach> 1. single  VCID across  the  provider network  (I  didn't mind  having
Vach>    different ones, as long as we signaled something that referred to a
Vach>    collection  of these VCs  that logically  created a  service, e.g.,
Vach>    VPLS) - signaling issue 

I think that what  we really want here is to use  a VPN-id in the signaling,
rather than a VCid.  I don't  think this calls for a different circuit type,
I think  it calls for a  different FEC type,  with a more general  method of
identifying the circuits.  The use of  a more general circuit id method than
VCid is applicable to all the different circuit types, not just to VPLS. 

Vach> 2. learning  - relating MAC to the outbound VC  based on which inbound
Vach>    VC it was seen on

This is definitely an NSP issue.  The MAC learning is NOT a PWE3 function.

Vach> 3. split horizon on forwarding - forwarding issue

For HVPLS,  you mean, so  that a  hub can apply  split horizon to  the other
hubs, but not  to the spokes?  If you  want a hub to be  able to dynamically
determine the  set of other  hubs, an  "I am a  hub" parameter on  a regular
ethernet  circuit type  would  seem to  do  the trick.   Again,  not a  PWE3
function. 

Vach> 4. full  mesh, with  a different  VC label  per peer

Don't see the  issue here, every PW at  a given PE has a  different VC label
per peer. 

I think the real heart of the issue is that the VCid field in draft-martini-
trans is not general  enough to let us say "I'm a hub node  for VPLS V and I
am trying  to set up an ethernet  circuit".  I think the  proper response to
this is to  generalize the circuit identification mechanism,  rather than to
try to create new circuit types  to compensate for the fact that the circuit
id mechanism isn't right.

---

From: "Vach Kompella" <[email-masked]>
Date: Fri, 26 Jul 2002 12:17:49 -0700

I guess the key is getting the signaling out of PWE3 and into PPVPN where all
the VPN issues like naming, connectivity, NSPs, etc., are better addressed.

See below for other comments.

-Vach

> Sent: Friday, July 26, 2002 10:44 AM
> To: Vach Kompella
> Cc: Giles Heron; Shahram Davari; 'Luca Martini'; [email-masked]

Clearly a PPVPN issue.

> This is definitely an NSP issue.  The MAC learning is NOT a PWE3 function.

I could be convinced of this - if there is such a thing as a "802.1d NSP".

> ethernet  circuit type  would  seem to  do  the trick.   Again,  not a  PWE3

I'm not arguing that it is a PWE3 issue.  I guess it's again a part of the
"802.1d NSP."

> id mechanism isn't right.

Clearly a signaling issue, which, again, I would classify as a PPVPN issue.

Maybe the WG chair and ADs will reconsider leaving signaling in PWE3?

---

From: Shahram Davari <[email-masked]>
Date: Fri, 26 Jul 2002 14:46:00 -0700

Hi,

Has any one defined any signaling extensions to LDP for NSP functions yet?

-Shahram

> From: Vach Kompella [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 3:18 PM
> To: [email-masked]
> Subject: RE: [PWE3] Ethernet Circuit Types 
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 29 Jul 2002 10:54:36 -0400

Shahram> Has  any  one defined  any  signaling  extensions  to LDP  for  NSP
Shahram> functions yet?  

There are a  number of proposals in PPVPN  for extending "martini signaling"
so  that it can  be used  for L2VPNs.Draft-lasserre-vkompella-ppvpn-vpls-02.
txt proposes  extensions specifically targeted  at using the  pseudowires to
provide a VPLS  service. Draft-rosen-l2-signaling-01.txt proposes extensions
to  make it  generally more  useful for  both VPLS  and VPWS,  in particular
generalizing the VCid  so that the signaling integrates  better with various
aspects of the VPWS and VPLS provisioning models, including auto-discovery.

---

From: Shahram Davari <[email-masked]>
Date: Mon, 29 Jul 2002 12:14:18 -0700

Thanks Eric,

So, can the VC-TLV be used to signal the NSP specific parameters?

Yours,
-Shahram

> Sent: Monday, July 29, 2002 10:55 AM
> To: Shahram Davari
> Cc: [email-masked]
> so  that it can  be used  for 
> L2VPNs.Draft-lasserre-vkompella-ppvpn-vpls-02.

---

From: "Matt Squire" <[email-masked]>
Date: Tue, 30 Jul 2002 16:47:05 -0400

Multiple VC types, and signaling tagged/untagged is completely unnecessary and counter-productive.  

One would hope an Ethernet pseudo-wire behaves like an Ethernet link.  An Ethernet link may be configured where one side uses "tagging" and the other side does not.  This is, in fact, how tag stacking comes about, as one endpoint views a tagged packet as untagged and adds a second tag.  

There is standard 802.1Q behavior about when to tag and not to tag on an Ethernet interface.  The Ethernet pw is just another interface, and should behave as closely as possible to an Ethernet MAC/PHY.  

The more the group strays from allowing valid Ethernet behavior, the more screwed up the protocols and exceptions are going to get, and interworking becomes a mess as different configurations operate differently over Ethernet links vs Ethernet pseudowires.  Let's not protect users from configurations you don't like - other people have and will find a use for them (re: tag stacking).  

Ethernet is a fairly proven and flexible technology - that is why we're trying to emulate it, correct?.  We shouldn't change behavior that other protocols and functions have come to expect from an Ethernet link.   Or if we do, we should at least stop calling it Ethernet.  

- Matt

>  
> well, yes I can agree with this. Which means we would have 
> only one ethernet PW type ,
> 
> but a parameter somewhere that signals the presence of a tag.
> 
> 
> Luca
> 
>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 30 Jul 2002 14:29:23 -0700

Matt,

Each PW behaves in fact like a normal p2p link. But since many PWs can
terminate on the same PE and possibly on the same interface, they look 
like multiple links to the terminating PE. A service provider
may want that the PE behave differently for each of these PWs (links). 
In that case you need to either configure the PE manually for each PW
or signal the required behavior.

Yours,
-Shahram

> From: Matt Squire [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2002 4:47 PM
> To: Luca Martini; [email-masked]
> Cc: Giles Heron; Vach Kompella; Shahram Davari; [email-masked]
> Multiple VC types, and signaling tagged/untagged is 
> completely unnecessary and counter-productive.  
> 
> One would hope an Ethernet pseudo-wire behaves like an 
> Ethernet link.  An Ethernet link may be configured where one 
> side uses "tagging" and the other side does not.  This is, in 
> fact, how tag stacking comes about, as one endpoint views a 
> tagged packet as untagged and adds a second tag.  
> 
> There is standard 802.1Q behavior about when to tag and not 
> to tag on an Ethernet interface.  The Ethernet pw is just 
> another interface, and should behave as closely as possible 
> to an Ethernet MAC/PHY.  
> 
> The more the group strays from allowing valid Ethernet 
> behavior, the more screwed up the protocols and exceptions 
> are going to get, and interworking becomes a mess as 
> different configurations operate differently over Ethernet 
> links vs Ethernet pseudowires.  Let's not protect users from 
> configurations you don't like - other people have and will 
> find a use for them (re: tag stacking).  
> 
> Ethernet is a fairly proven and flexible technology - that is 
> why we're trying to emulate it, correct?.  We shouldn't 
> change behavior that other protocols and functions have come 
> to expect from an Ethernet link.   Or if we do, we should at 
> least stop calling it Ethernet.  
> 
> - Matt
> 
> >

---

From: "Matt Squire" <[email-masked]>
Date: Tue, 30 Jul 2002 18:11:00 -0400

> or signal the required behavior.

Not arguing most of the points here but the last one.  Configuration is always required and signaling adds nothing.  

The two reasons I've heard mentioned for signaling the "tagged/not" parameter are (a) to eliminate misconfiguration, and (b) to eliminate extra configuration.  

To address (a), one side of a link using tags and the other side not using tags is a perfectly valid Ethernet configuration, and has over time proven useful.  Back when Q tags were introduced, people talked about adding safeguards to prevent such supposed misconfigurations where one side throws tags on, and the other side does not.  The decision was made to allow the behavior, and this has proven to be the correct (?) long term decision, allowing Q-tag stacking (if you view that as a good thing).  One man's misconfiguration is another man's enhancement, and outlawing valid configurations because someone doesn't like them in their environment doesn't seem like the right thing, especially when the technology being emulated made a completely contradictory decision that has resulted in practical technical flexibility.  

To address (b), I don't see that configuration is eliminated at all.  The PWs are virtual interfaces to which services must be mapped.  Knowing whether things are tagged/not is generally a consequence of how many services get mapped to an Ethernet interface (real or logical PW).  If you have > 1 VLAN on an interface, then you have to use tagging over that interface.  If you have <=1, then tagging is optional (and generally not used).  The difficult and time-consuming configuration is mapping services to interfaces/PWs, not determining whether tagging is used or not.  To tag or not to tag is generally a result of mapping VLANs to Ethernet interfaces (real or PW).  

I just want the thing to look like Ethernet.  I don't want to worry about special enhancements or limitations for PWs versus Ethernet links.  

- Matt

---

From: David Clear <[email-masked]>
Date: Tue, 30 Jul 2002 15:35:25 -0700

Hi,

I am coming in to this pretty late, but am interested in understanding how
the requirements deviate from this model:

An Ethernet PW works in one of two ways:

1) A port maps to a pseudo-wire (raw, truly transparent).
2) A port+VLAN maps to a pseudo-wire.

For type 1, operation is as follows:
	+ For PW ingress, the L2 frame is mapped by the PE to a PW based
	  on the PE ingress interface (port number), and is sent into the
	  PW untouched and otherwise unprocessed.
	+ At PW egress, the PW maps to an egress interface and the L2
	  frame is transmitted untouched and unprocessed.

Q. Is this even useful?

For type 2 (the more interesting type), operation is as follows:
	+ For PW ingress, the PE establishes the VLANID for the frame
	  either by the presence of an explicit VLAN tag, or using the
	  ingress port's default VLANID (as per .1Q).  The port+VLANID
	  then map to a PW, and the L2 frame is sent into the PW intact
	  and untouched.
	+ At PW egress, the PW maps to an egress port+VLANID.  Following
	  .1Q, the egress port will have configuration that specifies
whether
	  egress packets on the target VLAN should be tagged or untagged.
	  The L2 frame will be edited to conform, as follows:
		a) If egress packets on the target VLANID should be tagged:
			+ If the original packet was tagged, re-write the
			  VLANID with the target VLANID.
			+ If the original packet was untagged, tag it.
		b) If egress packets on the target VLANID should not be
tagged:
			+ If the original packet was tagged, strip it.

Q. Is there more to it than this?

I am not familiar with the "q-in-q" tag stacking - it sounds like it
violates .1Q (unless it's a post-dates my .1Q knowledge and has been
invented to do something clever).

It seems to me that the PW signaling should be limited to establishing
the Ethernet PW and that any extra layers of cleverness be handled by
other means.

Regards,
David.

---

From: "Andrew Smith" <[email-masked]>
Date: Tue, 30 Jul 2002 15:53:09 -0700

Matt,

Almost true. With the addition of IEEE 802.1v-2001, you can discriminate
VLANs based on upper-layer protocols, as well as just "port" (to be
precise, the original 802.1Q allows you to discriminate on whatever you
want to, it's just that the 802.1Q-1998 standard only defines the data
plane and management plane objects for "port"-based VLANs). That means
that you can have multiple VLANs on the same segment (that joins two or
more "ports" belonging to the same or different "bridges") without using
tagging. And it follows from that that all the the bridges that connect
to the segment need to have *consistent* views of how the VLANs are
being discriminated on that segment (they don't need the *same* view,
they just need someone to think through the overall network topology
before the discrimination rules are configured - there is nothing in
802.1 to help you with this network-wide configuration problem (other
than a discussion in Annex E of 802.1v - I'd suggest everyone read that
Annex before jumping into this discussion - it's applicable also to
port-based VLANs a la 802.1Q) but there are at least MIBs ...

Note: I've used the term "port" here (and put it in quotes) because this
is the term used by 802.1. How a 802.1 port relates to what this WG is
calling an "interface" needs careful definition of course.

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt
Squire
Sent: Tuesday, July 30, 2002 3:11 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [PWE3] Ethernet Circuit Types

... If you have > 1 VLAN on an interface, then you have to use tagging
over that interface.  If you have <=1, then tagging is optional (and
generally not used). ...