[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network
On Fri, 26 Sep 2003, Karim El-Malki (HF/EAB) wrote:
> Sorry for the late reply, I'm not reading email often this week
> (nor the next). I don't think major changes are needed to 3.2.1.
> We could add the "routing protocol over tunnel" (suggested by Pekka)
> to the last paragraph:
>
> 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.
As it is, I don't want to see any specific "marketing" here for IGP/EGP
based mechanisms. 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.
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.
<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>
> > -----Original Message-----
> > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com]
> > Sent: den 24 september 2003 15:18
> > To: pekkas@netcore.fi; Karim El-Malki (HF/EAB)
> > Cc: v6ops@ops.ietf.org
> > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP
> > operator's network
> >
> >
> > Hi, Karim (and Pekka)!
> >
> > Just asking your final comments and preferences considering
> > these two points raised up by Karim. Karim, can you make
> > text suggestion(s) for 3.2.1, if you feel those are needed!?
> >
> > (I'm currently editing revision -06, and I hope I can
> > publish it on Thursday/Friday this week).
> >
> > Cheers,
> > -Juha-
> >
> >
> > -----Original Message-----
> > From: ext Pekka Savola [mailto:pekkas@netcore.fi]
> > Sent: 22 September, 2003 18:06
> > To: Karim El-Malki (HF/EAB)
> > Cc: Wiljakka Juha (NMP/Tampere); v6ops@ops.ietf.org
> > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP
> > operator's network
> >
> >
> > On Mon, 22 Sep 2003, Karim El-Malki (HF/EAB) wrote:
> > > 1) Why change "IGP/EGP" to "routing protocols"?
> > > It's clear enough with IGP/EGP
> >
> > Note it was "IGP/EGP routing protocols" AFAIR.
> >
> > Routing protocols are all either IGP or EGP. There is no
> > need to spell
> > out the difference.
> >
> > > 2) Proposed rewrite of second parag.
> > > "Routing protocols over IPv6 links"
> > > We've already discussed this thoroughly
> > > and there was no agreement that this
> > > would be an appropriate choice to
> > > solve the redundancy problem.
> >
> > One could also characterize this that there was no agreement
> > that this is
> > needed for redundancy.
> >
> > > This would
> > > mean recommending that an operator runs
> > > an IPv4 routing protocol and in addition
> > > an IPv6 routing protocol inside each tunnel.
> >
> > Which is operationally Just Fine! :-)
> >
> > > > -----Original Message-----
> > > > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com]
> > > > Sent: den 22 september 2003 14:02
> > > > To: pekkas@netcore.fi; v6ops@ops.ietf.org
> > > > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP
> > > > operator's network
> > > >
> > > >
> > > >
> > > > Hi!
> > > >
> > > > I don't personally have big problems with that suggested
> > > > text. If the other people
> > > > on the list do not object the text change, we could move
> > > > forward with this issue.
> > > >
> > > > Cheers,
> > > > -Juha-
> > > >
> > > > -----Original Message-----
> > > > From: ext Pekka Savola [mailto:pekkas@netcore.fi]
> > > > Sent: 18 September, 2003 12:13
> > > > To: v6ops@ops.ietf.org
> > > > Subject: 3gpp-analysis-05: Automatic tunneling inside
> > 3GPP operator's
> > > > network
> > > >
> > > >
> > > > Hi,
> > > >
> > > > This is the previously-opened "Automatic tunneling inside
> > > > 3GPP operator's
> > > > network" case again.
> > > >
> > > > substantial
> > > > -----------
> > > >
> > > > The issues I'm still not very confortable with:
> > > >
> > > > [note: sending the second one first, because the first
> > requires some
> > > > editing yet..]
> > > >
> > > > 2) tunneling inside the 3GPP operator's network, in
> > > > particular, the last two
> > > > paragraphs of section 3.2.1:
> > > >
> > > > Even a dynamic tunneling mechanism or an IGP/EGP
> > routing protocol
> > > > based tunneling mechanism can be considered if
> > other methods are
> > > > not suitable.
> > > >
> > > > 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,
> > IGP/EGP based
> > > > mechanisms can provide redundancy.
> > > >
> > > > ==> at least, remove "IGP/EGP" (it's enough to say a routing
> > > > protocol), and
> > > > rewrite the last paragraph like:
> > > >
> > > > 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, such as routing protocols
> > > > run over IPv6
> > > > links.
> > > >
> > > > .. because "router redundancy mechanisms" is too vague, and
> > > > IGP/EGP based
> > > > mechanisms are routing protocols themselves and already
> > > > included in that
> > > > context.
> > > >
> > > > I'm not sure if these two edits would fix all my
> > concerns with the
> > > > document, but with these two, it would be much better already.
> > > >
> > > > --
> > > > Pekka Savola "You each name yourselves
> > king, yet the
> > > > Netcore Oy kingdom bleeds."
> > > > Systems. Networks. Security. -- George R.R. Martin: A
> > Clash of Kings
> > > >
> > > >
> > > >
> > >
> >
> > --
> > Pekka Savola "You each name yourselves king, yet the
> > Netcore Oy kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
>
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings