Early Review of draft-ietf-trill-irb-09
review-ietf-trill-irb-09-rtgdir-early-hares-2016-01-15-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see



​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document:



draft-ietf-trill-irb-09.txt



Reviewer: Susan Hares

Review Date: 1/14/2016

Type of Review: QA-Review

Summary:

 2 Minor issue which must be resolved before publication.  A few editorial nits.

Minor issues:

1.



Page 11 – states that each of the edge RBridges establishes its gateway
interface for the subnet and these gateway interfaces on different edge
RBridges share the same gateway Mac and gateway IP address.

It is unclear what specific mechanisms allow the different RBridge routers to
share the same gatewayAC and IP address.  If the mechanism is in section 7.1
(Tenant Label and Gateway MAC APPsub-TLV), then it needs to be  referred to
here.

It is clear in the second paragraph on p. 11, that the Ends System will ARP/ND
query and provide its MAC/IP address mapping to the gateway interface.

2.



p. 12 – paragraph 2 staring with “If a tenant is deleted on the edge RBridge
RB1, RB1 notifies all other edge RBridges to delete the tenant Label, the
gateway MAC, and related IP prefixes that were local to RB1 by withdrawing its
advertisement of that information.

There are two ways to withdraw advertisement:  a) a specific withdraw TLV, or
 b) re-announce IP Address lists (section 7.3) without the information.

If this solution uses section 7.1 to announce Tenant ID, Tenant Labels, and
Tenant MAC addresses – how are you going to delete these announcements?  It is
not covered any place in the draft.   One way you could do this is to include a
Type for announce / and a second type for delete.

If this solution uses section 7.3 or 7.4 to announce IP address labels, you
will need to announce all the IP addresses again.   If you do not want to do
this, you could duplicate the APPSub-TLVs (7.3 and 7.4) with a delete function.

These two issues are listed as “minor” because this lack in the specification
can be easily solved by with APPSub-TLV.  However, this lack needs to be
resolved before publication.

Editorial:

The majority of this draft is well written.  Here are a few editorial
comments.  The authors may utilize these editorials or decide not to use the
editorial suggestions

1)



p. 6

from:  /ES1 to ES8 belong to one tenant, the tenant has four subnets each
subnet corresponds to one VLAN indicating one individual layer 2 virtual
network, each ES’S IP address, VLAN, and subnet are listed as follows:/

to / ES1 to ES8 belong to one tenant network and the tenant has four subnets
with each subnet corresponding to one VLAN (which indicates one individual
layer 2 virtual network).  Each ES’s IP address, VLAN and subnet are listed
below:/

2)



p 11, section 5.2 paragraph 2.

From: /It’s implementation dependant and there is no restriction on this/

To: /It is implementation dependent and there is no restriction on this
assignment of labels/

3)



p. 11 section 5.2

Put a paragraph break before “The tenant gateway MAC differentiates”

4)



p. 14 section 5.4 paragraph 5

from: /the RBridge decapsulates the TRILL encapsulation and check the
Inner.MacDA, if /

to: /the RBridge decapsulates the TRILL encapsulation and check the
Inner.MacDA. If/

5)



section 6.2

You should check your form of doing the numbered list.  I believe if you use a
different style of list it will read better.  If the numbers “1., 2., 3. , and
4. – form the edge of the text, then this will be easier to read

1.



ESI sends unicast ..

Additional text after the first line should be at this indentation.

2.



Ingress RBridge …

3.



Transit RBridge …

4.



Egress RBridge

6)



Section 7 –

Bullet lists in section 7.1 – 7.4 – would be more readable if you used the same
form of indentation.

Sue Hares (shares at ndzh.com)