Subject: [rbridge] Minimal ISIS subset?

From: aidan at nicta.com.au (Aidan Williams)
Date: Tue Oct 12 20:57:00 2004

Hi All,

As currently defined, rbridge builds on top of the ISIS
routing protocol.

Would it make sense to define a subset of the ISIS protocol
for use with rbridge?  It would seem that an rbridge behaves
only as a Level 1 router.

- aidan

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Oct 12 22:34:01 2004

> only as a Level 1 router.

As I have been commented previously, but without follow-ups, what's 
the reason to using IS-IS to begin with?

None of the enterprise networks I know of (granted, I don't know 
all too many of them) use IS-IS.  Most use either OSPF or RIPv2, if 
they use a dynamic routing protocol.

What's the benefit of IS-IS?

I see nothing except it's inherent feature to do both v4 and v6 in the 
same protocol without hassles if the topology is congruent.. but in 
enterprises it often isn't, and you need something like 
draft-ietf-isis-wg-multi-topology-07.txt.

-- 
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: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Tue Oct 12 23:03:01 2004

1) Yes. It would be good to say what parts of IS-IS are unnecessary. 
However,
other than level 2 routing (which Aiden noticed),
I'm not sure there's much that's irrelevant to RBridges. What
IS-IS basically is, is the flooding algorithm and the Dijkstra 
calculation. So
whether the destinations are MAC addresses, IPv4 addresses, IPv6
addresses, or whatever, is very minor. Maybe there is some
simplification around the "area addresses". With RBRidges, there
should be a single area address, which would be a constant (and not
need to be configured).So one wouldn't need
the explanation of how to deal with multiple area addresses when two areas
are merged (and especially the hairiness around negotiating how many area
addresses this area should have).
But anyway, we should go through the spec and see what can be removed
when just used for RBridge.

2) As for "why IS-IS"? RIP wouldn't be appropriate. We really need a link
state protocol. As for OSPF, it requires assigning IP addresses to all the
routers, and the format isn't flexible for adding new information, so IS-IS
is just easier to adapt. With IS-IS the RBridges can be genuinely
zero configuration.

Radia

---

From: aidan at nicta.com.au (Aidan Williams)
Date: Tue Oct 12 23:34:05 2004

> What's the benefit of IS-IS?

The major benefit is that ISIS does not need configured
IP addresses for the routing protocol to work.
This helps a lot if you want plug and play rbridges.

The IP addresses in RIP and OSPF get used for more than
one purpose: 1) to put in headers when sending packets,
and 2) to identify the router in the protocol.
The IP address identifying the router in the protocol
must be unique otherwise all hell breaks loose.

Uniquely allocating IP addresses so that RIP and OSPF
can be used requires:
   - manual configuration, or
   - a unique address allocation protocol, or
   - a new, unique address format
     (probably only makes sense for IPv6).

A unique address configuration protocol must avoid a
chicken and egg dependency on the routing protocol.

Dealing with merging distinct rbridge networks looks
messy when a unique addr conf protocol is employed.
The same IP address could be correctly allocated in
both networks when they are apart, creating a conflict
when the networks are merged.

OSPFv3 uses IPv6 link local for communication,
but it still uses a 32bit number (ie IPv4 address) to
identify routers in the protocol.

On the other hand, ISIS uses a System ID to identify
routers in the protocol.  The System ID can be
automatically initialised from a MAC address.
ISIS does not need IP addresses to communicate with
routers on the link.

Hence, ISIS looks to be well suited for the task.

> draft-ietf-isis-wg-multi-topology-07.txt.

Well.. arguably, we don't even need the IP routing features
of ISIS for an L2-only rbridge.

- aidan

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Wed Oct 13 00:22:01 2004

> This helps a lot if you want plug and play rbridges.

But IS-IS requires one to configure a CLNS address per router, or 
that's what it requires from us who use it for routing IP at least.

And those CLNS addresses look pretty scary to the uninitiated.

> ISIS does not need IP addresses to communicate with

i.e., I guess you assume that the IS-IS implementation would do such
configuration on its own?

---

From: aidan at nicta.com.au (Aidan Williams)
Date: Wed Oct 13 01:19:01 2004

> configuration on its own?

Yes.

Being a plug and play router is a difficult problem if
you have to build on IP addresses that are configured.
See draft-williams-ipvlx-ipbridging-01.txt for some
thoughts on where the issues are.

Ethernet STP/bridging shows that plug and play networking
of multiple links can be done -- with the spanning tree
protocol (STP) using pre-configured addressing.

The point of rbridge is to do a better job than STP does
whilst retaining the plug-and-play-ness.

- aidan

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Wed Oct 13 09:02:05 2004

>>And those CLNS addresses look pretty scary to the uninitiated.

Yeah. I think you're talking about
the "Area address", and that stuff is turgid to read, but luckily
irrelevant for RBridge. We'd pick a constant and say "put this pile of bits
into "area address" and nobody would have to understand what an NSAP or
Network Entity Title is, or obtain such a thing.

I've always thought that it would be nice to rewrite the IS-IS spec and take
out the references to CLNS, since it really isn't relevant if you're not 
using it for
CLNS. It might even be nice to do an RBridge-specific writeup of it, which
would wind up looking really simple since we could remove all that CLNS 
stuff
and things that got put in and never used (like negotiating the size of 
IDs within
the area).

Radia

Date: Wed, 13 Oct 2004 09:01:33 -0700
From: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Minimal ISIS subset?
To: "Developing a hybrid router/bridge." <[email-masked]>
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 801

 >>And those CLNS addresses look pretty scary to the uninitiated.

Yeah. I think you're talking about
the "Area address", and that stuff is turgid to read, but luckily
irrelevant for RBridge. We'd pick a constant and say "put this pile of bits
into "area address" and nobody would have to understand what an NSAP or
Network Entity Title is, or obtain such a thing.

