Re: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017)

"Susan Hares" <shares@ndzh.com> Sat, 14 January 2017 15:14 UTC

Return-Path: <shares@ndzh.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 98795129674; Sat, 14 Jan 2017 07:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level:
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJwQK22_ePXz; Sat, 14 Jan 2017 07:14:17 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E4E12945E; Sat, 14 Jan 2017 07:14:17 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.185;
From: "Susan Hares" <shares@ndzh.com>
To: <trill@ietf.org>
Date: Sat, 14 Jan 2017 10:10:10 -0500
Message-ID: <01fe01d26e78$52a06560$f7e13020$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FF_01D26E4E.69CC3220"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJuc2ZW/JsGLZoBSw2sBH+1A+0GaQ==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/KU8sLVy_YPZADCS9AmnHByF-PeY>
Cc: draft-ietf-trill-address-flush@ietf.org, trill-chairs@ietf.org
Subject: Re: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 14 Jan 2017 15:14:19 -0000

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 - No deployment experience, but this target
action has been useful in other protocols. 

2)      Convergence experience - No convergence measurement experience, but
targeted convergence based on a centralized controllers can provide better
convergence theoretically. 

3)      Mechanisms comments below - seem to be editorial, but may be minor. 

4)      With editorial/minor changes - document is ready for publication 

 

 

Status: Ready with minor/editorial comments.  

 

Minor/editorial changes: 

 

#1 page 10,m paragraph 2 - 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 - editorial nits 

#2.a) p. 9, figure 4 - bottom +-+ does not match top - 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-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, January 13, 2017 8:45 PM
To: trill@ietf.org
Cc: draft-ietf-trill-address-flush@ietf.org; trill-chairs@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