Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 13 Feb 2013 21:19:15 -0000

Hi Joe,

Useful to get input from one of the Expert Reviewers for user Ports.
 
> Even the current draft assumes a fairly large number - 7.
> 
> If you can make this fly with 1 sure, and 2 *maybe*. But more than that
> is likely to have significant pushback.
> 
> Keep in mind that each tunnel might support only one encapsulation, but
> that this can (IMO should) be determined on a per-tunnel basis either by
> configuration or in-band negotiation. You don't need port numbers to
> indicate protocol parameters.
> 
> FWIW, making the implementation easier is not a consideration; reducing
> the number of port numbers needed is.

I'm not trying to be pugilistic here, but just understand the rules and
guidelines. 
RFC 6335 seems fairly clear to me, but it sounds like you are suggesting that
user ports are an even more scarce resource such that encapsulation in UDP
should either:
- use a further shim to identify the payload protocol
or
- use a signaling protocol to arrive at an understanding of what
   payload protocol is being used between a pair of dynamic ports

Both of these are achievable.

But I wonder how that relates to the way other protocols are carried over UDP.
There is, for example, an I-D just going through about encapsulating SCTP in UDP
using port 9899. Now I'll grant that 9899 was assigned a million years ago, but
why was a separate port assigned when there could have been signaling followed
by use of a dynamic port? And so on, and so on. Each new protocol that wants to
be carried in UDP asks for (and seemingly gets) a new port for the protocol to
listen on. This is done without use of either of the techniques I suggested
above.

So what is the guidance?
How does a protocol designer know whether to ask for a new port?

Thanks,
Adrian

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Feb 2013 14:48:14 -0800

Hi, Adrian,

> Both of these are achievable.

Yes, ports are a scarce resource.

> by use of a dynamic port?

As you note, it was assigned a long time ago. Many things assigned in 
the past would have a higher hurdle now.

 > And so on, and so on. Each new protocol that wants to

We're working on a doc that explains exactly that, and it's not always 
an easy decision.

This doc is a good example of a set of encapsulations all being 
developed in a coordinated fashion, for which we can realistically 
expect better coordinated use of the port space.

It's also useful to understand the purpose of an assigned port. If you 
need to configure both endpoints of a tunnel, then you can just as 
easily add a (dynamic) port number to the configuration.

Finally, the guidance, IMO, is:

	- if you need one port, maybe

	- if you need more than one, look for ways to conserve
	ports more carefully
	
		if more ports are needed only for performance
		or implementation convenience, then you
		probably don't need them

Joe

---

From: Lucy yong <[email-masked]>
Date: Wed, 13 Feb 2013 22:51:12 +0000

Hi Joe,

Thank you for the input. 

IMO: The underlying IP network should use the same mechanism to indicate an tunneled network layer protocol whether the UDP encapsulation is used or not. IP header has the protocol type field for this purpose, thus it is important to carry the same semantics in the UDP encapsulation.

There are tunneled applications that are on a per-tunnel basis, but it is not necessary case for all. We should not set the bar for it.

Regards,
Lucy    

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2013 3:19 PM
> To: 'Joe Touch'; Lucy yong
> Cc: [email-masked]; 'John E Drake'; 'Edward Crabbe';
> [email-masked]; 'Carlos Pignataro (cpignata)';
> [email-masked]; [email-masked]; 'Lee, Yiu'; Xuxiaohu
> Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-
> encap-4-ip-tunneling-00.txt
> 
> Hi Joe,
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 13 Feb 2013 23:02:03 +0000

Hi Joe,

> 		or implementation convenience, then you

[Lucy] We should separate two concerns. 1) if we should use UDP port to indicate the payload, 2) if we should reserve a block of port number for 1). If 1) is yes, we have to reserve the set of ports regardless they are contiguous or not. "implementation convenience" in my previous mail applies only too. 

IMO: 1) for this application is necessary because we need to keep the same semantics whether UDP encapsulation is used or not. 

Lucy

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Feb 2013 15:06:43 -0800

Hi, Lucy,

On 2/13/2013 2:51 PM, Lucy yong wrote:
> Hi Joe,
>
> Thank you for the input.
>
> IMO: The underlying IP network should use the same mechanism to
> indicate an tunneled network layer protocol whether the UDP
> encapsulation is used or not. IP header has the protocol type field for
> this purpose, thus it is important to carry the same semantics in the
> UDP encapsulation.

"a tunneled network layer protocol" over UDP would be a fine goal, in 
which case UDP would carry only "network layer protocols". In that case, 
you could put IPv4 and IPv6 in the same port, because they are already 
identified in their own header.

However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not network layer 
protocols.

If you intend a "generic protocol for encapsulation", then you need to 
indicate the contents when the body isn't sufficient. The problem is 
that you expect to use the port number as that indication, and IMO that 
is not appropriate.

If the type of a tunnel is persistent, you can send the indication of 
tunnel body type once (at tunnel establishment), periodically, or on 
every packet. That type would indicate differences you can't determine 
in-band, e.g., IP (but not IPv4 vs IPv6, MPLS, GRE, etc.

I.e., the tunnel body type is your "next protocol" identifier, not the 
port number.

> There are tunneled applications that are on a per-tunnel basis, but
> itis not necessary case for all. We should not set the bar for it.

AOK, but in that case a single byte is more than sufficient to 
differentiate the tunnel types you are supporting.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Feb 2013 15:10:26 -0800

Hi, Lucy,

On 2/13/2013 3:02 PM, Lucy yong wrote:
> [Lucy] We should separate two concerns. 1) if we should use UDP port
> to indicate the payload, 2) if we should reserve a block of port number
> for 1). If 1) is yes, we have to reserve the set of ports regardless
> they are contiguous or not. "implementation convenience" in my previous
> mail applies only too.

IMO, the reasoning is in the opposite order:

	1. if you need more than one port, it's not a good solution

	2. (there is no #2).
	
> IMO: 1) for this application is necessary because we need to keep
> thesame semantics whether UDP encapsulation is used or not.

The semantics are not affected by whether the port number or the first 
byte of the UDP payload indicate the protocol type. Either way, your 
payload is not affected at all.

Joe

---

From: Lucy yong <[email-masked]>
Date: Wed, 13 Feb 2013 23:29:43 +0000

> payload is not affected at all.
[Lucy] Thank you for the suggestion. But this means that we use different approach for the IP tunneling application. If UDP encap. is not used, the protocol field in IP header is used to indicate the payload type. If IDP encap. is used, the first nibble in the payload is used to indicate payload type. 
IPv4, IPv6, ICMP, MPLS, etc are used the first nibble. For future network virtualization overlay such as VXLAN and NVGRE, not sure the first byte is a good way and the space is enough. 

If this is the basic role, I don't know why RFC6380 is just passed. It uses the port to indicate the payload type. 

Regards,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Wed, 13 Feb 2013 23:32:32 +0000

> However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not network
[Lucy] In your opinion, what are they? 

Lucy
> >>> that this can (IMO should) be determined on a per-tunnel basis
> either
> >> by
> >> user ports are an even more scarce resource such that encapsulation
> in
> >> UDP
> >> should either:
> >> using port 9899. Now I'll grant that 9899 was assigned a million
> years
> >> ago, but
> >> why was a separate port assigned when there could have been
> signaling
> >> followed
> >> by use of a dynamic port? And so on, and so on. Each new protocol
> that
> >> wants to

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Feb 2013 16:32:09 -0800

> If this is the basic role, I don't know why RFC6380 is just passed. It uses the port to indicate the payload type.

Do you mean that RFC? "Suite B Profile for Internet Protocol Security 
(IPsec)"?

If you're referring to RFC 6830 (LISP), the difference in the two ports 
is that they are providing different services; one is data, one is 
control. FTP has a similar separation of data and control ports; that's 
not unusual, since it prevents head-of-line blocking if the same port is 
used for data and control.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Feb 2013 16:44:06 -0800

> [Lucy] In your opinion, what are they?

Network is L3.

MPLS is L2.5, more like a virtual physical layer. It typically runs 
outside IP.

GRE and VXLAN typically run over (as a payload inside) IP, so at best 
they are L3.5.

