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

["Templin, Fred L" <[e-mail]>]

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.

The same definition also shows up in RFC2460.

RFC3819 (PILC) is entirely about links, and could also be cited.

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