Re: [rbridge] rbridge Digest, Vol 57, Issue 9

["Ashwini Reddy (ashreddy)" <[e-mail]>]

Thanks.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Thursday, February 19, 2009 11:44 AM
To: [e-mail]
Subject: rbridge Digest, Vol 57, Issue 9

Send rbridge mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.postel.org/mailman/listinfo/rbridge
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of rbridge digest..."


Today's Topics:

   1. Ambiguity with IS-IS messages on PPP (Radia Perlman)
   2. Re: Ambiguity with IS-IS messages on PPP (James Carlson)
   3. Re: IS-IS for TRILL interoperability issues (Donald Eastlake)
   4. Re: IS-IS for TRILL interoperability issues (James Carlson)
   5. Re: WG last call on draft-trill-rbridge-protocol-10.txt
      (Donald Eastlake)
   6. Re: potential L2 forwarding loop issue in RBridges
      (Donald Eastlake)


----------------------------------------------------------------------

Message: 1
Date: Wed, 18 Feb 2009 16:10:43 -0800
From: Radia Perlman <[e-mail]>
Subject: [rbridge] Ambiguity with IS-IS messages on PPP
To: TRILL/RBridge Working Group <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

(Note: I like descriptive subject lines, so I'm changing the subject 
line for the thread to discuss
James Carlson's latest noticing of a problem in the spec).

He mentioned that currently the way to tell the difference between an 
IS-IS message and an encapsulated
TRILL message is that the outer destination MAC address is 
"All-IS-IS-RBridges" for IS-IS messages, and
"All-RBridges" for encapsulated data, and ESADI. But on PPP, there is no

"outer destination MAC addres". So,
how can we differentiate them?

Here are the possibilities that were floated around:

a) get two protocol types for TRILL for PPP (it's frowned on to "waste" 
these)

b) use the top bit after the PPP header, which would be the version 
field if there were
a TRILL header there, which fortuitously today happens to be 0 for 
TRILL-encapsulated, and 1 for
IS-IS. (kind of kludgy, and uses a bit of the already small version 
number field)

c) insert a "sub-protocol type" field after the PPP header, either a 
byte, or more if
people want the header byte-or word aligned. Currently it would only 
have two
values (IS-IS, or encapsulated)

d) always encapsulate with a TRILL header, and differentiate based on 
the "inner"
MAC destination address

************
I think I prefer suggestion c).

Here's James Carlson's original post:

James Carlson writes:

> >   - Given both this problem and the subtle MTU issues, reconsider
the
> >     "unencapsulated" decision, and put IS-IS frames after a TRILL
> >     header that includes a flag indicating whether the payload is
> >     IS-IS or data.
>   

I know, bad form to follow up my own posting, and I should have
included this in my original message, but I could live with either the
original Inner.MacDA test (needed for both IS-IS and ESADI) to
distinguish these frames or with a discrete flag in the header.  The
latter would chew up a precious bit, but would be far easier to
implement in hardware and embedded systems (much easier than looking
for a giant Ethernet address later in the message at a potentially
*variable* offset due to options).

That latter sort of header would look like this on Ethernet:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               All-IS-IS-RBridges MAC Destination              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     MAC Destination (cont)    |       Source MAC Address      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source MAC Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        TRILL Ethertype        | V |R|C|M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Egress RBridge Nickname     |  Ingress RBridge Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TRILL Options ...
      +-+-+-+-+-+-+-+-+-...
      |   IDRP = 83   |   Length ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

and this on PPP:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   ADDR = FF   |   CTRL = 03   |       TRILL Protocol ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | V |R|C|M|Op-Length| Hop Count |   Egress RBridge Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Ingress RBridge Nickname     |  TRILL Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
      |   IDRP = 83   |   Length ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

