Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

From: Erik Nordmark <[email-masked]>
Date: Fri, 07 Nov 2008 08:48:07 -0800

This message begins a working group last call on
draft-ietf-trill-rbridge-protocol-10.txt. Because of the size of the
document, it will run for three weeks until Wednesday, November 26th.

There are three issues in connection with this draft that you may wish 
to note:
   1. A method of doing VLAN mapping was discussed on the working
group mailing list. This protocol draft is compatible with that method
which has been written up in 
draft-perlman-trill-rbridge-vlan-mapping-00. This separate draft could
be considered for adoption as a working group draft and be progressed
separately or it could be considered as material to add to the
protocol draft, perhaps as an appendix.
   2. The protocol draft does incorporate a change in the
encapsulation of TRILL IS-IS frames (they are no longer encapsulated
but are always sent to a different multicast address) and a minor
change in the encapsulation of TRILL ESADI frames (they have a
different new inner multicast address). There was discussion of this
on the mailing list but sufficiently little that it was hard to gauge
working group opinion.
   3. There was discussion on the mailing list of alternatives for
distribution tree root selection and announcement but no changes along
these lines were made in the draft.

At least items 1 and 3 above are expected to be discussed at the
working group meeting in Minneapolis. Should those discussions result in 
any changes to the base draft then we will separately last call those 
changes.

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

---

From: mike shand <[email-masked]>
Date: Wed, 26 Nov 2008 18:18:29 +0000

I have reviewed the draft from the viewpoint of IS-IS, and I have the 
following comments. In view of the dependency on IS-IS protocol encoding 
AND protocol operation changes, I believe it is important that we get 
agreement with the IS-IS WG on those aspects that affect the operation 
of the IS-IS protocol before this draft is set in stone.

The points where I believe some discussion between the working groups is 
required include, but may not be limited to, the items I have enumerated 
below.

1. The problem of IIH space limitations (typically a maximum of < 1500 
octets) and potential number of VLAN tags (4.2.3.1.1) is not discussed. 
Even if some range based compression is used there is the possibility of 
pathological distributions of VLAN ids (e.g. just the odd ones) causing 
problems. There needs to be some guidance on what limitations this may 
impose etc.

2. The number of IIHs required to be sent when large numbers of VLANs 
are in use (4.2.3.1.1) is of some concern. Again there needs to be some 
discussion of what impact this may have in terms of limiting the 
scaleability of the protocol, and whether such limitations are acceptable.

3. The loop avoidance mechanisms described in 4.2.3.3 needs to be 
verified by the IS-IS WG. In addition the last bullet needs some further 
explanation as to what aspect "already provided in IS-IS" is being 
referenced.  IS-IS will normally only elect a single DIS in such 
circumstances, but there is no provision for disabling forwarding as is 
implied here.

4. The VLAN mapping detection (4.2.3.1.3) needs to be verified by IS-IS 
WG. In particular the mechanism of setting the  mapping detected bit in 
the next 5 hellos seems dangerous, since such messages could be lost in 
the looping which would ensue when mapping was configured. This should 
either be latched until reset, or at the very least latched until it is 
detected that it has been actioned by the DRB.

5. It is not clear how the existing VLAN mapping detection will 
interoperate with the proposed VLAN mapping extensions discussed in 
Minneapolis.

6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID 
USUALLY by appending another octet to the 6 octet system ID owned by the 
DRB. This suggests that the possibility of some other way is intended. 
If so this needs to be described.

7. The second para of 4.2.4.1 (ESADI participation) needs some rational 
for the sending of CSNPs by the non-DRB.

8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol is 
not IS-IS NSAP..." What does this mean?

Mike

---

From: "Ayan Banerjee (ayabaner)" <[email-masked]>
Date: Wed, 26 Nov 2008 10:48:40 -0800

All,

Please see attached comments to the last call on
draft-ietf-trill-rbridge-protocol-10.txt.

Thanks,
Ayan
------------------------------------------------------------------------
-----------------------

Item 1: Section 1.3, can we change the order of control
frame/trill-frame/native-frame (editing nits) 

Item 2: Section 2.1 has reference to ESADI as an IS-IS instance. I
believe we said that this is no 
        longer an IS-IS protocol. Can we please update the draft
accordingly. 

Item 3: Section 2.3.1 - Spraying of hellos, scalability concerns, text
is unclear Consider the following topology and the following scenarios.
      
      |            |              |
     RB1--------- RB2 ---------- RB3
      |            |              |
      |p1          |p2            |p3

The Rbi's are connected on the top to a TRILL cloud consisting of only
Rbridges (for ease of discussion). They are connected on the bottom to
CE switches/network via ports p1, p2, and p3. 

Scenario 1: All ports (p1, p2, and p3) are configured to be access ports
(as defined in Appendix A of the draft). 
In this case, Rbi's will spray with hellos on all VLANs configured on
their respective ports. The intent is if a hello is received by other
Rbi's and an "adjacency" can be formed, then we want to block ports to
prevent loops. The intent is such a link should not get in the LSP-DB;
this is inverse of the operation desired with a traditional-isis-hello.
Only one port remains forwarding and the others are blocked; if so I
could not figure out from the draft which one is forwarding (is
system-id etc used as a tie?). Once this is blocked, it remains blocked
till we "loose" the adjacency again. It is possible that the requirement
will be to send in the order of 10,000s hellos/per sec per node. This
solution of spraying poses scalability concerns for the protocol. Also,
the announcement of the vlan list (however compressed) may not fit
within the isis-hello-pdu. 

Scenario 2: All ports (p1, p2, and p3) are configured to be trunk ports
(as defined in Appendix A of the draft). 
Once again, Rbi's spray hello on all VLANs. In this case, forming of
adjacencies is desired, in the sense this links gets in the LSP-DB. Once
a DRB is elected, only the DRB continues spraying with hellos such that
future nodes can discover and join the designated vlan to send hellos.
Nodes other than the DIS after the initial spraying will move to sending
hellos on the designated vlan only. Question: What happens if the DRB
does not capture all the vlans, for example RB1 became DRB, but has
vlans 2,3 on p1 and the others p2 and p3, have vlan 2,3,4. Can a new
RB4, with vlan 4 configured on it enter this Rbridge LAN and create
issues? Can we have some text to clearly show the desired operation. 

