Subject: [rbridge] Encapsulation of RBridge IS-IS routing messages

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 10 May 2006 18:50:56 -0700

I was rereading the (not yet submitted draft) and realized I'm not sure 
exactly what an IS-IS packet
should look like. I'm sure people will have strong feelings about this, 
so please think about this.

It seems a shame to bother with 2 headers, but perhaps it's the 
simplest. The most straightforward
way I think is:

a) outer Ethernet header: destination="all-RBridges", source=transmitted 
RBridge, Ethertype="encapsulated
RBridge packet" (note...this would be the same as a data packet for an 
unknown destination, or a multicast
data packet transmitted by RBridges)

shim header=19-bit nickname of ingress RBridge, TTL

inner Ethernet header: no useful information other than VLAN tag (to 
separate out the VLAN-specific IS-IS that
reports endnode information from the "core" RBridge IS-IS instance)

The way to tell an IS-IS packet from a data packet is based on the DSAP 
in the inner Ethernet header (and yeah...given that it's IS-IS, it 
wouldn't be an Ethertype...it would be a SAP...the "protocol type" would be
a length, and there would be a DSAP)

**********
So an alternative encoding:

b) we can save lots of room if we don't bother with DSAP encoding or the 
inner header, but we do want the TTL.

Outer Ethernet header has destination=new layer 2 multicast address (not 
the same as the  layer 2 multicast used
by RBridges for other flooded packets, but instead, specific to IS-IS)
Ethertype="encapsulated RBridge packet"
Source=transmitting RBridge

Shim header: it's only 4 bytes, and it has the TTL, so use it...contains 
"ingress RBridge, and TTL"

Following the shim header, instead of a new inner Ethernet header, 
perhaps just have the VLAN tag? Then
directly start the IS-IS packet?

Radia

---

From: riw at cisco.com (Russ White)
Date: Thu, 11 May 2006 18:39:28 -0400

> directly start the IS-IS packet?

This sounds like the better way to do it.

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone

---

From: dino at cisco.com (Dino Farinacci)
Date: Thu, 11 May 2006 17:13:33 -0700

>> r header, but we do want the TTL.

    To do a service to implementors:

    c) the destination MAC address causes the packets to be sent to the
       control-plane processor.

    This way a hardware forwarder doesn't have to do the extra checks you
    propose. Hardware forwards based on destination MAC address, so the
    IS-IS destination multicast MAC address means "pass it up".

Dino

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 11 May 2006 19:18:24 -0700

Dino...I think what you're proposing is a special multicast address for 
use only by IS-IS for RBridges.
We don't need the shim header since we don't need TTL (IS-IS will not 
flood the same pkt twice), or
the "ingress RBridge" (since IS-IS does not send on a tree...each LSP is 
sent to each nbr). We do
need a VLAN tag though.

So, unless anyone objects, the IS-IS pkt will look like this:

Outer header of IS-IS pkt would be:
destination=new multicast address just for IS-IS RBridges
source=transmitting RBridge
Ethertype=I dunno...probably the one assigned for "encapsulated RBridge pkt"

After the outer header, just VLAN tag

After that, the IS-IS pkt.

Radia

******
But we could save space by not bothering with the shim header, an

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 11 May 2006 19:42:49 -0700

Actually, maybe we want a different encapsulation for the main IS-IS 
instance
than the per-VLAN one, since we want the per-VLAN one to be forwarded like
any multicast packet to be delivered to links in that VLAN.

So...the per-VLAN one I think should have the same encapsulation as any 
data packet
to be delivered to VLAN A, i.e.
a) outer hdr=destination="all-RBridges", PT="encapsulated RBridge pkt
b) shim hdr: ingress RBridge, TTL
c) inner hdr: source=original RBridge injecting it, 
destination="all-RBridges", VLAN tag=VLAN A

Then IS-IS pkt.

********
However, the "core IS-IS instance" can be as I proposed in the previuos 
email.

Radia

Radia Perlman wrote:

> Dino...I think what you're proposing is a special multicast address 
> for use only by IS-IS for RBridges.
> the "ingress RBridge" (since IS-IS does not send on a tree...each LSP 
> is sent to each nbr). We do
> need a VLAN tag though.
>
>

---

From: dino at cisco.com (Dino Farinacci)
Date: Thu, 11 May 2006 21:48:00 -0700

>> use only by IS-IS for RBridges.

    Yes, that is correct.

>> flood the same pkt twice), or

    Since the IS-IS messages are link-local in the core RBridges I agree. But
    what about the instance that runs at the edges where the core forwards
    them like they would for any other packet?

>> Ethertype=I dunno...probably the one assigned for "encapsulated RBridge pkt"

    Can we use the same format as IS-IS uses today. The only difference is
    the DA is different? That will reduce the changes to the existing
    implementations.

>> After that, the IS-IS pkt.

    To to be more precise you are proposing IS-IS packets in .1q? Why? Will
    the core switches do an IS-IS instance per VLAN? As I mentioned at the
    last IETF, this is a tradeoff between fault isolation and scalability.

    It would be nice for someone to make a final call on this.

Dino

---

From: dino at cisco.com (Dino Farinacci)
Date: Thu, 11 May 2006 21:48:54 -0700

>> destination="all-RBridges", VLAN tag=VLAN A

    Sorry I repeated what you said but I sent my reply before getting this
    message.

Dino

---

From: riw at cisco.com (Russ White)
Date: Fri, 12 May 2006 08:25:36 -0400

>     them like they would for any other packet?

Wouldn't this be to the original IS-IS MAC address, and thus treated
like any other layer 2 multicast?

>     the DA is different? That will reduce the changes to the existing

This is the route I would prefer, as well.

>     It would be nice for someone to make a final call on this.

I don't see why we would want a process per vlan, unless we're worried
about a process failing (as opposed to a device). IS-IS already does
constrained SPF for various reasons (traffic engineering, fast reroute,
and others...), so I don't see a big deal in doing a single process with
constrained SPF for each vlan.

:-)

Russ

- --

---

From: dino at cisco.com (Dino Farinacci)
Date: Fri, 12 May 2006 08:43:40 -0700

>> like any other layer 2 multicast?

    I was referring to the IS-IS messages used by RBridges and not the IS-IS
    used by routers (for L3) attached to the RBridge network.

>> constrained SPF for each vlan.

    I envision that really is the only way to go if the design expects to
    scale to 4096 VLANs.

Dino

---

From: riw at cisco.com (Russ White)
Date: Fri, 12 May 2006 13:42:24 -0400

>     used by routers (for L3) attached to the RBridge network.

I was thinking that the IS-IS used by routers would be on one l2
address, and the "local" IS-IS process would be on a different one.

>     I envision that really is the only way to go if the design expects to

Agreed....

:-)

Russ

- --

---

From: dino at cisco.com (Dino Farinacci)
Date: Fri, 12 May 2006 10:45:06 -0700

>> address, and the "local" IS-IS process would be on a different one.

    Yep, that is the point I am (not successfully) trying to make.

Dino

---

From: riw at cisco.com (Russ White)
Date: Sun, 14 May 2006 10:19:27 -0400

>     Yep, that is the point I am (not successfully) trying to make.

The cat's out of the bag! Maybe we could get a call for consensus on
this point? Perhaps we need to go back to Radia's original email, and
try to have a list of all the options, and what their pro's and con's are?

:-)

Russ

- --

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sun, 14 May 2006 09:23:38 -0700

We need to make sure that the per-VLAN IS-IS instance carrying endnode 
information is forwardable
just like any other packet to be flooded throughout the VLAN (e.g., 
unknown destination, multicast
destination not derived from IP multicast), but still recognizable by 
the egress RBridges attached to
that VLAN as an IS-IS message. Including the special "default VLAN" that 
has no tag, that would
carry endnode information for links without VLAN tags.

We need the core IS-IS instance that carries RBridge-RBridge 
reachability information to be easily
trappable and processed by every RBridge. (this is not the same as the 
default VLAN endnode instance,
which only has to be processed by RBridges that have attached endnodes 
on links without VLAN tags).

It might be nice not to have lots of extraneous padding where it's not 
necessary. So I'd like the
implementers to say what's most convenient for their implementations.

Radia

Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>  
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.2.2 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFEZzxvER27sUhU9OQRAj3TAJ9VLLCOWL8VJAuYHMdboA8CYb7b2ACgnoYg
>HMR/8UxLCbmKBpSEtKn7V2s=
>=nNjE
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>