You can't send these over the same channel natively without some 
indication of what is being sent, so requiring the encapsulation to have 
that indication in-band would be exactly the same as would be required 
if these were native.

Joe

---

From: Lucy yong <[email-masked]>
Date: Thu, 14 Feb 2013 15:06:32 +0000

Yes, I mean to say RFC6830. Sorry.
Lucy

> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2013 6:32 PM
> To: Lucy yong
> Cc: [email-masked]; [email-masked]; 'John E Drake'; 'Edward
> Crabbe'; [email-masked]; 'Carlos Pignataro (cpignata)';
> Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-
> > [Lucy] Thank you for the suggestion. But this means that we use
> different approach for the IP tunneling application. If UDP encap. is
> not used, the protocol field in IP header is used to indicate the
> payload type. If IDP encap. is used, the first nibble in the payload is
> used to indicate payload type.
> > IPv4, IPv6, ICMP, MPLS, etc are used the first nibble. For future
> network virtualization overlay such as VXLAN and NVGRE, not sure the
> first byte is a good way and the space is enough.
> >
> > If this is the basic role, I don't know why RFC6380 is just passed.
> It uses the port to indicate the payload type.
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 14 Feb 2013 15:08:44 +0000

Thank you to share your view. But not sure agree to.
Lucy

> Sent: Wednesday, February 13, 2013 6:44 PM
> To: Lucy yong
> >>>> Subject: RE: [tsvwg] New Version Notification for draft-yong-
> tsvwg-
> >> udp-
> >>>>> If you can make this fly with 1 sure, and 2 *maybe*. But more
> than
> >>>> that
> >>>>> Keep in mind that each tunnel might support only one
> encapsulation,
> >>>> but
> >>>> I'm not trying to be pugilistic here, but just understand the
> rules
> >> and
> >>>> guidelines.
> >>>> But I wonder how that relates to the way other protocols are
> carried
> >>>> over UDP.
> >>>> There is, for example, an I-D just going through about
> encapsulating
> >>>> SCTP in UDP

---

From: Joe Touch <[email-masked]>
Date: Thu, 14 Feb 2013 09:48:23 -0800

FWIW, one additional point on this:

port numbers are intended to differentiate *services*, not payload types 
within a given service.

This draft appears to describe a single service - that of using UDP as 
an encapsulation for a variety of different protocol layers. That's one 
service, thus one port. Any further differentiation is the 
responsibility of this service to support, e.g., as a "protocol layer" 
of this service.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 15 Feb 2013 18:12:49 +0000

I've just looked at this now, and have some very quick observations, 
that I'll post to the list:

I am surprised to see that you think RFC5405 design considerations do 
not apply. As I recall, the RFC explicitly speaks about tunnels (e.g. 
section 3.1).

Section 2 describes the use of the zero UDP checksum option for IPv6, 
which is interesting, but I note that the draft does not consider the 
mechanisms that have been specified in

I am not sure why the proposed protocol uses 9 port numbers, echoing 
Joe's comment below that they are not usually utilised to differentiate 
the payload. I'm assuming the src port would be different for each flow, 
so from the point of ECMP, wouldn't that be enough entropy to separate 
the traffic?

Gorry (as a list member)

---

From: Lucy yong <[email-masked]>
Date: Fri, 15 Feb 2013 20:11:55 +0000

Hi Gorry,

Thank you to look at this and give some feedbacks.

RFC5405 provides the design considerations for the case that use of UDP  provides a tunnel mechanism to a upper layer application. This is not the intention of this draft. This draft is about the use UDP header to provide the load balancing information and payload type for an IP network, which may applies to various IP tunneling application. It has no intention to use the UDP to provide any transport function. Therefore, it states that the design consideration in RFC5405 does not apply to this application.

Regarding the zero UDP checksum for IPv6, thank you for the point out. We will fix the text to align with the draft-ietf-6man-updchecksums. 

We thank Joe for the comments and guideline about UDP port assignment rule. Src port have 16 bits. Do you suggest using the src port for both entropy and payload type? This is a potential alternative. We like to get the community feedback on where is the right place to encode the payload type for this application.  

