Subject: [rbridge] RBridges and IS-IS packets, revisited

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 21 Jun 2006 21:47:30 -0700

I think we never decided on this. Encoding is not a very interesting 
thing, but
we should decide. I have a few questions.

a) Any reason to optimize sending of layer 3 IS-IS packets? RBridges can 
know which links
contain IS-IS routers because IS-IS routers send IS Hellos. If RBridges 
told each other
"I am attached to an IS-IS router", then IS-IS Link state packets and 
hellos (This is
layer 3 I'm talking about) only need to get sent to links that contain 
IS-IS routers.

I'm assuming we don't care about optimizing this, though perhaps we 
should on the last
hop (don't decapsulate layer 3 IS-IS traffic onto links for which you 
are Designated
RBridge and know there are no IS-IS routers there)

b) Do IS-IS Routers actually use VLANs? Do people partition their 
bridged topology into
VLANs and run different instances of layer 3 IS-IS (or OSPF) for each 
VLAN? Not sure
why people would do this, but oh well. I think it isn't hard to avoid 
breaking this
functionality, so it should probably be designed to allow it. But I'm 
just curious
if anyone would use it, and perhaps even get a clue as to why.

c) I assume layer 2 multicast addresses are basically free, and if I 
understood Dino's
email from a few weeks ago, he'd prefer using a different MAC multicast 
address for
RBridge IS-IS packets than ordinary encapsulated data packets, so that 
RBridges will
know they should process the packets.

d) I'll send a proposal for the encoding of the 3 types of IS-IS packets 
(encapsulated layer
3 IS-IS packets, core instance RBridge IS-IS, per-VLAN RBridge IS-IS) in
a subsequent email

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 21 Jun 2006 23:23:33 -0700

1) layer 3 IS-IS LSPs

It would be fine to treat these like any other layer 2 multicasts.
The only reason to do anything different would be if we want to
optimize distribution of these to go only to links on which there
are IS-IS routers. RBridges could recognize such packets because the
inner header would indicate the IS-IS DSAP. So I'm assuming these
will be encapsulated just like any layer 2 multicast.

2) core IS-IS instance for RBridges (these are the IS-IS packets by
which RBridges inform each other about RBridge-to-RBridge connectivity.

Outer header:
  Destination=new (to be assigned) layer 2 multicast address,
   indicating "core RBridge IS-IS packet"
  Source=transmitting RBridge
  protocol type=encapsulated RBridge packet

Shim header: TTL and ingress RBridge (in PWE format as defined in the 
unfortunately
expired internet draft by Bryant, et al)

No inner layer 2 header: IS-IS packet immediately follows

3) per-VLAN IS-IS instance for RBridges (these are the IS-IS packets by
which RBridges in a particular VLAN inform other RBridges attached to
the same VLAN of where the endnodes, multicast receivers, and multicast
routers associated with that VLAN are)

Outer header:
  Destination=second new (to be assigned) layer 2 multicast address,
   indicating "per-VLAN RBridge IS-IS packet"
  Source=transmitting RBridge
  protocol type=encapsulated RBridge packet

Shim header: TTL and ingress RBridge

No inner layer 2 header:, just VLAN tag,
followed by IS-IS packet

---

From: riw at cisco.com (Russ White)
Date: Thu, 22 Jun 2006 09:35:00 -0400

> a) Any reason to optimize sending of layer 3 IS-IS packets? RBridges
> can know which links contain IS-IS routers because IS-IS routers send
> IS Hellos. If RBridges told each other "I am attached to an IS-IS
> router", then IS-IS Link state packets and hellos (This is layer 3
> I'm talking about) only need to get sent to links that contain IS-IS
> routers.

I wouldn't try do this.... The first question that springs to mind is,
if you're going to optimize for IS-IS, why not for all the other routing
protocols that use link local multicast, as well, such as OSPF, EIGRP,
and RIPv2? The problem I see is that it would interfere with the three
way handshake used in many RP's, and possibly with OSPF DR election. I
would just leave it....

> bridged topology into VLANs and run different instances of layer 3
> IS-IS (or OSPF) for each VLAN? Not sure why people would do this, but
> oh well. I think it isn't hard to avoid breaking this functionality,
> so it should probably be designed to allow it. But I'm just curious 

Yes, they do.... For normal L3 IS-IS packets, though, we should just
encap in the correct vlan shim header, and send it out, just like any
other broadcast (link local multicast) packet.

>  understood Dino's email from a few weeks ago, he'd prefer using a
> different MAC multicast address for RBridge IS-IS packets than
> ordinary encapsulated data packets, so that RBridges will know they
> should process the packets.

This is what I'd prefer, as well.

:-)

Russ

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 22 Jun 2006 08:17:33 -0700

Radia Perlman wrote:
> a) Any reason to optimize sending of layer 3 IS-IS packets?

There might be, but that's just an optimization, like other L3
optimizations (e.g., IP multicast).

...
> know they should process the packets.

I was assuming we would get a separate L2 address for rbridge control
info, and that they'd be multicast as with other L2 control. Are you
asking whether we need multiple such addresses, or just one?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20060622/6c12c2fc/signature.bin

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 29 Jun 2006 10:35:12 -0700

The Trill protocol document refers to an expired internet draft (bryant, 
et al)
on using the pwe encoding for the shim header,
and the coauthors on that document think the content should be moved 
into the protocol document, rather than
keeping the seperate document alive and unexpired.

Rereading the expired document, I realized that that specifies a 
different way of differentiating
unicast from multicast than the base Trill protocol document does.

In the current base document, it says to differentiate based on whether the
MAC address in the outer header is a layer 2 multicast or unicast MAC
address. But in the expired pwe draft, it says to do it based
on the 20th bit in the label field in the shim header (the other 19 bits 
in the label field used for the nickname).

I think I like the 20th bit method better (the one in the expired
pwe draft), because in theory the campus might include links other than
Ethernet links, and the outer header is a link-specific header that gets 
removed and replaced hop by hop,
and there might even be a link that does not have the concept of 
multicast addresses (for example,
if I'd been designing
Ethernet addresses for the original Ethernet, I wouldn't have set aside 
a bit in the address...I'd have just said
"an address is an address, and it's just up to receivers what to listen 
to--if more than one is listening
it becomes a multicast").

So unless anyone objects, now that we've agreed to the 4-byte pwe-style 
shim header, I'll change
the method of differentiating multicast from unicast to be based on the 
20th bit in the label field.

And also, could someone review the IS-IS encoding? (attached below)

Radia

Radia Perlman wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>