Subject: [trill] 答复: Comments on draft-ietf-trill-smart-endnodes

From: <[email-masked]>
Date: Thu, 3 Aug 2017 09:10:59 +0800 (CST)

Hi, Donlad

Thanks for your comments.

A new version(draft-ietf-trill-smart-endnodes-06) is uploaded to IETF to fix the comments.

A new version of I-D, draft-ietf-trill-smart-endnodes-06.txthas been successfully submitted by Fangwei Hu and posted to theIETF repository.Name:        draft-ietf-trill-smart-endnodesRevision:    06Title:        TRILL Smart EndnodesDocument date:    2017-08-02Group:        trillPages:        14URL:            https://www.ietf.org/internet-drafts/draft-ietf-trill-smart-endnodes-06.txtStatus:         https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/Htmlized:       https://tools.ietf.org/html/draft-ietf-trill-smart-endnodes-06Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-trill-smart-endnodes-06Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-smart-endnodes-06Abstract:   This draft addresses the problem of the size and freshness of the   endnode learning table in edge RBridges, by allowing endnodes to   volunteer for endnode learning and encapsulation/decapsulation.  Such   an endnode is known as a "Smart Endnode".  Only the attached edge   RBridge can distinguish a "Smart Endnode" from a "normal endnode".   The smart endnode uses the nickname of the attached edge RBridge, so   this solution does not consume extra nicknames.  The solution also   enables Fine Grained Label aware endnodes.

Regards.

Fangwei.

原始邮件

发件人： <[email-masked]>
收件人： <[email-masked]>
日 期 ：2017年07月21日 17:07
主 题 ：[trill] Comments on draft-ietf-trill-smart-endnodes

I support this draft and have the following comments:

Technical
-------------

It is not made clear how Smart End Nodes learn the Designated VLAN of
the link they are on or, considering the paragraph just before the
Section 5.2 header, the Appointed Forwarder for a VLAN or the DRB. It
seems to me the draft needs to say explicitly that the smart end node
snoops on TRILL IS-IS Hellos. Also, it needs to say that a smart end
node, when encapsulating traffic in VLAN X, needs to use the nickname
of the appointed forwarder for VLAN X, regardless of which edge
RBridge it sends the encapsulated frame to, to avoid MAC flip-flop at
the egress RBridge.

The point paragraph just before the Section 6 header provides two
approaches to handling a hybrid local link (a hybrid link is one with
both smart and non-smart end nodes on it). As a Proposed Standard and
in accordance with TRILL's general design approach, the document needs
to select one and make it be the default.

Section 6 also has two alternatives and does not seem clear.
Presumably there isn't a single link with SE1, RB1, and RB2 on it
since that case is well handled by the smart end node using the
appointed forwarder nickname regardless of which edge RBridge it sends
the encapsulated user data to. So it must be that SE1 is dual ported.
If so, probably these ports have different MAC addresses and I'm not
sure what the problem is....

I think it is inconsistent that IANA Considerations says "Smart-Hello"
while near the start of the draft, the TLV is called
"Smart-Parameters".

"The mechanism for querying a directory is out of scope for this
document." -> "The mechanism for querying a directory is given in
[RFC8171]."

Editorial
-----------

Change ".While when" to ". When"

"nicknamae" -> "nickname"

There are also some other more minor editorial things I can
communicate directly to the principal author.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill