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

Linda Dunbar <linda.dunbar@huawei.com> Mon, 19 November 2012 17:49 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5C821F859D for <trill@ietfa.amsl.com>; Mon, 19 Nov 2012 09:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.117
X-Spam-Level:
X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvwMn-AsdVXh for <trill@ietfa.amsl.com>; Mon, 19 Nov 2012 09:49:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06221F86A8 for <trill@ietf.org>; Mon, 19 Nov 2012 09:49:06 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALS13178; Mon, 19 Nov 2012 17:49:03 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 17:48:33 +0000
Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 17:48:59 +0000
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 09:48:57 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Sam Aldrin <aldrin.ietf@gmail.com>, Donald Eastlake <d3e3e3@gmail.com>
Thread-Topic: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
Thread-Index: AQHNxDky/scuXvCj5EaZk4DoqUzctJfxX8OQ
Date: Mon, 19 Nov 2012 17:48:56 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645098B90@dfweml505-mbx>
References: <CAF4+nEH9_MkMTDDG7jn_xipXV-feu4Xy0GyH9NyNO_5EaNw3nQ@mail.gmail.com> <562590D1-B25A-475F-9EB5-BA2BA7F8A35B@gmail.com>
In-Reply-To: <562590D1-B25A-475F-9EB5-BA2BA7F8A35B@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.150.180]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645098B90dfweml505mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2012 17:49:12 -0000

Hi Sam,

Thanks for the comments. Answers are inserted below:


From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Friday, November 16, 2012 2:30 PM
To: Donald Eastlake
Cc: trill@ietf.org
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt

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?

[Linda] Yes. We will change the text accordingly.


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.



[Linda] RB1 is just an example, how about changing the wording to

"Unnecessary filling of slots in MAC table of edge RBridges, e.g. 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."





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.



[Linda] The solution draft will specify the policy of dropping frames with unknown DA or flooding. This paragraph is mainly to say that there is less chance of receiving data frames with unknown DA with directory service. Will change the wording accordingly.





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?



[Linda] The policy to drop or flood when entry is not in the directory should be configured as stated earlier.



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?



[Linda] Yes, both pull and push can co-exist. It is up to the configuration.



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?



[Linda] How about changing  the wording to "it is operator's decision on if a frame with unknown DA should be dropped or flooded when the DA doesn't exist in the directory" ?





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.



[Linda] The detailed description is in "draft-dunbar-trill-scheme-for-directory-assist-01". Do you have any suggestion on what should be described in the framework draft?



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.



[Linda] OK



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.



[Linda] OK. Will change wording accordingly.



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?



[Linda] Is it OK to use "more detailed mechanisms"?



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.

[Linda] We can add those requirement. Thanks.

Linda

On Oct 25, 2012, at 3:55 PM, Donald Eastlake <d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>> 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   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>
_______________________________________________
trill mailing list
trill@ietf.org<mailto:trill@ietf.org>
https://www.ietf.org/mailman/listinfo/trill