Scenario 3: Some ports are configured to be trunk and some others access
(could be due to mis-configuration or error in cabling) Not sure what is
the desired behavior? Are we saying that "adjacency" must not be formed
with hellos that have the access "AC" bit set, however, must be formed
with others. If p1 is the only with AC set, then does it "block" or
"forward" traffic? I believe that the above scenarios needs to be
addressed in the TRILL base spec. 

Item 4: Section 3.7.3 - An RBridge that will not act as an ingress,
egress, or tree root need not have a nickname.
        Do we really want this statement in the base spec ? What if it
does vlan-mapping, etc. Can we just delete
        this statement from the dradt. 

Item 5: Section 4.1 - please replace on Ethernet links with (on
multi-access links). I am hoping that we can be 
        sensitive to running a P2P mode (configured albeit) on Ethernet
links. 

Item 6: Section 4.1.2 - ESADI is a single instance or multiple instances
per vlan as currently defined. I 
        believe that I had raised scalability concerns with ESADI being
multiple instances.  

Item 7: Section 4.1.3 - There is talk about TRILL-IS-IS Hellos and outer
encapsulation. [This is to be 
        removed as per the last call note 2]. 

Item 8: Section 4.2.2 - TRILL-IS-IS frames must be ALL-Rbridges
multicast address (unicast address how?)
        Updates to this section are not in sync with 4.1.3 

Item 9: Section 4.2.3.1 - one rbridge is elected DRB for LAN case, but
in P2P case there should be no 
        such thing. I believe that the confusion could be due to the
fact 
        the base spec talks about TRILL-IS-IS in terms of LAN IIHs,
however, P2P IIHs (with a config option) 
        need to be accounted.  We want text in the base protocol spec
that says that in the event a link 
        is configured to be P2P, such DRB election is not needed (as per
base IS-IS protocol). Also, 
        with P2P mode configuration, there need not be any spraying of
hellos. 

Item 10: Section 4.2.3.5 - New section -- I think that we are better
served with a P2P IIH section in the draft. 

Item 11: Section 4.2.3.1.1 - Are Core IS-IS hellos tagged ? Maybe okay
for LAN, but is this true for P2P 

Item 12: Section 4.2.3.1.1 - Last sentence ?? Not sure I follow this,
can this be re-written please.

Item 13: Section 4.2.3.1.2 - Wording of bullet 5 is unclear. 

Item 14: Section 4.2.3.1.2 - Based on feedback from the IS-IS WG should
we remove this optimization (delete last 3 paras) 

Item 15: section 4.2.3.2 - (note 1) - designated vlan to be used for
trill data frames, does this imply that 
                            vlans are getting tunneled with a different
outer vlan-id. Just want to make this 
                            explicit.

