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

From: Lucy yong <[email-masked]>
Date: Fri, 21 Aug 2015 16:36:03 +0000

Hi Joe and Mark,

The draft is well written, I enjoy reading it. Here are some comments.

*         I agree the description about a tunnel and different view points to a tunnel. However when tunnel mechanism is used to implement an overlay network such as NVO3, each tunnel ingress and egress is a tunnel (link) termination point for multiple tunnels (links). In this case, a router, Ra, in M network needs to be aware the links to its next hop routers but not the end points. More than likely, designating single IP address for each tunnel endpoint is not practical for this case although it can be done technically. 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.

*         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.

*         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.

*         Text: "These observations make it much easier to determine what a tunnel must do to transit IP packets, notably it must satisfy all requirements expected of a link." Is there a reference for an IP link requirement? What are the requirements for IP link? I want to know it personally.

*         Text:

   o  The addresses of ...

     Many point-to-point tunnels are unnumbered in the network in which

      they reside (even though they must have addresses in the network

      they transit).

Is this rule? IMO: either unnumbered or numbered can be used in this case.

   o  Like network interfaces, the ingress and egress are never a direct

      source of ICMP messages but may provide information to their

      attached host or router to generate those ICMP messages.

Is this a rule or current usage?

*         Regarding for a network interface to provide a hint to its attached device in Section of signaling, this is multi-layer problem; and for a tunnel to support multiple virtual networks make it more complex. However two networks can used other approach via controller to interactive each other.

*         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?

Look forward to reading other incomplete sections.

Thanks & Regards,

Lucy

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Monday, July 20, 2015 1:17 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-01.txt

Hi, all,

This is the long overdue revision to the tunnels document.

The revision is based on the outline presented at the last IETF.

It would be most useful to comment on the overall document before providing nit-level feedback, but both are welcome, of course.

Joe

On 7/20/2015 11:04 AM, [email-masked]<mailto:[email-masked]> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.

>  This draft is a work item of the Internet Area Working Group Working Group of the IETF.

>         Title           : IP Tunnels in the Internet Architecture

>         Authors         : Joe Touch

>                           Mark Townsley

>     Filename        : draft-ietf-intarea-tunnels-01.txt

>     Pages           : 40

>     Date            : 2015-07-20

> Abstract:

>    This document discusses the role of IP tunnels in the Internet

>    architecture. It explains their relationship to existing protocol

>    layers and the challenges in supporting IP tunneling based on the

>    equivalence of tunnels to links.

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/

> There's also a htmlized version available at:

> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-01

> A diff from the previous version is available at:

> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-01

> Please note that it may take a couple of minutes from the time of

> submission until the htmlized version and diff are available at tools.ietf.org.

> Internet-Drafts are also available by anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

> _______________________________________________

> Int-area mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________

Int-area mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Fri, 21 Aug 2015 09:58:49 -0700

Hi Joe,

It might be good to reference draft-ietf-rtgwg-dt-encap-00 in this
draft. I think it may be complementary where
draft-ietf-intarea-tunnels describes architecture and tunneling
semantics, and draft-ietf-rtgwg-dt-encap focuses on the mechanics of
underlying encapsulation for tunnels. Right now there's some
redundancy and possibly some inconsistencies that should be rectified
(for instance the encap design draft also talks about IPv6 checksum
requirements).

Thanks,
Tom

On Mon, Jul 20, 2015 at 11:16 AM, Joe Touch <[email-masked]> wrote:
> It would be most useful to comment on the overall document before
> providing nit-level feedback, but both are welcome, of course.
>
> Joe
>
> On 7/20/2015 11:04 AM, [email-masked] wrote:
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> [email-masked]
> [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Aug 2015 10:13:42 -0700

Hi, Lucy,

On 8/21/2015 9:36 AM, Lucy yong wrote:
> ·         I agree the description about a tunnel and different view
> points to a tunnel. However when tunnel mechanism is used to implement
> an overlay network such as NVO3, each tunnel ingress and egress is a
> tunnel (link) termination point for multiple tunnels (links).

Agreed; that needs to be added to the description.

> In this
> case, a router, Ra, in M network needs to be aware the links to its next
> hop routers but not the end points. 

On any multippoint L2, Ra needs an L2 destination address (Network N) to
differentiate the destination L2.

For an IP-in-IP tunnel, that L2 address is the IP address of the egress
decapsulator at the receiving router.

> More than likely, designating single
> IP address for each tunnel endpoint is not practical for this case
> although it can be done technically.

Each tunnel needs "Network N" addresses. It does not need "Network M"
addresses.

> 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".

> ·         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?

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).

> ·         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?

> ·         Text: “These observations make it much easier to determine
> what a tunnel must do to transit IP packets, notably it must satisfy all
> requirements expected of a link.” Is there a reference for an IP link
> requirement? What are the requirements for IP link? I want to know it
> personally.

These are derived from RFCs 791, 1122, 2460 and 3819. I'm not sure
they've been summarized anywhere other than 3819 -- which focuses more
on special issues that are often ignored.

> ·         Text:
>    o  The addresses of …

It's stated as an observation rather than a rule, and it indicates a
likelihood. It isn't stated in a way that prevents tunnels from being
numbered in Network M.

> Is this a rule or current usage?  

It's more of an interpretation. Network interfaces don't generate ICMPs
-- the routers or hosts they belong to do. Tunnels ought to work the
same way conceptually, regardless of how they're implemented.

These principles should be more clear as to whether they're rules,
observations, or interpretations. I'll address that in the next update.

> ·         Regarding for a network interface to provide a hint to its
> attached device in Section of signaling, this is multi-layer problem;
> and for a tunnel to support multiple virtual networks make it more
> complex. However two networks can used other approach via controller to
> interactive each other.

It would help to understand "a tunnel that supports multiple virtual
networks". AFAICT, you're referring to the tunnel equivalent of an L2
VLAN, which is just a link with multiple L2 addresses.

If that's the case, I will add text to explain. If not, can you clarify?
> 
> ·         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).

Regardless of how the IP tunnel is implemented, it needs to be
considered a link to network M.

In network N, a UDP tunnel would look like an app.

Again, more to add ;-)

> Look forward to reading other incomplete sections.

Thanks, and thanks for the info above.

Joe

>> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Aug 2015 10:14:29 -0700

> (for instance the encap design draft also talks about IPv6 checksum

Hi, Tom,

I'll certainly take a look - it's worth citing, but let's also check the
issues between the two docs as well.

Joe

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Aug 2015 19:39:03 +0000

Hi Joe,

Thank you for the quick response. Please see inline below.

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Friday, August 21, 2015 12:14 PM
To: Lucy yong; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-01.txt

Hi, Lucy,

On 8/21/2015 9:36 AM, Lucy yong wrote:
> *         I agree the description about a tunnel and different view

> In this
> case, a router, Ra, in M network needs to be aware the links to its 
> next hop routers but not the end points.

On any multippoint L2, Ra needs an L2 destination address (Network N) to differentiate the destination L2.
[Lucy] L2 link can turn up itself and learn the MAC address.

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.

Each tunnel needs "Network N" addresses. It does not need "Network M"
addresses.
[Lucy] Yes; and multiple tunnels can share one tunnel endpoint address too.

> 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.

> *         Regarding tunnel encapsulation, the key driver for NVO3 is to
> 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. [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 result, tunnel ingress encapsulates VN traffic with different VNIDs but outer IP addresses are the same. In short, one tunnel can carry the traffic and use the encapsulation to segregate the virtual network traffic.  

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. Bridging technology does not use tunnel, it forms a virtual network by VLAN tag that is known to every nodes. 

> *         Text: From the perspective of the outermost hosts (Hsrc and

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. The hosts are not aware of the link, M network (routers) are aware of it.

> *         Text: "These observations make it much easier to determine
> what a tunnel must do to transit IP packets, notably it must satisfy 
> all requirements expected of a link." Is there a reference for an IP 
> link requirement? What are the requirements for IP link? I want to 
> know it personally.

These are derived from RFCs 791, 1122, 2460 and 3819. I'm not sure they've been summarized anywhere other than 3819 -- which focuses more on special issues that are often ignored.
[Lucy] Thank you for the info. 

> Is this rule? IMO: either unnumbered or numbered can be used in this case.

It's stated as an observation rather than a rule, and it indicates a likelihood. It isn't stated in a way that prevents tunnels from being numbered in Network M.

It's more of an interpretation. Network interfaces don't generate ICMPs
-- the routers or hosts they belong to do. Tunnels ought to work the same way conceptually, regardless of how they're implemented.

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 Internet Architecture was not designed for tunnel application before. 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. 

> *         Regarding for a network interface to provide a hint to its
> complex. However two networks can used other approach via controller 
> to interactive each other.

It would help to understand "a tunnel that supports multiple virtual networks". AFAICT, you're referring to the tunnel equivalent of an L2 VLAN, which is just a link with multiple L2 addresses.
[Lucy] As I mentioned above, IMO, a VN can be implemented by tunnel technique or bridge technique, but implementations are different.  

If that's the case, I will add text to explain. If not, can you clarify?
[Lucy] No, let me know if I made that clear above.
> 
> *         When an encapsulation header contains a UDP header (used over

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. 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) 

Thanks,
Lucy

Regardless of how the IP tunnel is implemented, it needs to be considered a link to network M.

Again, more to add ;-)

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Aug 2015 13:23:33 -0700

Hi, Lucy,

Focusing on issues that needed clarification:

On 8/21/2015 12:39 PM, Lucy yong wrote:
...
> [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.

> difference is whether an IP address or a true L2 address
> differentiates the "network interface".

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.

> [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.

> 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.
> 
> [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.

...
...
> [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.

...
> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Aug 2015 20:37:13 +0000

Hi Joe,

> Sent: Friday, August 21, 2015 1:24 PM
> To: Lucy yong
> Cc: [email-masked]

I agree. The term I see most frequently for this kind of tunnel is "Non-Broadcast,
Multiple Access (NBMA)". (Unless the underlying network is multicast-capable,
in which case the tunnel is simply "multiple access".) Tunnel endpoints are seen
as neighbors of the link, so standard link-scoped mechanisms like IPv6 ND and
DHCPv6 can be used the same as for an ordinary link. Would be good to see
this reflected in the draft.

Thanks - Fred
[email-masked]

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Aug 2015 20:51:18 +0000

Hi Fred,

[snip] 
> I'm assuming everything needs to be configured - there's no way to run 
> a tunnel without configuring both ingress and egress.
> 

I agree. The term I see most frequently for this kind of tunnel is "Non-Broadcast, Multiple Access (NBMA)". (Unless the underlying network is multicast-capable, in which case the tunnel is simply "multiple access".) Tunnel endpoints are seen as neighbors of the link, so standard link-scoped mechanisms like IPv6 ND and
DHCPv6 can be used the same as for an ordinary link. Would be good to see this reflected in the draft.
[Lucy] ARP and ND are used for MAC address resolution for a given IP. When tunnel is implemented over an IP network and is identified by IP address, to make them equivalent, will the protocols need to be enhanced to discover tunnel IP address, or which protocol does that now?  

Thanks,
Lucy  

Thanks - Fred

> >> tunnel endpoint characteristics for this case as well, i.e. same 
> >> and difference compared to a network interface.
> >
> 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.
> 
> >> 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"
> > As result, tunnel ingress encapsulates VN traffic with different 
> > VNIDs but outer IP addresses are the same.
> 
> 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.
> 
> >> 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 hopcount decrement and might receive traceroute responses from 
> > them if they participate) but not Rb or Rc.
> >
> 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.
> > [Lucy] It is great if the draft will state out some principles 
> > rather than current interpretation.
> 
> > what and How to evolve the Internet architecture to facilitate 
> > tunnel implementation and/or benefit to tunnel applications.
> 
> >> IP net), a tunnel is still an IP tunnel although tunnel egress and 
> >> on the link it may be treated as UDP app., right?
> >
> > 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.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Aug 2015 21:01:11 +0000

Hi Lucy,

> From: Lucy yong [mailto:[email-masked]]
> Sent: Friday, August 21, 2015 1:51 PM
> To: Templin, Fred L; Joe Touch
> Cc: [email-masked]
> Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-tunnels-01.txt
> 
> Hi Fred,
> 
> [snip]
> I agree. The term I see most frequently for this kind of tunnel is "Non-Broadcast, Multiple Access (NBMA)". (Unless the underlying
> network is multicast-capable, in which case the tunnel is simply "multiple access".) Tunnel endpoints are seen as neighbors of the link,
> so standard link-scoped mechanisms like IPv6 ND and
> [Lucy] ARP and ND are used for MAC address resolution for a given IP. When tunnel is implemented over an IP network and is
> identified by IP address, to make them equivalent, will the protocols need to be enhanced to discover tunnel IP address, or which
> protocol does that now?

Address resolution can be based on one or more centralized authorities
for the link. So, there should be one or more well-known addresses for
address resolution servers that can provide network layer to link-layer
address resolution for other nodes on the link. AERO is one example
of this. I think Joe's draft already covers this in Section 4.

Thanks - Fred

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Aug 2015 21:07:18 +0000

Hi Joe,

The Internet Architecture was designed based on OSI stacks where there are requirements for each layer. L2 provides the link function for L3; L3 provides a link function to L4. However L4 is not a network protocol but L3 is. Therefore the link provided by L3 is not the same as the link implemented by L2. Tunneling a L3 over a L3 has some difference than a L3 over L2. Furthermore, new tunnel encapsulation adds additional features to accomplish other purpose such as NVO3.

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. 

Regards,
Lucy 

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Friday, August 21, 2015 3:24 PM
To: Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-01.txt

Hi, Lucy,

> [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.

> [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.

> 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.

> the virtual network traffic.

I would still not consider that one single tunnel, regardless of NVO3 terminology.

> 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.

They're nearly identical in that regard; there are some other differences when it comes to broadcast, but that's about all AFAICT.

>> 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.   
> 

> 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.

...
...

> applications over the Internet. These principles are critical for what 
> and How to evolve the Internet architecture to facilitate tunnel 

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.

...
> [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.

> 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

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Aug 2015 21:11:52 +0000

Please inline below.

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

Hi Lucy,

> > I'm assuming everything needs to be configured - there's no way to 
> > run a tunnel without configuring both ingress and egress.
> >
> > 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.
> 
> I agree. The term I see most frequently for this kind of tunnel is 
> "Non-Broadcast, Multiple Access (NBMA)". (Unless the underlying 
> network is multicast-capable, in which case the tunnel is simply 
> "multiple access".) Tunnel endpoints are seen as neighbors of the 
> link, so standard link-scoped mechanisms like IPv6 ND and
> [Lucy] ARP and ND are used for MAC address resolution for a given IP. 
> When tunnel is implemented over an IP network and is identified by IP 
> address, to make them equivalent, will the protocols need to be enhanced to discover tunnel IP address, or which protocol does that now?

Address resolution can be based on one or more centralized authorities for the link. So, there should be one or more well-known addresses for address resolution servers that can provide network layer to link-layer address resolution for other nodes on the link. AERO is one example of this. I think Joe's draft already covers this in Section 4.
[Lucy] Make sense. They use different implementations.

Thanks,
Lucy

Thanks - Fred

> > >> 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.
> > >
> > >> 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.
> > >
> > > server to multiple virtual networks and encapsulates virtual 
> > > network traffic by VXLAN where a VNID is used to segregate virtual 
> > > network traffic.
> >
> > 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.
> >
> > > 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.
> > >
> > 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.
> >
> > ...
> > >> 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).
> > >
> > > 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)
> >

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Aug 2015 14:19:13 -0700

> this reflected in the draft.

Yup - it's on the list to add.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Aug 2015 14:21:27 -0700

On 8/21/2015 1:51 PM, Lucy yong wrote:
> [Lucy] ARP and ND are used for MAC address resolution for a given
> IP. When tunnel is implemented over an IP network and is identified by IP
> address, to make them equivalent, will the protocols need to be enhanced
> to discover tunnel IP address, or which protocol does that now?

IP expects every L2 multiaccess net to provide its own resolution
mechanism (see RFC3819). This is no different - it's necessary to find a
way to determine the appropriate egress address.

In most cases I know, this is accomplished by static routing table
entries. A dynamic system would be useful, and it would look a lot like
RFC1577 (ATM ARP via LAN emulation).

Again, more to add...

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Aug 2015 14:36:20 -0700

Hi, Lucy,

On 8/21/2015 2:07 PM, Lucy yong wrote:
> Hi Joe,
> 
> The Internet Architecture was designed based on OSI stacks where 
> there are requirements for each layer.

OSI was created in 1980; the Internet architecture was being developed
at roughly the same time. It's clear they influenced each other, but not
as clear that the Internet was intended as an example of OSI.

But sure, let's assume that at the time, functions were considered
specific to a layer.

> L2 provides the link function for L3;

For all the layers, really.

> L3 provides a link function to L4.

L3 provides the network function, which is "paths created from links".

But you're pointing to an issue which has been understood much later -
that "what is in each layer" is really somewhat relative, i.e., based on
the layer at which you look.

> However L4 is not a network protocol but L3 is.

L4 is a link to L5 and above.

As to "network protocol", that's typically explained as the composition
of links. L2 sometimes makes a network out of L1 hops (e.g., ethernet
segments become an ethernet network). L3 clearly makes a network out of L2.

L4 examples are harder to find because the Internet uses L3 addresses as
part of L4 endpoint identifiers. It's not at all clear that this is a
deficiency of the functions provided by L4, but just an artifact of the
Internet failing to completely decouple L3 from L4.

> Therefore the link provided by L3 is not
> the same as the link implemented by L2. 

I completely disagree. If both links transit IP packets, they're both
L2's to the transiting packet.

They may be implemented differently, but so too are ethernet and ATM.

> Tunneling a L3 over a L3 has
> some difference than a L3 over L2. 

Can you give an example? There are L2s that fragment and reassemble
(ATM), L2s with multicast and broadcast (ethernet), etc. Can you give an
example of a difference that isn't specific to the particular L3 or L2
operating as the link?

> Furthermore, new tunnel
> encapsulation adds additional features to accomplish other purpose
> such as NVO3.

ATM, SONET, etc. all add features not present in IP. Ethernet doesn't as
much, but that may be the result of the concurrent development of both
protocols.

> 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.

Joe

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Aug 2015 21:52:56 +0000

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.

I.e., IP can't exist without Ethernet (or something equivalent), but ethernet can exist without ethernet.

Put another way:

	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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Aug 2015 22:14:54 +0000

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

> From: Int-area [mailto:[email-masked]] On Behalf Of Lucy yong
> Sent: Friday, August 21, 2015 2:53 PM
> To: Joe Touch
> Cc: [email-masked]
> 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
> > 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.
> >
> >
> > IP is closer to an NBMA L2 (unless there's native broadcast or multicast between ingress and egress network N addresses), but it's
> > 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
> > 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.
> >
> > ...

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Aug 2015 15:29:41 -0700

>                  "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"

> 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

---

From: Lucy yong <[email-masked]>
Date: Mon, 24 Aug 2015 13:58:37 +0000

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:[email-masked]] 
Sent: Friday, August 21, 2015 5:30 PM
To: Templin, Fred L; Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-01.txt

> 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.

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

>> it's an artificial distinction. We are defining a tunnel as different from a link only in their implementation - not their behavior, IMO.
>>>>> discuss/point out how that impacts the tunnel (the link) operation 
>>>>> and behavior and individual virtual networks carried by a tunnel.
>>>>
>>> means
>>>> consider the link implementation. Thus some of my suggestion may 
>>>> not apply to this draft. (sorry)
>>>

---

From: Joe Touch <[email-masked]>
Date: Mon, 24 Aug 2015 11:47:05 -0700

Hi, Lucy,

On 8/24/2015 6:58 AM, Lucy yong wrote:
> 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.

It's certainly worth clarifying.

Network interfaces may or may not be "visible" to a network. Unnumbered
interfaces are tracked by routing protocols and forwarding mechanisms,
but are not directly visible except at the device where they attach.

Additionally, such interfaces can serve as a "bump in the wire" and be
completely invisible even to all devices.

When the interfaces are numbered, then they are definitely visible. They
are also visible insofar as they affect ARP or other L2 glue protocols.

The key issue is that they are "no more visible than any other L2",
however. That can and will be made more clear.

Thanks for the suggestion.

Joe

---

From: Lucy yong <[email-masked]>
Date: Mon, 24 Aug 2015 19:35:32 +0000

Hi Joe,

Please see inline below.

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Monday, August 24, 2015 1:47 PM
To: Lucy yong; Templin, Fred L
Cc: [email-masked]; [email-masked]
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-01.txt

Hi, Lucy,

On 8/24/2015 6:58 AM, Lucy yong wrote:
> 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.

Network interfaces may or may not be "visible" to a network. Unnumbered interfaces are tracked by routing protocols and forwarding mechanisms, but are not directly visible except at the device where they attach.
[Lucy] My point is the visibility of a device that a tunnel ingress or egress is implemented. Not the tunnel ingress/egress itself.

Additionally, such interfaces can serve as a "bump in the wire" and be completely invisible even to all devices.

When the interfaces are numbered, then they are definitely visible. They are also visible insofar as they affect ARP or other L2 glue protocols.
[Lucy] Agree. I am thinking too much on the IP tunnels that are implemented over the Internet.

The key issue is that they are "no more visible than any other L2", however. That can and will be made more clear.
[Lucy] Although the draft specifies IP tunnels that can be implemented by a protocol, IMO, it would be nice to give a specific look on the IP tunnels that is implemented over the Internet. This is because a large amount of use cases employ it and when M and N network uses the same protocols, there are additional interworking opportunities. May consider describe this case as a special case in Section 5.1, 5.2, 5.3. 

RFC3819 [you are co-authored] provides the guideline about Internet subnetwork design and aims in the subnetwork as connection-oriented. When IP tunnel is implemented over the Internet that is connectionless, do we need to design the tunnel behave as connection-oriented or stay as connectionless, or both cases are valid?  Hope this draft can give more clear guide.

In addition, should tunnel protocol designers/implementers consider host mobility (has visibility or no visibility)? will network supporting multicast be necessary or important for supporting tunnels over it? 

Thanks,
Lucy

Joe