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

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 1 Feb 2006 10:24:22 +0200

Andy (and all)
Lots of thanks for a prompt response.
 
I agree with you that adapting the 2684 approach would be quite
straightforward.
 
I would also like to note that, IMHO, such a generic packet PW would not,
per se, solve the problem of carrying meaningful "IP pseudo-wires" between
disparate Layer 2 attachment circuits (assuming that this is one of the
objectives pursued). The following points needs special attention

1.	ARP: mediation vs. translation 

*	The latter could operate in the data plane but seems to be
restricted to the case when the two ACs represent interfaces of the same
type (P2P, NMBA or LAN)

*	FRF8  can be adapted where where applicable
*	IPCP translation for PPP-based AC requires special consideration

*	The former can operate between interfaces of different types but
seems to involve dependency on the control plane (see
draft-ietf-l2vpn-arp-mediation-04)

2.	IGP operation: forcing LAN interface to P2P operation should be
considered (e.g., as in draft-ietf-isis-igp-p2p-over-lan-05.txt)

Hopefully these notes will be useful.
 
Regards,
                    Sasha

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, January 31, 2006 7:25 PM
To: Sasha Vainshtein
Cc: 'Stewart Bryant'; Danny McPherson (E-mail);
[email-masked]; [email-masked]
Subject: RE: [PWE3] Generic PW - Is there a need?

Sasha,

Yes, I was about to send out an email with the same conclusion.  It should
be relatively straightforward to adapt one of these two (probably 2684,
given its header word alignment vs. header byte alignment in 2427) for this
purpose.  I've always been of the opinion that we should have included a PID
in the MPLS header way back when, but that was the minority opinion at the
time.

Cheers,
Andy

-------------

At 1/31/2006 06:24 PM +0200, Sasha Vainshtein wrote:

Stewart, Danny and all,
Are we possibly speaking about something like "multiprotocol interconnect
over PW" similar to multiprotocol interconnect over FR (RFC 2427/STD 55) or
multiprotocol interconnect over AAL5 (RFC 2684)? 
 
Regards,
                    Sasha

-----Original Message-----

From: Stewart Bryant [  <mailto:[email-masked]>
mailto:[email-masked]]

Sent: Tuesday, January 31, 2006 4:54 PM

To: [email-masked]

Cc: [email-masked]

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

[email-masked] <mailto:[email-masked]>  wrote:

Danny,

It is not entirely clear to me what the proposal you are making is

or

the motivation behind it.

Are you stating that to support IPLS, transport of MPLS PWs over a

PW

etc. that a new control word format/encapsulation is required and

this

document will specify such a control word format?  If so, what

is

deficient/missing in the current control word formats?

You need a standard method to multiplex a number of protocols over the 

PW. It's not always the case that the only protocol that needs to be

carried is IP. You might want to carry IP + ISIS, or IP + MPLS etc.

We could do this by defining a canonical data-link type, or by

adding a PID to the PW. How we do it is a WG decision.

Or is it to just essentially combine several PW types into a

single

document rather than a document per PW type?

No, we think that there is a need to carry multiple types over the same PW.

- Stewart

Or am I completely missing the point?

Thanks

Ben

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 2 Feb 2006 11:48:04 +0200

Himanshu and all,
I see a certain problem with your proposal to limit the work in PWE3 to
 
<quote>

defining the PW encapsulation and setup of the PW

<end quote>
 
The problem is that, until now, the PWE3 specs commonly included not just
the encapsulation format but also some description of the encap/decap
(a.k.a. PW adaptation) procedures, e.g., see Section 4 "Generic Procedures"
of draft-ietf-pwe3-ethernet-encap-11.txt, Section 7.5 "PW Packet Processing"
in draft-ietf-pwe3-frame-relay-06.txt etc.
 
Can we define any such procedures for a "generic packet PW"? I doubt that
this can be done because:

1.	Discrimination of the types of packets coming from the local CE is
AC-specific
2.	Specific examples of "generic packet PWs" would presumably pass only
some of the  packets received from the local CE (based on their type)  while
peering with the local CE for some other ones (this is what an IP PW with
ARP mediation does, right?) And, when it comes to setup, the types of
packets that are passed probably has to be coordinated between the two
endpoints...

I am also not sure if the "generic packet PW" would be the right thing for
pre-wiring PW segments between S-PEs for MS-PWs because IMHO S-PEs should
not add their own PW headers while "generic packet PWs presumably require
some header to carry specific packet types.
 
Regards,
                    Sasha

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]]
Sent: Wednesday, February 01, 2006 5:09 PM
To: Sasha Vainshtein; Andrew G. Malis
Cc: [email-masked]; Danny McPherson (E-mail); [email-masked];
Stewart Bryant

Hi Sasha,
I believe the work in PWE3 would be limited to defining the PW encapsulation
and
setup of the PW. The interworking/arp-mediation or translation type of work
is being
pursued in L2VPN WG. The current L2VPN drafts (IPLS, ARP-MEDIATION) uses
IP L2 Transport PW (i.e. IP PW). This constrains those drafts to support
IS-IS (granted
that proper MAC learning mechanisms would have to be defined along with isis
over pt-pt).
 
The generic PW mechanisms paves way for other possible functionalities such
as,
1) pre-wiring PWs (especially between S-PEs for MS-PWs)
2) muxing diff types of PWs into a PW (as long as there is something else in
the packet to demux)
3) backhauling PWs over infrastructure (i.e. generic) PW (using PW in PW)
etc etc
 
/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sasha
Vainshtein
Sent: Wednesday, February 01, 2006 3:24 AM
To: 'Andrew G. Malis'
Cc: [email-masked]; Danny McPherson (E-mail); [email-masked];
'Stewart Bryant'
Subject: RE: [PWE3] Generic PW - Is there a need?

Andy (and all)

 
Regards,
                    Sasha

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, January 31, 2006 7:25 PM
To: Sasha Vainshtein
Cc: 'Stewart Bryant'; Danny McPherson (E-mail);

Sasha,

Cheers,
Andy

-------------

