Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt

[Sam Aldrin <[e-mail]>]

Authors,

Please find my detailed comments (with %sam) regarding this draft.

cheers
-sam

1.  “This draft describes why and how Data Center TRILL networks can be
   optimized by utilizing a directory assisted approach.”.
%sam – 'How' is part of the solution document isn’t it?
 
2.  Sec 3 – “Unnecessary filling of slots in MAC table of edge RBridges RB1,
        due to RB1 receiving broadcast/multicast traffic (e.g. ARP/ND,
        cluster multicast, etc.) from end stations under other edge
        RBridges that are not actually communicating with any end
        stations attached to RB1.”
%sam - Where is RB1? It is not indicated in the picture. 

3.  Sec 4 – “If the application location information can
   be fed to RBridge edge nodes, in some form of Directory Service,
   then RBridge edge nodes won't need to flood data frames with unknown
   DA across the TRILL campus.”
%sam – You may want to clarify here - Does flooding happen when the DA is not present in the Directory. If not, I see a problem. How do you account for the dropped frames. In traditional model, the frames are broadcasted and not dropped.

4.  Sec 4 – “It can trust the directory to tell it where
         the DA is or it will discard the frame if the directory says
         the DA does not exist in the campus.”
%sam- Little confused and same concern as above . Are you saying that the frame is dropped if the DA is not present in the directory. Shouldn’t it flood just like in regular case?

5.  Sec5 – “The {list of interested RBridges} would get populated when an
   RBridge queries for information, or pushed down from management
   systems.”
%sam – Is the document describing the framework for how and when a specific model should be used to populated. Could both pull and push exist at the same time?

6.  Sec 5.3“Under this model, it is recommended that the ingress RBridge simply
   drops a data packet (instead of flooding to TRILL campus) if the
   packet's destination address can't be found in the MAC&VLAN<->Egress
   RBridge mapping table.”
%sam – What is the rationale for this recommendation? How do you know the Directory server has upto date dB that it pushes down to RBridge? If the dB is not consistent, wouldn’t the unknown unicast frames get dropped as per the above?

7.  “The detailed method and hand-shake mechanism between RBridge and Directory Server(s) is beyond the scope of this framework draft.”
%sam – How does the Directory server know whether to push, full or partial info to an RBridge, if there is no handshake mechanism? FW should identify those requirements.

8.  %Sam - On the same lines,If there exists more than one directory server, what are the requirements for both Push and pull models. For ex: How does RBridge know from where to pull the data or which dir server know to push the entries onto the RBridge?

9. For words like should, must, could you use caps SHOULD, MUST etc. Think there is a RFC for the same.

10. Sec 5.3 "There are several options to trigger the pulling process.
   For example, the RBridge edge node can send a pull request whenever
   it receives an unknown DA, or the RBridge edge node can simply
   intercept all ARP/ND requests and forward them to the Directory
   Server(s) that has the information on where the target stations are
   located."
%Sam - I think the options when to pull should clearly be identified and listed, rather than as an example.

11. Sec 6. "Therefore, we suggest TRILL consider directory assisted approach(es).
    This draft only describes the basic framework of using directory
    assisted approach for RBridge edge nodes. More complete mechanisms
    will be described in separate drafts."
%sam - Are you saying, there are complicated mechanisms for Directory assisted approach? What do you mean by basic FW?

12. %sam - Security considerations should take into account of securing the dB of the directory server as well.

13. %sam - May be I am missing the bigger picture for the scope of this draft. Draft describes two different models for directory assisted TRILL N/w. What I fail to see in the draft is the list for requirements for each of those. Should all the requirements be clearly identified and laid out in the draft as well? I do not think the requirements belong in solution document. For example: In Pull model, requirement for 'what should happen when the request time-out? What are the requirements when Directory server reboots? etc. I fail to see those things clearly identified in the document.


On Oct 25, 2012, at 3:55 PM, Donald Eastlake <[e-mail]> wrote:

> This message begins a TRILL WG two week Last Call on the
> draft-ietf-trill-directory-framework draft.
> 
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd   [phone] (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [e-mail]
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill