Subject: Proposed change to 5..4.1 of PWE3 architecture

From: Stewart Bryant <[email-masked]>
Date: Fri, 19 Mar 2004 16:36:33 +0000

After discussions with Yaakov Stein regarding the use of UDP/IP
as a PW mechanism (used by both TDM approaches), it is proposed
that 5.4.1 be amended as shown below.

Is this acceptable to the WG?

- Stewart

New text:

5.4.1. PWE3 over an IP PSN

    The protocol definition of PWE3 over an IP PSN should employ existing
    IETF protocols where possible.

        +---------------------+              +-------------------------+
        |      Payload        |------------->| Raw payload if possible |
        /=====================\              +-------------------------+
        H Payload Convergence H-----------+->|     Flags, seq # etc    |
        H---------------------H          /   +-------------------------+
        H       Timing        H---------/--->|            RTP          |
        H---------------------H        /     +-------------+           |
        H     Sequencing      H----one of    |             |
        \=====================/        \     |             +-----------+
        |  PW Demultiplexer   |---------+--->|     L2TP, MPLS etc.     |
        +---------------------+              +-------------------------+
        |  PSN Convergence    |------------->|       Not needed        |
        +---------------------+              +-------------------------+
        |        PSN          |------------->|            IP           |
        +---------------------+              +-------------------------+
        |      Data-link      |------------->|         Data-link       |
        +---------------------+              +-------------------------+
        |       Physical      |------------->|          Physical       |
        +---------------------+              +-------------------------+

      Figure 10: PWE3 over an IP PSN

    Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a
    rule, the payload should be carried as received from the NSP, with
    the Payload Convergence Layer provided when needed.  However in
    certain circumstances it may be justifiable to transmit the payload
    in some processed form. The reasons for this must be documented in
    the Encapsulation Layer definition for that payload type.

    Where appropriate, explicit timing is provided by RTP [RFC3550],
    which when used also provides a sequencing service.  When the PSN is
    UDP/IP, the RTP header follows the UDP header and precedes the PW
    control field, while for all other cases the RTP header follows the
    PW control header.

    The encapsulation layer may additionally carry a sequence number;
    sequencing is to be provided either by RTP, or by the PW
    encapsulation layer but not both.

    PW Demultiplexing is provided by the PW label, which may take the
    form specified in a number of IETF protocols,  e.g. an MPLS label, an
    L2TP session ID, or a UDP port number.

    When PWs are carried over IP the PSN Convergence Layer will not be
    needed.

    As a special case, if the PW Demultiplexer is an MPLS label, the
    protocol architecture of section 5.4.2 can be used instead of the
    protocol architecture of this section.
=======================================================================

For reference the following is the text that appears in the -06 draft.

5.4.1. PWE3 over an IP PSN

    The protocol definition of PWE3 over an IP PSN SHOULD employ existing
    IETF protocols where possible.

        +---------------------+              +-------------------------+
        |      Payload        |------------->| Raw payload if possible |
        /=====================\              +-------------------------+
        H Payload Convergence H-----------+->|        As Needed        |
        H---------------------H          /   +-------------------------+
        H       Timing        H---------/--->|            RTP          |
        H---------------------H        /     +-------------+           |
        H     Sequencing      H----one of    |             |
        \=====================/        \     |             +-----------+
        |  PW Demultiplexer   |---------+--->|     L2TP, MPLS etc.     |
        +---------------------+              +-------------------------+
        |  PSN Convergence    |------------->|       Not needed        |
        +---------------------+              +-------------------------+
        |        PSN          |------------->|            IP           |
        +---------------------+              +-------------------------+
        |      Data-link      |------------->|         Data-link       |
        +---------------------+              +-------------------------+
        |       Physical      |------------->|          Physical       |
        +---------------------+              +-------------------------+

      Figure 10: PWE3 over an IP PSN

    Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a
    rule, the payload SHOULD be carried as received from the NSP, with
    the Payload Convergence Layer provided when needed.  (It is accepted
    that there MAY sometimes be good reason not to follow this rule, but
    the exceptional circumstances need to be documented in the
    Encapsulation Layer definition for that payload type).

    Where appropriate, timing is provided by RTP [RFC3550], which when
    used also provides a sequencing service.  PW Demultiplexing may be
    provided by a number of existing IETF tunnel protocols.  Some of
    these tunnel protocols provide an optional sequencing service.
    (Sequencing is provided either by RTP, or by the PW Demultiplexer
    Layer, but not both).

    RTP is normally carried over UDP, however the tunnel protocols that
    are capable of carrying a PW, provide sufficient functionality to
    carry RTP without an intervening transport layer.  UDP MAY therefore
    be omitted from the protocol stack.

    A PSN Convergence Layer is not needed, because all the tunnel
    protocols shown above are designed to operate directly over an IP
    PSN.

    As a special case, if the PW Demultiplexer is an MPLS label, the
    protocol architecture of section 5.4.2 can be used instead of the
    protocol architecture of this section.

