Subject: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

From: [email-masked]
Date: Tue, 08 Oct 2002 07:14:04 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Virtual Hierarchical LAN Services
	Author(s)	: A. Sodder
	Filename	: draft-sodder-ppvpn-vhls-00.txt
	Pages		: 12
	Date		: 2002-10-7
	
This draft describes an Ethernet [IEEE-802.3] L2VPN model that 
provides point-to-point and point-to-multipoint Layer 2 data 
communication services using a hierarchical LAN switching 
architecture.  The model is based on a hierarchical MAC frame format. 
Scalability and manageability is achieved by simplifying the control 
plane at the cost of adding functionality to the forwarding plane.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sodder-ppvpn-vhls-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sodder-ppvpn-vhls-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sodder-ppvpn-vhls-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Joris wils <[email-masked]>
Date: Tue, 8 Oct 2002 10:01:05 -0400

Arnold:

I like this draft, because it stays close to Ethernet and 802.1, thus having
good multicast properties where topologies allow.

However, you effectively propose to expand the VLAN ID of the encapsulated
frame, your VHLS-ICW field, from 16 bits to 32 bits.  Thus, the frames
become non-IEEE 802.1 compliant.  I assume you proposed that to get beyond
the 4k VLAN bottleneck imposed by the 16 bit VLAN ID.  However, the "wave"
in the IEEE 802.1 committee and the Metro Ethernet Forum is to get beyond
this bottleneck with VLAN tag stacking and tag translation instead, so that
minimal or no changes will be required to existing equipment.

Would you consider defining the VHLS-ICW field to be 16 bits and for the
L2VPN identifier within to have local significance within the tree headed by
a PE?  Then the encapsulated frames will be 802.1 compliant.

Signalling would be needed between the PEs, not the L2PEs, to exchange the
local L2VPN-ids and the PEs would have to support tag translation.  However,
I think this is less objectionable than trying to change the format of an
802.1 frame.

Joris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 08, 2002 7:14 AM
Cc: [email-masked]
Subject: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Send a message to:
	[email-masked].
In the body type:

---

From: "Sodder, Arnold" <[email-masked]>
Date: Thu, 10 Oct 2002 14:33:13 -0400

Joris:

Thanks for your comments.

My plan does not propose expanding the VLAN Tag to 32 bits.  It proposes
defining a new ethernet-type which describes how an ethernet frame is
encapsulated in another ethernet frame with a control word that defines a
VPN-id.  The proposal is still  802.1 compliant and todays L2 switches will
be able to switch the frame based on its outer MAC address.  As with the
stacked VLAN Tag approach, the L2 switch will need to handle the larger
frame size.

The biggest advantage of my plan is the simplicity at the control plane
where it does not require signaling of a per VC label.  For this the VPN
identifier must be a global number within the network. Another benefit of
this approach is that the MAC address tables on the L2PE and PE exhibit
better scalability.

Hopefully this clears up the need to a new ethernet type and the VHLS-ICW.

Arnold

-----Original Message-----
From: Joris wils [mailto:[email-masked]]
Sent: Tuesday, October 08, 2002 10:01 AM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

Arnold:

Joris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 08, 2002 7:14 AM
Cc: [email-masked]
Subject: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

	

Send a message to:
	[email-masked].
In the body type:

---

From: Du Wenhua <[email-masked]>
Date: Fri, 11 Oct 2002 15:15:46 +0800

Hi,Sodder, Arnold！
[VHLS] say:
   In the above frame formats the CE frame MUST -include- the original
   CRC32 to allow detection of bit errors introduced by devices in the
   service provider network or attached to the service provider network.
   If the L2PE device needs to modify the CE frame it MUST calculate and
   add a new CRC32 to the CE frame.
draft-martini-l2circuit-encap-mpls-03.txt say:
  For simple Ethernet port to port transport, the entire Ethernet frame
  -without- the preamble or FCS is transported as a single packet.
   Would you consider change [VHLS]  as later, just because many vendors surport it now.
  　　　　　　　　　　　　　Du Wenhua
                         [email-masked]
　　　　　　　　　　 　　　　　2002-10-11

---

From: "asodder" <[email-masked]>
Date: Wed, 16 Oct 2002 14:15:27 -0400

-----Original Message-----
From: asodder [mailto:[email-masked]]
Sent: Wednesday, October 16, 2002 1:59 PM
To: 'Norman Finn'
Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

Norm,

