Subject: [v6tc] goals of tunneling configuration protocol

From: Prakash Jayaraman <[email-masked]>
Date: Mon, 07 Mar 2005 23:09:57 -0600

Comments on the draft
Goals for Tunneling Configuration - draft-palet-v6tc-goals-tunneling-00.txt

 > 1.  Introduction:
 >...
 >   However, this is not the case for the access network, which may
 >  involve different types of layer two technologies.  In all the cases,
 >   in order to facilitate the transition of those access networks, which

This first line talks about "different layer two technologies" - but it 
does not tell why it is significant only for access networks. Core 
networks have different layer two technologies as well.

Line 327:

 >   o  IPv4 multicast is not widely available, so the tunnel
 >      configuration protocol should work in IPv4 network environments
 >      where IPv4 multicast is not provided.

Video-broadcast over IP is being designed (slow deployment due to 
bandwidth constraints in the access network) for DSL/FTTH/FTTP access 
networks already. I presume that IPv4-multicast will see widespread use 
within the next couple of years. We already know of a few customers who 
are using IPv4-multicast already.

It may be ok to restrict the scope of the BOF or the proposed protocol, 
but the assumption about the availability of IPv4-multicast may not stay 
true.

 > 4.2.4  Latency in Set-up Phases

The lifetime of the tunnel needs to be discussed somewhere. Is the 
tunnel-endpoint on the client-side considered an IP interface?   A 
tunnel is a point-to-point link by definition. However, there is a 
widespread tendency to use a bunch of point-to-point links at the edges 
to emulate a multi-access network.

Although the draft states that the tunnel will not be made "perfect" 
(i.e. not all IPv6 services will be available over this tunnel), unless 
it is stated explicitly otherwise in the BOF charter, enhancements are 
likely to happen.

The following are some of the issues that need to be addressed by the 
BOF charter, either as a goal or a non-goal.

- emulating multi-access links, with a single IP subnet, by using a lot 
of tunnels (broadcast and multicast are problems)
- MTU:- the tunnel-endpoint at the ISP side should not have to do any 
sort of packet reassembly. Having reassembly buffers for each of the 
tunnels is not a scalable or cost-effective solution. Packets going from 
the CPE-side going upstream must be fragmented to a lower value (using 
TCP MSS or lower IP-mtu).  Packets going from ISP-side to the CPE may be 
fragmented if necessary. Fragmentation is simple - it does not require 
resources on the edge routers.
- Should routing protocols be able to work over such tunnels?
- tunnel load-balancing, failover, tunnel-switching etc.

- prakash

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Alain Durand <[email-masked]>
Date: Tue, 08 Mar 2005 07:49:16 -0800

Prakash Jayaraman wrote:

> - emulating multi-access links, with a single IP subnet, by using a 
> lot of tunnels (broadcast and multicast are problems)

Could you please clarify what would be the benefits?

    - Alain.

---

From: Prakash Jayaraman <[email-masked]>
Date: Tue, 08 Mar 2005 08:18:57 -0600

> Could you please clarify what would be the benefits?

The text in my earlier was not clear. Tunnels are point-to-point by 
definition. However, with a number of unidirectional tunnels, a logical 
multi-access subnet can be created (something similar to RFC2225 - 
classical IP over ATM). The access network would then emulate a IPv6 
subnet with more than two hosts communicating with each other.

Obviously, there will be a lot of complexity and overhead in creating a 
set of tunnels. My opinion is that the charter should explicitly state 
that the tunnels under consideration would strictly emulate 
point-to-point links and will not attempt to emulate a multi-access 
network using a set of unidirectional tunnels. The downside of this 
choice is that IPv6-multicast has to be handled at the tunnel endpoints 
and there will not be any packet replication within the IPv4 network.

- prakash

---

From: Prakash Jayaraman <[email-masked]>
Date: Tue, 08 Mar 2005 08:26:28 -0600

> definition. However, with a number of unidirectional tunnels, a 
> logical multi-access subnet can be created (something similar to 
> RFC2225 - classical IP over ATM). The access network would then 
> emulate a IPv6 subnet with more than two hosts communicating with each 
> other.
>
> Obviously, there will be a lot of complexity and overhead in creating 
> a set of tunnels. My opinion is that the charter should explicitly 
> state that the tunnels under consideration would strictly emulate 
> choice is that IPv6-multicast has to be handled at the tunnel 
> endpoints and there will not be any packet replication within the IPv4 
> network.
>
> - prakash
>
Please ignore the last statement in my previous response. Multicast 
handling is the same with any configuration of tunnels.

- prakash