RE: 3gpp-analysis document and automatic tunneling

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 15 May 2003 juha.wiljakka@nokia.com wrote:
> I'd like to raise one issue in the 3gpp-analysis document which bothers me 
> a lot.
> 
> I'd like to either understand the reasoning for mentioning all the kinds
> of automatic tunneling mechanism in this draft, or remove the references.
> (the last paragraph of 2.2 quoted below, and some re-editing of the
> paragraphs in 3.2.1).
> 
>   JW: What comes to the tunneling text in 2.2, I am fine with shortening
> it. There actually isn't anything 3GPP-specific, it is more like general
> tunneling description that is already described elsewhere (RFC 2893,
> etc...). As you see, the references to DSTM, ISATAP and TEREDO are
> informational references and thus not vital in this document. They are
> just mentioned as examples of tunneling mechanisms. Would making the
> tunneling text shorter (e.g. one paragraph) and removing the references
> to mechanisms (that are not used in this document) be a good thing to do
> in your opinion?

Yes, 1-2 paragraphs (one about tunneling in general, possibly one about
static/dynamic distinction) without going too far into the specifics would
seem to be a good approach -- enough to give the reader an impression 
about the basic choices he has.

> In particular, I feel this is an issue about IGP/BGP tunneling.  It is
> possible such methods could be used -- if the network is built just so --
> but that's entirely different thing from whether they're a required or
> even a recommended solution ("we have a hammer, now let's go find the
> nails").
> 
>   JW: Well, I don't think we can give unambiguous recommendations. It is
> much better to discuss different solution alternatives. Anyway, we can't
> require any solutions to be used by operators. We had some discussion
> with other authors (especially Karim) how to edit the text. One point
> that was brough up in the discussion was redundancy. Static tunnels on
> their own don't give a solution if a route goes down. Instead, EGP/IGP
> mechanisms support this. Say that I have multiple tunnels to two router
> endpoints connected to the same network. If one goes down I would like
> to start tunnelling to the other. Do you have any comments on this?

If an operator wishes redundancy, he will run routing protocol(s) on top
of his network infrastructure. This would be the case e.g. if the IPv6
network was run on top of static ATM PVC's.

In the case of IPv6-over-IPv4, this is often not (as) necessary (but there
are some other failure modes in some scenarios), if the IPv4
infrastructure is redundant and there is an IPv4 routing protocol to
ensure the reachability.  On the other hand, if you cannot rely on the
IPv4 infrastructure, you have to run the routing protocol anyway.

It seems to me that IGP/EGP mechanisms provide little added value here --
except if you have a very large number of IPv6-enabled routers you wish to
connect in a full-mesh manner, and manual configuration would be a chore.  
Such operators have a lot of other chores too, as managing the other
aspects of the routers is not simple either.

I've having difficulty picturing that particular deployment (a lot of
routers, dense mesh instead of some hierarchy, etc.) to be a requirement.
 
> I fail to see anything 3GPP specific in the description of the network in 
> 3.2.1 and consequently, I'd rather not go down the rathole of describing 
> how an ISP would run its network in the 3GPP scenarios/analysis document.  
> Rather, I'd try to work out generic ISP scenarios in the ISP 
> documents to avoid duplicating the work.
> 
>   JW: I fully agree with you that we should not do work that actually
> belongs to the ISP design team. What kind of text would you suggest in
> our document?

I'll try to work on something to start with within a week.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings