Subject: RE: [Isis-wg] Feedback on IS-IS Automatic Encapsulation

From: "Tony Li" <[email-masked]>
Date: Tue, 22 Jul 2003 16:29:17 -0700

Strictly speaking, that's not necessarily true.  As long as your
IPv6 topology is convex, you should be fine.  Obviously, you want to
migrate to having all routers within an area running the same L3
protocols
for management simplicity.

The real question that we need to discuss is whether the need for
topological flexibility outweighs the complexity.

Tony

|    -----Original Message-----
|    From: Albert Tian [mailto:[email-masked]] 
|    Sent: Tuesday, July 22, 2003 4:21 PM
|    To: Pekka Savola
|    Cc: [email-masked]; [email-masked]; [email-masked]
|    Subject: Re: [Isis-wg] Feedback on IS-IS Automatic Encapsulation
|    
|    
|    Hi, Pekka,
|    
|    Pekka Savola wrote:
|    
|    [snip]
|    
|    > Note that the multiple topology IS-IS specification 
|    would probably satisfy
|    > the requirements of partial IPv4/IPv6 deployment in a 
|    simpler manner, if
|    > really necessary.  As an aside, we run an IPv4/IPv6 
|    backbone, use IS-IS as
|    > our IPv6 routing protocol, and haven't had *any* need for even
|    > multiple-topology IS-IS (and I'm not sure if even that 
|    is needed).
|    
|    Just a quick comment on your side note. 
|    
|    Using the single-topology ipv6 ( as opposed to 
|    multi-topology ipv6 ), you need a
|    flag day to upgrade all your routers and turn it on on all 
|    interfaces. Using
|    multi-topology gives you more control regarding to which 
|    protocol goes where and
|    allows you to roll out ipv6 incrementally. For a sizable 
|    network, these
|    flexibilities will probably generate some demand for MT.
|    
|    Cheers,
|    
|    Albert
|    
|    _______________________________________________
|    Isis-wg mailing list
|    [email-masked]
|    https://www1.ietf.org/mailman/listinfo/isis-wg
|    _______________________________________________
|    Isis-wg-external mailing list
|    [email-masked]
|    http://mailist.procket.com/mailman/listinfo/isis-wg-external
|    

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Albert Tian <[email-masked]>
Date: Tue, 22 Jul 2003 17:28:27 -0700

Hi, Tony,

Tony Li wrote:
> IPv6 topology is convex, you should be fine.  

That I agree.

> Obviously, you want to

Ture. If you've decided to roll out ipv6 on all your nodes, you might as well do
it in one shot. 

But there may also be cases where people want to try on selective sites and see.

> topological flexibility outweighs the complexity.

Also there is the traffic engineering flexibility. MT allows seperate metric and
requires seperate spf for v4 and v6. 

The need will vary from operator to operator. My guess is that there will always
a percentage of the spectrum that will say yes. The question is what percentage.

Thanks,

Albert

---

From: Albert Tian <[email-masked]>
Date: Tue, 22 Jul 2003 23:21:28 -0700

Pekka Savola wrote:
> 
> Hi,
> 
> I changed to subject as we turned to speaking of MT IS-IS.. which is fine
> :-)
> 
> On Tue, 22 Jul 2003, Tony Li wrote:
> > Strictly speaking, that's not necessarily true.  As long as your IPv6
> > topology is convex, you should be fine.  Obviously, you want to migrate
> > to having all routers within an area running the same L3 protocols for
> > management simplicity.
> 
> My point exactly.
> 
> We've avoided the pain here, and some other operational networks I've been
> talking about have upgraded their core by keeping it convex.  Their core
> is still only partially upgraded by the way.

I'm supprised to hear this ... they must be really good at topology :-)

One question here -- consider the nodes and the links that form the boundary of
your convex, how can you gurantee that when any of them fails the backup route
would fall inside your boundary?

Thanks,

Albert

> 
> My belief that this is not really the case.  Ops folks just *don't* roll
> out new features to every box during a night (well some might, and in some
> cases it might be warranted, but it's rather rare).  People deploy it in a
> few places, watch out for a couple of weeks for the first bugs to show up,
> work on finding solutions to those, start expanding etc.
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Jul 2003 10:10:51 +0300 (EEST)

> I'm supprised to hear this ... they must be really good at topology :-)

Yep :-)
 
> One question here -- consider the nodes and the links that form the
> boundary of your convex, how can you gurantee that when any of them
> fails the backup route would fall inside your boundary?

The costs have been assigned so that any failure of one link or node will
still stay convex (AFAIR).  If multiple nodes go kaboom, it may not
necessarily be the case anymore, but that's typically beyond the scope of 
redundancy requirements.

...

I'm sure that in the general case keeping your topology convex for 
extended periods of time and having to also consider backup routes will 
give you headaches -- which is why I think there are basically three 
possibilities/stages to the IPv6 IGP introduction:

 - having separate IGP's for v4 and v6; we use OSPF for v4 and IS-IS for
v6 so we don't have any problems. (Avoids all the problems of the "v6
kick-start phase".)  Could be the other way too, now that OSPFv3 is rather
widely supported.

 - testing IS-IS for v4 and v6 is rather straightforward with a small 
number or nodes (2-3 or the like).  Such topologies may be more easily be 
kept convex.  This decision give enough confidence for "no-go" or "go and 
deploy everywhere" -decision.

 - deploying IS-IS for v4 and v6 everywhere; typically done after the
previous point.  You don't have to worry about backup connectivity, but
keeping the topology convex while expanding your convex area is desirable.  
As all you have to do is to enable IS-IS for v6 (you can deploy IP
addresses, new software, etc. beforehand), this is a very quick operation
and could also be done (in some cases) during a short maintenance window.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Jul 2003 08:50:33 +0300 (EEST)

Hi,

My point exactly.

---

From: [email-masked]
Date: Wed, 23 Jul 2003 09:35:32 +0100

what is a "convex" topology ?

Philip

---

From: Albert Tian <[email-masked]>
Date: Wed, 23 Jul 2003 01:44:07 -0700

> what is a "convex" topology ?

I think this means the path between any two nodes on a topology lies completely
within the topology.

Thanks,

Albert

---

From: Paul Fee <[email-masked]>
Date: Wed, 23 Jul 2003 09:49:39 +0100

Philip,

It sounds like it's one which is totally self enclosed.

So if someone mentions that the dual IPv6/IPv4 portion of their network 
is convex, then that means that IPv6 packets would never be sent outside 
the IPv6/IPv4 part of the network, hence avoiding packet loss in the 
IPv4 only part of the network.

A convex topology will be an island, but an island will not necessarily 
be convex.  For example if the island has "arms" which extend from the 
core and routes are based only on metric and not on protocol type.  Then 
routes may be chosen which go between arms, sending packets from one 
part of the island to another but breaking outside the boundary of the 
island.

A convex topology allows the topology rules of RFC 1195 to be broken in 
a calculated way to avoid packet loss.

-- 
Paul Fee
Aisling Design Services Ltd.
Tel: +44 (0)28 90811003
Mobile: +44 (0)7890 486204
Web: http://www.aislingds.com
E-mail: mailto:[email-masked]

---

From: Andrew Partan <[email-masked]>
Date: Wed, 23 Jul 2003 06:05:59 -0400

On Wed, Jul 23, 2003 at 01:44:07AM -0700, Albert Tian wrote:
> I think this means the path between any two nodes on a topology
> lies completely within the topology.

Which turns out to be difficult in practice.  You need the
multi-topology stuff.  Then all you need is a conneted path & things
work.  If you have to have working software on supported hardware
even on just a convex topology before things work, you may never
get there.
	--asp