RE: 3gpp-analysis document and automatic tunneling

["Bound, Jim" <Jim.Bound@hp.com>]

Juha,

We need this for deployment as you have it.  I don't agree with Pekka.
But lets just build a deployment paper out of here.  There are going to
many of them rolling out soon.

/jim

> -----Original Message-----
> From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] 
> Sent: Thursday, May 15, 2003 8:43 AM
> To: pekkas@netcore.fi; Jonne.Soininen@nokia.com; 
> Karim.El-Malki@era.ericsson.se
> Cc: v6ops@ops.ietf.org
> Subject: RE: 3gpp-analysis document and automatic tunneling
> 
> 
> 
>  Hi, Pekka!
> 
> Trying to briefly answer your questions considering the issue.
> 
> -----Original Message-----
> From: ext Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: 14 May, 2003 14:33
> 
> 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?
> 
> 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?
> 
> 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? 
> 
> Therefore, I'd like to either understand why this is in scope 
> and what's 
> 3GPP specific about it, or try to reword the text 
> appropriately (I can 
> try to help if needed).
> 
>   JW: Certainly, your help is appreciated!
> 
>  Thanks for your comments,
> 
> 		-Juha W.-
> 
>