From ostokes@extremenetworks.com Wed Apr 3 13:21:46 2013 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 47D2921F8AC2 for ; Wed, 3 Apr 2013 13:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbEKVNhCGmTk for ; Wed, 3 Apr 2013 13:21:43 -0700 (PDT) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id D359D21F8AB0 for ; Wed, 3 Apr 2013 13:21:43 -0700 (PDT) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p1.corp.extremenetworks.com ([10.0.4.73]) with mapi; Wed, 3 Apr 2013 13:21:43 -0700 From: Olen Stokes To: "trill@ietf.org" Date: Wed, 3 Apr 2013 13:21:42 -0700 Thread-Topic: Review of draft-ietf-trill-oam-framework-01 Thread-Index: Ac4wqFoDeYsGLCzuRWalcngnNaMvwQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB502A172B83A1FUSEXCHANGEc_" MIME-Version: 1.0 Subject: [trill] Review of draft-ietf-trill-oam-framework-01 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 20:21:46 -0000 --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB502A172B83A1FUSEXCHANGEc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on a review of the subject document, please consider the following co= mments: 1) Section 2.6 states that "a CFM MEP resides in the "802.1Q Port VLAN Pro= cessing" block" of Figure 2. I was not able to find a block with that titl= e in Figure 2. 2) Section 2.6 states that "A TRILL OAM solution that conforms to this fra= mework" MAY support UP MEP's and MAY support DOWN MEP's on TRILL physical p= orts. I was unclear about the implications of these statements. Does that= imply that a solution could be acceptable even though it does not support = either UP or DOWN MEP's? 3) Section 3.1 at the top of Page 16 states, "The TRILL Header is as speci= fied in [RFC6325]". Should this paragraph include some discussion or refer= ence to the TRILL Header as specified in the Fine Grained Labeling (FGL) do= cument, especially since the FGL document "changes the description of the T= RILL Header" in its Section 2.2? 4) Section 3.3 states, "The use of [802.1Q] CFM encoding format for the OA= M Message channel is one possible choice." Given the amount of Y.1731 term= inology used in this document, it might be helpful to at least make some st= atement about the possibility of using Y.1731 formatting. I understand tha= t the formats are compatible, but there are some differences. 5) Section 3.3 references [TRILL-OAM] which is listed as "draft-tissa-tril= l-8021ag". This document is expired. Has it been replaced by "draft-tissa= -trill-oam-fm-01.txt"? 6) Section 3.4 suggests "using a reserved MAC address as the inner MAC SA"= to identify a TRILL OAM packet. It is unclear to me how this is more back= wards compatible than using previously unused fields or bits in the TRILL H= eader as suggested in the preceding paragraph. Is not the inner MAC SA use= d in some configurations for hashing at hops with equal-cost paths? 7) Section 4.1.2.2 describes Reverse Defect Indication (RDI). Given that = Section 4.1.1 states that fault detection must be able to exercise each equ= al-cost path individually, Section 4.1.2.2 should probably state that RDI m= ust be able to identify on which equal-cost path the failure was detected. 8) Section 4.2.1 discusses carrying "test patterns as defined in [RFC2544]= ." RFC 2544 is a substantial document but it does not contain the word "pa= ttern". Is this a reference to the frame formats in Appendix C or to some = other section of the RFC? 9) Section 4.2.1.2 discusses an un-pruned tree and a campus wide diagnosti= c VLAN. A campus wide diagnostic FGL is probably also required. 10) Section 4.2.2 discusses fault isolation. It would be helpful to includ= e a statement that fault isolation has to work for both known unicast and m= ulti-destination packets. As a general comment, Section 1.2 states that the document "leverages conce= pts and draws upon elements defined and/or used" in multiple existing OAM s= tandards including 802.1ag CFM and Y.1731. The document contains a mixture= of terms from these two standards. For example, the Y.1731 term Maintenan= ce Entity Group (MEG) is used as opposed to the 802.1ag term Maintenance As= sociation (MA). However, the 802.1ag term Maintenance Point (MP) is used a= s opposed to the Y.1731 term Maintenance Entity (ME). It does not appear t= o affect the technical content but it is unclear why the terminology is mix= ed. Some statement about the method used to determine which terms to use m= ight be helpful. Please let me know if you would like to discuss any of these items further. Cheers, Olen --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB502A172B83A1FUSEXCHANGEc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on a review of the subject= document, please consider the following comments:

1)=   Section = 2.6 states that “a CFM MEP resides in the "802.1Q Port VLAN Proc= essing" block” of Figure 2.  I was not able to find a block= with that title in Figure 2.

 

2)  Section 2.6 states that “= A TRILL OAM solution that conforms to this framework” MAY support UP = MEP’s and MAY support DOWN MEP’s on TRILL physical ports. = I was unclear about the implications of these statements.  Does that = imply that a solution could be acceptable even though it does not support e= ither UP or DOWN MEP’s? 

=  

3)  Section 3.1 at = the top of Page 16 states, “The TRILL Header is as specified in [RFC6325]̶= 1;.  Should this paragraph include some discussion or reference to the= TRILL Header as specified in the Fine Grained Labeling (FGL) document, esp= ecially since the FGL document “changes the description of the TRILL = Header” in its Section 2.2?

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

4)  Section 3.3 states, “= The use of [802.1Q] CFM encoding format for the OAM Message channel is one = possible choice.”  Given the amount of Y.1731 terminology used i= n this document, it might be helpful to at least make some statement about = the possibility of using Y.1731 formatting.  I understand that the for= mats are compatible, but there are some differences. 

 

5)  = Section 3.3 references [TRILL-OAM] which is listed as “draft-tissa-tri= ll-8021ag”.  This document is expired.  Has it been replace= d by “draft-tissa-trill-oam-fm-01.txt”?

 

6)<= span style=3D'font:7.0pt "Times New Roman"'>  Section 3= .4 suggests “using a reserved MAC address as the inner MAC SA” = to identify a TRILL OAM packet.  It is unclear to me how this is more = backwards compatible than using previously unused fields or bits in the TRI= LL Header as suggested in the preceding paragraph.  Is not the inner M= AC SA used in some configurations for hashing at hops with equal-cost paths= ?

 

<= span style=3D'mso-list:Ignore'>7)Section 4.1.2.2 describes Reverse Defect Indicatio= n (RDI).  Given that Section 4.1.1 states that fault detection must be= able to exercise each equal-cost path individually, Section 4.1.2.2 should= probably state that RDI must be able to identify on which equal-cost path = the failure was detected.

=  

8)  Section 4.2.1 discusses ca= rrying “test patterns as defined in [RFC2544].”  RFC 2544 = is a substantial document but it does not contain the word “pattern&#= 8221;.  Is this a reference to the frame formats in Appendix C or to s= ome other section of the RFC?

 <= /o:p>

9)  Section 4.2.1.2 discus= ses an un-pruned tree and a campus wide diagnostic VLAN. A campus wide diag= nostic FGL is probably also required.

 

10) <= /span>

As a general comment, Section 1.2 states that the document <= /span>“lev= erages concepts and draws upon elements defined and/or used” in multi= ple existing OAM standards including 802.1ag CFM and Y.1731.  The docu= ment contains a mixture of terms from these two standards.  For exampl= e, the Y.1731 term Maintenance Entity Group (MEG) is used as opposed to the= 802.1ag term Maintenance Association (MA).  However, the 802.1ag term= Maintenance Point (MP) is used as opposed to the Y.1731 term Maintenance E= ntity (ME).  It does not appear to affect the technical content but it= is unclear why the terminology is mixed.  Some statement about the me= thod used to determine which terms to use might be helpful.

Please let me know if you would like to = discuss any of these items further.

 

Cheers,

Olen