Item 16: Section 4.2.3.3 - (last note - should this must be the
ext-ckt-id for P2P, and in a lan. This implies
                           that we should mandate 3-way handshake for
P2P links.

Item 17: Section 4.2.3.4 - (note 5) - not announcing allows to choose
all (see note 3 in the last call) 

Item 18: Section 4.3 - Distribution tree (see note 3 in last call and
please see draft-ward) 

Item 19: Section 4.3.1 - Talk about parallel links and what needs to
break them 

Item 20: Section 4.3.4 - (note 3 - how - it will hit the group address
and go everywhere) 

Item 21: Section 4.4.1.2 - Second last paragraph - please change the
last sentence. 

Item 22: Section 4.4.2.2 - the forwarding rbridge need not be a AF on
the link (paragraph 2, consider a P2P case).
                           Or make a statement, that on a P2P, rbridges
are automatically AFs.

Item 23: Section 4.5 needs more text on forwarding of various classes of
multicast control plane packets
                     some are forwarded using a special address while
other are flooded.

Item 24: Section 4.6.2 - Last paragraph, first sentence is not clear. 

Item 25: Section 4.6.3 - Not sure if mis-configuration detection being
carried in the LSP is a good idea. 
                         Assuming that it stays there, I do not see any
text on what to do when things are 
                         mis-configured. If this is just a log, I would
suggest that we take this out-of-band
                         and configuration mismatch issues be handled
separately. 

Item 26: Section 4.7.1 - Text is confusing since we are talking about
creating adjacencies, pseudo-node
                         LSPs etc. Please see item 3 above and text
needs to make the scenarios outlined
                         there clearer.

Item 27: Section 4.7.3.3 - Last sentence, do rbridges with access ports,
run STP ? If not, why not? I am 
                           guessing that statement is talking about
trunk ports; if so can we make that 
                           explicit.

Item 28: Section A.2 - Solution 4 to problem 1- what optional feature?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Nordmark
Sent: Friday, November 07, 2008 8:48 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

There are three issues in connection with this draft that you may wish
to note:
   1. A method of doing VLAN mapping was discussed on the working group
mailing list. This protocol draft is compatible with that method which
has been written up in draft-perlman-trill-rbridge-vlan-mapping-00. This
separate draft could be considered for adoption as a working group draft
and be progressed separately or it could be considered as material to
add to the protocol draft, perhaps as an appendix.
   2. The protocol draft does incorporate a change in the encapsulation
of TRILL IS-IS frames (they are no longer encapsulated but are always
sent to a different multicast address) and a minor change in the
encapsulation of TRILL ESADI frames (they have a different new inner
multicast address). There was discussion of this on the mailing list but
sufficiently little that it was hard to gauge working group opinion.
   3. There was discussion on the mailing list of alternatives for
distribution tree root selection and announcement but no changes along
these lines were made in the draft.

At least items 1 and 3 above are expected to be discussed at the working
group meeting in Minneapolis. Should those discussions result in any
changes to the base draft then we will separately last call those
changes.

Erik and Donald

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Nov 2008 11:25:18 -0800

In support of Mike's comments, I would also suggest we look at this in
the context of the recent agreement that draft-ward-l2isis be the home
for all L2 IS-IS extensions. We therefore want to minimize the overlap
between the architecture document and draft-ward-l2isis so as to avoid
even the appearance of diverging specifications.

It may make sense for the architecture document to discuss the required
functionality at a high level, but currently there is considerable text
which specifies the procedural extensions of an L2-IS-IS instance - and
that clearly is the province of draft-ward-l2isis.

So in addition to working out the technical issues on points Mike
describes below, the architecture document needs to be revised in such a
way as to not duplicate or be in conflict with the protocol extensions
draft as it develops.

   Les

> Behalf Of Mike Shand (mshand)
> Sent: Wednesday, November 26, 2008 10:18 AM
> To: Erik Nordmark
> Cc: [email-masked]
> Subject: Re: [rbridge] WG last call on
draft-trill-rbridge-protocol-10.txt

---

From: "Donald Eastlake" <[email-masked]>
Date: Fri, 28 Nov 2008 10:28:14 -0500

Hi Mike,

Thanks for your comments, responses below...

On Wed, Nov 26, 2008 at 1:18 PM, mike shand <[email-masked]> wrote:
>...

That's a reasonable point. The Hello contents are in 4.2.3.1.2. The
only bulky items are 3 (enabled VLANs) and 6 (appointed forwarders).

Item 3 is usually present and relates, so to speak, to the
configuration of the 802.1Q part of the RBridge port and so could be
pretty arbitrary. For that reason, draft-eastlake-trill-isis proposes
that it be bit encoded so it can't take too much more than 512 bytes
(in the worst case it takes three TLVs/sub-TLVs to fit the data).

Item 6 is only in the DRB's Hello but you may want to specify VLANs
for each of several other RBridges if you are load sharing the
forwarding function. This obviously won't fit in the general case and
there should be a comment to that effect. On the other hand, I don't
see this as a big problem.  The DRB appointing some other RBridge as
forwarder for one or more VLANs or blocks of VLANs is just an
optimization. Its probably OK, in my opinion, if the DRB can't do such
appointments with complete generality due to the Hello frame size
limit.

I think some discussion of this should be added as you suggest.

> scaleability of the protocol, and whether such limitations are acceptable.

There was considerable discussion in the TRILL WG on the number of
Hellos to be sent. Some wanted Hellos to always be sent on all VLANs,
considerably more than the default specified in this protocol
specification draft. Some wanted fewer Hellos, possibly just Hellos on
the Designated VLAN. However, fewer Hellos are not safe in general
unless you also use the optional decapsulation check. See Sections 3.2
of
http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-00.txt
(However, note that that draft has not been updated for the latest
changes in the protocol draft; I'm working on a -01).

> circumstances, but there is no provision for disabling forwarding as is

TRILL loop avoidance is unrelated to IS-IS routing loop avoidance.
TRILL loop avoidance is just about minimizing the probability that a
frame which is decapsulated by one RBridge port onto a link will be
picked up and re-encapsulated by another RBridge port connected to
that link (where a link may be a bridged LAN). In fact, the sketch of
a proof that persistent loops do not occur in RBridge campuses, which
appears in Section 4 of
http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-00.txt
(which, as I mention above, is out of date and needs to be updated),
simply assumes that there are no persistent IS-IS routing loops (and
no persistent loops within any bridged LANs). So, while I welcome any
review and intelligent comment, given that TRILL loop avoidance is
unrelated to IS-IS routing loop avoidance, it is not clear to me why
the TRILL loop avoidance mechanisms need to be blessed by the IS-IS
WG.

On your second point concerning the last bullet point in Section
4.2.3.3, I think you are correct to question it. It seems superfluous
and a little confused.
       As I understand it, TRILL IS-IS Hellos injected by the same
RBridge into a link through different ports are distinguished by their
source MAC addresses. In any case, it would be plausible that, under
some circumstances, the DRB would want to appoint as a forwarder some
other of its own port's that are attached to the same link. This might
seem like an odd and useless thing to do if you imagine the link as a
hunk of classic Ethernet cable but, in fact, the ports may be
connected to different areas of an arbitrarily complex bridged LAN.
       In any case, I think this last bullet point item should simply
be deleted.

> detected that it has been actioned by the DRB.

The TRILL VLAN mapping detection is only there for TRILL loop
avoidance. A mapping of VLAN X to Y inside a link is only a problem if
different RBridge ports are appointed forwarder for X and Y on that
link. That's why, by default, RBridges send Hellos on a port in all
VLANs for which they are appointed forwarder for that port. If a
VLAN-X frame is decapsulated onto a link and picked up and
re-encapsulated as a VLAN-Y frame, while you're not there yet, you
have taken a big step towards having a loop. (A second link doing VLAN
Y to X mapping and one broadcast frame and you're sunk...)
       But having it latch until the DRB acknowledges it seems like a
reasonable idea.

> interoperate with the proposed VLAN mapping extensions discussed in

TRILL VLAN mapping detection concerns mapping that is occurring
between RBridges on a path that includes an initial RBridge port below
the EISS interface, a link which may be a bridged LAN, and a final
RBridge port below the EISS interface. On the other hand, the VLAN
mapping extension in
http://tools.ietf.org/id/draft-perlman-trill-rbridge-vlan-mapping-00.txt
that was discussed in Minneapolis provides for VLAN mapping in the
core of the cut-set RBridges between two regions. As far as I can see,
these two kinds of VLAN mapping are orthogonal.

> If so this needs to be described.

Probably Radia should answer this one. However, if the assertion in
that section that "The only constraint is that the 7-octet ID be
unique within the campus, and that the 7th octet be nonzero." is not
correct, then the section needs to be re-written. However, if that
assertion is correct, I see no reason why the method used by any
particular DRB to determine the campus-unique 7-octet ID needs to be
discussed or described. There are a number of obvious ways to do this
which generally leverage off the global uniqueness of MAC addresses.

> for the sending of CSNPs by the non-DRB.

Another item probably for Radia...but as I recall the idea is that
participants, other than the DRB, know they should be getting a CSNP
occasionally. If they don't get one in a long enough time, they send
one on the theory it might help and can't hurt.

> not IS-IS NSAP..." What does this mean?

The wording is poor... You get to 4.4.2.1 on receipt of a frame
addressed to All-IS-IS-RBridges. You want to discard the frame if it
isn't an IS-IS frame. The "frame protocol" is the Ethertype or SNAP
SAP 5-octet protocol or the LSAPs... anyway, I think this is just
trying to say that it must be an IS-IS frame encoded in the usual LLC
way even if there is currently or in the future an IS-IS Ethertype or
the like... i.e., if there is now, or in the future, some other way of
encoding the IS-IS protocol in a frame, RBridges need not support it.

> Mike

Thanks again for the comments,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia Perlman <[email-masked]>
Date: Fri, 28 Nov 2008 14:58:11 -0800

Re Ayan Banerjee's comments on protocol-10:

a) your concern about spraying of hellos. Indeed there was much 
discussion, with viewpoints ranging
from "send Hellos on every VLAN by all RBridges" (which minimizes the 
possibility of two RBridges
not noticing each other because of weird bridge configurations) to "only 
send Hellos on VLAN 1" (simplicity,
least bandwidth). What is in the spec is a compromise which people 
seemed willing to live with. Only
the DRB (once established) sends Hellos on more than one VLAN, and it 
can be configured to
send on a smaller set of VLANs than the set it supports.

Another option which I kind of liked was to have the RBridge attempt to 
become bridge Root. And
become DRB if and only if it succeeds in being tree Root. We might want 
to revisit that. I happened to
be talking to someone (who hasn't been participating in the WG, but 
might be building this) who brought up
that solution as a suggestion instead of spraying with hellos.

b) differently-configured access and trunk ports: I think all the 
scenarios work. It is the DRB that decides
if it is an access port (and therefore prevents any through-traffic by 
either setting the overload bit or not
creating a pseudonode). So it doesn't matter what the other RBs think 
the port is. And if the DRB
thinks it is a trunk port, it will not assign any designated forwarders.
If the DRB thinks it's a "universal port" (both access and transit), and 
some other RBridge believes
it is a trunk port, that other RBridge will not volunteer to be 
designated forwarder. No problem.
If the other RBridge thinks it's an access port, then given that the DRB 
doesn't claim it's an access port,
its decision is overridden, and it does have to forward.

