Subject: RE: ITU-T Q5/13 Liason re PW over UDP

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 Jul 2004 20:26:49 +0300

> So, now  I see  why you  want to pursue  this!  Are  you 
> submitting  a draft specifying the signaling procedures? 

I could.  But the obvious solution is to use standard PWE
signaling based on targeted LDP.

Y(J)S

---

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Jul 2004 13:39:57 -0400

> the obvious  solution is to use  standard PWE signaling  based on targeted
> LDP

That results  in an exchange  of MPLS labels  for the pseudowire,  while you
seem to  be asking for  something which results  in an exchange of  UDP port
numbers.

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 Jul 2004 20:50:00 +0300

> > the obvious  solution is to use  standard PWE signaling  based on 
> > targeted LDP
> 
> That results  in an exchange  of MPLS labels  for the 
> pseudowire,  while you seem to  be asking for  something 
> which results  in an exchange of  UDP port numbers. 

Precisely.

Of course we need to remember that UDP port numbers
have fewer bits than MPLS labels, but there is no other
major difference.

Similarly, PWE signaling could be used for exchanging
VLAN tags (which we aren't handling here at the IETF,
but other forums are).

This would result in a single label distribution protocol
no matter where the demux labels are in the PSN headers.

Y(J)S

---

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Jul 2004 14:11:22 -0400

> have fewer bits than MPLS labels, but there is no other

Are you suggesting that UDP port  numbers should be encoded into LDP's label
TLVs?  Since a UDP  port number and an MPLS label can  have the same numeric
value, that seems severely broken.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 1 Jul 2004 14:40:00 -0400

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Thursday, July 01, 2004 1:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [PWE3] ITU-T Q5/13 Liason re PW over UDP 
> 
> 
>  

Yaakov,

I would turn your argument around. If, as you say, a label id is just a number, why not standardize on one specific format, i.e. MPLS labels. For the encapsulation function the label format may not have major implications, but for packet switches in the middle it does. 

Therefore, don't extend the label distribution protocol to support additional label formats, but standardize all packet switching applications on one single label format.

Peter

> Y(J)S
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Fri, 2 Jul 2004 07:38:05 +0100

Peter,
> I would turn your argument around. If, as you say, a label id 
> is just a number, why not standardize on one specific format, 
> i.e. MPLS labels. For the encapsulation function the label 
> format may not have major implications, but for packet 
> switches in the middle it does. 
> 
> Therefore, don't extend the label distribution protocol to 
> support additional label formats, but standardize all packet 
> switching applications on one single label format.
> 
> Peter
NH=> I tend to agree with you and Eric, but I have additional reasons:

As you know, I have some serious reservations about the whole PW concept.  Further, I am a strong believer in understanding/respecting the functional architecture of transport networks and the constraints this imposes on the mode considered.  We did not develop G.805/G.809 for fun.....these are very powerful modelling techniques that are important for the development of management information models.

