Subject: RE: Draft PWE3 Charter

From: [email-masked]
Date: Mon, 2 Aug 2004 15:18:07 +0100

Folks,

One of the WG objectives of the old charter was:
"The WG will determine the requirements for having a pseudo wire pass across an administrative boundary."

One of the WG objectives of the new charter is:
"Define mechanisms to allow the inter-domain operation of PWs."

IMO a requirements definition should come before a solution definition.  Given that there are now drafts proposing solutions to the problem of inter-domain PWs (i.e. PW switching/stitching) can I assume that the requirements for "inter-domain operation of PWs" have been identified?  If so, where can I find those requirements documented?

Thanks
Ben

-- 
Ben Niven-Jenkins
Networking Specialist
Next Generation IP/Optical Networks, BT Exact

e-mail: [email-masked]
tel: +44(0) 1473 648225
fax: +44(0) 1473 620109

pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 3 Aug 2004 00:24:48 +0200

Ben, Stewart, Danny and all,

It looks like there are multiple interpretations of the desired WG scope wrt
multi-hop PWs.

One  interpretation considers these PWs as solutions for
inter-provider/inter-area problems.

Another deals with limited number of targeted LDP sessions and different PSN
technologies etc. 

There are also issues related to QoS, dual homing etc.

And, IMHO, there are issues that go beyond the mere PW stitching/switching,
like routing 
(how do you find your S-PEs where the switching is done?) and OAM (how do
you identify the faulty 
PW segment if you have U-PE-to-U-PE problems?) etc.

I think that we need a wider definition of scope of the related work in the
Charter that would include:

- clear specification of requirements for MH-PWs including some guidelines
as to when these must be
  preferred over some simpler solution (e.g., a SH-PW over L2TPv3). These
requirements should address
  the inter-provider/inter-area case but are not necessarily limited to this
case

- additions to the PWE3 architecture/reference models addressing the MH-PW
issues (the present
  architecture seems tightly bound to the SH-PW case). The mere fact that I
have to use the new
  terms like U-PE/S-PE proves in my eyes that this work is necessary

- identification of a small number of solutions addressing these
requirements with the appropriate
  applicability statements

- specification of the appropriate OAM mechanisms (or modification of the
existing OAM mechanisms)
  facilitating effective fault localization

- extension of the PWE3 MIBs supporting MH-PWs (I suspect - even if I did
not check - that the current
  PWE3 MIBs do not address the MH-PW issues?)

In fact, I think that there is a lot of work to do - and I think this work
is necessary, too.

Hopefully these notes will be useful.

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Monday, August 02, 2004 4:18 PM
> To: [email-masked]
> Subject: RE: [PWE3] Draft PWE3 Charter
> 
> 
> Folks,
> 
> "The WG will determine the requirements for having a pseudo 
> wire pass across an administrative boundary."
> 
> IMO a requirements definition should come before a solution 
> definition.  Given that there are now drafts proposing 
> solutions to the problem of inter-domain PWs (i.e. PW 
> switching/stitching) can I assume that the requirements for 
> "inter-domain operation of PWs" have been identified?  If so, 
> where can I find those requirements documented?
> 
> Thanks
> Ben
> 
> -- 
> Ben Niven-Jenkins
> Networking Specialist
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Tue, 3 Aug 2004 11:41:20 +0100

Not half Sasha!  We in BT are very concerned at where PWE3 are now
heading, and we had a long internal discussion on this yesterday.

PWE3 work is clearly nothing to do with the Internet any longer (as if
it ever was), but what is being created now is hardly what operators
need either in our view (and if I get chance I'll post some comments on
the proposed revised charter later today....as we see it, both the large
operator requirements and the public Internet requirements are being
compromised by what looks like a bunch of enterprise grade stuff).  Wrt
PW sw/titching, and no matter how this is dressed-up, as Richard pointed
out a few days ago this is creating a new layer network......that is
simply a fact whether it is understood or not by some folks.  Further,
there is a tangle of protocols now that is functionally becoming a right
dog's dinner.

Let me try and briefly explain what I mean by this......

