[v6tc] goals of tunneling configuration protocol

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
v6tc@ietf.org
https://www1.ietf.org/mailman/listinfo/v6tc