Stewart, Danny and all,
 
Regards,
                    Sasha

-----Original Message-----

Cc: [email-masked]

Danny,

or

PW

this

is

  

single

  

- Stewart

Thanks

Ben

---

From: "Yaakov Stein" <[email-masked]>
Date: Fri, 3 Feb 2006 11:21:37 +0200

That raises an important question. Are we going to handle
the interworking of OAM between this new generic
PW type and existing types in the PWE3 WG, and if so,
how? At present, the delimitation has been that PWE3
only handles the like-to-like case, while the L2VPN WG
(and the MFA) have taken on the definition of the any2any
case.  I think we need some guidance from the chairs/AD
on this issue if we are to proceed forward with having
OAM functions defined correctly for this new PW type.

The main issue is to reduce the effort in interworking in the usual PWE
sense.
 
We have to carefully consider mechanisms based on extended PID
or RFC2427, which may require intricate translations
(Ethertype - NLPID - SNAP - etc).
 
The second consideration is for end-to-end VCCV-based OAM
to function correctly. This should automatically be OK
unless we deviate from PWE work here.
 
All other considerations, such as message mapping 
and splicing of PWs of different types,
should be tertiary in importance.
 
Y(J)S

---

From: Luca Martini <[email-masked]>
Date: Fri, 10 Feb 2006 15:37:05 -0700

Danny McPherson wrote:
>
> Folks,
> We would like to start a discussion on whether the PWE3
> WG should work on the definition of a generic packet PW.
Danny,

I believe that there is a need for the IP PW that we originally defined, 
However I have a problem with defining a true multiprotocol PW.
PWE3 WG has an existing architecture , and within this architecture we 
do not have a PID in the PW packet. This was a choice made in the 
beginning to allow hardware implementations to be simpler. In MPLS we 
can bind any meaning we want to a label. So , for example  we 
dynamically bind  the meaning "ethernet packet" to label 44. Then we 
know that is we receive label 44 we must decode an ethernet header.
So a multiprotocol PW is not simply another type of PW , it is a change 
in the pwe3 architecture to move some of the control plane functionality 
to the dataplane.
( Note that the VCCV associated channel is not for transport of the 
payload data itself but just for OAM purposes.... otherwise we'll have 
to recursively define another associated channel. etc. etc.)

An MPLS PW is also another unclear proposition. First the MPLS WG would 
have to review such a pw type. An MPLS PW should not be used to change 
the MPLS architecture. For example use MPLS labels for addressing 
purposes, global labels .etc.

I an already see a bunch of arguments that where settled when MPLS was 
designed arise again here. ex. the MPLS PID.
Having said that, the following PW fit perfectly well into our architecture:

- IP PW
- CLNS PW ( ISIS )

Note that the IP in IP case , the MPLS in  IP, and the IP in MPLS and 
the MPLS in MPLS cases have already been solved outside this WG without 
changing the rules on the original transported protocol. ( for example 
IP in IP doe not mean that now IP addresses are labels ... )

In summary , we should not be using PWE3 to change existing protocol 
architectures. If we need to change those architectures , then we should 
work in the appropriate WG on new versions of those protocols.

Thanks.
Luca

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 13 Feb 2006 19:07:05 +0200

Scott,
The charter could probably say something like:

"Investigate potential requirements for multiprotocol
interconnect over pseud-wires and, if required, define
the corresponding encapsulation formats, procedures
and applicability statements."

Does it make sense?

Regards,
			Sasha

> From: Scott W Brim [mailto:[email-masked]]
> Sent: Monday, February 13, 2006 6:53 PM
> To: Sasha Vainshtein
> Cc: 'Florin Balus'; Luca Martini; pwe3 pwe3; Danny McPherson
> On 02/13/2006 11:41 AM, Sasha Vainshtein allegedly wrote:
> > So maybe we should start with a more accurate definition of 
> the problem
> > space in order to understand whether it can and should be 
> covered by a
> > single
> > solution.
> 
> What would you say in the charter, then?
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 15 Feb 2006 09:41:50 -0500

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Florin Balus
> Sent: Monday, February 13, 2006 10:07 AM
[snipped]
> I believe there is a need for a multiprotocol PW as we want some flows
> to share really the same path: i.e. I want the IP data 
> packets to follow
> the same path as the IS-IS protocol that provides the routing 
> exchanges.

Florin,

Creating multi-protocol PWs is not the only solution to this problem. First, Service Providers could avoid any ECMP problem by using RSVP-TE to set up Transport LSPs. Second, in the case of LDP LSPs and ECMP, you could use VCCV and correlate the status of PWs that belong together.

To explain this last point: the only problem with mapping IS-IS and IP Data to separate PWs is that it might cause a situation where one PW is down while the other is not, isn't it? However, instead of carrying all traffic over one PW, the two PEs could also use separate PWs and use VCCV to monitor the status of both. Upon failure of one, they would block transmisson over the other.

In the particular case of IP and IS-IS, I actually don't have a problem with creating a solution for carrying both over the same PW. I would consider it a consequnce of the peculiarities of IPLS. However, I don't agree that this corner case justifies the creation of generic multi-protocol PWs. Not that there is anything fundamentally wrong with multi-protocol PWs, but I agree with Luca that it is a complete departure from the existing approach.

Also, I think that eventually we might have other cases where we need to deal with ECMP and where multi-protocol PW don't help. E.g. I believe that it would make sense to create multipoint PWs to make Ethernet emulation more efficient. This idea has been brought up in the past, but the concern was that Spanning Tree BPDUs could follow a different route than the payload, potentially creating a black hole. I believe we can avoid that by using VCCV and correlate the status of all PWs involved. Obviously, multi-protocol PWs wouldn't work in that case.

Peter

> There could be also simplifications related to the fact that an
> enterprise customer will not need to buy different PWs for each
> encapsulation if the resulted connections go between the same 2 sites:
> IPv4, IPv6, IS-IS etc... Think also about PWs as uplinks for 
> Managed CE
> <Virtual> Routing not only just for ACs...
>

---