c) no nickname necessary if not ingress, egress, or tree root

We decided this was a good thing in case nicknames became scarce. It 
seems totally harmless. Just RB
doesn't include a TLV for nickname if it doesn't want a nickname.

d) ESADI instances: I couldn't find the place in the spec you point to 
(you said 4.1.2). I don't see a scalability
problem if endnodes for each VLAN are announced in separate 
announcements. I think the notion of
calling it an "IS-IS instance" (my bad terminology) led to lots of 
confusion, ranging from people thinking
that it meant totally separate per-VLAN topologies of the core, to ... 
not sure what else. I think we've
decided not to call it an "instance" anymore, but just to redefine the 
acronym "ESADI" to be "End System
Advertisement Information". One of the reasons to keep the announcements 
in separate packets for
different VLANs is because of VLAN mapping.

The scalability concerns people have raised for this involve sending 
Hellos per VLAN for these ESADI "instances".
But there are no Hellos. There is, however, a CSNP for each VLAN-ESADI.

e) you said:

>>served with a P2P IIH

Just to confirm on the mailing list what I asked at the meeting (since sometimes
"off the top of people's head at a meeting" might be incorrect):

I was worried about sending a P2P IIH and having it misinterpreted. Someone
said that P2P IIHs and multi-access IIHs are different PDU types. Is this correct?
If so, (or if there is some other way of not getting confused by getting one when
you are expecting the other), it seems OK, but we'd have to look through the
P2P IIH and make sure that all the TRILL information we need is there. I suppose
there is no VLAN information needed, pseudonodes, or information about whether it's
a trunk or access port. maybe there really is no TRILL information needed in
a P2P IIH...

f) You said you were confused by this sentence:
>>Note that an RBridge RBn does not defer to the
>>   DRB listed in a Hello, even if that claimed DRB is higher priority,
>>   if the Hello was sent by an RBridge with lower priority than RBn.

I think that's saying that RB1 might hear a Hello from RB2, wherein RB2 announces
that RB2 thinks RB3 is DRB, and that RB1 should not defer to RB2 unless RB3
actually hears Hellos from RB3.
That's kind of interesting -- maybe it should...

I'm sending this in case my email fails, and will try to respond to the rest
of Ayan's comments later.

Radia

---

From: Radia Perlman <[email-masked]>
Date: Fri, 28 Nov 2008 15:26:53 -0800

> Item 13: Section 4.2.3.1.2 - Wording of bullet 5 is unclear.

How about adding a comma after "controls"
> we remove this optimization (delete last 3 paras) 
I think that the optimization is particularly valuable when IS-IS is 
operating in layer 2. And it
doesn't add complexity, so I see no downside to this.
> outer vlan-id. Just want to make this 
Yes. The inner and outer VLAN tags are unrelated on encapsualted frames. 
I thought the
spec was clear about this.
> P2P links

Hmm. I don't understand the above comments, probably because I don't 
know what "note 5"
and "note 3" are referring to.
> Item 20: Section 4.3.4 - (note 3 - how - it will hit the group address
Can you be more specific about your concern? I can't tell, based on 
reading the section, what you're
asking about.

I think the last sentence you are referring to is:

>>(Using a unicast
>>   Outer.MacDA is of no benefit on a point-to-point link but may result
>>   in substantial savings if the link is actually a bridged LAN with
>>   many bridged branches and end stations, to all of which the frame may>>
>>   get flooded if a multicast destination is used.)

Not sure what's wrong with it...

>                            Or make a statement, that on a P2P, rbridges
I think this is just a simple clarification. That if it's a P2P case 
RBridge-endnode, that the
RBridge is automatically an AF...
>                      some are forwarded using a special address while

Hope Donald understands this one...
> Item 24: Section 4.6.2 - Last paragraph, first sentence is not clear. 
It might be nice to quote the offending text, but I think you are 
referring to:

>>   When the appointed forwarder lost counter for RBridge RBn for VLAN-x
>>   is observed to increase via the core TRILL IS-IS link state database
>>   but RBn continues to be an appointed forwarder for VLAN-x on at least
>>   one of its ports, every other RBridge that is an appointed forwarder
>>   for VLAN-x modifies the aging of all the addresses it has learned by
>>   decapsulating native frames in VLAN-x from ingress RBridge RBn as
>>   follows: The time remaining for each entry is adjusted to be no
>>   larger than a per RBridge configuration parameter called (to
>>   correspond to [802.1Q]) "Forward Delay".

Hmm. I don't remember that section, and don't remember the purpose of
counting the number of times appointed forwarder status is lost. Wouldn't
the sequence number on the ESADI (together with the CSNP to assure delivery
of the latest ESADI from each RBridge) make is unnecessary to have a
"appointed forwarder lost counter"?

>                          and configuration mismatch issues be handled
Adding optional information into LSPs to detect misconfiguration, and 
not saying what to do as a result
of this information, was a compromise. One could have RBridges act on 
the information, or
have some sort of management tool that looks through things for 
misconfigurations. Seems like a good
idea and mostly harmless.
> trunk ports; if so can we make that 

The sentence is
 >>"Except for this optional capability,

 >>  RBridges MUST NOT send spanning tree BPDUs."

I don't remember that. Why did we put that in? I might make an independent note about
this...

---

From: Radia Perlman <[email-masked]>
Date: Fri, 28 Nov 2008 15:31:19 -0800

The spec currently says (in section 4.7.3.3 Transmission of BPDUs)

  RBridges MAY support a capability for sending spanning tree BPDUs for
   the purpose of attempting to force a bridged LAN to partition as
   discussed in Section A.3.3.  Except for this optional capability,
   RBridges MUST NOT send spanning tree BPDUs.

I don't remember any discussion on saying that RBridges MUST NOT send 
BPDUs. I remember
at one point requiring it, and saying that an RBridge is DRB if and only 
if it is the Spanning tree Root.
(I still would prefer that, by the way -- makes all the controversial 
per VLAN Hellos
unnecessary).

I remember it being removed from the spec (because of complexity with n 
versions of
spanning tree, and links with no bridges, perhaps, where the spanning 
tree messages would
be unnecessary overhead), but I don't remember any reason to say 
RBridges MUST NOT sent
BPDUs.

Anyone else remember?

Thanks,

Radia

---

From: "Donald Eastlake" <[email-masked]>
Date: Fri, 28 Nov 2008 21:01:29 -0500

Hi Radia,

See below...

> be unnecessary overhead), but I don't remember any reason to say

I suspect it used to say "do not" in the sense that there is no
RBridge reason for an RBridge port to send spanning tree BPDUs except
for the optional bridge LAN partitioning feature described in Section
A.3.3. In some pass to upgrade to IETF implementation key words, it
probably got changed when it didn't necessarily need to be. The only
problem I can see with dropping this is that it might marginally
increase the chance someone would erroneously try to build spanning
trees through an RBridge.

Donald

---

From: Radia Perlman <[email-masked]>
Date: Fri, 28 Nov 2008 21:36:42 -0800

Yeah. I think we should either drop the sentence, or say "MAY generate 
BPDUs,
but MUST NOT forward BPDUs from
one link to another".

Radia

---

From: Dinesh G Dutt <[email-masked]>
Date: Sat, 29 Nov 2008 21:00:15 -0800

I strongly agree with dropping the sentence and adding the "MUST NOT 
forward" piece,

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Date: Sat, 29 Nov 2008 21:00:15 -0800
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: Donald Eastlake <[email-masked]>, [email-masked]
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Status: RO
Content-Length: 2827

I strongly agree with dropping the sentence and adding the "MUST NOT 
forward" piece,

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Date: Fri, 28 Nov 2008 21:36:42 -0800
From: Radia Perlman <[email-masked]>
To: Donald Eastlake <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Status: RO
Content-Length: 2287

Radia

> trees through an RBridge.

Date: Fri, 28 Nov 2008 21:01:29 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] MUST not send spanning tree BPDUs?
Status: RO
Content-Length: 1873

Hi Radia,

See below...

Donald

Date: Fri, 28 Nov 2008 20:21:56 -0500
From: "Donald Eastlake" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Status: RO
Content-Length: 2678

Hi Jim,

See below...

On Wed, Nov 26, 2008 at 5:21 PM, James Carlson <[email-masked]> wrote:
> Donald Eastlake writes:
>> I've reviewed the draft and will be posting a few suggested changes. This is
>> the first.
>> 802.1 bridges have a Maximum Bridge Transit Delay. They are required to
>> discard frames that have been inside the bridge for longer than this time.
>> It is configurable with a recommended value of 1 second and maximum value of
>> 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a
>> sentence or two to indicate that RBridges have this parameter configurable
>> per RBridge and enforce a maximum RBridge transit delay.
>
> Do modern bridges actually _implement_ such a feature, or do they just
> have a knob labeled "Maximum Bridge Transit Delay" that's connected to
> nothing underneath?

It is my impression that low end 802.1D bridges don't implement this
but mid and high end 802.1Q bridges do. Typically, when a frame is
received, a control block is created with the VLAN, priority, time of
receipt, and other control information. When a frame is de-queued for
transmission, the time is checked and frame discarded if it is too
old. This time check doesn't need to be, and probably isn't, extremely
accurate.

> I can imagine flushing Ethernet output queues if link status goes down
> and stays down for more than a second, thus blocking timely output,
> but tracking internal timestamps on individual packets seems like a
> wasted effort to me, and may not even be feasible with modern
> hardware.
>
> I'm inclined to say "no" to this, just on the basis that I cannot see
> how it would serve any real purpose.  It looks like a spec for the
> sake of a spec.

In bridges, I think it is required to back up the assurances of
Spanning Tree Protocol. I think bridges also flush the output queue
and any input queue associated with a port when the port goes down.
Generally, it seems like good hygiene not to keep a frame for a long
time and then release it...

> James Carlson, Solaris Networking              <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

It would certainly be easy enough to make this a SHOULD rather than
being mandatory the way it is in 802.1, not that people seem to pay
that much attention to what is mandatory in 802.1. But perhaps it
really isn't necessary for RBridges... Anyone else have an opinion on
this.

Thanks,
Donald

Date: Fri, 28 Nov 2008 15:31:19 -0800
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] MUST not send spanning tree BPDUs?
Status: RO
Content-Length: 935

Anyone else remember?

Thanks,

Radia

Date: Fri, 28 Nov 2008 15:26:53 -0800
From: Radia Perlman <[email-masked]>
To: "Ayan Banerjee (ayabaner)" <[email-masked]>
Cc: [email-masked], Erik Nordmark <[email-masked]>
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Status: RO
Content-Length: 5095

The sentence is

