Return-Path: 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 F37E4129569 for ; Mon, 6 Feb 2017 17:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 nUjXH_rien8w for ; Mon, 6 Feb 2017 17:22:55 -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 3481D129568 for ; Mon, 6 Feb 2017 17:22:55 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.124.247.135; From: "Susan Hares" To: , , "'Donald Eastlake'" References: In-Reply-To: Date: Mon, 6 Feb 2017 20:18:28 -0500 Message-ID: <002c01d280e0$16e016e0$44a044a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01D280B6.2E0CF510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINlVBSp/eUy7CVYSkwzvsiwjx44aDmk2gA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jon Hudson' Subject: Re: [trill] WG LC for draft-ietf-trill-smart-end-nodes (8/26 to 9/9)- extending WG LC (10/4 to 10/18)//FWD: I-D Action: draft-ietf-trill-smart-endnodes-05.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 01:22:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002D_01D280B6.2E0CF510 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Fangwei:=20 =20 Thank you for uploading the new draft today. I will review the draft as = the shepherd and send you comments.=20 =20 Sue Hares=20 =20 From: hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]=20 Sent: Monday, February 6, 2017 7:53 PM To: Susan Hares; trill@ietf.org; Donald Eastlake Cc: Jon Hudson Subject: Re: [trill] WG LC for draft-ietf-trill-smart-end-nodes (8/26 to 9/9)- extending WG LC (10/4 to 10/18)//FWD: [trill] I-D Action: draft-ietf-trill-smart-endnodes-05.txt =20 Hi,all=20 A new draft is updated based on the discussion with Donald to solve his comments.=20 Please check the link for the new drafts:=20 https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/=20 Regards.=20 Fangwei.=20 >Hi, >See below answers to questions and a review of this draft. >Thanks, >Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >On Tue, Oct 4, 2016 at 12:10 PM, Susan Hares wrote: > This begins a 2 week extension to the WG LC for > draft-ietf-trill-smart-end-nodes (10/4 to 10/18). We started the = call > during August Holidays so the WG may missed this in the email list. = The > authors are asked to indicate whether they know of the IPR relating to this > draft. I do not know of any IPR in this draft that has not already been declared. (Note there are two IPR declarations to the IETF by myself. The first is related to a patent application while the second states authoritatively that that patent application has been abandoned.) > WG participants are asked to consider: > > 1) Does this draft ready for publication? I do not think this document is ready for publication. See review below. > 2) Does the extension of the Rbridge to smart-end nodes solve the > problem of learning freshness and provide offload for the > encapsulation/decapsulation problem? Yes, if all the problems in the draft can be cleaned up, it describes a general approach that can solve these problems. > 3) Do you know of any planned implementations or deployments? > Sue Hares and Jon Hudson Comments on draft-ietf-trill-smart-endnodes-04: On Smart-Hellos It turns out that you also need something like Smart-Hellos and a concept of ajdacency in order to support end station access to Pull Directories as well as end station hosting of Pull Directories. So draft-ietf-trill-directory-assist-mechanisms-08 specifies "TRILL ES-IS" which has Hellos and adjacency determination. A problem with Hellos is their limited capacity and that they cannot generally be fragmented. Sending the MAC addresses a Smart Endnode is handling inside Smart Hellos, as the smart-endndoes draft currently specifies, is probably fine for most servers but if there were some kind of specialized gateway or the like that was acting as a Smart Endnode, the MAC addresses (and Data Labels they are in) might not fit into one Hello PDU. TRILL ES-IS also supports local E-L1CS LSPs which provide fragmentation and plenty of room. So perhaps it should be supported to put MAC reachability information in both TRILL ES-IS Hellos and TRILL ES-IS E-L1CS LSPs.=20 [hfw] On using ESADI This draft says that ESADI can be used by Smart Endnodes. But it is not clear how ESADI works to an end station. As ESADI is currently specified, ESADI LSPs would not even be sent onto a link with end stations unless there was more than one edge RBridge on the link with the Smart End Stations and the ESADI distribution tree happens to include that link. Even if ESADI LSPs are being sent on the link, it seems that all the end station could do currently is snoop on the LSPs, which would not be a reliable distribution mechanism because it is not clear how the end station would request ESADI for a particular Data Label or how it would request retransmission of LSPs it missed -- maybe it could originate ESADI PSNPs in that case... But how does the Smart Endstation originate ESADI LSPs? If it uses the nickname the edge RBridge gives it, how does it know that LSP fragments it originates won't colide with those originated by the edge RBridge? If we can figure out how to support ESADI, that should probably go into draft-trill-ietf-directory-assist-mechanisms draft... Since ESADI is the basis of Push Directories, I suggest that this draft be changed to assume that, for directory like stuff, only Pull Directory information is available, not ESDAI or Push Directories. (How an end station can access Pull Directory information is described in draft-ietf-trill-directory-assist-mechanims.) Some other points The draft does not seem to cover the case of an edge RBridge port that supports Smart Endnodes with a link having both Smart and non-Smart end nodes where the edge RBridge port receives a native multi-destination frame from a non-Smart Endnode. In particular, as well as the usual encapsulation, it would seem that the edge RBridge always needs to send the encapsulated multi-destination frame out that same port so it will be seen by Smart Endnodes since the draft says that the Smart Endnodes will ignore the native multi-destination frame. But what about the case where there are two edge RBridges with ports on the link and the link is part of the distribution tree? The draft says that if a Smart Endnode originates a multi-destination frame, it encpsulates it to a ditribution tree and unicasts it to an edge RBridge that sends it on the distribution tree. But if that tree includes the link, then it will get sent out the port and the Smart Endnode that originated the encapuslated multi-destinaiton frame will see it -- this violates a fundamental principal of Ethernet that when you send a frame, you don't see it echoed back to you. Maybe the Smart Endnode can look as the inner and/or outer source MAC address on some of these things to decide what to listen to and what to do... But, in any case, I do not think all the cases are covered in this draft and things don't really work for mised Smart/non-Smart links in the current draft. Section 6 doesn't really read like part of a standards document. It talks about one possibility and then another. It suggests that under one option multiple edge RBridges on a link that support Smart Endnodes could cooperate to provide a psuedo-nickname to Smart Endnodes on that link to use in encapsulating. But how this would all work, including if the link partitions or rejoints, does not seem to be specified either directly in this draft or indirectly by reference to another document. As a standards track document, this draft need to clearly specify a way to do things. There can be options but all alternatives in the main flow of the document need to be specified. If there are actually options so interesting that they have to be mentioned but that are not specified, they should be relegated to an appendix or something and their descrition should explicitly say that the otion is just besing sketched out and not specified. It is good that a Smart End Node can support Fine Granied Labels (FGL) but the draft should probably say that when and how a Smart End Node decides to use an FGL to encapsulate is beyond the scope of the document. Or say there is configurable mapping from VLANs to FGLs. Or at least say something more. ----- =D7=AA=B7=A2=C8=CB =BA=FA=B7=BD=CE=B0175772/user/zte_ltd = =CA=B1=BC=E4 2017/02/07 08:44 -----=20 internet-drafts@ietf.org=20 =B7=A2=BC=FE=C8=CB: "trill" =20 2017/02/07 08:40=20 =CA=D5=BC=FE=C8=CB ,=20 =B3=AD=CB=CD trill@ietf.org=20 =D6=F7=CC=E2 [trill] I-D Action: draft-ietf-trill-smart-endnodes-05.txt =20 =09 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL Smart Endnodes Authors : Radia Perlman Fangwei Hu Huawei technology Kesava Vijaya Krupakaran Ting Liao Filename : draft-ietf-trill-smart-endnodes-05.txt Pages : 15 Date : 2017-02-06 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trill-smart-endnodes-05 A diff from the previous version is available at: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-smart-endnodes-05 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: = ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill ------=_NextPart_000_002D_01D280B6.2E0CF510 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Fangwei:

 

Thank you for uploading the new draft today.  I will review the = draft as the shepherd and send you comments.

 

Sue Hares

 

From:= = hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]
Sent: = Monday, February 6, 2017 7:53 PM
To: Susan Hares; = trill@ietf.org; Donald Eastlake
Cc: Jon = Hudson
Subject: Re: [trill] WG LC for = draft-ietf-trill-smart-end-nodes (8/26 to 9/9)- extending WG LC (10/4 to = 10/18)//FWD: [trill] I-D Action: = draft-ietf-trill-smart-endnodes-05.txt

 

Hi,all=

A new draft = is updated based on the discussion with Donald to solve his = comments.

Please check = the link for the new drafts:
https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ =

Regards.
Fangwei.

>Hi,

>See below answers to = questions and a review of this = draft.

>Thanks,
>Donald
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Donald E. Eastlake 3rd   = +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 = USA
d3e3e3@gmail.com

>= ;On Tue, Oct 4, 2016 at 12:10 PM, Susan Hares <shares@ndzh.com> = wrote:
> This begins a 2 week extension to the WG LC = for
> draft-ietf-trill-smart-end-nodes (10/4 to 10/18). =   We started the call
> during August Holidays so = the WG may missed this in the email list.  The
> = authors are asked to indicate whether they know of the IPR relating to = this
> draft.

