Subject: [rbridge] draft-ietf-trill-rbridge-arch-05.txt review

From: Andrew Lee <[email-masked]>
Date: Thu, 26 Jun 2008 11:11:41 -0400

If I am not mistaken, I am the mysterious 5th and last person from 
Philadelphia to promise to review the architecture document (it looks 
like my last name got misspelled in the minutes), so here is my review. 
  I am relatively new to the group and do not have all the background 
and history this document may have already been through.  To a degree I 
have purposefully ignored discussions on the list as far as this review 
is concerned to give a "fresh" perspective, so I apologize if I am 
rehashing old, settled arguments.

One of the things I noticed is an implied requirement at certain points
in the document that an RBridge not be anything but an RBridge.  I could
be reading too much into the document, but I think there would be
benefit to add a statement that points out that it is not a requirement
of the architecture that an RBridge device cannot also participate in
other Layer 2 architectures such as an STP domain (sorry for the double
negative), similar to the disclaimer given for ISIS in the middle of page 6.

In Section 2.2, Using terms (especially TRILL Campus) before defining
them can be confusing.  While there is elegance in alphabetizing this
section, consideration should be given to the order in which the terms
appear.

There are too many terms that refer to an RBridge Distribution Tree:
distribution tree, RDT, or R-Tree.  Please pick one.
	
Sections 4.1 and 4.4 seem redundant to me.  There is little added in
section 4.4, maybe that could be merged into 4.1 and 4.4 deleted or
strike the second paragraph in 4.1?

In 4.6, 2nd paragraph, "desitnation" should be "destination" (which I am
sure has been pointed out already).

5.2 has the following sentence:

         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.

It seems like there is an "or ..." missing.  It may be easiest to just 
delete the word "either" so that it 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 the designated RBridge.

This seems like it would be consistent with the egress behavior 
described several paragraphs earlier, though maybe a further 
modification would be "for which it is the designated egress RBridge" so 
that the previous exception of distinct ingress/egress DRBs is covered.

In section 5.3.2-1, I am a little concerned about language regarding 
treatment of broadcast frames and point to point links.  The document 
seems to imply that if you have a point to point link between two 
RBridges, and no learning has occurred on that link, it is not necessary 
to forward a broadcast packet across that link to the other RBridge. 
Perhaps I am misreading it, but if the RBridge on the other side of that 
link has egress interfaces, it should receive all broadcast packets 
regardless of the state of learning on the point to point link.  It is 
also possible that I am misunderstanding the use of 'point to point' in 
this context.

Section 5.5 has the statement

         This architecture assumes RBridges block STP.

This may seem like a dumb question, but why is this?  Why wouldn't STP 
packets be encapsulated and flooded through the RBridge Campus to each 
egress interface like it would be "if RBridges were replaced by other 
types of L2 forwarding devices" as stated at the top of 5.5?  This seems 
like it would solve the wiring closet problem quite neatly (which makes 
me think I am overlooking something painfully obvious to everyone else). 
  As mentioned in 5.1.1, either RB-a or RB-b would be the DRB for the 
MAC address originating the STP frame, but wouldn't the other be 
considered an egress interface, and thus a valid destination for the 
(multicast) frame?

I will leave it at this for now.  I plan on re-reading the draft, and 
sending out any further comments that I may come up with, if any.

Thanks for reading this.

~Andrew

Andrew Lee
Network Engineer
Indiana University Global Research NOC
[email-masked] | http://www.globalnoc.iu.edu
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge