Subject: Ethernet over MPLS

From: Shahram Davari <[email-masked]>
Date: Wed, 12 Mar 2003 11:24:48 -0800

Hi,

Why does draft-ietf-pwe3-ethernet-encap-02.txt requires that in tagged mode all frames inside a single PW have the same VLAN tag?

Thanks,
> __________________________________________
> Shahram Davari, B.Eng., M.Sc.
> Senior Product Research Engineer
> PMC_Sierra, Inc.
> Tel: (613)271-4018
> Fax: (613)271-6468
> MailTo: [email-masked]
> __________________________________________
> 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 13 Mar 2003 10:12:27 -0500

Shahram,

I agree that the draft could do a better job explaining the difference 
between raw mode and tagged mode.  The distinction really is how the VLAN 
tags are treated by the network.

In tagged mode, the PEs interpret the VLAN tag and have a one-to-one 
association between tags and inner VC labels.  Since the ingress PE is 
demultiplexing ingress frames by VLAN tag in order to associate them with a 
particular VC label, a priori all of the frames sent using a particular VC 
label must have the same tag.  This is similar in concept to ATM VPI/VCI mode.

In raw mode, VLAN tags are ignored by the PEs (LERs) and are just passed 
transparently if they are in the frames.  If they exist, they only have 
significance to the CEs. An inner LSP can mix both tagged and non-tagged 
frames, and different tags can used in the frames.  This is very much like 
ATM port mode.

A very good question is whether the VLAN tags should be stripped in tagged 
mode, since they are carrying redundant information and are thus just 
additional overhead.  I personally wouldn't mind that, but the consensus 
among the authors was that the additional processing at the ingress wasn't 
worth it, especially since there is a good chance that a new tag will be 
imposed at the egress.  If you transmit the tag, then you just have to 
overwrite it at the egress rather than have to add it to the frame.  But 
you may have to strip it at the egress anyway.

Cheers,
Andy

-------

At 3/12/2003 11:24 AM -0800, Shahram Davari wrote:

>Hi,
>
>Why does draft-ietf-pwe3-ethernet-encap-02.txt requires that in tagged 
>mode all frames inside a single PW have the same VLAN tag?
>
>
>Thanks,
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Eric Rosen <[email-masked]>
Date: Thu, 13 Mar 2003 10:25:20 -0500

Andy> In tagged mode,  the PEs interpret the VLAN tag  and have a one-to-one
Andy> association between tags and inner VC labels.  Since the ingress PE is
Andy> demultiplexing ingress frames  by VLAN tag in order  to associate them
Andy> with a particular VC label, all  of the frames sent using a particular
Andy> VC label must have the same tag.

Andy> In raw  mode, VLAN  tags are ignored  by the  PEs (LERs) and  are just
Andy> passed transparently if  they are in the frames.   If they exist, they
Andy> only have  significance to the CEs.  An inner LSP can  mix both tagged
Andy> and  non-tagged frames,  and different  tags can  used in  the frames.

This is a nice explanation of something which is not explained at all in the
draft.  I suggest that this explanation be incorporated into the draft.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 13 Mar 2003 08:38:48 -0800

Andy,

Thanks for your clear explanation. So the tagged mode is like
ATM 1:1 mode and the raw mode is like ATM port mode. My question is
why don't we have something like ATM n:1 mode?

Thanks,
-Shahram

>-----Original Message-----
>From: Andrew G. Malis [mailto:[email-masked]]
>Sent: Thursday, March 13, 2003 10:12 AM
>To: Shahram Davari
>Cc: [email-masked]'
>Subject: Re: [PWE3] Ethernet over MPLS
>
>
>Shahram,
>

---

From: "Vach Kompella" <[email-masked]>
Date: Thu, 13 Mar 2003 09:10:05 -0800

I concur.

Note that VPLS suggests a PSN function (which can also be used with POPS
(plain-old-pipe-service) :-)) of stripping service-delimiting tags.  This would
accommodate Shahram, probably, but be out of scope for PWE3.  We do describe it
in VPLS because we think it is useful (critical) for a multi-point service.

-Vach

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
> Rosen
> Sent: Thursday, March 13, 2003 7:25 AM
> To: Andrew G. Malis
> Cc: Shahram Davari; [email-masked]'

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 13 Mar 2003 12:23:35 -0500

Hi Andy,

I think I have the same question as Shahram ("why don't we have something like ATM n:1 mode?")

I don't see why the fact that the PE interprets the VLAN tag implies that there needs to be a one-to-one association between tag and inner VC label. As you write yourself, it makes the VLAN tag redundant.

I thought that the main benefit of the tagged mode was that it makes VLAN tags only locally significant. I.e. a specific tag is valid in one metro network and can be translated to another tag if the traffic is forwarded to another metro network, hence increasing the scaleability of the service. It seems to make more sense to me to use the inner label to identify the customer and to use the additional VLAN tag to identify a VLAN on that customers network. In other words, use a one-to-one association between customer and inner label but an N:1 association between VLAN tags and inner label.

Peter

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 10:12 AM
To: Shahram Davari
Cc: [email-masked]'
Subject: Re: [PWE3] Ethernet over MPLS

Shahram,

Cheers,
Andy

-------

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 13 Mar 2003 16:29:45 -0500

Andy, Eric,

Two observations:

1) Eric wrote: "Irrespective of the PW mode, one can have an NSP function which manipulates the tags according to some local policy." This contradicts the ethernet-encapsulation draft, which states that "On a raw mode PW, a frame MAY contain an 802.1Q VLAN tag, but if it does, the tag is not meaningful to the NSPs, and passes transparently through them" .  However, Eric suggests that the real intention of the draft is not to limit NSP behavior, but to create a mode (the tagged mode), where the VLAN tag is used by the ingress PE to determine the PW

2) Andy's email is in line with statement I quoted from the draft. However, Andy's interpretation of tagged mode is that it is the only mode in which you can rewrite tags on egress because you are sure that you don't loose information.

This raises two questions:

a) In Andy's explanation, I still don't understand why all VLAN tags on a tagged-mode PW must be the same. E.g. in the canonical example of interworking 802.1Q with 802.1 (non-Q), why can't the NSP use different VLAN tags for each non-Q physical interface and map all traffic on the same PW?

b) Why do we make a difference between "raw mode" and "tagged mode"? It seems that Andy's canonical example could also be solved in raw mode if you follow Eric's way of thinking:(going from non-Q over PW to Q) on ingress, map each non-Q physical interface to a PW; on egress add a VLAN tag according to local policies.

Peter

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 3:03 PM
To: [email-masked]
Cc: Busschbach, Peter B (Peter); 'Andrew G. Malis'; Shahram Davari;
[email-masked]'; Vach Kompella
Subject: Re: [PWE3] Ethernet over MPLS 

Eric and Vach,

Thanks for the clarifications.  One thing that's perfectly clear :-) is 
that we need to better specify the external functionality and internal 
behavior on the wire of these modes before the Ethernet spec makes it to 
RFC-hood.

As Eric points out, you should use a combination of raw mode on the wire 
and ingress classification in the PE to produce "N-to-1 mode".  And Vach is 
also correct that you most certainly don't want to rewrite the tags.

So "tagged" mode remains the only mode where you can rewrite existing tags 
on the egress, because you absolutely know that you're not losing any 
information.

I did have a couple of comments on Eric's clarifications:

>This does  show a problem with Andy's  statement that in raw  mode "tags are
>ignored by the PEs".  It would be more precise to say that the tags (if any)
>which are carried in raw mode are not used by the PE to choose the PW.

Not exactly (see above).  It would be more precise to say that raw mode 
requires the transparent transport of any and all VLAN tags at the ingress, 
and at the egress tags are not rewritten; while with tagged mode, all of 
the tags are the same, and this allows tags to be rewritten at the egress.

As Vach pointed out, for the most part it becomes VPLS functionality when 
you start pushing and popping tags, but there is one case where PWE3 label 
pushing and popping should be allowed, and that is to allow the 
interoperation of 802.1Q on one side of the pseudo-wire and "legacy" 802.1 
(non-Q) on the other.  The canonical example is the interconnection of a 
multi-VLAN port (using tags to distinguish between VLANs) to a bunch of 
individual non-tagged Ethernet ports elsewhere in the network, with each 
non-tagged Ethernet port corresponding to a VLAN at the 802.1Q port.  In 
this case tagged mode would be used for the pseudo-wire.  I suppose this 
could also be generalized to Q-in-Q by supporting a single port with N+1 
tags on one side of the pseudo-wires and a bunch of ports with N tags on 
the other side of the PWs.

>I also don't  think it would make any  sense to use tagged mode  but to omit
>the VLAN tag, as this would be no different than raw mode.

The point here was that in tagged mode, you don't lose any information if 
you strip the outermost tag before transmitting on the wire, so it's an 
implementation ease vs. transmission efficiency issue.

Cheers,
Andy

---

From: Samir Sanghani <[email-masked]>
Date: Thu, 13 Mar 2003 17:04:51 -0500

I also would like to ask along with Peter and Shahram's original question. -
why restrict?

What draft could allow is:

A PW may have either multiple or single VLAN associated with it based on the
wire requirements. If I think of a PW as a VLAN trunk, then I don't see
anything wrong in mapping multiple VLAN streams to the SAME VC label at
Ingress PE. Wouldn't it be simpler?

However,
if such VLANs (individually) need to be re-written at Egress PE, it wld be
easier if each VLAN has a separate VC label association. 
(I am thinking from hardware implementation point of view)

Samir 

-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:[email-masked]]

Hi Andy,

I think I have the same question as Shahram ("why don't we have something
like ATM n:1 mode?")

I don't see why the fact that the PE interprets the VLAN tag implies that
there needs to be a one-to-one association between tag and inner VC label.
As you write yourself, it makes the VLAN tag redundant.

I thought that the main benefit of the tagged mode was that it makes VLAN
tags only locally significant. I.e. a specific tag is valid in one metro
network and can be translated to another tag if the traffic is forwarded to
another metro network, hence increasing the scaleability of the service. It
seems to make more sense to me to use the inner label to identify the
customer and to use the additional VLAN tag to identify a VLAN on that
customers network. In other words, use a one-to-one association between
customer and inner label but an N:1 association between VLAN tags and inner
label.

Peter

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 13 Mar 2003 14:47:22 -0800

At 04:29 PM 3/13/2003 -0500, Busschbach, Peter B (Peter) wrote:
>Andy, Eric,
>
>
>Two observations:
>
>1) Eric wrote: "Irrespective of the PW mode, one can have an NSP function 
>which manipulates the tags according to some local policy." This 
>contradicts the ethernet-encapsulation draft, which states that "On a raw 
>mode PW, a frame MAY contain an 802.1Q VLAN tag, but if it does, the tag 
>is not meaningful to the NSPs, and passes transparently through them" 
>.  However, Eric suggests that the real intention of the draft is not to 
>limit NSP behavior, but to create a mode (the tagged mode), where the VLAN 
>tag is used by the ingress PE to determine the PW

If you consider  the example of: a single .1q trunk on one side is getting 
mapped into multiple non-tagged Ethernet ports on the other side, then both 
of these statements are true when raw mode is used. On the PE with .1q 
trunk, the NSP is transparent to different VLAN tags; whereas, on the PE 
with non-tagged Etherent ports, the NSP needs to push a VLAN tag on each 
frame before passing it through the PW. Maybe the text should say, that in 
raw mode, when a PW contains VLAN tags, these tags are not used as 
service-delimiter by the NSP.

>a) In Andy's explanation, I still don't understand why all VLAN tags on a 
>tagged-mode PW must be the same. E.g. in the canonical example of 
>interworking 802.1Q with 802.1 (non-Q), why can't the NSP use different 
>VLAN tags for each non-Q physical interface and map all traffic on the same PW?

In that case, you can just use raw mode.

>b) Why do we make a difference between "raw mode" and "tagged mode"? It 
>seems that Andy's canonical example could also be solved in raw mode if 
>you follow Eric's way of thinking:(going from non-Q over PW to Q) on 
>ingress, map each non-Q physical interface to a PW; on egress add a VLAN 
>tag according to local policies.

As mentioned earlier, raw mode can be used for all scenarios; whereas, 
tagged mode is intended for scenarios where PEs don't have flexible NSP to 
do push and pop of VLAN tags (mainly egress PEs) and instead egress PE 
expects to receive the Ethernet frame in the final delivery format (with 
proper tagging).

-Ali

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 13 Mar 2003 19:09:22 -0500

Ali,

Your last two emails provide a clear reason why the tagged mode is defined. It still leaves me with a couple of questions, though.

1) The ethernet-encap draft suggests that in tagged mode the NSPs manipulate frames ("the two endpoints must have some agreement on how to process the tag"). However, in your explanation the tagged mode is defined because at least one of the two PEs cannot push or pop tags. This is not necessarily inconsistent, but reading the draft, I never would have guessed.

2) You write that raw mode can be used in all scenarios. I don't understand that. According to the ethernet-encap draft, in raw mode, NSPs pass tags transparently through. It seems that you, Eric and Vach all assume that in raw mode, the NSP have full flexibility in pushing, popping and rewriting tags. I don't have a problem with that, but if that is the consensus, the draft needs to be reworded.

3) Is it reasonable to assume that there are PEs that are not able to push and pop tags? In Andy's canonical example, at least one of the two PEs must be able to push and pop tags. That means that a service provider would end up with a network of some non-popping PEs and some fully-functional PEs. Isn't that a situation one would want to avoid at all costs? 

4) I still don't understand why all VLAN tags on a tagged-mode PW must be the same. I understand that I can use different VLAN tags in raw mode. However, the 
ethernet-encap draft explicitly forbids it for the tagged mode and I still don't understand why. If the tagged mode is defined because one of the PEs cannot push and pop tags, that doesn't seem a reason to forbid the use of different tags on the same PW.

Peter

-----Original Message-----
From: Ali Sajassi [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 5:47 PM
To: Busschbach, Peter B (Peter); 'Andrew G. Malis'; [email-masked]
Cc: Busschbach, Peter B (Peter); Shahram Davari; [email-masked]'; Vach
Kompella
Subject: RE: [PWE3] Ethernet over MPLS 

-Ali

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 13 Mar 2003 17:15:42 -0800

>2) You write that raw mode can be used in all scenarios. I don't 
>understand that. According to the ethernet-encap draft, in raw mode, NSPs 
>pass tags transparently through. It seems that you, Eric and Vach all 
>assume that in raw mode, the NSP have full flexibility in pushing, popping 
>and rewriting tags. I don't have a problem with that, but if that is the 
>consensus, the draft needs to be reworded.

Yes, you can use raw mode to:
A) transport single VLAN - in that case the VLAN tag is popped at the 
ingress and is pushed at the egress PE (VLAN tag is used as service 
delimiter and PW carries untagged frames)
B) transport multiple VLANs - in that case VLANs are transparent to NSP wrt 
service delimiter functionality (it is not used as service delimiter)
C) transport both tagged and untagged frames (e.g., port mode)

I agree that the text of the draft can be improved as Eric suggested.

>3) Is it reasonable to assume that there are PEs that are not able to push 
>and pop tags? In Andy's canonical example, at least one of the two PEs 
>must be able to push and pop tags. That means that a service provider 
>would end up with a network of some non-popping PEs and some 
>fully-functional PEs. Isn't that a situation one would want to avoid at 
>all costs?

Yes, it should be avoided if possible but if the provider has some 
non-popping PEs already installed, then "tagged  mode" comes in handy in 
this type of situation as one PE (fully-functional PE) can insert the tag 
which is used by another PE (non-popping PE). Also some PEs can perform tag 
rewriting more efficiently than tag pushing/poping (e.g., if they have a 
choice between tagged mode and raw mode, they would prefer tagged mode).

>4) I still don't understand why all VLAN tags on a tagged-mode PW must be 
>the same. I understand that I can use different VLAN tags in raw mode. 
>However, the
>ethernet-encap draft explicitly forbids it for the tagged mode and I still 
>don't understand why. If the tagged mode is defined because one of the PEs 
>cannot push and pop tags, that doesn't seem a reason to forbid the use of 
>different tags on the same PW.

In tagged mode, there is one-to-one relationship between PW and a single 
VLAN. If you remove this restriction, then the difference between tagged 
mode and raw mode becomes nebulous.

-Ali

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Fri, 14 Mar 2003 11:24:24 +0900 (JST)

Andy,

> label must have the same tag. This is similar in concept to ATM VPI/VCI mode.

According to the IEEE 802.1D-1998, frame misordering is defined as following.

|6.3.3 Frame misordering
|The MAC Service does not permit the reordering of frames with a given user
|priority for a given combination of destination address and source address.
|
|Where Bridges in a Bridged LAN are capable of connecting the individual MACs
|in such way that multiple paths between any source-destination station pairs
|exist, the operation of a protocol is required to ensure that a single path
|is used.

