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

From: "Susan Hares" <[email-masked]>
Date: Sat, 14 Jan 2017 10:10:10 -0500

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:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, January 13, 2017 8:45 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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

---

From: Haoweiguo <[email-masked]>
Date: Mon, 16 Jan 2017 01:48:37 +0000

Thanks Sue, I will update the draft as per your comments ASAP.
weiguo

发件人: Susan Hares [mailto:[email-masked]]
发送时间: 2017年1月14日 23:10
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: RE: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017)

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

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.

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”

Sue Hares

From: trill [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, January 13, 2017 8:45 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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/

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?

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