Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-01.txt

[Lucy yong <[e-mail]>]

Hi Joe,

Another comment.

I have some concern on Figure 6 and Figure 8. Although it is right that tunnel endpoints are not visible in M network, tunnel endpoints are the network interfaces that need to be implemented on some devices that are visible to the M network; Figure 6 does not reflect that unless it states that the tunnel endpoints are implemented on Ra and Rd. Although the tunnel endpoints are viewed as a host in N network, the device that implements the tunnel endpoint may have another network interface that makes the device to be viewed as a router, Figure 8 and related statement does not point out that.  I know that the draft focus the tunnel behavior, but the figures somehow gives incomplete views, which may cause some confusion or misleading. You may consider clarifying these points.

Thanks,
Lucy

   


-----Original Message-----
From: Joe Touch [mailto:[e-mail]] 
Sent: Friday, August 21, 2015 5:30 PM
To: Templin, Fred L; Lucy yong
Cc: [e-mail]; [e-mail]
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-01.txt



On 8/21/2015 3:14 PM, Templin, Fred L wrote:
> Here is a good definition of "link" from RFC4861:
> 
>    link        - a communication facility or medium over which nodes can
>                  communicate at the link layer, i.e., the layer
>                  immediately below IP.  Examples are Ethernets (simple
>                  or bridged), PPP links, X.25, Frame Relay, or ATM
>                  networks as well as Internet-layer (or higher-layer)
>                  "tunnels", such as tunnels over IPv4 or IPv6 itself.

It's frankly tautological:

	"a link is a thing that communicates over a link layer"

Stepping into the "i.e.," part, it could be rewritten as:

	"a link is a communication layer that transits IP"

> The same definition also shows up in RFC2460.
>
> RFC3819 (PILC) is entirely about links, and could also be cited.

PILC is about subnets - i.e., multipoint links, not merely links. It similarly defines a subnet as anything that transits IP, though:

A subnetwork
refers to any network operating immediately below the IP layer to connect two or more systems using IP (i.e., end hosts or routers).

This definition doesn't preclude IP as a subnetwork. However, if we want to differentiate a link from a tunnel, it fails. I'm not sure that's a bad thing.

What I would like to do is:

	1. Say basically as above - an Internet link layer is
	a comm system that transits IP

	2. Note that, by this definition, IP tunnels are just
	as much links as Ethernet

	3. Note that, by common convention, a "conventional" link
	is directly implemented on a physical layer whereas
	a tunnel is implemented at least one layer removed

Note that, even by #3, if there were an IP implemented directly on a physical layer (which there could be), then it could carry IP traffic just like any other link layer.

Joe