Where the big change is the addition of the "C" (command/data) flag:

  If C == 0, then the header specifies TRILL data, and contains an
  Ethernet MAC header with VLAN tag after the TRILL Options (if any).

  If C == 1, then:

	M must be 0
	Op-Length is zero because no options are yet defined
	Hop Count must be 0
	Egress and Ingress RBridge Nicknames are 0 on transmit
	The IS-IS packet (starting with IDRP) begins after the
	(non-existent) options field.

A form like this guarantees that the key information required to
distinguish control from data is always at fixed offsets in the
packet, which is necessary for hardware design, simple embedded
systems, and some kinds of packet filtering mechanisms.

-- James Carlson, Solaris Networking <[e-mail]> Sun 
Microsystems / 35 Network Drive 71.232W Vox [phone] MS 
UBUR02-212 / Burlington MA 01803-2757 42.496N Fax [phone] 
_______________________________________________ rbridge mailing list 
[e-mail] http://mailman.postel.org/mailman/listinfo/rbridge




------------------------------

Message: 2
Date: Thu, 19 Feb 2009 08:18:38 -0500
From: James Carlson <[e-mail]>
Subject: Re: [rbridge] Ambiguity with IS-IS messages on PPP
To: Radia Perlman <[e-mail]>
Cc: TRILL/RBridge Working Group <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

Radia Perlman writes:
> c) insert a "sub-protocol type" field after the PPP header, either a 
> byte, or more if
> people want the header byte-or word aligned. Currently it would only 
> have two
> values (IS-IS, or encapsulated)
[...]
> I think I prefer suggestion c).

I dislike (c) for at least two reasons:

  - This means that TRILL headers have two "formats."  There's one
    format (without this sub-protocol [kludge] field) on media that
    have L2 addresses that we can allocate, and another format (with
    the field) on media that don't.  This is unlike all other L3
    protocols that run on PPP, which all have well-known formats that
    also work on other media.

  - The difference in headers means that the already-subtle MTU
    computation (which is marred by the "unencapsulated" IS-IS running
    in parallel with the highly-encapsulated data) gains another wart.
    I'm already a bit wary that we can get interoperability at all
    (the spec has no real guidance on MTU issues), and this will add
    to the problem.

  - What happens if we simplify the implementation?  Why not have the
    same TRILL header format on both Ethernet and PPP?  To me, the
    sub-protocol idea is just a half-step into using a flag to
    distinguish data from control, so we might as well go all the way.

OK; at least two reasons.  Probably more like three.  ;-}

One more possible solution (peculiar to PPP) would be:

  (e) use the rarely-used 4xxx range of PPP Protocol IDs to carry
      TRILL IS-IS and ESADI.

That's still not so great, as we'd need to distinguish between TRILL
IS-IS and ESADI, and it still doesn't address MTU.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


------------------------------

Message: 3
Date: Thu, 19 Feb 2009 09:30:08 -0500
From: Donald Eastlake <[e-mail]>
Subject: Re: [rbridge] IS-IS for TRILL interoperability issues
To: "TRILL/RBridge Working Group" <[e-mail]>
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1

Hi Jim,

On Wed, Feb 18, 2009 at 10:02 AM, James Carlson
<[e-mail]> wrote:
> In testing our TRILL implementation, I've discovered that there's both
> ambiguity in the current -11 I-D (separate designers here were able to
> interpret the specification in incompatible ways), as well as serious
> issues looming further down the road.
>
> I recommend (1) including explicit diagrams of *all* of the packet
> formats (currently, only the TRILL header is diagrammed), so that
> there can be no confusion about the meaning of the English text, and
> (2) reconsidering the recent "IS-IS unencapsulated" decision.
>
> The first issue (specification ambiguity) revolves around the way
> IS-IS frames are transmitted, and the interpretation of the word "and"
> in this text:
>
>      o  "TRILL" frames are those (1) with a multicast destination
>         address allocated to the TRILL protocol (see Section 7.2) and
>         (2) non-control frames with the TRILL Ethertype. There are

Probably should be re-worded something like:
  "TRILL" frames are those that either (1) have a multicast
