[rbridge] Review of draft-ietf-trill-rbridge-arch-05

[Bill Fenner]

In Philadelphia, I volunteered to review draft-ietf-trill-rbridge- 
arch-05.  I apologize that this review is so delayed.

Similar to James, I found that the extensive equivocation about what  
an rbridge might or might not do made it difficult to figure out what  
it actually would do.  Given the lackluster WG response to his review,  
though, I am not encouraged that there is energy to fix this.  In  
fact, Eric's response implied that the WG more or less has consensus  
that the document needs to be vague and wishy-washy.

I have some specific comments for some minor improvements.

- In the middle of page 5, in addition to 4) Establish L2 delivery  
using shortest path, is there a desire to enable ECMP forwarding at L2?

- In 2.2, taken together, the definitions are confusing.  For example,  
an Egress RBridge removes the TRILL encapsulation and forwards the  
unencapsulated frame to the destination, causing it to leave the TRILL  
campus.  However, the TRILL campus is defined as the set of RBridges  
and TRILL links, and the link connecting an RBridge and an end station  
is a TRILL link, so the packet actually isn't leaving the TRILL  
campus?  An extreme example is a hub connecting two RBridges and an  
end station -- since the spec is careful not to say that any link is  
point-to-point unless explicitly configured -- is that inside the  
campus or outside?  Seems like the TRILL-encapsulated frames are  
inside and the other packets are outside.

- As used in 3.2.1, the term "Adjacent RBridge peers" is confusing,  
since in my first reading I took it to mean "Adjacent to the system  
maintaining the forwarding database", making its statements  
ridiculous.  Of course, it means "The set of all 'Adjacent RBridges'  
in the TRILL Campus", but that meaning is not very clear at first read.

- In 3.2.2, the definition of Local RBridge is confusing to me.  Isn't  
it possible to also have a transit RBridge, which is neither the root  
nor an egress, yet still needs to maintain a multi-destination FDB  
entry?

- The next to last paragraph of section 5.2 left me wondering "or  
what?" - either there needs to be another clause or the word "either"  
needs to be removed:
                                 ... it will forward the frame on all
         interfaces for which it is either the designated RBridge.

- The pessimization of broadcast, multicast and flooded frames should  
probably be called out more explicitly.  Specifically, without  
configuration, 5.3.2-1 requires that when forwarding a broadcast [so  
presumably also a multicast or flooded frame] using the trill  
encapsulation, it be also forwarded on the same interface without  
encapsulation, in the case that there's an end station on that link  
that we don't know about.  Specific configuration is required to avoid  
this behavior.  This seems like a fairly significant aspect of the  
protocol that's left implicit - e.g., traffic to unknown destinations  
is double-forwarded on all links.  For example, this [only] doubles  
the effect of a denial-of-service attack sending frames to unknown  
destinations.

- Another behavior that is somewhat implicit is the addition of an  
extra hop in some situations when delivering to a destination on a  
shared medium - of course, true shared mediums are pretty rare these  
days, and this doesn't apply in the all-RBridge case, but when a frame  
arrives at a shared medium on the non-egress RBridge it gets forwarded  
across that medium to the egress RBridge and then decapsulated.


- I found the intro to the problem in 5.5.1 more confusing than  
helpful.  It assumes the operation of a DR protocol that hasn't been  
described (in stating that either RB-a or RB-b will be the DR so only  
one link between the closet and the core will be used).


Here's my summary of RBridge operation, after reading through the  
architecture document.  Whether or not it's accurate might have some  
relevance to the question of whether the architecture document  
describes RBridge operation well.

- There's a routing instance running, carrying egress RBridge addresses.

- Packets are encapsulated inside a TRILL encapsulation inside the  
TRILL campus, which is all the TRILL routers and the encapsulated  
frames between them.  The encapsulation probably contains an egress  
RBridge for the encapsulated frame's source (which, in many cases, is  
the ingress RBridge).  It also probably contains a TTL, or maybe a  
full source route.

- Packets are [by default] flooded inside the TRILL campus in order to  
learn the mapping of destination to egress RBridge, although a  
variation could flood this mapping in the routing protocol.

- Flooding/multicast/broadcast are, by default, pessimized by  
forwarding the frame both encapsulated and unencapsulated.  Explicit  
configuration of links as point-to-point links between RBridges can  
avoid this traffic duplication.

- Unknown destination flooding can be optimized if an intermediate  
RBridge knows the destination.

- Multicast flooding can be optimized if the location of multicast  
group members is advertised in the routing protocol.

- The protocol might or might not do some kind of ARP/ND optimization  
by advertising these mappings in the routing protocol and then  
intercepting and/or snooping these protocols.

   Bill