The root problem is MPLS != IP.  How anyone can continue to maintain a
pretence that this is not true is beyond us. We need all 3 modes (ie
cl-ps, co-ps and co-cs) to operate in concert.....but this is not the
same as assuming they can all somehow be treated the same.

The real problems that need fixing 1st for MPLS are these:
-	Deprecate the stuff that creates violations (and thus
operational/service problems) of the co-ps mode....so that's LDP mp2p,
PHP and ECMP (ECMP is fine in IP);
-	Add the missing/important functional components.....so that's:
consistent access point addressing of LSPs, an OOB control/management
plane and carrier-grade OAM.

This cannot be done overnight, but if you really want to work on the
next generation network standards for large operators then stuff that is
broken/missing has to be recognised as such and not ignored.

Currently PWE3 stuff is building on flawed foundations (ie the above)
and then adding further kludges (in some cases to try and compensate for
these).

Now let me come to some of the protocol tangle/mess:

When a trail (eg an LSP here) is created/destroyed one needs to
activate/deactivate the OAM fault-management in sync with this....else
there are going to be operational problems.  Two key things here:
-	the trails must *all* use the same form of access point
identification so that this can be used in the OAM packets to detect all
break/swap/mismerging defects in a consistent manner network-wide;
-	given the activation/deactivation of the OAM fault-management
(at the trail term sink point) must be harmonised to the
set-up/tear-down of the LSP, its obvious that the LSP source identifier
should be loaded into the LSP sink trail termination point in harness
with whatever agent is doing the trail set-up/tear-down, eg the
signalling protocol or the management protocol.

The above is not difficult *if* its done properly....however, here is
some of the mess we currently see here:

Some folks also want to use LDP as a proxy device for data-plane fault
notification in the case of peer-partition interworking across different
technologies/modes.  Bad call for many reasons.  On reason is that fault
management must be done in the data-plane because it has to work even if
the control-plane fails, and it also has to be consistent irrespective
of the signalling protocol used (inc case of 'none', ie static).

But targeted LDP is now starting to look like CR-LDP and some folks
don't like that....RSVP-TE is the stated preferred signalling protocol
here is it not.  So what about fault notification handling in this case?
Is RSVP-TE going to get the same treatment?

BFD:  This has several issues:
-	its supposed to be a lightweight OAM connectivity verification
function, rather reminiscent of the Y.1711 CV in fact.  But I find it
needs LSP-Ping, which is a bloated heavyweight protocol (largely to
cater for the mp2p and ECMP violations), to 'boot-strap' it, ie load the
LSP source ID (see next item) at the LSP sink point.  So a lightweight
protocol needs a heavyweight protocol to boot-strap it?.....that does
not look right.  But in any case, this function ought to be done via the
signalling agent and *not* LSP-Ping.  Further, if you keep this LSP-Ping
boot-strap behaviour, how is OAM activation/deactivation going to be
synchronised to the signalling protocol (and which is this, LDP or
RTSVP-TE)?
-	BFD uses a locally generated 'discriminator' as the LSP source
ID.  This could be OK if this was the true access point address of
whatever the trail it was being used on......but we don't have
consistent LSP access point addressing in MPLS (these are not IP layer
addresses in case anyone is making that (wrong) connection here).
-	The CV/BFD OAM packet must be injected/extracted at the right
trail termination points.....this is *not* the PW trail term points but
the LSP trail term points, ie we want the same/consistent behaviour over
all LSPs, not just PW LSPs. 

In addition to these issues we also of course have:

-	the fact that martini CW is an optional, still not fully
specified (ie seq no defect handling) and largely redundant entity for a
properly specified co-ps server layer network (or indeed any co-cs
server layer network)......the general issue here that does not seem to
be understood is that the adaptation function that is required between 2
layer networks in a client/server relationship depends on the mode of
both the client and server layer networks.  1-size does not fit all
here.