= --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB502A172B83A1FUSEXCHANGEc_-- From d3e3e3@gmail.com Wed Apr 3 14:06:49 2013 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 66B2621F8F10 for ; Wed, 3 Apr 2013 14:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9ocXMeaui2O for ; Wed, 3 Apr 2013 14:06:49 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id E218821F8F0D for ; Wed, 3 Apr 2013 14:06:48 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so2057482oag.1 for ; Wed, 03 Apr 2013 14:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=q2ONY2P+iF36qJiSyitf1egSXY1qnzN6DdL4FXCmOdQ=; b=lCI5Nxv2xzrtbxf92cgXjsXhSAogI4BWEw817qJXJXhBkNimOXy09+C/JSpUdQju/A m/tCO7+BWM7b9MHpL6077wSQXJFHPi5Il+rD8Xi6911PzAe+FxCJ1xtnA623pJXINCSZ zxRaig8yHgIsQoXylW0NZPE2aRUeomwmbufGFB/RYb1PPTKZ9szPlRePwwitDhaHxoCO d8XJyPF44jov14OygLErhnbrDafcnpfkPkve12dTfOF+ZOmp57++xoT/v0EhbOjlmTMt TeqZQJ96te0Ozxh82DxrUXiZDqpj5m+BarC/QwbrXK+QgXMs6frr3ZkPvX7PGsY0t1sp K+Mg== X-Received: by 10.60.118.104 with SMTP id kl8mr2221111oeb.68.1365023208507; Wed, 03 Apr 2013 14:06:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.139.200 with HTTP; Wed, 3 Apr 2013 14:06:28 -0700 (PDT) In-Reply-To: <201304010513.r315DbDx076312@skyhighway.com> References: <201304010513.r315DbDx076312@skyhighway.com> From: Donald Eastlake Date: Wed, 3 Apr 2013 17:06:28 -0400 Message-ID: To: gayle noble Content-Type: text/plain; charset=ISO-8859-1 Cc: trill@ietf.org Subject: Re: [trill] Review of draft-ietf-trill-oam-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:06:49 -0000 Hi Gayle, On Mon, Apr 1, 2013 at 1:13 AM, gayle noble wrote: > In reading some of the drafts it occurred to me that something should be > specified as to how one should handle OAM messages that might be sent from > outside the TRILL campus in the draft that talks about this. > > Currently in draft draft-ietf-trill-oam-framework-01.txt, in the Security > Considerations Section it says: > "Optionally authenticate communicating endpoints (MEPs and MIPs)" > > To be real clear I think it should read something like:: > > "Optionally authenticate at communicating endpoints (MEPs and MIPs) > that an OAM message has originated at a communicating endpoint." Thanks for the comment... Maybe it should even say "... has originated at an appropriate communicating endpoint." > Perhaps even add in that if the OAM message fails authentication, the switch > should log the attempt and notify the sys admin. Or maybe that is obvious? I don't think the IETF is complete consistent on this point but generally IETF specifications concentrate on the bits on the wire and the state machines at the end points so they frequently omit saying anything explicit about logging... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > gayle From nordmark@acm.org Wed Apr 3 21:01:59 2013 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 7822011E80A5 for ; Wed, 3 Apr 2013 21:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhjZYK2Sjgzu for ; Wed, 3 Apr 2013 21:01:59 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 07C9011E80A2 for ; Wed, 3 Apr 2013 21:01:58 -0700 (PDT) Received: from [10.21.145.80] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r3441tHZ020993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Apr 2013 21:01:56 -0700 Message-ID: <515CFB34.2060800@acm.org> Date: Wed, 03 Apr 2013 21:01:56 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Donald Eastlake References: <201303201859.r2KIxJ32017742@cichlid.raleigh.ibm.com> <201303202032.r2KKWOMj030163@cichlid.raleigh.ibm.com> <201303202119.r2KLJL8X003890@cichlid.raleigh.ibm.com> <201303210103.r2L13KOi032305@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , trill@ietf.org Subject: Re: [trill] FGL "safe" mode in fine labels X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 04:01:59 -0000 On 3/22/13 8:06 AM, Donald Eastlake wrote: >> >3a) First, if you are using both VL-Edges and FGL-edges, what is the >> >interoperabilty model intended to be? If RB1 is VL-only and supports >> >VLAN 1, but RB3 is an FGL-edge and also accepts traffic on VLAN 1, >> >what is supposed to happen? Is traffic supposed to be relayed between >> >those two VLANs? Why or why not? > > I don't quite understand your questions and, like almost everything, > it depends on whether you are doing 0, 1, or 2 and your topology, at > least whether your FGL-safe TRILL switches are all contiguous, as they > should be, or your campus is misconfigured to have disjoint FGL > islands. I think Thomas question is not so much about the transit behavior, but about the semantics of a VLAN vs. a FGL at the edge. FWIW VLAN 1 is a bad example, because it special from 802.1's perspective. I'll use VLAN 100 below aka VLAN 0x64 (in hex). When RB1 receives a native packet with VLAN 100 (or a co-located bridge tags an untagged from a port configured to tag with VLAN 100), then this packet will be encapsulated by TRILL with an inner VLAN 100. If the port on RB3 (recall, FGL is configured per port at the edge) has been configured as a VL port, then the same thing happens on RB3 as on RB1. But if the port on RB3 has been configured as FGL, then RB3 will map VLAN 100 to some FGL. That FGL value could be 0x000064 (i.e., a FGL label with the value of 100) or it could be 0x123456. In neither of those cases will that be equivalent to a packet with VL 0x064. The VL space is disjoint from the FGL space. All of the above is orthogonal to how the transit works - whether or not there are some VL RBridges or only FGL-safe RBridges in the network. Erik From nordmark@acm.org Wed Apr 3 21:18:00 2013 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 8083F11E80A5 for ; Wed, 3 Apr 2013 21:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg+HUMN8kNZv for ; Wed, 3 Apr 2013 21:17:58 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACE711E80A2 for ; Wed, 3 Apr 2013 21:17:58 -0700 (PDT) Received: from [10.21.145.80] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r344HsSe000454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Apr 2013 21:17:55 -0700 Message-ID: <515CFEF4.4090605@acm.org> Date: Wed, 03 Apr 2013 21:17:56 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Thomas Narten References: <201303201859.r2KIxJ32017742@cichlid.raleigh.ibm.com> <201303202032.r2KKWOMj030163@cichlid.raleigh.ibm.com> <201303202119.r2KLJL8X003890@cichlid.raleigh.ibm.com> <515CFCB8.6000207@sonic.net> In-Reply-To: <515CFCB8.6000207@sonic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Radia Perlman , trill@ietf.org Subject: Re: [trill] FGL "safe" mode in fine labels X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 04:18:00 -0000 On 3/20/13 2:19 PM, Thomas Narten wrote: > The above says to me that you now have a TRILL campus where R1 does > process FGL frames and R2 does not. But doesn't that contradict the > model: > >> 1) VL-only (today's deployment), then >> 2) A mixture of VL and FGL-safe, until >> 3) EVERYone upgraded to FGL-safe, then >> 4) FGL-links can be introduced. FWIW Your use of "FGL-link" is not consistent with the definition in the document. The document defines it as "A link where all of the attached TRILL switches are FGL." I think what you refer to in #4 is what the document calls FGL-edge. > Or maybe we are having a violent agreement? if we are at step 2) > above, then isn't the entire campus operating in "VL mode"? I.e., at > step 2, no one is sending/receiving/processing FGL frames. (Right?) > > It's not until step 3/4 that you see *any* FGL frames being used. And > for that, you can't have *any* RBs still operating only in VL mode - > they *all* have to support FGL. While the above 1-4 is a reasonable way to deploy FGL, the protocol mechanisms must be robust against there (perhaps accidentally) being VL RBridges when FGL-edges are in use; whether that is because not all was upgraded to FGL-safe, or after everything is FGL-safe someone (perhaps accidentally) connects one or more VL RBridges to the network. That is why we have the rules about safety - not forwarding a FGL frame to a VL RBridge. Regards, Erik From dromasca@avaya.com Thu Apr 4 01:56:29 2013 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 A638A21F961A for ; Thu, 4 Apr 2013 01:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.974 X-Spam-Level: X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b345ATtWSDcI for ; Thu, 4 Apr 2013 01:56:28 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD0121F9619 for ; Thu, 4 Apr 2013 01:56:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALh+MVHGmAcF/2dsb2JhbAA6CoJmv16BABZzgh8BAQEBAgESKDgMDQEVFRRCJgEEGxMHh2sGAZ99hCqcQ41SgRqDF2EDkwKJWopSgwiCJw X-IronPort-AV: E=Sophos;i="4.84,766,1355115600"; d="scan'208";a="5521153" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Apr 2013 04:56:27 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Apr 2013 04:54:00 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Thu, 4 Apr 2013 04:56:26 -0400 From: "Romascanu, Dan (Dan)" To: TRILL Working Group Thread-Topic: my comments on draft-ietf-trill-oam-framework Thread-Index: Ac4xEkkxNdzOrNdAThmijtqtgZEQwg== Date: Thu, 4 Apr 2013 08:56:25 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C1543@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [trill] my comments on draft-ietf-trill-oam-framework X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 08:56:29 -0000 Hi, Here are my comments on draft-ietf-trill-oam-framework-01.txt I have divided them in Technical and Editorial.=20 Technical T1. The references are broken in many ways. Many references in the text are= not included in the References sections - runing id-nits shows this immedi= ately. Listed references point to documents that do not exist [TRILL-OAM], = [TRILL-IP].=20 T2. I have mixed feelings about the usage of RFC 2119 capitalized keywords = in this document. My preference would be to drop them completely, especiall= y as the document is targeting Informational status. If they stay, we need = to carefully review the usage, right now it's quite inconsistent.=20 T3. The document does not include a section on operational and manageabilit= y considerations. I believe that this is necessary, and this section should= include as a minimum:=20 - what parameters need to be configured on Rbridges in order to activate TR= ILL OAM - activation of specific OAM functions, periodicity of OAM messages= , activation of synthetic traffic (periodic or on demand) - how are these parameters configured? Are there recommended default values= ?=20 - how are results of Performance Management used or retrieved? T4. Several terms are used according to the terminology defined in RFC 6905= - Section, Flow, Connectivity, Continuity Indication, etc. I suggest to me= ntion this in Section 1.2 T5. Are the references to L2VPN and MPLS-TP (and the respective [RFC6136] a= nd [RFC6371]) in Section 1.2 needed at all? I do not see these technologies= mentioned in any other part of the document, and if there is no relevant r= elationship with the OAM functions on these layers I would suggest to drop = these.=20 T6. In 2.4 we have an example why using 2119 capitalized keywords is proble= matic: > When considering multi-domain scenarios, the following rules must be followed: TRILL OAM domains MUST NOT overlap, but MUST either be disjoint or nest to form a hierarchy (i.e. a higher Maintenance Domain MAY completely engulf a lower Domain). If I was to chose, I would prefer not to use capitalization, or use capital= ization only for the first 'must' which is not capitalized in the text. 'MU= ST either ...' is a strange combination. One may argue that nesting is a fo= rm of overlapping, and actually 'MUST not overlap' is should rather be 'MUS= T not partially intersect'.=20 T.7 In Section 3.1:=20 > Additionally methods must be provided to prevent OAM packets from being transmitted out as native frames. If capitalized RFC 2119 keywords are to be kept, this 'must' must be a 'MUS= T' (because of the critical impact on the bits on wire)=20 T.8 In section 3.2:=20 > When running OAM functions over Test Flows, the TRILL OAM should provide a mechanism for discovering the flow entropy parameters by querying the RBridges dynamically. I am wondering why this is a 'should' and not a 'must'. Are there any excep= tion cases?=20 T.9 Section 3.4:=20 > RBridges must be able to identify OAM messages that are destined to them, either individually or as a group, so as to properly process those messages.=20 OK - so a method must be in place.=20 It may be possible to use a combination of one of the unused fields or bits in the TRILL Header and the OAM EtherType to identify TRILL OAM messages.=20 ' one of the unused fields or bits in the TRILL Header' - which ones? Are w= e talking about an update to RFC 6395? Where is this defined?=20 Is the 'and' between the TRILL header combinations and the OAM EtherType re= ally an 'and' or rather an 'or'? 'OAM EtherType' is rather 'TRILL OAM Ether= Type'?=20 [RFC6325] does not specify any method of identifying OAM messages. Hence, for backwards compatibility reasons, TRILL OAM solutions must provide methods to identify OAM messages through the use of well- known patterns in the Flow Entropy field; for e.g., by using a reserved MAC address as the inner MAC SA. Is this an alternate method to the ones described in the previous paragraph= ? Then, the 'must' is probably rather a 'may' or should'. What ' reserved M= AC address' are we talking about? Is this something that we should ask from= the IEEE RAC? Where is this specified?=20 T.10 Section 4.1.1 - What does 'Period mis-configuration' mean? Is this abo= ut the periodicity of the OAM messages? If so this defect is about OAM conf= iguration, not about continuity check. If it's something different, please = explain or provide a reference.=20 T.11 Section 4.2:=20 > On-demand fault management functions are initiated manually by the network operator and continue for a time bound period. The last part of the statement is not always true, as some fault management= functions may be one-time actions or tests. =20 T.12 Section 5. - Performance Management - I am not thrilled about this sec= tion at all. Note that RFC 6905 talks about Performance Monitoring (not Man= agement) and it's not a mandatory function. Terminology aside, I dislike ge= nerating synthetic traffic in order to measure packet loss - how much traff= ic? Limiting this seems mandatory. Who compares what was sent with what was= received? 5.2 talks about hardware-based time-stamping to measure Packet = Delay. This implies some kind of clocks synchronization between RBridges. W= hat are the requirements?=20 T.13 The Security Considerations section should be more explicit on what 'e= xploitation of the OAM message channel' means. Specifically the threats rel= ated to overloading the network and the Rbridges with OAM messages should b= e mentioned, as well as the impact of interrupting the OAM services.=20 =20 Editorial E1. In Section 1:=20 > Some characteristics of a TRILL network that are different from Ethernet bridging ... s/Ethernet bridging/IEEE 802.1 bridging/ E2. Check for completeness of the acronyms list in section 1.1. For example= ECMP is used a few times in the document, but not listed here and never ex= panded.=20 E3. In several places (2.1.3 is the first) I found 'For e.g.,'. I believe t= hat this is a pleonasm, either use 'For example', or just e.g.=20 E4. In section 2.2: s/TRILL OAM processing can be modeled as a layer/TRILL = OAM processing can be represented as a layer/ E5. In Section 2.3:=20 > Network OAM mechanisms provide fault and performance management functions in the context of a representative 'test' VLAN or fine- grained label [TRILL-FGL]. =20 What does 'representative' mean here?=20 E6. 'faults in connectivity or performance' - 'connectivity faults and perf= ormance degradation' is probably better E7. In Section 2.6:=20 > MEPs are the active components of TRILL OAM: MEPs source TRILL OAM messages proactively or on-demand based on operator invocation. The usage of the term 'proactively' seems to me to be incorrect. I would ra= ther use 'periodically'. Also s/operator invocation/operator configuration = actions/ E8. In Section 2.6:=20 > - MUST support the UP MEP function on a TRILL virtual port (to=20 support OAM functions on Sections) I would add for clarity inside the brackets '... as defined in 'rfc6905' Regards, Dan From dromasca@avaya.com Thu Apr 4 02:46:49 2013 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 CC2A121F9644 for ; Thu, 4 Apr 2013 02:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.453 X-Spam-Level: X-Spam-Status: No, score=-103.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSX6wkDeoqpJ for ; Thu, 4 Apr 2013 02:46:48 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8318521F9643 for ; Thu, 4 Apr 2013 02:46:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAHpXMFGHCzI1/2dsb2JhbABEgma/Tn8Wc4IfAQEBAQIBEig/DAQCAQgNAQMEAQELFAkHMhQJCAIEAQ0FCBqHawYBpGGcQ45jJgsHBoJZYQOcWopRgwiCJw X-IronPort-AV: E=Sophos;i="4.84,760,1355115600"; d="scan'208";a="5530894" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Apr 2013 05:46:47 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Apr 2013 05:44:21 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Thu, 4 Apr 2013 05:46:46 -0400 From: "Romascanu, Dan (Dan)" To: Donald Eastlake , gayle noble Thread-Topic: [trill] Review of draft-ietf-trill-oam-framework-01.txt Thread-Index: AQHOMK8ru+5fmdrbvUO6aG0U+pbvy5jFz7Sw Date: Thu, 4 Apr 2013 09:46:45 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C16F6@AZ-FFEXMB04.global.avaya.com> References: <201304010513.r315DbDx076312@skyhighway.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] Review of draft-ietf-trill-oam-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 09:46:49 -0000 > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf > Of Donald Eastlake > Sent: Thursday, April 04, 2013 12:06 AM > To: gayle noble > Cc: trill@ietf.org > Subject: Re: [trill] Review of draft-ietf-trill-oam-framework-01.txt >=20 > > Perhaps even add in that if the OAM message fails authentication, the > > switch should log the attempt and notify the sys admin. Or maybe that > is obvious? >=20 > I don't think the IETF is complete consistent on this point but > generally IETF specifications concentrate on the bits on the wire and > the state machines at the end points so they frequently omit saying > anything explicit about logging... >=20 [[DR]] As Donald says (politely) the IETF is not completely consistent on t= his point. My preference is for an Operational and Manageability Considerat= ions section (as recommended by RFC 5706) which would among other list the = recommended tools to be implemented in the routers or hosts for administra= tion purposes. Logging security incidents would be such a function. See als= o my review of the same document, a few more items may be included in such = a section. There is no need to define all the details here, but to list the= issues to the attention of implementers and operators, and as subject for = future work.=20 Regards, Dan From shares@ndzh.com Thu Apr 4 14:36:33 2013 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 BD6A621F8F0E for ; Thu, 4 Apr 2013 14:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.705 X-Spam-Level: * X-Spam-Status: No, score=1.705 tagged_above=-999 required=5 tests=[AWL=1.199, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOULUYEEWvpk for ; Thu, 4 Apr 2013 14:36:32 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E9F0A21F8FCF for ; Thu, 4 Apr 2013 14:36:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Donald Eastlake'" , , , Date: Thu, 4 Apr 2013 17:36:28 -0400 Message-ID: <014e01ce317c$778f7880$66ae6980$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014F_01CE315A.F0815AF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4xfGWYe5JQyIDFRvKvLvCLF+llFg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: trill@ietf.org Subject: [trill] TRILL OAM framework review (draft-ietf-trill-oam-framework-01) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:36:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014F_01CE315A.F0815AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Donald, Sam, Tissa, and Samer: General comments: Nicely written and enjoyable to read after all of the debates. Two technical issues concern me as underspecified in the document: 1. Section 2.4 has maintenance Domains which can be "nested to form a hierarchy" (p. 12, para. 1) a. The nesting of Domains seems to be underspecified in this draft and it is unclear exactly how these domains would nest. b. There are mechanism for finding the hierarchy (Domain name and maintenance level (numeric ID), but it is not clear from the document how this works. 2. Section 4.2.1.2 - Multicast prevention of reply storms from overwhelming the initiating RBridge. a. Staggering or Jittering responses may or may not protect the initiating RBridge b. Again - this may be right or wrong, but the lack of additional details concerns me whether this solution has been written down correctly. I suspect from Tissa's comments that it is working. Editorial comments: 1. Replace TRILL-OAM-REQ with RFC6905 in all document, 2. p. 4 TRILL in para. 2 has an extra space "- TRILL" to "-TRILL" 3. use of "multipathing" - has this been defined elsewhere? - it should be defined or referenced, 4. page 6. Para. 2 beginning [RFC6371]. Please change /protection-switching management and/protection-switching management/ 5. page 8 sentence: "The output ports on which TRILL OAM message are sent are determined by the TRILL routing function, which will only send on links that are in the up state and have been incorporated into the local view of the campus topology" - Suggest a. "The output ports on which TRILL OAM messages are sent are determined by the TRILL routing function. The TRILL Routing function will only send on links that are in the up state and have been incorporated into the local view of the campus topology". 6. Page 11 - [TRILLML] - is not listed in the references - 7. Page 16. Suggest changing 1st sentence of paragraph into two parts. /[RFC6325] and the Link Header/[RFC6325]. The Link header" 8. Page 4.1.2.2 add at end of sentence 2 /section./ section (4.1.2.1). Sue Hares Reviewer ------=_NextPart_000_014F_01CE315A.F0815AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Donald, = Sam, Tissa, and Samer:

 