From: "Florin Balus" <[email-masked]>
Date: Wed, 15 Feb 2006 10:13:42 -0500

Peter,

The fact that solutions to correlate PWs might be available do not
necessarily justify the trouble. Consider that: 

- for a (Enterprise/Carrier) or wholesale/carrier of carrier
relationship the PW Virtual Circuit (VC) starts in one provider network
(customer) and then continues in the wholesaler (transport) domain. The
"customer SP" can't control what is going on in the transport domain so
this creates issues for correlation etc... (it's not just ECMP existing
in the transport domain - consider the possibility of MS-PWs,
loadsharing of PWs across Tunnel Groups etc). These issues may arise
even for the same SP when it comes to Metro guys dictating to the WAN
group etc...

Also I don't see why bother to build n*connectivity (PWs) if you just
need to connect the same 2 endpoints. I thought that was the reason for
the 4 bits nibble + channel ID? Is there anything that breaks? If 0001
was reserved for OAM maybe we can use 0002 in the nibble to indicate
generic PWs/PID presence...

By the way in the above reply, I am considering that PWs (or maybe we
should call them MPLS VCs) will go down to the CE device - I see value
in a common service layer down to the end user/metro service provider
(CoC scenario) ...

For Ethernet link, having a PW VC as a p2p uplink on the CE will also
transform the IWK stuff from a complex mediation exercise to a simple
translation to ATM/FR ACs.. 

>From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
>Sent: Wednesday, February 15, 2006 9:42 AM
>To: Balus, Florin [CAR:6955:EXCH]; Luca Martini; Danny McPherson
>Cc: pwe3 pwe3
>> to share really the same path: i.e. I want the IP data packets to 
>> follow the same path as the IS-IS protocol that provides the routing
>> exchanges.
>
>Florin,
>
>Creating multi-protocol PWs is not the only solution to this 
>problem. First, Service Providers could avoid any ECMP problem 
>by using RSVP-TE to set up Transport LSPs. Second, in the case 
>of LDP LSPs and ECMP, you could use VCCV and correlate the 
>status of PWs that belong together.
>
>To explain this last point: the only problem with mapping 
>IS-IS and IP Data to separate PWs is that it might cause a 
>situation where one PW is down while the other is not, isn't 
>it? However, instead of carrying all traffic over one PW, the 
>two PEs could also use separate PWs and use VCCV to monitor 
>the status of both. Upon failure of one, they would block 
>transmisson over the other.
>
>In the particular case of IP and IS-IS, I actually don't have 
>a problem with creating a solution for carrying both over the 
>same PW. I would consider it a consequnce of the peculiarities 
>of IPLS. However, I don't agree that this corner case 
>justifies the creation of generic multi-protocol PWs. Not that 
>there is anything fundamentally wrong with multi-protocol PWs, 
>but I agree with Luca that it is a complete departure from the 
>existing approach.
>
>Also, I think that eventually we might have other cases where 
>we need to deal with ECMP and where multi-protocol PW don't 
>help. E.g. I believe that it would make sense to create 
>multipoint PWs to make Ethernet emulation more efficient. This 
>idea has been brought up in the past, but the concern was that 
>Spanning Tree BPDUs could follow a different route than the 
>payload, potentially creating a black hole. I believe we can 
>avoid that by using VCCV and correlate the status of all PWs 
>involved. Obviously, multi-protocol PWs wouldn't work in that case.
>
>Peter
>
>
>
>
>
>
>> IPv4, IPv6, IS-IS etc... Think also about PWs as uplinks for Managed 
>> CE <Virtual> Routing not only just for ACs...
>>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 15 Feb 2006 13:43:09 -0500

> Sent: Wednesday, February 15, 2006 10:14 AM
> To: Busschbach, Peter B (Peter); Luca Martini; Danny McPherson
> Cc: pwe3 pwe3

I don't understand the problem you see. You are referring to a case where one SP's traffic is carried through another's transport domain. I think we both agree that a single PW, thanks to the Control Word with all-zero first nibble, will follow a deterministic path even in the presence of ECMP.

Now consider a service that for some reason needs to be inversely multiplexed across two or more PWs (as in the IP + IS-IS case). My proposal was that the two PEs (the two T-PEs in the case of MS-PWs) correlate the PW state between the set of PWs and consider the whole set down in the case of a failure on one PW. I don't understand why ECMP, load sharing and/or MS-PW creation in the transport network has any impact.

> generic PWs/PID presence...

It is a consequence of the PWE architecture. Consider a case where two PEs have both ATM and Ethernet Attachment Circuits. Acoording to the PW specs, the PEs need to set up separate PEs, some of type Ethernet and some of type ATM.

Would it have been possible to define a multi-protocol PW that was able to carry ATM as well as Ethernet traffic over a single PW? Yes, of course. But that was not what the WG decided to do. As I wrote in my previous email: "Not that there is anything fundamentally wrong with multi-protocol PWs, but I agree with Luca that it is a complete departure from the existing approach."

> translation to ATM/FR ACs.. 

I don't understand the scenario. Are you talking about an Ethernet AC on one side that needs to be interworked with a FR/ATM AC on the other side of the MPLS core, or are you talking about a CE that maps both Ethernet interfaces and ATM interfaces onto a single PW?

---

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 17 Feb 2006 19:09:32 +0200

Luca and all,
Please see a couple of comments inline below.

Regards,
                 Sasha

-----Original Message-----
From: Luca Martini
To: Sasha Vainshtein
Cc: 'Florin Balus '; 'pwe3 pwe3 '; 'Danny McPherson '
Sent: 2/17/2006 7:01 PM
Subject: Re: [PWE3] Generic PW - Is there a need?

Yes that is what florin proposed at some point.
However that changes the architecture, and does not really share the 
same path.
 
[Sasha] If it doesn't then it is equally unsuitable to carry VCCV IMHO.

The associated channel might not be HW switched. 
[Sasha] I am not sure I follow you.
( and it is not meant to transport user routing information )
[Sasha] Well, originally it has not been specified at all.
[Sasha] Then it has been added to carry IP traffic (needed for VCCV).
[Sasha] So why not to extend it to carry other types of traffic?