I agree that this requirement should be changed to a should.  In doing that
I'll also need to add a bit in the VHLS-ICW that indicates if the inner CRC
is present or not.

Arnold

-----Original Message-----
From: Norman Finn [mailto:[email-masked]]
Sent: Tuesday, October 15, 2002 2:22 PM
To: Sodder, Arnold
Cc: [email-masked]; [email-masked]
Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

Arnold,

Are we talking end-to-end (e.g. enter a box from an Ethernet,
transmit on a tunnel, and out again on an Ethernet)?  If so, this
requirement is totally obsolete.

Such a "don't touch the original CRC" rule was once used by bridges.
But, bridges have been violating this rule since 802.1Q was
introduced.  Today, few 802.1Q-compatible bridges keep the CRC
intact end-to-end, whether actually doing 802.1Q or not.

Furthermore, for many kinds of service, especially those in which
different Customer VLANs are used to tell the Service Provider which
"tunnel" to which other site a frame should be sent on, it may be
important to change part of the frame.  For example, the 802.1Q tag
may need to change.  Not only that, but as currently implemented in
many MAN Provider networks, a customer's BPDUs may have their MAC
addresses altered in order to get them to pass transparently through
a network of Provider bridges.

There do exist algorithms that the very careful implementor may use
so that, if a frame is altered, a delta to the CRC can be computed
and XORed into the original CRC.  This allows the frame to be
changed without losing all of the benefit an end-to-end CRC.  It
would be much better to specify a SHOULD for this technique, rather
than prohibiting a class of very useful operations based on a
behavior that is obsolete.

-- Norm

"Sodder, Arnold" wrote:
>
> This requirement comes from an operations standpoint.
>
> Consider the case where a CE device is creating incorrect data in the
frame
> body and creating a CRC based on the incorrect data.  When the frame is
> received by the L2PE device the CRC will be checked and found to be good,
> even though the data in the frame is bad.  When the total frame (including
> the CRC) is delivered by the service providers network there is a trace
left
> as to where the error was created.  In the case where the CRC is stripped,
> detecting the error becomes difficult.
>
> Thus when the original customers frame is not modified this error can be
> detected.  In the case where the customers frame is modified the error
> cannot be detected.  In general there should be no need for the L2PE
device
> to modify the frame.
>
> For this reason I have choosen to carry the complete frame (including CRC)
> over the service providers network.  Having an option is possible but
being
> an implementor I'd like to keep the PE and L2PE devices as simple as
> possible and so choose to not support one.
>
> Hopefully this addresses your question.
>
> Arnold
>
> ---------------------------
>
> Hi,Sodder, Arnold,
>
> [VHLS] say:
>
> In the above frame formats the CE frame MUST -include- the original CRC32
to
> allow detection of bit errors introduced by devices in the  service
provider
> network or attached to the service provider network.  If the L2PE device
> needs to modify the CE frame it MUST calculate and add a new CRC32 to the
CE
> frame.
> Would you consider change [VHLS] as later, just because many vendors
surport
> it now.
>
> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
> Du Wenhua [email-masked] <mailto:[email-masked]>
> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ ¡¡¡¡¡¡¡¡¡¡2002-10-11

---
You are currently subscribed to ppvpn as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 17 Oct 2002 09:54:59 -0400

Eric,

	See below...

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, October 17, 2002 9:21 AM
> To: [email-masked]
> Cc: [email-masked]
> Arnold> You mentioned that this is a PWE3 issue, however I was 
> Arnold> under the (maybe incorrect) assumption that the outer 
> Arnold> mac frame follows the rules as specified in the PWE3 
> Arnold> draft for ethernet-over-IP/MPLS.  If this is incorrect 
> Arnold> do let me know.  The inner mac frame is different but
> Arnold> should be transported as data in the outer mac frame.
> 
> If you want to argue that the ethernet-over-IP/MPLS service begins 
> after the MAC-in-MAC encaps has been done, and ends before the 
> corresponding decaps has been done, then you could argue that the 
> rules for the MAC-in-MAC encaps are outside PWE3's scope.
> 
> The rules for MAC-in-MAC encapsulation would then be totally outside
> the scope of the IETF, I believe, as there is  no IP or MPLS involved.
> The proposal would have to be taken to IEEE.
> 
> This might be a good way to approach it, as the hierarchy would then be
> done in the  layer 2 network using layer  2 techniques, and in  the 
> MPLS/IP layer one can just do "ordinary" VPLS without need for further 
> hierarchy.
> 