=========================================================================

---

From: "Ron Cohen" <[email-masked]>
Date: Fri, 19 Mar 2004 09:29:55 -0800

Stewart,

Since we no longer have a PSN convergence layer either in IP or in MPLS,
I suggest we remove it altogether.

In reference to:

I find this disturbing. Either people have the ECMP or ECMP-like problem
here as well or they don't. If they do we should better know this in
advance on not find out after another year has passed. 

Following that, I suggest that we change the layering diagram such that
the layers include only: Physical, Data-link, PSN, PW-Multiplexing,
Payload Convergence, Payload (where payload convergence include timing,
sequencing, etc but the decomposition is not explicitly shown on the
figure). The payload convergence includes RTP and the control word. 

We write a single architecture layer section which is good for both IP
and MPLS, since we don't specify the internal order of RTP and Control
word within the convergence layer in this section.

We write another section that describes the Convergence layer
decomposition and specify (unfortunately) that the RTP and control word
order changes depending on the demulplexing layer. If MPLS is used as
demultiplexing layer RTP is after control word, else RTP before control
word, or whatever)

Regards
Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant
> Sent: Friday, March 19, 2004 8:37 AM
> To: [email-masked]
> Subject: [PWE3] Proposed change to 5..4.1 of PWE3 architecture
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 19 Mar 2004 19:17:05 +0000

Ron

Please see inline:

> I suggest we remove it altogether.

The reserved nibble and the length are both PSN convergence elements
of the CW, and so there is still a need for MPLS PSN convergence.

> advance on not find out after another year has passed. 

I am not quite sure I follow your argument. The proposed change is
in the IP section, and there is no ECMP issue in IP unless you
run per packet ECMP, but that breaks so many other things that in
practise no one runs it.

> demultiplexing layer RTP is after control word, else RTP before control

How important are these changes?

If we make this level of change we really risk a significant delay in
getting the document back to the IESG, and since this document gates all
the encapsulation and control drafts we delay them also.

Perhaps it would be better to rule Yaakov's proposal out of scope
for a draft that has already passed last call on this text?

- Stewart

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 21 Mar 2004 16:47:04 +0200

> > Following that, I suggest that we change the layering diagram such 
> > that the layers include only: Physical, Data-link, PSN, 
> > PW-Multiplexing, Payload Convergence, Payload (where payload 
> > convergence include timing, sequencing, etc but the decomposition is

> > not explicitly shown on the figure). The payload convergence
includes RTP and the control word.
> > decomposition and specify (unfortunately) that the RTP and control 
> > word order changes depending on the demulplexing layer. If MPLS is 
> > used as demultiplexing layer RTP is after control word, else RTP 
> > before control word, or whatever)
> 
> If we make this level of change we really risk a significant 
> delay in getting the document back to the IESG, and since 
> this document gates all the encapsulation and control drafts 
> we delay them also.
> 
> Perhaps it would be better to rule Yaakov's proposal out of 
> scope for a draft that has already passed last call on this text?

