RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 29 Sep 2003, Karim El-Malki (HF/EAB) wrote:
>  > I don't think this is OK.  First of all, this overlaps with 
>  > ISP work.  
>  > From the ISP work, we can say for certainty that manual IPv6 
>  > tunnels and
>  > running an IPv6 routing protocol over them will be considered as good
>  > practice.  After all, tunnel is just a link layer; you run 
>  > IPv6 routing
>  > protocols over your native infrastructure -- there is zero difference
>  > here.  I don't think there have been sufficient reasoning 
>  > presented to say
>  > anything of IGP/EGP based mechanisms running over IPv4 
>  > networks in this
>  > context.
> 
> First, it is available in some products so there is a reason.

"someone implements it so it must be needed" is not a tenet I subscribe
to.. nor do many others who work at the operations community.  More often
than not, vendors are more than happy to provide more-or-less fringe
features, for example, as a means to try to differentiate from the others,
to gain a market share.

> You are proposing that we run multiple routing protocol instances, one
> for IPv4 and one for IPv6 inside the tunnels.  The alternative is
> obviously to integrate this info in one routing protocol. [...]

Right.  Although I would rephrase this:

I am proposing that the systems either:

 1) run multiple routing protocol, one for IPv4 and one for IPv6
(basically, different combinations of OSPFv2|IS-IS and OSPFv3|IS-IS,
excluding RIPv2 and RIPng), or

 2) run a single routing protocol which includes both IPv4 and IPv6 over
the infrastructure supporting both (basically, IS-IS)

As you see, I decidedly avoid talking about "tunnels" in 1).  If it's
IPv6, it's IPv6.. the IPv6 infrastructure need to be handled in a routing
protocol (and you can't handle it in an IPv4 routing protocol, because the
IPv6 infrastructure is more than just tunnels).  And as you see, I'm not
against running a single routing protocol either (IS-IS is the only
option, basically), as long as the infrastructure you run it over supports
both IPv4 and IPv6.

This wording seems to give an entirely different outcome as yours..

> I am no
> routing expert, but what's so strange with this? I'm not against the
> former but I can't see how the latter can be a worse solution.

Some _dual-stack_ backbones have gone into a single protocol (IS-IS) to
handle both IPv4 and IPv6.  That's fine.. but you're using this argument
to advocate an IPv4 routing protocol building and maintaining
IPv6-over-IPv4 tunnel infrastructure, which is really unbearable.

>  > As it is, I don't want to see any specific "marketing" here 
>  > for IGP/EGP 
>  > based mechanisms.
> 
> Did you really intend to say that I am doing "marketing"?

I'm not sure what to intend.  What I see is that a set of mechanisms are 
strongly pushed in a scenario I don't see they fit very well, or are 
useful at all.

> If so I think you are mistaken, I have no interest in any of
> those drafts. Rather it is quite obvious you don't approve of
> them. 

True. :-)

> Should I understand from this that the routing WGs and
> IETF in general does not want any such mechanisms to be used
> or is it your personal opinion?

I cannot speak for routing WGs or IETF in general.

However, a routing WG has asked v6ops for opinion whether they should go
forward with specifying e.g. BGP tunneling; they would not want to do it
unless there was support from v6ops that it's needed and useful.  We, as
v6ops chairs, gave pushback to that idea, deferring to look at the ISP
scenarios/solutions work first.

>  > We'll have to properly analyze it first.  
>  > There have 
>  > been no arguments which require it in this context, so the
>  > work should be 
>  > done with ISP scenarios.  Therefore, I'd really prefer to 
>  > keep the current 
>  > text to the basics, like:
>  > 
>  >     Connection redundancy should also be noted as an important 
>  >     requirement in 3GPP networks. Running an IPv6 routing protocol 
>  >     over static tunnels, as one would run IPv6 routing protocols over
>  >     native infrastructure, provides a well-known routing 
>  > recovery solution.
> 
> Are you really saying that we have more experience in running IPv6
> routing protocols over static tunnels than e.g. BGP-based tunneling?
> It's the first time I hear this...

Yes, I'm saying this, and I can guarantee that it's very accurate.  
Welcome to the operational reality!  Take a deep breath, the air smells so
much cleaner this side of the (vendor, operator) fence ;-).

>  > and reword:
>  > 
>  >     Even a dynamic tunneling mechanism or an IGP/EGP routing protocol
>  >     based tunneling mechanism can be considered if other methods are
>  >     not suitable.
>  > 
>  > to something like:
>  > 
>  >     Even a dynamic tunneling mechanism or a routing protocol
>  >     based tunneling mechanism could be considered if other 
>  > methods are
>  >     not suitable.  Whether this is really needed is to be 
>  > analyzed at ISP 
>  >     scenarios/solutions work.
> 
> ...while running an IPv6 routing protocol inside a tunnel is OK
> anyway independently of the ISP work? Doesn't make sense.

It makes perfect sense if one knows what are the basic elements we use in 
the configured tunnels and a basic routing protocol on top of it:
 1) TRANS-MECH(v2): configured tunnels (whether IP or GRE)
 2) IPv6 routing protocol without any frills: IS-IS, OSPFv3, RIPng

Nothing new needed.

BGP-tunneling and similar, on the other hand, are quite far from finished,
generally approved, or used.  They are not basic building blocks.  Those
expand heavily on the existing basic building blocks.  So, it still
remains a question whether they will be needed, and if so, in which
specific scenarios (e.g., in certain MPLS networks only, not for
IPv6-over-IPv4 tunneling, ...).

> I appreciate the intention to keep things simple and get WG feedback,
> but if we keep on removing details 

Well, I guess opinions differ on this; for one person, it may be an
important detail, for the other, irrelevant or even dangerous
recommendation to do something that there seems to be little justification
to do otherwise.

> and adding opinions regarding
> IPv6 deployment in mobile nets then the document will not be
> useful to 3gpp operators and manufacturers any more.

The goal here is to document what 3GPP operators *need*, not what they
*think they need*, or even, *what their vendors think the operators need*.  
There is a vast distinction between these... and especially our AD has
been very keen to stick to the first.  If there are operators or users out
there, let them come forward and talk to us.

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