Date: Fri, 28 Nov 2008 14:58:11 -0800
From: Radia Perlman <[email-masked]>
To: "Ayan Banerjee (ayabaner)" <[email-masked]>
Cc: [email-masked], Erik Nordmark <[email-masked]>
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Status: RO
Content-Length: 13902

Radia

> changes to the base draft then we will separately last call those

Date: Fri, 28 Nov 2008 10:28:14 -0500
From: "Donald Eastlake" <[email-masked]>
To: "mike shand" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Status: RO
Content-Length: 8387

Hi Mike,

Date: Wed, 26 Nov 2008 17:21:43 -0500
From: James Carlson <[email-masked]>
To: Donald Eastlake <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Status: RO
Content-Length: 1382

Donald Eastlake writes:
> I've reviewed the draft and will be posting a few suggested changes. This is
> the first.
> 802.1 bridges have a Maximum Bridge Transit Delay. They are required to
> discard frames that have been inside the bridge for longer than this time.
> It is configurable with a recommended value of 1 second and maximum value of
> 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a
> sentence or two to indicate that RBridges have this parameter configurable
> per RBridge and enforce a maximum RBridge transit delay.

Do modern bridges actually _implement_ such a feature, or do they just
have a knob labeled "Maximum Bridge Transit Delay" that's connected to
nothing underneath?

I can imagine flushing Ethernet output queues if link status goes down
and stays down for more than a second, thus blocking timely output,
but tracking internal timestamps on individual packets seems like a
wasted effort to me, and may not even be feasible with modern
hardware.

I'm inclined to say "no" to this, just on the basis that I cannot see
how it would serve any real purpose.  It looks like a spec for the
sake of a spec.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Date: Wed, 26 Nov 2008 17:26:33 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] draft protocol-10 WGLC Security Considerations BPDU/Hello DoS addition
Status: RO
Content-Length: 5649

------=_Part_21997_30575635.1227738393709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is the last of my three comments on the draft.
I propose to add a section to the Security Considerations of the protocol-10
draft as pasted at the end of this message. Comments welcome.

Thanks,Donald

The TRILL protocol requires that an appointed forwarder on an RBridge port
be temporarily inhibited if it sees a Hello from another RBridge claiming to
be the appointed forwarder or sees a root bridge change out that port. Thus
it would seem that forged BPDUs showing repeated root bridge changes and
forged Hellos with the Appointed Forwarder flag set could represent a
significant denial of service attack. However, the situation is not as bad
as it seems.

The best defense against forged Hellos or other IS-IS messages is the use of
IS-IS security [RFC5304]. Rogue end-stations would not normally have access
to the required IS-IS keying material needed to forge authenticatible
messages.

Authentication similar to IS-IS security is usually unavailable for BPDUs.
However, it is also the case that in typical modern wired LANs, all the
links are point-to-point. If you have an all RBridged campus, then the worst
that an end-station can do by forging BPDUs is to deny itself service. This
could be either through falsely inhibiting the forwarding of native frames
by the RBridge to which it is connected or by falsely activating the
optional decapsulation check (see Section 4.2.3.3).

However, when an RBridge campus contains bridged LANs, those bridged LANs
appear to any connected RBridges to be multi-access links. The forging of
BPDUs by an end-station attached to such a bridged LAN could affect service
to other end-stations attached to the bridged LAN. Note that bridges do not
forward BPDUs but process them, although this processing may result in the
issuance of further BPDUs. Thus, for an end-station to forge BPDUs to cause
continuing changes in the root bridge as seen by an RBridge through
intervening bridges would typically require it to cause root bridge
thrashing throughout the bridged LAN which would be disruptive even in the
absence of RBridges.

Some bridges can be configured to ignore BPDUs on particular ports and
RBridges can be configured not to inhibit appointed forwarding on a port;
however, such configuration should be used with caution as it can be unsafe.

------=_Part_21997_30575635.1227738393709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is the last of my three comments on the draft.<div><br></div><div>I propose to add a section to the Security Considerations of the protocol-10 draft as pasted at the end of this message. Comments welcome.<br clear="all">
<br>Thanks,<div>Donald<br>=============================<br> Donald E. Eastlake 3rd &nbsp; +1-508-634-2066 (home)<br>

 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
</div><div><br></div><div><br></div><div><br></div><div>The TRILL protocol requires that an appointed forwarder on an RBridge port be temporarily inhibited if it sees a Hello from another RBridge claiming to be the appointed forwarder or sees a root bridge change out that port. Thus it would seem that forged BPDUs showing repeated root bridge changes and forged Hellos with the Appointed Forwarder flag set could represent a significant denial of service attack. However, the situation is not as bad as it seems.</div>

<div><br></div><div>The best defense against forged Hellos or other IS-IS messages is the use of IS-IS security [RFC5304]. Rogue end-stations would not normally have access to the required IS-IS keying material needed to forge authenticatible messages.</div>

<div><br></div><div>Authentication similar to IS-IS security is usually unavailable for BPDUs. However, it is also the case that in typical modern wired LANs, all the links are point-to-point. If you have an all RBridged campus, then the worst that an end-station can do by forging BPDUs is to deny itself service. This could be either through falsely inhibiting the forwarding of native frames by the RBridge to which it is connected or by falsely activating the optional decapsulation check (see Section <a href="http://4.2.3.3"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 4.2.3.3</a>).</div>

<div><br></div><div>However, when an RBridge campus contains bridged LANs, those bridged LANs appear to any connected RBridges to be multi-access links. The forging of BPDUs by an end-station attached to such a bridged LAN could affect service to other end-stations attached to the bridged LAN. Note that bridges do not forward BPDUs but process them, although this processing may result in the issuance of further&nbsp;BPDUs. Thus, for an end-station to forge BPDUs to cause continuing changes in the root bridge as seen by an RBridge through intervening bridges would typically require it to cause root bridge thrashing throughout the bridged LAN which would be disruptive even in the absence of RBridges.</div>

<div><br></div><div>Some bridges can be configured to ignore BPDUs on particular ports and RBridges can be configured not to inhibit appointed forwarding on a port; however, such configuration should be used with caution as it can be unsafe.</div>

</div>

------=_Part_21997_30575635.1227738393709--

Date: Wed, 26 Nov 2008 17:08:37 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses
Status: RO
Content-Length: 4390

