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

[Lucy yong <[e-mail]>]

Pls see inline below.


On 11/2/2015 12:59 AM, Lucy yong wrote:
...
>> It would be useful for your draft to explicitly distinct two cases 
>> and point out the requirements for both cases. For example, ICMP usage.
> 
...
> 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.

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