Subject: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

From: Danny McPherson <[email-masked]>
Date: Mon, 23 Jun 2008 12:31:06 -0600

Folks,
Please consider today the start of a two-week WG LC for
this document.

LC ends July 7, 2008.

Thanks!

-danny

Begin forwarded message:

> From: [email-masked]
> Date: May 28, 2008 9:15:03 AM MDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action:draft-ietf-pwe3-congestion-frmwk-01.txt
> Reply-To: [email-masked]
>
> 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           : Pseudowire Congestion Control Framework
> 	Author(s)       : S. Bryant, et al.
> 	Filename        : draft-ietf-pwe3-congestion-frmwk-01.txt
> 	Pages           : 26
> 	Date            : 2008-05-28
>
> Pseudowires are sometimes used to carry non-TCP data flows.  In these
> circumstances the service payload will not react to network
> congestion by reducing its offered load.  Pseudowires should
> therefore reduces their network bandwidth demands in the face of
> significant packet loss, including if necessary completely ceasing
> transmission.  Since it is difficult to determine a priori the number
> of equivalent TCP flow that a pseudowire represents, a suitably
> "fair" rate of back-off cannot be pre-determined.  This document
> describes pseudowire congestion problem and provides guidance on the
> development suitable solutions.Requirements Language
>
> The key words "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 [RFC2119].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-congestion-frmwk-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 29 Jun 2008 12:04:26 +0300

> Folks,
> Please consider today the start of a two-week WG LC for this document.

Stewart et al.

I apologize for just getting around to reading this document.

I have so many issues with it, that I don't know where to begin.

So I guess I will start with the scope. 
The draft claims to address congestion control for PWs. 
Actually it addresses TCP friendliness for PWs over the Internet
(or an Internet-like environment).
This preassumes that the most interesting topic to be solved
is how to keep PWs from crashing the Internet.
I have no doubt that this is an important issue,
since if we produce an encapsulation, then someone may one day use it on
the public Internet.
However, there is still a major jump between this legitimate concern 
and calling the treating of this pathological case "congestion control
for PWs".

Setting aside the aforementioned unusual cases, the focus of PWE3 is,
and has always been,
the service provider environment. No SP I have ever seen would place
individual user TCP flows
inside an MPLS tunnel along with PWs. And if one did, then they would
certainly have no problem
with such an individual user flow suffering from the PW traffic - and
would certainly not reduce
the PW service level in order to protect such an individual TCP flow.
(Note - I am not including
system TCP flows, such as LDP or BGP here. These would assumably be
appropriately prioritized).

So, I would have much fewer problems with calling this ID "congestion
control for PWs over the Internet",
but definitely object to calling it "congestion control for PWs".

So, what IS congestion control for PWs ?
Well, due to the unfortunate decision detailed in RFC 3468
and the interpretation that this limits PWE3 from extending its control
protocol to include BW reservations, 
we have to accept the situation that PWs are not properly BW limited.
So, we can't talk about a PW's committed rate (CR), and thus even if we
deny admission when
we believe we don't have sufficient BW, we can't properly enforce CR and
excess rate schedules.

What should a congestion framework for a service provider network
specify ?
We should be able to enable the PWs to be guaranteed their CR, and to
enjoy excess traffic
when BW is available. When congestion occurs, we should be able to tell
the ingress PEs
that this is the case, and that they should police to their CR. If
congestion continues,
we should exercise fairness between the PWs - BUT this does NOT mean
that all PWs should
get the same BW, rather that the percentage reduction from CR should be
the same !

There are many ways that this can be done. Of course, SP networks
usually have central management,
and the management may directly instruct ingress PEs as to their
constraints.
However, we can also develop noncentralized mechanisms. In order to
obtain
the kind of fairness required, we still us AIMD, but instead of reducing
the flow to half the PRESENT
rate, we need to multiply it by a percentage of the CR (or whatever we
desire to call it here).

Second topic.
The tutorial material on TCP congestion control and TFRP are useful, 
but I believe that they miss the main point for PWs.
TCP flows end up approximately equally sharing the BW (rather than the
fairness I defined above)
because of the basic assumptions of the model, not solely because of
AIMD. 
Each TCP flow is assumed to be atomic, 
all flows are assume equally important (i.e. to have the same CR), 
and the TCP flows are assumed to emanate from an end-user box where the
back-pressure 
can be used to hold up the application.
It is this set of assumptions along with the AIMD mechanisn that leads
to the TCP rate equation.
Were an Ethernet PW carrying TCP/IP to be in parallel to TCP flows, 
then loss of a single PW packet would translate to loss of a TCP packet
of a single socket pair, and thus lead to a much smaller reduction in PW
capacity
(which I assume is what the authors mean by "equivalent number of TCP
flows").
Similarly, were we to weight the flow importance, we could get different
flow rates.

On the other hand PWs emanate from PEs that can not usually perform
back-pressure 
and need to police by dropping packets. Furthermore, as stated above,
fairness does not
mean that we allot the same BW to the PWs - instead we need to allot CRs
and police to these. 
This is more direct and easier to understand and configure than the
nebulous concept
of "equivalent number of TCP flows".

Now for some shorter issues.

There is a statement about MOST (99%?) PWs carrying TCP/IP traffic.
This certainly needs qualification. I have been involved in many network
deployments
where NONE of the PWs carry TCP/IP. 

There is a statement about the possibility of sending PWs over IPsec
tunnels.
It is unclear to me what this means. IPsec is most commonly used for
TCP/IP traffic,
and thus if you use IPsec then you probably already have the behavior
you need.
On the other hand, there are PW encapsulations that use UDP/IP which
could
potentially be put in IPsec tunnels. But these are the TDM
encapsulations,
that can not fall back at all.
Finally, perhaps the ID means some new encapsulation of PW over RFC4023
over IPsec.
If so, it would be nice to have this stated, and to explain how this
works.

The drawbacks the draft mentions regarding using the sequence numbers
to detect packet drop seem artificial. Yes, misordering can masquerade
as packet drop if the delayed packet is very late. But no method is
perfect.
BTW, for TDM PWs packet arrival times can also be used as a very
senstive
mechanism to detect imminent congestion.

The draft needs a serious edit. There are numerous typos (newtork?) 
and in several places whole words seems to have dropped
(due to congestion, no doubt).

Y(J)S

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 30 Jun 2008 11:49:33 +0100

Yaakov
> is how to keep PWs from crashing the Internet.
Whist it is relatively rare for a PW to be run over the Internet, we all 
know
that they can and have been operated in that way, including as
I recall some TDM PWs. Congestion safeguards have been a day
one concern by the Transport ADs, and we have had many
requests to address the issue. As you will recall that is why the
WG was originally created in the Transport Area.

> No SP I have ever seen would place
> inside an MPLS tunnel along with PWs.
Perhaps someone with more configuration experience that I have
can confirm this. I would have expected that all the traffic between
the PEs went on the same tunnel, unless you explicitly
configured it otherwise.

> but definitely object to calling it "congestion control for PWs".
This was an issue that the authors though about quite a lot. There is some
hint of this in the conclusion

"In some service provider network environments the network
operator may choose to not deploy congestion
avoidance mechanisms, but they should make that choice in the full
knowledge that they are avoiding a network safety valve. "

To use an analogy : you could operate a stream engine without
a safety valve and indeed in the early days people did. All it
takes is vigilance to make sure the pressure  never goes above
limits even when  the  driver is  dealing with  other emergencies.
So no problem safety mechanisms are not need on the railway.

So back to our case here. We assume that the operator will
set the thresholds so that the congestion cut off never gets invoked
- unless there is a real problem in their network, in which
as the shedding of PW load will be the least of their problems.
 
> we believe we don't have sufficient BW, we can't properly enforce CR and

Wait a moment, there is nothing to stop you running PW over MPLS-TE, 
that has
the properties that you are looking for.

> when BW is available. 
Run over MPLS-TE and you will get a CR.
> When congestion occurs, we should be able to tell
> the ingress PEs

I do not think we said otherwise.
> rate, we need to multiply it by a percentage of the CR (or whatever we
I don't think we said apply AIMD to the PWs.
> of "equivalent number of TCP flows".
The unfortunate problem is that in congestion work the unit of currency 
is the
"TCP flow". So what unit of currency would you propose that is common
to both PW and non-PW traffic?
> where NONE of the PWs carry TCP/IP.
... and I doubt that those networks experienced congestion, in which case
no congestion backoff will be involved. However there are a lot of data PWs
out there - certainly nearly all the first deployments were Ethernet and ATM
replacement and they were carrying data.
> There is a statement about the possibility of sending PWs over IPsec
For example PW over L2TP, or PW over MPLS over GRE over IP.

> that can not fall back at all.
As I said there are other PWs that run over IP.
> mechanism to detect imminent congestion.
Can you propose some text?
> (due to congestion, no doubt).
I am not sure that needed to be said on the public list. If I could 
spell better, I would :)

Stewart

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 30 Jun 2008 15:33:03 +0300

Stewart,  

> To use an analogy : you could operate a stream engine without a safety
valve and indeed in the early days people did. 
> All it takes is vigilance to make sure the pressure  never goes above
> So back to our case here. We assume that the operator will set the
thresholds so that the congestion cut off never gets invoked
> - unless there is a real problem in their network, in which as the
shedding of PW load will be the least of their problems.

So, if I understand you correctly, you are saying that this draft is a
framework for a mechanism
that will never really be used for a service provider network. This was
precisely my point.
 
> > Well, due to the unfortunate decision detailed in RFC 3468 and the 
> > interpretation that this limits PWE3 from extending its control 
> > protocol to include BW reservations, we have to accept the situation

> > that PWs are not properly BW limited.
> > So, we can't talk about a PW's committed rate (CR), and thus even if

> > we deny admission when we believe we don't have sufficient BW, we 
> > can't properly enforce CR and excess rate schedules.  

> Wait a moment, there is nothing to stop you running PW over MPLS-TE,
that has the properties that you are looking for.

Sorry, that is not the same thing. In my analysis I assume that the MPLS
is indeed TE,
but the PWs are not. So we know that the MPLS tunnel can handle, say 1
Gbps,
but we load it with 20 PWs each of which peaks at 100 Mbps.
What do we do now ?

Well, we could
1) have a centralized management system force each PE to police to rates
that sum to < 1 G
2) have a distributed mechanism whereby packet drop causes each PE to
police down
    to a percentage of the "expected maximum rate" (I hesitate to call
this committed).
3) use the TCP/IP mechanism whereby packet drop causes halving the rate
4) use a TCP-like or TCP-friendly mechanism which polices to a "fair BW"
(not fair degradation!)
    but does not know which internal flows it effects
