[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network
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.
/Karim
> -----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
>