I've always thought that it would be nice to rewrite the IS-IS spec and take
out the references to CLNS, since it really isn't relevant if you're not 
using it for
CLNS. It might even be nice to do an RBridge-specific writeup of it, which
would wind up looking really simple since we could remove all that CLNS 
stuff
and things that got put in and never used (like negotiating the size of 
IDs within
the area).

Radia

Date: Wed, 13 Oct 2004 18:18:11 +1000
From: Aidan Williams <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Minimal ISIS subset?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 829

Yes.

- aidan

Date: Wed, 13 Oct 2004 10:21:43 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Minimal ISIS subset?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 950

Date: Wed, 13 Oct 2004 16:33:22 +1000
From: Aidan Williams <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Minimal ISIS subset?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2112

- aidan

Date: Tue, 12 Oct 2004 23:02:45 -0700
From: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Minimal ISIS subset?
To: "Developing a hybrid router/bridge." <[email-masked]>
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2069

Radia

>draft-ietf-isis-wg-multi-topology-07.txt.

Date: Wed, 13 Oct 2004 08:33:10 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Minimal ISIS subset?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1023

From: "Peter Ashwood-Smith" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: RE: [rbridge] Minimal ISIS subset?
Date: Wed, 13 Oct 2004 01:03:39 -0400
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2997

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4B0E2.00D35988
Content-Type: text/plain

I suppose there is value in that for testing purposes since it puts bounds
on what has to be tested, and since most vendors would pick up full IS-IS
implementations it would help identify exactly what parts of the full
implementation to cut out/disable.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 12, 2004 11:56 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Minimal ISIS subset?

Hi All,

Would it make sense to define a subset of the ISIS protocol
for use with rbridge?  It would seem that an rbridge behaves only as a Level
1 router.

- aidan

_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

------_=_NextPart_001_01C4B0E2.00D35988
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [rbridge] Minimal ISIS subset?</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I suppose there is value in that for testing purposes =
since it puts bounds on what has to be tested, and since most vendors =
would pick up full IS-IS implementations it would help identify exactly =
what parts of the full implementation to cut out/disable.</FONT></P>

<P><FONT SIZE=3D2>Peter</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:rbridge-bounces@postel=
.org</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, October 12, 2004 11:56 PM</FONT>
<BR><FONT SIZE=3D2>To: Developing a hybrid router/bridge.</FONT>
<BR><FONT SIZE=3D2>Subject: [rbridge] Minimal ISIS subset?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi All,</FONT>
</P>

<P><FONT SIZE=3D2>As currently defined, rbridge builds on top of the =
ISIS</FONT>
<BR><FONT SIZE=3D2>routing protocol.</FONT>
</P>

<P><FONT SIZE=3D2>Would it make sense to define a subset of the ISIS =
protocol</FONT>
<BR><FONT SIZE=3D2>for use with rbridge?&nbsp; It would seem that an =
rbridge behaves only as a Level 1 router.</FONT>
</P>

<P><FONT SIZE=3D2>- aidan</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>rbridge mailing list</FONT>
<BR><FONT SIZE=3D2>[email-masked] <A =
HREF=3D"http://www.postel.org/mailman/listinfo/rbridge" =
TARGET=3D"_blank">http://www.postel.org/mailman/listinfo/rbridge</A></FO=
NT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4B0E2.00D35988--

Date: Wed, 13 Oct 2004 13:56:11 +1000
From: Aidan Williams <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Minimal ISIS subset?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 241

Hi All,

- aidan

Date: Fri, 8 Oct 2004 14:40:49 -0700 (PDT)
From: Fred Templin <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: 
Subject: [rbridge] Re: IPvLX
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2099

--0-1980266083-1097271649=:1569
Content-Type: text/plain; charset=us-ascii

Hello,
 
On August 23, 2004 I announced to this distribution a -00 document entitled:
 
  "IPvLX: IPv6 Addressing in the IPv4 Internet"
 
Since that time, a -01 revision of the base document has obsoleted the
-00 version, and a new document entitled: "IPvLX Errata" that specifies
patches to be applied against the base document has been submitted
to [email-masked].
 
The documents are currently available at the following URLs (the latter
of the two should soon be appearing in the I-D repository):
 
  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt
  http://www.geocities.com/osprey67/ipvlx/ipvlx_errata-00.txt
 
Sincerely,
 
Fred L. Templin
[email-masked]

--0-1980266083-1097271649=:1569
Content-Type: text/html; charset=us-ascii

<DIV>Hello,</DIV>
<DIV>&nbsp;</DIV>
<DIV>On August 23, 2004 I announced to this distribution a -00 document entitled:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; "IPvLX: IPv6 Addressing in the IPv4 Internet"</DIV>
<DIV>&nbsp;</DIV>
<DIV>Since that time, a -01 revision of the&nbsp;base document has obsoleted the</DIV>
<DIV>-00 version, and a new document entitled: "IPvLX Errata" that specifies</DIV>
<DIV>patches to be applied against the base document has been submitted</DIV>
<DIV>to&nbsp;<A href="mailto:[email-masked]">[email-masked]</A>.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The documents are currently available at the following URLs (the latter</DIV>
<DIV>of the two&nbsp;should soon be appearing in the I-D repository):</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; <A href="http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt">http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt</A></DIV>
<DIV>&nbsp; <A href="http://www.geocities.com/osprey67/ipvlx/ipvlx_errata-00.txt">http://www.geocities.com/osprey67/ipvlx/ipvlx_errata-00.txt</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>Sincerely,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Fred L. Templin</DIV>
<DIV><A href="mailto:[email-masked]">[email-masked]</A></DIV>
--0-1980266083-1097271649=:1569--