-	in any client/server relationship one must have an ability for
layer independence (ie client and server owned by different
parties....very common case, *not* an exception).  This also means the
default behaviour is client layer transparency......not BW squeezing as
we find in many cases.  Note also that real networks run at rather low
loads over the vast majority of their operating life, so BW squeezing is
not a priority issue for major operators.....but getting rid of
complexity is (and PWE3 is creating significant complexity for no good
technical reason), and so is solving the commercial problem of 'how to
create fair/meaningful/consistent services over all load
points'......though this is another matter.

-	the PID/VCCV stuff....yet another set of optional behaviours, ie
more complexity.

-	nowhere in any IETF work are there any defects specified, ie
entry/exit criteria and consequent actions.   This is simply not
acceptable if you are trying to 'sell' any of this stuff to a large
operator like BT.  Further, as I have painfully kept pointing
out.....the defects that can affect the cl-ps mode (eg IP) are not the
same as those that can affect the co-ps mode, and neither of these is
the same as those that can affect the co-cs mode.  Y.1711 is actually a
generic OAM solution for the co-ps mode.......the fact it can be
directly applied to arch valid forms of MPLS is just an obvious
consequence of this. 

It's a mess folks, and its getting worse.....and it all starts with the
flawed notion that MPLS == IP, and the arch violations and func
deficiencies of MPLS as-is.....the rest then follows.   This stuff is
not meeting our requirements as a large network operator....yet the
re-spun charter's opening bars strongly suggest this is who this is
targeted at. 

Regards, Neil

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sasha Vainshtein
> Sent: 02 August 2004 23:25
> To: Niven-jenkins,B,Ben,XGH5 R; Stewart Bryant (E-mail); 
> Danny McPherson (E-mail)
> Cc: Sharon Galtzur; [email-masked]; Alik Shimelmits
> It looks like there are multiple interpretations of the
> desired WG scope wrt multi-hop PWs.
> 
> Another deals with limited number of targeted LDP sessions
> and different PSN technologies etc. 
> 
> And, IMHO, there are issues that go beyond the mere PW
> stitching/switching, like routing 
> (how do you find your S-PEs where the switching is done?) and 
> OAM (how do you identify the faulty 
> I think that we need a wider definition of scope of the
> related work in the Charter that would include:
> 
> - clear specification of requirements for MH-PWs including
> some guidelines as to when these must be
>   preferred over some simpler solution (e.g., a SH-PW over 
> L2TPv3). These requirements should address
>   the inter-provider/inter-area case but are not necessarily 
> limited to this case
> 
> - additions to the PWE3 architecture/reference models
> addressing the MH-PW issues (the present
>   architecture seems tightly bound to the SH-PW case). The 
> mere fact that I have to use the new
> - identification of a small number of solutions addressing
> these requirements with the appropriate
>   applicability statements
> 
> - specification of the appropriate OAM mechanisms (or
> modification of the existing OAM mechanisms)
> - extension of the PWE3 MIBs supporting MH-PWs (I suspect -
> even if I did not check - that the current
> In fact, I think that there is a lot of work to do - and I
> think this work is necessary, too.
> 
> > definition.  Given that there are now drafts proposing solutions to 
> > the problem of inter-domain PWs (i.e. PW

---

From: [email-masked]
Date: Tue, 3 Aug 2004 14:48:25 +0100

Hi Stewart....a few observations in-line.

Regards, Neil

> Here is the proposed updated PWE3 Charter that Danny and I sent to 
> Thomas a little while ago.
> 
> We will be working on this at the meeting next week, but comments 
> ahead of time would be appreciated.
> 
> - Stewart
> 
> 
> Description of Working Group:
> 
> Network operators
NH=> So this is now aimed at the likes of BT I take it and has very
little to do with the Internet?

> and their subscribers
NH=> 'Subscribers' is a bit old-hat these days.....suggest 'customers'
(noting that there are client/server relationships even between
operators).  Though I am not sure why even 'customers' needs to appear
here anyway.

> are seeking to
> rationalize their networks by migrating to a single, IP or 
> MPLS based packet switched network.
NH=> This is not completely accurate.  A full service operator like BT
actually needs all 3 network modes....as they do different jobs.  What
we primarily want is rationalisation of technologies that belong to the
same mode, because in the past this has created the so-called
'stovepipe' problem (ie selling a specific technology and its features
as the 'service').  This also continues the interworking headache.  So
its not appropriate to say 'a single network' nor, as a slight technical
correction, is it 'IP *or* MPLS'.....both a cl-ps mode and co-ps mode
are required if one wants to correctly cater for all public/private
services.

As a suggestion try this text:
"Operators want to reduce the number of different technologies in each
network mode that support both public and private services.  This
essentially means convergence to IP and MPLS as the target core
technologies."

> This migration requires 
> communications services that can emulate the essential 
> properties of traditional communications links over a packet 
> switched network (PSN).
NH=> I am not sure that the word 'emulation' is correct here.  If I look
at the current PW stuff it is simply client/server encapsulation.
Client compression is not really emulation....this is simply BW
squeezing, which is hardly a key issue anyway given core networks
usually run at low loads.  So IMO a more accurate description of what
PWE3 are currently doing (or should be doing) would be:

"As part of the convergence process there will be a requirement for the
IP and MPLS target core networks to carry various legacy technologies.
This places no obligations on the functions/features of the core IP and
MPLS networks (but see Note) to replicate legacy technology functions or
features.  However, there is an overarching requirement for transparent
client carriage and an ability to meet the availability and transfer
network performance requirements of the clients.
Note - The core IP and MPLS networks still require to be completely
functionally specified in their own right for the mode they represent,
and they must respect the connectivity constraints of their mode."
> 
> Pseudowire Emulation Edge to Edge (PWE3) will specify the 
> encapsulation, transport, control, management, interworking 
> and security of services emulated over IETF specified packet 
> switched networks.
NH=> Just an observation here.  Not sure you need 'interworking'
mentioned.  The word 'encapsulation' intimates one has a client/server
relationship here.  The so-called (badly) 'service-interworking' concept
that was used with FR and ATM in FRF.8 is not a general case, because
when one has different server technologies partitions (carrying some
common client on each) all the characteristic information of each server
technology partition must be terminated at the interworking point.  This
ought to be obvious IMO as there will be a mismatch of functions and/or
features, especially when the technology partitions belong to different
modes.
> 
> A pseudowire emulates a point-to-point link, and provides a 
> service which is perceived by its user as an unshared link or 
> circuit of the chosen service.
> 
> It is not intended that an emulated service will be 
> indistinguishable from the service that is being emulated. 
> The emulation need only be sufficient for the satisfactory 
> operation of the service. Emulation necessarily involves a 
> degree cost-performance trade-off. In some cases it may 
> necessary to design more than one emulation mechanism in 
> order to resolve these design conflicts. All emulated service 
> definitions will provide an applicability statement 
> describing the faithfulness of the emulation.
NH=> Seems a lot of text to describe something that is not even being
done (see prior common wrt 'emulation vs encapsulation').  The real
issue here is wrt to satisfying the transfer network performance that
the client will get IMO.
> 
> Switching, multiplexing, modification or other operation on
> the traditional service, unless needed as part of the 
> emulation is out of the scope of the PWE3 WG.
> 
> PWE3 will make use of existing IETF specified mechanisms
> unless there are technical reasons why the existing 
> mechanisms are insufficient or unnecessary.
> 
> PWE3 will not exert control on the underlying PSN, other than 
> to use any existing QoS or path control mechanism to provide 
> the required connectivity between the two ends of the PW.
> 
> PWE3 will use RTP where necessary to perform clock recovery 
> and other real-time signaling functions.  This work will be 
> coordinated with the AVT WG and payloads will follow RFC 2736.
> 
> 
> WG Objectives (in order of priority):
> 
> Specify the following PW types:
> Ethernet, Frame Relay, PPP, HDLC, ATM, TDM and SONET
> 
> Specify the control and management of the PW types
> identified above.
> 
> Specify OAM mechanisms for all PW types, suitable for
> operation over both IP and MPLS PSNs, and capable of
> providing the necessary interworking with the OAM mechanisms
> of the emulated service.
NH=> If a client is transparently carried (which ought to be the
default) this is a non-issue as the client OAM should be carried
completely transparently.  The only thing you have to get right is this:
the defects that occur in the server layer need detecting/handling
there, and one consequence is the generation of the appropriate client
FDI.  And this really should be be done in the data-plane (though some
clients are not well specified in this respect).  Further, speaking as
an operator I don't want to see a plethora of OAM (or indeed other
functional components)......esp when there are unnecessarily complex
relationships between the components (see my earlier posting where I
tagged a mail from Sasha).   The defects of the cl-ps mode are *not* the
same as the co-ps mode, and neither are the same as those of the co-cs
mode.  1 size does not fit all, but neither are multiple solutions per
mode required.  Use the right functional solutions for the mode
considered.  Putting this more simply:  The OAM required for IP is not
the same as that required for MPLS, and neither is the same as that
required for SDH (read this as GMPLS if that helps). 
> 
> Enhance packet-based PW specifications as necessary to
> allow the emulated service to be carried transparently
> over the PSN, for example by the retention of the FCS
> across the PW.
NH=> This is hardly an 'enhancement'.  Removing it in the 1st place is
an error of judgement IMO.  BW squeezing of the client is not a priority
requirement.  The default behaviour should be transparent client
carriage over the server.
> 
> Define mechanisms to permit the operation of a PW over
> a PSN that deploys equal cost multiple path packet (ECMP) switching.
NH=> How can you do this (or make it a requirement) when ECMP is not
standardised?  ECMP in IP is not at all the same thing as ECMP in MPLS
IMO.
> 
> Specify the encapsulation, control and management of an
> IP PW type.
> 
> A PW operating over a shared PSN does not have the same 
> intrinsic security as a dedicated purpose built network. In 
> some cases this is perfectly satisfactory. In other cases it 
> will be necessary to enhance the security of the PW to 
> emulate the intrinsic security of the emulated service.
NH=> There is no reason IMO why a properly specified MPLS network cannot
offer similar security levels to other co-ps technologies.
> 
> Whilst a service provider may traffic engineer their network
> is such a way that PW traffic will not cause significant 
> congestion, a PW deployed by an end-user may cause congestion 
> of the underlying PSN. Suitable congestion mechanisms are 
> therefore needed to protect the Internet from the 
> unconstrained deployment of PWs.
NH=> I thought this stuff was being targeted at operators of commercial
networks?  Well that's what the opening paragraph implies.
> 
> Define mechanisms to allow the interconnection of PWs.
NH=> What does this mean?  Is this between PWs supported by the same
server layer technology (ie both IP or both MPLS) or different server
layer technologies (which also seems to imply some interworking of (at
least) signalling of the IP or MPLS server layer networks)?
> 
> Define mechanisms to allow the inter-domain operation of PWs.
> 
> Define the mechanisms needed to allow the operation of 
> switched virtual circuits over a PSN.
NH=> Which SVCs?  I assume you must mean ATM SVCs.  One could of course
imagine MPLS LSP SVCs.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 03 Aug 2004 08:00:58 -0700

Neil,

> it ever was), 

If that is indeed the case, then the PWE3 WG should be dissolved, as
its work would be outside of the mission for the IETF. Quoting from 
draft-alvestrand-ietf-mission-02 (" A Mission Statement for the IETF"):

   The goal of the IETF is to make the Internet work better.

   The mission of the IETF is to produce high quality, relevant
   technical and engineering documents that influence the way people
   design, use and manage the Internet in such a way as to make the
   Internet work better.

Yakov.

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 3 Aug 2004 19:37:16 +0300

> PWE3 work is clearly nothing to do with the Internet any 
> longer (as if it ever was)

The PWE work is begin done in the IETF due to its
being related to MPLS and L2TP, both of which are being 
developed here.

No-one is implying that PWs MUST be sent over the public
Internet, rather than well-engineered IP networks, 
although nothing prohibits this either.

> but what is being created now is 
> hardly what operators need either in our view 

Well, perhaps there are other types of operators.
Also, as I have argued before, perhaps a lot of this work
should be directed towards the enterprise space instead.

So I would assume that you would have no problem with
our specifically adding enterprise applications to our charter?

> as we see it, both the large operator 
> requirements and the public Internet requirements are being 
> compromised by what looks like a bunch of enterprise grade 
> stuff).  

See my question above.

Please take into account that the IETF, unlike the ITU,
first solves the data transfer problem, and only afterwards
looks into other issues (e.g. OAM).

> Wrt PW sw/titching, and no matter how this is 
> dressed-up, as Richard pointed out a few days ago this is 
> creating a new layer network......that is simply a fact 
> whether it is understood or not by some folks. 

I have been saying for a long time that we should stop
pretending that PWs are NOT a full blown layer network.

> The root problem is MPLS != IP.  How anyone can continue to 
> maintain a pretence that this is not true is beyond us. 

No-one is. We are just saying that it is useful to design a layer
network (PWE) which can be run over many different PSNs.
Obviously, the various aspects will function somewhat differently,
e.g. QoS will be different over RSVP-TE MPLS and best-effort IP.

But then again RSVP-TE MPLS and LDP MPLS are just as different
in this regard.

Y(J)S

---

From: [email-masked]
Date: Tue, 3 Aug 2004 19:17:46 +0100

> > PWE3 work is clearly nothing to do with the Internet any longer (as
> > if it ever was)
> 
> being related to MPLS and L2TP, both of which are being developed 
> here.
> 
> No-one is implying that PWs MUST be sent over the public Internet, 
> rather than well-engineered IP networks, although nothing prohibits 
> this either.
NH=> I am very confused as what is the target audience here.  I don't
see the requirements of the public Internet, the ISP/altnet community,
the enterprise community or the large operator community as being the
same.  The charter does open up saying this is for operators
'....seeking to rationalise their networks....'.  So this assumes these
networks exist.....ISPs and the Internet don't have such legacy
networks, we however do.....so I can therefore only infer this is being
done for our 'benefit'.
> Well, perhaps there are other types of operators.
NH=> Yes, but far fewer than before......when the
technology/architecture creates an environment where opex > profit this
tends to happen ;-)

> Also, as I have argued before, perhaps a lot of this work should be 
> directed towards the enterprise space instead.
NH=> Looks like that sort of stuff to me.
> our specifically adding enterprise applications to our charter?
NH=> Adding?  Why not re-spin it to clearly state exactly who the target
audience is so that we are all clear?
> > compromised by what looks like a bunch of enterprise grade stuff).
> 
> See my question above.
> 
> first solves the data transfer problem, and only afterwards looks into

> other issues (e.g. OAM).
NH=> I have noticed.
> > dressed-up, as Richard pointed out a few days ago this is creating a

> > new layer network......that is simply a fact whether it is 
> > understood or not by some folks.
> 
> I have been saying for a long time that we should stop pretending that

> PWs are NOT a full blown layer network.
NH=> Richard continues to make this point quite nicely IMO.  Its just a
fact.
> 
> > The root problem is MPLS != IP.  How anyone can continue to maintain
> > a pretence that this is not true is beyond us.
> 
> No-one is.
NH=> Are you sure about that?

> We are just saying that it is useful to design a
> layer network (PWE) which can be run over many different
> PSNs. Obviously, the various aspects will function somewhat 
> differently, e.g. QoS will be different over RSVP-TE MPLS and 
> best-effort IP.
> 
> But then again RSVP-TE MPLS and LDP MPLS are just as different in this

> regard.
NH=> Quite.

Regards, Neil

---

From: [email-masked]
Date: Wed, 4 Aug 2004 09:57:31 +0100

other issues (e.g. OAM).

Pity.

Peter. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: 03 August 2004 17:37
To: Harrison,N,Neil,IKR2 R
Cc: [email-masked]
Subject: RE: [PWE3] Draft PWE3 Charter

No-one is implying that PWs MUST be sent over the public Internet,
rather than well-engineered IP networks, 
although nothing prohibits this either.

See my question above.

No-one is. We are just saying that it is useful to design a layer
network (PWE) which can be run over many different PSNs. Obviously, the
various aspects will function somewhat differently, e.g. QoS will be
different over RSVP-TE MPLS and best-effort IP.

Y(J)S