------=_Part_21853_18661479.1227737317617
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,
When TRILL started, it had only one multicast address: All-RBridges. Then it
was decided that encapsulated IS-IS frames would have an Inner.MacDA of
All-IS-IS-RBridges and there were two. Now there are three multicast
address: (1) IS-IS frames are not longer encapsulated
and  All-IS-IS-RBridges is their Outer.MacDA, (2) All-RBridges is the
Outer.MacDA for ESADI and multi-destination data frames, and (3)
All-ESADI-RBridges is the Inner.MacDA for ESADI frames.

I don't think we are going to need any more than these three multicast
addresses for the Base Protocol Specification but multicast addresses are
cheap. 802.1 initially allocated itself a block of 16 addresses for bridging
and link protocols (see, for example, 802.1D-2004 Figure 7-10 or the more
recent 802.1Q-2005 Table 8-1) with the defined behavior being that a bridge
was required to drop any frame sent to one of these addresses if the bridge
did not understand the protocol(s) indicated by that address. This sort of
behavior has to be specified at the beginning. Once you start shipping
devices that are transparent to some addresses, you can't practically later
say they have to drop them if they don't know the protocol(s) associated
with those addresses. (This behavior for bridges has been somewhat modified
for more recent complicated cases like provider bridging.)

So, I propose that, when we apply, we get a block of 16 addresses with the
ones listed in the first paragraph above being the first three addresses in
this block and the remaining 13 being reserved for future use. And that the
protocol specification require RBridges to drop frames with Outer.MacDA
being any of these 13 addresses (unless the RBridge understands some future
use of that address).

Thanks,
Donald

------=_Part_21853_18661479.1227737317617
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,<div><br></div><div>When TRILL started, it had only one multicast address: All-RBridges. Then it was decided that encapsulated IS-IS frames would have an Inner.MacDA of All-IS-IS-RBridges and there were two. Now there are three multicast address: (1) IS-IS frames are not longer encapsulated and&nbsp;&nbsp;All-IS-IS-RBridges is their Outer.MacDA, (2) All-RBridges is the Outer.MacDA for&nbsp;ESADI and&nbsp;multi-destination data frames, and (3) All-ESADI-RBridges is the Inner.MacDA for ESADI frames.</div>

<div>

<br><div>I don&#39;t think we are going to need any more than these three multicast addresses for the Base Protocol Specification but multicast addresses are cheap. 802.1 initially allocated itself a block of 16 addresses for bridging and link protocols (see, for example, 802.1D-2004 Figure 7-10 or the more recent 802.1Q-2005 Table 8-1) with the defined behavior being that a bridge was required to drop any frame sent to one of these addresses if the bridge did not understand the protocol(s) indicated by that address.&nbsp;This sort of behavior has to be specified at the beginning. Once you start shipping devices that are transparent to some addresses, you can&#39;t practically later say they have to drop them if they don&#39;t know the protocol(s) associated with those addresses.&nbsp;(This behavior for bridges has been somewhat modified for more recent complicated cases like provider bridging.)&nbsp;</div>

<div><div><br></div><div>So, I propose that, when we apply, we get a block of 16 addresses with the ones listed in the first paragraph above being the first three addresses in this block and the remaining 13 being reserved for future use. And that the protocol specification require RBridges to drop frames with Outer.MacDA being any of these 13 addresses (unless the RBridge understands some future use of that address).<br>

