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

[Joe Touch <[e-mail]>]

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