Subject: Re: UDP ports and the ITU Liason

From: Eric Rosen <[email-masked]>
Date: Tue, 21 Sep 2004 12:53:54 -0400

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: Eric Rosen <[email-masked]>
Date: Mon, 27 Sep 2004 10:21:41 -0400

> 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. 

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.)