While I think that Ron's suggestions 
(having first a common section, and thereafter separate IP and MPLS
ones)
are sensible, they seem to be basically editorial in nature.

At this late date I wouldn't want to hold everything up for
such editorial changes.

On the other hand, the use of UDP/IP has been in our
charter from the very beginning, even if most of the work
has been MPLS-oriented. 

I would therefore object to removing the use of pure UDP/IP
from the architecture document.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 21 Mar 2004 17:07:43 +0200

Stewart, Ron and all,
Please see inline below.

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

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Friday, March 19, 2004 9:17 PM
> To: Ron Cohen
> Cc: [email-masked]
> Subject: Re: [PWE3] Proposed change to 5..4.1 of PWE3 architecture
> 
> 
> Ron
> 
> Please see inline:
> 
> Ron Cohen wrote:
> 
> > Stewart,
> > 
Not that this is really important - but I'd say that there is 
need of the PSN convergence layer in case of MPLS because
it there neither protocol nor length in the MPLS iself, and
this layer is represented by the reserved first nibble and LEN field
of the CW.  
> > advance on not find out after another year has passed. 
I assume that the intention here was to treat MPLS in IP or GRE as
an a special case of PW over IP. If this is correct, I find the 
situation where the demultiplexing "tail" wags the tunneling "dog"
somewhat worrying: e.g., if you suddenly need the PSN convergence
layer (i.e., the reserved nibble and the LEN field) with an IP PSN! 
> run per packet ECMP, but that breaks so many other things that in
... snipped ...
> >>    control field, while for all other cases the RTP header 
The original reason for placing RTP after the CW in case of MPLS
was the need to make the encapsulation ECMP-safe (plus the worry
about 0100 in the first nibble being allocated by IANA for some
experiment ages ago without any evidence of existing
deployments anywhere). Since this need does not exist for an 
IP PSN (as explained by Stewart above), I do not see any need 
in one more "branch" ( aspecial rule for UDP demultiplexing vs. 
another rule for, say L2TPv3 demultiplexing).
... snipped to the end ...

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 21 Mar 2004 17:09:12 +0200

Yaakov, Stewart, Ron and all,
Please see inline below.

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Sunday, March 21, 2004 4:47 PM
> To: [email-masked]; Ron Cohen
> Cc: [email-masked]
> Subject: RE: [PWE3] Proposed change to 5..4.1 of PWE3 architecture
> 
...
> from the architecture document.
[Sasha] I concur.

---

From: "Ron Cohen" <[email-masked]>
Date: Sun, 21 Mar 2004 12:11:46 -0800

1. Never suggested to remove support for IP/UDP encapsulation. Where did
this come from?

2. It seems more consistent to have the order of RTP and control word be
dependent on the demultiplexing layer (MPLS vs. L2TP or UDP) and not PSN
layer (IP or MPLS), as potentially the PSN layer tunneling technique may
change along the path without a need to change the upper payload
convergence layer. As a minimal change I therefore suggest to change the
'can' to a 'must' in the following text:

3. The rest of the changes I suggested are editorial.  

Ron