And in the draft of update version of 802.1D, it is defined as following.

|6.3.3 Frame misordering
|The MAC Service (9.2 of ISO/IEC 15802-1) permits a negligible rate of the 
|reordering of frames with a given user priority for a given combination of 
|destination address and source address.
|
|NOTE 1-The Forwarding Process in Bridges (7.7) does not mis-order or duplicate
|frames.
|
|Where Bridges in a Bridged LAN are capable of connecting the individual MACs
|in such way that multiple paths between any source-destination station pairs
|exist, the operation of a protocol is required to ensure that a single path
|is used.

IEEE 802.1Q does not override the above definition. Therefore, Bridges must 
ensure frame ordering regardless VLAN ID value. And an end station may 
belong to multiple VLANs. So my question is how the tagged mode ensures
frame ordering between LSPs. I think it must have some mechanism, 
otherwise it violates the standard.

Thanks,

Muneyoshi Suzuki
Nippon Telegraph and Telephone Corp.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 14 Mar 2003 10:06:01 -0500

Ali's got it right.  If there weren't PEs that preferred to overwrite tags 
on egress as opposed to pushing them (or are unable to push tags on egress) 
then we wouldn't need tagged mode at all.  But as long as we wish to 
accommodate such PEs, we need the two modes.  In any case, Ali's 
definitions are probably the best to capture for the next revision of the 
draft.

Cheers,
Andy

-------

At 3/13/2003 05:15 PM -0800, Ali Sajassi wrote:

>>assume that in raw mode, the NSP have full flexibility in pushing, 
>>popping and rewriting tags. I don't have a problem with that, but if that 
>>is the consensus, the draft needs to be reworded.
>
>B) transport multiple VLANs - in that case VLANs are transparent to NSP 
>wrt service delimiter functionality (it is not used as service delimiter)
>>3) Is it reasonable to assume that there are PEs that are not able to 
>>push and pop tags? In Andy's canonical example, at least one of the two 
>>PEs must be able to push and pop tags. That means that a service provider 
>which is used by another PE (non-popping PE). Also some PEs can perform 
>tag rewriting more efficiently than tag pushing/poping (e.g., if they have 
>a choice between tagged mode and raw mode, they would prefer tagged mode).
>
>
>>ethernet-encap draft explicitly forbids it for the tagged mode and I 
>>still don't understand why. If the tagged mode is defined because one of 
>>the PEs cannot push and pop tags, that doesn't seem a reason to forbid 
>>the use of different tags on the same PW.
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 14 Mar 2003 07:32:31 -0800

Ordering is generally required for micro-flows. Is there any application that might generate Ethernet packets with different VLAN ID for the same micro-flow?

Yours,
-Shahram

>Sent: Friday, March 14, 2003 10:19 AM
>To: Muneyoshi Suzuki
>Cc: [email-masked]; [email-masked];
>[email-masked]
>Muneyoshi,
>Thanks (?) for bringing this up.  The issue is actually more 
>general than 
>just tagged mode, since one conceivably could have more than 
>one raw mode 
>VC LSP between a pair of Ethernet ports, and use arbitrary ingress 
>classification to assign frames to a particular LSP.  But the 
>problem is 
>most pronounced in tagged mode, since it is then impossible to 
>maintain 
>sequentiality for an arbitrary <sa, da, priority> combination over all 
>VLANs between a pair of ports - sequentially can only be 
>assured for <sa, 
>da, priority, tag> combinations.
>
>I don't think we have any easy way to fix this without getting rid of 
>tagged mode.  I think the best we can do is note this violation in the 
>draft, and say that if a SP wishes to comply with the 802.1D 
>requirement of 
>sequentially for all <sa, da, priority> combinations, then it 
>MUST only use 
>raw mode, and have at most one raw mode VC between each pair 
>of Ethernet ports.
>
>Cheers,
>Andy
>
>--------
>
>At 3/14/2003 11:24 AM +0900, Muneyoshi Suzuki wrote:
>
>
>>Andy,
>>
>> > demultiplexing ingress frames by VLAN tag in order to 
>associate them 
>> with a
>> > label must have the same tag. This is similar in concept 
>to ATM VPI/VCI 
>> mode.
>>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 14 Mar 2003 10:51:54 -0500

Andy,

Couldn't this be solved by allowing multiple VLAN tags on the same tagged-mode PW?

If the only reason for introducing tagged mode is the accomodation of PEs that can't push tags, I still don't see why there needs to be a one-to-one relationship between PW and VLAN tag. (Unless these "legacy" PEs have other restrictions that we have to take into account.)

Peter

> most pronounced in tagged mode, since it is then impossible 
> to maintain 
> >|NOTE 1-The Forwarding Process in Bridges (7.7) does not 
> mis-order or 
> >duplicate
> >|frames.
> >|

---

From: Shahram Davari <[email-masked]>
Date: Fri, 14 Mar 2003 07:58:02 -0800

Ali,

>If a single PW is used to carry all the tagged frames from the 
>.1q port, 
>then raw mode needs to be used. However, if multiple PWs are 
>used, then you 
>have a choice of  using either raw mode (stripping the VLAN tag at the 
>ingress and then pass it over the PW) or tagged mode (passing 
>the VLAN tag over the PW and then stripping it at the egress before delivery to 
>non-tagged Ethernet port).

Why can't one use raw mode for the latter case? If the ingress PE can't strip
the VLAN tags, then it can simply send all tagged frames in a single PW. The egress
PE (which can pop tags) could simply pop the tags. 

>The functionality of pushing/popping tags is a 
>local mater which should be handled within the NSP.