> 
> Thanks - Fred
> [e-mail]
> 
>> -----Original Message-----
>> From: Int-area [mailto:[e-mail]] On Behalf Of Lucy 
>> yong
>> Sent: Friday, August 21, 2015 2:53 PM
>> To: Joe Touch
>> Cc: [e-mail]
>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-01.txt
>>
>> Hi Joe,
>>
>> [snip]
>>> The draft clearly defines what is tunnel, how that is different than 
>>> a traditional link (OSI stacks based). IMO: a tunnel simulates a 
>>> link; but a link, by definition, is not a tunnel.
>>
>> We can create a definition, e.g.:
>>
>> 	a tunnel uses a transit communication system that cannot stand
>> 	on its own
>>
>> 	a link uses a transit communication system that can stand on its
>> 	own
>>
>> I.e., IP can't exist without Ethernet (or something equivalent), but ethernet can exist without ethernet.
>>
>> Put another way:
>>
>> 	links touch physical links
>>
>> 	tunnels don't
>>
>> That might be useful to add to the beginning of Section 3.1, however 
>> it's an artificial distinction. We are defining a tunnel as different from a link only in their implementation - not their behavior, IMO.
>> [Lucy] Agree on this distinction. It aligns with the draft.
>>
>> Thanks,
>> Lucy
>>
>> Joe
>>
>>
>>
>>
>>>
>>> Regards,
>>> Lucy
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Joe Touch [mailto:[e-mail]]
>>> Sent: Friday, August 21, 2015 3:24 PM
>>> To: Lucy yong
>>> Cc: [e-mail]; [e-mail]
>>> Subject: Re: [Int-area] I-D Action: 
>>> draft-ietf-intarea-tunnels-01.txt
>>>
>>> Hi, Lucy,
>>>
>>> Focusing on issues that needed clarification:
>>>
>>> On 8/21/2015 12:39 PM, Lucy yong wrote:
>>> ...
>>>> For an IP-in-IP tunnel, that L2 address is the IP address of the egress decapsulator at the receiving router.
>>>> [Lucy] True, but it has implementation difference. This needs to be configured somehow.
>>>
>>> I'm assuming everything needs to be configured - there's no way to run a tunnel without configuring both ingress and egress.
>>>
>>> I would consider all the ingresses that lead to one egress as "one 
>>> tunnel", i.e., a multipoint tunnel. Yes, that needs to be added to
>> the description - so both one ingress to many egresses, many ingresses to one egress, and combinations thereof.
>>>
>>>
>>>>> In fact, such tunnel endpoint
>>>>> functions are a key technique for NVO3. Hope the draft can address 
>>>>> tunnel endpoint characteristics for this case as well, i.e. same 
>>>>> and difference compared to a network interface.
>>>>
>>>> The doc should go into more detail about this case, in which the 
>>>> difference is whether an IP address or a true L2 address 
>>>> differentiates the "network interface".
>>>> [Lucy] IP does not have all characteristics that Ethernet has.
>>>
>>> IP is closer to an NBMA L2 (unless there's native broadcast or 
>>> multicast between ingress and egress network N addresses), but it's
>> largely equivalent to most other types of L2s.
>>>
>>>>> *         Regarding tunnel encapsulation, the key driver for NVO3 is to
>>>>> support multi-tenant environment, which results that multiple 
>>>>> virtual networks share one same tunnel. The draft may 
>>>>> discuss/point out how that impacts the tunnel (the link) operation 
>>>>> and behavior and individual virtual networks carried by a tunnel.
>>>>
>>>> Can you clarify? If these are separate virtual networks, how can 
>>>> they share a network interface unless they have a "gateway" to
>> "relay"
>>>> between the virtual networks?
>>>>
>>>> [Lucy] NVO3 means that a virtual network is implemented over an IP 
>>>> network where virtual network traffic is encapsulated at the edge 
>>>> node
>>>> (NVE) and carried over the IP network.
>>>
>>> That's just a multipoint tunnel IMO.
>>>
>>>> [RFC7365] one edge node can
>>>> server to multiple virtual networks and encapsulates virtual 
>>>> network traffic by VXLAN where a VNID is used to segregate virtual 
>>>> network traffic.
>>>
>>> AS I note below, that's equivalent to L2 aliasing.
>>>
>>>> As result, tunnel ingress encapsulates VN traffic with different 
>>>> VNIDs but outer IP addresses are the same.
>>>
>>> Whether you use multiple IPs or one IP with multiple VNIDs is a 
>>> detail that does affect some aspects, but it's somewhat "in the
>> details" for this doc. I.e., the VNID isn't substantially different than a UDP header between the two IP headers.
>>>
>>>> In short, one
>>>> tunnel can carry the traffic and use the encapsulation to segregate 
>>>> the virtual network traffic.
>>>
>>> I would still not consider that one single tunnel, regardless of NVO3 terminology.
>>>
>>>>
>>>> Or are you talking about something equivalent to a VLAN? (see below
>>>> -- I think this might be a VLAN, in which case the text is easy to 
>>>> extend to explain).
>>>>
>>>> [Lucy] IMO: this is different from VLAN. VLAN technology is also 
>>>> virtual network technology but has different implementation.
>>>
>>> Yes, I didn't mean that they were identical in implementation but very similar in spirit.
>>>
>>>> Bridging
>>>> technology does not use tunnel, it forms a virtual network by VLAN 
>>>> tag that is known to every nodes.
>>>
>>> Ethernet VLANs use an Ethernet L2 header and adds a VLAN ID extension.
>>>
>>> NVO3 uses a IP as an L2 header and adds a VNID extension.
>>>
>>> They're nearly identical in that regard; there are some other differences when it comes to broadcast, but that's about all AFAICT.
>>>
>>>>> *         Text: From the perspective of the outermost hosts (Hsrc and
>>>>> Hdst), the tunnel appears as a link between two routers (Ra and Rd).
>>>>>
>>>>> Comment: IMO: from M network view (i.e. topology), tunnel appears 
>>>>> as a link between two routers; the hosts (Hsrc and Hdst) are not 
>>>>> aware of the existence of Rc and Rd.
>>>>
>>>> The hosts can be aware of routers Ra and Rd (e.g., they see them in 
>>>> the hopcount decrement and might receive traceroute responses from 
>>>> them if they participate) but not Rb or Rc.
>>>>
>>>> Can you explain why you think Rd isn't visible to Hsrc and Hdst?
>>>>
>>>> [Lucy] Sorry, my mistate in the first place. It should be Rb and Rc.
>>>> My origin point is that the link exists between Ra and Rd.
>>>
>>> That's what the doc already says.
>>>
>>>> The hosts are
>>>> not aware of the link, M network (routers) are aware of it.
>>>
>>> Yes, directly, but the hosts are aware of the link in its impact on 
>>> the hopcount and those routers can participate in traceroute if they
>> want.
>>> That's quite different from Rb and Rc.
>>>
>>> I'll clarify the text to be more clear, though.
>>>
>>>
>>> ...
>>> ...
>>>> These principles should be more clear as to whether they're rules, 
>>>> observations, or interpretations. I'll address that in the next 
>>>> update.
>>>>
>>>> [Lucy] It is great if the draft will state out some principles 
>>>> rather than current interpretation.
>>>
>>> The answer depends a little on both.
>>>
>>>> The Internet Architecture was not
>>>> designed for tunnel application before.
>>>
>>> IMO it was - we just call it L2.
>>>
>>>> Now there are various tunnel
>>>> applications over the Internet. These principles are critical for 
>>>> what and How to evolve the Internet architecture to facilitate 
>>>> tunnel implementation and/or benefit to tunnel applications.
>>>
>>> Part of the point of the intro material is that tunnels are a 
>>> natural part of the architecture IF we treat them correctly, which 
>>> means
>> both principles and how we interpret existing requirements.
>>>
>>> ...
>>>>> *         When an encapsulation header contains a UDP header (used over
>>>>> IP net), a tunnel is still an IP tunnel although tunnel egress and 
>>>>> on the link it may be treated as UDP app., right?
>>>>
>>>> This document defines "IP tunnels" as tunnels that carry IP 
>>>> packets, regardless of the way in which they carry IP packets. It 
>>>> does focus on IP in IP but does also include a discussion on IP in 
>>>> other protocols (UDP in particular).
>>>>
>>>> [Lucy] I see. The document focuses on the M network that is IP and 
>>>> has a tunnel (link) between Ra and Rd. Tunnel endpoint 
>>>> implementation have two parts: provides the link function to M 
>>>> network, implement such link functions in N network.
>>>
>>> Exactly.
>>>
>>>> Since N network can be implemented
>>>> by different network protocols, it is fair for the draft do not 
>>>> consider the link implementation. Thus some of my suggestion may 
>>>> not apply to this draft. (sorry)
>>>
>>> That's OK; the draft should be more clear on this, and we can decide 
>>> otherwise (i.e., we can have a section that does focus on some
>> implementation issues in specific).
>>>
>>> We do discuss many implementation issues but in a fairly abstract manner, i.e., as would apply to any link implementation.
>>>
>>> Joe
>>>
>>>
>>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area