Subject: Re: [Int-area] draft-ietf-intarea-tunnels

From: Joe Touch <[email-masked]>
Date: Sun, 1 Nov 2015 18:09:48 -0800

Hi, Lucy,

On 10/31/2015 5:56 PM, Lucy yong wrote:
> Hi Joe,
> 
> Your tunnel draft addresses IP tunnel in the Internet, i.e. both M
> network and N network (in the draft) are on the Internet.

Yes, that's an area already identified for update for clarity.

> The draft describes the arch and req. for use portion of the
> Internet providing a link to other portion of the Internet.
> 
> There are also applications that using portion of the Internet
> provides many links to individual private IP networks, i.e. one link to
> one private IP network. e.g. network virtualization.

Network virtualization has many - often inconsistent and mutually
conflicting - definitions. E.g., IMO, any network that includes tunnels
as links includes network virtualization. A truly virtual network is one
composed entirely of tunnels, IMO.

> It would be useful for your draft to explicitly distinct two cases
> and point out the requirements for both cases. For example, ICMP usage.

I don't see them as distinct. Whether a network is connected to the
public Internet or not is less important than whether IPv4 or IPv6 is
used as the network layer.

Can you clarify how the second case might be distinct from the first
regarding ICMP use or any other aspect?

Joe

> Regards,
> Lucy

---

From: Lucy yong <[email-masked]>
Date: Mon, 2 Nov 2015 08:59:08 +0000

> The draft describes the arch and req. for use portion of the Internet 
> providing a link to other portion of the Internet.
> 
> provides many links to individual private IP networks, i.e. one link 
> to one private IP network. e.g. network virtualization.

Network virtualization has many - often inconsistent and mutually conflicting - definitions. 
[Lucy] So a proper architecture helps resolving the mess.
E.g., IMO, any network that includes tunnels as links includes network virtualization. A truly virtual network is one composed entirely of tunnels, IMO.
[Lucy] not sure. 

> It would be useful for your draft to explicitly distinct two cases and 
> point out the requirements for both cases. For example, ICMP usage.

I don't see them as distinct. Whether a network is connected to the public Internet or not is less important than whether IPv4 or IPv6 is used as the network layer.
[Lucy] Less important does not mean not an important. Agree Ipv4 or Ipv6 as underlay is important one.

Can you clarify how the second case might be distinct from the first regarding ICMP use or any other aspect?
[Lucy] One example, in second case, upon receiving ICMP, the router that ingress tunnel terminate has to determine which network the msg need to be sent out while the first case only has one network over the tunnel. In second case, these networks using the same IP tunnel run in ship-in-night mode. In other words, dedicate tunnel vs shared tunnel. 

Lucy 

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Nov 2015 07:30:16 -0800

On 11/2/2015 12:59 AM, Lucy yong wrote:
...
>> point out the requirements for both cases. For example, ICMP usage.
...
> [Lucy] One example, in second case, upon receiving ICMP, the router
> that ingress tunnel terminate has to determine which network the msg
> need to be sent out while the first case only has one network over
> the tunnel. In second case, these networks using the same IP tunnel
> run in ship-in-night mode. In other words, dedicate tunnel vs shared
> tunnel.

When an ICMP arrives at the tunnel ingress, it ought to modify the
ingress's interface properties as needed. *Subsequent* packets that
arrive at the interface might result in ICMPs generated back to the
source - but that would happen in the router/host attached to the
ingress interface, not inside the ingress mechanism itself. Device
drivers don't themselves generate ICMPs.

If two networks use the same tunnel, then the host or router that uses
the tunnel that way needs to run a dynamic mechanism over that tunnel to
differentiate how it supports each - e.g., dynamic routing.

Remember that ICMPs inside a tunnel are *link* indicators of tunnel
behavior - as far as the original source packets are concerned. ATM and
ethernet link errors aren't necessarily translated into ICMPs, nor
should internal tunnel ICMPs.

Joe

---

From: Lucy yong <[email-masked]>
Date: Tue, 3 Nov 2015 09:18:35 +0000

Pls see inline below.

...
> need to be sent out while the first case only has one network over the 
> tunnel. In second case, these networks using the same IP tunnel run in 
> ship-in-night mode. In other words, dedicate tunnel vs shared tunnel.

When an ICMP arrives at the tunnel ingress, it ought to modify the ingress's interface properties as needed. *Subsequent* packets that arrive at the interface might result in ICMPs generated back to the source - but that would happen in the router/host attached to the ingress interface, not inside the ingress mechanism itself. Device drivers don't themselves generate ICMPs.

If two networks use the same tunnel, then the host or router that uses the tunnel that way needs to run a dynamic mechanism over that tunnel to differentiate how it supports each - e.g., dynamic routing.
[Lucy] IMO: it is worth to point out this in the draft.    

Remember that ICMPs inside a tunnel are *link* indicators of tunnel behavior - as far as the original source packets are concerned. 
[Lucy] yeah, a link never terminates/inspects ICMP.

Lucy
ATM and ethernet link errors aren't necessarily translated into ICMPs, nor should internal tunnel ICMPs.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Nov 2015 07:39:54 -0800

> [Lucy] IMO: it is worth to point out this in the draft. 

Certainly.