If pushing/poping is local matter handled by NSP, then why does it have impact on the
definition of PW?

Yours,
Shahram

>Basically, raw mode PW can handle all types of scenarios and 
>tag mode is 
>needed for the scenarios where the PE can not do 
>pushing/popping of VLAN tags.
>
>-Ali
>
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 14 Mar 2003 12:16:50 -0800

Peter/Andy/Ali,

Since Raw mode does not define any NSP function, it could be used to accommodate your scenario , in which one of the PEs can't push/pop as following:

Use a single Raw PW mode and send all the frames without touching the VLAN tagged over that PW. At the egress PE, pop the VLAN tags. Since in Tagged PW mode, the VC label and the VLAN tag represent the same information, then that means we could get the flow information
directly from VLAN tag, without looking at VC label. So we could multiplex many tagged flows in Raw mode and still use it for cases that one of the PEs can't push/pop tags. 

The only restriction that I see in my above suggestion is for multipoint-to-multipoint services in which a number of VLAN tagged ports at ingress PE need to be connected to a number of other ports at egress PE. In that case if the ingress PE is not using a per-platform VLAN tag (i.e., it is using per interface VLAN tag), then flows in different interfaces at ingress PE could have the same VLAN tag, and if they are muxed and transported over the same PW, we can't demultiplex them at the egress PE.

Yours,
-Shahram

>Sent: Friday, March 14, 2003 10:52 AM
>To: 'Andrew G. Malis'; Muneyoshi Suzuki
>Cc: [email-masked]; [email-masked]
>If the only reason for introducing tagged mode is the 
>accomodation of PEs that can't push tags, I still don't see 
>why there needs to be a one-to-one relationship between PW and 
>VLAN tag. (Unless these "legacy" PEs have other restrictions 
>that we have to take into account.)
>
>Peter
>
>
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 14 Mar 2003 12:32:34 -0800

Andy,

Yes I understand, but my point was that the IEEE requirement is too restrictive for no reason.

Thanks,
-Shahram

>Sent: Friday, March 14, 2003 3:26 PM
>To: Shahram Davari
>Cc: 'Andrew G. Malis'; Muneyoshi Suzuki; 
>[email-masked];
>[email-masked]
>Muneyoshi's point is that if you want to be conformant to the 
>letter of the 
>IEEE requirement, ordering in this case is not required just for 
>microflows, but for the entire <sa, da, priority> set of frames.
>
>Andy
>
>-------
>
>At 3/14/2003 07:32 AM -0800, Shahram Davari wrote:
>
>>Ordering is generally required for micro-flows. Is there any 
>application 
>>that might generate Ethernet packets with different VLAN ID 
>for the same 
>>micro-flow?
>>
>>Yours,
>>-Shahram
>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 14 Mar 2003 15:26:14 -0500

Shahram,

Muneyoshi's point is that if you want to be conformant to the letter of the 
IEEE requirement, ordering in this case is not required just for 
microflows, but for the entire <sa, da, priority> set of frames.

Andy

-------

At 3/14/2003 07:32 AM -0800, Shahram Davari wrote:

>Ordering is generally required for micro-flows. Is there any application 
>that might generate Ethernet packets with different VLAN ID for the same 
>micro-flow?
>
>Yours,
>-Shahram
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 14 Mar 2003 15:39:36 -0500

Peter and Shahram,

Muneyoshi's problem can only be resolved if you have ALL the VLAN tags 
between a pair of Ethernet ports use the same VC label.  Whether you call 
that raw or tagged mode I guess depends on what the treatment is at the 
egress.  If you are overwriting existing tags, then it's tagged mode, 
otherwise its raw mode.

Right now the primary reason that tagged mode requires all of the VLAN tags 
to be identical on the PW is simplicity of implementation - for each VC 
label, you just need to configure a single new tag that use to overwrite 
the existing tag before it is sent out the egress interface, and you don't 
have to inspect the old tag - you don't care what it is.  If you wanted to 
allow multiple tags on the same tagged PW, then you would need to provision 
a two-dimensional table at the egress indexed by VC label and original VLAN 
tag to determine what the new tag will be, and you have to inspect the old 
tag in order to do that table lookup.

One thing I want to make clear in this discussion is that I don't want to 
be put in the position of defending the current definition of tagged 
mode.  It wasn't my requirement, and while my gear has implemented it 
because its in the draft, we can push and pop tags as easily as overwriting 
them.  I've just been explaining how the draft got to where we are now.  I 
can let other people defend it if the WG would like to see it changed or 
removed from the draft.

Cheers,
Andy

--------

At 3/14/2003 10:51 AM -0500, Busschbach, Peter B (Peter) wrote:

>If the only reason for introducing tagged mode is the accomodation of PEs 
>that can't push tags, I still don't see why there needs to be a one-to-one 
>relationship between PW and VLAN tag. (Unless these "legacy" PEs have 
>other restrictions that we have to take into account.)
>
>Peter
>
>
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 14 Mar 2003 13:02:48 -0800

Andy,

As you said, it seems that the only benefit of Tagged mode is that it requires
1 lookup rather than 2. However, if 1 lookup is simpler to implement, then I am
wondering why the same logic does not apply to ATM case, in which the N:1 mode,
which requires 2 lookup is mandatory, while 1:1 mode that requires 1 lookup is
optional.

Thanks,
-Shahram

>Sent: Friday, March 14, 2003 3:40 PM
>To: Busschbach, Peter B (Peter); Shahram Davari
>accomodation of PEs

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 14 Mar 2003 16:10:43 -0800

>PE (which can pop tags) could simply pop the tags.

Yes, everything is possible with the raw mode.

