Subject: Re: Why two Ethernet Types for PW + MTU question

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 14 Nov 2002 15:25:06 -0500

Dawn,

>1. There is an alternative to your suggestion: For frames from CE2 to CE1, PE2
>will not strip the VLAN tag and will pass the frame as is to PE1, PE1 will 
>then
>strip the VLAN tag; for frames from CE1 to CE2, PE1 will pass the frame to PE2
>and PE2 will add the VLAN tag. Two alternatives (your suggestion and this one)
>will both work, but totally incompatible. Has PWE3 decided to standardize 
>one, or
>either one of them is fine? If either one of them is fine, there will be an
>interoperability issue.

The alternative in my earlier message is what is being standardized in the 
IETF.

>2. I think it is fine to signal Ethernet (0x0005) in this case. What I am 
>really
>confused is in what situation, do we need to signal Ethernet VLAN (0x0004) 
>type?
>Does anyone know any case where Ethernet VLAN type needs to be used, that
>otherwise things will break?

0x0004 is used, and VLAN tags transmitted on the wire, if tags are used for 
VLAN switching at both ends (between both CE1 and PE1 and between CE2 and 
PE2), or if the tags have end-to-end significance between CE1 and CE2 and 
are carried transparently by the PEs.

>Thanks.
>-- Dawn

Cheers,
Andy

---------

>"Andrew G. Malis" wrote:
>
> > Dawn,
> >
> > In this case, you should signal Ethernet (0x0005) in both directions, and
> > MTU without the tag.  It's up to PE2 to strip the tag on ingress from CE2
> > and add the tag on egress to CE2.  This allows CE2 to have PWs to multiple
> > other CEs, one per VLAN tag, and the tag only has significance between CE2
> > and PE2.  VLAN-capable equipment must be able to handle the extra four
> > octets between CE2 and PE2 (see Figure C-6 in 801.1Q).
> >
> > Cheers,
> > Andy
> >
> > -------
> >
> > At 11/13/2002 06:44 PM -0500, Dawn Xie wrote:
> >
> > >There was a discussion on whether two PW types (Ethernet and Ethernet
> > >VLAN) is needed a couple months ago. Was there any conclusion reached on
> > >that discussion? From the newest draft
> > >http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01 
> .txt,
> > >it does not look like a conclusion is reached.
> > >
> > >Without the conclusion, there is difficulty to support the following PW
> > >case:
> > >
> > >    | CE1 |--untagged--| PE1 |----------| PE2 |--VLAN--| CE2 |
> > >
> > >The PW at PE1 side accepts untagged Ethernet, and the PW at PE2 side
> > >accepts 802.1Q tagged frames.  It is a quite useful and common scenario.
> > >Now there are two issues:
> > >
> > >1. What PW-type PE1 and PE2 shall advertise? If PE1 advertise Ethernet
> > >(0x0005) and PE2 advertise Ethernet VLAN (0x0004), the PW will not be
> > >established based on the draft, isn't it?
> > >2. How PE1 and PE2 advertise MTU? If PW agrees on MTU equals to X, and a
> > >frame of size X reaches PE2 from PE1, PE2 will need to insert 4 bytes
> > >for the VLAN tag, and the new frame size may become more than the link
> > >between PE2 and CE2 can handle.
> > >
> > >Any recommendation on solving the issues? One way to solve issue 1 is to
> > >remove the need of two Ethernet types. One way to solve issue 2 is that
> > >PE2 needs to make sure that the MTU it has negotiated with PE1 is 4
> > >bytes smaller than it is actually able to transmit between PE2 and CE2..
> > >
> > >-- Dawn

---

From: Dawn Xie <[email-masked]>
Date: Thu, 14 Nov 2002 14:14:35 -0500

Andy:

Thank you for the response. Still there is confusion:

1. There is an alternative to your suggestion: For frames from CE2 to CE1, PE2
will not strip the VLAN tag and will pass the frame as is to PE1, PE1 will then
strip the VLAN tag; for frames from CE1 to CE2, PE1 will pass the frame to PE2
and PE2 will add the VLAN tag. Two alternatives (your suggestion and this one)
will both work, but totally incompatible. Has PWE3 decided to standardize one, or
either one of them is fine? If either one of them is fine, there will be an
interoperability issue.

2. I think it is fine to signal Ethernet (0x0005) in this case. What I am really
confused is in what situation, do we need to signal Ethernet VLAN (0x0004) type?
Does anyone know any case where Ethernet VLAN type needs to be used, that
otherwise things will break?

Thanks.

-- Dawn

"Andrew G. Malis" wrote:

> >http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01.txt,

---

From: Dawn Xie <[email-masked]>
Date: Thu, 14 Nov 2002 18:08:05 -0500

