Subject: UDP ports and the ITU Liason

From: Stewart Bryant <[email-masked]>
Date: Mon, 13 Sep 2004 16:32:51 +0100

We have the outstanding ITU UDP Liaison still to resolve.

This topic has been discussed on a number of
occasions with no firm agreement.

I think that we have three options in how to
approach this next. If we opt option A or option
C below there is clearly no point in addressing the
details of the five proposals put to us by the ITU.

So please can we start by choosing between A, B and
C below.

If we choose option A or C we are done. If we
choose option B, I will try to glean the consensus
response to each of the five ITU proposals
and summarize them to the list.

- Stewart

The five ITU proposals are:

1.    Use of destination port as application de-multiplexers,
and source + destination socket as connection de-multiplexers.

2.    Use of destination port number to identify a protocol
setup message, and implicit allocation of port numbers by
originator.

3.    Use of destination port number to identify a
control protocol, and explicit allocation of port
numbers (either downstream or upstream).

4.    Use of destination port number as application
de-multiplexer, and source port number as connection
de-multiplexer.

5.    Use of destination port number as connection
de-multiplexer, and optionally source port number
as application de-multiplexer.

Having looked at the responses to the mailing list
that followed the publication of
http://www.ietf.org/internet-drafts/draft-stein-pwe3-udp-00.txt
there appear classes of response we can make.

A) State that UDP is not an appropriate transport
protocol for this application and should not be used.

B) We can pick one of the mechanisms 1..5 above as
our preferred method.

C) State that although UDP may be used as a transport
protocol, the BOTH ports MUST be set by user
configuration and hence none of the options 1..5
are appropriate.

Let us consider each of these in turn:

A) There is merit in the argument that we already
have two methods of carrying PW over IP (L2TPv3 and
GRE/MPLS), and that UDP simply creates complexity and
interoperability issues. There is also merit in
the argument that firewalls could be configured
to pass L2TPv3 or GRE and would not be tempted
to mess with the payload.

On the other hand TDM over UDP/IP has been widely
implemented, is specified in both our own and
ITU draft standards and is a transport protocol
that is familiar to the customer base that some
vendors are targeting.

B) Each of the mechanisms 1..5 proposed has both
proponents and detractors. A number of these
proposals have been implemented and deployed.

Arguments for or against each approach usually
center around analogy with other UDP applications
and firewall compatibility.

This set of proposals have as an underlying
assumption that some measure of implicit or
explicit signaling of the UDP ports will
take place.

By selecting one of these mechanisms may we
simplify the demux design for the h/w and
s/w engineers since they only have consider
one UDP port as a variable.

On the other hand any implicit or explicit
signaling only solves part of the configuration
problem because there are many other parameters
that need to exchanged or confirmed. We have
no proposal for a complete signaling mechanism
to support PW over UDP.

Any signaling (implicit or explicit) has security
implications which have not been properly
addressed as yet.

C) This approach makes the UDP port usage a matter
of user policy. Demux occurs on source and destination
ports and the user is free to choose whether they
fix source, fix destination or fix neither.

This is doubtless harder to implement and there
is a danger that vendors will make mutually
incompatible simplifying assumptions.

On the other hand there is no consensus on a signaling
protocol that configures all of the parameters and
it is hard to see the merit in one that signals
just this one aspect of the configuration.

- Stewart

---

From: [email-masked]
Date: Mon, 13 Sep 2004 20:07:28 +0100

Hi Stewart,  yes to are right to remind us about this as it seems most
folks have forgotten about it.

I have a fundamental question that I'd like answered first to put any
responses to the options in context, viz:

*Who* is the target audience for this stuff?

I surely cannot believe any serious operator needs this.....but please
speak up if you do have a reason why IP or MPLS is not good enough.

I don't see why its relevant to the Internet (big I).....but then I also
wonder just how relevant most of the PW stuff stuff is here anyway.

I believe it might be more relevant to enterprises.

So, speaking as an operator I have to select option A.  

I have a further technical rationale that goes along these lines:

UDP is not a layer network.  IP is a layer network, ie we can
switch/route IP pkts.  MPLS is a layer network, ie we can switch MPLS
pkts along a (routed) parent LSP trail.  We do not switch/route UDP
pkts.

UDP (and for that matter TCP) are 'application to 1st layer network'
adaptation functions.....they only exist in end-systems above true layer
networks.

It therefore seems rather bizaare to me to want to carry other layer
networks above these (and I make a distinction here between co-cs layer
network entities and 'voice', the latter is an application and not a
layer network either).

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant
> Sent: 13 September 2004 16:33
> To: [email-masked]
> Subject: [PWE3] UDP ports and the ITU Liason
> 
> 
> 
> setup message, and implicit allocation of port numbers by originator.
> 
> de-multiplexer, and source port number as connection de-multiplexer.
> 
> interoperability issues. There is also merit in the argument 
> that firewalls could be configured to pass L2TPv3 or GRE and 
> would not be tempted to mess with the payload.
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Tue, 14 Sep 2004 01:08:53 +0100

As expressed by others on the list, I do not see the use of UDP/TCP ports as a viable solution from an operators perspective, and therefore I vote for option A.

As operators seek to converge their existing networks onto common platforms, convergence alternatives that have already been developed/deployed include i) IP/GRE and MPLS PSNs with MPLS (PW) labels for muxing and LDP/RSVP-TE/BGP for signalling, and ii) IP PSNs with L2TP for muxing/signalling.

There are probably hundreds of different ways PWs could be muxed/signalled, but just because its possible and proprietary solutions have been deployed for specific applications, it does not justify standardising those solutions as a means of solving a problem that has already been solved.

Regards,
Richard

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stewart Bryant

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Sep 2004 09:58:11 +0100

Neil

>*Who* is the target audience for this stuff?
In the specific case of PW over UDP I believe that the target is
customers who buy IP connectivity and run their own TDM
connectivity emulation. I am not sure how big that market is,
but to some vendors it is a market.

>speak up if you do have a reason why IP or MPLS is not good enough.
Nor can I, other than in perhaps some sort of tactical situation. 

So as an operator, that may have customers running TDM emulation
over the IP services that you have sold them, can you confirm that
your answer would still be A?

- Stewart

---

From: [email-masked]
Date: Tue, 14 Sep 2004 12:20:45 +0100