5) use a TCP-friendly mechanism coupled with DPI to mimimize effect on
flows.

> The unfortunate problem is that in congestion work the unit of
currency is the "TCP flow". 
> So what unit of currency would you propose that is common to both PW
and non-PW traffic?

That unit of currency is only meaningful in the context of individual
user TCP flows.
I am claiming that it does make sense in a PW context,
and treating PWs as an equivalent number of flows is both a blunt tool,
and leads to internal TCP flows being badly treated as compared to
external ones.

> For example PW over L2TP, or PW over MPLS over GRE over IP.

Yes, PW over L2TPv3 or L2TP over UDP are possible.
Are you talking about IPsec transport or tunnel mode here?
I am trying to figure out what the packet looks like.
I guess, for IPv4 tunnel mode :
   outside IP header, IPSec AH and/or ESP headers, inside IP header,
L2TP header, PW payload, ESP trailer

> > sensitive mechanism to detect imminent congestion.

Actually, we had a lot of text about the TDM PW case in RFCs 4553, 5086
and 5087.
I can provide some text about using the arrival times.

Y(J)S

---

From: [email-masked]
Date: Mon, 30 Jun 2008 18:56:48 -0400

Yaakov,

Comments on the major topics in this thread.  I've (mostly) gone back
to your original message for the text I've quoted.

-- Scope --
 
> So I guess I will start with the scope.  The draft claims to address
congestion control for PWs. 
> Actually it addresses TCP friendliness for PWs over the Internet (or
an Internet-like environment).
> This preassumes that the most interesting topic to be solved is how to
keep PWs from crashing the
> Internet.  I have no doubt that this is an important issue, since if
we produce an encapsulation,
> then someone may one day use it on the public Internet.  However,
there is still a major jump
> between this legitimate concern and calling the treating of this
pathological case 
> "congestion control for PWs".
> 
and has always been,
> the service provider environment.

Ok, but keep in mind that the I in IETF stands for Internet with the
capital "I" (i.e.,
public). Protocols need to be specified so that they can be used over
the public Internet,
even if their most common uses will be on private networks.  This has
the very useful
effect of producing protocols that are more robust on private networks.
iSCSI is an
example that I'm very familiar with.

> No SP I have ever seen would place individual user TCP flows inside an
MPLS tunnel along
> with PWs.

Can we add that to the congestion framework draft as a general principle
with the words
"SHOULD NOT"?

[... snip ...]

> So, I would have much fewer problems with calling this ID "congestion
control for PWs over
> the Internet", but definitely object to calling it "congestion control
for PWs".

I think this is hair-splitting over choice of words.  At the end of the
day,
we need a congestion control framework for pseudo-wires.  It may well
turn
out to be inapplicable/not-needed in a well-managed service provider
environment.

> So, what IS congestion control for PWs ? Well, due to the unfortunate
decision detailed in RFC 3468
> and the interpretation that this limits PWE3 from extending its
control protocol to include BW
> reservations,  we have to accept the situation that PWs are not
properly BW limited.
> So, we can't talk about a PW's committed rate (CR), and thus even if
we deny admission when
> we believe we don't have sufficient BW, we can't properly enforce CR
and excess rate schedules.

specify ?
enjoy excess traffic
> when BW is available. When congestion occurs, we should be able to
tell the ingress PEs
> that this is the case, and that they should police to their CR.

I think that for a "service provider network," policing to CR is a fine
place to start.
The nature of a "service provider network" needs to be defined in a
fashion that makes
this a reasonable proposition - all traffic is in an aggregate (PW or
otherwise) with
a CR, and there is traffic management in place such that if all the
flows are running
at their CR, nothing has to be dropped.  Consider this a suggestion for
your forthcoming
(I hope) draft on how service providers should deal with PW congestion.
OTOH, outside
a service provider environment, the CR may be zero, so consideration
needs to be given
to PWs running entirely as "excess traffic when BW is available."

> If congestion continues,
that all PWs should
> get the same BW, rather that the percentage reduction from CR should
be the same !

I would not agree with the words "the same", but I suspect we're in
violent agreement
on the higher level point that the centralized OAM typically found in a
service
provider network provides options not available to an individual PW
running
over a network whose topology, components, etc. are unknown to a first
approximation.
As Stewart has pointed out, we need something that works for the latter
case.

[... snip ...]

-- TCP-like congestion control -- 

> The tutorial material on TCP congestion control and TFRC are useful,
but I believe that they miss
> the main point for PWs.  TCP flows end up approximately equally
sharing the BW (rather than the
> fairness I defined above) because of the basic assumptions of the
model, not solely because of
> AIMD.  Each TCP flow is assumed to be atomic, all flows are assume
equally important (i.e. to
> have the same CR), and the TCP flows are assumed to emanate from an
end-user box where the
> back-pressure can be used to hold up the application. It is this set
of assumptions along with
> the AIMD mechanism that leads to the TCP rate equation.

I think I'm in 80%+ agreement with this, although I would have described
TCP flows as
"independent", omitted any mention of "same CR" and talked about "lack
of delivery
causing cessation of application forward progress" as the means of back
pressure.
I suspect that this is 80%+ hair-splitting on my part.

