Subject: draft-ietf-pwe3-ethernet-encap-02.txt: Tagged mode

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 20 Mar 2003 17:22:58 -0800 (PST)

Hi Luca,

Wanted to re-iterate my comment about the tagged mode in the ethernet
encapsulation draft. There is a value in having the tagged mode and there
are several reasons for it:
    - Bunch of existing implementations; inter-operability and some
      deployment
    - Router hardware that cannot insert vlan tags on the egress PE

Some people might argue that all can be achieved with the raw mode and a
NSP function. No one is stopping them from using only the raw mode in that
case :) But there are several of us who want the tagged mode to stay there
and IMHO we should keep it that way.

thanks,
rahul

---

From: "Andrew Smith" <[email-masked]>
Date: Thu, 20 Mar 2003 19:12:50 -0800

Well that really gets to the heart of my original point: is the IETF in
the business of writing good standards or of rubber-stamping existing
implementations and deployments? It's high time the IESG made a decision
on this, specifically in the sub-IP area, and enforced whatever it
decides its policy to be by culling and pruning WGs and/or WG products
appropriately.

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rahul Aggarwal
Sent: Thursday, March 20, 2003 5:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: [PWE3] draft-ietf-pwe3-ethernet-encap-02.txt: Tagged mode

Hi Luca,

encapsulation draft. There is a value in having the tagged mode and
there

Some people might argue that all can be achieved with the raw mode and a
NSP function. No one is stopping them from using only the raw mode in
that
case :) But there are several of us who want the tagged mode to stay
there
and IMHO we should keep it that way.

thanks,
rahul 

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

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 21 Mar 2003 11:11:07 -0800 (PST)

On Fri, 21 Mar 2003, Lloyd Wood wrote:

> On Thu, 20 Mar 2003, Rahul Aggarwal wrote:
> 
> > Hi Luca,
> >
> In other words, there's value _for you_ in having it.

The above advantages go beyond me or the vendor I represent.

> Is there value for the defined standard in having it?

A defined standard has to balance between existing usage/deployment and
perfection. In this case leaving the tagged mode doesn't add undue
complexity.

> > case :)
> so you admit that the raw mode is sufficient, then.

Theoretically yes, but in practice no.

> Which means that tagged mode can be removed from the draft.
> 

Tagged mode is needed for the reasons I pointed out above.

rahul

> Andrew's entirely right to identify problems with
> drafts/PWE3/WGs/sub-ip/IESG/IETF.
> 
> L.
> 
> is just waiting for PWE3 to appoint a rapporteur.
> 
> 
> > But there are several of us who want the tagged mode to stay there
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 21 Mar 2003 11:25:55 -0800 (PST)

On Fri, 21 Mar 2003, Lloyd Wood wrote:

> On Fri, 21 Mar 2003, Rahul Aggarwal wrote:
> 
> > perfection.
> You do not standardise something simply because it exists. There are
> vendor-specific extensions in a host of arenas.

In this case the draft has been out there for a while and
lot of implementations followed the draft.

> 
> > In this case leaving the tagged mode doesn't add undue
> > complexity.
> 
> think about interoperabilty. unnecessary options weaken
> interoperability.

Inter-operability using the tagged mode has been demonstrated between
several vendors. Removing it will only hurt inter-operability.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 21 Mar 2003 16:23:30 -0500

Eric,

I agree with your view. The problem, however, is that the limitations of legacy equipment lead to a confusing situation.

Consider the following scenario:
PE1 supports ethernet interfaces on which VLAN tags are used as service delimiters (i.e. "802.1q" interfaces). PE2 supports ethernet interfaces on which VLAN tags are not used as service delimiters.

If PE1 is a legacy device that doesn't support label pushing and popping, the tagged-mode needs to be used. However, if PE2 is a legacy device, raw mode needs to be used. In other words, the applicability statement of tagged mode and raw mode will need to explicitly mention the limitations imposed by these legacy devices.

To illustrate the confusion that exists: The pwe3-control draft mentions in paragraph 4.3 that ethernet VLANs need to be carried in tagged mode. As explained above, that doesn't always work for legacy devices.

In summary, IMO the problem is not that it is essentially wrong to carry VLAN tags that are used as service delimiters over PWs. The problem is that it is almost impossible to formulate a neat applicability statement of the two modes because of the limitations of legacy equipment.

And to come back to another pet-peeve: I think that the best "real" reason for the tagged mode is the frame-ordering issue that Muneyoshi brought up a while ago. However, that would require that a PE should be able to map multiple VLAN tags onto the same PW. Should we add that as an additional mode? (A "liberal tagged mode" versus a "restricted tagged mode")

