Subject: [PWE3] (no subject)

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jul 2011 08:59:58 -0400

Authors,

I still don't like the idean of carrying a full Ethernet header with
fixed 12 bytes of PacketPWEthA PacketPWEthB when really all that is
needed it the Ethertype.

I would like to see this format, along with the PW type 5 for Ethernet
Raw Mode, used for backwards compatibility for the purpose of
supporting old hardware only.  This can then be a fallback for an LSR
that cannot support just putting the EtherType above (in the PW sense,
below in the MPLS sense) the optional control word.

So a type 5 PW would have:

   +-------------------------------+
   |            Client             |
   |          Network Layer        |
   |            packet             |  n octets
   |                               |
   +-------------------------------+
   |                               |
   |          Ethernet             | 14 octets
   |           Header              |
   |               +---------------+
   |               |
   +---------------+---------------+
   |    Optional Control Word      |  4 octets
   +-------------------------------+
   |          PW label             |  4 octets
   +-------------------------------+
   |   Server MPLS Tunnel Label(s) |  n*4 octets (four octets per label
   +-------------------------------+

and a type IANA-TBD PW would have:

   +-------------------------------+
   |            Client             |
   |          Network Layer        |
   |            packet             |  n octets
   |                               |
   +-------------------------------+
   |  EtherType    |                  2 octets
   +---------------+---------------+
   |    Optional Control Word      |  4 octets
   +-------------------------------+
   |          PW label             |  4 octets
   +-------------------------------+
   |   Server MPLS Tunnel Label(s) |  n*4 octets (four octets per label
   +-------------------------------+

I know that this has been discussed and I'm not sure why there are
such objections to offering such an option.  I do know of hardware
that could handle this today, but I don't doubt that there is hardware
that could not handle it.  Going forward if the more efficient
encapaulation is the preferred one, then new hardware will support it.

Curtis

------- Forwarded Message (trimmed)

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF.

	Title           : Packet Pseudowire Encapsulation over an MPLS PSN
	Author(s)       : Stewart Bryant
                          Luca Martini
                          George Swallow
                          Andy Malis
	Filename        : draft-ietf-pwe3-packet-pw-01.txt
	Pages           : 14
	Date            : 2011-07-08

   This document describes a pseudowire mechanism that is used to
   transport a packet service over an MPLS PSN is the case where the
   client LSR and the server PE are co-resident in the same equipment.
   This pseudowire mechanism may be used to carry all of the required
   layer 2 and layer 3 protocols between the pair of client LSRs.

------- End of Forwarded Message

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Jul 2011 14:34:30 +0100

Curtis

One concern that I have is with the need to "reconstruct"
the MAC addresses. For example I understand that
ISIS when running over a pt-pt Ethernet still sends
some packets with the multicast destination addresses.

As soon as we compress the Ethernet header we have to
understand the protocols we are carrying. If we leave them
untouched we can punt the problem to the specification
of the protocols that are being carried.

- Stewart

On 14/07/2011 13:59, Curtis Villamizar wrote:
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jul 2011 10:46:15 -0400

Stewart,

If the point is to carry Etherent, we use RFC4448.  If the purpose is
to carry IP, ICMP and ISIS (probably the only non-IP traffic anyone
cares about today) across a point to point PW, the we only need the
EtherType.  There is no purpose to the layer-2 unicast, multicast, or
broadcat address on a point to point link.  There is no purpose to any
layer-2 address on a point to point link that is not doing layer-2
switching.  ISIS is never forwarded.  Any ISIS traffic is delivered
directly to the other end of the point to point link.

The purpose of a packet PW is a layer-3 PW.  Both ends have to be able
to understand the layer-3 protocol that corresponds to the EtherType.
The L2 addressing in this cases adds nothing, except backwards
compatibility with old silicon.  BTW- ISIS is defined over GFP with no
MAC addresses so it should work over PW with no MAC addresses.

Curtis

In message <[email-masked]>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 14 Jul 2011 11:13:39 -0400

Curtis,

This is the approach that we proposed way back in the -00 version of
our individual draft. We got a lot of flack from HW vendors that they
couldn't implement it on current chipsets.

Cheers,
Andy

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Jul 2011 19:26:50 +0300

Curtis, and all,
I also do not see any sense in inventing fictional MAC addresses just so that we can push them on the PW packet on Tx and ignore them on Rx.

A minor comment: 
If you extend EtherType (2 octets) to 4 octets with all zeroes padding, you have your GRE header.
AFAIK IS-IS runs over GRE quite well. And I do not think adding 16 bits really matters here.

I've proposed this at the  face-to-face PWE3 Session some time ago, but it was not accepted by the authors.

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis
> Villamizar
> Sent: Thursday, July 14, 2011 5:46 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] draft-ietf-pwe3-packet-pw
> 
> 
> Stewart,
> 
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Pseudowire Emulation Edge to
> Edge Working Group of the IETF.
> > >

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jul 2011 14:54:25 -0400

In message <CAK+d4xsOoKvJ+Gn7VM7v38B-a5uimjPZ6Qdcm8JC=[email-masked]>
> couldn't implement it on current chipsets.

Andy,

That is the point of making it optional.  Rather than taking a
limitation of a subset of current chips and carrying an inefficiency
forever.  The default behavior is what most chips can do today.

Some chips can't do any MPLS and some can't do any PW.  Some low end
Ethernet chips of a decade ago couldn't even do IPv4.  We can't limit
IETF work forever based on low end chips of the past.  If we did we
would never have moved forward with MPLS in the late 1990s.

Curtis