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

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Mon, 29 Sep 2003 18:01:46 +0200

> >     Connection redundancy should also be noted as an important 
 > >     requirement in 3GPP networks. Static tunnels on their 
 > own don't 
 > >     provide a routing recovery solution for all scenarios 
 > where an IPv6 
 > >     route goes down. However, they may provide an adequate 
 > solution 
 > >     depending on the design of the network and in presence 
 > of other 
 > >     router redundancy mechanisms. On the other hand, redundancy can
 > >     be obtained by running IGP/EGP based tunneling mechanisms or by
 > >     running an IPv6 routing protocol over the manually configured
 > >     tunnels described previously.
 > 
 > 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.
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. 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.

 > 
 > 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"?
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. 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?

 > 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...

 > 
 > 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.

 > 
 > <chair hat=on> 
 > When we get to the Last Call, I will plan to (in any case,
 > whatever the outcome) list a few particularly controversial 
 > points to try
 > to get more WG feedback on what it thinks the good approach here.  
 > However, it's (IMHO) better to be minimalistic from the 
 > start and expand 
 > if really necessary, as we should keep things simple (if not 
 > simpler).
 > <chair hat=off>

I appreciate the intention to keep things simple and get WG feedback,
but if we keep on removing details and adding opinions regarding
IPv6 deployment in mobile nets then the document will not be
useful to 3gpp operators and manufacturers any more.

/Karim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Sep 2003 16:31:09 +0300 (EEST)

> 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.

> 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.

> them. 

True. :-)

> Should I understand from this that the routing WGs and

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.

> 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 ;-).

> 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, ...).

> 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

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