However , I have not seen much market demand for this or IP PWs I doubt 
it worth the effort. Just use a normal L2 PW if ISIS is needed.

[Sasha] I do not know if the market requires this functionality or not.
[Sasha] But this seems to be a different issue altogether.

Luca

Sasha Vainshtein wrote:
> Luca, Florin and all,
> Sorry for a possibly naive question, but did anybody consider
> carrying IS-IS along an IP PW using the Associated Channel mechanism
> defined in draft-ietf-pwe3-cw-06.txt and allocating a dedicated
Channel
> Type in the appropriate IANA registry?
>
> In this way:
> - fate-sharing of IP and IS-IS packets along the PW would be
guaranteed
> - potential MS-PW issues could be handled in a generic manner
> - performance would not be an issue (presumably IS-IS traffic is
>   negligible when compared with the IP traffic)
> - It would be possible (and easy) for a pair of PEs to negotiate
>   specific Associated Channel Type(s) they support during the setup
>   by adding an appropriate Interface Parameter sub-TLV thus making it
>   a scalable approach (at least,as long as we are talking about some
>   control protocols accompanying data and not about true "data"
>   multi-protocol.
>
> It would be interesting to see which use case for the generic packet
PW
> would remain unresolved.
> My 2 c.
> From: Luca Martini
> To: Florin Balus
> Cc: pwe3 pwe3; Danny McPherson
> Sent: 2/16/2006 8:53 PM
> Florin Balus wrote:
> follow
> CE
> Are you talking about having some kind of layer3 PW ?
> what next ? a TCP PW , an UDP PW , and a Rip PW ?
>
> The IS-IS case is a black sheep indeed , as we are using an non IP 
> protocol to route IP.
> As I explained before the answer for that is to use the true layer2 
> protocol, not an IP PW.
>
> Luca
>

---

From: "Florin Balus" <[email-masked]>
Date: Tue, 21 Feb 2006 10:17:39 -0500

Luca,

So from what you are saying below in your opinion PW/MPLS is not going
to be the service interface in the CE router? In other words for L2
Services there will always be Ethernet (or other <mix of> native) ACs at
both sides of the Virtual Circuit. I appreciate your insight. I am also
interested to hear back from Service Providers (and the PWE3 WG) in
general one more time though... 

Myself I see values to have a common service layer end to end, instead
of translating encapsulations, OAM and other native procedures (e.g.
ARP) between different types of ACs or even AC and PW uplink. Also we
should have the option of building a common L2 path for multiple related
protocols (IP/IS-IS) instead of dictating one VC per protocol/having to
worry about making sure the PW paths/faults are correlated. 

On the other hand, if we are sure PW/MPLS architecture is not the right
way of getting there I am opened to look to alternatives. 

Regards,
Florin 

>From: Luca Martini [mailto:[email-masked]]
>Sent: Monday, February 20, 2006 11:26 AM
>To: Balus, Florin [CAR:6955:EXCH]
>Cc: Sasha Vainshtein; Busschbach, Peter B (Peter); pwe3 pwe3;
>Danny McPherson
>This idea has been around for 8 years. Since when MPLS was first 
>noticed , the first thing I heard from my marketing folks at the time 
>was "Can we sell an MPLS UNI ? "
>
>Over the years it became apparent that the application is routed  IP, 
>and the L2 technology between the CE and the PE does not really matter 
>all that much. The interworking cases that spawned this IP PW 
>technology where justified by either migration scenarios, or regulatory

>rules that somebody was attempting to circumvent.
>The example you give below is very much like a frame relay pvc. So why 
>would be create new protocols , or modify existing one to fit an 
>application  that is well served by existing technology ?
>I believe that the IP PW has it's application to facilitate 
>interworking 
>, but I doubt it would be useful as a PW MPLS UNI .
>
>Luca
>
>
>
>Florin Balus wrote:
>> Sasha,
>> That is what we proposed in the IP PW draft - see
>enclosed... Granted
>> we need to update the encoding of the fields to match the
>evolution of
>> the CW draft.
>>
>> Luca, Peter,
>> Replying to your comments: on top of the regular native AC use case 
>> (ETH to ATM/FR etc) with an IP PW in the middle I thought people 
>> wanted with the generic PW initiative to push the PW encapsulation 
>> down to the CE router in either an entreprise or a Carrier
>of Carrier
>> use case. That is to benefit from a common service layer end to end: 
>> no more translation between native AC and PW will benefit
>the OAM etc,
>> ARP mediation will go away etc...
>>
>> The topology will look something like this:
>>
>> CE1 (SP1/Entreprise) PW uplink - SS1-PW AC on PE2 (w/ Seg PWs in SP2
>> netw) -- PSN (SP2) -- PE3 (w/ Seg PWs - SP2) SS3-PW AC - PW
>Uplink on
>> CE4 (SP1/Entreprise)
>>
>> CE1 and CE4 may be routers or even PEs in their own network
>and do not
>> need to have control plane exchanges with PE2/PE3 (although they may 
>> run E-LDP). They are just getting a L2 VC based on a PW/LSP format 
>> from SP1 and they can do whatever they want with it for a true data
>> VC: e.g. run
>> IP+IS-IS on top of it if they want to instead of buying multiple PWs
>> from SP1 and worry about fate sharing etc (all the stuff that Sasha 
>> mentioned below).
>>
>> I know this is against conventional wisdom of this times but maybe 
>> worth investigating if people see value in considering this use case.
>>
>>
>>
>>   
>>> From: Sasha Vainshtein [mailto:[email-masked]]
>>> Sent: Friday, February 17, 2006 2:55 AM
>>> To: 'Luca Martini '; Balus, Florin [CAR:6955:EXCH]
>>> Cc: 'pwe3 pwe3 '; 'Danny McPherson '

>>> Channel Type in the appropriate IANA registry?
>>>
>>> In this way:

>>> PW would remain unresolved.
>>>
>>> My 2 c.
>>>
>>> Regards,
>>>                 Sasha
>>>
>>>
>>>
>>>> I believe there is a need for a multiprotocol PW as we want
>>>>       
>>> some flows
>>>     
>>>> encapsulation if the resulted connections go between the
>>>>       
>>> same 2 sites:
>>>     
>>> protocol to route IP. As I explained before the answer for that is 
>>> to use the true layer2 protocol, not an IP PW.
>>>
>>> Luca
>>>
>---------------------------------------------------------------------
>>> ---
>>>
>>>
>>>
>>>  PWE3 Working Group
>>>  Internet Draft
>>>  Expires: April 2005
>>>
>>>  Himanshu Shah                                   Florin Balus
>>>  Ciena Networks                                  Mike Loomis
>>> 								
> Jeff Sugimoto                                                
>>> 								
> Nortel Networks
>>>  Mustapha Aissaoui						
>	 
>>>  Alcatel    						
> Mircea Pisica
>>>  								 Infonet
>>>
>>>                                                  October 2004
>>>
>>>
>>>                        IP Pseudowire Encapsulation
>>>
>>>                   draft-balus-pwe3-ip-pseudowire-01.txt
>>>
>>>
>>>  Status of this Memo
>>>
>>>     By submitting this Internet-Draft, I certify that any
>applicable
>>>     patent or other IPR claims of which I am aware have
>been disclosed,
>>>     or will be disclosed, and any of which I become aware will be 
>>>     disclosed, in accordance with RFC 3668.
>>>
>>>     This document is an Internet-Draft and is in full
>conformance with
>>>     all provisions of Section 10 of RFC2026.
>>>     Internet-Drafts are working documents of the Internet
>Engineering
>>>     Task Force (IETF), its areas, and its working groups.  Note that
>>>     other groups may also distribute working documents as Internet-
>>>     Drafts.
>>>
>>>     Internet-Drafts are draft documents valid for a maximum of six
>>>     months and may be updated, replaced, or obsoleted by
>other documents
>>>     at any time.  It is inappropriate to use Internet-Drafts as
>>>     reference material or to cite them other than as "work in 
>>> progress."
>>>
>>>     The list of current Internet-Drafts can be accessed at
>>>          http://www.ietf.org/ietf/1id-abstracts.txt
>>>     The list of Internet-Draft Shadow Directories can be accessed at
>>>          http://www.ietf.org/shadow.html.
>>>
>>>  Abstract
>>>
>>>     This document proposes a PW encapsulation specific to
>IP packets,
>>>     the IP Pseudowire, following the architectural
>principles defined in
>>>     [PWE3 Architecture]. This proposal introduces an
>optional CW for IP
>>>     encapsulation. Note that when the inclusion of a
>control word is not
>>>     negotiated, the IP PW uses the encapsulation described in 
>>> [RFC3032].
>>>
>>>  Balus et.al            Expires Jan 2005                     Page 1
>
>>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires 
>January 2005
>>>
>>>  Table of Contents
>>>
>>>  1.    Conventions used in this 
>document.............................2
>>>  2.    Introduction and 
>Requirements.................................2
>>>  3.    Reference 
>Model...............................................3
>>>  4.    IP PW 
>Encapsulation...........................................4
>>>  5.    Support for PW 
>OAM............................................5
>>>  6.    Support for non-IP 
>payload....................................6
>>>  7.    Signaling of the IP 
>PW........................................7
>>>  8.    Security 
>Considerations.......................................7
>>>  9.	 Changes from the previous version.............................7
>>>  10.   
>Acknowledgements..............................................7
>>>  11.   Intellectual Property Rights 
>Notices..........................7
>>>  12.   
>References....................................................7
>>>  13.   Authors' 
>Addresses............................................8
>>>
>>>  1. Conventions used in this document
>>>     The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
>"SHALL NOT",
>>>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>>>     this document are to be interpreted as described in RFC 2119
>>>
>>>  2. Introduction and Requirements
>>>
>>>     This document defines the encapsulation and the
>motivators for using an
>>>     optional CW for IP pseudowire. In this model, the AC
>circuits are
>>>     terminated at each PE, and only the IP payload is
>transported across the
>>>     PSN using a PW header. Two solutions using the IP PW
>encapsulation
>>>     are described in [ARP Mediation] and [IPLS]. Multi-hop
>pseudowire could be
>>>     also another application for the concepts described in this 
>>> draft.
>>>     
>>>     The requirements for an IP PW vary depending on the
>behavior expected
>>>     from end user application, and sometimes by how much
>the layer 2 media
>>>     characteristics were used to achieve said behaviour.
>For instance,
>>>     deterministic path forwarding, connection tracing,
>discard priorities
>>>     and congestion notifications are typical L2 attributes,
>which often
>>>     benefit a native, end-to-end service encapsulated
>within it. In the
>>>     context of an IP PW, these characteristics may need to
>be reflected to
>>>     preserve current SLAs.
>>>
>>>     Specifically concerning deterministic path forwarding
>in IP/MPLS networks,
>>>     when no CW is used, the IP PW uses the encapsulation
>described in
>>>     [RFC3032], virtually indistiguishable from the IP over
>MPLS encapsulation,
>>>     mapped based on the IP FEC. Current ECMP algorithms
>used by the MPLS LSRs
>>>     may perform deep packet inspection and loadshare the IP
>over MPLS packets
>>>     based on the IP addresses from the customer IP header.
>As a result, when
>>>     the CW is not present, the packets on an IP PW may be
>loadspread across
>>>     multiple backbone paths compromising the deterministic
>path forwarding.
>>>     In this scenario potential OAM packets (see [VCCV]) may
>be forwarded
>>>     consistently on a different path than most of the IP PW
>packets. This
>>>     could cause challenges for troubleshooting and
>operational changes to the
>>>     network administrator looking to migrate their L2VPN
>networks to
>>> an IP PW
>>>
>>>  Balus et.al                                                
>     Page 2>
>>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires 
>January 2005
>>>
>>>     transport. Network operators that relied on L2
>mechanisms to provide this
>>>     functionality may expect to preserve this behavior in
>IP PWs. Similarly,
>>>     some end user applications rely on native L2 congestion
>notifications or
>>>     discard priority markings for QoS treatment or even SLA 
>>> reporting.
>>>     
>>>     Clearly, not all end user applications using an IP PW
>will have an
>>>     identical set of requirements. Typically an internet
>access service has
>>>     less requirements from its layer 2 transport media,
>when compared to a
>>>     SLA-based, L2VPN service. An IP PW must be flexible
>enough to satisfy the
>>>     loose requirements of the basic application, but offer
>the optional tools
>>>     to address the strict requirements of the more
>demanding one.These
>>>     requirements typically include:
>>>      *  Enable the use of PW in-band OAM with or without ECMP
>>>      *  Distinguish an IP PW frame from a regular IP/MPLS frame for 
>>> 	   consistent forwarding of user frames in a PSN using ECMP
>>>      *  The option to reflect important layer 2 service 
>>> characteristics
>>> 	
>>>     This document proposes an IP PW encapsulation that
>includes an optional
>>>     IP control word. The new encapsulation enables the use
>of PW OAM tools
>>>     already defined in [VCCV] while offering the mechanisms
>for preserving the
>>>     characteristics of the end-to-end L2 service. This
>provides an efficient
>>>     transport of IP PDUs between ACs in environment where
>ECMP is deployed but
>>>     the lack of determinism of ECMP, and diagnostic
>complexity is not desired
>>>     for this specific service. The document describes also
>how the proposed
>>>     solution addresses the case of an MPLS backbone running
>ECMP so that the
>>>     data and OAM packets follow the same path throughout the 
>>> backbone.
>>>
>>>  3. Reference Model
>>>
>>>     The following diagram represents the reference model used to
>>>     describe the services emulated by the IP PW, based on
>the concepts
>>>     outlined in [PWE3 Architecture].
>>>              |<------------- Emulated L2 Service -------------->|
>>>              |                                                  |
>>>              |          |<----- IP Pseudo Wire ----->|          |
>>>              |          |                            |          |
>>>              |          |    |<-- PSN Tunnel -->|    |          |
>>>              |          V    V                  V    V          |
>>>              V(IP/)X AC +----+                  +----+(IP/)Y AC V
>>>        +-----+    |     | PE1|==================| PE2|     
>|    +-----+
>>>        |     |----------|..........IP 
>PW1............|----------|     |
>>>        | CE1 |    |     |    |                  |    |     
>|    | CE2 |
>>>        |     |----------|..........IP 
>PW2............|----------|     |
>>>        +-----+  ^ |     |    |==================|    |     
>| ^  +-----+
>>>              ^  |       +----+                  +----+     | |  ^
>>>              |  |   Provider Edge 1         Provider Edge 2  |  |
>>>        Customer |                                           
> | Customer
>>>        Edge 1   |                                           
> | Edge 2
>>>                 |                                            | 
>>>          native X service                             
>native Y service
>>>                     Figure 1: PWE3 IP PW Network Reference Model
>>>
>>>  Balus et.al                                                
>     Page 3>
>>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires 
>January 2005
>>>
>>>     In figure 1, X and Y represent two Attachment Circuits, both 
>>>     upporting an IP payload. An IP PW is used to provide
>PSN transport
>>>     between the two ACs. It is important to note as a
>general rules that
>>>     for the direction CE1 to CE2 the ingress PE, PE1,
>should map all the
>>>     IP/X frames to IP/PW encapsulation described in section
>4. The rest
>>>     of the frame types MUST be discarded with the
>exceptions noted in
>>>     section 7. Same is valid in the reverse direction (CE2->CE1) on 
>>> PE2.
>>>
>>>  4. IP PW Encapsulation
>>>
>>>     This document introduces an OPTIONAL Control Word (CW)
>in front of
>>>     the customer IP payload. This will address the requirements
>>>     described in section 2, ensuring that the IP PW data
>packets follow
>>>     the same path with the PW OAM ones. Also the presence
>of this CW
>>>     allows for additional flexibility in maintaining the
>Layer 2 service
>>>     characteristics.
>>>
>>>     The IP PW Control Word follows the guidelines and the bit format
>>>     described in [Martini L2CIRC] section 3.1 - see figure 3 below:
>>>     
>>>         0                   1                   2           
>        3
>>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>6 7 8 9 0 1
>>>        
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        | Rsvd  |B|F|D|0|FRG|   Length  |           Sequence 
>           |
>>>        
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |                      Customer IP PDU               
>           |
>>>        |                             "                      
>           |
>>>        |                             "                      
>           |
>>>        |                             "                      
>           |
>>>        
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>                         Figure 3: IP PW Control Word
>>>
>>>     - The first 4 bits are reserved for further use. They
>MUST be set to
>>> 	(0000) upon transmitting. They ensure the IP PW data
>packets are
>>> 	differentiated from normal IP packets in the MPLS ECMP
>case. Or in other
>>> 	words they will follow the same path with the PW OAM ones.
>>>
>>>     - The next 4 bits (4 to 7) MAY be used to provide
>flexible support for
>>> 	transport-specific treatments for any given AC type:
>>>
>>> 	 . Bit 4 (B) used to signal Backward Congestion Indication (BCI)
>>> 	   This bit could be used to alleviate possible
>congestion situation
>>> 	   related to differences in speed between ACs located
>at the two sides
>>> 	   of an IP PW: e.g. Ethernet/ATM AC X --> FR AC Y. 	      
>>>
>>> 	 . Bit 5 (F) used to signal Forward Congestion
>Indication (FCI) 	
>>> 	 . Bit 6 (D) used to indicate the Discard Priority (DP)
>>>
>>> 	If the transmitting PE does not support the processing
>of the above
>>>       flags, it MUST set them to 0. If the receiving PE does not 
>>> support the
>>>
>>>
>>>  Balus et.al                                                
>    Page 4>
>>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires 
>January 2005
>>>
>>>       processing of the flags it MAY ignore them upon reception.
>>> 	 . Bit 7 is reserved and must be set to 0.
>>>
>>>     - FRG field (bits 8,9) MAY be used to provide support
>for PW Fragmentation
>>> 	to address MTU mismatch. The usage of these bits is
>compliant with the
>>> 	procedure described in [FRAG]. Note that the usage of
>PW fragmentation
>>>       could be negotiated using the parameter id described
>in section 4 of
>>>       [FRAG]. Alternatively, fragmentation at IP Layer
>could be used - see
>>>       section 3 of [FRAG]. In the latter case the packet is
>fragmented at the
>>>       ingress PE and reassembled just at the IP Destination
>device - i.e. the
>>>       egress PE does not get involved. As such this option
>could be enabled by
>>>       provisioning just at the ingress PE.
>>>
>>>     - Length field (bits 10 to 15) MAY be used (see
>[Martini L2CIRC] section
>>>       3.1) in conjunction with the padding of short IP PW
>payloads (i.e. 40
>>>       Bytes) when the link layer protocol on the related
>PSN links requires a
>>>       minimum frame length: i.e. minimum payload for
>Ethernet is 64 bytes. If
>>>       the total length of the IP payload plus the CW (4
>bytes) plus the 2
>>>       labels (8 bytes) is less than 64 bytes then the
>Length field indicates
>>>       the total length of the L2 payload (i.e. IP
>payload+12 bytes). Otherwise
>>>       the length field must be set to zero. The egress PE
>will remove the
>>>       padding and it will restore the frame to its original size. 
>>>       Alternatively, the Length field from the IP header
>could be used to
>>>       address this issue. In this case the padding will be
>removed just at the
>>>       IP destination.
>>>
>>>     - The next 16 bits provide a sequence number that can
>be used to guarantee
>>> 	ordered packet delivery. The processing of the sequence
>number field is
>>> 	OPTIONAL and a value of 0 is used to indicate an
>unsequenced packet.
>>>       This Sequence number SHOULD be compliant with the
>rules defined in
>>>       [Martini L2CIRC] see section 3.1.1 and 3.1.2.
>>>
>>>  5. Support for PW OAM
>>>
>>>     [VCCV] defines a set of OAM tools (i.e. Ping, BFD) to
>be used for
>>>     any type of PW encapsulation. One of the methods
>proposed to identify
>>>     the associated OAM flows (see Section 4.1 of [VCCV])
>suggests the use
>>>     of the following format:
>>>
>>>      0                   1                   2                   3
>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>     
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>     |0 0 0 1| reserved = 0  |  PA=0 |      PPP DLL Proto 
>Number     |
>>>     
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>                      Figure 2: VCCV OAM Encapsulation
>>>
>>>     The first nibble (0001) together with PPP DLL Protocol
>Number field is
>>>     used to identify the OAM flows. This will enable, for
>the IP PW, the
>>>     unrestricted use of OAM mechanisms common to other PW types.
>>>
>>>
>>>  Balus et.al                                                
>     Page 5>
>>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires 
>January 2005
>>>
>>>  6. Support for non-IP payload
>>>     
>>>     As a general rule PE1 and PE2 will discard the incoming
>non-IP payloads
>>>     on ACs X and Y. Still there could be exceptions from
>the above rule: e.g.
>>>     if CE1 and CE2 are using IS-IS for routing protocol,
>the IP PW might be
>>>     required to transport this non-IP payload between PE1 and PE2.
>>>
>>>     To achieve the above goal, it is proposed to extend the
>PWE3 Payload Type
>>>     Identifier defined in [PWE3-CW] as follows:   
>>>     
>>>      0                   1                   2                   3
>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>     
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>     |0 0 0 1| reserved = 0  |  PA=X |          Payload Type 
>        |
>>>     
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>       Figure 2: IP PW Encapsulation used non-IP payload exceptions
>>>
>>>     The value PA=0 is reserved for PW OAM messages (VCCV
>PING, BFD). Values
>>>     other than zero are used to identify user packets which
>are not IP packet.
>>>     For example,  PA=1 (ISO protocol) and the corresponding
>ISO NLPID code
>>>     points could be used to provide support for
>transporting IS-IS frames over
>>>     an IP PW:
>>>       0                   1                   2                   3 
>>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>7 8 9 0 1
>>>      
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>>>      |0 0 0 1|      rsvd.    | PA=1  |ISO NLPID=0x83 |0 0 0 
>0 0 0 0 0|
>>>      
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>  7. Signaling of the IP PW
>>>
>>>     A 15 bit quantity containing a value is used as part of
>the PWiD and
>>>     Generalized Id FECs to identify the type of PWs - see
>[PWE3-CTRL] sections
>>>     5.1 and 5.2. To signal the IP PW we propose the usage
>of the value 0x000b
>>>     already assigned in [IANA PWE3]section 2 for IP Layer2
>Transport.
>>>
>>>     The negotiation of the control word complies with the
>procedure described
>>>     in [PWE3-CTRL] section 5.4.2.
>>>
>>>     No new TLVs, Interface parameters are required for now.
>>>
>>>  8. Security Considerations
>>>     To be completed later.
>>>
>>>  9. Changes from the previous version
>>>     
>>>     - Improved the Abstract and Introduction to clarify the
>goal of the draft
>>>     - Switched section "Support for PW OAM" (now 5,
>previously 4) with "IP PW
>>>       Encapsulation" (now 4, previously 5).
>>>     - Comments in section 4: on the usage of
>BE(fragmentation) and Lenght bits
>>>     - Changed the format in section 6 to allign to the
>newly proposed
>>> PTI
>>>
>>>  Balus et.al                                                
>     Page 6>
>>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires 
>January 2005
>>>
>>>  10. Acknowledgements
>>>
>>>     The authors would like to thank David Allan, Hamid
>Ould-Brahim, for
>>>     their helpful discussions and feedbacks.
>>>
>>>  11. Intellectual Property Rights Notices.
>>>
>>>     This document is being submitted for use in IETF standards 
>>> discussions.
>>>
>>>  12. References
>>>
>>>     [PWE3 Architecture] "PWE3 Architecture", draft-ietf-pwe3-arch-
>>>     07.txt, IETF work in progress, March 2004
>>>
>>>     [ARP Mediation] Shah, Himanshu "ARP Mediation for IP
>Interworking of
>>>     Layer 2 VPN", draft-shah-l2vpn-arp-mediation-03.txt,
>IETF work in
>>>     progress, October 2003
>>>
>>>     [IPLS] Shah,Himanshu "IP-Only LAN Service",
>draft-ietf-l2vpn-ipls-01.txt,
>>>     IETF work in progress, May 2004
>>>
>>>     [RFC3032] "MPLS Label Stack Encoding" IETF RFC 3032
>>>
>>>     [2547] Rosen, E. Rekhter, Y., "BGP/MPLS VPNs", IETF RFC 2547,
>>>       March 1999
>>>
>>>     [VCCV] Nadeau et.al., "Pseudo Wire (PW) Virtual Circuit
>Connection
>>>     Verification (VCCV)", draft-ietf-pwe3-vccv-02.txt, February 2004
>>>     [RFC2427] RFC 2427, "Multiprotocol Interconnect over
>Frame Relay"
>>>
>>>     [RFC2684] RFC 2684, "Multiprotocol Encapsulation over
>ATM Adaptation
>>>     Layer 5"
>>>
>>>     [Martini L2CIRC] Martini et.al. "Encapsulation Methods
>for Transport
>>>     of Layer 2 Frames Over IP and MPLS Networks", draft-martini-
>>>     l2circuit-encap-mpls-07.txt, IETF Work in Progress, June 2004
>>>
>>>     [Martini L2TRANS] Martini et.al. "Transport of Layer 2
>Frames Over
>>> 	MPLS", draft-martini-l2circuit-trans-mpls-14.txt, IETF Work in
>>> 	Progress, June 2004
>>>
>>>     [FR PW] Kawa et.al. "Frame Relay over Pseudo-Wires", draft-ietf-
>>> 	pwe3-frame-relay-02.txt, IETF Work in Progress, February 2004
>>>
>>>     [ATM PW] Martini et.al. "Encapsulation Methods for
>Transport of ATM
>>> 	Over IP and MPLS Networks",
>draft-ietf-pwe3-atm-encap-05.txt, IETF
>>> 	Work in Progress, April 2004
>>>
>>>     [PWE3-CTRL] Martini et.al. "Pseudowire Setup and
>Maintenance using
>>>       LDP", draft-ietf-pwe3-control-protocol-07.txt, IETF Work in
>>>       Progress, June 2004
>>>
>>>  Balus et.al                                                
>     Page 7>
>>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires 
>January 2005
>>>
>>>     [IANA PWE3] Martini, Townsley "IANA Allocations for
>pseudo Wire Edge
>>>       to Edge Emulation (PWE3)",
>draft-ietf-pwe3-iana-allocation-04.txt
>>> 	(work in progress), April 2004
>>>    
>>>     [IANA PPP] IANA Point-to-Point Protocol Field
>Assignments, June 28,2004
>>> 	http://www.iana.org/assignments/ppp-numbers
>>>
>>>     [RCF3032] RFC 3032 Rosen, et al., "MPLS Label Stack
>Encoding", January
>>>       2001
>>>     
>>>     [PWE3-CW] Bryant-McPherson, "PWE3 Control Word" 
>>> 	draft-bryant-mcpherson-pwe3-cw-00.txt, July 2004
>>>
>>>  12. Authors' Addresses
>>>
>>>     Florin Balus
>>>     Nortel Networks
>>>     3500 Carling Ave.
>>>     Ottawa, Ontario, CANADA
>>>     e-mail: [email-masked]
>>>
>>>     Jeff Sugimoto
>>>     Nortel Networks
>>>     3500 Carling Ave.
>>>     Ottawa, Ontario, CANADA
>>>     e-mail: [email-masked]
>>>
>>>     Mike Loomis
>>>     Nortel Networks
>>>     Billerica, MA
>>>
>>>     Himanshu Shah 
>>>     35 Nagog Park, 
>>>     Acton, MA 01720 
>>>     Email: [email-masked]
>>>
>>>     Mircea Pisica
>>>     Infonet Services Corporation
>>>     Brussells, Belgium
>>>
>>>     Mustapha Aissaoui
>>>     Alcatel
>>>     600 March Rd
>>>     Kanata, ON, Canada. K2K 2E6
>>>     Email: [email-masked]
>>>
>>>     Full copyright statement
>>>     Copyright (C) The Internet Society (2004). This
>document is subject
>>>     to the rights, licenses and restrictions contained in
>BCP 78, and
>>>     except as set forth therein, the authors retain all
>their rights.
>>>
>>>
>>>  Balus et.al                                                
>     Page 8>
>>>  draft-balus-pwe3-ip-pseudowire-01.txt             Expires 
>January 2005
>>>
>>>     This document and translations of it may be copied and
>>>     furnished to others, and derivative works that comment
>>>     on or otherwise explain it or assist in its implementation
>>>     may be prepared, copied, published and distributed, in
>>>     whole or in part, without restriction of any kind,
>>>     provided that the above copyright notice and this
>>>     paragraph are included on all such copies and derivative works.
>>>     However, this document itself may not be modified in any way,
>>>     such as by removing the copyright notice or references to the
>>>     Internet Society or other Internet organizations, except as
>>>     needed for the purpose of developing Internet standards in
>>>     which case the procedures for copyrights defined in the
>>>     Internet Standards process must be followed, or as required to
>>>     translate it into languages other than English.
>>>
>>>     The limited permissions granted above are perpetual and will
>>>     not be revoked by the Internet Society or its successors or 
>>> assigns.
>>>
>>>     This document and the information contained herein are
>provided on
>>>     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
>>>     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
>SOCIETY AND
>>>     THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
>WARRANTIES, EXPRESS
>>>     OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
>THAT THE USE OF
>>>     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
>ANY IMPLIED
>>>     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 
>>> PURPOSE.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  Balus et.al                                                
>     Page 9
>
>