This seems very reasonable.  In fact, I can't see how making
L2 (MAC) re-encapsulation part of something the IETF cares
about could make sense...

> ...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]

---

From: Masato Ando <[email-masked]>
Date: Wed, 23 Oct 2002 15:02:16 +0900

Sodder

(1)VHLS Draft say
>L2PE devices are assigned a single MAC address.  When an L2PE device 
>has two uplinks to different PE devices the same MAC address is used 
In my opinion, L2PE devices can be assigned one or
more configurable addresses. This allows you to
assign different MAC addresses on each downlink
port on L2PE devices. You can use this type of assignment
to control traffic by MAC address filtering.

For example, it is supposed that you build a nationwide
IX by L2 network and the IX supports two services,
regional exchange and nationwide exchange. You can
provide this service by L2PE MAC address filtering
with MAC addresses on downlink port.

Tier1                                                             Tier1
ISP(A)--+    ..........         ........          ..........   +--ISP(C)
      L2PE---.Regional.---MAC---.nation. ---MAC---.Regional.--L2PE   
Tier2   |    .  bb(X) .  Filter .  bb  .   Filter .  bb(Y) .   |  Tier2
ISP(B)--+    ..........         ........          ..........   +--ISP(D)

*Tier1 ISPs MAC frame can pass MAC Filter.
*Tier2 ISPs MAC frame cannot pass MAC Filter.

PSTN(iSCSI, etc)-GW service is other example.
This requires location base access control and
MAC address filtering is also useful for this.

(2) About hierachical MAC assignment.
I support your idea about L2PE MAC.
The other advantage on L2PE MAC is capability of hierarchical MAC assignment.

West coast switchs L2PE MAC address=(aa:aa:**:**:**)
  San Francisco area switches L2PE MAC address=(aa:aa:aa:**:**)
    area 1 switches L2PE MAC address=(aa:aa:aa:aa:**)
    area 2 switches L2PE MAC address=(aa:aa:aa:bb:**)
  Los Angeles ara switches L2PE MAC address=(aa:aa:bb:**:**)
East coast switches L2PE MAC address=(bb:bb:**:**:**)
  New York area switches L2PE MAC address=(bb:bb:aa:**:**)

You can use MAC address filtering with a mask for avoiding loop traffic.
You can use aggregate MAC bridging also.

(3)I have same idea as VHLS.
I call this technology "Ethernet over Ethernet(EoE)" or "Mac on mac".
I made a similar presentation to the JANOG10 in Tokyo on this July 2002.
You can get the presentation form  
http://www.janog.gr.jp/meeting/janog10/pdf/janog10-l2-ando.pdf
It is written in Japanese, but you can understand page 16,17 figure.
I have another detail documentation written in Japanese.
If you want I will transrate the document to English and send it to you.
I want to contribute your draft.

(4)
I belong to one of the largest nation wide ethernet VPN provider in Japan.
In our company, we are using QinQ(VMAN) technology.
Im looking for new solution for next generation network to solve some
problems.
I like VPLS.But I dont want to use VPLS.
Because it has full mesh LSP broadcast problem which wastes backbone capacity.
("H"VPLS is not perfect solution, core needs full mesh LSP anyway)
The point of broadcast capability, I think your idea is superior to VPLS.

--
Masato Ando <[email-masked]>  03-4431-6630

---

From: "Mancour, Tim" <[email-masked]>
Date: Wed, 23 Oct 2002 11:11:10 -0400

Masato,

In reference to 1 below - I believe that we can use 
the VPN identifier, instead of a MAC address, to 
provide the filtering capability that you are 
requesting.

The service provider could partition the VPN space 
into a nation space (e.g. 1..N) and separate set of
regional spaces (e.g. N+1..16777215). The filtering
function would then pass traffic that contains a
VPN identifier that is a member of the national 
space and block all other traffic.

Regards,
Tim Mancour

-----Original Message-----
From: Masato Ando [mailto:[email-masked]]
Sent: Wednesday, October 23, 2002 2:02 AM
To: [email-masked]
Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

Sodder

(1)VHLS Draft say

Tier1                                                             Tier1

(2) About hierachical MAC assignment.
I support your idea about L2PE MAC.
The other advantage on L2PE MAC is capability of hierarchical MAC
assignment.

(4)
Because it has full mesh LSP broadcast problem which wastes backbone
capacity.