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

From: Lucy yong <[email-masked]>
Date: Tue, 12 Feb 2013 16:23:57 +0000

Please see below and comments are welcome.

Lucy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2013 10:19 AM
> To: Lucy yong
> Cc: Xuxiaohu
> Subject: New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-
> tunneling-00.txt
> 
> 
> A new version of I-D, draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt
> has been successfully submitted by Lucy Yong and posted to the
> IETF repository.
> 
> Filename:	 draft-yong-tsvwg-udp-encap-4-ip-tunneling
> Revision:	 00
> Title:		 Generic UDP Encapsulation for IP Tunneling
> Creation date:	 2013-02-12
> WG ID:		 Individual Submission
> Number of pages: 14
> URL:             http://www.ietf.org/internet-drafts/draft-yong-tsvwg-
> udp-encap-4-ip-tunneling-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-yong-tsvwg-udp-
> encap-4-ip-tunneling
> Htmlized:        http://tools.ietf.org/html/draft-yong-tsvwg-udp-encap-
> 4-ip-tunneling-00
> 
> 
> Abstract:
>    This document describes a method for encapsulating network layer
>    protocols within UDP such that the payload protocol can be
>    identified from the destination port value. The mechanism also
>    allows for the source port to be used as the entropy field for the
>    purpose of load balancing in environments such as Equal Cost
>    Multipath (ECMP) in the underlying IP network.
> 
>    Application of this technique is focused on tunneling network
>    protocol flows across IP networks in environments where load-
>    balancing is required. No changes to the underlying IP network or
>    the payload networks are required.
> 
> 
> 
> 
> The IETF Secretariat

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 12 Feb 2013 16:46:51 +0000

Hi,

>> Filename:	 draft-yong-tsvwg-udp-encap-4-ip-tunneling

why do you require IANA to register a block of port numbers? You could simply use a block of private ports (> 49152) without registration. A lot of other tunneling state will need to be configured; requiring to configure which port block is used is just one more piece of information.

Lars

---

From: Lucy yong <[email-masked]>
Date: Tue, 12 Feb 2013 17:51:45 +0000

Hi Lars,

Thank you for the quick comments! 

As mentioned in the document and you point out, a block of port numbers make the implementation easier, e.g. may use of mask. Regarding IANA registry or private ports, for vendor hardware interworking, it is better to standardize the port number for the payload types. IANA registry is the way to achieve this. This is our suggestion and we would like to hear the opinions on this.

Since we have discussed this a lot among contributors, I include them in this thread in case that they are not a subscriber in this WG.

Regards,
Lucy

> From: Eggert, Lars [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2013 10:47 AM
> To: Lucy yong
> Cc: [email-masked]; Xuxiaohu
> Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-
> encap-4-ip-tunneling-00.txt
> 
> Hi,
> 
> why do you require IANA to register a block of port numbers? You could
> simply use a block of private ports (> 49152) without registration. A
> lot of other tunneling state will need to be configured; requiring to
> configure which port block is used is just one more piece of
> information.
> 
> Lars

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 Feb 2013 17:51:52 -0000

Hey Lars,

The thought is that it is useful for interop that ports are registered.
It is useful for implementations if all the ports used for this tunneling are
contiguous (although that may be tenuous).
It would be useful for future allocations for similar tunneling to be
contiguous.

However, the I-D does not ask to register a block of port numbers. It asks IANA
to consider reserving further ports for future similar use.

When you say "a lot of other tunneling state will need to be configured", what
have you in mind? What tunneling state is currently configured to carry stuff in
IP tunnels?

Cheers,
Adrian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Eggert, Lars
> Sent: 12 February 2013 16:47
> To: Lucy yong
> Cc: Xuxiaohu; [email-masked]
> Subject: Re: [tsvwg] New Version Notification for
draft-yong-tsvwg-udp-encap-4-
> ip-tunneling-00.txt
> why do you require IANA to register a block of port numbers? You could simply
> use a block of private ports (> 49152) without registration. A lot of other
tunneling
> state will need to be configured; requiring to configure which port block is
used is
> just one more piece of information.
> 
> Lars

---

From: <[email-masked]>
Date: Wed, 13 Feb 2013 08:31:16 +0100

Hi Lucy,

as the draft only specifies tunnel ingress and egress behaviour, these nodes are identified and configured by an operator I guess.

Further, the draft mentions DiffServ, but it doesn't mention ECN or Conex treatment. The latter two aren't widely deployed yet, but may see deployment if e.g. measurement based admission control is extended to real time services. So ECN and Conex treatment should become part of the draft.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, February 12, 2013 6:52 PM
To: Eggert, Lars
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 Lars,

Regards,
Lucy

---

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

Hey Ruediger,

Yes, an operator needs to configure an IP tunneling application at the desired tunnel end points.

I assume what you mean: the underlying IP network congestion and ECN notification. IMO: the tunnel egress should be able to pass the ECN status from the underlying network to an IP tunneling application. We will mention that in the next version. However, the underlying network congestion control is out of the scope. The congestion control mechanism in underlying network should be the same regardless if the udp encapsulation described in this document is used or not. Does this make a sense to you?

Thank you for the comment.

Lucy   

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2013 1:31 AM
> To: Lucy yong
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Xuxiaohu
> Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-
> as the draft only specifies tunnel ingress and egress behaviour, these
> nodes are identified and configured by an operator I guess.
> 
> Further, the draft mentions DiffServ, but it doesn't mention ECN or
> Conex treatment. The latter two aren't widely deployed yet, but may see
> deployment if e.g. measurement based admission control is extended to
> real time services. So ECN and Conex treatment should become part of
> the draft.
> 
> Regards,
> 
> Ruediger
> 
> Cc: [email-masked]; 'John E Drake'; 'Edward Crabbe';
> [email-masked]; 'Carlos Pignataro (cpignata)';
> [email-masked]; [email-masked]; 'Lee, Yiu'; Xuxiaohu
> As mentioned in the document and you point out, a block of port numbers
> make the implementation easier, e.g. may use of mask. Regarding IANA
> registry or private ports, for vendor hardware interworking, it is
> better to standardize the port number for the payload types. IANA
> registry is the way to achieve this. This is our suggestion and we
> would like to hear the opinions on this.
> 
> Since we have discussed this a lot among contributors, I include them
> in this thread in case that they are not a subscriber in this WG.
> 
> Regards,
> Lucy
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 13 Feb 2013 16:11:48 -0000

Yes, Ruediger!

I've been wittering on to the other co-authors about the need to look at
congestion properly, but sadly I am no expert in that field.

I'm not sure whether this is "only" mapping congestion information from the
tunneled protocol into the IP/UDP of the tunnel, or whether the tunnel itself
has to be congestion aware.

In the former case, the requirement will be mixed (some network layers do not
have congestion signaling, and some do). In the latter case, I have no clue
where to start!

Cheers,
Adrian

> [email-masked]
> Sent: 13 February 2013 07:31
> To: [email-masked]
> [email-masked]; [email-masked]; [email-masked]
> ip-tunneling-00.txt
> 
> Hi Lucy,
> 
> as the draft only specifies tunnel ingress and egress behaviour, these nodes
are
> identified and configured by an operator I guess.
> 
> Further, the draft mentions DiffServ, but it doesn't mention ECN or Conex
> treatment. The latter two aren't widely deployed yet, but may see deployment
if
> e.g. measurement based admission control is extended to real time services. So
> ECN and Conex treatment should become part of the draft.
> 
> Regards,
> 
> Ruediger
> 
> Lucy yong
> Cc: [email-masked]; 'John E Drake'; 'Edward Crabbe'; [email-masked];
> 'Carlos Pignataro (cpignata)'; [email-masked]; [email-masked];
> 'Lee, Yiu'; Xuxiaohu
> As mentioned in the document and you point out, a block of port numbers make
> the implementation easier, e.g. may use of mask. Regarding IANA registry or
> private ports, for vendor hardware interworking, it is better to standardize
the
> port number for the payload types. IANA registry is the way to achieve this.
This
> is our suggestion and we would like to hear the opinions on this.
> 
> Since we have discussed this a lot among contributors, I include them in this
> thread in case that they are not a subscriber in this WG.
> 
> Regards,
> Lucy
>

---

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

On 2/12/2013 9:51 AM, Lucy yong wrote:
> As mentioned in the document and you point out, a block of port numbers make the implementation easier, e.g. may use of mask.

FWIW, a block of port numbers will be *very* difficult to get, and IANA 
doesn't reserve blocks for future use anymore.

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.

Joe

---

From: <[email-masked]>
Date: Thu, 14 Feb 2013 09:14:34 +0100

Hi Lucy,

the network section passed by the tunnel may in full or in parts support some form of ECN. The tunnel packets or the tunneled packets should then indicate the ECN markings at the ECN control end-points correctly. See http://www.rfc-editor.org/rfc/rfc6040.txt

You mention fragmentation in your draft. I couldn't find text about ECN and fragmentation in RFC6040. But http://www.rfc-editor.org/rfc/rfc3168.txt contains some.

I'm not a TCP congestion control expert and can't discuss that. I'm rather liking measurement based admission control for real time services, that's why I'm interested in ECN as a potential mechanism.

Regards,

Ruediger

-----Original Message-----
From: Lucy yong [mailto:[email-masked]]
Sent: Wednesday, February 13, 2013 3:30 PM
To: Geib, Rüdiger
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Xuxiaohu
Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt

Hey Ruediger,

Lucy

---

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

Hi Ruediger,

Thank you to info the rfc6040. Yes, we should clarity the ECN marking propagation and reference rfc6040. It will be fixed in next version.

Regards,
Lucy

> Sent: Thursday, February 14, 2013 2:15 AM
> To: Lucy yong
> the network section passed by the tunnel may in full or in parts
> support some form of ECN. The tunnel packets or the tunneled packets
> should then indicate the ECN markings at the ECN control end-points
> correctly. See http://www.rfc-editor.org/rfc/rfc6040.txt
> 
> You mention fragmentation in your draft. I couldn't find text about ECN
> and fragmentation in RFC6040. But http://www.rfc-
> editor.org/rfc/rfc3168.txt contains some.
> 
> I'm not a TCP congestion control expert and can't discuss that. I'm
> rather liking measurement based admission control for real time
> services, that's why I'm interested in ECN as a potential mechanism.
> 
> Regards,
> 
> Ruediger
> 
> I assume what you mean: the underlying IP network congestion and ECN
> notification. IMO: the tunnel egress should be able to pass the ECN
> status from the underlying network to an IP tunneling application. We
> will mention that in the next version. However, the underlying network
> congestion control is out of the scope. The congestion control
> mechanism in underlying network should be the same regardless if the
> udp encapsulation described in this document is used or not. Does this
> make a sense to you?
> 
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Lucy yong