The efficacy of a layer network is largely determined by the completeness of its functional specification (eg see Tom Nadeaus's remark to me the other day agreeing that OAM should not be an afterthought....this is an example of what I mean here), and whether it respects the connectivity constraints of the mode considered (some types/features on MPLS break these principles and, as a consequence, create operational problems.....however, that is a seperate issue which I do not want to open up here as it is not relevant to this topic).

IP is a cl-ps mode technology and MPLS is a co-ps mode technology.  These are different despite protestations to the contrary (if this was not true then there would be no need for MPLS to exist).  However, both IP and MPLS are layer networks.  UDP is *not* a layer network.  UDP and TCP are the key application adaptation functions of IP (in principle, however, they could be used with other layer networks).

Speaking as an operator I do not see the requirement for carrying (other) layer networks over an application adaptation function (here UDP).  This makes no sense at all to me.

regards, Neil

---

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 2 Jul 2004 17:44:52 +0200

Eric,Yaakov and all,
I agree that LDP is not a good method for distributing UDP ports as PW
demultiplexers because LDP distributes labels and not UDP ports.

I am also not sure that incorporation of LDP into existing low-end
devices using UDP for demultiplexing of PWs is a good idea. A simpler
method would probably suffice.

My 2 c.

Regards,
                     Sasha

-----Original Message-----
From: Eric Rosen
To: Yaakov Stein
Cc: [email-masked]
Sent: 7/1/2004 8:11 PM
Subject: Re: [PWE3] ITU-T Q5/13 Liason re PW over UDP 

> have fewer bits than MPLS labels, but there is no other

Are you suggesting that UDP port  numbers should be encoded into LDP's
label
TLVs?  Since a UDP  port number and an MPLS label can  have the same
numeric
value, that seems severely broken.

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 4 Jul 2004 08:36:53 +0300

> Are you suggesting that UDP port  numbers should be encoded 
> into LDP's label TLVs?  Since a UDP  port number and an MPLS 
> label can  have the same numeric value, that seems severely broken.

I am not sure that we are talking about the same deployment scenario.

The gateways that use UDP port numbers do not use MPLS-like inner
labels.
There are no MLPS labels with which to get confused.

Of course there could be, in principle, a gateway that interfaces
to both PWs using UDP port numbers and to PWs using MPLS labels
(and to a further set of PWs using VLAN tags)
in which case it will either have a label space per interface type,
or will have to divide up a single label space.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 4 Jul 2004 08:40:50 +0300

Peter

We already have more than one single label format,
namely both MPLS labels and L2TP session IDs.

This use of UDP port numbers predated both of these formats,
and is very widely deployed. If we want to remove a format
my vote is to leave UDP and remove the L2TP.

Furthermore, the packet switch in the middle shouldn't
care about inner labels of UDP port numbers.
It should only care about the top of the MPLS stack,
or the IP address.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 4 Jul 2004 08:43:58 +0300

Neil, 

>From what I read in your email, you are simply re-iterating 
your feelings about the advisability of PWs in general.

I didn't see that you have any specific problem with the use of UDP port
numbers.

Do you believe that using UDP port numbers rather than, say, L2TP
session IDs, is more of a architectural problem for carriers?

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 4 Jul 2004 10:12:51 +0200

Yaakov and all,

AFAIK the MPLS labelspace is already partitioned according
to RFC 3031.Thispartictioning includes reserved labels, per-interface
label space and global label space.

The requirement to allocate the PWE3 label from the global
label space is,IMHO, substantial for normal operarion of MPLS PWs.

Inventing a new partitioning of the MPLS label
space is, IMHO not a good idea, neither is it 
within the scope of the PWE3 Charter.

If you want to use an "LDP-like" protocol to distribute
UDP ports, you can do so, but this protocol MUST be ditinct
from LDP, i.e. it cannot use LDP Label Mapping message "as is"
to distribute UDP ports. IMHO it would be also better not to
call it LDP to avoid mis-understanding...

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

> Sent: Sunday, July 04, 2004 7:37 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 4 Jul 2004 11:11:53 +0300

> AFAIK the MPLS labelspace is already partitioned according to 
> RFC 3031.Thispartictioning includes reserved labels, 
> per-interface label space and global label space.

How is this relevant for PW labels?
 
> label space is,IMHO, substantial for normal operarion of MPLS PWs.

Are you saying that the PW labels must be distinct
from MPLS labels used above them?
Not only don't I understand the reasoning for this requirement,
it is also not in the spirit of MPLS.

What you are saying is that all labels in the label stack
must be allocated from the same label space.
This would require a single label registry throughout the network,
something we don't have or want.

> Inventing a new partitioning of the MPLS label space is, IMHO 
> not a good idea, neither is it within the scope of the PWE3 Charter.

I never suggested a new partitioning of MPLS label space.
In fact I said that in almost all cases there is no problem,
and even if we have the unusual case of a gateway connected
to various types of PWs, standard mechanisms could be used.

> If you want to use an "LDP-like" protocol to distribute UDP 
> ports, you can do so, but this protocol MUST be ditinct from 
> LDP, i.e. it cannot use LDP Label Mapping message "as is"

It should be used "as-is".
I agree it should not be called LDP,
it should be called the PWE control (or signaling) protocol.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 4 Jul 2004 11:52:59 +0200

Yaakov and all,
Please see some answers 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: Sunday, July 04, 2004 10:12 AM
> To: Sasha Vainshtein
> Cc: [email-masked]; [email-masked]
> > AFAIK the MPLS label space is already partitioned according to 
[Sasha] This is explained in the next para.
> it is also not in the spirit of MPLS.
[Sasha] 
I suggest you read carefully Section 3.9 thru 3.15 of
RFC 3031 which specifies if not exactly "the spirit of the
MPLS" then, at leat, its architecture.

When a PW packet arrives to the egress PW with several 
labels, these labels will be processed one by one according to the
corresponding entries in the ILM of this PE. Presumably the entries
corresponding to all the "transport" labels will
require the label to be popped and the packet sent to the 
loopback i/f. The transport labels may be global or per i/f
(at least the top one). 
The ILM entry corresponding to the PW label would point to the 
PW IFW (or something like that). 

Since the ILM entry for the PW label is different from the
entries for the transport labels,  *at this point* the PW label MUST 
be different from all the transport labels. 
> something we don't have or want.
[Sasha] I do not understand what in my message could be
interpreted in such a way. Can you please elaborate?

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 4 Jul 2004 13:51:28 +0300

Sasha,

See below. 

> labels, these labels will be processed one by one according 
> to the corresponding entries in the ILM of this PE. 
> Presumably the entries corresponding to all the "transport" 
> labels will require the label to be popped and the packet 
> sent to the loopback i/f. The transport labels may be global 
> or per i/f (at least the top one). 
> The ILM entry corresponding to the PW label would point to 
> the PW IFW (or something like that). 
> 
> entries for the transport labels,  *at this point* the PW 
> label MUST be different from all the transport labels. 

OK, now I understand what you mean, but even for this unusual case
(i.e. a gateway that supports two different kinds of PW) this is not the
only
way it can work.

When the edge router processes the last of the MPLS forwarding labels,
it performs a PHP and sends the packet with only an inner label to the
IWF.

In this case the IWF needn't (shouldn't) know any of the transport
labels,
and the router needn't (shouldn't) know any of the interworking labels.