Peter 

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, March 21, 2003 3:00 PM
> To: [email-masked]
> Subject: Re: [PWE3] draft-ietf-pwe3-ethernet-encap-02.txt: 
> Tagged mode 
> 
> 
> I  don't think  we'll make  any progress  by turning  this 
> into  a religious
> issue. 
> 
> FWIW, here is my take on the issue. 
> 
> At  a given interface,  we can  distinguish between  the 
> "service-delimiting
> tags" (which we might also call "provider tags") and the 
> "customer tags". 
> 
> The  customer tags  are  meaningless to  the  provider, and  
> must be  passed
> transparently through  the PW.  A provider  tag, if present, 
> is  used by the
> provider to identify a particular customer. 
> 
> Whether a provider tag is used  at a particular interface is 
> a local matter.
> If a PW connects two interfaces, a provider tag may be used 
> at zero, one, or
> two of those interfaces.  If used at both of them, it may be 
> the either same
> or different  at the two  interfaces.  Therefore, I  think 
> the best  rule is
> "don't carry a provider tag on the pseudowire".  This is raw mode.
> 
> Note that raw mode requires that, if  a provider tag is used 
> at a particular
> interface, the forwarding hardware servicing  that interface 
> must be able to
> add and remove the tags.  Tagged mode seems useful if there 
> is hardware that
> cannot manipulate  the tags  in this manner,  but is 
> otherwise  suitable for
> providing  PWE3  functionality.   My   understanding  is  
> that  there  is  a
> significant amount of deployed hardware which falls into this 
> category.
> 
> The issue of whether tagged mode should  be part of the 
> standard is just the
> issue of  whether there  should be  a standard which  
> supports that  sort of
> hardware,  and  which  tells you  how  to  interoperate  with 
> that  sort  of
> hardware.   I  don't think  anyone  has given  a  good  
> argument that  there
> shouldn't be. 
> 
> Given that the purpose of  IETF standards is to facilitate 
> interoperability,
> my suggestion would be to leave  tagged mode in the document, 
> though perhaps
> as a "deprecated mode". 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

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

At 04:23 PM 3/21/2003 -0500, Busschbach, Peter B (Peter) wrote:
>Eric,
>
>I agree with your view. The problem, however, is that the limitations of 
>legacy equipment lead to a confusing situation.
>
>PE1 supports ethernet interfaces on which VLAN tags are used as service 
>delimiters (i.e. "802.1q" interfaces). PE2 supports ethernet interfaces on 
>which VLAN tags are not used as service delimiters.
>
>If PE1 is a legacy device that doesn't support label pushing and popping, 
>the tagged-mode needs to be used. However, if PE2 is a legacy device, raw 
>mode needs to be used. In other words, the applicability statement of 
>tagged mode and raw mode will need to explicitly mention the limitations 
>imposed by these legacy devices.
>
>To illustrate the confusion that exists: The pwe3-control draft mentions 
>in paragraph 4.3 that ethernet VLANs need to be carried in tagged mode. As 
>explained above, that doesn't always work for legacy devices.
>
>In summary, IMO the problem is not that it is essentially wrong to carry 
>VLAN tags that are used as service delimiters over PWs. The problem is 
>that it is almost impossible to formulate a neat applicability statement 
>of the two modes because of the limitations of legacy equipment.

The point is that if only one-end is capable of supporting raw-mode, then 
you can compensate for the other end that doesn't support it - you don't 
have to have both ends supporting raw mode.

-Ali

>And to come back to another pet-peeve: I think that the best "real" reason 
>for the tagged mode is the frame-ordering issue that Muneyoshi brought up 
>a while ago. However, that would require that a PE should be able to map 
>multiple VLAN tags onto the same PW. Should we add that as an additional 
>mode? (A "liberal tagged mode" versus a "restricted tagged mode")
>
>Peter
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 24 Mar 2003 15:20:46 -0500

Eric> Given  that   the  purpose  of   IETF  standards  is   to  facilitate
Eric> interoperability, my suggestion would be  to leave tagged mode in the
Eric> document, though perhaps as a "deprecated mode". 

Rahul> Just to clarify, what would 'deprecated' mean in this case..? 

It would  mean that tagged mode  is only there to  support legacy equipment,
and new equipment should be designed to support raw mode.

---

From: "Andrew Smith" <[email-masked]>
Date: Mon, 24 Mar 2003 12:40:01 -0800

Eric,

I'd suggest that this distinction be made much more explicit: list the
raw mode in a "standards' track" RFC, move the tagged mode to an
"informational" RFC (or remove it entirely which is my, and several
other people's, preference) - if you don't do this, you will be creating
a whole lot of marketplace confusion and will neither be "facilitating
interoperability" over anything more than a very short timeframe nor
making "good standards" (as in "good standards need to describe how to
live with existing implementations of things, some of which are the
product of different traditions" - Harald Alvestrand). I am assuming
that Harald did not mean to endorse the practice of implementing, and
shipping in volume, implementations of early-stage IETF drafts, and then
using any momentum built up through those means to force inclusion of an
option in the final IETF standard (though that would be a "different
tradition", of course, from the good old IETF way of doing things).

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rosen
Sent: Monday, March 24, 2003 12:21 PM
To: Rahul Aggarwal
Cc: [email-masked]
Subject: Re: [PWE3] draft-ietf-pwe3-ethernet-encap-02.txt: Tagged mode 

Eric> Given  that   the  purpose  of   IETF  standards  is   to
facilitate
Eric> interoperability, my suggestion would be  to leave tagged mode in
the
Eric> document, though perhaps as a "deprecated mode". 

It would  mean that tagged mode  is only there to  support legacy
equipment,
and new equipment should be designed to support raw mode.

---

From: Luca Martini <[email-masked]>
Date: Thu, 27 Mar 2003 17:24:50 -0700

> tradition", of course, from the good old IETF way of doing things).
humm , wouldn't IP fall into this category ? V6 was built upon V4 
implementation experience.

Maybe we should have started over ?

In the end , today service is sold primarily on a tagged mode implementations.

We are going to have many optional modes of operation for different PW types 
and requirements, but one default mode for each. High Interoperability among 
implementations of this protocol is best preserved if we keep the optional 
tagged mode. Therefore I do not believe that we should remove tagged mode if we 
want this standard to be a " good standard"

Luca