I do not know of any IPR in = this draft that has not already been
declared. (Note there = are two IPR declarations to the IETF by myself.
The first is = related to a patent application while the second = states
authoritatively that that patent application has been = abandoned.)

> WG participants are asked to = consider:
>
> 1)      Does = this draft ready for publication?

I do not think this = document is ready for publication. See review = below.

> 2)      Does the extension of = the Rbridge to smart-end nodes solve the
> problem of = learning freshness and provide offload for the
> = encapsulation/decapsulation problem?

Yes, if all the = problems in the draft can be cleaned up, it describes
a = general approach that can solve these problems.

> 3) =      Do you know of any planned implementations or = deployments?

> Sue Hares and Jon = Hudson

Comments on = draft-ietf-trill-smart-endnodes-04:

On = Smart-Hellos
   It turns out that you also need = something like Smart-Hellos and a
concept of ajdacency in = order to support end station access to Pull
Directories as = well as end station hosting of Pull Directories. = So
draft-ietf-trill-directory-assist-mechanisms-08 specifies = "TRILL
ES-IS" which has Hellos and adjacency = determination.
    A problem with Hellos is their = limited capacity and that they
cannot generally be = fragmented. Sending the MAC addresses a Smart
Endnode is = handling inside Smart Hellos, as the smart-endndoes = draft
currently specifies, is probably fine for most servers = but if there
were some kind of specialized gateway or the = like that was acting as a
Smart Endnode, the MAC addresses = (and Data Labels they are in) might
not fit into one Hello = PDU. TRILL ES-IS also supports local E-L1CS LSPs
which = provide fragmentation and plenty of room. So perhaps it = should
be supported to put MAC reachability information in = both TRILL ES-IS
Hellos and TRILL ES-IS E-L1CS = LSPs.

[hfw]

On using ESADI
  =   This draft says that ESADI can be used by Smart Endnodes. But = it
is not clear how ESADI works to an end station. As ESADI = is currently
specified, ESADI LSPs would not even be sent = onto a link with end
stations unless there was more than one = edge RBridge on the link with
the Smart End Stations and the = ESADI distribution tree happens to
include that link. Even = if ESADI LSPs are being sent on the link, it
seems that all = the end station could do currently is snoop on the
LSPs, = which would not be a reliable distribution mechanism because = it
is not clear how the end station would request ESADI for = a particular
Data Label or how it would request = retransmission of LSPs it missed --
maybe it could originate = ESADI PSNPs in that case... But how does the
Smart = Endstation originate ESADI LSPs? If it uses the nickname = the
edge RBridge gives it, how does it know that LSP = fragments it
originates won't colide with those originated = by the edge RBridge? If
we can figure out how to support = ESADI, that should probably go = into
draft-trill-ietf-directory-assist-mechanisms = draft...
    Since ESADI is the basis of Push = Directories, I suggest that this
