Thanks Sue, I will update the draft as per your comments ASAP. weiguo 发件人: Susan Hares [mailto:sha...@ndzh.com] 发送时间: 2017年1月14日 23:10 收件人: trill@ietf.org 抄送: draft-ietf-trill-address-fl...@ietf.org; trill-cha...@ietf.org 主题: RE: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017)
Weiquo, Donald, Yizhou, and Mohammed: Thank you for your work on draft-ietf-trill-address-flush. This is a shepherd’s review for draft-ietf-trill-address-flush. ‘ Shepherd’s answer to questions: 1) Deployment experience �C No deployment experience, but this target action has been useful in other protocols. 2) Convergence experience �C No convergence measurement experience, but targeted convergence based on a centralized controllers can provide better convergence theoretically. 3) Mechanisms comments below �C seem to be editorial, but may be minor. 4) With editorial/minor changes �C document is ready for publication Status: Ready with minor/editorial comments. Minor/editorial changes: #1 page 10,m paragraph 2 �C after table, beginning with “All RBridges implementing” Editorial change: The next 4 paragraph state requirements for processing need to be clearly laid out. A set of suggested text that replaces paragraphs 2, 3, 4 (p. 10-11). New:/ Processing Requirements: The processing requirements based on support for Address Flush Channel message plus the additional types: ・ Basic RBridges functionality: All RBridges supporting the Address Flush Channel message MUST implement type 1 (Blocks of VLANs), type 2 (Bit map of VLANs), and type 6 (All Data labels). Type 6 indicates that all addresses are to be flushed for all data labels. ・ Optional RBridges functionality: RBridges SHOULD implement types 7 and type 8 so that specific MAC addresses can be can be flushed. If a set of RBridges does not implement types 7 and 8, the flush will be inefficient as those not intent to be flashed will have to be relearned. ・ FGL functionality : All RBridges implementing the FGL ingress/egress support and the Address Flush Channel message MUST implement type 3 (Blocks of FGLs), type 4 (Lists of FGLs), and type 5 (Bit Map of FGL). An RBridge that is merely FGL safe [RFC7172], but cannot egress TRILL data packets, SHOULD ignore the FGL types with the Address Flush Channel message as it will not learn any MAC addresses with FGL scope from the MAC data plane. Processing interactions: The parsing of the TLVs in an Rbridge Channel Message in the Address Flush Protocol Specific TLVS by a receiving bridge results in three items: 1) All-Data-label-found flag indicating whether one or more types 6 TLVs (All Data Labels) were encountered, 2) A set of Data labels and blocks of data labels compiled from VLAN TLVs (types 1 and 2), and/or FGL TLVs (types 3, 4, and 5), 3) If a MAC TLVs types (type 6 and 7) are implemented, a set of MAC addresses and Blocks of MAC addresses from the MAC TLVs. For the following flag settings, the processing is as follows: a) If the set of MAC addresses and Block of MAC address is null (item 3 above) then Address Flush applies to all messages. b) If the All-Data-label-found flag (item 1 above) is true, then the address flush message applies to all data labels. The set of Data label and block of data labels (item 2 above) does not have any effect. c) If the All-Data-label-found flag (item 1 above) is false, then the Address Flush message applies to the set of Data labels (see item 2 above) found in VLAn TLVs (types 1 and 2), and/or FGLs TLVS (types 3, 4, and 5). If the set of Data Labels (see item 2 above) is null, the Address Flush message does nothing. / #2 �C editorial nits #2.a) p. 9, figure 4 �C bottom +-+ does not match top �C Is this what you wanted or an error? #2.b) p. 9, paragraph beginning “Type: The 8 bit” Old/ of this Section 2.2 for details on each type / New/of this section (section 2.2) for details on each type/ Sue Hares From: trill [mailto:trill-boun...@ietf.org] On Behalf Of Susan Hares Sent: Friday, January 13, 2017 8:45 PM To: trill@ietf.org<mailto:trill@ietf.org> Cc: draft-ietf-trill-address-fl...@ietf.org<mailto:draft-ietf-trill-address-fl...@ietf.org>; trill-cha...@ietf.org<mailto:trill-cha...@ietf.org> Subject: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017) This begins a 2 week WG Last Call for (1/13/2017 to 1/27/2017) for draft-ietf-trill-address-flush which you can access at: https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/ In your review please consider the following questions: 1) Do you think this request from one TRILL Rbridge to another TRILL Rbridges is useful in deployments? 2) Does it supplement TRILL’s automatic address forgetting and achieve better convergence times when topologies or configuration changes? 3) Are the mechanisms described in this draft technically sound without adding lots of complexity to Trill? 4) Is this document ready for publication? Will the authors please indicate if they know of any IPR relating to this draft in their response to this WG LC? I would appreciate if the authors will answer these four questions as well. Sue Hares Shepherd TRILL WG Co-chair
_______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