> Were an Ethernet PW carrying TCP/IP to be in parallel to TCP flows,
then loss of a single PW
> packet would translate to loss of a TCP packet of a single socket
pair, and thus lead to a much
> smaller reduction in PW capacity (which I assume is what the authors
mean by "equivalent number
> of TCP flows"). Similarly, were we to weight the flow importance, we
could get different
> flow rates.

Cf. Diffserv (Differentiated Services).

back-pressure 
fairness does not
> mean that we allot the same BW to the PWs - instead we need to allot
CRs and police to these. 
nebulous concept
> of "equivalent number of TCP flows".

TFRC is fairly important because rate control provides a potentially
better approach to
rate policing than dropping every out-of-CR-profile packet.  In
particular, the constant
bit rate PWs look like they fit TFRC much better than a drop-based
mechanism.

-- PW congestion control for service providers --

>> So back to our case here. We assume that the operator will set the
thresholds so that
>> the congestion cut off never gets invoked - unless there is a real
problem in their
>> network, in which as the shedding of PW load will be the least of
their problems.
> that will never really be used for a service provider network. This
was precisely my point.

Ok, I can agree with that.

>> Can you propose a mechanism that has better properties?
>
> I can (and perhaps will) write a draft on what to do in the SP
scenario,
> which your draft does not cover.

IMHO, that would be a good idea, starting with a crisp statement of the
key aspects of a "service provider network" that differentiate it from
the public Internet.  At the end of the day, the structure of what
results
could be two frameworks and sets of mechanisms:
1) Basic congestion control framework/mechanisms for all pseudo wires
that
	makes no service provider assumptions.
2) A traffic-management-based congestion control framework and
mechanisms
	for service providers that assume a "service provider network."

Some carefully worded applicability language could position these two.
The per-PW (or per-tunnel) mechanisms for 1) may need to be "MUST
implement" for the same sort of reason that IETF requires mandatory-
to-implement security; if the PW is deployed in a non-service-provider
environment that needs congestion control, the means to do it will be
available.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 01 Jul 2008 09:01:24 +0200

Yaakov,

> We should be able to enable the PWs to be guaranteed their CR, and to
enjoy
> excess traffic when BW is available. 

I fully agree with you.

> When congestion occurs, we should be able to tell the ingress PEs that
this
> is the case, and that they should police to their CR. 

I very much disagree with you here.

Any PW should have at its UNI-N a Traffic Conditioning function that
enforces the CIR/EIR of the service. Furthermore, connection admission
control and traffic engineering should guarantee that links inside the
transport network do not have unexpected congestion conditions.

When congestion occurs this is per network design; the excess rate traffic
(marked as discard eligible) will be discarded. If the network design
includes committed rate based oversubscription of links, then also committed
rate traffic may experience congestion and some of those packets will be
discarded as well. No need to do anything special in the PWs. In a well
engineered network such conditions will be very rare. 

Furthermore, netowrk management will monitor the actual load on the links
and will receive indications when the load is increasing and/or crosses a
threshold. Then either the link capacity will be increased or some of the
PWs are rerouted over another link.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: 29 June 2008 11:04
To: Stewart Bryant; Danny McPherson
Cc: [email-masked]
Subject: Re: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

Stewart et al.

So I guess I will start with the scope. 
The draft claims to address congestion control for PWs. 
Actually it addresses TCP friendliness for PWs over the Internet (or an
Internet-like environment).
This preassumes that the most interesting topic to be solved is how to keep
PWs from crashing the Internet.
I have no doubt that this is an important issue, since if we produce an
encapsulation, then someone may one day use it on the public Internet.
However, there is still a major jump between this legitimate concern and
calling the treating of this pathological case "congestion control for PWs".