> Behalf Of Sasha Vainshtein
> Sent: Sunday, March 21, 2004 7:09 AM
> To: 'Yaakov Stein'; [email-masked]; Ron Cohen
> Cc: [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Mar 2004 09:35:29 +0000

Following Ron's input, the proposed new text for 5.4.1 is:

    As a special case, if the PW Demultiplexer is an MPLS label, the
    protocol architecture of section 5.4.2 must be used instead of the
    protocol architecture of this section.

========================

This differs from the previous CHANGED text in the last sentence in that
it used to read "section 5.4.2 can be used" and now reads "section 5.4.2
must be used"

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 22 Mar 2004 12:18:30 +0200

Stewart and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> Sent: Monday, March 22, 2004 11:35 AM
> To: [email-masked]
... snipped ...
>     control field, while for all other cases the RTP header 
[Sasha] I do not think that UDP/IP is a special kind of PSN (at least the WG

Charter does not say so). And I do not see any reason for difference in
the relative position of the CW and RTP headers for any kind of
demultiplexing 
over an IP PSN with the possible exception of MPLS-in-IP as noted in the
last
para of this section.
>     L2TP session ID, or a UDP port number.
[Sasha] IMO explicit references to MPLS-in-IP and L2TPv3
specs would be helpful here.
>     protocol architecture of this section.
[Sasha] The above-mentioned explicit reference to the MPLS-in-IP spec
would make it clear that using an MPLS label as a demultiplexer actually
makes PWs using them MPLS PWs regardless of the actuall tunneling mechanism.

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 22 Mar 2004 13:06:49 +0200

> 1. Never suggested to remove support for IP/UDP 
> encapsulation. Where did this come from?

This is what Stewart suggested if the changes were too radical.

> 2. It seems more consistent to have the order of RTP and 
> control word be dependent on the demultiplexing layer (MPLS 
> vs. L2TP or UDP) and not PSN layer (IP or MPLS), as 
> potentially the PSN layer tunneling technique may change 
> along the path without a need to change the upper payload 
> convergence layer. As a minimal change I therefore suggest to 
> change the 'can' to a 'must' in the following text:
> 

The reason the differentiation was based on IP was simple.
In the IP world the RTP header has a well-known location,
and it is not for use to change this, although it is inconvenient
for the MPLS case. Hence we based the decision on IP vs MPLS.

However, I agree that your comment is valid and it is more consistent to

base the positioning on the multiplexing layer.  I am just wondering
if anyone else has a problem with this (AVT or L2TPEXT WGs ...)

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 22 Mar 2004 13:21:18 +0200

> [Sasha] The above-mentioned explicit reference to the 
> MPLS-in-IP spec would make it clear that using an MPLS label 
> as a demultiplexer actually makes PWs using them MPLS PWs 
> regardless of the actual tunneling mechanism.

That's the problem!

I know that I have lost this battle multiple times,
but I still don't buy the idea that the obvious tactic of using 
a double word header as the PW demux label  
makes the PSN into MPLS.

In particular, does the use of this format for the PW label
mean that one MUST support label stacking?
(I don't see how you can rule that out in an MPLS network.)

Does it rule out non-LDP control protocols for PW setup?

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 22 Mar 2004 15:14:47 +0200

Yaakov, Stewart and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, March 22, 2004 1:21 PM
> To: Sasha Vainshtein; [email-masked]
> Cc: [email-masked]
I am not sure I follow you. Stewart's text (to which my comment
refers) says:

<quote>
<end quote>

Let's start from a simple point: if PW label over an IP PSN
is an MPLS label, what protocol number must be set in
the IP header of the corresponding packets?

I see two options:

1) It is MPLS-in-IP protocol number (still to be assigned by IANA).
   If this is the case, then MPLS-in-IP encapsulation mechanism
   as described in draft-ietf-mpls-in-ip-or-gre-07 fully applies.
   Of course in this case the demultiplexor is an MPLS label, and,
   IMO, this is the only way to use an MPLS label as a demultiplexer
   for PWs over an IP PSN.

2) It is some new, not yet specified protocol (let's call it
   PW-in-IP). If this is the case, you may use any 32-bit 
   demultiplexer (a.k.a PW label) you wish but, IMHO, you 
   MUST NOT call this demultiplexer an MPLS label.
   (Of course, it would be also nice to specify such a protocol
   and to provide justification for adding it to the 
   set of already existing tunneling mechanisms.:-)