draft be changed to assume = that, for directory like stuff, only Pull
Directory = information is available, not ESDAI or Push = Directories.
(How an end station can access Pull Directory = information is described
in = draft-ietf-trill-directory-assist-mechanims.)

Some other = points

    The draft does not seem to cover = the case of an edge RBridge port
that supports Smart = Endnodes with a link having both Smart and
non-Smart end = nodes where the edge RBridge port receives a = native
multi-destination frame from a non-Smart Endnode. In = particular, as
well as the usual encapsulation, it would = seem that the edge RBridge
always needs to send the = encapsulated multi-destination frame out that
same port so = it will be seen by Smart Endnodes since the draft says
that = the Smart Endnodes will ignore the native = multi-destination
frame.
    But what = about the case where there are two edge RBridges with
ports = on the link and the link is part of the distribution tree? = The
draft says that if a Smart Endnode originates a = multi-destination
frame, it encpsulates it to a ditribution = tree and unicasts it to an
edge RBridge that sends it on the = distribution tree. But if that tree
includes the link, then = it will get sent out the port and the Smart
Endnode that = originated the encapuslated multi-destinaiton frame will
see = it -- this violates a fundamental principal of Ethernet that = when
you send a frame, you don't see it echoed back to you. = Maybe the Smart
Endnode can look as the inner and/or outer = source MAC address on some
of these things to decide what to = listen to and what to do... But, in
any case, I do not think = all the cases are covered in this draft and
things don't = really work for mised Smart/non-Smart links in the
current = draft.

    Section 6 doesn't really read like = part of a standards document.
It talks about one possibility = and then another. It suggests that
under one option multiple = edge RBridges on a link that support Smart
Endnodes could = cooperate to provide a psuedo-nickname to Smart
Endnodes on = that link to use in encapsulating. But how this would = all
work, including if the link partitions or rejoints, does = not seem to
be specified either directly in this draft or = indirectly by reference
to another document. As a standards = track document, this draft need to
clearly specify a way to = do things. There can be options but all
alternatives in the = main flow of the document need to be specified. If
there are = actually options so interesting that they have to = be
mentioned but that are not specified, they should be = relegated to an
appendix or something and their descrition = should explicitly say that
the otion is just besing sketched = out and not specified.

    It is good that a = Smart End Node can support Fine Granied Labels
(FGL) but the = draft should probably say that when and how a Smart End
Node = decides to use an FGL to encapsulate is beyond the scope of = the
document. Or say there is configurable mapping from = VLANs to FGLs. Or
at least say something = more.


-= ---- =D7=AA=B7=A2=C8=CB = =BA=FA=B7=BD=CE=B01= 75772/user/zte_ltd =CA=B1=BC=E4 = 2017/02/07 08:44 -----

internet-drafts@ietf.org =
=B7=A2=BC=FE=C8=CB: =  "trill" <trill-bounces@ietf.org>

2017/02/07 = 08:40

<i-d-announce@ietf.org>, =

 

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

trill@ietf.org =

=D6=F7=CC=E2

[trill] I-D = Action: = draft-ietf-trill-smart-endnodes-05.txt





A New Internet-Draft is available = from the on-line Internet-Drafts directories.
This draft is = a work item of the Transparent Interconnection of Lots of Links of the = IETF.

       Title     =       : TRILL Smart Endnodes
    =    Authors         : Radia = Perlman
              =            Fangwei Hu
  =                     =    Huawei technology
        =                  Kesava = Vijaya Krupakaran
            =              Ting = Liao
                = Filename        : = draft-ietf-trill-smart-endnodes-05.txt
      =           Pages         =   : 15
              =   Date            : = 2017-02-06

Abstract:
  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.


The IETF datatracker status page for = this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tr= ill-smart-endnodes/

There's also a htmlized version = available at:
<= tt>https://tools.ietf.org/html/draft-ietf-trill-s= mart-endnodes-05

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -trill-smart-endnodes-05


Please note that it may take = a couple of minutes from the time of submission
until the = htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

__________________________________= _____________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

------=_NextPart_000_002D_01D280B6.2E0CF510--