Setting aside the aforementioned unusual cases, the focus of PWE3 is, and
has always been, the service provider environment. No SP I have ever seen
would place individual user TCP flows inside an MPLS tunnel along with PWs.
And if one did, then they would certainly have no problem with such an
individual user flow suffering from the PW traffic - and would certainly not
reduce the PW service level in order to protect such an individual TCP flow.
(Note - I am not including
system TCP flows, such as LDP or BGP here. These would assumably be
appropriately prioritized).

So, I would have much fewer problems with calling this ID "congestion
control for PWs over the Internet", but definitely object to calling it
"congestion control for PWs".

So, what IS congestion control for PWs ?
Well, due to the unfortunate decision detailed in RFC 3468 and the
interpretation that this limits PWE3 from extending its control protocol to
include BW reservations, we have to accept the situation that PWs are not
properly BW limited.
So, we can't talk about a PW's committed rate (CR), and thus even if we deny
admission when we believe we don't have sufficient BW, we can't properly
enforce CR and excess rate schedules.

What should a congestion framework for a service provider network specify ?
We should be able to enable the PWs to be guaranteed their CR, and to enjoy
excess traffic when BW is available. When congestion occurs, we should be
able to tell the ingress PEs that this is the case, and that they should
police to their CR. If congestion continues, we should exercise fairness
between the PWs - BUT this does NOT mean that all PWs should get the same
BW, rather that the percentage reduction from CR should be the same !

There are many ways that this can be done. Of course, SP networks usually
have central management, and the management may directly instruct ingress
PEs as to their constraints.
However, we can also develop noncentralized mechanisms. In order to obtain
the kind of fairness required, we still us AIMD, but instead of reducing the
flow to half the PRESENT rate, we need to multiply it by a percentage of the
CR (or whatever we desire to call it here).

Second topic.
The tutorial material on TCP congestion control and TFRP are useful, but I
believe that they miss the main point for PWs.
TCP flows end up approximately equally sharing the BW (rather than the
fairness I defined above) because of the basic assumptions of the model, not
solely because of AIMD. 
Each TCP flow is assumed to be atomic,
all flows are assume equally important (i.e. to have the same CR), and the
TCP flows are assumed to emanate from an end-user box where the
back-pressure can be used to hold up the application.
It is this set of assumptions along with the AIMD mechanisn that leads to
the TCP rate equation.
Were an Ethernet PW carrying TCP/IP to be in parallel to TCP flows, then
loss of a single PW packet would translate to loss of a TCP packet of a
single socket pair, and thus lead to a much smaller reduction in PW capacity
(which I assume is what the authors mean by "equivalent number of TCP
flows").
Similarly, were we to weight the flow importance, we could get different
flow rates.

On the other hand PWs emanate from PEs that can not usually perform
back-pressure and need to police by dropping packets. Furthermore, as stated
above, fairness does not mean that we allot the same BW to the PWs - instead
we need to allot CRs and police to these. 
This is more direct and easier to understand and configure than the nebulous
concept of "equivalent number of TCP flows".

There is a statement about MOST (99%?) PWs carrying TCP/IP traffic.
This certainly needs qualification. I have been involved in many network
deployments where NONE of the PWs carry TCP/IP. 

There is a statement about the possibility of sending PWs over IPsec
tunnels.
It is unclear to me what this means. IPsec is most commonly used for TCP/IP
traffic, and thus if you use IPsec then you probably already have the
behavior you need.
On the other hand, there are PW encapsulations that use UDP/IP which could
potentially be put in IPsec tunnels. But these are the TDM encapsulations,
that can not fall back at all.
Finally, perhaps the ID means some new encapsulation of PW over RFC4023 over
IPsec.
If so, it would be nice to have this stated, and to explain how this works.

The drawbacks the draft mentions regarding using the sequence numbers to
detect packet drop seem artificial. Yes, misordering can masquerade as
packet drop if the delayed packet is very late. But no method is perfect.
BTW, for TDM PWs packet arrival times can also be used as a very senstive
mechanism to detect imminent congestion.

The draft needs a serious edit. There are numerous typos (newtork?) and in
several places whole words seems to have dropped (due to congestion, no
doubt).

Y(J)S