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

From: Bill Fenner <[email-masked]>
Date: Sun, 22 Jun 2008 17:34:31 -0400

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

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

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 23 Jun 2008 10:44:01 -0500

Bill,

	Thanks for your review, some responses below.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bill Fenner
> Sent: Sunday, June 22, 2008 5:35 PM
> To: [email-masked]
> Subject: [rbridge] Review of draft-ietf-trill-rbridge-arch-05
> 

> that the document needs to be vague and wishy-washy.

I am willing to work with you and James to figure out what can be
removed to make this document less wishy-washy.  If we have specific
proposals that are acceptable to the WG, I am sure there is enough 
energy to get the changes done.

> using shortest path, is there a desire to enable ECMP forwarding at
L2?

Yes.  Is there a reason to bring this up at this point in the draft?

If so, it can be added.  There are some reason to be cautious about an
ECMP-like forwarding at L2.  For example, while symmetric forwarding is
not strictly a requirement when tunneling end-station frames across 
TRILL links (as long as they start and end at the same places), L2 
applications assume "shared-fate" with respect to their use of physical 
links - and L2 link state determinations are based on this assumption - 
so having frames traversing non-symmetric paths in opposite directions 
increases the probability of a link failure being detected between end
stations.  

There are other issues, as well, almost certainly including ones we do 
not know of at this time.

The thing is, we have precedence that leads me to believe that it is 
not impossible to add ECMP at a later point.

> inside and the other packets are outside.

Terminology was a very sore issue, requiring a lot of effort to get 
agreement on.

The issue that you point out seems to arise out of the definitions of
Ingress and Egress RBridge - which assume the TRILL Campus consists
ONLY of the TRILL links between RBridges (where those links might be
defined as exclusively having TRILL encapsulation).

I will try to get consensus to change these definitions to read as
follows:

   o  Egress RBridge: for any specific frame, the RBridge at which 
      the TRILL header is removed from the frame prior to delivery
      to an end station (possibly via a LAN).  

   o  Ingress RBridge: for any specific frame, the RBridge at which 
      a TRILL header is added to the frame prior to being forwarded
      to one or more other RBridges.  

One could argue that - in the degenerate case where there is, for
example, only one RBridge - it is possible that an implementation
will encapsulate a frame at an ingress port, send it across the
backplane and decapsulate it at an egress port.  In this case, the
second definition breaks down (for that implementation) because
the encapsulated frame is never forwarded to another RBridge.  But 
- at some point - a definition starts to have a little too much 
baggage to be useful, and I would counter that such an RBridge is
not visibly an ingress RBridge from an external perspective...

> in the TRILL Campus", but that meaning is not very clear at 

Agreed.  I propose removing the word "Adjacent" in this case.

> nor an egress, yet still needs to maintain a multi-destination FDB  

Agreed. I propose changing the definition to include transit RBridges.

>          interfaces for which it is either the designated RBridge.

Agreed.  I propose removing the entire paragraph, which now reads:

"In the DRB example, if the destination MAC address of a received 
 frame does not correspond to a learned MAC destination address 
 at an egress interface, it will forward the frame on all 
 interfaces for which it is either the designated RBridge. If a 
 received frame does correspond to a learned MAC destination 
 address at an egress interface, the RBridge will forward the 
 frame via that interface only."

Owing to other changes, this paragraph is now out of place.

> the effect of a denial-of-service attack sending frames to unknown  

Agreed.  This was a complication made very difficult to explicitly 
state as a result of not being allowed to assume that a DRB election 
process would be required.

I already have a number of "Note" statements and this should be
explicitly added, along with a potential structure modification 
to make these notes both clearer and more obvious.

As a general observation, this kind of forwarding requirement 
has had these same effects on L2 deployments for some time - 
particularly since the advent of VLANs.

> across that medium to the egress RBridge and then decapsulated.

Just to be clear, implementations would presumably include the 
"extra" hop in their shortest path calculations and the case
you describe only occurs when the path (that traverses first 
the TRILL link between a penultimate RBridge and the egress 
RBridge, and then the hop back to the end-station is still the 
shortest path.

Interestingly enough, this is (yet another) one of the areas in
which we would have to be careful about using an L2 ECMP-like
forwarding.  If the path that includes the "hop back" has an
equal cost with the one that does not, it is tempting to use
the one that does not.  However, this can very easily break
normal bridging in the shared media LAN between these two
RBridges.

Otherwise, I agree with your comment.  I propose adding another
note as with the above comment.

> one link between the closet and the core will be used).

Agreed.  I propose rewriting the second sentence in the paragraph
that immediately follows the diagram as follows.

"Moreover, the process defined in protocol specification to avoid 
 breaking bridge learning, may result in only using one of the 
 links (B-1<=>RB-a, B-2<=>RB-b).  This is contrary to the usage 
 intended in a similar network using IEEE 802.1Q bridges."

There are two separate issues: one is that - unless RBridges
participate in (M)STP - (M)STP will not block the link between
B-1 and B-2; the other is that - without blocking this link -
RBridges RB-a and RB-b will detect a connection and this will
require use of some mechanism or approach to resolve which is
the one providing ingress/egress for this common link.  

The first issue is the more relevant one - hence that is the 
one the is addressed mostly in the remaining text.  However, 
the second issue needed to be mentioned as well.  It is the
second issue that will impact on the time it would take for
the example network to recover from a loss of the link between
B-1 and B-2, since the two RBridges will now need to detect 
the loss, start operating independently (including re-learning
end-station attachments and re-computing shortest paths) - and
then the bridges can start learning again.