>If pushing/poping is local matter handled by NSP, then why does it have 

Lets say that we have the other type to help out with the 
push/pop-challenged NSPs :-)
These two types of PWs as defined in the spec. basically covers all the 
scenarios that one can think of. We just need some additional explanation 
in the text for better clarification.

Cheers,
Ali

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Mon, 17 Mar 2003 12:44:50 +0900 (JST)

Shahram,

> but my point was that the IEEE requirement is too restrictive for no reason.

I also think the requirement is too restrictive, if we regard a VLAN ID as
a multiplexing identifier such as VPI/VCI and DLCI. In addition to the
frame ordering rule, according to the 802.1Q, not all MAC frames are tagged,
especially BPDUs. This spec is also hard to understand.

So, I think we need to carefully investigate the VLAN standard. VLAN is 
defined in IEEE 802.1Q as, "a subset of the active topology of Bridge LAN.
Associated with each VLAN is a VLAN ID". VLAN identifies network topology!?
I think VPI, VCI identify VP, VC, never relate topology information.

Then, tagging is supported by the E-ISS in the MAC Relay Entity, not in 
the MAC Entity. This implies that the 802.1Q defines VLAN as a MAC frame 
forwarding process in a Bridge based on the VLAN ID value. That is, VLAN is 
not a technology that multiplexes logical MAC/LAN entities into a MAC/LAN 
layer.

In this sense, I think, VLAN standard in IEEE 802.1Q is completely 
consistent and not restrictive. But I think, it does not match with 
concept of multiplexing identifier in WAN technology.

Thanks,

Muneyoshi Suzuki

---

From: Shahram Davari <[email-masked]>
Date: Sun, 16 Mar 2003 23:53:30 -0800

>>the VLAN tags, then it can simply send all tagged frames in a 
>single PW. 
>>The egress

I can't understand. If you agree that the raw mode can satisfy the
requirement in which one of the PEs can't push/pop, then why is there
a need for tagged mode?

-Shahram

---

From: [email-masked]
Date: Mon, 17 Mar 2003 10:26:43 -0000

Muneyoshi,  please see below.  regards, Neil

Muneyoshi Suzuki wrote 17 March 2003 03:45
> a multiplexing identifier such as VPI/VCI and DLCI.
NH=> VPI/VCI and DLCI should strictly be regarded as link-connection
identifiers.  These only have networking currency when associated with some
parent trail.  I can see why you regard them as 'multiplexing identifiers'
(obvious for case of multiple VPCs carried by 1 VPC say) but the key
observation IMO is the parent trail association....and in this sense they
are very different to a VLAN identifier which has no parent trail.

 In addition to the
> I think VPI, VCI identify VP, VC, never relate topology information.
NH=> They do actually.....but only in the sense of the topological entity
that is their parent trail (as noted above, VPI/VCI or DLCI (or even labels
in MPLS) cannot exist outside of a parent trail).  So there is a specific
topology relationship between a link-identifer and its parent trail.  On the
other hand a VLAN tag signifies some arbitrary topology which is not at all
well defined.
> concept of multiplexing identifier in WAN technology.
NH=> I agree with your sentiments in general, subject to the difference to
link-connection identifiers noted above,

---

From: "Vach Kompella" <[email-masked]>
Date: Mon, 17 Mar 2003 06:41:33 -0800

> From: Shahram Davari [mailto:[email-masked]]
> >

Because there are PEs that cannot do some NSP functions.

-Vach

---

From: Luca Martini <[email-masked]>
Date: Mon, 17 Mar 2003 17:12:00 -0700

Following this thread I understand the following two changes that will be 
required to the draft text:

1) an explanation that Tagged mode may reorder frames <sa, da, priority>.

2) Some re-wording of the raw mode vs tagged mode text.
Can somebody suggest some simple text  for this point ?

Thanks.
Luca

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 17 Mar 2003 17:29:40 -0800

>requirement in which one of the PEs can't push/pop, then why is there

Lets go back to your previous question again and lets go over different 
scenarios:

1) mapping a trunk port on the ingress to a trunk port on the egress
This is basically port-based operation and raw mode needs to be used for 
the PW.

2) mapping a trunk port on the ingress to multiple access ports on the egress
In this case, there are two options: a) use a single raw-mode PW to send 
all the VLAN tags from ingress to egress and then use the VLAN tags in the 
egress PE to decide which access port to send the frames to or b) use 
multiple tagged-mode PWs (one for each VLAN). The problem with the first 
approach is that when VLAN tags are used as service delimiter, each PE uses 
them independent from others. So you can't expect VLAN-10 in the ingress PE 
means the same thing as egress PE.
What this means is that if you want to use a single raw-mode PW, you need 
to translate the VLAN in the ingress PE before sending it over the PW; 
however, this conflicts with raw-mode definition which says the VLAN tags 
are transparent. Therefore, you need to use either multiple raw-mode PWs 
(one for each VLAN) or multiple tagged-mode PWs (one for each VLAN). If 
raw-mode is used, then you need to do push/poping in both ingress and 
egress PEs; whereas, if tagged mode is used, you need to do push/pop in the 
ingress PE (w/ trun port) and VLAN re-write in the egress PE (w/ access 
ports). Furthermore, if tagged mode is used, then the egress PE can 
re-write the tag based on the PW itself and without paying any attention to 
the value of the VLAN tag coming over the PW.

Hope this helps. If not, then lets talk on Wednesday before or after the 
meeting.

-Ali

---

From: [email-masked]
Date: Tue, 18 Mar 2003 09:34:03 -0000