Hi Stewart,
Stewart observed/asked 14 September 2004 09:58

> In the specific case of PW over UDP I believe that the target 
> is customers who buy IP connectivity and run their own TDM 
> So as an operator, that may have customers running TDM 
> emulation over the IP services that you have sold them, can 
> you confirm that your answer would still be A?
NH=> The trite answer to your question would be say 'anyone can try
anything they like....whether it works (well enough) or not is a
different matter'.  How can one (and why would one) stop folks
attempting such things?  Whether the industry sanctions this however
with formal standards is, IMO, more to do with a judgement-call on
common-sense and economics of the market addressed.

To expand on this a bit further........ 

-	When one forms a client/server relationship between 2 layer
networks then there is an implicit assumption the server is 'fit for
purpose' in carrying the client.  This is due to performance inheritance
(which is recursive to the duct).  If this is not the case one might
have problems.  Some client/server relationships make more sense than
others IMO (eg there are sound reasons why when close to the duct in the
WAN the layer networks are generally co-cs in nature....see next
bullet)......this is not to say 'one is banned from doing certain
things' but common-sense ought to be one's guide here.

-	 When layer networks are nested the applications become 'less
bound' to the characteristics of a given layer network (ie the 1st one
they encounter) as one moves towards the duct.  Further, we are also
dealing with increasiongly larger traffic type aggregates.  So because
one loses sight of the specific needs of an application as one gets
closer to the duct, the performance/behaviour of a server layer network
ought to be good enough for the all clients it supports....which is of
course recursive, ie need to get better and not worse as one approaches
the duct.

-	IMO client/server layer network upwards recursion needs to be
bounded at some point.  I'd draw the line at UDP and TCP and say there
should not be layer networks above these, only applications.  I
therefore see a difference between UDP/IP (or TCP/IP) and X/IP(GRE or
L2tpv3 say).

IMO this is just common sense.

regards, neil

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 14 Sep 2004 19:07:10 +0200

Andy, Stewart and all,
I completeely agree with Andy and Ron - if UDP is 
used as transport, it must be done exactly as the 
AVT people do it!

I am not so sure if CE-to-CE TDM transport really falls within
their charter, though...

And with the way in which the options are presented in Stewart's mail,
I am not sure which of them really suits this definition.

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

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Tuesday, September 14, 2004 5:43 PM
> To: Ron Cohen
> Cc: [email-masked]; [email-masked]
> Subject: RE: [PWE3] UDP ports and the ITU Liason
> 
> 
> I completely agree with Ron on this - let's follow  the AVT 
> WG's lead on 
> this.  In fact, i would posit that CE-to-CE TDM transport 
> over UDP really 
> falls into their charter, not ours.
> 
> Cheers,
> Andy
> 
> ---------
> 
> At 9/13/2004 10:55 PM -0700, Ron Cohen wrote:
> >My 2 cents:
> >
> >UDP is a layer needed only for PDH/SDH emulation (due to 
> RTP), not as a
> >general PWE3 mechanism. The use of UDP for PDH/SDH should 
> follow the use
> >of UDP/RTP in VoIP applications. There is no need for PWE3 drafts on
> >this matter. Use of non-standard UDP/RTP for bypassing firewalls etc
> >should be addressed in the appropriate workgroups in IETF, 
> not in PWE3.
> >
> >Ron
> 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 15 Sep 2004 13:02:38 +0300

Stewart (and all others who took part in the discussion), 

I sat this one out,
both because I have stated my views in the past,
and because I wanted more people to comment.