Andy:

> The alternative in my earlier message is what is being standardized in the

I agree your alternative is a better choice. Is it already included in the draft,
or going to be included? I have difficulty to locate the text in the current
drafts.

> are carried transparently by the PEs.

I understand your explanation which is what the drafts recommendate: use 0x0005
Ethernet type when VLAN tag MAY be carried, use 0x0004 Ethernet VLAN type when VLAN
tag MUST be carried. However, I still don't understand why we need to make this
distinction. The logic to make this distinction is not straightforward. The logic
seems having no relationship with the processing at either PE (whether
strip/add/preserve VLAN tag), instead the logic depends on the end-to-end PW
behavior. Want to hear good justification that a such distinction is absolutely
necessary. Is there a use case that can demonstrate if we do not make this
distinction, things will break?

Thanks.

-- Dawn

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 14 Nov 2002 19:00:49 -0500

Dawn,

The current PWE3 drafts of interest are:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01.txt

>distinction, things will break?

Read the discussion regarding raw vs. tagged mode in the encaps draft and 
see if that explains it for you.  If not, then this would be a good topic 
of discussion next week.

Cheers,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 20 Nov 2002 15:49:11 -0500

Renwei,

You're right about the separation of function between the NSP and the PW.

The INTENT in the Tagged mode is that the PEs are participating in VLAN 
switching and tag rewriting, and the only reason the tag is being 
transmitted is that on some vendor's hardware, it's easier to transmit the 
tag and overwrite it at the egress than to strip it on the ingress and add 
it at the egress.  Otherwise there would be just one encapsulation, and 
it's up to the NSPs to do all switching, stripping, and adding as 
appropriate.  This has been an ongoing discussion the PWE3 email list, and 
the argument of supporting existing HW seems to be winning the day.

You should note that I am not a co-author or editor on the PWE3 Ethernet 
draft, so any comments or suggestions for improvement should be directed to 
the PWE3 list.

Cheers,
Andy

-------

At 11/20/2002 10:28 AM -0800, Renwei Li wrote:

>The VLAN tag stripping on PE2 should be part of PE2 NSP
>functions, and is not standardized by the IETF Martini draft.
>
>If I understand correctly, in the Ethernet mode both Ethernet
>frames and Vlan frames can be transmitted and the Vlan frames can
>have different Vlan tags, but in the Tagged mode only the Vlan
>frames can be transmitted and the Vlan frames MUST have THE SAME
>vlan tag.
>
>I had a look at Appendix A. It doesn't seem to be quite clear.
>What is "C" in the column "Encap on C" in that table? On column
>"Service and Encapsulation on A", the frames are already
>processed by NSP or not? If processed by NSP
>(adding/deleting/overwriting of vlan tags), the frames are
>actually different from the frames received by PHY, and thus does
>it make sense to give such a table? If B does something, the NSP
>can always "undo" it. It is easy to give some examples to show
>that the NSP just does the opposite of what B does.
>
>Renwei

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 21 Nov 2002 08:28:38 -0500

Andrew G. Malis wrote:
> transmitted is that on some vendor's hardware, it's easier to transmit 
> the tag and overwrite it at the egress than to strip it on the ingress 
> and add it at the egress.  Otherwise there would be just one 
> encapsulation, and it's up to the NSPs to do all switching, stripping, 
> and adding as appropriate.  This has been an ongoing discussion the PWE3 
> email list, and the argument of supporting existing HW seems to be 
> winning the day.

Perhaps a better compromise here would be a single ethernet PW type, and an 
associated ethernet-specific interface parameter to define what VLAN 
manipulation needs to be done - similar in concept (though not necessarily in 
form) to the C-bit identifying whether the optional Control Word is present or not.

This gives the same affect we have now, but with perhaps more flexibility, and 
without overloading the PW type. This "tag present" interface parameter would be 
targeted for the relative near term to support the aforementioned HW, with 
_hopes_ that it would eventually go away leaving just the single PW type alone.

Thoughts?

> draft, so any comments or suggestions for improvement should be directed 
> to the PWE3 list.
> 
> Cheers,
> Andy
> 
> -------
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Renwei Li <[email-masked]>
Date: Wed, 20 Nov 2002 10:28:38 -0800

Renwei

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 25 Nov 2002 10:44:16 -0500

Dawn, Mark,

Dawn Xie wrote:

> Mark:
>
> "W. Mark Townsley" wrote:
>
> > Andrew G. Malis wrote:
> > > Renwei,
> > >
> I agree this is a much better compromise than overloading the PW type.
>

Ditto.

regards
cheng-yin

---

From: Dawn Xie <[email-masked]>
Date: Mon, 25 Nov 2002 10:15:53 -0500

Mark:

-- Dawn