> (I don't see how you can rule that out in an MPLS network.)
Of course, I may be totally wrong, but, IMHO, you are asking
the following question:

	Is it possible to terminate MPLS-in-IP PWs in PEs that
	do not support MPLS?

The answer depends on what you are going to do with such a device:
- you clearly cannot use it in MPLS networks
- you can, IMO< easily use it in IP networks for termination of MPLS-in-IP
  PWs.
> Does it rule out non-LDP control protocols for PW setup?
IMO, no. You can always use manual PW setup.

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 22 Mar 2004 18:11:15 +0200

Sasha,

As conventional, my remarks are in-lined. 

<snip>
> is an MPLS label, what protocol number must be set in the IP 
> header of the corresponding packets?
> 
> I see two options:
> 

This is the same debate we had regarding Ethertypes
in another forum ...

It seems obvious to me that when using UDP/IP the IP protocol type 
is set to obviously 11H, signifying UDP. Then the UDP destination
port MUST be set to an application identifier assigned
by IANA to the PW type being used. As you know,
IANA has assigned 085EH to TDMoIP for this purpose.
We should request port numbers for the various PW types.

If you choose NOT to use UDP, rather L2TP,
then the protocol is set to 73H. 
Similarly, if use use MPLS-in-IP, then you use 
whatever IANA decides.

The question arises - where is the PW label 
for the UDP case? Well, this is the function of the UDP
port, but that has already been taken, so the only sensible
thing to do is to use the UDP source port.

This actually makes a lot of sense, since it 
1) allows standard use of the UDP destination port
   (solving the problem you raised)
2) doesn't require an additional field (there is already a 
   16 bit field sitting there...)
3) according to our standard use the PW label is a 
   downstream (source) identifier.

> 	Is it possible to terminate MPLS-in-IP PWs in PEs that

Why such a complex way of reading an easy question.
You stated (and have defended this view in the past)
that by using an MPLS-like label, we are effectively creating
an MPLS network. In that case, the network has to act like an MPLS
network.
 
> - you can, IMO, easily use it in IP networks for termination of
MPLS-in-IP PWs.

... or could you terminate the IP layer and launch the MPLS packets
into an MPLS network ?

> IMO, no. You can always use manual PW setup. 

Yes, of course. But I was asking whether alternative
control PROTOCOLS are ruled out. 

Although UDP/IP has been with us in PWE from the beginning,
we have tacitly assumed MPLS in almost everything we have done.
In particular, the control protocol is LDP based.

Of course, there is nothing wrong with using targetted LDP
in a pure IP network for this purpose. But perhaps we may want
to do something else (I intend writing a draft before the next
meeting on this subject).

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 22 Mar 2004 18:32:41 +0200

Sasha, 

<snip>
> Sorry, but I do not follow you. The ORIGINAL question
> (AFAIK) has been usage of an MPLS label as  a demultiplexer 
> (a.k.a. PW label) in PWs over an IP PSN. I have suggested 
> that the (only, IMO) correct way to do that is by using 
> MPLS-in-IP (with all the implications). How is your 
> explanation above related to that?

The original question (AFAIK) was where to put the PW
label in the UDP/IP case, and what effect that decision
has on the protocols.

I suggested that there was no good reason
to interpose an MPLS-like label
(except in cases where 16 bits are not enough, but 20 are).

(Similarly, although off-topic here,
 I think that VLAN tags could be used,
 assuming that 4K labels are enough.)

> I'd say that the control protocol for distribution of PW 
> labels depends on the nature of these labels. E.g., LDP is 
> one of the native choices for distributing MPLS labels 
> serving as a PW label; and L2TPv3 uses its own way of 
> distributing Session IDs.

I'll go along with that, except that for pure UDP/IP
we don't have a protocol yet.

> In both cases the point is not inventing a new protocol.
> IMO, if you want to use UDP as the demultiplexing layer, and 
> define correctly which UDP port is used as the demultiplexer, 
> you can reuse some suitable protocol as well.

What do you mean by correctly (source or destination) ?

What protocol do you suggest?