Andrew, I/BT would largely agree with you here.  IEEE do appear to have a
sound constitution for creating stds....so do ITU.  We have several concerns
with IETF modus operandi, and in particular: 'rough consensus and running
code'.....Probably a very good way of working many years ago (Internet =>
experiment), but today it looks like a method to standardise what's been
implemented (however bad?) and, by inference, one might also argue it
favours a dominant supplier.

So (wrt to your proposal), if there is no *forward looking* justification
for tagged mode than I'd agree it should be deprecated in any standards.

regards, Neil

> From: Andrew Smith [mailto:[email-masked]]
> Sent: 18 March 2003 01:25
> To: 'Luca Martini'
> Cc: [email-masked]
> Luca,
> Alternatively, it's time to reconsider whether the Tagged Mode is
> justified at all. 
> 
> There's not a really good set of criteria that IETF uses for 
> evaluating
> this sort of thing: maybe it needs some. For what it's worth, IEEE 802
> uses what many consider to be a good set of "5 criteria" that must be
> met by any standard or feature of a standard. These include, with my
> commentary on each added:
> - distinct identity (don't publish two standards that achieve the same
> goal, don't allow multiple options in one standard for achieving the
> same goal).
> - broad market potential (general purpose solutions - don't make
> assumptions about how e.g. VLANs will be used in the future; don't
> fragment the market by making customers choose between incompatible
> options). 
> - compatibility with other standards (e.g. don't place restrictions on
> the ways in which existing standards can be used with this new one).
> - technical feasibility (anything's possible - it's just software or
> gates, right?).
> - economic feasibility (backwards compatibility with pre-standard
> implementations is *not* part of this criterion - the standard/feature
> must stand on its own for new implementations).
> 
> I don't think Tagged Mode passes many of these test criteria: may I
> start a call for getting rid of Tagged Mode? Does anyone else think it
> doesn't belong here in this piece of work? Does it make it a "better"
> standard for having it in there?
> 
> Andrew Smith
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luca
> Martini
> Sent: Monday, March 17, 2003 4:12 PM
> To: [email-masked]
> Cc: Shahram Davari; 'Ali Sajassi'; Andrew G. Malis; [email-masked];
> Busschbach, Peter B (Peter); [email-masked]

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 18 Mar 2003 09:40:47 -0500

> are transparent. Therefore, you need to use either multiple 

[PB] My personal view is that this restrictive definition of raw-mode is undesirable. From earlier emails it is clear that there is consensus that in raw mode, NSPs can push and pop tags. There also seems to be consensus that in raw mode NSPs can overwrite tags on egress, but that somehow there is a need to forbid overwriting tags on ingress. This seems to be necessary to achieve a clear distinction  between raw mode and tagged mode.

I agree with Andrew Smith: get rid of the tagged mode. Instead, clarify in the ethernet-encap draft that NSPs should be able to push, pop and overwite tags both on ingress and egress and that NSPs should be able to map one VLAN tag onto a single PW or multiple VLAN tags onto one PW. With such a definition, tagged mode is just a special case of general NSP functionality.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 18 Mar 2003 11:18:59 -0500

Small correction, see below

> From: Busschbach, Peter B (Peter) 
> < snipped >
> [PB] My personal view is that this restrictive definition of 
> raw-mode is undesirable. From earlier emails it is clear that 
> there is consensus that in raw mode, NSPs can push and pop 
> tags. There also seems to be consensus that in raw mode NSPs 
> can overwrite tags on egress, but that somehow there is a 
> need to forbid overwriting tags on ingress. This seems to be 
> necessary to achieve a clear distinction  between raw mode 
> and tagged mode.
> 
> I agree with Andrew Smith: get rid of the tagged mode. 
> Instead, clarify in the ethernet-encap draft that NSPs should 
> be able to push, pop and overwite tags both on ingress and 
> egress and that NSPs should be able to map one VLAN tag onto 
> a single PW or multiple VLAN tags onto one PW. With such a 
> definition, tagged mode is just a special case of general NSP 
> functionality.
> 

[PB] I meant: NSPs should be able to map one VLAN tag onto a single PW, AND to map multiple VLAN tags onto one PW

> < snipped >

---

From: Shahram Davari <[email-masked]>
Date: Tue, 18 Mar 2003 09:37:34 -0800

Ali,

-----Original Message-----
From: Ali Sajassi
To: Shahram Davari; 'Ali Sajassi'; Andrew G. Malis; [email-masked]
Cc: Busschbach, Peter B (Peter); 'Andrew G. Malis'; [email-masked]'; Vach Kompella
Sent: 3/17/03 5:29 PM
Subject: RE: [PWE3] Ethernet over MPLS 

the PW.

SD=>OK.

2) mapping a trunk port on the ingress to multiple access ports on the
egress
In this case, there are two options: a) use a single raw-mode PW to send

all the VLAN tags from ingress to egress and then use the VLAN tags in
the 
egress PE to decide which access port to send the frames to or b) use 
multiple tagged-mode PWs (one for each VLAN). The problem with the first

approach is that when VLAN tags are used as service delimiter, each PE
uses 
them independent from others. So you can't expect VLAN-10 in the ingress
PE 
means the same thing as egress PE.

SD=> Why? VLAN tag meaning at the two ends are configured, aren't they?

What this means is that if you want to use a single raw-mode PW, you
need 
to translate the VLAN in the ingress PE before sending it over the PW; 
however, this conflicts with raw-mode definition which says the VLAN
tags 
are transparent. Therefore, you need to use either multiple raw-mode PWs

(one for each VLAN) or multiple tagged-mode PWs (one for each VLAN). If 
raw-mode is used, then you need to do push/poping in both ingress and 
egress PEs; whereas, if tagged mode is used, you need to do push/pop in
the 
ingress PE (w/ trun port) and VLAN re-write in the egress PE (w/ access 
ports). Furthermore, if tagged mode is used, then the egress PE can 
re-write the tag based on the PW itself and without paying any attention
to 
the value of the VLAN tag coming over the PW.

meeting.

-Ali

---

From: [email-masked]
Date: Wed, 19 Mar 2003 13:46:30 -0000

Lloyd,   
> Lloyd Wood [mailto:[email-masked]]
> Sent: 19 March 2003 13:20
> To: Harrison,N,Neil,IKL2 R
> Cc: [email-masked]; ; 
> On Tue, 18 Mar 2003 [email-masked] wrote:
> 
> > Andrew, I/BT would largely agree with you here.
> 
> You speak for BT?
I work for them and the views I express are:
(i) based on internal dicsussions with many colleagues, and
(ii)reflected in the arch document I/others here are writing that will
ultimately be reflected in out stds activities, R&D activities and
requirements to vendors.
So yes, I do speak for BT....as opposed to AT&T, FT, Nortel, etc.

regards, Neil

---

From: Peter Willis <[email-masked]>
Date: Wed, 19 Mar 2003 17:19:05 +0000

There are other people from BT here as well!

Neil does represent the views of the people in BT who have considered PWE3 
issues.

Neil is actually doing you all a service by pointing out what needs to be done 
to fix the standards that go into the boxes network operators such as BT would 
like to buy. Some vendors' business models may allow them to ignore such views.

Regards,
Peter Willis
Office of the BT Group CTO.

> On Wed, 19 Mar 2003 [email-masked] wrote:
> 
> It must be extremely convenient not having anyone else from BT here to
> disagree with you on that.
> 
> L.
>

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 24 Mar 2003 01:30:24 -0800

>SD=> Why? VLAN tag meaning at the two ends are configured, aren't they?

Yes but as discussed, if the use of same VLAN tag is enforced at both end, 
it creates scalability issue - limiting to 4K VLANs.

-Ali

---

From: "Nick Tingle" <[email-masked]>
Date: Tue, 18 Mar 2003 12:48:05 -0800

I agree too, tagged mode should go. The definition of NSPs is out of PWE3 scope anyway so why are we talking about them here (and that is what almost all of these emails have been discussing)? They can do whatever [some other WG] says they can do. It's up to that other WG to specify legal combinations of NSPs to achieve whatever multiplexing, bridging or forwarding behaviour is desired/possible. The PW just gets the Ethernet packets from A to B.

>From draft-ietf-pwe3-protocol-layer-00.txt:

   In some applications some form of data or address translation, or
   other operation requiring knowledge of the semantics of the payload,
   will be required. This is the function of the Native Service
   Processor (NSP).

   The use of the NSP approach simplifies the design of the PW by
   restricting a PW to homogeneous operation.  NSP is included in the
   reference model to provide a defined interface to this functionality.
   The specification of the various types of NSP is outside the scope of
   PWE3.

Nick.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Busschbach, Peter B (Peter)
> Sent: Tuesday, March 18, 2003 6:41 AM
> To: 'Ali Sajassi'; Shahram Davari; Andrew G. Malis; [email-masked]
> [PB] My personal view is that this restrictive definition of raw-mode 
> is undesirable. From earlier emails it is clear that there is 
> consensus that in raw mode, NSPs can push and pop tags. There also 
> seems to be consensus that in raw mode NSPs can overwrite tags on 
> egress, but that somehow there is a need to forbid overwriting tags 
> on ingress. This seems to be necessary to achieve a clear distinction 
>  between raw mode and tagged mode.
> 
> I agree with Andrew Smith: get rid of the tagged mode. Instead, 
> clarify in the ethernet-encap draft that NSPs should be able to push, 
> pop and overwite tags both on ingress and egress and that NSPs should 
> be able to map one VLAN tag onto a single PW or multiple VLAN tags 
> onto one PW. With such a definition, tagged mode is just a special 
> case of general NSP functionality.
> 
> 
>

---

From: Scott W Brim <[email-masked]>
Date: Wed, 19 Mar 2003 14:04:59 -0500

On Wed, Mar 19, 2003 06:50:08PM +0000, Lloyd Wood allegedly wrote:
> > but today it looks like a method to standardise what's been
> > implemented (however bad?) and, by inference, one might also argue
> > it favours a dominant supplier.
> 
> Note the order: first rough consensus, then running code (which
> finetunes that consensus). 

There has never been an implied ordering.  Running code has always been
influential.  On the other hand, people who write code based on a
standard before the standard is finished, and then object to
improvements, don't get respect.

---

From: "Andrew Smith" <[email-masked]>
Date: Tue, 25 Mar 2003 18:05:29 -0800

Scott,

Unfortunately, what we're seeing here is a lot of respect being given to
people/vendors who have done just that, not just by WG contributors (who
can be excused for doing what's best for their employers), but also by
WG chairs and even by IESG members (who should know better - they're the
ones who are supposed to "steer" this whole ship away from such
icebergs). That needs to change for this work, and in fact the whole
sub-IP area of the IETF, to be at all relevant.

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Scott W Brim
Sent: Wednesday, March 19, 2003 11:05 AM
To: [email-masked]
Subject: Re: [PWE3] Ethernet over MPLS

...
 On the other hand, people who write code based on a
standard before the standard is finished, and then object to
improvements, don't get respect.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 28 Mar 2003 09:33:48 -0500

> Could you clarify the reason why the hw cannot support raw mode if a
> frame has a "provider tag"? 

In my example,  the tag manipulation is part of the  processing path that is
invoked when  an ethernet frame is  about to be transmitted  out an ethernet
interface.   However, in  an ingress  PE,  the ethernet  frame never  passes
through this processing path.  Hence the provider tag cannot be removed.