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

[Eric Gray]

Bill,

	Thanks for your review, some responses below.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Bill Fenner
> Sent: Sunday, June 22, 2008 5:35 PM
> To: rbridge at postel.org
> Subject: [rbridge] Review of draft-ietf-trill-rbridge-arch-05
> 
> 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 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.

> 
> 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?

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.

> 
> - 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.

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...

> 
> - 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.

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

> 
> - 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?

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

> 
> - 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.

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 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.

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.

> 
> - 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.

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.

> 
> 
> - 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).

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.

> 
> 
> 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
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>