Subject: What is PWE3 chartered to do?

From: George Swallow <[email-masked]>
Date: Fri, 28 Mar 2003 11:22:05 -0500

The PWE3 charter says in part:

"The basic idea of this working group is to develop standards for the
encapsulation and service emulation of pseudo wires: encapsulating
service-specific PDUs arriving at an ingress logical port and carrying
them across a tunnel, managing their timing, order or other aspects
entering and leaving the tunnel, to emulate the behavior and
characteristics of the service as well as possible."

Note that in this paragraph, nor anywhere else in the charter does it
say, "redefine the PSN service" It does say "develop standards for
encapsulating service-specific PDUs ... managing their ... order
... leaving the tunnel, to emulate the behavior and characteristics of
the service as well as possible."

MPLS provides several services.  With RSVP-TE one can define a single
explicit route through a network that offers a service which includes
ordered delivery.

Another service is to offer the equivalent of IP datagrams.  When MPLS
first started there were proposals to carry labels in every routing
protocol.  It was decided that it would be simpler, and in most cases
technically superior to have a single protocol - LDP - to carry those
labels.  

The IP service is connectionless.  It does not guarantee that packets
will flow over the same path, nor does it offer a  guarantee of
ordered deliver.  However, if certain conventions are followed, ones
chances of getting packets delivered in order are greatly increased,
i.e. pretty much guaranteed in the presence of stable routing.

It behooves the user of the service to follow those conventions.  The
PWE3 charter instructs us to define encapsulations to "manage the
order of packets leaving the tunnel".

So this would be my proposal for doing so:

For any PWE3 control header, define the first nibble of the first word
as a format identifier with the following values:

Value 0 = control word as defined in PWE Arch, data

       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 0| Flags |FRG|  Length   | Sequence Number               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Value 1 = control word as defined in PWE Arch, OAM

       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| Flags |FRG|  Length   | Sequence Number               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note:  The sequence number would either be unused or used to mark the
position in the sequence, that is, carry the same value as the last
data PDU sent.

Value 2 = PPP PID 

       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 1 0|  reserved             | PPP DLL Protocol Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As defined by PID                          |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Values 3 - 15 = Reserved.

New PPP DLL Protcol numbers would then be defined to indentify the
further contents, such as the Sonet encaps. 

...George

======================================================================
George Swallow          Cisco Systems                   (978) 497-8143
                        250 Apollo Drive
                        Chelmsford, Ma 01824

---

From: [email-masked]
Date: Fri, 28 Mar 2003 19:39:34 -0000

George, some important observations in-line.  regards, Neil (speaking with
his BT operator's hat on to be clear in case someone thinks I don't
represent BT views here).

George Swallow wrote 28 March 2003 16:22
> characteristics of the service as well as possible."

NH=> This is almost G.805-speak for client/server layer adaptation.  One
things we are very keen to see here are clean client/server architectures,
such that the client (X) and server (Y) layers are independent.  X/Y
relationship flexibility is an obvious requirement (subject to 'does it make
sense to carry specific X over specific Y?'), but we also want to allow X
and Y to be added/changed/sunsetted independently.  A further requirement is
minimisation of functions that lie between X and Y, ie keep the adaptation
simple.  This means that if X or Y is functionally deficient then fix X or Y
as necessary, but please don't start bolting-on functions in the adapation
process.  Currently there is a whole raft of stuff being proposed to go in
here that we would simply not want.
> say, "redefine the PSN service"
NH=> Is 'PSN service' defined somewhere?

> It does say "develop standards for
> Another service is to offer the equivalent of IP datagrams.
NH=> MPLS cannot do this.....the signature of a cnls pkt is that it must
possess a SA/DA pair and be routable from any network location (within the
bounds where the SA/DA are valid, and subject to TTL exhaust).  A MPLS pkt
in a LSP does not allow this because such pkts contain link-connection
identifiers and not addresses.

>  When MPLS
> protocol.
NH=> Link-state routing functions would make little sense in proxying for
the signalling function.....that is why they are unsuitable.

> It was decided that it would be simpler, and in most cases
NH=> I'd hardly call LDP 'technically superior'!  It for sure introduces
problems that have no need to exist (since you can address all applications
of interest with either a proper IP/cnls mode or a proper MPLS/p2p mode).
In any case, there is not a single MPLS signalling protocol:  There are at
least 3 mutually disjoint MPLS networks, characterised by the signalling
protocols they use, viz: RSVP-TE, LDP and BGP4.  The former 2 are proper (?)
signalling protocols, whereas the latter is a routing protocol that is being
asked to perform a signalling function (which it can because it is not
link-state).  So there is no such thing as a single MPLS protocol/network.
> 
> The IP service is connectionless.
NH=> Yes, but MPLS is not despite what some falsely claim.  This is more
obviously true for RSVP-TE but it is also true for LDP.  This is apparent
from the fact that MPLS (all cases) uses link-connection identifiers that
only have network currency when allocated to a parent LSP.  The problems
start when you try and make what is essentially a co pkt-sw forwarding
behaviour act like it has a cnls behaviour.  This is why whenever LDP is
used it has a forced requirement to have a p2p LSP above the mp2p LSP.  What
is going on architecturally here is that the label in the mp2p LSP is
proxying for a DA function in IP, whilst the label in the p2p higher level
LSP is proxying for the SA function in IP (this is indeed how one starts to
recover from the effect of merging).   However, the fault-behaviour when
using a co pkt-sw forwarding mode is very different to that of a proper cnls
mode, as no doubt I am sure you understand George, eg misdirect a pkt in a
cnls mode and it can self-correct (SA/DA always unique), but misdirect a pkt
in an LSP and it won't self-correct in the general case (it either
black-holes or gets misrouted to the sink of some other LSP).  I wish people
would stop pretending MPLS and IP are the same.....it's just not true.  And
that is one of the main problems we see with the PWE work.  There is
actually no need to try and force identical solutions for carrying X over IP
and X over MPLS. 

