Subject: RE: UDP ports and the ITU Liason

From: "Ron Cohen" <[email-masked]>
Date: Mon, 13 Sep 2004 22:55:29 -0700

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, September 13, 2004 5:09 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [PWE3] UDP ports and the ITU Liason
> 
> 
> 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
> 
> > -----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
> > 
> > 
> > 
> > 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
> > 
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked] (Amnon Ilan)
Date: Tue, 14 Sep 2004 10:57:05 +0200

Hi Richard,

Isn't the proposed use of UDP ports the same as UDP ports in RTP (VoIP)?
What is youre view regarding the use of UDP ports in RTP?

Regards,
Amnon.

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

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

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 14 Sep 2004 11:42:36 -0400

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

---------