The 9 addition port number makes total 16 port numbers, which is a pretty number.

Regards,
Lucy 

> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Friday, February 15, 2013 12:13 PM
> To: Joe Touch
> Cc: Lucy yong; [email-masked]; 'Carlos Pignataro (cpignata)';
> 'Edward Crabbe'; [email-masked]; 'John E Drake';
> >>>>> However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not
> network
> >>>>> layer
> >>>>> protocols.
> >>>>> If you intend a "generic protocol for encapsulation", then you
> need
> >>> to
> >>>>> that you expect to use the port number as that indication, and
> IMO
> >>> that
> >>>>> is not appropriate.
> >>>>>
> >>>>> If the type of a tunnel is persistent, you can send the
> indication
> >>> of
> >>>>> I.e., the tunnel body type is your "next protocol" identifier,
> not
> >>> the
> >>>>> port number.
> >>>>>
> >>>>>>>> configuration or in-band negotiation. You don't need port
> numbers
> >>>>> to
> >>>>>>> be carried in UDP asks for (and seemingly gets) a new port for
> the
> >>>>>>> protocol to
> >>>>>>> listen on. This is done without use of either of the techniques
> I
> >>>>>>> suggested
> >>>>>>> above.
> >>>>>>>
> >>>>>>> So what is the guidance?

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 13:20:52 -0800

Hi, Lucy (et al.),

On 2/15/2013 12:11 PM, Lucy yong wrote:
...
> We thank Joe for the comments and guideline about UDP port
> assignment rule. Src port have 16 bits. Do you suggest using the src
> port for both entropy and payload type?

Source port helps differentiate different streams between two IP 
endpoints to the same service, but I would not strictly call that 
"entropy". It can be useful to keep flows separate, as Gorry noted, and 
can indicate a flow type *after* some other mechanism (in band or out of 
band) provides initial information of the flow type - that way you can 
avoid needing to send a shim layer in every payload.

The source port cannot be used as payload type. Depending on your view, 
either you can't reserve them at all or they are reserved by the same 
IANA process as destination ports (I've heard both arguments, but 
without going into detail they're equivalent here - the source port 
isn't useful as a known quantity).

Joe

---

From: [email-masked]
Date: Sat, 16 Feb 2013 09:04:25 -0000

Hi,

Some more thoughts on port usage:

I would like to understand whether we REALLY need a separate destination
port per protocol. I think that it would relatively easy to use a header
byte in the payload to differentiate tunnel control messages and tunnelled
(encapsulated) IP packets. If you do this, wouldn't it be possible to run
over one port. GRE, for example, runs over one IP codepoint.

When you talk about the source port reflecting payload type, were you
suggesting a tunnel control protocol negotiates using a setup packet what
protocol is being used? - that seems a possibility with each (src,dst)
pair being dynamically transported protocol? (or have I misunderstood?)

On the source port, I was expecting that each "tunnel" could have one
source port. I'm not clear of your use cases, are we expecting multiple
associations to the same destination that want to use with ECMP for
example? in which case, this seems it would imply multiple src ports in
use from the same sender, allowing each to be independently be routed? 
(This was why I mentioned "entropy" for ECMP).

Gorry

---

From: Lucy yong <[email-masked]>
Date: Wed, 20 Feb 2013 20:19:01 +0000

Gorry,

Please see inline.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, February 16, 2013 3:04 AM
> To: Joe Touch
> Cc: Lucy yong; [email-masked]; [email-masked]; 'Edward
> Crabbe'; [email-masked]; 'John E Drake'; 'Carlos Pignataro (cpignata)';
[Lucy] Theoretically, we can do that way, i.e. implementing a shim at tunnel end point. But many existing hardware are not able to do that, it may interfere with other existing shims.

Since you did not mean the following in your previous mail, I interpreted you wrong. Let's take this off table now.

Regards,
Lucy

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Feb 2013 12:50:04 -0800

> Since you did not mean the following in your previous mail, I interpreted you wrong. Let's take this off table now.

Can you explain? Existing hardware won't support any new port number 
assignments anyway. Adding a field for demultiplexing is trivial given 
the other requirements.

Joe