Although I can go along with use of the destination
UDP port number as the AVT people use it,
I have a problem with Andy's wording
("as specified in IETF RFC 3550, 
similar to Voice over IP implementations").

RTP is an optional feature in PWE encapsulations,
and this wording seems to imply that it is needed.
(For this reason I also believe that it is inappropriate
to refer this problem to the AVT WG, as Andy
originally suggested.)

Furthermore, although 3550 softens the requirement
as compared with 1889, RTP typical uses pairs of
port numbers (for RTP and RTCP), which may be confusing
in this context.

Regarding Neil's comments, 
he seems to be saying that he as a carrier is not interested
in using UDP/IP at all (although I believe that BT's
CEO may see things a bit differently),
but if users want to use it, he doesn't really care what they do.

If the WG is of the opinion that UDP destination
port should be used, I would suggest the following wording:

   The PWE3 WG consensus regarding pseudowires over UDP/IP
   is that the connection label should preferably be placed in
   the UDP destination port field.
   This placement is consistent with the use of UDP ports by RTP.
   Concerns with respect to NAT and firewall compatibility
   should be addressed to other WGs in the IETF.

   We have not reached consensus on a signaling mechanism
   to support pseudowires over UDP/IP.
   The WG would like to point out that any use of signaling (implicit or
explicit) 
   has security implications that would need to be addressed.

Y(J)S

---

From: [email-masked]
Date: Wed, 15 Sep 2004 11:36:28 +0100

Yaakov,

> but if users want to use it, he doesn't really care what they do.

My understanding is that the view expressed by my BT colleagues is that UDP should only be used as an application adaptation (and not a network layer adaptation).  So for example VoIP can use UDP as it is adapting/encapsulating an application (Voice) in UDP/IP, however TDMoIP should not use UDP as TDMoIP is adapting/encapsulating a network layer (TDM) in UDP/IP.

Ben

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

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

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

BT Exact is a trademark of British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000

---

From: [email-masked]
Date: Wed, 15 Sep 2004 12:06:18 +0100

Yaakov,

> but if users want to use it, he doesn't really care what they do.

Obviously carriers will use UDP/TCP for VoIP, just like they use UDP/TCP for any other IP application, e.g. HTTP, SMTP, etc. but I don't see what this has to do with PWs. I believe Neil was saying that carriers would not use UDP/TCP for adapting/muxing client layer networks, e.g. ATM CBR services, Ethernet private lines, etc across a common core. Using UDP/TCP for adapting/muxing voice (or even TDM) services over an access link or across an enterprise network is very different from carrying multiple services for millions of customers end-to-end over a carrier network. One can imagine that a carrier would be likely to aggregate VoIP UDP/TCP flows and carry them across the core using IP/MPLS PWs.

Perhaps you could enlighten us as to what you believe BT's CEOs views are on this subject as you seem to think you know what they are?

Richard

---

From: [email-masked]
Date: Wed, 15 Sep 2004 21:43:53 +0100

Sorry Andy, but I do not agree with you that a voice (or any other
end-system) application is the same as a co-cs layer network client.  So
I do not agree this is a valid precedent.

I am still of the firm opinion this is an abuse of the UDP adaptation
function as no *layer network* should appear above this point IMO.  I
am, quite frankly, rather amazed (some folks in) IETF are prepared to
countenance this. 

We don't seem to have heard from (m)any operators on this topic.  I'd be
interested (seriously) to know which major operators are planning to
migrate their current PDH/SDH-based leased-line services to this
particular proposal.....so please speak now and tell us why this is
important for you.  

regards, Neil

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Andrew G. Malis
> Sent: 14 September 2004 20:58
> To: Stewart Bryant
> Cc: [email-masked]; Ron Cohen; Sasha Vainshtein
> Subject: Re: [PWE3] UDP ports and the ITU Liason
> 
> 
> Stewart,
> 
> I recommend the following text in response:
> 
> The IETF PWE3 working group recommends UDP port number allocation and
> signaling as specified in IETF RFC 3550, similar to Voice over IP 
> implementations.
> 
> Cheers,
> Andy
> 
> ----------
> 
> At 9/14/2004 08:03 PM +0100, Stewart Bryant wrote:
> 
> 
> >Sasha Vainshtein wrote:
> >
> >>Andy, Stewart and all,
> >>I completeely agree with Andy and Ron - if UDP is used as
> transport,
> >>it
> >>must be done exactly as the AVT people do it!
> >>
> >>I am not so sure if CE-to-CE TDM transport really falls
> within their
> >>charter, though...
> >>
> >The options are the first line of each of the options in
> >the communication from the ITU, which can be found at:
> >
> >http://www.ietf.org/IESG/LIAISON/file21.pdf
> >
> >We could of course supply alternative text in our response.
> >
> >Stewart
> >
> >>
> >>With best regards,
> >>                                   Sasha Vainshtein
> >>>I completely agree with Ron on this - let's follow  the
> AVT WG's lead
> >>>on
> >>>this.  In fact, i would posit that CE-to-CE TDM transport over UDP
> >>>really falls into their charter, not ours.
> >>>
> >>>Cheers,
> >>>Andy
> >>>
> >>>---------
> >>>

---

From: [email-masked]
Date: Thu, 16 Sep 2004 09:03:38 +0100

Yaakov,

Yaakov wrote 15 September 2004 11:03

<snipped>
> similar to Voice over IP implementations").
NH=> I have a problem with this period.  I think this is an improper use
of rfc3550.  One simply must draw the line somewhere wrt to
client/server layer network recursion.  There is a physical limit going
down the stack at the section layer.  Going up the stack things *should*
stop at the application adaptation function....so, in the case of IP,
this is UDP and TCP, ie no layer network should appear above these IMO.
And I believe this is what IETF ought to recommend....sure folks can go
break this recommendation just like they can with any recommendation.

I (and the vast majority of my colleagues here in BT) think there are
enough questions about arbitrary client/server relationships between the
3 proper layer network modes as it is.....and some of our very
large/important customers (who run their own networks) are already
making noises that this also concerns them.
> to refer this problem to the AVT WG, as Andy
NH=> Why do you say this is wrong?  rfc3550 was designed for
applications that need this behaviour....RTP is a component of this.  It
was not designed for folks to go and use it in an improper way.
<snipped>

> in using UDP/IP at all
NH=> Please do not misquote me.  I have consistently stated that IMO UDP
and TCP are application adaptation functions for the IP layer
network.....these have not been designed, nor was it ever intended
AFAIK, for folks to run PDH/SDH layer networks above them. 

>(although I believe that BT's
NH=> Let me be clear here....are you telling me that you believe my CEO
advocates the running of PDH/SDH layer networks over UDP?

> but if users want to use it, he doesn't really care what they do.
NH=> I feel you are misrepresenting me again.  If we sell some network
service we cannot be totally prescriptive about how folks use that.  But
this principle applies almost anywhere.  There are, of course,
legal/commercial protection mechanisms in place to protect innocent
parties from folks who abuse their products.  For example:
-	There is nothing to physically stop you buying a car capable of
180mph and driving it at that speed on the public roads.  However, in
doing so you break the law and you will be punished if caught.  You
can't then go back and sue the car manufacturer saying its his fault you
broke the speed laws.
-	Although there is nothing to stop you buying a washing machine
and then mixing concrete in it, if you then try and sue the washing
machine manufacturer because the machine broke when used to mix concrete
the case will not stand-up as its an abuse of the washing machine, ie it
was not designed for this job.

In our case we will have to provide 'service descriptions' and 'SLAs' to
customers...and for some operators they have to abide by a regulatory
framework.  Its not clear to me this is going to be easy (or possible)
to achieve with some of the things I see going on.  The above hints at
the reasons why I have, in the past, been quite 'strong' on wanting to
see modal architecture principles adherered to and why I regard OAM as a
vital component of any layer network.

So please be clear on the point I was making here.

regards, Neil
<snipped to end>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Sep 2004 15:06:40 +0100

Responses seem to be polarized between those that think that
we should deprecate the use UDP (or any other "transport
protocol" ) as a method of PW multiplexing, and those that seem
to be homing in on text of the following form:

"The PWE3 WG consensus is that in an IP network, pseudowires should
preferably be carried over L2TPv3 or MPLS/GRE. The use of pseudowires
over UDP/IP is only applicable where there is a technical constraint
preventing the use of L2TPv3 or GRE / MPLS.

"The PWE3 WG consensus regarding pseudowires over UDP/IP is that the
connection label should preferably be placed in the UDP destination
port field. This placement is consistent with the use of UDP ports
by RTP [RFC3550].

"Concerns with respect to NAT and firewall compatibility should be
addressed to other WGs in the IETF.

"We have not reached consensus on a signaling mechanism  to support
pseudowires over UDP/IP, but the WG would like to point out that
any use of signaling (implicit or explicit) has security implications 
that would need to be addressed."

It might also be appropriate to append something of the form
to the answer:

"The WG would also like to point out that within the IETF there
are misgivings about the use of UDP in these applications from
a congestion perspective. Full regard must therefore be
given to the likely deployment scenarios and the design of
appropriate congestion management mechanisms."

Now back to the decision process WRT our response:

I understand the reasons from the operator community as to why
they see the use of UDP as an inappropriate multiplexing
mechanism, but note that this request comes from ITU-T, which
normally has a strong focus on the needs of that community.

I would suggest that we all need to focus on the first
paragraph and succinctly state the circumstances under which
UDP would be permissible. I would appreciate responses in the
form of suggested text to be sent to our collegues in ITU-T.

If there are no circumstance under which UDP would be applicable
I would appreciate response in the form of a suggested relpy
to the ITU to that affect.

I would also request the proponents of UDP to look carefully
at the remaining three paragraphs and confirm that this text
is suitable.

Thanks

Stewart

---

From: Eric Rosen <[email-masked]>
Date: Fri, 17 Sep 2004 12:18:36 -0400

"The use  of pseudowires  over UDP/IP  is only applicable  where there  is a
technical constraint preventing the use of L2TPv3 or GRE / MPLS." 

The technical  constraint being  what, the fact  that a product  already has
support for UDP and UDP only? 

It seems to me  that this WG has not given any  serious consideration to the
use of UDP in this manner, and hence should not be making any recommendation
to the ITU-T with regard to its use. 

The proposed liaison statement appears  to be a conditional endorsement of a
proposed ITU-T standard, but without  any mechanism to declare that standard
to also be an IETF standard.  Frankly, I don't understand this procedure.  

The liaison  is further confusing in  that it declares certain  things to be
the consensus of the  WG, and then goes on to state  the various reasons why
the WG hasn't achieved a consensus. 

Perhaps a better liaison statement would  be "the PWE3 WG has not considered
the use of UDP as the tunneling  mechanism for PWE3, and at the present time
is not planning a standards track document on that topic."

---

From: [email-masked]
Date: Fri, 17 Sep 2004 18:13:20 +0100

Eric....I agree with you....but also see below.

> Behalf Of Eric Rosen
> Sent: 17 September 2004 17:19
> To: Stewart Bryant
> Cc: Thomas Narten; [email-masked]'; [email-masked]; Jon 
> Peterson; Allison Mankin
> "The use  of pseudowires  over UDP/IP  is only applicable  
> where there  is a technical constraint preventing the use of 
> L2TPv3 or GRE / MPLS." 
> 
> The technical  constraint being  what, the fact  that a 
> product  already has support for UDP and UDP only? 
NH=> Mark Townsley has already asked this question, and AFAIK there has
been no answer to what these 'technical constraints' are.  Can someone
please elaborate?
> 
> It seems to me  that this WG has not given any  serious 
> consideration to the use of UDP in this manner, and hence 
> should not be making any recommendation to the ITU-T with 
> regard to its use. 
NH=> I agree.  I also made the point that an application over UDP (which
is what rfc3550 is all about) is not the same as blasting some PDH/SDH
constant bit rate layer network over UDP.  Further, IMO no layer network
should appear above UDP (or TCP)......however, perhaps that is something
folks responsible for UDP (or TCP) should be asked to rule on (who is
that?).
> 
> The proposed liaison statement appears  to be a conditional 
> endorsement of a proposed ITU-T standard, but without  any 
> mechanism to declare that standard to also be an IETF 
> standard.  Frankly, I don't understand this procedure.
NH=> Well, I think IETF should provide a view on the proper/improper use
of UDP (and/or TCP) as 'application to 1st layer network (invariably IP)
adaptation'.  Also remember that operator's are (sadly) rather thin of
the standards ground these days....so folks should not necessarily
assume an ITU liaison is specifically coming from the operator
community.  In fact, I am quite concerned that I have heard no other
operators voicing any opinion on any of this.
> 
> The liaison  is further confusing in  that it declares 
> certain  things to be the consensus of the  WG, and then goes 
> on to state  the various reasons why the WG hasn't achieved a 
> consensus.
NH=> I have seen next to no good debate to achieve any consensus
here....and as already noted almost zero operator comment. 
> 
> Perhaps a better liaison statement would  be "the PWE3 WG has 
> not considered the use of UDP as the tunneling  mechanism for 
> PWE3, and at the present time is not planning a standards 
> track document on that topic." 
NH=> Well, that's a reasonable assessment of what we have seen IMO.
However, it still leaves the specific question open....that is:
Are layer networks allowed to exist above UDP (or TCP) or not?

regards, Neil

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 17 Sep 2004 14:04:24 -0400

> support for UDP and UDP only? 

Isn't that roughly the same reason we give in 
draft-ietf-mpls-in-ip-or-gre-08.txt for MPLS over GRE vs. MPLS over IP?

      - Implementation considerations may dictate the use of MPLS-in-GRE.
        For example, some hardware device might only be able to handle
        GRE encapsulations in its fastpath.

> to the ITU-T with regard to its use. 

The most practical argument one might have for using UDP when tunneling over IP 
is to be more friendly to NAT. For example, draft-ietf-ipsec-udp-encaps-09.txt 
does precisely this. L2TPv3 also has an optional mode that inserts UDP for NAT 
friendliness. Now, being NAT friendly generally means one UDP port mapping per 
host behind the NAT. Overloading the UDP port number with the PW multiplexer 
serves to tax NAT tables to their extreme, ultimately reducing the number of 
sessions across the set of multiple applications which use UDP behind a given 
NAT. Yes, I know voice uses UDP. That's part of the problem. What if *all* 
applications used UDP ports for session multiplexing?

 > is not planning a standards track document on that topic."

But the record of emails, at least one draft vying for standards track on the 
topic, and mention of UDP specifically in our charter would all suggest that we 
have considered UDP.

- Mark

---

From: Eric Rosen <[email-masked]>
Date: Fri, 17 Sep 2004 14:47:19 -0400

Eric> The technical constraint  being what, the fact that  a product already
Eric> has support for UDP and UDP only?

Mark> Isn't that  roughly the same reason we  give in draft-ietf-mpls-in-ip-
Mark> or-gre-08.txt for MPLS over GRE vs.  MPLS over IP?

The situations are not truly analogous.  For carrying MPLS packets across an
IP network, just about any IP-based tunneling mechanism will do, because all
you really need  to know at the other  end is that you have  an MPLS packet.
So if  someone wanted to use  MPLS-in-UDP, on the grounds  that his hardware
only supports  UDP encapsulation, I'd  find it hard  to maintain a  sense of
outrage; after all the functionality is the same.

However, when  you consider  the case  of UDP as  an alternative  to L2TPv3,
MPLS, MPLS-in-IP, or MPLS-in-GRE, a few things seem to be missing, e.g., (a)
signaling and (b) any clearly  acceptable means of identifying a pseudowire.
Where  I'm  having some  difficulty  is in  understanding  what  the set  of
technical constraints are that justify the differences in functionality.

Mark> But the record of emails, at least one draft vying for standards track
Mark> on the topic, and mention of UDP specifically in our charter would all
Mark> suggest that we have considered UDP.

What did we decide? 

Seriously,  the most  in-depth analysis  I've seen  of the  merits  (or lack
thereof) of using UDP in this way is the one you just wrote.

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 19 Sep 2004 14:27:49 +0300

Neil, 
 
> > RTP is an optional feature in PWE encapsulations, and this wording 
> > seems to imply that it is needed.
> > (For this reason I also believe that it is inappropriate to refer
this 
> > problem to the AVT WG, as Andy originally suggested.)
> applications that need this behaviour....RTP is a component 
> of this.  It was not designed for folks to go and use it in 
> an improper way.
> <snipped>

All I meant is that you can have perfectly good PWs
without RTP. I believe that you are claiming that even
WITH RTP you don't believe we should use UDP/IP.

> > he seems to be saying that he as a carrier is not 
> > interested in using UDP/IP at all
> NH=> Please do not misquote me.  I have consistently stated 
> that IMO UDP and TCP are application adaptation functions for 
> the IP layer network.....these have not been designed, nor 
> was it ever intended AFAIK, for folks to run PDH/SDH layer 
> networks above them. 

I was talking only in the context of PWs
(I was not implying that you wouldn't use UDP/IP
or TCP/IP for some other application).

> NH=> Let me be clear here....are you telling me that you 
> believe my CEO advocates the running of PDH/SDH layer 
> networks over UDP?

No, but he has been quoted widely in stating that half of BT's
UK customers will have migrated to VoIP by 2008.
If we understand this VoIP to be the standard UDP/IP based service,
I assume that this means that he has a lot of faith in UDP/IP's
reliability.

> In our case we will have to provide 'service descriptions' 
> and 'SLAs' to customers...and for some operators they have to 
> abide by a regulatory framework.  Its not clear to me this is 
> going to be easy (or possible) to achieve with some of the 
> things I see going on.  The above hints at the reasons why I 
> have, in the past, been quite 'strong' on wanting to see 
> modal architecture principles adherered to and why I regard 
> OAM as a vital component of any layer network.

Now I have a question.
Do you mean that it is impossible to provide an SLA
with a UDP/IP service, but it becomes possible 
by using an MPLS based encapsulation? 
I don't see how the MPLS we are talking about here
(as opposed to the somewhat different MPLS you often 
espouse) is that different.

Y(J)S

---

From: [email-masked]
Date: Mon, 20 Sep 2004 10:08:38 +0100

Yaakov,

> I assume that this means that he has a lot of faith in UDP/IP's

IMO, the crux of the point Neil is trying to make is that an application != a layer network.  Therefore just because UDP is suitable for encapsulating applications does not imply that it is suitable for encapsulating layer networks.  VoIP (i.e. Voice over UDP/IP) != PDH/SDH over UDP/IP.

Just because something can be done does not mean that it is sensible to do it (especially for service providers who are the target of PWE3 according to my interpretation of the PWE3 charter).

Ben

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 20 Sep 2004 12:42:47 +0200

Ben and all,
I would appreciate a clarification of your position (presumably also
Neil's).

When you say that UDP is not suitable for carrying PDH/SDH, do you really
mean
that IP, regardless of the demultiplexing method used - be it UDP, L2TPv3
over IP,
L2TPv3 over UDP over IP, MPLS-in-IP, MPLS-in-GRE-in-IP etc. - is not
suitable
for this purpose?

Or is your statement really limited to usage of UDP as the demultipexer?

With best regards,
                                   Sasha Vainshtein

> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Monday, September 20, 2004 11:09 AM
> To: [email-masked]
> IMO, the crux of the point Neil is trying to make is that an 
> application != a layer network.  Therefore just because UDP 
> is suitable for encapsulating applications does not imply 
> that it is suitable for encapsulating layer networks.  VoIP 
> (i.e. Voice over UDP/IP) != PDH/SDH over UDP/IP.
> 
> Just because something can be done does not mean that it is 
> sensible to do it (especially for service providers who are 
> the target of PWE3 according to my interpretation of the PWE3 
> charter).
> 
> Ben
>

---

From: [email-masked] (Amnon Ilan)
Date: Mon, 20 Sep 2004 12:54:43 +0200

Ben,

If you look at what a VoIP gateway does: it takes POTS ports or E1/T1 ports
and convert it
to RTP. The UDP is not only for encapsulation, the UDP port number
information is needed
for forwarding. Is it a layer network (in some degenerated form) or an
application?
A TDMoIP gateway has a similar functionality: takes E1/T1 and convert it to
IP.
Maybe the point is in the size and the network location: in small access
gateways UDP port
option may be useful (even for carrier networks).

Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Monday, September 20, 2004 11:09 AM
To: [email-masked]
Subject: RE: [PWE3] UDP ports and the ITU Liason

Yaakov,

> I assume that this means that he has a lot of faith in UDP/IP's

IMO, the crux of the point Neil is trying to make is that an application !=
a layer network.  Therefore just because UDP is suitable for encapsulating
applications does not imply that it is suitable for encapsulating layer
networks.  VoIP (i.e. Voice over UDP/IP) != PDH/SDH over UDP/IP.

Just because something can be done does not mean that it is sensible to do
it (especially for service providers who are the target of PWE3 according to
my interpretation of the PWE3 charter).

Ben

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3
 This mail arrived via mail.mrv.com

---

From: [email-masked]
Date: Mon, 20 Sep 2004 10:56:57 +0100

Sasha,

> Or is your statement really limited to usage of UDP as the 

My statement is limited to the use of UDP as a demultiplexer.

IP is a layer network.  UDP is an application adaptation (i.e. it is used to encapsulate/adapt an application into a layer network PDU).  IMO UDP should not be used as a layer network adaptation function.

Whether using a clns layer network to transport a co-cs layer network is sensible (e.g. is PDH/SDH over IP sensible) is a different question that I have not been addressing in this thread.

Ben

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 20 Sep 2004 13:46:03 +0300

Amnon/Sasha,

I think what Neil and Ben are saying is that UDP/IP is good
enough for "mere VoIP", 
which they don't yet consider a carrier service 
(but as I quoted before, their CEO already does), 
but not for an E1 or T1.

Is it the datarate that concerns them?
I assume not; the AVT WG has standardized RTP formats 
for video at these rates and higher, 
and I haven't heard them complain.

Is it because the PWs may multiplex traffic
belonging to many users? Perhaps, but in that case
they should have no problem with an unframed TDM PWs
(SAToP) and should complain about several AVT efforts, 
including TCRTP.

Perhaps they are worried that maintaining certain
native service features, such TDM timing, 
becomes more difficult in such "unprotected" networks.
But these are items for applicability statements,
(and TDM timing, in fact, turns out to be about the same
in UDP and LDP-MPLS networks).

Neil has often cited insufficient OAM functionality.
But in that case he should equally object to PWs 
over LDP-based MPLS (which as he himself 
has frequently pointed out, suffers in this respect)
and certainly over any form of MPLS not running Y.1711.
Since I haven't heard of L2TPv3 OAM recommendations
in the ITU, I guess that is ruled out as well.

So it comes down to the pure architectural problem.
UDP and TCP are "adaptation functions", 
and no "layer network" should be carried over them. 

So why don't our BT friends have the same problem
with transporting TDM over AAL1 
(patently an adaptation and NOT a layer network) ?

And are UDP and TCP really pure adaptations,
and are all of our traffic types always layer networks?

UDP-TCP contain addressing functionality (ports)
and error correction, 
can use ICMP packets to discover connectivity,
and have various other features that are normally 
associated with layer networks.

On the other hand TDM can certainly be used as
a simple point to point data stream, i.e. a pure application.
Even when it carries timeslots, these are frequently
from a dumb PBX, and not a PSTN switch, and thus
does not represent a layer network.

So, let's be consistent.
If the problem is of architectural principal,
then we need to disallow transport of layer network traffic
over AAL1 over ATM, over all flavors of MPLS except 
RSVP-TE and with Y.1711 OAM, and over L2TPv3.

oh, and over UDP/IP too.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 20 Sep 2004 13:55:10 +0200

Ben,
Thank you for a prompt and unambiguous response.

I must admit, however, that I respectfully disagree with you.
IMHO, UDP does not provide any "application adaptation" functions,
just demultiplexing of IP datagrams received at the specific IP interface.
It differs from the other demultiplexing methods I've mentioned because
it does not provide any specific control plane. But as far as the data plane
is
concerned, I do not perceive any substantial difference.

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, September 20, 2004 11:57 AM
> To: Sasha Vainshtein
> Cc: [email-masked]; [email-masked]
> IP is a layer network.  UDP is an application adaptation 
> (i.e. it is used to encapsulate/adapt an application into a 
> layer network PDU).  IMO UDP should not be used as a layer 
> network adaptation function.
> 
> Whether using a clns layer network to transport a co-cs layer 
> network is sensible (e.g. is PDH/SDH over IP sensible) is a 
> different question that I have not been addressing in this thread.
> 
> Ben
>

---

From: [email-masked]
Date: Mon, 20 Sep 2004 12:09:22 +0100

<snipped to question>

> espouse) is that different.
Having a 'connection' (aka trail in G.805) allows one to control traffic
directivity and decouple the 'importance' semantic from the nature of
the traffic carried.  This all works fine for p2p and p2mp....difficulty
arises with merging as created by mp2p and PHP.  Further, these
difficulties are not present in the cl-ps mode anyway since each traffic
unit carries the full DA/SA, so one can only get muxing here and not
merging.

So, if I have a p2p trail I can assign a stronger performance assurance
to it than if I only have the cl-ps mode or I merge in the co-ps mode.

regards, Neil

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 20 Sep 2004 12:03:17 -0400

> What did we decide? 

Not sure, but I would summarize the overall properties of a UDP PW as follows:

- VoIP traffic is carried over RTP/UDP/IP. Designers of PWE3 protocols making 
use of RTP (i.e., TDM-based PWs), have found the UDP encapsulation for PW 
multiplexing more natural and consistent than designers of PWE3 protocols that 
do not directly carry real-time data.

- A UDP/IP encapsulation may be useful for NAT traversal when NAT ALGs for other 
IP-based PW encapsulations do not exist.

- Overloading the UDP Port number and PW Multiplexer can serve to reduce the 
header overhead compared to other UDP-based encapsulations (for example, L2TPv3 
over UDP which uses a single UDP port for multiple PWs, but inserts its own 
4-byte multiplexing field to do so).

- Allocating UDP ports for each PW significantly increases state necessary to be 
maintained in an intervening NAT or Firewall, and does not scale beyond the 
number of free UDP ports available on a given system (theoretically 65535, but 
in practice less after eliminating use of well-known ports, ports in use by 
applications, etc.).

- There is no standard mechanism defined by PWE3 for UDP port signaling. Thus, 
if the UDP port is also used for PW multiplexing, this value must be manually 
configured.

- A UDP encapsulation may be used to compute and carry a checksum for each PW 
packet across the PW. Doing so MAY aid in detection of bit-errors, but comes at 
the expense of significant (and perhaps redundant) per-packet processing 
overhead at the PEs.

- Mark

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 21 Sep 2004 12:47:33 +0200

Mark and all,
A very nice summary, IMO.
I have added a single brief comment inline below.
With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Monday, September 20, 2004 6:03 PM
> To: [email-masked]
> Cc: Thomas Narten; [email-masked]; Jon Peterson; 
> [email-masked]'; Allison Mankin; Stewart Bryant
[Sasha] I'd like to note that RFC 3489 "STUN - Simple Traversal 
of User Datagram Protocol (UDP) Through Network Address 
Translators (NATs)" is a Standards Track RFC describing a
method for making peer-to-peer UDP-based protocols NAT-friendly. 
Since one of the declared objectives of the STUN designers 
has been allowing VoIP and other RTP-based protocols) to run 
through NATs regardless of ALGs, STUN clearly favors RTP-like 
usage of UDP ports for demultiplexing.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 21 Sep 2004 06:37:38 -0400

> usage of UDP ports for demultiplexing.

The existance of STUN and its motivation rooted in a protocol which uses 
UDP-based session multiplexing serves to prove that overloading UDP was a bad 
idea to start with. If UDP ports were not so heavily overloaded in this way, 
perhaps STUN would not have been necessary. But, your point is well-taken that 
at least we have a standards-track method for mitigating the ill-effects - no 
matter how painful it is to discover NATs, send periodic "bubble" packets over 
each UDP port to keep it open, etc. What a mess.

So, let me ask... If you really want UDP and a NAT, which would be easier: 
running L2TPv3 over a single well-known UDP port for which ALGs are widely and 
commonly implemented (L2TPv3 uses the same UDP port 1701 as RFC2661 L2TP, so its 
been around for 5+ years). Or, multiplexing with UDP and loading a STUN client 
and server on top of the PW to make sure you keep the NAT happy? I suppose VoIP 
didn't have a choice, the protocol was already invented and deployed and they 
had to create STUN to deal with it. Do we want to perpetuate the status quo in 
PWE3 where we have some advantage of hindsight?

- Mark

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 21 Sep 2004 16:43:00 +0300

> running L2TPv3 over a single well-known UDP port for which 
> ALGs are widely and commonly implemented (L2TPv3 uses the 
> same UDP port 1701 as RFC2661 L2TP, so its been around for 5+ 
> years). Or, multiplexing with UDP and loading a STUN client 
> and server on top of the PW to make sure you keep the NAT 
> happy? I suppose VoIP didn't have a choice, the protocol was 
> already invented and deployed and they had to create STUN to 
> deal with it. 

It's much easier to put the connection demux in the source UDP address,
and place a single PW application demux in the destination port.

No tables, no STUN, just FUN.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 21 Sep 2004 19:07:58 +0200

Yaakov and all,
One advantage of having an IETF Standards Track RFC on NAT traversal
(STUN) is off-the-shelf availability of comprehensive analysis of the
NAT implemenation and deployment variations. One of the (IMO, relevant)
use cases described in RFC 3489 is multiple levels of NAT. This use case
seems to be relevant in the cable access networks, where in many cases
the entire cable access network is separated from the public Internet
by the provider's NAT while the end users operate NAT of their own.

The network diagram below depicting the resulting topology
is based on the similar diagram in RFC 3489. In this diagram
the Hub PE establishes a small number of PWs with each of the
Spoke PEs.

                            /-----\
                          //  Hub  \\
                         |    PE     |
                          \\       //
                            \-----/

                       +--------------+             Public Internet
       ................| Provider NAT |.......................
                       +--------------+

       +---------------+  +----------------+    Upper  Private NET 
       | Customer NAT 1|..| Customer NAT N.|..................
       +---------------+  +----------------+

          /-----\           /-----\
        // Spoke \\       // Spoke \\
       |    PE 1  |      |    PE N  |    Lower Private NETs 1,..., N
        \\       //      \\        //         
          \-----/          \------/

STUN has been specifically designed to address this and similar use
cases.

Your "FUN" proposal, however, probably will not work in this case since, 
on one hand, more than one PW end point can reside behind the provider's
NAT, while, on the other hand, the provider NAT would not be able 
to demultiplex different PW flows coming from the public side as they would
all use the same destination IP and UDP port.

Did I miss something?

With best regards,
                                   Sasha Vainshtein

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Tuesday, September 21, 2004 3:43 PM
> To: W. Mark Townsley; Sasha Vainshtein
> [email-masked]; [email-masked]; Allison Mankin; Stewart Bryant

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 21 Sep 2004 10:03:11 -0700

Mark,

My 2c:

I would remove any consideration regarding firewalls and NAT. Frankly I
don't understand where these firewalls are located in edge-to-edge
emulation. We haven't discussed how MPLS tunnels transverse firewalls
nor I believe we should have. 

I think UDP is meaningful for real-time PDH and SDH emulation only. Its
usage should follow the protocols defined in AVT WG. In future I see
room for signaling used for VoIP to apply to circuit emulation too.
Don't see any real difference between a voice call and an NxDS0 circuit
being setup. Regardless whether it makes sense or not, I don't think it
is under PWE3 charter at this time. 

Regards
Ron

> Behalf Of W. Mark Townsley
> Sent: Monday, September 20, 2004 9:03 AM
> To: [email-masked]

---

From: John Drake <[email-masked]>
Date: Tue, 21 Sep 2004 10:22:02 -0700

Eric,

A very sensible note.  I think the ITU liaison should explicitly indicate
that the WG will not make a recommendation on this topic.

Thanks,

John

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Tuesday, September 21, 2004 9:54 AM
> To: Sasha Vainshtein
> Cc: Thomas Narten; 'Yaakov Stein'; [email-masked]; Jon Peterson; Allison
> Mankin; W. Mark Townsley; [email-masked]; Stewart Bryant
> Doesn't this whole discussion make it clear that there is no WG consensus
> on
> how and/or whether to do a UDP encapsulation?
> 
> Anyone who  wants to produce  such a  consensus should try  to do so  in
> the
> usual manner, i.e, by producing  an internet-draft and attempting to move
> it
> through the standardization process.  In the  absence of that, I think it
> is
> fair to say only  that the scheme has not been considered  (which is not
> the
> same as saying that it has never been mentioned or never been discussed).
> 
> If someone wants  to do "forum shopping" by taking it  to the ITU-T
> instead,
> that's their right, but this WG should avoid complicity.
> 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 22 Sep 2004 10:39:20 +0300

> If someone wants  to do "forum shopping" by taking it to the 
> ITU-T instead, that's their right, but this WG should avoid 
> complicity.  

Eric, 

Just a clarification as to why this liaison was sent to PWE 
in the first place. 

In ITU-T SG13 Q5 there is much interest in advancing this work,
even if PWE is not interested in it.

While discussing a draft recommendation (started March 2003) 
on transport of low-rate TDM over IP
there was a difference of opinion regarding whether to use UDP
destination
or source ports as connection demultiplexers.

At the last SG13 meeting the representative of a certain large router
manufacturer 
stated that it was his view that UDP/IP "belonged" to the IETF,
and we should thus postpone any decision relating to its use
until we ask for its opinion on the matter.

This was done by sending a liaison to PWE3 due to the close working ties
between SG13Q5 and PWE3. It could have been directed to the AVT WG,
but there is no TDM transport service being developed there,
and it was believed that AVT would not be overly interested
in devoting time to discussion of the issue.

It is perfectly acceptible for PWE3 to respond that
  it has no opinion on the matter,  or
  it could not reach consensus, or 
  it only recommends use of MPLS or L2TPv3, or
  the question should be redirected to some other IETF WG or to the
IESG.

Y(J)S

---

From: [email-masked]
Date: Wed, 22 Sep 2004 10:47:02 +0100

Yaakov,

> > instead, that's their right, but this WG should avoid complicity.
> 
> Eric,
> 
> In ITU-T SG13 Q5 there is much interest in advancing this
> work, even if PWE is not interested in it.
NH=> ITU is largely responsible for developing international layer
network standards between operators.  I have yet to hear an operator
support this...and I have asked for such folks to make themselves known
a few times now.  As a slight aside here, given the discussion has
recently brought up NAT issues as an important consideration for this
proposal, this makes me even more convinced this is not a device for
operators in building core networks.   
> there was a difference of opinion regarding whether to use 
> UDP destination or source ports as connection demultiplexers.
> 
> At the last SG13 meeting the representative of a certain
> large router manufacturer 
> stated that it was his view that UDP/IP "belonged" to the 
> IETF, and we should thus postpone any decision relating to 
> its use until we ask for its opinion on the matter.
NH=> Client/server adaptation between 2 layer networks is not the same
IMO as application adaptation to 1st layer network.  And I still
maintain there should be no layer networks above UDP as we have to draw
the line somewhere....though I know you disagree with me on this. 

regards, Neil
> 
> This was done by sending a liaison to PWE3 due to the close 
> working ties between SG13Q5 and PWE3. It could have been 
> directed to the AVT WG, but there is no TDM transport service 
> being developed there, and it was believed that AVT would not 
> be overly interested in devoting time to discussion of the issue.
> 
>   the question should be redirected to some other IETF WG or 
> to the IESG.
> 
> 
> Y(J)S
> 
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 22 Sep 2004 05:57:20 -0400

> or source ports as connection demultiplexers.

If the question is really about the use of source or destination UDP ports as 
multiplexers, I can see how this question would lie within the boundaries of the 
IETF. Given the possible side affects on other components that expect certain 
behaviors from UDP-based applications, I don't think it is a question which 
should be taken lightly. For example, if you do wish to pass through a NAPT, I 
think using the the source port as the demultiplexer could cause problems as the 
source UDP port is commonly altered in transit.

Within the context of PWE3, it has been stated that the charter largely targets 
Provider edge to edge scenarios, and that NAT is thus not a concern. This is 
certainly a valid argument. However, I'm afraid that, certainly for the 
enterprise market, and perhaps the managed CE SP market that current TDMoIP 
products target, one cannot brush aside NAT so quickly. As such, perhaps PWE3 
isn't the best place for you to get the recommendation you want. Perhaps AVT, or 
even an escalation to the IAB to advise, in general, on the topic of UDP session 
multiplexing since that seems to be the real heart of the issue.

- Mark

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 22 Sep 2004 13:26:01 +0300

> I would remove any consideration regarding firewalls and NAT. 
> Frankly I don't understand where these firewalls are located 
> in edge-to-edge emulation. 

<snip>

> Regardless whether it makes sense 
> or not, I don't think it is under PWE3 charter at this time. 

It isn't under the charter right now,
but we are re-chartering and one of the issues
being discussed is CE to CE PWs
(you may recall
http://www.watersprings.org/pub/id/draft-stein-pwe3-pwce2e-00.txt )

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 28 Sep 2004 09:35:17 +0200

Eric and all,
I did not imply that STUN as a solution is applicable to PWE3.
I just used it as a reference documenting known variance in
existing NAT implementation and deployment. I would be glad
to accept another reference document if you think it is more
suitable.

Further, I think that IF we discuss NAT traversal by PWs,
we should explicitly address known variance of NAT implementation
and deployment. We may then find out that some case are
completely irrelevant to PWE3, while some should be addressed.
But we should not simply ignore these cases unless we decide that
PWs MUST NOT, under any circumstances, traverse NAT.

One specific use case that the STUN document describes is
the case when NAT that is under administration of the 
access network SP while UDP flows that traverse it are 
under administration of the end user. 

IMO, some of the proposed approaches for using UDP ports as 
PW demultiplexers simply will not work in this case as they
assume (implicitly) that NAT can be explicitly configured
by the end user.

Hopefully these notes clarify my position.

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, September 27, 2004 4:22 PM
> To: Sasha Vainshtein
> Cc: 'Yaakov Stein'; Thomas Narten; [email-masked]; Jon 
> Peterson; [email-masked]; Allison Mankin; Stewart Bryant; W. 
> Mark Townsley
> > NAT implemenation and deployment variations. 
> 
> I don't  really see  the applicability of  STUN to  PWE3.  
> STUN seems  to be
> aimed at situations where the endsystems engage in a 
> signaling protocol that
> itself has  to carry network layer  addresses.  Thus each  
> endsystem must be
> able to  figure out the  public network layer  address which 
> can be  used to
> reach it.  The STUN  spec specifies a set of hacks which  
> enable you to find
> this out dynamically, sometimes, under some circumstances. 
> 
> This seems aimed at providing limited  support for an SVC 
> type of model, not
> for the PVC type of model on which PWE3 has focused. 
> 
> In any event,  if you really want to function through  NATs 
> that surely what
> you want is  a tunneling protocol that  runs inside of UDP, 
> so  that the UDP
> header can be  used solely for getting the packets  to the 
> endsystems, while
> the  internal  tunneling  protocol  would  be used  for  
> demultiplexing  the
> pseudowires.  Then  whatever procedures you have  to use to  
> get through the
> NATs  would  not  need to  be  sensitive  to  the assignment  
> of  pseudowire
> multiplexing values.  (That would then be analogous to the 
> L2TPv3 inside UDP
> procedures that Mark mentioned.)  
> 
> 
>