Even if we assume that the IWF is inextricably coupled to the
forwarding function (perhaps not disallowed by the PWE architecture
document,
but certainly not the ideal solution in many cases)
and maintains a single label space for PW labels and MPLS forwarding
labels, 
this simply means that it must know to allocate labels of the
appropriate size
to the PWs that use UDP port numbers. This is what I meant by requiring
a label range TLV for this case.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 4 Jul 2004 14:39:14 +0200

Yaakov and all,
Please see below.

With best regards,
                                   Sasha Vainshtein

> Sent: Sunday, July 04, 2004 12:51 PM
> To: Sasha Vainshtein
> Cc: [email-masked]; [email-masked]
> (i.e. a gateway that supports two different kinds of PW) this 
> is not the only way it can work.
>
[Sasha] What is so unusual about it? Consider a hub-and-spokes
application where the hub is a full-fledged LSR and, in addition, has to
handle UDP-demultiplexed PWs coming from legacy low-end spokes.
> it performs a PHP and sends the packet with only an inner label to the
[Sasha] PHP is not a mandatory function, just an option. It is only applied
if the "ultimate" LSR (i.e., the egress PE) has explicitly requested
the penultimate LSR to perform it. Some routers I'm aware of never
request PHP. So building on EVERY PE requesting PHP does not look right.
> document, but certainly not the ideal solution in many cases)
>
[Sasha] I do not understand which "forwadring function" you refer to.
The demultiplexer (which presumably applies here) surely supports a
data plane binding between IWF instances and incoming PW labels.
> and maintains a single label space for PW labels and MPLS forwarding
[Sasha] The IWF does not maintain a label space, IMO. The PE does.
> a label range TLV for this case.
[Sasha]AFAIK, the label range only applies to per-i/f labels
for label-controlled cell (ATM) and frame (FR) interfaces.

---

From: [email-masked]
Date: Sun, 4 Jul 2004 13:15:50 +0100

Yaakov,  Please see below.

> and is very widely deployed.
NH=> By whom?  Which carriers are using this, if you are at liberty to disclose this of course.

> If we want to remove a format
NH=> Well, I would tend to agree with you but for completely different reasons, ie I'd like to have all 3 network modes available (though I for sure don't want lots of different technologies per mode in the long-term) and I can see far smarter ways of using all 3 modes in harmony (to solve the QoS (sic) issues) than trying to force 1 mode to do everything (across the range of both public and private services).....this will simply not be optimal.  So I would like MPLS to be both functionally complete and not violate the co-ps mode.  However, to get to this state we simply have to accept that MPLS is not IP, and treat it accordingly.  This is not a technical issue at all IMO, it is simply one of political/religious barriers.

regards, Neil
> It should only care about the top of the MPLS stack,
NH=> As I said in my previous mail, UDP is an application adaptation function.  It was never designed to be an inter-layer network adaptation function.  It does not carry all the functions required for inter-layer network adaptation, eg alignment to arbitrary server layers.  Further, one can easily make the jump (at least in one's mind) from 'adaptation function' to 'layer network'......and then we end up not only having to augment what was previously just an adaptation function (to make it a layer network) but we recurse the problem by now requiring further application adaptation functions to this new layer network.

You can see (and I have seen) folks mulling over the above points wrt GFP and PWs.

IMO we currently have anarchy in the industry as some folks are proposing what I consider to be far from optimal solutions.....and I can also see the interworking problem-space exploding.  I have some ideas on how to stop this madness, but it does require a bit of re-set on how folks think about the 3 modes, and how we should be mapping public and private services to these modes.  I do not believe a 1 mode solution (with loads of QoS classes per mode) is the right answer.  And a (if not 'the') critical problem to solve for operators is this:  "(Given real networks will run at low loads over the vast majority of their operating life) how can we create consistently meaningful services (both public and private), and where the 'service price' is decoupled from the BW used, over a large range of load points".

If we (as a collective body of engineers) cannot provide a network arch that delivers against the above (and this assumes no modal violations and functional completeness) then we are going to slowly bankrupt the industry IMO.  And currently I see us smack on course for doing this.

regards, Neil

---

From: [email-masked]
Date: Sun, 4 Jul 2004 13:15:52 +0100

Hi Yaakov,
> your feelings about the advisability of PWs in general.
NH=> Not really....the issues I have with PWs are actually nothing do to with PWs per se, but stem from deeper and more fundamental architectural aspects, viz:

-	one should respect the connectivity constraints of the 3 modes (else it will cause operational problems)....and here I am specifically referring to the co-ps mode and what is/is-not allowed.  In the co-ps mode you can break its connectivity rules of course (ie mp2p) due to the nature of the link-connection ID in the traffic unit.  In the co-cs mode this is simply not possible (even if you try).  And in the cl-ps mode 'merging' is a non-issue since, by definition of the traffic unit of this mode having a DA/SA pair, one can only ever have 'muxing'.  A corollary of this observation is that the native transport defects of the 3 modes are all different....and hence require different OAM.

-	the functional completeness of the technology for the mode concerned.

-	respecting layer independence between the client and server layer networks.

-	whether arbitrary combinations of client/server relationships are sensible or not (there are 9 possible combinations between the 3 modes)....noting that the adaptation function required is a function of the nature (ie mode) of both the client and the server, ie just like OAM, I do not think a '1 size fits all' adaptation solution is sensible here.  Example:  Alignment adaptation (eg rate decoupling and traffic unit delineation) is quite different if the server technology belongs to the co-cs mode from the other modes.

I could now go through specific examples of the above and explain why breaking the connectivity rules of the mode and a lack of functional completeness causes operational problems, but I think you understand very clearly what I am driving at here.  

IMO PWs are simply some form of client/server adaptation relationship and nothing more.  However, it is the underpinning correctness/completeness of the network architecture that is my major gripe here.
> I didn't see that you have any specific problem with the use 
NH=> I thought I expressed a clear reason why I find proposing using these strange.  However, let me have a another quick go:

We have adaptation functions between layer networks.....the nature of this adaptation function varies depending on the modes of the client and server layer concerned (as I tried to explain above a little).

We also have adaptation functions between applications and the 1st layer network they encounter.  Now IMO UDP, and also TCP,  are the primary 'application to 1st layer network adaptation functions' for an IP layer network (they could be used with other layer networks in theory of course) to cater for the 3 major application traffic types, viz: messages, files and streams.

So, it seems very bizarre (to me anyway) to want to have a client layer network running over UDP.....and I wonder what functional changes might suddenly becomes required in UDP?  Maybe others don't think this is strange but I do.  But hey, in world where some folks think SDHoverIP makes sense then what do I know!
> session IDs, is more of a architectural problem for carriers?
NH=> I think many things that are being done/proposed are going to create problems for carriers, and I'd rather not keep adding to this list ;-).  All I am stating here is that I think it quite odd to run some arbitrary client layer network over UDP.  If some folks want this then so be it, I just don't think its very sensible....esp for a carrier.

regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 4 Jul 2004 15:37:15 +0300

> for label-controlled cell (ATM) and frame (FR) interfaces.

Yes, that is what I have been saying all along!
For the scheme to work we will have to add a label range option
for this case.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 4 Jul 2004 15:54:27 +0200

Yaakov and all,
IMHO a scheme that requires so many changes to the MPLS and
PWE3 architecture simply is not justified.

With best regards,
                                   Sasha Vainshtein

> Sent: Sunday, July 04, 2004 2:37 PM
> To: Sasha Vainshtein

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 4 Jul 2004 17:07:13 +0300

Sasha, 

As I have been saying from the beginning, 
the only thing we need to add is the
label range command to the PWE signaling protocol
initialization phase.

This doesn't seem to be "so many changes" ...

Y(J)S

---

From: Shahram Davari <[email-masked]>
Date: Mon, 5 Jul 2004 12:24:47 -0700

Sasha,

>be different from all the transport labels. 

Correct. And that is easy to do. The downstream node is in full
control of the label distribution. It can easily exclude the labels used
for UDP from the Transport LSP labels.

-Shahram

---

From: Eric Rosen <[email-masked]>
Date: Tue, 06 Jul 2004 10:19:30 -0400

> The gateways that use UDP port numbers do not use MPLS-like inner labels.
> There are no MPLS labels with which to get confused. 

This  is exactly  the kind  of  assumption one  must never  make when  doing
protocol (or  even program) design.  ("Well, my  protocol/program would have
worked  if only  the users  had used  it in  the way  I intended!   Bad, bad
users!")

> Of course there could be, in  principle, a gateway that interfaces to both
> PWs using UDP port numbers and to  PWs using MPLS labels (and to a further
> set of  PWs using VLAN  tags) in  which case it  will either have  a label
> space per interface type, 

I don't see what "interface types" have to do with anything.

> or will have to divide up a single label space. 

This "dividing up" is  bad enough on a single node, as  (a) it gets into the
guts of  the label  allocation/deallocation routines, and  (b) you  now need
LDP's service  interface to understand  what kind of application  is calling
it, and  what kind of label is  needed by that application.  But even worse,
you'd need  to do this dividing  up on a network-wide  basis (world-wide, to
accommodate multi-provider  PWs), so that  when you receive a  label binding
you know which kind of "label" it is. 

So I believe your suggestion would be a very poor design. 

> If we  want to  remove a format  my vote  is to leave  UDP and  remove the
> L2TP. 

Well, we  can't "remove" UDP in  this WG because  we don't have it  to begin
with.  Removing L2TP would require a charter change.  

I  do not  favor adding  UDP to  our charter  because MPLS-in-IP  is already
available, but if we did add UDP we'd have to do proper signaling for it.

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 7 Jul 2004 14:46:40 +0300

> Well, we  can't "remove" UDP in  this WG because  we don't 
> have it  to begin with.  Removing L2TP would require a 
> charter change.  

Sorry, but UDP has been in there from the beginning.

Quote from the charter :

Tunnels for PWE3 encapsulations will use IP (both versions), L2TP,
or MPLS.  

Please note IP COMMA L2TP, and NOT IP WITH L2TP.
The reason we didn't say UDP/IP is that someone may want TCP/IP
(there is that option for RTP as well, although it is rarely used).

Also please note that the original Anavi drafts from had ONLY UDP/IP
(no MPLS or L2TP at all). 
This was never considered out-of-scope for PWE3.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 7 Jul 2004 14:53:01 +0300

labels.
> This  is exactly  the kind  of  assumption one  must never  
> make when  doing protocol (or  even program) design.  ("Well, 
> my  protocol/program would have worked  if only  the users  had used
it in  the way  I 
> intended!   Bad, bad users!")

Quite the opposite. Communications protocols should be designed
for the scenarios where they will be used, and not over-designed
for special cases that will never be important.
(I have seen far too many over-designed protocols in the ITU
which ended up never being implemented.)

Our cousins in the AVT WG use UDP port numbers 
as session demuxes all the time. Does anyone ever complain
that they shouldn't because we want to simplify a  
box that can handle both VoIP and VoMPLS sessions?

> > Of course there could be, in  principle, a gateway that interfaces
to 
> > both PWs using UDP port numbers and to  PWs using MPLS labels (and
to 
> > a further set of  PWs using VLAN  tags) in  which case it  will
either 
> > have  a label space per interface type,
> 

By "interface types" I meant UDP/IP vs. MPLS interfaces.
If someone really wants to build a box that does both
PWoIP and PWoMPLS, it would simply have to remember
which interface feeds which.

> This "dividing up" is  bad enough on a single node, as  (a) 
> it gets into the guts of  the label  allocation/deallocation 
> routines, and  (b) you  now need LDP's service  interface to 
> understand  what kind of application  is calling it, and  
> what kind of label is  needed by that application.  But even 
> worse, you'd need  to do this dividing  up on a network-wide  
> basis (world-wide, to accommodate multi-provider  PWs), so 
> that  when you receive a  label binding you know which kind 
> of "label" it is. 
> 

That suggestion was for completeness.
I didn't like it either.

Y(J)S

---

From: Eric Rosen <[email-masked]>
Date: Wed, 07 Jul 2004 10:36:10 -0400

Eric> Well, we  can't "remove" UDP in  this WG because  we don't 
Eric> have it to begin with. 

> Sorry, but UDP has been in there from the beginning. 

I didn't mean to suggest that use  of UDP is necessarily out of the charter,
just that the WG hasn't done the  work for it.  Since the WG hasn't done the
work for it, so there is nothing to remove.

However,  your  interpretation  of  the  charter as  REQUIRING  an  IP-based
solution other than L2TP strikes me as very far-fetched.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 07 Jul 2004 10:45:21 -0400

> Communications protocols should be designed

I assume you  mean they should be designed for the  scenarios where you plan
to use  them, and not  "over designed" to  work in scenarios that  you don't
happen to be planning to support.

I don't think so. 

> Our cousins in the AVT WG use  UDP port numbers as session demuxes all the
> time. 

I hope  you're not going  to tell me  that they use  LDP to signal  the port
numbers! (If they don't, then this point is of course irrelevant.) 

> PWoIP and PWoMPLS, 

If both methodologies get deployed, this is inevitable.

> it would simply have to remember which interface feeds which. 

Any interface could feed both.