General = comments: Nicely written and enjoyable to read after all of the debates. =

 

Two technical issues concern me as underspecified in = the document:

 

1.       = Section 2.4 has maintenance Domains which can be = “nested to form a hierarchy” (p. 12, para. 1) =

a.       The = nesting of Domains seems to be underspecified in this draft and it is = unclear exactly how these domains would nest.

b.      = There are mechanism for finding the hierarchy = (Domain name and maintenance level (numeric ID), but it is not clear = from the document how this works.

2.       = Section 4.2.1.2 – Multicast prevention of = reply storms from overwhelming the initiating RBridge.

a.       = Staggering or Jittering responses  may or = may not protect the initiating RBridge

b.      = Again – this may be right or wrong, but = the lack of additional details concerns me whether this solution has = been written down correctly.  I suspect from Tissa’s comments = that it is working.

 

Editorial = comments:

1.       = Replace TRILL-OAM-REQ with RFC6905 in all = document,

2.       p. = 4 TRILL in para. 2 has an extra space “-     = TRILL” to “-TRILL”

3.       use = of “multipathing” – has this been defined elsewhere? = – it should be defined or referenced,

4.       = page 6. Para. 2 beginning [RFC6371].  = Please change /protection-switching management and/protection-switching = management/

5.       = page 8 sentence:  “The output ports = on which TRILL OAM message are sent are determined by the TRILL routing = function, which will only send on links that are in the up state and = have been incorporated into the local view of the campus = topology”  - Suggest

a.       = “The output ports on which TRILL OAM = messages are sent are determined by the TRILL routing function. The = TRILL Routing function will only send on links that are in the up state = and have been incorporated into the local view of the campus = topology”. 

6.       = Page 11 – [TRILLML] – is not listed = in the references –

7.       = Page 16.  Suggest changing 1st = sentence of paragraph into two parts.  /[RFC6325] and the Link = Header/[RFC6325]. The Link header”

8.       = Page 4.1.2.2 add at end of sentence 2 /section./ = section (4.1.2.1).

 

Sue = Hares

Reviewer

------=_NextPart_000_014F_01CE315A.F0815AF0-- From d3e3e3@gmail.com Thu Apr 4 19:06:56 2013 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 C78FE21F9665 for ; Thu, 4 Apr 2013 19:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGIvujPdkdNe for ; Thu, 4 Apr 2013 19:06:56 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB1C21F9644 for ; Thu, 4 Apr 2013 19:06:55 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id ef5so3271198obb.13 for ; Thu, 04 Apr 2013 19:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=BhM3TVwtSiATunsb3j6UVRRWDJsNDQQWqFdhBaH0Y48=; b=nHfKj0rxLxQvRb0y29JUeu7Tf68ZL7TaEu78Bgikaa5UEePS79soewXG3EOPN73d7k QJ1raCulqtvxAKkZLMk5xNCmaNrzol0re3CdyhfaSaYFUkg/TrKAsPpzfd2e31n8jAhf FIooL6hxoWAuwvqwHCCLZeBCcrWwOgL7WKPVXoitBNvX+y9YJe8k4K6Imdnyy/zzC1HI yrRwQpNuc7NA72z69e7fVkgi0b2n3dxx3DvxN+vXMWT7bUrql/vJTVYhJa2FlAcvZChE B/v28xAov3u1q9pFpDwdVmBRNFcGa8xXu3QlxOqOFMLh4bs7poljCenjSsVj0kxqyQ6W v+EA== X-Received: by 10.60.60.227 with SMTP id k3mr6424377oer.97.1365127615608; Thu, 04 Apr 2013 19:06:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.28.131 with HTTP; Thu, 4 Apr 2013 19:06:35 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 4 Apr 2013 22:06:35 -0400 Message-ID: To: Olen Stokes Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" Subject: Re: [trill] Review of draft-ietf-trill-oam-framework-01 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 02:06:56 -0000 Hi Olen, Thanks for promptly posting these comments. 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Apr 3, 2013 at 4:21 PM, Olen Stokes w= rote: > Based on a review of the subject document, please consider the following > comments: > > > > 1) Section 2.6 states that =93a CFM MEP resides in the "802.1Q Port VLAN > Processing" block=94 of Figure 2. I was not able to find a block with th= at > title in Figure 2. > > > > 2) Section 2.6 states that =93A TRILL OAM solution that conforms to this > framework=94 MAY support UP MEP=92s and MAY support DOWN MEP=92s on TRILL= physical > ports. I was unclear about the implications of these statements. Does t= hat > imply that a solution could be acceptable even though it does not support > either UP or DOWN MEP=92s? > > > > 3) Section 3.1 at the top of Page 16 states, =93The TRILL Header is as > specified in [RFC6325]=94. Should this paragraph include some discussion= or > reference to the TRILL Header as specified in the Fine Grained Labeling > (FGL) document, especially since the FGL document =93changes the descript= ion > of the TRILL Header=94 in its Section 2.2? > > > > 4) Section 3.3 states, =93The use of [802.1Q] CFM encoding format for th= e OAM > Message channel is one possible choice.=94 Given the amount of Y.1731 > terminology used in this document, it might be helpful to at least make s= ome > statement about the possibility of using Y.1731 formatting. I understand > that the formats are compatible, but there are some differences. > > > > 5) Section 3.3 references [TRILL-OAM] which is listed as > =93draft-tissa-trill-8021ag=94. This document is expired. Has it been r= eplaced > by =93draft-tissa-trill-oam-fm-01.txt=94? > > > > 6) Section 3.4 suggests =93using a reserved MAC address as the inner MAC= SA=94 > to identify a TRILL OAM packet. It is unclear to me how this is more > backwards compatible than using previously unused fields or bits in the > TRILL Header as suggested in the preceding paragraph. Is not the inner M= AC > SA used in some configurations for hashing at hops with equal-cost paths? > > > > 7) Section 4.1.2.2 describes Reverse Defect Indication (RDI). Given tha= t > Section 4.1.1 states that fault detection must be able to exercise each > equal-cost path individually, Section 4.1.2.2 should probably state that = RDI > must be able to identify on which equal-cost path the failure was detecte= d. > > > > 8) Section 4.2.1 discusses carrying =93test patterns as defined in > [RFC2544].=94 RFC 2544 is a substantial document but it does not contain= the > word =93pattern=94. Is this a reference to the frame formats in Appendix= C or > to some other section of the RFC? > > > > 9) Section 4.2.1.2 discusses an un-pruned tree and a campus wide diagnos= tic > VLAN. A campus wide diagnostic FGL is probably also required. > > > > 10) Section 4.2.2 discusses fault isolation. It would be helpful to incl= ude > a statement that fault isolation has to work for both known unicast and > multi-destination packets. > > > > As a general comment, Section 1.2 states that the document =93leverages > concepts and draws upon elements defined and/or used=94 in multiple exist= ing > OAM standards including 802.1ag CFM and Y.1731. The document contains a > mixture of terms from these two standards. For example, the Y.1731 term > Maintenance Entity Group (MEG) is used as opposed to the 802.1ag term > Maintenance Association (MA). However, the 802.1ag term Maintenance Poin= t > (MP) is used as opposed to the Y.1731 term Maintenance Entity (ME). It d= oes > not appear to affect the technical content but it is unclear why the > terminology is mixed. Some statement about the method used to determine > which terms to use might be helpful. > > > > Please let me know if you would like to discuss any of these items furthe= r. > > > > Cheers, > > Olen > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From d3e3e3@gmail.com Thu Apr 4 20:01:50 2013 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 2BBB421F9660 for ; Thu, 4 Apr 2013 20:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r01kDD05oT+I for ; Thu, 4 Apr 2013 20:01:49 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB8A21F9494 for ; Thu, 4 Apr 2013 20:01:49 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so3493976oag.25 for ; Thu, 04 Apr 2013 20:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=CrqB5uUa9GWYGZrxa5jfV+tzrOadV8r81nEzlbhJMog=; b=dYvp/Iuwoo2vVkc8Uiffl6q+w9aGqBg8qiNnyz2aUUnf+LinaxOxDSAW92QAco2+nT JMXKG3h6PiMFPcekrWZedVa3p7XKveZorponhjrM9O3YzP2KJ/J0BCp08Zzhdi3s+s6N ZiyNuJ+faeA70K49xHCEGllTVmJDJvccP3b/qQKVYu10/dyYc8EUIZC3Ie9KKSk1f7t3 UH3BfV/bk/e4NxK25aMtySoww7Xb+OU5kepVbyv0JAto9mz8FcFGazBr0VHmW4w6iB4P J3bZ7/SqU3q+MLSTI8a6fwLxWjXkQRHSqYUuB5pYH8741civ0OHraq4wnd3HDeklbT04 mnYg== X-Received: by 10.182.129.101 with SMTP id nv5mr6452380obb.56.1365130908740; Thu, 04 Apr 2013 20:01:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.28.131 with HTTP; Thu, 4 Apr 2013 20:01:28 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C1543@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0C1543@AZ-FFEXMB04.global.avaya.com> From: Donald Eastlake Date: Thu, 4 Apr 2013 23:01:28 -0400 Message-ID: To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: TRILL Working Group Subject: Re: [trill] my comments on draft-ietf-trill-oam-framework X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 03:01:50 -0000 Hi Dan, Thanks for your prompt comments. 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Apr 4, 2013 at 4:56 AM, Romascanu, Dan (Dan) w= rote: > Hi, > > Here are my comments on draft-ietf-trill-oam-framework-01.txt > > I have divided them in Technical and Editorial. > > > Technical > > T1. The references are broken in many ways. Many references in the text a= re not included in the References sections - runing id-nits shows this imme= diately. Listed references point to documents that do not exist [TRILL-OAM]= , [TRILL-IP]. > > T2. I have mixed feelings about the usage of RFC 2119 capitalized keyword= s in this document. My preference would be to drop them completely, especia= lly as the document is targeting Informational status. If they stay, we nee= d to carefully review the usage, right now it's quite inconsistent. > > T3. The document does not include a section on operational and manageabil= ity considerations. I believe that this is necessary, and this section shou= ld include as a minimum: > - what parameters need to be configured on Rbridges in order to activate = TRILL OAM - activation of specific OAM functions, periodicity of OAM messag= es, activation of synthetic traffic (periodic or on demand) > - how are these parameters configured? Are there recommended default valu= es? > - how are results of Performance Management used or retrieved? > > T4. Several terms are used according to the terminology defined in RFC 69= 05 - Section, Flow, Connectivity, Continuity Indication, etc. I suggest to = mention this in Section 1.2 > > T5. Are the references to L2VPN and MPLS-TP (and the respective [RFC6136]= and [RFC6371]) in Section 1.2 needed at all? I do not see these technologi= es mentioned in any other part of the document, and if there is no relevant= relationship with the OAM functions on these layers I would suggest to dro= p these. > > T6. In 2.4 we have an example why using 2119 capitalized keywords is prob= lematic: > >> When considering multi-domain scenarios, the following > rules must be followed: TRILL OAM domains MUST NOT overlap, but MUST > either be disjoint or nest to form a hierarchy (i.e. a higher > Maintenance Domain MAY completely engulf a lower Domain). > > If I was to chose, I would prefer not to use capitalization, or use capit= alization only for the first 'must' which is not capitalized in the text. '= MUST either ...' is a strange combination. One may argue that nesting is a = form of overlapping, and actually 'MUST not overlap' is should rather be 'M= UST not partially intersect'. > > T.7 In Section 3.1: > >> Additionally > methods must be provided to prevent OAM packets from being > transmitted out as native frames. > > If capitalized RFC 2119 keywords are to be kept, this 'must' must be a 'M= UST' (because of the critical impact on the bits on wire) > > T.8 In section 3.2: > >> When running OAM functions over Test Flows, the TRILL OAM should > provide a mechanism for discovering the flow entropy parameters by > querying the RBridges dynamically. > > I am wondering why this is a 'should' and not a 'must'. Are there any exc= eption cases? > > T.9 Section 3.4: > >> RBridges must be able to identify OAM messages that are destined to > them, either individually or as a group, so as to properly process > those messages. > > OK - so a method must be in place. > > It may be possible to use a combination of one of the unused fields > or bits in the TRILL Header and the OAM EtherType to identify TRILL > OAM messages. > > ' one of the unused fields or bits in the TRILL Header' - which ones? Are= we talking about an update to RFC 6395? Where is this defined? > > Is the 'and' between the TRILL header combinations and the OAM EtherType = really an 'and' or rather an 'or'? 'OAM EtherType' is rather 'TRILL OAM Eth= erType'? > > [RFC6325] does not specify any method of identifying OAM messages. > Hence, for backwards compatibility reasons, TRILL OAM solutions must > provide methods to identify OAM messages through the use of well- > known patterns in the Flow Entropy field; for e.g., by using a > reserved MAC address as the inner MAC SA. > > Is this an alternate method to the ones described in the previous paragra= ph? Then, the 'must' is probably rather a 'may' or should'. What ' reserved= MAC address' are we talking about? Is this something that we should ask fr= om the IEEE RAC? Where is this specified? > > T.10 Section 4.1.1 - What does 'Period mis-configuration' mean? Is this a= bout the periodicity of the OAM messages? If so this defect is about OAM co= nfiguration, not about continuity check. If it's something different, pleas= e explain or provide a reference. > > T.11 Section 4.2: > >> On-demand fault management functions are initiated manually by the > network operator and continue for a time bound period. > > The last part of the statement is not always true, as some fault manageme= nt functions may be one-time actions or tests. > > T.12 Section 5. - Performance Management - I am not thrilled about this s= ection at all. Note that RFC 6905 talks about Performance Monitoring (not M= anagement) and it's not a mandatory function. Terminology aside, I dislike = generating synthetic traffic in order to measure packet loss - how much tra= ffic? Limiting this seems mandatory. Who compares what was sent with what w= as received? 5.2 talks about hardware-based time-stamping to measure Packe= t Delay. This implies some kind of clocks synchronization between RBridges.= What are the requirements? > > T.13 The Security Considerations section should be more explicit on what = 'exploitation of the OAM message channel' means. Specifically the threats r= elated to overloading the network and the Rbridges with OAM messages should= be mentioned, as well as the impact of interrupting the OAM services. > > > > Editorial > > E1. In Section 1: > >> Some > characteristics of a TRILL network that are different from Ethernet > bridging ... > > s/Ethernet bridging/IEEE 802.1 bridging/ > > E2. Check for completeness of the acronyms list in section 1.1. For examp= le ECMP is used a few times in the document, but not listed here and never = expanded. > > E3. In several places (2.1.3 is the first) I found 'For e.g.,'. I believe= that this is a pleonasm, either use 'For example', or just e.g. > > E4. In section 2.2: s/TRILL OAM processing can be modeled as a layer/TRIL= L OAM processing can be represented as a layer/ > > E5. In Section 2.3: > >> Network OAM mechanisms provide fault and performance management > functions in the context of a representative 'test' VLAN or fine- > grained label [TRILL-FGL]. > > What does 'representative' mean here? > > E6. 'faults in connectivity or performance' - 'connectivity faults and pe= rformance degradation' is probably better > > E7. In Section 2.6: > >> MEPs are the active components of TRILL OAM: MEPs source TRILL OAM > messages proactively or on-demand based on operator invocation. > > The usage of the term 'proactively' seems to me to be incorrect. I would = rather use 'periodically'. Also s/operator invocation/operator configuratio= n actions/ > > > > E8. In Section 2.6: > >> - MUST support the UP MEP function on a TRILL virtual port (to > support OAM functions on Sections) > > I would add for clarity inside the brackets '... as defined in 'rfc6905' > > Regards, > > Dan > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From dromasca@avaya.com Sun Apr 7 08:43:47 2013 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 B69FF21F848B for ; Sun, 7 Apr 2013 08:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYvh6MvKjlkh for ; Sun, 7 Apr 2013 08:43:46 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 56A9E21F8203 for ; Sun, 7 Apr 2013 08:43:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHpXMFHGmAcF/2dsb2JhbABEgma/Tn8Wc4IfAQEBAQIBEig1Dw0BFRUUQiYBBBsUBodrBgGgN4QqnEOOY4MXYQOTAIlailGDCIIn X-IronPort-AV: E=Sophos;i="4.84,760,1355115600"; d="scan'208";a="5938282" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Apr 2013 11:43:39 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Apr 2013 11:41:01 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Sun, 7 Apr 2013 11:43:38 -0400 From: "Romascanu, Dan (Dan)" To: "trill@ietf.org" Thread-Topic: comments on draft-tissa-trill-oam-fm-01.txt Thread-Index: Ac4zpqqD0+chBGnnQmuvhAd4wMWHdw== Date: Sun, 7 Apr 2013 15:43:36 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C3C25@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [trill] comments on draft-tissa-trill-oam-fm-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 15:43:48 -0000 Hi, I read draft-tissa-trill-oam-fm-01.txt. It needs a lot of editorial cleanin= g, both in organization of the material and details of editing. The princip= al challenge is the separation of work between the IETF and IEEE 802.1 - as= much of what is described in this I-D is an extension of the IEEE 802.1Q C= FM OAM. We need a clear separation of what is defined in TRILL and what is = expected from the IEEE 802.1 and this needs to receive positive acknowledgm= ent from the IEEE 802.1 WG in order to make progress.=20 Please find below a set of comments divided into Technical and Editorial. P= lease address the issues raised below in the coming reviews.=20 Technical T1. In Figure 1 the TRILL Header is said to be 8 bytes, while the explanati= on speaks about 'Minimum of 8 bytes when the Extended Header is not include= d'. If there are reasons to believe that the Extended Header may be used fo= r OAM Messages this needs to be specified clearly, including the cases wher= e this happens. The information in Section 3.1 and Figure 5 of draft-ietf-t= rill-oam-framework-01 would also need to be corrected. However this would b= e problematic, as the OAM EtherType is expected at a deterministic offset f= rom the TRILL Header. T2. In section 3:=20 > This document specifies using the EtherType allocated for 802.1ag for this purpose. Is this what was agreed with IEEE 802.1? Is this true also if the backwards= compatibility method in 3.3 is used? Further in section 16 I see:=20 > 16.1. IEEE Allocation Considerations The IEEE 802.1 Working Group is requested to allocate a separate opcode and TLV space within 802.1QCFM messages for TRILL purpose. Did you discuss with IEEE 802.1 how this allocation will be performed. Does= this need to be included in an update of IEEE 802.1Q? T3. In Section 5:=20 > We propose to augment the [8021Q] MIB to add the TRILL specific information. Figure 6, below depicts the augmentation of the CFM MIB to add the TRILL specific Flow Entropy. The augmentation of the MIB as described in this section is a challenge, as= MIB development is now under the responsibility of the IEEE 802.1 WG. Here= also there would be a need to cooperate closely with the IEEE 802.1 WG - w= as this agreed?=20 T4. Section 7 seems to contain information that is not related to the bits = on the wire but to the internal implementation. Should not this be moved to= an appendix? =20 T5. Section 9.1:=20 > o MD-L: Maintenance Domain Level (3 bits). Identifies the maintenance domain level. For TRILL, this MAY be always set to zero. However, in multilevel TRILL, backbone MAY be of a different MD-LEVEL. (Please refer to [8021Q] for the definition of MD-Level) What does 'MAY be always' mean?=20 T6. Section 9.1:=20 > o Version: Indicates the version (5 bits). As specified in [8021Q]. Is this document an update of the version?=20 E1. There is more work to put references in order. I suggest to run idnits = before submission, this immediately will point on most of the references-re= lated problems. Currently idnits points to the following problems:=20 Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------= - (See RFCs 3967 and 4897 for information about using normative referenc= es to lower-maturity documents in RFCs) =3D=3D Missing Reference: 'TRLLOAMMIB' is mentioned on line 977, but not defined 'raise SNMP TRAPs [TRLLOAMMIB] as Alarms when a connectivity failu...' =3D=3D Unused Reference: 'RFC5226' is defined on line 2039, but no explic= it reference was found in the text '[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an I.= ..' =3D=3D Outdated reference: draft-ietf-trill-oam-req has been published as= RFC 6905 =20 E2. In the Introduction section:=20 > The OAM message channel, if defined properly, can be shared between different technologies. A common OAM channel allows a uniform user experience for the customers, savings on operator training, re-use of software code base and faster time to market. This sounds a little bit 'marketing'. I would rather replace this with a sh= orter definition and explanation about the role of the OAMA channel of ensu= ring consistency between message formats whatever transport TRILL runs on. = Also avoid to say 'if defined properly' - there is no reason not to define = properly in IETF documents :-) E3. Also in the Introduction:=20 > The ITU-T Y.1731 standard utilizes the same messaging format as [8021Q] and OAM messages where applicable. Probably better:=20 > The ITU-T Y.1731 [REFERENCE] standard utilizes the same messaging format = as [8021Q] and reuses OAM messages where applicable. Note the need to provide a reference to Y.1731 E4. The acronyms section is incomplete - for example ECMP, ISS should be ad= ded, probably more E5. Section 3.4 (and other sections in the document) - avoid the 'We propo= se' language - this is a specification, not just a proposal Also here s/the implementation is OAM capable but utilize backwards compati= ble method defined in section 3.3/the implementation is OAM capable and uti= lizes the backwards compatible method defined in section 3.3/ E6. Section 16.2 - the different registries and sub-registries maintained b= y IANA need to point back to specific sections in the document, also need t= o use consistent naming in these sections and here.=20 E7. [8021Q] must be a normative reference.=20 Regards, Dan From d3e3e3@gmail.com Sat Apr 13 08:01:03 2013 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 55C4221F86FA for ; Sat, 13 Apr 2013 08:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iKV3BrQgtLC for ; Sat, 13 Apr 2013 08:01:02 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B886621F869A for ; Sat, 13 Apr 2013 08:01:02 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wn14so3069278obc.4 for ; Sat, 13 Apr 2013 08:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=qr/NeyKrpbeapkdbbTKL2T3PbdMQlOzaAw1/Gk9E0AQ=; b=qhC2wNBa8yr9+VTqCYRhtodpihp1za/nmOov8mi2A6UD8tcYgUGMuz6ezx0ANXswJy FTJJPm3fiiYvZw+0McKEDm0gWyRZfWcwXHen6Yp19z4bd96QADCOUJ0goSA/8m+vWzOY UTiU0lpkNqMZnacrupXRwo2isxCGf4/lwVNwsdsDLcrzKYvMpEMIFNwoNSC5N/Wkia4s TEgwxFAkxCjqeKeEz0qxgGNw5OT/YeRUnTOQAXPAkSUVj1le7pY8i1vXHpiJmzT6/nZu s2chyUJwJ0Ug5T+5SawQRZpG+D1AGan0+hXrS05MFOkNDXCkA8uYGKynZdrd6EdAl9O9 uX/g== X-Received: by 10.60.146.131 with SMTP id tc3mr5312526oeb.29.1365865262308; Sat, 13 Apr 2013 08:01:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Sat, 13 Apr 2013 08:00:42 -0700 (PDT) From: Donald Eastlake Date: Sat, 13 Apr 2013 11:00:42 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] Draft minutes from Orlando posted X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 15:01:03 -0000 Draft minutes of the TRILL WG meeting in Orlando have been posted. See http://www.ietf.org/proceedings/86/minutes/minutes-86-trill Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From ssalam@cisco.com Wed Apr 17 10:33:27 2013 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 A6DBA21F8976 for ; Wed, 17 Apr 2013 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YVmD0hsuj9a for ; Wed, 17 Apr 2013 10:33:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 542D921F896C for ; Wed, 17 Apr 2013 10:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17291; q=dns/txt; s=iport; t=1366220006; x=1367429606; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=tZoWQUtfUtzvKRsahFEyKNCSmbQbuZ+crYEgVJpfmBQ=; b=dCd/Qjtx9ZPRilFLg8EgqZLx9tA8JOL0GF98NmWiLgVE0y6y1VnY82BE 2w2DZ7vEgRRSewL3vexn0rERcEzFMwCZljzicprAFkebly3FnpeqQD14e QSX/ElNNBFsnT7h+3AhzAC5qCRxx2fivp90Q1UKstTpvi44EqhucTBqQr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAK7bblGtJXG8/2dsb2JhbABQgkIjITbARIEEFnSCHwEBAQQtTBIBCA4DAwECCx0oERQJCAEBBAENBQgTh2cDDwGzdA2JXYxHgiIgEQcGgl9hA5UjjVuFHIMLgig X-IronPort-AV: E=Sophos;i="4.87,495,1363132800"; d="scan'208,217";a="199708904" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 17 Apr 2013 17:33:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3HHXPbB008670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 17:33:25 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 12:33:25 -0500 From: "Samer Salam (ssalam)" To: Susan Hares , "'Donald Eastlake'" , "sam.aldrin@gmail.com" , "Tissa Senevirathne (tsenevir)" Thread-Topic: TRILL OAM framework review (draft-ietf-trill-oam-framework-01) Thread-Index: Ac4xfGWYe5JQyIDFRvKvLvCLF+llFgKBH6OA Date: Wed, 17 Apr 2013 17:33:25 +0000 Message-ID: <8F25FF8EA49D164EBE5F1B5AD33F3BC9123A0CC7@xmb-aln-x13.cisco.com> In-Reply-To: <014e01ce317c$778f7880$66ae6980$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [161.44.210.96] Content-Type: multipart/alternative; boundary="_000_8F25FF8EA49D164EBE5F1B5AD33F3BC9123A0CC7xmbalnx13ciscoc_" MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] TRILL OAM framework review (draft-ietf-trill-oam-framework-01) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 17:33:27 -0000 --_000_8F25FF8EA49D164EBE5F1B5AD33F3BC9123A0CC7xmbalnx13ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Sue, Thank you for the review comments. We will incorporate them in the updated = revision of the draft. Best Regards, Samer From: Susan Hares > Date: Thursday, April 4, 2013 2:36 PM To: 'Donald Eastlake' >, "sam.ald= rin@gmail.com" >, "Tissa Senevirathne (tsenevir)" >, "Samer Salam (ssalam)" > Cc: "trill@ietf.org" > Subject: TRILL OAM framework review (draft-ietf-trill-oam-framework-01) Donald, Sam, Tissa, and Samer: General comments: Nicely written and enjoyable to read after all of the deb= ates. Two technical issues concern me as underspecified in the document: 1. Section 2.4 has maintenance Domains which can be =93nested to form= a hierarchy=94 (p. 12, para. 1) a. The nesting of Domains seems to be underspecified in this draft an= d it is unclear exactly how these domains would nest. b. There are mechanism for finding the hierarchy (Domain name and main= tenance level (numeric ID), but it is not clear from the document how this = works. 2. Section 4.2.1.2 =96 Multicast prevention of reply storms from over= whelming the initiating RBridge. a. Staggering or Jittering responses may or may not protect the init= iating RBridge b. Again =96 this may be right or wrong, but the lack of additional de= tails concerns me whether this solution has been written down correctly. I= suspect from Tissa=92s comments that it is working. Editorial comments: 1. Replace TRILL-OAM-REQ with RFC6905 in all document, 2. p. 4 TRILL in para. 2 has an extra space =93- TRILL=94 to =93-= TRILL=94 3. use of =93multipathing=94 =96 has this been defined elsewhere? =96= it should be defined or referenced, 4. page 6. Para. 2 beginning [RFC6371]. Please change /protection-sw= itching management and/protection-switching management/ 5. page 8 sentence: =93The output ports on which TRILL OAM message a= re sent are determined by the TRILL routing function, which will only send = on links that are in the up state and have been incorporated into the local= view of the campus topology=94 - Suggest a. =93The output ports on which TRILL OAM messages are sent are deter= mined by the TRILL routing function. The TRILL Routing function will only s= end on links that are in the up state and have been incorporated into the l= ocal view of the campus topology=94. 6. Page 11 =96 [TRILLML] =96 is not listed in the references =96 7. Page 16. Suggest changing 1st sentence of paragraph into two part= s. /[RFC6325] and the Link Header/[RFC6325]. The Link header=94 8. Page 4.1.2.2 add at end of sentence 2 /section./ section (4.1.2.1)= . Sue Hares Reviewer --_000_8F25FF8EA49D164EBE5F1B5AD33F3BC9123A0CC7xmbalnx13ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Sue,

Thank you for the review comments. We will incorporate them in the upd= ated revision of the draft.

Best Regards,
Samer

From: Susan Hares <shares@ndzh.com>
Date: Thursday, April 4, 2013 2:36 = PM
To: 'Donald Eastlake' <d3e3e3@gmail.com>, "sam.aldrin@gmail.com" <sam.aldrin@gmail.com>, "Tissa Senevir= athne (tsenevir)" <tsenevir@cisco.= com>, "Samer Salam (ssalam)" <ssalam@cisco.com>
Cc: "trill@ietf.org" <tri= ll@ietf.org>
Subject: TRILL OAM framework review= (draft-ietf-trill-oam-framework-01)

Donald, Sam, Tissa, and Samer:

 

General comments: Nicely written and enjoyable to re= ad after all of the debates.

 

Two technical issues concern me as underspecified in= the document:

 

1.    &nbs= p;  Section 2.4 has maintenance Domains which can b= e =93nested to form a hierarchy=94 (p. 12, para. 1)

a.       The nesting of Domains seems to be underspecifi= ed in this draft and it is unclear exactly how these domains would nest.

b.      There are mechanism for finding the hierarchy (= Domain name and maintenance level (numeric ID), but it is not clear from th= e document how this works.

2.    &nbs= p;  Section 4.2.1.2 =96 Multicast prevention of rep= ly storms from overwhelming the initiating RBridge.

a.       Staggering or Jittering responses  may or = may not protect the initiating RBridge

b.      Again =96 this may be right or wrong, but the l= ack of additional details concerns me whether this solution has been writte= n down correctly.  I suspect from Tissa=92s comments that it is workin= g.

 

Editorial comments:

1.    &nbs= p;  Replace TRILL-OAM-REQ with RFC6905 in all docum= ent,

2.    &nbs= p;  p. 4 TRILL in para. 2 has an extra space =93-&n= bsp;    TRILL=94 to =93-TRILL=94

3.    &nbs= p;  use of =93multipathing=94 =96 has this been def= ined elsewhere? =96 it should be defined or referenced,

4.    &nbs= p;  page 6. Para. 2 beginning [RFC6371].  Plea= se change /protection-switching management and/protection-switching managem= ent/

5.    &nbs= p;  page 8 sentence:  =93The output ports on w= hich TRILL OAM message are sent are determined by the TRILL routing functio= n, which will only send on links that are in the up state and have been inc= orporated into the local view of the campus topology=94  - Suggest

a.       =93The output ports on which TRILL OAM messages= are sent are determined by the TRILL routing function. The TRILL Routing f= unction will only send on links that are in the up state and have been inco= rporated into the local view of the campus topology=94. 

6.    &nbs= p;  Page 11 =96 [TRILLML] =96 is not listed in the = references =96

7.    &nbs= p;  Page 16.  Suggest changing 1st = sentence of paragraph into two parts.  /[RFC6325] and the Link Header/= [RFC6325]. The Link header=94

8.    &nbs= p;  Page 4.1.2.2 add at end of sentence 2 /section.= / section (4.1.2.1).

 

Sue Hares

Reviewer

 --_000_8F25FF8EA49D164EBE5F1B5AD33F3BC9123A0CC7xmbalnx13ciscoc_-- From ssalam@cisco.com Wed Apr 17 10:37:57 2013 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 9418221F871C for ; Wed, 17 Apr 2013 10:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q70BE9mxaHUp for ; Wed, 17 Apr 2013 10:37:56 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0D821F8652 for ; Wed, 17 Apr 2013 10:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7723; q=dns/txt; s=iport; t=1366220276; x=1367429876; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=lYEimEQ7PMa/+HbpqjHJk0z+IgDfUh0FBjehYjDQKOc=; b=M1WmZn/va8UacPwSzutgrPZWVadze4IsQR47sL3QHwsdMnA/tMuUw4FK hQvaeesEiAV7r/NtCwQ78ULXDEnTn3ESZ2RwTMnvWFFflCk7J5xN1OVw/ BgswI0cl5esBpiRpF22mrFaqc7GQrFbj3VaUZSedLjsDidRs1HHxzB9Ie k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAO/cblGtJXG8/2dsb2JhbABGCoJlITbARIEEFnSCIQEEAQEBNzQEGQEIIhQ3CyUBAQQBEggTh3kBC71VBI1egQs4gmVhA5M5lGGDC4Io X-IronPort-AV: E=Sophos;i="4.87,495,1363132800"; d="scan'208";a="199873276" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 17 Apr 2013 17:37:55 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3HHbtK6014492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 17:37:55 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 12:37:55 -0500 From: "Samer Salam (ssalam)" To: "Romascanu, Dan (Dan)" , TRILL Working Group Thread-Topic: [trill] my comments on draft-ietf-trill-oam-framework Thread-Index: Ac4xEkkxNdzOrNdAThmijtqtgZEQwgKbzx8A Date: Wed, 17 Apr 2013 17:37:54 +0000 Message-ID: <8F25FF8EA49D164EBE5F1B5AD33F3BC9123A0CE2@xmb-aln-x13.cisco.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C1543@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [161.44.210.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <7FC8254F651CA64C975E8E97B0CD2735@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [trill] my comments on draft-ietf-trill-oam-framework X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 17:37:57 -0000 Hi Dan, Thank you for your comments, we will incorporate them into the updated draft. Best Regards, Samer On 13-04-04 1:56 AM, "Romascanu, Dan (Dan)" wrote: >Hi, > >Here are my comments on draft-ietf-trill-oam-framework-01.txt > >I have divided them in Technical and Editorial. > > >Technical > >T1. The references are broken in many ways. Many references in the text >are not included in the References sections - runing id-nits shows this >immediately. Listed references point to documents that do not exist >[TRILL-OAM], [TRILL-IP]. > >T2. I have mixed feelings about the usage of RFC 2119 capitalized >keywords in this document. My preference would be to drop them >completely, especially as the document is targeting Informational status. >If they stay, we need to carefully review the usage, right now it's quite >inconsistent.=20 > >T3. The document does not include a section on operational and >manageability considerations. I believe that this is necessary, and this >section should include as a minimum: >- what parameters need to be configured on Rbridges in order to activate >TRILL OAM - activation of specific OAM functions, periodicity of OAM >messages, activation of synthetic traffic (periodic or on demand) >- how are these parameters configured? Are there recommended default >values?=20 >- how are results of Performance Management used or retrieved? > >T4. Several terms are used according to the terminology defined in RFC >6905 - Section, Flow, Connectivity, Continuity Indication, etc. I suggest >to mention this in Section 1.2 > >T5. Are the references to L2VPN and MPLS-TP (and the respective [RFC6136] >and [RFC6371]) in Section 1.2 needed at all? I do not see these >technologies mentioned in any other part of the document, and if there is >no relevant relationship with the OAM functions on these layers I would >suggest to drop these. > >T6. In 2.4 we have an example why using 2119 capitalized keywords is >problematic: > >> When considering multi-domain scenarios, the following > rules must be followed: TRILL OAM domains MUST NOT overlap, but MUST > either be disjoint or nest to form a hierarchy (i.e. a higher > Maintenance Domain MAY completely engulf a lower Domain). > >If I was to chose, I would prefer not to use capitalization, or use >capitalization only for the first 'must' which is not capitalized in the >text. 'MUST either ...' is a strange combination. One may argue that >nesting is a form of overlapping, and actually 'MUST not overlap' is >should rather be 'MUST not partially intersect'. > >T.7 In Section 3.1: > >> Additionally > methods must be provided to prevent OAM packets from being > transmitted out as native frames. > >If capitalized RFC 2119 keywords are to be kept, this 'must' must be a >'MUST' (because of the critical impact on the bits on wire) > >T.8 In section 3.2: > >> When running OAM functions over Test Flows, the TRILL OAM should > provide a mechanism for discovering the flow entropy parameters by > querying the RBridges dynamically. > >I am wondering why this is a 'should' and not a 'must'. Are there any >exception cases?=20 > >T.9 Section 3.4:=20 > >> RBridges must be able to identify OAM messages that are destined to > them, either individually or as a group, so as to properly process > those messages. > >OK - so a method must be in place. > > It may be possible to use a combination of one of the unused fields > or bits in the TRILL Header and the OAM EtherType to identify TRILL > OAM messages.=20 > >' one of the unused fields or bits in the TRILL Header' - which ones? Are >we talking about an update to RFC 6395? Where is this defined? > >Is the 'and' between the TRILL header combinations and the OAM EtherType >really an 'and' or rather an 'or'? 'OAM EtherType' is rather 'TRILL OAM >EtherType'?=20 > > [RFC6325] does not specify any method of identifying OAM messages. > Hence, for backwards compatibility reasons, TRILL OAM solutions must > provide methods to identify OAM messages through the use of well- > known patterns in the Flow Entropy field; for e.g., by using a > reserved MAC address as the inner MAC SA. > >Is this an alternate method to the ones described in the previous >paragraph? Then, the 'must' is probably rather a 'may' or should'. What ' >reserved MAC address' are we talking about? Is this something that we >should ask from the IEEE RAC? Where is this specified? > >T.10 Section 4.1.1 - What does 'Period mis-configuration' mean? Is this >about the periodicity of the OAM messages? If so this defect is about OAM >configuration, not about continuity check. If it's something different, >please explain or provide a reference. > >T.11 Section 4.2:=20 > >> On-demand fault management functions are initiated manually by the > network operator and continue for a time bound period. > >The last part of the statement is not always true, as some fault >management functions may be one-time actions or tests. > >T.12 Section 5. - Performance Management - I am not thrilled about this >section at all. Note that RFC 6905 talks about Performance Monitoring >(not Management) and it's not a mandatory function. Terminology aside, I >dislike generating synthetic traffic in order to measure packet loss - >how much traffic? Limiting this seems mandatory. Who compares what was >sent with what was received? 5.2 talks about hardware-based >time-stamping to measure Packet Delay. This implies some kind of clocks >synchronization between RBridges. What are the requirements? > >T.13 The Security Considerations section should be more explicit on what >'exploitation of the OAM message channel' means. Specifically the threats >related to overloading the network and the Rbridges with OAM messages >should be mentioned, as well as the impact of interrupting the OAM >services.=20 > >=20 > >Editorial > >E1. In Section 1:=20 > >> Some > characteristics of a TRILL network that are different from Ethernet > bridging ... > >s/Ethernet bridging/IEEE 802.1 bridging/ > >E2. Check for completeness of the acronyms list in section 1.1. For >example ECMP is used a few times in the document, but not listed here and >never expanded.=20 > >E3. In several places (2.1.3 is the first) I found 'For e.g.,'. I believe >that this is a pleonasm, either use 'For example', or just e.g. > >E4. In section 2.2: s/TRILL OAM processing can be modeled as a >layer/TRILL OAM processing can be represented as a layer/ > >E5. In Section 2.3: > >> Network OAM mechanisms provide fault and performance management > functions in the context of a representative 'test' VLAN or fine- > grained label [TRILL-FGL]. >=20 >What does 'representative' mean here? > >E6. 'faults in connectivity or performance' - 'connectivity faults and >performance degradation' is probably better > >E7. In Section 2.6: > >> MEPs are the active components of TRILL OAM: MEPs source TRILL OAM > messages proactively or on-demand based on operator invocation. > >The usage of the term 'proactively' seems to me to be incorrect. I would >rather use 'periodically'. Also s/operator invocation/operator >configuration actions/ > > > >E8. In Section 2.6: > >> - MUST support the UP MEP function on a TRILL virtual port (to > support OAM functions on Sections) > >I would add for clarity inside the brackets '... as defined in 'rfc6905' > >Regards, > >Dan > >_______________________________________________ >trill mailing list >trill@ietf.org >https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Mon Apr 22 19:40:26 2013 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 5952E21E80B0 for ; Mon, 22 Apr 2013 19:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeFRdjA4ubcS for ; Mon, 22 Apr 2013 19:40:25 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 93D8D21F9298 for ; Mon, 22 Apr 2013 19:40:25 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id dn14so116905obc.41 for ; Mon, 22 Apr 2013 19:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=lz6Pe3f09tYFPLIT/401FPdFpi7yD7M9I3kdi6nYLeM=; b=CmPyhQuSjAcy3Br8nfV5f8NntcuPfUerPfmjSOyIano8u6ePtY5+T8ftF7CKlJ4wGC NHfBNvgo+l18/Yq/xefrZmiyzZZGugJOVNi1Zj/8Lpj+gmAqeIOm9rRixDgmm6qSgbFM wiOdvyjYDgMPhqu0L8BA+ZzTo0bP0woIjHY3OfOQSh4HAMYb26lHQHLvfyVhujIwjtDB TTSnQx5RyM5O9Xxe3ud+CfbI6VUgEWgz5YGhBW6kagL7p/0AenK5Bw9gsz0dOuQ4A+9g JDQjU1EbCG34WxOF9HVyVOWT1MyPlzmkxmBxO7Oj8MVoGqwBotvRPDK9haG/1wWINUzg 6t6A== X-Received: by 10.182.134.230 with SMTP id pn6mr15864627obb.19.1366684825182; Mon, 22 Apr 2013 19:40:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Mon, 22 Apr 2013 19:40:05 -0700 (PDT) From: Donald Eastlake Date: Mon, 22 Apr 2013 22:40:05 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] IPR Disclosure Requirements - Please READ & NOTE X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 02:40:26 -0000 The following is a good reminder about the IETF IPR policy patterned after a message that Kathleen Moriarty sent to the MILE WG in August 2012 and one that was recently sent to the DHC WG. Dear TRILL WG: As TRILL WG chairs, we would like to minimize or hopefully even eliminate late disclosures relating to documents under consideration within the TRILL WG. So you might see us send "reminder" messages in the future to authors or to the TRILL WG email list as a whole, asking people whether they know of Intellectual Property Rights (IPR) relating to specific documents. In order to comply with IETF processes and avoid unnecessary delays, document authors and contributors to our discussions in the TRILL WG are asked to pay attention to these messages. Please note that these messages are only reminders of existing IETF policy, and we are all bound by that policy even in the absence of such reminder messages. Everyone who participates in the IETF Standards Process (whether by posting to mailing lists, authoring documents, attending IETF meetings, or in other ways) needs to be aware of the IETF rules with regard to IPR. These rules are described in BCP 79 and can be referenced through http://www.ietf.org/ipr/policy.html. In addition, online tools for filing IPR disclosures can be found at http://www.ietf.org/ipr/file-disclosure. Finally, existing disclosures can be searched online at https://datatracker.ietf.org/ipr/search/. Also note that these are personal requirements applying to all IETF participants as individuals, and that these requirements also apply to all participants in the TRILL WG. Disclosures are required on individual submissions, as soon as practical after the -00 version... not just on working group documents. There are many people who think it's okay to disclose only after adoption, and everyone needs to be reminded that it's not. Thanks, Donald & Erik (TRILL WG Co-chairs) From jon.hudson@gmail.com Wed Apr 24 00:42:43 2013 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 6973B21F8FA4 for ; Wed, 24 Apr 2013 00:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYJVeLaJhl+j for ; Wed, 24 Apr 2013 00:42:42 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id A82BC21F8F4D for ; Wed, 24 Apr 2013 00:42:42 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id l29so1365488iag.0 for ; Wed, 24 Apr 2013 00:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=4b5LJUYLnm1iOgsZC9NhzR+E6TNNR8ILvT4wa6XloPs=; b=AEejhdDIwXsurKJQ1r6l3735Gbuy/0MC52GgduA5KiCEnw/h45fKE+puNilRbMQtn5 VBc3DEfmLIfD0G3IirFi8ZrMj9fWAnlBLyncuoY1L2q6w3t13q9Weo8kZnAmHCZNXXca S9aP9/7saGkL9Ic7+1yTONjHYKdg1FiuPLWZXgA3lCqe58DegU8W9+H2t4gdyYzjvJiH 0Ogc0OMTQsbHrr9oLE8Gr9DLFRuV/ewKqxDmT1/XfSxWYkE5s0aTrpdWpjq6RwtWoWey KOHUo6wWqZ8om5hWiyKrloDiLEpQU7qRN8P3FIFjAduUFEt/OeZlOjTOI0010xdXMSIK f5Xg== MIME-Version: 1.0 X-Received: by 10.50.93.3 with SMTP id cq3mr13557570igb.70.1366789362175; Wed, 24 Apr 2013 00:42:42 -0700 (PDT) Received: by 10.50.41.1 with HTTP; Wed, 24 Apr 2013 00:42:42 -0700 (PDT) Date: Wed, 24 Apr 2013 00:42:42 -0700 Message-ID: From: Jon Hudson To: Linda Dunbar , Donald Eastlake , Radia Perlman , igor@yahoo-inc.com Content-Type: multipart/alternative; boundary=047d7b2e3e006aaadc04db16722a Cc: "trill@ietf.org" Subject: [trill] Edge Directory Assistance Framework draft-ietf-trill-directory-framework-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 07:42:43 -0000 --047d7b2e3e006aaadc04db16722a Content-Type: text/plain; charset=ISO-8859-1 Greetings Authors! I am the Document Shepard for you draft. Initial review of your draft brings up three initial small issues and one small suggestion (1) Acronyms that are not common IETF acronyms need to be spelled out on first use in the Abstract and Introduction. (TRILL is spelled out on second use in the abstract but there are others not spelled out at all.) (2) The list of acknowledgements should include Sam Aldrin and Yizhou Li who did reviews. (3) A light editing pass should be done by someone who is a native English speaker to add articles and the like so it reads more smoothly.Some statements are a wee bit awkward. Just in the paragraph below "...where VMs migrates" needs to be either where a VM migrates or where VMs migrate. (4) Just a suggestion: the last paragraph in section 3.1 ( lovely ascii pictures by the way) - In an environment where VMs migrates, there is higher chance of cached information becoming invalid, causing traffic to be black-holed by the ingress RBridge, that is, persistently sent to the wrong egress RBridge. If VMs do not flood gratuitous ARP/ND or VDP [802.1Qbg] messages upon arriving at new locations, the ingress nodes might not have MAC entries for the MAC of the newly arrived VMs, causing unknown address flooding. It may be worth noting that the issues with reliance on the gratuitous ARP is exacerbated by the fact that individual implementations in the field vary, and even between product lines in the same vendor you will different timers as to how long it takes for a switch to act on a gratuitous arp. The inconsistency this creates is so troublesome I have worked in some shops that flat never relied on gratuitous ARPs for anything. Now since this amounts to implementation issues, and not any issues with 802.1bg, it may not be worth mentioning. However it is the first thing I think of when I think of the value learning by directory would bring me in a datacenter. Just a suggestion, 4 is not a blocking issue. Other than the items above, the draft is looking quite good. Cheers, Jon --047d7b2e3e006aaadc04db16722a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Greetings Authors!


I am the Document Shepard for you draft.=A0


Initial review of your draft brings up three initia= l small issues and one small suggestion


(1) Acronyms that are not common IETF acronyms need= to be spelled out

on first use in the Abstract and Introduction. (TRI= LL is spelled out

on second use in the abstract but there are others = not spelled out at

all.)


(2) The list of acknowledgements should include Sam= Aldrin and Yizhou

Li who did reviews.


(3) A light editing pass should be done by someone = who is a native

English speaker to add articles and the like so it = reads more smoothly.Some statements are a wee bit awkward. Just in the para= graph below "...where VMs migrates" needs to be either where a VM= migrates or where VMs migrate.=A0


(4) Just a suggestion: the last paragraph in sectio= n 3.1 ( lovely ascii pictures by the way)=A0


=A0 =A0=A0- In a= n environment where VMs migrates, there is higher chance of

=A0 =A0 =A0 =A0 = cached information becoming invalid, causing traffic to be

=A0 =A0 =A0 =A0 = black-holed by the ingress RBridge, that is, persistently sent

=A0 =A0 =A0 =A0 = to the wrong egress RBridge. If VMs do not flood gratuitous

=A0 =A0 =A0 =A0 = ARP/ND or VDP [802.1Qbg] messages upon arriving at new

=A0 =A0 =A0 =A0 = locations, the ingress nodes might not have MAC entries for the

=A0 =A0 =A0 =A0 = MAC of the newly arrived VMs, causing unknown address flooding.

=

=

It may be worth noting that the issues with relianc= e on the gratuitous ARP is exacerbated by the fact that individual implemen= tations in the field vary, and even between product lines in the same vendo= r you will different timers as to how long it takes for a switch to act on = a gratuitous arp. The inconsistency this creates is so troublesome I have w= orked in some shops that flat never relied on gratuitous ARPs for anything.= =A0


Now since this amounts to implementation issues, an= d not any issues with 802.1bg, it may not be worth mentioning. However it i= s the first thing I think of when I think of the value learning by director= y would bring me in a datacenter.=A0


Just a suggestion, 4 is not a blocking issue.=A0


Other than the items above, the draft is looking qu= ite good.=A0


Cheers,

Jon


=A0
--047d7b2e3e006aaadc04db16722a-- From iesg-secretary@ietf.org Wed Apr 24 06:30:56 2013 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 3793421F8FA4; Wed, 24 Apr 2013 06:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F0oiFBC9-nc; Wed, 24 Apr 2013 06:30:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C51AD21F8C14; Wed, 24 Apr 2013 06:30:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Sender: Message-ID: <20130424133055.17679.11810.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 06:30:55 -0700 Cc: trill@ietf.org Subject: [trill] Last Call: (TRILL (Transparent Interconnection of Lots of Links): Fine-Grained Labeling) to Proposed Standard X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 13:30:56 -0000 The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL (Transparent Interconnection of Lots of Links): Fine-Grained Labeling' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF has standardized TRILL (Transparent Interconnection of Lots of Links), a protocol for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports labeling of TRILL data with up to 4K IDs. However, there are applications that require more fine-grained labeling of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1688/ From linda.dunbar@huawei.com Wed Apr 24 15:03:48 2013 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 AA77221F8BE4 for ; Wed, 24 Apr 2013 15:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTsbiB8RA6CA for ; Wed, 24 Apr 2013 15:03:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A413B21F8B13 for ; Wed, 24 Apr 2013 15:03:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQT80737; Wed, 24 Apr 2013 22:03:40 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 23:03:08 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 23:03:38 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.204]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 24 Apr 2013 15:03:31 -0700 From: Linda Dunbar To: Jon Hudson , Donald Eastlake , Radia Perlman , "igor@yahoo-inc.com" Thread-Topic: Edge Directory Assistance Framework draft-ietf-trill-directory-framework-04.txt Thread-Index: AQHOQL9UjiBkRRuOHE+RnoS3UxekfJjl5Pzw Date: Wed, 24 Apr 2013 22:03:30 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B0FB10@dfweml509-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.224] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B0FB10dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] Edge Directory Assistance Framework draft-ietf-trill-directory-framework-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 22:03:48 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645B0FB10dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jon, Thank you very much for shepherding this draft. Reply to your comments are inserted below: From: Jon Hudson [mailto:jon.hudson@gmail.com] Sent: Wednesday, April 24, 2013 2:43 AM To: Linda Dunbar; Donald Eastlake; Radia Perlman; igor@yahoo-inc.com Cc: trill@ietf.org Subject: Edge Directory Assistance Framework draft-ietf-trill-directory-fra= mework-04.txt Greetings Authors! I am the Document Shepard for you draft. Initial review of your draft brings up three initial small issues and one s= mall suggestion (1) Acronyms that are not common IETF acronyms need to be spelled out on first use in the Abstract and Introduction. (TRILL is spelled out on second use in the abstract but there are others not spelled out at all.) [Linda] Can you point out the exact acronyms? Terminology Section should ha= ve the definitions for all of acronyms used in the document. But we might = missed some. (2) The list of acknowledgements should include Sam Aldrin and Yizhou Li who did reviews. [Linda] Absolutely. We can re-spin the draft to include the people who prov= ided valuable comments. (3) A light editing pass should be done by someone who is a native English speaker to add articles and the like so it reads more smoothly.Some= statements are a wee bit awkward. Just in the paragraph below "...where VM= s migrates" needs to be either where a VM migrates or where VMs migrate. [Linda] I will leave it to Donald for a final check. (4) Just a suggestion: the last paragraph in section 3.1 ( lovely ascii pic= tures by the way) - In an environment where VMs migrates, there is higher chance of cached information becoming invalid, causing traffic to be black-holed by the ingress RBridge, that is, persistently sent to the wrong egress RBridge. If VMs do not flood gratuitous ARP/ND or VDP [802.1Qbg] messages upon arriving at new locations, the ingress nodes might not have MAC entries for the MAC of the newly arrived VMs, causing unknown address flooding. It may be worth noting that the issues with reliance on the gratuitous ARP = is exacerbated by the fact that individual implementations in the field var= y, and even between product lines in the same vendor you will different tim= ers as to how long it takes for a switch to act on a gratuitous arp. The in= consistency this creates is so troublesome I have worked in some shops that= flat never relied on gratuitous ARPs for anything. Now since this amounts to implementation issues, and not any issues with 80= 2.1bg, it may not be worth mentioning. However it is the first thing I thin= k of when I think of the value learning by directory would bring me in a da= tacenter. [Linda] So you are agreeing with the statement in our draft? i.e. You can't= depend on Gratuitous ARP to flush stalled entries. You can't depend on 802= .1bg either because not every server support this feature. Just a suggestion, 4 is not a blocking issue. Other than the items above, the draft is looking quite good. Cheers, Jon --_000_4A95BA014132FF49AE685FAB4B9F17F645B0FB10dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jon,

 <= /p>

Thank you very much for s= hepherding this draft.

 <= /p>

Reply to your comments ar= e inserted below:

 <= /p>

From: Jon Huds= on [mailto:jon.hudson@gmail.com]
Sent: Wednesday, April 24, 2013 2:43 AM
To: Linda Dunbar; Donald Eastlake; Radia Perlman; igor@yahoo-inc.com=
Cc: trill@ietf.org
Subject: Edge Directory Assistance Framework draft-ietf-trill-direct= ory-framework-04.txt

 

Greetings Authors!=

 

I am the Document Shepard for= you draft. 

 

Initial review of your draft = brings up three initial small issues and one small suggestion

 

(1) Acronyms that are not com= mon IETF acronyms need to be spelled out

on first use in the Abstract = and Introduction. (TRILL is spelled out

on second use in the abstract= but there are others not spelled out at

all.)

 

[L= inda] Can you point out the exact acronyms? Terminology Section should have= the definitions for all of acronyms used in the document.  But we might missed some.

 

(2) The list of acknowledgeme= nts should include Sam Aldrin and Yizhou

Li who did reviews.

 

[L= inda] Absolutely. We can re-spin the draft to include the people who provid= ed valuable comments.

 

 

(3) A light editing pass shou= ld be done by someone who is a native

English speaker to add articl= es and the like so it reads more smoothly.Some statements are a wee bit awk= ward. Just in the paragraph below "...where VMs migrates" needs t= o be either where a VM migrates or where VMs migrate. 

 

[L= inda] I will leave it to Donald for a final check.

 

 

(4) Just a suggestion: the la= st paragraph in section 3.1 ( lovely ascii pictures by the way) <= /o:p>

 

    - In an environment where VMs mig= rates, there is higher chance of

        cached information becom= ing invalid, causing traffic to be

        black-holed by the ingre= ss RBridge, that is, persistently sent

        to the wrong egress RBri= dge. If VMs do not flood gratuitous

        ARP/ND or VDP [802.1Qbg]= messages upon arriving at new

        locations, the ingress n= odes might not have MAC entries for the

        MAC of the newly arrived= VMs, causing unknown address flooding.

 

 

It may be worth noting that t= he issues with reliance on the gratuitous ARP is exacerbated by the fact th= at individual implementations in the field vary, and even between product l= ines in the same vendor you will different timers as to how long it takes for a switch to act on a gratuitous arp. Th= e inconsistency this creates is so troublesome I have worked in some shops = that flat never relied on gratuitous ARPs for anything. 

 

Now since this amounts to imp= lementation issues, and not any issues with 802.1bg, it may not be worth me= ntioning. However it is the first thing I think of when I think of the valu= e learning by directory would bring me in a datacenter. 

 

[L= inda] So you are agreeing with the statement in our draft? i.e. You canR= 17;t depend on Gratuitous ARP to flush stalled entries. You can’t depend on 802.1bg either because not every server support this feature.

 

 

Just a suggestion, 4 is not a= blocking issue. 

 

Other than the items above, t= he draft is looking quite good. 

 

Cheers,

Jon

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645B0FB10dfweml509mbxchi_-- From d3e3e3@gmail.com Wed Apr 24 18:19:19 2013 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 8DE1B21F84CE for ; Wed, 24 Apr 2013 18:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSNefyyOIN97 for ; Wed, 24 Apr 2013 18:19:18 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id AD71521F84CD for ; Wed, 24 Apr 2013 18:19:18 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o17so2410713oag.32 for ; Wed, 24 Apr 2013 18:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Me/EspC7uHRXqJMVy9LKyyQiQl5nx0U7NgqByApmxEc=; b=c0PZXT6fPi6EdLiYcI54D41PLAwPtGv+jXCtCOrJwKhSeRaU6Or+BXGOG9Z6kBac4k Qwdx37sn799YNLBR7lv8H6fTa8A2QANCaReLIblZhjfJYSA2X5CDWs6E7VHScRn01RpH zZ339AToj1r8Zmxz4Np6MhRw01y36D0m0zLfwZoVx84L1Q6JPHKTWknqjs/AjgA/1SHi RM8+VDU9nOke9C4zEH68p6+uRSCy2pkH4hBd4LebLsANUVOsMfSlz0tx4gPPX+EIViO4 E56pOic8nmYg1Ye2pjIZCXLuJ8GiW5oMq4uWuYhfHAACxU9K+7UpFj0i5eRe6PYRlJco 71Bg== X-Received: by 10.60.18.233 with SMTP id z9mr19300612oed.19.1366852758348; Wed, 24 Apr 2013 18:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Wed, 24 Apr 2013 18:18:57 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B0FB10@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645B0FB10@dfweml509-mbx.china.huawei.com> From: Donald Eastlake Date: Wed, 24 Apr 2013 21:18:57 -0400 Message-ID: To: Jon Hudson Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" , "igor@yahoo-inc.com" Subject: Re: [trill] Edge Directory Assistance Framework draft-ietf-trill-directory-framework-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 01:19:19 -0000 Replying as a co-author, On Wed, Apr 24, 2013 at 6:03 PM, Linda Dunbar wro= te: > Jon, > > Thank you very much for shepherding this draft. > > Reply to your comments are inserted below: > > From: Jon Hudson [mailto:jon.hudson@gmail.com] > Sent: Wednesday, April 24, 2013 2:43 AM > To: Linda Dunbar; Donald Eastlake; Radia Perlman; igor@yahoo-inc.com > Cc: trill@ietf.org > Subject: Edge Directory Assistance Framework > draft-ietf-trill-directory-framework-04.txt > > Greetings Authors! > > I am the Document Shepard for you draft. > > Initial review of your draft brings up three initial small issues and one > small suggestion > > (1) Acronyms that are not common IETF acronyms need to be spelled out > on first use in the Abstract and Introduction. (TRILL is spelled out > on second use in the abstract but there are others not spelled out at > all.) > > [Linda] Can you point out the exact acronyms? Terminology Section should > have the definitions for all of acronyms used in the document. But we mi= ght > missed some. OK. > (2) The list of acknowledgements should include Sam Aldrin and Yizhou > Li who did reviews. > > [Linda] Absolutely. We can re-spin the draft to include the people who > provided valuable comments. OK. > (3) A light editing pass should be done by someone who is a native > > English speaker to add articles and the like so it reads more smoothly.So= me > statements are a wee bit awkward. Just in the paragraph below "...where V= Ms > migrates" needs to be either where a VM migrates or where VMs migrate. > > [Linda] I will leave it to Donald for a final check. OK. > (4) Just a suggestion: the last paragraph in section 3.1 ( lovely ascii > pictures by the way) > > - In an environment where VMs migrates, there is higher chance of > cached information becoming invalid, causing traffic to be > black-holed by the ingress RBridge, that is, persistently sent > to the wrong egress RBridge. If VMs do not flood gratuitous > ARP/ND or VDP [802.1Qbg] messages upon arriving at new > locations, the ingress nodes might not have MAC entries for the > MAC of the newly arrived VMs, causing unknown address flooding. > > It may be worth noting that the issues with reliance on the gratuitous AR= P > is exacerbated by the fact that individual implementations in the field > vary, and even between product lines in the same vendor you will differen= t > timers as to how long it takes for a switch to act on a gratuitous arp. T= he > inconsistency this creates is so troublesome I have worked in some shops > that flat never relied on gratuitous ARPs for anything. > > Now since this amounts to implementation issues, and not any issues with > 802.1bg, it may not be worth mentioning. However it is the first thing I > think of when I think of the value learning by directory would bring me i= n a > datacenter. > > [Linda] So you are agreeing with the statement in our draft? i.e. You can= =92t > depend on Gratuitous ARP to flush stalled entries. You can=92t depend on > 802.1bg either because not every server support this feature. I'm not sure that is worth changing in the 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Just a suggestion, 4 is not a blocking issue. > > > > Other than the items above, the draft is looking quite good. > > > > Cheers, > > Jon > > > > > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From internet-drafts@ietf.org Fri Apr 26 07:30:00 2013 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 29D1321F99C9; Fri, 26 Apr 2013 07:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1dnFezd9UPu; Fri, 26 Apr 2013 07:29:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0463221F99CC; Fri, 26 Apr 2013 07:29:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426142957.24294.9033.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 07:29:57 -0700 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-directory-framework-05.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 14:30:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots of Li= nks Working Group of the IETF. Title : TRILL (Transparent Interconnection of Lots of Links): Ed= ge Directory Assistance Framework Author(s) : Linda Dunbar Donald Eastlake Radia Perlman Igor Gashinsky Filename : draft-ietf-trill-directory-framework-05.txt Pages : 17 Date : 2013-04-26 Abstract: Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame whose destination address (MAC&VLAN) that switch does not know, the data frame is flooded within the frame's VLAN across the TRILL campus. This document describes the framework for using directory services to assist edge RBridges in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND, thus improving TRILL network scalability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trill-directory-framework-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-directory-framework-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From d3e3e3@gmail.com Fri Apr 26 07:34:37 2013 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 A8D7921F992F for ; Fri, 26 Apr 2013 07:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlTE3xh0vlpA for ; Fri, 26 Apr 2013 07:34:37 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD1821F95D0 for ; Fri, 26 Apr 2013 07:34:37 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so4033219oah.21 for ; Fri, 26 Apr 2013 07:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=+IFHODHHMjA/wPmGPBb++g8fiZzIN8iXhBK3+qeWef4=; b=fngALyonn05ElNBLW9jVmq1PYZ/7UL1+8ZE4j+Z+n7E4CFMWYj7Xl/50BWyWA8DF8m 7KH3sanR5oxhGCFUJGLjPKMS2WPok8DtqSBSlQp3i4fXRGrvPawMlWoL6khE5bs8QDQY QQHDEZvJK5hIugxVC59KHGhYDbSrdToP+aVc+IgRsk3AExoaPOP8D64AEV3FxvFwx6JF LATJ8ZGnyJm6ZGMRej5nL+GX7JuqN9OoDp3j1SbrC+ARbL447ZyLRk1+mkTW9pcoyuuf deW14oYQ8ztNuF2asqxKGpCZQhV28B29DK+X1EoqYHE6F4nKa5wXVDDg4LgTprnvdTf7 Yp+g== X-Received: by 10.60.18.233 with SMTP id z9mr22791797oed.19.1366986876731; Fri, 26 Apr 2013 07:34:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Fri, 26 Apr 2013 07:34:15 -0700 (PDT) In-Reply-To: <20130426142957.24294.9033.idtracker@ietfa.amsl.com> References: <20130426142957.24294.9033.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Fri, 26 Apr 2013 10:34:15 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [trill] I-D Action: draft-ietf-trill-directory-framework-05.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 14:34:37 -0000 This revision incorporates most of the document shepherd comments. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Apr 26, 2013 at 10:29 AM, wrote: > > 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 Working Group of the IETF. > > Title : TRILL (Transparent Interconnection of Lots of Links): Edge Directory Assistance Framework > Author(s) : Linda Dunbar > Donald Eastlake > Radia Perlman > Igor Gashinsky > Filename : draft-ietf-trill-directory-framework-05.txt > Pages : 17 > Date : 2013-04-26 > > Abstract: > Edge TRILL (Transparent Interconnection of Lots of Links) switches > currently learn the mapping between MAC addresses and their egress > TRILL switch by observing the data packets they ingress or egress or > by the TRILL ESADI (End Station Address Distribution Information) > protocol. When an ingress TRILL switch receives a data frame whose > destination address (MAC&VLAN) that switch does not know, the data > frame is flooded within the frame's VLAN across the TRILL campus. > > This document describes the framework for using directory services to > assist edge RBridges in reducing multi-destination frames, > particularly unknown unicast frames flooding, and ARP/ND, thus > improving TRILL network scalability. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trill-directory-framework > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-trill-directory-framework-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-directory-framework-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From hammondjohnson@hushmail.com Sat Apr 27 14:57:06 2013 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 0B08F21F98DA for ; Sat, 27 Apr 2013 14:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uR8mXuI6aOYO for ; Sat, 27 Apr 2013 14:57:05 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id C5E1721F9839 for ; Sat, 27 Apr 2013 14:57:05 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 775D3580B6 for ; Sat, 27 Apr 2013 17:52:56 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:52:56 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 313A0E6739; Sat, 27 Apr 2013 17:52:55 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:52:55 -0400 To: trill@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427175256.313A0E6739@smtp.hushmail.com> Subject: [trill] Biggest Fake Conference in Computer Science X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:57:06 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From d3e3e3@gmail.com Mon Apr 29 13:27:13 2013 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 36B3621F99C3 for ; Mon, 29 Apr 2013 13:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLBWekeImKnx for ; Mon, 29 Apr 2013 13:27:05 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8237F21F997D for ; Mon, 29 Apr 2013 13:26:58 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i10so6576819oag.1 for ; Mon, 29 Apr 2013 13:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=LL/fVgRm27boIhJGN9x3nZxWX+fXksJv52p2W9qsIAM=; b=UaZK2tRlHbpferuI3+Eq/YGmQ0ccn9CoLY4YE/v1/XmXmxE1lV4Mz8OlFgcRrKWpBj 2z+L3f2Wd0z0ACwXekIwGvKuNMvnqT5b/Gf5/YVvqyAluLxddFBRi5Y4V9t+cl76BAjj hvPC4l/NmaM5wmgeYe6KKNw/PEdddgEd7VMSB+yzF5PWVJJZrAJ3XJKmEUTPvboHUIrA z3T2MQokcuP00e5SGhXfWm5YpR1DTV9WH6aAJ9DNHYfAbveoIHwCTjoMNIQCncszvtug TrplAciqY2Xw6CEYI1/p35Qu9AfxULH99ew/WxW2kYnckGSYuGp8vNfRUaNOnH99lKy9 EUrQ== X-Received: by 10.60.132.196 with SMTP id ow4mr24721470oeb.75.1367267218058; Mon, 29 Apr 2013 13:26:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Mon, 29 Apr 2013 13:26:38 -0700 (PDT) In-Reply-To: <20130429014034.769.85799.idtracker@ietfa.amsl.com> References: <20130429014034.769.85799.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 29 Apr 2013 16:26:38 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] Fwd: New Version Notification for draft-eastlake-trill-rfc6327bis-00.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 20:27:13 -0000 A possible revision of RFC 6327 "TRILL: Adjacency" has been posted that may be of interest. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com ---------- Forwarded message ---------- From: Date: Sun, Apr 28, 2013 at 9:40 PM Subject: New Version Notification for draft-eastlake-trill-rfc6327bis-00.txt To: Radia Perlman , Vishwas Manral , Anoop Ghanwani , "Donald E. Eastlake 3rd" A new version of I-D, draft-eastlake-trill-rfc6327bis-00.txt has been successfully submitted by Donald E. Eastlake and posted to the IETF repository. Filename: draft-eastlake-trill-rfc6327bis Revision: 00 Title: TRILL: Adjacency Creation date: 2013-04-28 Group: Individual Submission Number of pages: 39 URL: http://www.ietf.org/internet-drafts/draft-eastlake-trill-rfc6327bis-00.txt Status: http://datatracker.ietf.org/doc/draft-eastlake-trill-rfc6327bis Htmlized: http://tools.ietf.org/html/draft-eastlake-trill-rfc6327bis-00 Abstract: The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol supports arbitrary link technologies between TRILL switches including point-to-point links and multi-access LAN (Local Area Network) links that can have multiple TRILL switches and end stations attached. TRILL uses IS-IS (Intermediate System to Intermediate System) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacency between TRILL switches, also known as RBridges. It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bi- Directional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325. The IETF Secretariat