Subject: RE: [PWE3] Generic PW - Is there a need?

From: "Gray, Eric" <[email-masked]>
Date: Mon, 30 Jan 2006 13:52:46 -0500

Danny,

	As a clarification question, since it appears that the
intent is to carry multiple different types of traffic using
a generic pseudowire, is the intent to negotiate the carried
packet type, or would this be indicated by code points in the
pseudowire encapsulation format?

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Danny McPherson
--> Sent: Monday, January 30, 2006 12:51 PM
--> To: pwe3 pwe3
--> Subject: [PWE3] Generic PW - Is there a need?
--> 
--> 
--> Folks,
--> We would like to start a discussion on whether the PWE3
--> WG should work on the definition of a generic packet PW.
--> 
--> The driver for this work is threefold:
--> 
--> 1) The need for a PW to support the IPLS work in the L2VPN
--> WG
--> 
--> 2) The need to provide an MPLS PW to satisfy the same need
--> as the IP PW proposed in the L2TPext WG
--> 
--> 3) The need to provide PW to transport MPLS PWs
--> 
--> This type of PW is generally needed where it is required to
--> interconnect ACs with two (actually or potentially) disparate
--> Layer 2 protocols.
--> 
--> Generally one would use a Layer 3 service to provide this,
--> but the use of a Layer 2 service allows greater decoupling
--> between the client and transport networks.
--> 
--> The types of packets that need to be carried over a generic
--> packet PW are know to be (are there others?):
--> 
--> IPv4
--> IPv6
--> IS-IS
--> MPLS
--> Compressed IP
--> 
--> In all cases the payload would be carried over a PW with a CW
--> to allow ECMP suppression and the discrimination of different
--> packet types multiplexied over the PW, for example IPv4 packets
--> and IS-IS protocol packets. Because a CW was used the EoS bit
--> would need to be set in the transport label stack, as well as in
--> the client label stack.
--> 
--> A generic PW would be supported by its own OAM mechanism
--> (VCCV) which would be different from any client OAM
--> mechanism.
--> 
--> One application for the service would be a SP transit domain
--> in which it was desired that there was no interaction between
--> the client and transport network protocols (e.g., MPLS LSP
--> transport services w/no LDP interaction between the transport
--> and client networks).
--> 
--> The work within PWE3 would be a short encapsulation specification
--> and applicability statement.
--> 
--> Where the generic packet PW payload was MPLS the PW would be
--> transparent to the MPLS client layer and not an extension of the
--> MPLS heirachy. This would need to be made clear in the
--> applicability statement.
--> 
--> Do folks here have comments either way on the utility, application
--> and/or requirement for this (i.e., if you're in favor or 
--> against please
--> make it known to the list)?
--> 
--> Thanks!
--> 
--> -danny & Stewart 
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
--> 

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 30 Jan 2006 19:13:09 +0000

>pseudowire encapsulation format?
That is up to the WG to define.

My preverence would be the latter - i.e. to indicate within
the pw encap.

- Stewart

---

From: Danny McPherson <[email-masked]>
Date: Mon, 30 Jan 2006 12:21:57 -0700

> pseudowire encapsulation format?

While the message I sent suggested this MAY be conveyed
via code points in the PW CW, it's something the WG will need
to decide -- as I suspect there are instances where negotiating
the type would be desirable [necessary?].

-danny