Y)J(S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 22 Mar 2004 18:20:53 +0200

Yaakov and all,
Please see inline.
With best regards,
                                   Sasha Vainshtein

> Sent: Monday, March 22, 2004 6:11 PM
> To: [email-masked]; Sasha Vainshtein
> Cc: [email-masked]
MPLS-in-IP (with all the implications). How is your explanation
above related to that?
> thing to do is to use the UDP source port.
This is a different question that has not been even asked 
in the architecture document. I suggest to discuss it in another 
thread. As you know, I keep different opinion wrt to what
does and what does not makes sense here. 
... snipped ...
> meeting on this subject).
I'd say that the control protocol for distribution of PW labels
depends on the nature of these labels. E.g., LDP is one of
the native choices for distributing MPLS labels serving as a
PW label; and L2TPv3 uses its own way of distributing Session IDs.
In both cases the point is not inventing a new protocol.
IMO, if you want to use UDP as the demultiplexing layer, and
define correctly which UDP port is used as the demultiplexer, you
can reuse some suitable protocol as well.

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 23 Mar 2004 10:41:48 +0200

Yaakov and all,
Please see some answers inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, March 22, 2004 6:33 PM
> To: Sasha Vainshtein
> Cc: [email-masked]; [email-masked]
This may well be so. However, it did not, IMHO, leave any mark
in the text of the updated architecture draft beyond the basic 
point of declaring UDP as a valid PW demultiplexer mechanism for 
IP PSNs. As I have said already, I support this.
>  assuming that 4K labels are enough.)
Sorry, I did not understand that - neither from the text of
the draft nor from the previous emails.
Just to make this point clear: do you object to using MPLS-in-IP 
as a valid mechanism for PWs over an IP PSN?
> we don't have a protocol yet.
I agree. 
> What do you mean by correctly (source or destination) ?
I think that using source UDP port as the PW demultiplexer, 
does not match the PWE3 architecture, while the destination UDP 
port for the same purpose does. 

I suggest to move this discussion to a separate email thread 
because it is not, IMO, related to the contents of Section 5.4.1 
of the PW Architecture draft as this Section stands now.
> What protocol do you suggest?
I am not sure that one is needed. I have not found a suitable
existing protocol (but, maybe, my search went wrong:-), and
development of a brand new protocol with properties similar to
these of the L2TPv3 control plane does not seem justified.
(At the moment even the requirements for such a protocol have
not been clearly specified, but I believe that they should
include reliable transport, tie-breaking, ability to convey
status of attachment circuits etc. - in short, they would
be very similar to any other control protocol with the only
difference being the pool from which the PW demultiplexers
are allocated).

So if you need a control plane for PWs over IP - and I believe
one is often required, and if the requirements for such a control
plane are similar to thoses met by the L2TPv3 control plane,
why not to use L2TPv3 in the data plane as well and save the
development effort?

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 23 Mar 2004 11:32:29 +0200

> Just to make this point clear: do you object to using 
> MPLS-in-IP as a valid mechanism for PWs over an IP PSN?

No, I believe MPLS-in-IP is a valid mechanism.

<snip>

> does not match the PWE3 architecture, while the destination 
> UDP port for the same purpose does. 

If by PWE architecture you mean what is stated in the PWE3 architecture
draft,
then I would like to see where precisely in the architecture draft you
see
anything relevant.

The whole issue started by my stating that I couldn't find
anything in the architecture draft that mentioned the use
of UDP ports, one way or the other.

> development of a brand new protocol with properties similar 
> to these of the L2TPv3 control plane does not seem justified.

I assume that you agree that one is needed for MPLS
and for L2TP, so why is it not clear that one is needed here?
 
> not been clearly specified, 

They have been specified as clearly as they have been for MPLS.

> but I believe that they should 
> status of attachment circuits etc. - in short, they would be 
> very similar to any other control protocol with the only 
> So if you need a control plane for PWs over IP - and I 
> believe one is often required, and if the requirements for 
> such a control plane are similar to thoses met by the L2TPv3 
> control plane, why not to use L2TPv3 in the data plane as 
> well and save the development effort?

So we agree that a control protocol is required.

I am not ruling out use of L2TP, but I believe that pure UDP/IP
is a perfectly valid data payload format, and one that I have been
tacitly assuming all along (see all versions of draft-anavi).

Y(J)S