>  It does not guarantee that packets

NH=> What makes you think having to manage this 'in-between' layer with it's
own OAM should be considered 'good' by an operator George?  We still have to
manage the client X and we still have to manage the server Y...and we
certainly want to do this properly.  However, we for sure don't want to see
lots of functions added between X and Y that we also have to manage too,
perhaps to try and compensate for defficiencies in either the client or the
server layers....however, get these right and only minimalist adaptation is
required.
<snipped to end NH>

---

From: George Swallow <[email-masked]>
Date: Fri, 28 Mar 2003 15:02:30 -0500

> identifiers and not addresses.

When I as a router hand out an LDP label with a FEC that has an IP
prefix then I expect to be able to treat the labeled object the same
whay that I treat a packet that has a destination address within that
prefix.

> the signalling function.....that is why they are unsuitable.

Correct.

> link-state).  So there is no such thing as a single MPLS protocol/network.

I did not make this claim.  Only that we did LDP instead of attempting
to muck with every IGP.

> NH=> Yes, but MPLS is not despite what some falsely claim.  This is more

Dream on.  Or get real.

> in an LSP and it won't self-correct in the general case (it either

The point I'm making has nothing to do with mis-directing and self
correct.  It is simply that when I have an LDP label with a FEC of IP
prefix, I can change my notion of next hop at any time (note I will
adjust the next hop label as well) and I can do ECMP.

> NH=> What makes you think having to manage this 'in-between' layer

I sent this message to PWE.  I'm not proposing an 'in between' layer.
I'm proposing a format identifier for the PWE header.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Peter Willis <[email-masked]>
Date: Mon, 31 Mar 2003 10:04:55 +0100

> > NH=> Yes, but MPLS is not despite what some falsely claim.  This is more

Without getting emotional or religious about whether MPLS is CNLS or CO lets 
just look at the problems a network operator faces.

With traditional IP routing if I get a fault then at a router I can look in 
the routing table I know where a packet is going irrespective or where it had 
come from. I can even look at IP packets as they arrive and know where they 
had come from and where they are going to. So fault finding is easy 
(relatively speaking).

With LDP MPLS when I get a fault I can not by inspection at one router 
determine where the MPLS packet has come from or where it has gone to. What I 
have to do it logon to all the routers from the ingress to the egress, check 
the label tables, and build a table off-line as to what is happening. So we 
(BT) run a script to do this.

So the point is that although an MPLS LDP cloud from the outside behaves just 
like an IP CNLS cloud when its working when it breaks it requires very 
different methods to fix it. And its the cost of operating (which includes 
fixing) networks that is important to network operators not whether the
 protocol is CO or CNLS.

As regards "in-between" layers perhaps the whole of PWE3 is an "in-between" 
layer and as such we have to recognise running PWE3 adds costs. So before 
someone decides to use PWE3 they have to weigh the costs of operating another 
layer of functions against what it's saving elsewhere. If we keep adding 
functions and cost to PWE3 it becomes less attractive to use. (Apologies for 
stating the obvious!)

Regards,
Peter.

---

From: George Swallow <[email-masked]>
Date: Mon, 31 Mar 2003 13:07:52 -0500

Peter -

> fixing) networks that is important to network operators not whether the

Agree completely with all you said.  But I still maintain that the
service (after all the service is what you get when its working!) is
CNLS.  In particular, every CO service I know of delivers packets in
order, whereas LDP may not.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 936-1398
                     250 Apollo Drive
                     Chelmsford, Ma 01824