<br></div><div>Thanks,</div><div>Donald<br>=============================<br> Donald E. Eastlake 3rd &nbsp; +1-508-634-2066 (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>

</div></div>
</div>

------=_Part_21853_18661479.1227737317617--

Date: Wed, 26 Nov 2008 16:30:58 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
Status: RO
Content-Length: 1828

------=_Part_21520_7245256.1227735058906
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I've reviewed the draft and will be posting a few suggested changes. This is
the first.
802.1 bridges have a Maximum Bridge Transit Delay. They are required to
discard frames that have been inside the bridge for longer than this time.
It is configurable with a recommended value of 1 second and maximum value of
4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a
sentence or two to indicate that RBridges have this parameter configurable
per RBridge and enforce a maximum RBridge transit delay.

Thanks,Donald

------=_Part_21520_7245256.1227735058906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I&#39;ve reviewed the draft and will be posting a few suggested changes. This is the first.<div><br></div><div>802.1 bridges have a Maximum Bridge Transit Delay. They are required to discard frames that have been inside the bridge for longer than this time. It is configurable with a recommended value of 1 second and maximum value of 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a sentence or two to indicate that&nbsp;RBridges have this parameter configurable per RBridge and enforce a maximum RBridge transit delay.<br clear="all">
<br>Thanks,<div>Donald<br>=============================<br> Donald E. Eastlake 3rd &nbsp; +1-508-634-2066 (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>

</div></div>

------=_Part_21520_7245256.1227735058906--

Content-class: urn:content-classes:message
Date: Wed, 26 Nov 2008 11:25:18 -0800
From: "Les Ginsberg (ginsberg)" <[email-masked]>
To: "Mike Shand (mshand)" <[email-masked]>, "Erik Nordmark" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Status: RO
Content-Length: 5764

   Les

> > any changes to the base draft then we will separately last call
those

Date: Wed, 26 Nov 2008 14:05:18 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] draft-eastlake-trill-rbridge-options-01.txt
Status: RO
Content-Length: 3005

------=_Part_31247_14338146.1227726318463
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

   - *To*: i-d-announce at ietf.org <[email-masked]>
   - *Subject*: I-D ACTION:draft-eastlake-trill-rbridge-options-01.txt
   - *From*: Internet-Drafts at ietf.org <[email-masked]>
   - *Date*: Mon, 24 Nov 2008 14:45:02 -0800 (PST)
   - *List-archive*: <http://www.ietf.org/pipermail/i-d-announce>
   - *List-id*: Internet Draft Announcements only <i-d-announce.ietf.org>

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

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Rbridges: TRILL Header Options
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-eastlake-trill-rbridge-options-01.txt
	Pages		: 17
	Date		: 2008-11-24
	
The TRILL base protocol specification, draft-ietf-trill-rbridge-
   protocol-10.txt, specifies minimal hooks for options. This draft more
   fully describes the format for options and an initial set of options.

A URL for this Internet-Draft
is:http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-options-01.txt

Internet-Drafts are also available by anonymous FTP
at:ftp://ftp.ietf.org/internet-drafts/

------=_Part_31247_14338146.1227726318463
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<span class="Apple-style-span" style="font-family: Times; font-size: 16px; "><ul><li><em>To</em>:&nbsp;<a href="mailto:[email-masked]">i-d-announce at ietf.org</a></li><li><em>Subject</em>: I-D ACTION:draft-eastlake-trill-rbridge-options-01.txt</li>
<li><em>From</em>:&nbsp;<a href="mailto:[email-masked]">Internet-Drafts at ietf.org</a></li><li><em>Date</em>: Mon, 24 Nov 2008 14:45:02 -0800 (PST)</li><li><em>List-archive</em>: &lt;<a href="http://www.ietf.org/pipermail/i-d-announce">http://www.ietf.org/pipermail/i-d-announce</a>&gt;<br>
</li><li><em>List-id</em>: Internet Draft Announcements only &lt;<a href="http://i-d-announce.ietf.org">i-d-announce.ietf.org</a>&gt;</li></ul><hr><pre>A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Rbridges: TRILL Header Options
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-eastlake-trill-rbridge-options-01.txt
	Pages		: 17
	Date		: 2008-11-24
	
The TRILL base protocol specification, draft-ietf-trill-rbridge-
   protocol-10.txt, specifies minimal hooks for options. This draft more
   fully describes the format for options and an initial set of options.

A URL for this Internet-Draft is:
<a rel="nofollow" href="http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-options-01.txt">http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-options-01.txt</a>

Internet-Drafts are also available by anonymous FTP at:
<a rel="nofollow" href="ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-drafts/</a></pre></span>

------=_Part_31247_14338146.1227726318463--

Content-class: urn:content-classes:message
Date: Wed, 26 Nov 2008 10:48:40 -0800
From: "Ayan Banerjee (ayabaner)" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Status: RO
Content-Length: 9608

All,

Thanks,
Ayan

      
      |            |              |

-----Original Message-----

Erik and Donald

Date: Wed, 26 Nov 2008 18:18:29 +0000
From: mike shand <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Status: RO
Content-Length: 4318

Mike

> any changes to the base draft then we will separately last call those 

Date: Thu, 20 Nov 2008 16:31:11 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Merging of draft-eastlake-trill-rbridge-isis and draft-ward-l2isis
Status: RO
Content-Length: 996

The allocation of IS-IS code-points and the specification of encoding
for information in IS-IS to support Layer-2 routing were discussed in
the TRILL and ISIS working group meetings earlier this week. There
were also presentations in the ISIS working group meeting on TRILL and
on IEEE 802.1aq. (The IEEE 802.1aq project has expanded to include
Layer-2 use of IS-IS.)

The conclusion was that the existing draft-eastlake-trill-rbridge-isis
draft should be merged into draft-ward-l2isis and corrected and, in
addition, the IEEE 802.1aq requirements should also be merged into the
resulting "kitchen sink" document which would be processed as an ISIS
working group document. The plan is that Ayan Banerjee, a current
author of ward-l2isis, and Donald Eastlake would be two of the
co-authors of the resulting document.

People should indicate sometime in the next week if they object to this 
plan.

If there are no objections we will request that ISIS make this a WG 
document.

   Erik and Donald

Date: Mon, 17 Nov 2008 23:01:22 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Minneapolis Presentations
Status: RO
Content-Length: 335

Hi,

All of the presentations given at today's TRILL WG meeting have been
uploaded/updated on the Meeting Materials page at
https://datatracker.ietf.org/meeting/73/materials.html.

Thanks,
Donald

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Date: Mon, 17 Nov 2008 13:38:09 -0800 (PST)
Cc: [email-masked]
Subject: [rbridge] Last Call: draft-ietf-trill-prob (Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement) to Informational RFC
Reply-To: [email-masked]
Status: RO
Content-Length: 856

The IESG has received a request from the Transparent Interconnection of 
Lots of Links WG (trill) to consider the following document:

- 'Transparent Interconnection of Lots of Links (TRILL): Problem and 
   Applicability Statement '
   <draft-ietf-trill-prob-05.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-12-01. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14771&rfc_flag=0

Date: Fri, 07 Nov 2008 08:48:07 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Status: RO
Content-Length: 1510

Erik and Donald

Date: Tue, 4 Nov 2008 12:54:39 -0500
From: "Donald Eastlake" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] draft-eastlake-trill-rbridge-isis-02.txt
Status: RO
Content-Length: 1015

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: RBridges: Use of IS-IS
	Author(s)	: D. Eastlake 3rd, R. Perlman, D. Dutt
	Filename	: draft-eastlake-trill-rbridge-isis-02.txt
	Pages		: 19
	Date		: 2008-11-3
	
RBridges implement the TRILL protocol, which in turn makes use of an
   extended version of the IS-IS (Intermediate System to Intermediate
   System) routing protocol to determine topology and frame forwarding
   and for the distribution and synchronization of data. RBridges
   provide optimal pair-wise forwarding with zero configuration, safe
   forwarding even during periods of temporary loops, and multipathing
   for both unicast and multicast traffic. Rbridges also support VLANs.
   This document specifies some details of IS-IS PDUs used in TRILL.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-isis-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

From: [email-masked]
To: [email-masked]
Date: Mon,  3 Nov 2008 15:30:01 -0800 (PST)
Cc: [email-masked]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-10.txt
Status: RO
Content-Length: 1923

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: Rbridges: Base Protocol Specification
	Author(s)	: R. Perlman
	Filename	: draft-ietf-trill-rbridge-protocol-10.txt
	Pages		: 86
	Date		: 2008-11-3
	
RBridges provide optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and support for multipathing of both unicast and multicast
   traffic. They achieve these goals using IS-IS routing and
   encapsulation of traffic with a header that includes a hop count.

   RBridges are compatible with previous IEEE 802.1 customer bridges as
   well as IPv4 and IPv6 routers and end nodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design supports VLANs and optimization of the distribution of
   multi-destination frames based on VLAN and IP derived multicast
   groups.  It also allows forwarding tables to be sized according to
   the number of RBridges (rather than the number of end nodes), which
   allows internal forwarding tables to be substantially smaller than in
   conventional bridges.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-trill-rbridge-protocol-10.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--