destination address allocated to the TRILL protocol (see Section 7.2)
or (2) are non-control frames with the TRILL Ethertype. ...

> Assuming Ethernet, my reading of the current specification results in
> TRILL IS-IS frames that look like this:
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |               All-IS-IS-RBridges MAC Destination              |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     MAC Destination (cont)    |       Source MAC Address      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                      Source MAC Address                       |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Ethernet 802 Length Field   |   DSAP = FE   |   SSAP = FE   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   CTRL = 03   |   IDRP = 83   |   Length ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
>
> That is, I read the "and" in the text to mean that any packet with
> that special multicast destination *OR* with the appropriate Ethertype
> is to be considered a "TRILL frame," and I understood "unencapsulated"
> to mean that the *ONLY* thing distinguishing this from a regular IS-IS
> frame was the destination MAC address (and woe unto those
> implementations that don't filter multicast perfectly).

The above is indeed what was intended.

> The other designer here apparently read that "and" literally, because
> his frames look like this on the wire:
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |               All-IS-IS-RBridges MAC Destination              |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     MAC Destination (cont)    |       Source MAC Address      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                      Source MAC Address                       |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        TRILL Ethertype        |   IDRP = 83   |   Length ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
>
> Both seem plausible, and given the lack of information, it's possible
> that others may read this specification in other ways, perhaps
> including the LLC header with the Ethertype, depending on what those
> readers consider to be the IS-IS frame.  Thus, I strongly encourage
> the authors to include an appropriate diagram (such as the above) to
> make the frame format unambiguous.

Yes, the wording in the definition of a TRILL frame should be improved
and an explicit frame diagram for a TRILL IS-IS frame should also be
included.

> ... [see other messages re PPP problem]

Thanks,
Donald
-- 
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


------------------------------

Message: 4
Date: Thu, 19 Feb 2009 10:15:31 -0500
From: James Carlson <[e-mail]>
Subject: Re: [rbridge] IS-IS for TRILL interoperability issues
To: Donald Eastlake <[e-mail]>
Cc: TRILL/RBridge Working Group <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

Donald Eastlake writes:
> On Wed, Feb 18, 2009 at 10:02 AM, James Carlson
<[e-mail]> wrote:
> >      o  "TRILL" frames are those (1) with a multicast destination
> >         address allocated to the TRILL protocol (see Section 7.2)
and
> >         (2) non-control frames with the TRILL Ethertype. There are
> 
> Probably should be re-worded something like:
>   "TRILL" frames are those that either (1) have a multicast
> destination address allocated to the TRILL protocol (see Section 7.2)
> or (2) are non-control frames with the TRILL Ethertype. ...

Yes, that's clearer, though I still like the idea of pictures better.
There's no arguing with an array of bytes.

> Yes, the wording in the definition of a TRILL frame should be improved
> and an explicit frame diagram for a TRILL IS-IS frame should also be
> included.

That'll help; thanks.

> > ... [see other messages re PPP problem]

For what it's worth, I had them in one message because the two issues
are tangled together.  The text is unclear in part because of this
change ... and the change itself has also made the text dependent on
features of Ethernet that aren't present on other media.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


------------------------------

Message: 5
Date: Thu, 19 Feb 2009 10:58:51 -0500
From: Donald Eastlake <[e-mail]>
Subject: Re: [rbridge] WG last call on
	draft-trill-rbridge-protocol-10.txt
To: Ayan Banerjee <[e-mail]>
Cc: [e-mail], Radia Perlman <[e-mail]>
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1

Hi Ayan,

See below...

On Tue, Jan 13, 2009 at 5:56 PM, Ayan Banerjee <[e-mail]>
wrote:
> Radia and Donald,
>
> ...
>
> Clarification for EASDI:
> If my understanding of the draft is accurate, there are possibly 4K
> vlan-ESADIs and on each node and we are "only" running the CSNP
> functionality (of traditional IS-IS). The "hello" functionality is not
run
> on them. Consider a router that is interested in all "vlans"; such a
router
> will have to support *all* VLAN-ESADIs.

I assume by router you mean RBridge. No RBridge "has to support" any
VLAN-ESADIs. It always works, in the sense that behavior is correct,
for the RBridge to just learn from the data plane. No one implementing
an RBridge is required to implement any ESADI support.

Support/use of ESADI would likely be important in cases where their is
a Layer 2 registration protocol for end stations and you want to
transmit the end station MAC address information securely or the rate
of mobility or arrival/departure of end stations is so high that, in
the absence of ESADI, you would have excessive black-holing due to
out-of-date address cache information that has not yet timed out or
excessive broadcast traffic due to unknown unicast addresses.

I can think of scenarios where an RBridge is appointed forwarder for
4K VLANs. But I have a much harder time thinking of plausible
scenarios where there are 4K VLANs all of which have the special
requirements to make ESADI very important. Can you give me an example?

>                                                            I believe
that this is a significant
> load on the router. I believe that we should have an optional
single-ESADI
> instance as well; this will allow for control-plane learning of
unicast MAC
> addresses in a more scalable fashion. I am fine with having the
optional 4K
> instances also co-exist; but my preference is to have a single
instance for
> unicast MAC distribution.

As I say, I don't see why there would ever be thousands of VLANs for
which the ESADI protocol was being used. But let's assume there are.
So what exactly do you mean by "instance"? It seems to me its mostly a
matter of implementation whether it is more "load" on an RBridge that
for some reason is running ESADI for thousands of VLANs to get
separate LSPs/CSNPs for each VLAN or some kind of merged single set of
LSPs/CSNPs that are received, processed, and possibly re-emitted
hop-by-hop throughout the entire campus.

In order for this "single-ESADI instance" you propose to work,
wouldn't all transit RBridges have to implement it? Doesn't that
impose a big burden, since no RBridge has to implement ESADI right
now. Doesn't it add a big load to almost all RBridges that are
actually interested in running ESADI for zero or maybe one or two
VLANs? Wouldn't they have to actively process all ESADI protocol
mediated updates for all VLANs? ESADI is carefully designed current to
impose zero control plane burden on transit RBridges that don't
implement it and have it enabled. Wouldn't you lose that? Also,
wouldn't the information in the "single instance" LSPs have to be
labeled as to what VLAN it applies to? Doesn't that imply the
specification of a bunch of additional TLVs or optional fields in TLVs
with VLAN fields? And doesn't that break VLAN translation within
RBridges or at least make it much more complex?

> P2P IIHs and LAN IIHs:
> When TRILL-IS-IS sends out hellos it does so based on the link
capability.
> On P2P links (configured or real ones) it sends P2P IIHs and on
multi-access
> links it sends LAN IIHs. I presume that in TRILL we want to default
sending
> out LAN IIHs (is this accurate?). We should have a section on P2P IIHs
and
> just talk about if any functionality/sub-tlvs are not required for
that case
> (for example, do we need to find a common vlan in P2P like in a LAN -
> probably not etc). Note that a P2P IIH and LAN IIH will not be bring
up an
> adjacency.

Yes, I think the default should be LAN Hellos. I'm not sure there are
many differences between P2P and LAN Hello contents. Couldn't you have
a "point-to-point" link between two RBridges that was, in fact, over
carrier Ethernet facilities or something that only provide
connectivity on, say, VLAN 42? But if there are any differences at
all, a brief section on P2P Hellos seems reasonable.

> Parallel links between rbridges:
> We need information in the draft that states that we break ties using
(a)
> extended circuit id on P2P links (makes 3-way handshake mandatory) and
(b)
> in a LAN, use lan circuit id.

I'm confused by what you say. Assume we have RBridges 1 and 2 such
that there is, say, a point to point link between port A on RB1 and
port A on RB2 and also between port B on RB1 and port B on RB2. There
are two points of view depending on whether you are one of these two
RBridges or some other RBridge in the campus:

Assume you are some other RBridge, RB3. Do you even see both the A and
B adjacencies in the link state? I would think not and that this
should be reported as only a single adjacency in the RB1 and RB2 LSPs.
If, for some reason, you do see it as two adjacencies, why would you
care? As long as you know there is connectivity between RB1 and RB2
you can use that in SPF calculations. I suppose you need a way of
determining the cost from the two costs you would see but you could
just use the minimum of the two or something. And if for some really
bizarre reason, even though you are remote from RB1 and RB2 you not
only see the two parallel paths in the link state but you actually
care which path is taken, there is no space in the LSP TLVs to encode
any tie breaking information such as you suggest. So I don't see any
need for a tiebreaker here.

Assume the other case, that you are either RB1 or RB2. I don't see any
difficulty here either. You should accept TRILL traffic on both
connections and we should say that as a clarification. (You wouldn't
want the Reverse Path Forwarding Check or something causing TRILL
frames on one of the parallel connections to be discarded.) And you
can send traffic on either connection. Or can do Equal Cost MultiPath
on both. But if you send over only one of them then, assuming they are
equal cost, it seems like a purely local decision which one and I
don't see why we need to specify a tie breaker.

> Thanks,
> Ayan
>
> P.S. I have not fully cross-checked with version 11 to see all that
has gone
> in, but I will take a look. Also, I will take a closer look on the
> hello-AF/AC issue with mis-configurations and get back to you.
>
> ...
>

Thanks,
Donald

=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


------------------------------

Message: 6
Date: Thu, 19 Feb 2009 14:43:29 -0500
From: Donald Eastlake <[e-mail]>
Subject: Re: [rbridge] potential L2 forwarding loop issue in RBridges
To: Radia Perlman <[e-mail]>
Cc: TRILL/RBridge Working Group <[e-mail]>
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1

Below is a slightly more specific suggestion for "two Hellos"...

On Tue, Feb 17, 2009 at 12:17 AM, Radia Perlman <[e-mail]>
wrote:
> Yup. Nasty problem.
>
> So...it seems to be that there are two purposes to a Hello:
> a) ensuring that you can hear your neighbors
> b) testing to see how big a frame you can really send.
>
> So these are kind of competing purposes.
>
> I'd suggest having RBridges send two types of Hellos:
> a) a minimal-sized Hello that includes the RBridge's ID and priority,
> and the designated VLAN -- perhaps
> some other stuff like what it thinks the MTU size actually is
> b) fully padded Hello with all the other information included.
>
> The second type of Hello only needs to be sent on the designated VLAN,
> and perhaps could
> be sent less frequently than the minimal sized Hello.

More detailed proposal on two Hellos (this would be changes in Section
4.2.3.1 and possibly other sections of the protocol specifciation):

The current Hello contents discussion in 4.2.3.1.2 needs to be
augmented to discuss and distinguish adjacency Hellos and native frame
loop safety Hellos and discuss MTU considerations.

Adjacency Hellos: Only send on the Designated VLAN. Have all the
additional data elements listed in the current section 4.2.3.1.2
including the IS Neighbor TLV. Have the usual IS-IS padding to the
expected MTU tweaked as needed.

Native frame loop safety Hellos: Sent as in the current Draft on the
Designated VLAN and possibly many others. Have the same IS PDU type
and fixed header fields as adjacency Hello but only have the
additional data needed for loop safety. In particular, only items 1,
2, and 4 from the current section 4.2.3.1.2 and do not have an IS
Neighbor TLV and do not have padding.

Does the above seem reasonable as a starting point?

Thanks,
Donald

> ...
>
> Radia
>
>
> James Carlson wrote:
>> ...

-- 
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


------------------------------

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge


End of rbridge Digest, Vol 57, Issue 9
**************************************

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge