From nobody Thu Mar 2 14:44:41 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA351293F8; Thu, 2 Mar 2017 14:44:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148849468012.30822.585902932075331305.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 14:44:40 -0800 Archived-At: Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-directory-assist-mechanisms-12.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:44:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL: Edge Directory Assist Mechanisms Authors : Donald Eastlake Linda Dunbar Radia Perlman Yizhou Li Filename : draft-ietf-trill-directory-assist-mechanisms-12.txt Pages : 55 Date : 2017-03-02 Abstract: This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi- destination traffic, particularly ARP/ND and unknown unicast flooding. It can also be used to detect traffic with forged source addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-directory-assist-mechanisms-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 2 14:45:50 2017 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 900EF12941D; Thu, 2 Mar 2017 14:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXttIP1lpv-M; Thu, 2 Mar 2017 14:45:42 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CB41293F8; Thu, 2 Mar 2017 14:45:42 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id f84so62767707ioj.0; Thu, 02 Mar 2017 14:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fnLWeMx4JfAk50qx54PL7eNOpN3704N/yuhe0KSPGZI=; b=lOOiw9jghkOvtAfC7vsrJt0goyF8yyUIRegIsZOYChmfckXGEveTsy+TEuFoYpabbn MUrcPQygklDXa2nrBdK3D944LS09c/rYOe83Plq92VQpvVFlSnNrhx9jJ69j6nk8acdu 8akc8/UMJ7igHgwaQmRjNHmNix0eb8UAf9aTBeVHj8RaVlhU0mjuO7jMlsbM2bmEIWfD JI6JL8q7nDUiwC+c+CWNlLdDhSZaY8SPCRzMPN4xjRmQ3WjQqsMQBVa8+aZrkUf6oAKn bB+DC7D3uhJfybuz5K5EsAdclp0Jxdfwy/OMegYyohjoTPA5SkeJlE994oeCVfO9NkWd 0E6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fnLWeMx4JfAk50qx54PL7eNOpN3704N/yuhe0KSPGZI=; b=rf5AXkmuME1g6MnEQc6hcLNQTXxuqpateinlruUj0ovyeglpDjRvTrXcnN8fYBxDCZ hwsHMtds0E56vgFEO3BvW8S6QkGkUG7nZ4m9sQyG8dUpOHpTTrbAiZL+THnCnfPlHQY8 tzVk538gH29KlwmFROfMy/4lOv2WWIKGSO/Xttgvjp6XyoWy7hVonP1ve1LKbPB/SNm9 i5ElCOX0vn0C6AIo7DPbe3LpdKEBRlohrd6+9VNZ2Cbj0eFWrVSypFV/DqS5qPQ9gfFY 6q/3XPhSxkS36Yof642ieqwoYaIaJDX7FujwSIjMPeEpd4dTtU374CaiCspnT3RVHjiO qHFw== X-Gm-Message-State: AMke39mSMUXAjSaxKEaU/aJ5/iFn4BfKVPsTtREE7oqWt6Roe59DiHpVghB+cpCTpH7s4vwOOEaSTej1Bzaadw== X-Received: by 10.107.48.142 with SMTP id w136mr185419iow.16.1488494741443; Thu, 02 Mar 2017 14:45:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:45:25 -0800 (PST) In-Reply-To: References: <148460788762.22588.13989856834598298736.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 2 Mar 2017 17:45:25 -0500 Message-ID: To: Spencer Dawkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:45:45 -0000 Hi Spencer, Version -12 of this draft, which has just been posted, is intended to resolve your comments. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jan 16, 2017 at 9:57 PM, Donald Eastlake wrote: > Hi Spencer, > > Thanks for your thorough review. See below > > On Mon, Jan 16, 2017 at 6:04 PM, Spencer Dawkins > wrote: >> >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-trill-directory-assist-mechanisms-11: No Objection >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> In this text, >> >> It might learn that information from >> the directory or could query the directory if it does not know. >> >> is "learning information from the directory" different from "querying the >> directory"? My apologies for not knowing TRILL well. > > It should probably say "It might have learned that information from > the directory or could query the direction if it does not already know > it." because it could be that either (1) it has been pushed to it by > a Push Directory or (2) it could have pulled it from a Pull Directory > and cached it. > >> I found this text, >> >> A Push Directory also advertises whether or not it >> believes it has pushed complete mapping information for a Data >> Label. >> >> to be odd ("directories believe things?"), and I'm wondering what that >> belief would be based on. If a Push Directory has pushed all the >> information it's currently storing, is that what's being described here? >> Or does this mean something else? > > Not quite. It could be de-anthropomorphised and made more precise by > saying something like "A Push Directory advertises when it both is > configured to be a directory having complete information and has > actually pushed all the information it has." > >> In section 2.3.1, there are several states that refer to "enough time for >> propagation" - for example, >> >> Active Completing : Same behavior as the Active state except >> that the server responds differently to events. The purpose of >> this state is to be sure there has been enough time for directory >> information to propagate to subscribing edge TRILL switches >> before >> the Directory Server advertises that the information is complete. >> >> Is it possible to provide a pointer or reference that describes how >> "enough time" is calculated? I'm not sure whether this is referring to >> PushDirTimer in Section 2.7 or something else. > > This propagation time, as you might expect, depends on network > topology. The worst possible time for a network with a large number > of TRILL switches could be impractically long. Yet, in a richly > connected data center or Internet exchange with reasonably high > bandwidth links, one second would be plenty of time. In this > specification, the time in the time for "The Time Condition" as > specified in Section 2.3.2, page 11 and is, indeed, PushDirTimer. It > defaults to twice the CSNP time, which is related to the ESADI link > state consistency time scale and is pretty conservative. It might be > good to add some forward pointers to the places where there is this > "enough time" wording. > >> It's a nit, but I think this text, >> >> TRILL switches, whether or not they are a Push Directory server, >> >> should be something like >> >> TRILL switches, whether or not they are Push Directory servers, >> >> - there's a numbering mismatch. > > OK > >> I think this text, >> >> Thus, there is commonly a >> small window during which the an RBridge using directory information >> might either (1) drop or unnecessarily flood a frame as having an >> unknown unicast destination or (2) encapsulate a frame to an edge >> RBridge where the end station is not longer connected when the frame >> arrives at that edge RBridge. >> >> is garbled (somewhere around "during which the an RBridge"). > > Yes, the first occurrence of the word "the" should be deleted. > >> In this text, >> >> Support of TRILL ES-IS is generally optional for both the TRILL >> switches and the end stations on a link but may be required to >> support certain features. >> >> can you give any guidance to the reader on how to know whether TRILL >> ES-IS support is required for a feature? > > Any feature that needs TRILL ES-IS needs to say so. TRILL ES-IS is > specified in Section 5 which enumerates in its first paragraph the > only existing use of TRILL ES-IS (Pull Directory hosting on and use by > end stations) and the two anticipated uses of TRILL ES-IS (the > trill-directory-assisted-encap and trill-smart-endnodes drafts). > Probably the first and second paragraphs of Section 5 could be > re-organized a bit to clarify this. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Thu Mar 2 14:46:19 2017 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 BBB8A1293F8; Thu, 2 Mar 2017 14:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrcfxQMYP1cP; Thu, 2 Mar 2017 14:46:13 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E7F128E18; Thu, 2 Mar 2017 14:46:13 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id 90so63953534ios.1; Thu, 02 Mar 2017 14:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bzSTv6Fa8EwGWN8LrF/amfEPl35QBvVFkQbiCOPzAEs=; b=ArreKLcLVM2hruV6dpqgIy+wTog0MtL0AvzAVIcKxu4YJ/CxtsXNv8KLZ6aUe8DwA5 RNiZ8jXMltXQZZ0QA0462bSvq7OKchi3VeRqH1/4+0rpV5UD/U3PJqo8Ddn2tMsjbJoi eYBWEAnNdzTZTHId+eKmkCwQMitD+jSwMnzhwqqNjfqyqRuLtpoDU6RoqOb6QrNAl2mv 1SJdKgoHq6y/HRujjUdVAVWPK4xPLmBwzK5I8XgD1DP0PkuhNNkUqFiZq7sCLoEtxlze aKV+nAt+IjtneiDlW7E/G1TyIhq35wKAxs5VhzKVDQs3tLP23mlYjy1lzn7SGzQPkZ1s IsLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bzSTv6Fa8EwGWN8LrF/amfEPl35QBvVFkQbiCOPzAEs=; b=b7a7Mki2+SVczrRhWabfLqPj6sMo0LQFJglC+APmLr6uXDclk3bbvtYhbOqKkJaWpq cTtTXfOa/v55wb85u57sWvKCxT6vvlyUtVJqNnM/b73Qb6efL8pfbu0VWSRFcsyEteAe 8LYpDJxtOpZmrMG2vBqmcaNswA5DX7ww7dyq6YRVcjl7KkQIFFgFs3aDAemR8XXzTQzO uMuwiwXMcyiMxSjYqPOtZ6CC4YmwtmWkGPQnvmkmJh+kpDKUSM7x2oO13YccxiZbGSa8 EM+NLX4OZoh5711Xr4CoFJnJiniF22EfpmxVEKpzRPVIy6OZg/dkg6BExTt7mt+QCrjb ygNw== X-Gm-Message-State: AMke39mzk0BUH0MTjYbChe61vZqy1uY6mWers/su+7Irjx6sIcuybrHS7WQ70PKSjTfBVX9yAAK3mr7WtexYMA== X-Received: by 10.107.141.80 with SMTP id p77mr156591iod.97.1488494772544; Thu, 02 Mar 2017 14:46:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:45:56 -0800 (PST) In-Reply-To: <09692183-AC90-4862-8EA9-86A176C69EF8@fastmail.fm> References: <148476684392.2033.546851999767154453.idtracker@ietfa.amsl.com> <09692183-AC90-4862-8EA9-86A176C69EF8@fastmail.fm> From: Donald Eastlake Date: Thu, 2 Mar 2017 17:45:56 -0500 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:46:15 -0000 Hi Alexey, Version -12, just posted, is intended to resolve your DISCUSS. My apologies for taking so long. Could you take a look? Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Jan 19, 2017 at 4:48 AM, Alexey Melnikov wrote: > Hi Donald, > >> On 19 Jan 2017, at 05:16, Donald Eastlake wrote: >> >> Hi Alexey, >> >>> On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov wrote: >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-trill-directory-assist-mechanisms-11: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> In Section 3.1 there is a Version field. What are the condition(s) for >>> bumping this version number? What backward compatibility guaranties are >>> expected (if any)? How would version negotiation be done? >> >> Well, I could say that the answers to all of your questions are about >> the same for this Version field as they are for the RBridge Channel >> Header version field [RFC7178], the TRILL Header version field >> [RFC6325], and many other version fields in IETF protocols but you >> probably wouldn't consider that a very good answer. >> >> I suppose if text was being added along this lines, it should say that >> the version number must be incremented for a specification that does >> not just specify new field values where that is allowed in version >> zero but cannot be correctly parsed beyond the version nibble. Since >> the protocol is a request/response protocol, the responder should >> indicate the highest version number they understand but the response >> must be valid in the version number specified in the request including >> the possibility of indicating a valid error saying that the version is >> not implemented. Thus all implementations of version X would need to >> be able to at least send such an error for all versions from 0 through >> X-1. Then you would add an explicit suberror code in Section 3.6.3 for >> unimplemented version. For a version zero implementation, that would >> be returned for any higher version. >> >> However, I don't expect an incremented version number to be needed >> anytime soon. Was it your intent with this DISCUSS to get something >> like the above added to the draft? > > Yes, exactly along the lines of your text above. > > From nobody Thu Mar 2 14:47:27 2017 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 AE6F91293F8; Thu, 2 Mar 2017 14:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18DMX_oxSN9Z; Thu, 2 Mar 2017 14:47:24 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCEC128E18; Thu, 2 Mar 2017 14:47:24 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id 90so63970625ios.1; Thu, 02 Mar 2017 14:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZMisJE+z6/m0xquq4TnPhAKCtEpXrAnM8vovurQeCyk=; b=i0ymLEv6OyX/GBGJTatY0ZiFUwTg1AyjsCa1dMXuzULPnaSN98MMwQwGbJfI4A1JBa Ar0kWBEi9llHSmu/ZvIT7eHPGQID9lT7nkYwhl253IsDiAQnYv0gYX/cQJg+FVMev6cw 9W8uuYngY9MxGkgP2CnbkKvMS1GbDyVH9XcT0PN4qcwejcPXFSOjEAB9NlINDjyUWlnH PhY4QJqB3EkSKsFDKAQO6rmHyrRPS99RKptEE96YBncvP/1C6+NS60DbsYLT/17vpU70 /q214gZpe1tgPRppBBu3XkkgiQC59iqkxpPFDywUi9q5oS+yAVji5KjZJYdGpVMODi2D ptSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZMisJE+z6/m0xquq4TnPhAKCtEpXrAnM8vovurQeCyk=; b=GcouK8uxA3eMZMyDbJwUT9zix6q+dMiULi6MPe6j7IhbXBESOPEIdkr/Lnabht/5n2 nbRXXg5hSDXF8/PPz4/cvlNO6vl6pORu37t8E5T3P0ULc5e+3EmPsnV1o+cI7hxBeKcM X2xHrqkz0iLotX8UCBvZwj6hs3R94LlZvRyXjHAabm0jfSxUF3lmGsuRpZMLIqAP8IRa 8nv8LDdqsOH+4uhoOzRb8n/EkClh3ij+uIGhs2dqCNayOlXoxrQ8oRxaMtyb6CLYBuYs 0qkygzP3uODeg8ZphqC31VSOWo3vHqWyb66kqoXVNJTx69h6mLgk1LIq6S+pGzXok7b9 GNIA== X-Gm-Message-State: AMke39mGnk1gAy6rKK2taXkyBZJovkJc7lP0ssOzlCXp2IQ0yK2tuQ+GGbZF4oERbjTuRzbRzC6a1YgS14edKQ== X-Received: by 10.107.20.148 with SMTP id 142mr193952iou.12.1488494843540; Thu, 02 Mar 2017 14:47:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:47:07 -0800 (PST) In-Reply-To: <148482836602.10328.15276840045846655138.idtracker@ietfa.amsl.com> References: <148482836602.10328.15276840045846655138.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 2 Mar 2017 17:47:07 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:47:25 -0000 Hi Stephen, Thanks for your comments. See below and version -12 just posted. On Thu, Jan 19, 2017 at 7:19 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-trill-directory-assist-mechanisms-11: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - 2.6: I wondered why this was useful. Is it for cases where > the secondary push service is differently connected or is it > in case the primary goes down? Might be good to say. The reasons for multiple directory servers are resilience, increase the bandwidth of directory services, and to make them more locally available reducing network load. It seems likely that in many cases the directory information would come from a data center orchestration service which would have a co-located push directory that would be used to populate other directories. It seems like you could equally well ask why the DNS has primary and secondary servers and does zone transfers to populate the secondary from a primary. People generally find this sort of thing useful in multiple-server directory applications. > - section 6: what security mechanism differences are there > between the push and pull cases? Why aren't those called out > here? Forcing the reader to delve into the various other > security mechanism RFCs and figure this out themselves seems > less good. I don't see it that way. I believe that people will choose what combination of Push, Pull, both, or no directory they are going to use and the like based on their operational and efficiency needs. Then they are going to evaluate, in the context of their network/use, how important it is to add cryptographic security. So a pointer to the security available for each type (Push or Pull) of message answers most implementer needs. That being said, it seems reasonable to add that IS-IS security, available for Push messages, provides only authentication, while RBridge Channel security, available for Pull messages, can also provide confidentiality. > - section 6: apologies if I asked this before (in which case I > forget the answer;-) but how fictional/real is the crypto > stuff with TRILL in terms of the likelihood of it being > actually used? I ask again, as if the crypto stuff is mostly > fictional, then I think you ought note that here, given the > attack surface that the directory function creates. I'm not entirely sure what you mean by the "crypto stuff with TRILL". TRILL is built on IS-IS and IS-IS security is quite widely implemented and deployed. The Push directory message security uses this IS-IS security and I would expect it to be available in almost all implementations. On the other hand, TRILL security for RBridge Channel messages, which can be used to secure Pull directory messages, was only fairly recently standardized in RFC 7978 so it is less widely implemented or deployed. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Mar 2 14:48:01 2017 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 2F3A21293F8; Thu, 2 Mar 2017 14:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0erx5YvA2tQ2; Thu, 2 Mar 2017 14:47:58 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11C6128E18; Thu, 2 Mar 2017 14:47:58 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id m27so2927933iti.1; Thu, 02 Mar 2017 14:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8kRaZAWuUGMZP/ATAHUvdTB10uaT+PR5su3cX5t7VQ=; b=D9Vk17ZPSSHKsQqYEm+mhxLoVpXNSZQjccCj09U6ypU358cktBaucxh6AiPf2M8/uS 33QU6RWQ60bMuqjOpYD4yBLGwAJpn967Ss9asvV8Fc/QrobmW5o/fw2b+a4ashOJwzKv Kf6E3ZolKrBZIk8rfuo92beXp8i3A9x/4Au4UmnijIm7991kR3VLcEWx/8iTeIgG7Lwc VJAhNAHsoUOkHY10l6GgYtHZYJvgDRQ6fJS8DTrNnsR10lijIN3VDKC1T8ubKQXFdR1a u2DKdc9hy7pZ8eayOUXErhuczs+yKPZDPiqw7Lessh5o/zg36GwJQkzVGS0BUPqT4SkL aEdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8kRaZAWuUGMZP/ATAHUvdTB10uaT+PR5su3cX5t7VQ=; b=CU5h1zCPDk5J6pvln1g7EFbp88MR8ferlXQaK5pzBYD4CjxyKgbK/pEaRbgVSK5VBX IObqbLqvgpBZWIXk3rAUFl/goVP93v60oV9ySPammQk3QXxY1c9Mrup6FYxeTfdPYvGA b18ufE6fmAier3i+zZhSJLgLTA2+efRibycv9zrou4hzKZQQdFd6sgUxurKa9j7nZb0e IKjQaotJPtk3L55nTk+bEK8ggPbdl500bKxW9hC97Q+63kmi5m491wUDk47anWf7hhbr IK93GBdUdss8q5XUH/BuFHKnDFoWxwHmRhS8Owzu/uarPsPtzTyXGqtX+0Gh1RNbywnW zzyw== X-Gm-Message-State: AMke39kCJ5eel2BnOVbbnWY7n9cZh2bjqSrWL4DYCXdkpiZQZoD/u4x0chYjAeTK9LtSaqhI99PlKeOLdpFxqg== X-Received: by 10.36.77.10 with SMTP id l10mr148811itb.59.1488494878095; Thu, 02 Mar 2017 14:47:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:47:42 -0800 (PST) In-Reply-To: <049DB5B4-422C-496D-824E-3ABB290D289A@cooperw.in> References: <148475513653.2001.17665625207200773811.idtracker@ietfa.amsl.com> <049DB5B4-422C-496D-824E-3ABB290D289A@cooperw.in> From: Donald Eastlake Date: Thu, 2 Mar 2017 17:47:42 -0500 Message-ID: To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a1144d016758e670549c73854 Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Alissa Cooper's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:48:00 -0000 --001a1144d016758e670549c73854 Content-Type: text/plain; charset=UTF-8 Hi Alissa, The -12 version of this draft, just posted, has a paragraph about ephemeral MAC addresses in Section 1 and some text about protecting directory information added to Section 6, which is now divided into subsections. This is intended to resolve your comments. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Jan 19, 2017 at 9:21 AM, Alissa Cooper wrote: > > > On Jan 18, 2017, at 2:02 PM, Donald Eastlake wrote: > > > > Hi Alissa, > > > > On Wed, Jan 18, 2017 at 10:58 AM, Alissa Cooper > wrote: > >> > >> Alissa Cooper has entered the following ballot position for > >> draft-ietf-trill-directory-assist-mechanisms-11: No Objection > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Since this document implies the creation of centralized databases of > >> addressing information, I think it would help to call out in Section 6 > > > > Yes, although such centralized databases are quite common currently in > > terms of data center management and orchestration system databases. > > > >> the need to secure the directory contents themselves, not just against > >> abuses of the push or pull services but in general against unauthorized > >> access. > > > > OK. > > > > I'm not sure the need to secure directories resident on TRILL switches > > is that much different from the need to secure the routing function > > and routing data of TRILL switches. But the draft also supports Pull > > Directories hosted on end stations and I think something should be > > said about end station security in connection with the end station > > hosting a directory. > > Sounds good. > > > > >> Also, I recall in prior evaluations of TRILL documents some discussion > >> about how TRILL deals with ephemeral MAC addresses and my recollection > is > >> that they are likely prohibited by policy on TRILL networks. But if > there > > > > The payload of a TRILL Data packet looks like an Ethernet frame. TRILL > > delivers it to end station(s) based on the destination MAC address > > and, by default, learns about MAC reachability by observing the source > > MAC address. So, while I would not say ephemeral or frequently > > changing MAC addresses are prohibited by "policy", they would reduce > > the efficiency of a TRILL campus by frequently obsoleting learned MAC > > reachability information. > > > >> is some interaction between ephemeral MAC addresses and the services > >> described in this document that would be good for implementors to be > >> aware of, those are probably worth mentioning. > > > > Directories need not be complete. If, for example, there were servers > > with fixed MACs and clients with mostly ephemeral MACs, I think it > > would still be reasonable to have the reachability (edge attachment > > point) information for the fixed MACs in a directory. Something about > > this could be added to the draft. > > I think that would be helpful. > > Thanks, > Alissa > > > > > Thanks, > > Donald > > =============================== > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > d3e3e3@gmail.com > > --001a1144d016758e670549c73854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alissa,

The -12 version of this draf= t, just posted, has a paragraph about ephemeral MAC addresses in Section 1 = and some text about protecting directory information added to Section 6, wh= ich is now divided into subsections. This is intended to resolve your comme= nts.

Thanks= ,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2= =A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757= USA
=C2=A0d3e3e3@= gmail.com

On Thu, Jan 19, 2017 at 9:21 AM, Alissa Coop= er <alissa@cooperw.in> wrote:

> On Jan 18, 2017, at 2:02 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>
> Hi Alissa,
>
> On Wed, Jan 18, 2017 at 10:58 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>>
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-trill-directory-assist-mechanisms-11: No Objection=
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut= this
>> introductory paragraph, however.)
>>
>> ------------------------------------------------------------<= wbr>----------
>> COMMENT:
>> ------------------------------------------------------------<= wbr>----------
>>
>> Since this document implies the creation of centralized databases = of
>> addressing information, I think it would help to call out in Secti= on 6
>
> Yes, although such centralized databases are quite common currently in=
> terms of data center management and orchestration system databases. >
>> the need to secure the directory contents themselves, not just aga= inst
>> abuses of the push or pull services but in general against unautho= rized
>> access.
>
> OK.
>
> I'm not sure the need to secure directories resident on TRILL swit= ches
> is that much different from the need to secure the routing function > and routing data of TRILL switches. But the draft also supports Pull > Directories hosted on end stations and I think something should be
> said about end station security in connection with the end station
> hosting a directory.

Sounds good.

>
>> Also, I recall in prior evaluations of TRILL documents some discus= sion
>> about how TRILL deals with ephemeral MAC addresses and my recollec= tion is
>> that they are likely prohibited by policy on TRILL networks. But i= f there
>
> The payload of a TRILL Data packet looks like an Ethernet frame. TRILL=
> delivers it to end station(s) based on the destination MAC address
> and, by default, learns about MAC reachability by observing the source=
> MAC address. So, while I would not say ephemeral or frequently
> changing MAC addresses are prohibited by "policy", they woul= d reduce
> the efficiency of a TRILL campus by frequently obsoleting learned MAC<= br> > reachability information.
>
>> is some interaction between ephemeral MAC addresses and the servic= es
>> described in this document that would be good for implementors to = be
>> aware of, those are probably worth mentioning.
>
> Directories need not be complete. If, for example, there were servers<= br> > with fixed MACs and clients with mostly ephemeral MACs, I think it
> would still be reasonable to have the reachability (edge attachment > point) information for the fixed MACs in a directory. Something about<= br> > this could be added to the draft.

I think that would be helpful.

Thanks,
Alissa

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


--001a1144d016758e670549c73854-- From nobody Fri Mar 3 16:02:18 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC198129A58; Fri, 3 Mar 2017 15:55:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533676.15846.10129217193638377834.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:36 -0800 Archived-At: Cc: trill@ietf.org, akatlas@gmail.com Subject: [trill] trill - Requested session has been scheduled for IETF 98 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:39 -0000 Dear Donald Eastlake, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. trill Session 1 (1:30:00) Monday, Afternoon Session II 1520-1650 Room Name: Zurich B size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transparent Interconnection of Lots of Links Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 35 Conflicts to Avoid: First Priority: saag intarea idr i2rs netconf netmod bess i2nsf lpwan babel grow Second Priority: isis sfc spring sidr dnsop People who must be present: Susan Hares Donald E. Eastlake 3rd Alia Atlas Jon Hudson Resources Requested: Meetecho support in room Special Requests: Please do not schedule on Friday. --------------------------------------------------------- From nobody Sat Mar 4 11:10:00 2017 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 CB759129580; Sat, 4 Mar 2017 11:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2B9SrD7e7jG; Sat, 4 Mar 2017 11:09:55 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26CE129519; Sat, 4 Mar 2017 11:09:54 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Andrew G. Malis'" , "'Bocci, Matthew \(Nokia - GB\)'" References: <8FA0B47D-32C0-41D0-BBDD-35F430DC44EE@nokia.com> In-Reply-To: Date: Sat, 4 Mar 2017 14:05:02 -0500 Message-ID: <058301d2951a$3ae0b920$b0a22b60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0584_01D294F0.520CD400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGCA568JvJrW7wv57ie05NblKPEFwJ1BxMKohKE4IA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-trill-transport-over-mpls@ietf.org, trill@ietf.org Subject: Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 19:09:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0584_01D294F0.520CD400 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andrew and Matthew:=20 =20 Thank you for the review.=20 =20 Sue=20 =20 From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Andrew G. = Malis Sent: Monday, February 27, 2017 11:43 AM To: Bocci, Matthew (Nokia - GB) Cc: rtg-dir@ietf.org; draft-ietf-trill-transport-over-mpls@ietf.org; = trill@ietf.org Subject: Re: [RTG-DIR] Routing Area Directorate QA review of = draft-ietf-trill-transport-over-mpls-02 =20 I=E2=80=99ve got some comments on Matthew=E2=80=99s review, inline. =20 On Mon, Feb 27, 2017 at 10:44 AM, Bocci, Matthew (Nokia - GB) = wrote: Routing Area Directorate QA review of = draft-ietf-trill-transport-over-mpls-02 =20 Hi, =20 I have been assigned the QA reviewer for this draft. The general = guidelines for QA reviews=20 can be found at: https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa=20 =20 These state: =20 "When reviewing a draft at WG Adoption, the QA Reviewer should determine whether the draft is readable, understandable, makes sense and is a good start for a WG draft. Any issues the QA Reviewer finds are written down, sent to the mailing list and discussed for future versions" =20 Here is my review of this draft: =20 ** Summary. Generally, the draft is well written - thank you. I have a few minor = comments below,=20 mostly related to the relationship between TRILL over MPLS and = established VPLS mechanisms. =20 ** Is the draft readable? =20 Yes. There are a few minor grammatical errors and it would help if the = draft was proof-read=20 to weed-out these. An example is:=20 Abstract "..that are separated by MPLS provider network." s/by MPLS/by an MPLS =20 =20 ** Is the draft understandable? =20 Yes, provided the reader is familiar with TRILL, MPLS and VPLS. =20 ** Does it make sense? I think it is mostly clear, but I have a few comments, as follows: =20 Section 3.4. MPLS encapsulation for VPLS model =20 "Use of VPLS [RFC4762] to interconnect TRILL sites requires no changes = to a VPLS implementation, in particular the use of Ethernet pseudowires between VPLS PEs. A VPLS PE receives normal Ethernet frames from an RBridge (i.e., CE) and is not aware that the CE is an RBridge device. As a result, an MPLS-encapsulated TRILL packet within the MPLS network will use the format illustrated in Appendix A of [RFC7173]." =20 It doesn't look like the encapsulation shown in Appendix A of RFC7173 takes account of the case where PBB VPLS [RFC7041] is used in = the provider's=20 MPLS network, but I would have thought this would still be a valid VPLS = type to transport=20 TRILL. It might be worth qualifying your reference with some text to = state that=20 this is just an example in the non-PBB case. =20 Andy: As the author of this paragraph, I agree with Matthew=E2=80=99s = comment. We can change the last sentence to say: =20 "As an example, an MPLS-encapsulated TRILL packet within the MPLS = network will use the format illustrated in Appendix A of [RFC7173] for the non-PBB = case, or in the PBB case, with the additional header fields illustrated in = [RFC7041]." =20 =20 Section 4.1.1: "TIR devices are a superset of the VPLS-PE devices defined in [RFC4026] = with the=20 additional functionality of TRILL." Is this really true? Later you state that TIRs use PPP PWs, not the = Ethernet PWs used in=20 VPLS. It is also not clear if TRILL needs some of the LDP or BGP = signaling extensions=20 used for VPLS. Wouldn't it be cleaner just to define a TIR as a new kind = of PE? =20 Andy: I also agree with this comment. =20 =20 Section 6. VPTS Model Versus VPLS Model "An issue with the above rule is that if a pseudowire between PEs fails, frames will not get forwarded between the PEs where pseudowire went down." =20 I think this is only true for a simple full mesh VPLS where there are = not other protection mechanisms. I am not sure this is applicable to H-VPLS with PW = redundancy, for example,=20 which I think is likely to be a widespread deployment case for the VPLS = model of TRILL=20 over MPLS. =20 Andy: I agree. In addition, see section 4.4 of RFC 4742, which allows = the use of spanning tree in a VPLS network to provide redundancy in the = case of a failure in the VPLS. =20 =20 =20 Best regards Matthew =20 Cheers, Andy =20 =20 ------=_NextPart_000_0584_01D294F0.520CD400 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andrew and Matthew:

 

Thank you for the review.

 

Sue

 

From:= = rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Andrew G. = Malis
Sent: Monday, February 27, 2017 11:43 AM
To: = Bocci, Matthew (Nokia - GB)
Cc: rtg-dir@ietf.org; = draft-ietf-trill-transport-over-mpls@ietf.org; = trill@ietf.org
Subject: Re: [RTG-DIR] Routing Area Directorate = QA review of = draft-ietf-trill-transport-over-mpls-02

 

I=E2=80=99ve got some comments on Matthew=E2=80=99s = review, inline.

 

On Mon, = Feb 27, 2017 at 10:44 AM, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> = wrote:

Routing Area Directorate QA = review of draft-ietf-trill-transport-over-mpls-02

 

Hi,

 

I have been assigned the QA = reviewer for this draft. The general guidelines for QA reviews =

can be found at:

https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa =

 

These state:

 

  "When reviewing a = draft at WG Adoption, the QA Reviewer should

  determine whether the = draft is readable, understandable, makes sense

  and is a good start for a = WG draft. Any issues the QA Reviewer finds

  are written down, sent to = the mailing list and discussed for future

  = versions"

 

Here is my review of this = draft:

 

** Summary.

Generally, the draft is well = written - thank you. I have a few minor comments below,

mostly related to the = relationship between TRILL over MPLS and established VPLS = mechanisms.

 

** Is the draft = readable?

 

Yes. There are a few minor = grammatical errors and it would help if the draft was proof-read =

to weed-out these. An example = is:

Abstract

"..that are separated by = MPLS provider network."

s/by MPLS/by an MPLS

 

 

** Is the draft = understandable?

 

Yes, provided the reader is = familiar with TRILL, MPLS and VPLS.

 

** Does it make = sense?

I think it is mostly clear, but = I have a few comments, as follows:

 

Section 3.4. MPLS encapsulation = for VPLS model

 

"Use of VPLS [RFC4762] to = interconnect TRILL sites requires no changes to

a VPLS implementation, in = particular the use of Ethernet pseudowires

between VPLS PEs. A VPLS PE = receives normal Ethernet frames from an

RBridge (i.e., CE) and is not = aware that the CE is an RBridge device. As

a result, an MPLS-encapsulated = TRILL packet within the MPLS network will

use the format illustrated in = Appendix A of [RFC7173]."

 

It doesn't look like the = encapsulation shown in Appendix A of

RFC7173 takes account of the = case where PBB VPLS [RFC7041] is used in the provider's

MPLS network, but I would have = thought this would still be a valid VPLS type to transport

TRILL. It might be worth = qualifying your reference with some text to state that

this is just an example in the = non-PBB case.

 

Andy: As the author of this paragraph, I agree with = Matthew=E2=80=99s comment. We can change the last sentence to = say:

 

"As an example, an MPLS-encapsulated TRILL packet = within the MPLS network will

use the format illustrated in Appendix A of [RFC7173] = for the non-PBB case, or

in the PBB case, with the additional header fields = illustrated in [RFC7041]."

 

 

Section 4.1.1:

"TIR devices are a superset = of the VPLS-PE devices defined in [RFC4026] with the

additional functionality of = TRILL."

Is this really true? Later you = state that TIRs use PPP PWs, not the Ethernet PWs used in

VPLS. It is also not clear if = TRILL needs some of the LDP or BGP signaling extensions

used for VPLS. Wouldn't it be = cleaner just to define a TIR as a new kind of PE?

 

Andy: I also agree with this = comment.

 

 

Section 6. VPTS Model Versus = VPLS Model

"An issue with the above = rule is that if a pseudowire between PEs fails,

frames will not get forwarded = between the PEs where pseudowire went

down."

 

I think this is only true for a = simple full mesh VPLS where there are not other protection

mechanisms. I am not sure this = is applicable to H-VPLS with PW redundancy, for example,

which I think is likely to be a = widespread deployment case for the VPLS model of TRILL

over MPLS.

 

Andy: I agree. In addition, see section 4.4 of RFC = 4742, which allows the use of spanning tree in a VPLS network to provide = redundancy in the case of a failure in the = VPLS.

 

 

 

 Best regards

 Matthew

 

Cheers,

Andy

 

 

------=_NextPart_000_0584_01D294F0.520CD400-- From nobody Sat Mar 4 11:14:50 2017 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 6B46E129572; Sat, 4 Mar 2017 11:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj9iq81ZkdZo; Sat, 4 Mar 2017 11:14:47 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE20129519; Sat, 4 Mar 2017 11:14:47 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id u48so92845694wrc.0; Sat, 04 Mar 2017 11:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GZmSBVorzR7ElOWwi/7Lh6F0ti4i3g4cDuOBRYu9xFA=; b=qeE8H71s/msTi3o19NtpySnbduBxBmyjlh2Ecsg2OFGr9GpXL//ZmUcBRGF/ZEHvs8 dCVaw/s2CXupMlhzw8+f2PGXRtd53r0DP/5ozaz/djcPB/nXnX7nSxcxAfNNebxB9Y27 lfBNazuEU+/oyeZIC6I4naxvcY+yEBeTfqce/01SouDesJtF0jG/lyAT87MxDXTh13J6 tD3rp45EBxsVNQG2DIhf9I4paK8Zc9j5HiClpHAu6QHFStKgKOUVyVlx6hlQoLJZsLij lEw4N1RPthPD3GD2Ghq5b5yCuPCQqnVSg3NZwVfpaihg41edrqQ4vxrssmsgE8rWBmGi RxGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GZmSBVorzR7ElOWwi/7Lh6F0ti4i3g4cDuOBRYu9xFA=; b=bjDOUGuSfFPQgl6UAlnGoIURuXqINYnORU0HMfH3xHFISjQmmrk7364fNp66nDYFlc BANBzznC8YbMqZUqF0O419Tph80djKvhq2vc77Bu1unO1HX5bFGnncBSG4nEj1TYQIXx X+IjSnwXZ96Mts6iPbJ8xhiU9J0tqjPfMjtVPaLQr++9gT6PJT5c6Lcygat7HBplIpuh zWlW52a0AjPUA48FOL0DF8hUgx9gXhk+nLGLBEKMMaU8vNERJa1hWV41WS0n3a8vBz4o OldtAlAq+KV3RCeAXsn848AZ1mvxDnRexN4JuHQlVIOSSutgm4L0YJ++8OD7YNQ20AxP ejMw== X-Gm-Message-State: AMke39mJOvwQT1c8m7snEOVjw1h1c8DtOiOfVeELbkC+I/wRpyYv6uEr0vcPXoWxKE8hD0iBKY+ijcrQg1N4Hg== X-Received: by 10.223.161.156 with SMTP id u28mr7678480wru.203.1488654885561; Sat, 04 Mar 2017 11:14:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.153.164 with HTTP; Sat, 4 Mar 2017 11:14:45 -0800 (PST) In-Reply-To: <058301d2951a$3ae0b920$b0a22b60$@ndzh.com> References: <8FA0B47D-32C0-41D0-BBDD-35F430DC44EE@nokia.com> <058301d2951a$3ae0b920$b0a22b60$@ndzh.com> From: Kingston Smiler Date: Sun, 5 Mar 2017 00:44:45 +0530 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=f403045f225ea5aeef0549ec79cb Archived-At: Cc: "Bocci, Matthew \(Nokia - GB\)" , rtg-dir@ietf.org, draft-ietf-trill-transport-over-mpls@ietf.org, trill@ietf.org Subject: Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 19:14:49 -0000 --f403045f225ea5aeef0549ec79cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andrew and Matthew, Thanks for the review. We are working on the revised draft Regards, S. Kingston Smiler. On Sun, Mar 5, 2017 at 12:35 AM, Susan Hares wrote: > Andrew and Matthew: > > > > Thank you for the review. > > > > Sue > > > > *From:* rtg-dir [mailto:rtg-dir-bounces@ietf.org] *On Behalf Of *Andrew > G. Malis > *Sent:* Monday, February 27, 2017 11:43 AM > *To:* Bocci, Matthew (Nokia - GB) > *Cc:* rtg-dir@ietf.org; draft-ietf-trill-transport-over-mpls@ietf.org; > trill@ietf.org > *Subject:* Re: [RTG-DIR] Routing Area Directorate QA review of > draft-ietf-trill-transport-over-mpls-02 > > > > I=E2=80=99ve got some comments on Matthew=E2=80=99s review, inline. > > > > On Mon, Feb 27, 2017 at 10:44 AM, Bocci, Matthew (Nokia - GB) < > matthew.bocci@nokia.com> wrote: > > Routing Area Directorate QA review of draft-ietf-trill-transport- > over-mpls-02 > > > > Hi, > > > > I have been assigned the QA reviewer for this draft. The general > guidelines for QA reviews > > can be found at: > > https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa > > > > These state: > > > > "When reviewing a draft at WG Adoption, the QA Reviewer should > > determine whether the draft is readable, understandable, makes sense > > and is a good start for a WG draft. Any issues the QA Reviewer finds > > are written down, sent to the mailing list and discussed for future > > versions" > > > > Here is my review of this draft: > > > > ** Summary. > > Generally, the draft is well written - thank you. I have a few minor > comments below, > > mostly related to the relationship between TRILL over MPLS and establishe= d > VPLS mechanisms. > > > > ** Is the draft readable? > > > > Yes. There are a few minor grammatical errors and it would help if the > draft was proof-read > > to weed-out these. An example is: > > Abstract > > "..that are separated by MPLS provider network." > > s/by MPLS/by an MPLS > > > > > > ** Is the draft understandable? > > > > Yes, provided the reader is familiar with TRILL, MPLS and VPLS. > > > > ** Does it make sense? > > I think it is mostly clear, but I have a few comments, as follows: > > > > Section 3.4. MPLS encapsulation for VPLS model > > > > "Use of VPLS [RFC4762] to interconnect TRILL sites requires no changes to > > a VPLS implementation, in particular the use of Ethernet pseudowires > > between VPLS PEs. A VPLS PE receives normal Ethernet frames from an > > RBridge (i.e., CE) and is not aware that the CE is an RBridge device. As > > a result, an MPLS-encapsulated TRILL packet within the MPLS network will > > use the format illustrated in Appendix A of [RFC7173]." > > > > It doesn't look like the encapsulation shown in Appendix A of > > RFC7173 takes account of the case where PBB VPLS [RFC7041] is used in the > provider's > > MPLS network, but I would have thought this would still be a valid VPLS > type to transport > > TRILL. It might be worth qualifying your reference with some text to stat= e > that > > this is just an example in the non-PBB case. > > > > Andy: As the author of this paragraph, I agree with Matthew=E2=80=99s com= ment. We > can change the last sentence to say: > > > > "As an example, an MPLS-encapsulated TRILL packet within the MPLS network > will > > use the format illustrated in Appendix A of [RFC7173] for the non-PBB > case, or > > in the PBB case, with the additional header fields illustrated in > [RFC7041]." > > > > > > Section 4.1.1: > > "TIR devices are a superset of the VPLS-PE devices defined in [RFC4026] > with the > > additional functionality of TRILL." > > Is this really true? Later you state that TIRs use PPP PWs, not the > Ethernet PWs used in > > VPLS. It is also not clear if TRILL needs some of the LDP or BGP signalin= g > extensions > > used for VPLS. Wouldn't it be cleaner just to define a TIR as a new kind > of PE? > > > > Andy: I also agree with this comment. > > > > > > Section 6. VPTS Model Versus VPLS Model > > "An issue with the above rule is that if a pseudowire between PEs fails, > > frames will not get forwarded between the PEs where pseudowire went > > down." > > > > I think this is only true for a simple full mesh VPLS where there are not > other protection > > mechanisms. I am not sure this is applicable to H-VPLS with PW redundancy= , > for example, > > which I think is likely to be a widespread deployment case for the VPLS > model of TRILL > > over MPLS. > > > > Andy: I agree. In addition, see section 4.4 of RFC 4742, which allows the > use of spanning tree in a VPLS network to provide redundancy in the case = of > a failure in the VPLS. > > > > > > > > Best regards > > Matthew > > > > Cheers, > > Andy > > > > > --f403045f225ea5aeef0549ec79cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew and Matthew,

Thanks for the r= eview. We are working on the revised draft=C2=A0

R= egards,
S. Kingston Smiler.

On Sun, Mar 5, 2017 at 12:35 AM, Susan Hare= s <shares@ndzh.com> wrote:
<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">

A= ndrew and Matthew:

=C2=A0

Thank you for the review.

=C2=A0

Sue =

=C2=A0<= u>

From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Andrew G= . Malis
Sent: Monday, February 27, 2017 11:43 AM
To: Bo= cci, Matthew (Nokia - GB)
Cc: rtg-dir@ietf.org; draft-ietf-trill-transport= -over-mpls@ietf.org; trill@ietf.org
Subject: Re: [RTG-DIR] Routing Area Dir= ectorate QA review of draft-ietf-trill-transport-over-mpls-02

=C2=A0=

I=E2=80=99ve got some comments on Ma= tthew=E2=80=99s review, inline.

=C2=A0

On Mon, Feb 27, 2017 = at 10:44 AM, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:

Routing Area Directorate QA review of draft-ietf-trill-tr= ansport-over-mpls-02<= /p>

= =C2=A0

Hi,

=C2=A0

I have been assigned the QA reviewer for this draft. The genera= l guidelines for QA reviews

can be found at:

http= s://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa

=C2=A0=

These state:

=C2=A0<= /span>

= =C2=A0 "When reviewing= a draft at WG Adoption, the QA Reviewer should=

=C2=A0 determine whether the draft is readable, under= standable, makes sense

=

=C2= =A0 and is a good start for a WG draft. Any issues the QA Reviewer finds

=C2=A0 are written down, sent= to the mailing list and discussed for future

=C2=A0 versions"=

=C2=A0

Here i= s my review of this draft:=

= =C2=A0

** Summary.

Generally, the draft is well writte= n - thank you. I have a few minor comments below,

mostly related to the relationship between TRILL ov= er MPLS and established VPLS mechanisms.=

=C2=A0

** Is = the draft readable?

=C2=A0<= /span>

= Yes. There are a few minor = grammatical errors and it would help if the draft was proof-read

to weed-out these. An example is:

<= span lang=3D"EN-GB" style=3D"font-size:11.0pt">Abstract

"..that are separated by MPLS provider ne= twork."

s/by MPLS/by= an MPLS

=C2=A0

=C2=A0=

** Is the draft understandable?

=C2=A0

Yes, provided the reader is familiar with TRILL, MPLS and VPLS.

=C2=A0<= u>

** Does it make sense?=

I think it is mostly clear, but I have a few comments, as= follows:

=C2=A0

Section 3.4. MPLS encapsulation for V= PLS model

=C2=A0

"Use of VPLS [RFC4762] to interc= onnect TRILL sites requires no changes to

a VPLS implementation, in particular the use of Ethernet pse= udowires

between VPLS PEs. = A VPLS PE receives normal Ethernet frames from an

RBridge (i.e., CE) and is not aware that the CE is a= n RBridge device. As

a resu= lt, an MPLS-encapsulated TRILL packet within the MPLS network will

use the format illustrated in Appen= dix A of [RFC7173]."<= /p>

= =C2=A0

It doesn't look = like the encapsulation shown in Appendix A of

RFC7173 takes account of the case where PBB VPLS [RFC704= 1] is used in the provider's =

MPLS network, but I would have thought this would still be a valid V= PLS type to transport

=

TRIL= L. It might be worth qualifying your reference with some text to state that=

this is just an example i= n the non-PBB case.

=C2=A0

Andy: As the author of this paragraph, I agree with Mat= thew=E2=80=99s comment. We can change the last sentence to say:

=C2=A0

=

"As an example, an MPLS-encapsulated TRILL= packet within the MPLS network will

use the format illustrated in Appendix A of [RFC7173] for th= e non-PBB case, or

in the PBB case, with the additional header fields illustrated in [RFC7041= ]."

=C2=A0

= =C2=A0

Section 4.1.1:

"TIR devices are a superset= of the VPLS-PE devices defined in [RFC4026] with the

additional functionality of TRILL."=

Is this really true? Later you st= ate that TIRs use PPP PWs, not the Ethernet PWs used in

VPLS. It is also not clear if TRILL needs s= ome of the LDP or BGP signaling extensions <= /u>

used for VPLS. Wouldn't it be cleaner just to define a= TIR as a new kind of PE?<= /p>

=C2=A0

Andy: I also agree with this comment= .

=C2=A0

=C2=A0

Section 6. VPTS Model Versus = VPLS Model

"An issue w= ith the above rule is that if a pseudowire between PEs fails,

frames will not get forwarded between th= e PEs where pseudowire went

down."

=C2=A0

I think this is only true for a = simple full mesh VPLS where there are not other protection

mechanisms. I am not sure this is applicabl= e to H-VPLS with PW redundancy, for example,

which I think is likely to be a widespread deployment ca= se for the VPLS model of TRILL

over MPLS.

<= /div>

=C2=A0

Andy: I agree. In addition, see section 4.4 of= RFC 4742, which allows the use of spanning tree in a VPLS network to provi= de redundancy in the case of a failure in the VPLS.

=

=C2=A0

=C2=A0

=C2=A0

=C2=A0Best regards

=

=C2=A0Matthew=

=C2=A0

Cheers,=

Andy

=C2=A0

=C2=A0


--f403045f225ea5aeef0549ec79cb-- From nobody Mon Mar 6 20:29:45 2017 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 09DD7129AF0; Mon, 6 Mar 2017 20:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHMAdTAwdRQO; Mon, 6 Mar 2017 20:29:43 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C408A126D73; Mon, 6 Mar 2017 20:29:42 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.16.251; From: "Susan Hares" To: Date: Mon, 6 Mar 2017 23:24:43 -0500 Message-ID: <010201d296fa$bf7f7f40$3e7e7dc0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01D296D0.D6AAFDE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKW+okay2QbsVyDTfmwcEjhs1omWg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: trill-chairs@ietf.org Subject: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/2016 - Second WG LC (3/7 to 3/20) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 04:29:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0103_01D296D0.D6AAFDE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We did not receive any comments on the WGLC for draft-ietf-p2mp-bfd-04.txt (https://www.ietf.org/mail-archive/web/trill/current/msg07692.html). Perhaps this was because I started the WG LC during Chinese new year. We will try a second WG LC before declaring "no support for this draft" In your comments please consider, 1) Does the support of multi-point BFD aid deployments? 2) Are the suggested additions to RFC7177 bootstrapping sufficient for this technology? 3) Do you feel this technology is ready for standardization? Sue Hares ------=_NextPart_000_0103_01D296D0.D6AAFDE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We did not = receive any comments on the WGLC for draft-ietf-p2mp-bfd-04.txt (https://www.ietf.org/mail-archive/web/trill/current/msg07692.html).=   Perhaps this was because I started the WG LC during Chinese new = year.   We will try a second WG LC before declaring “no = support for this draft”  

 

In your = comments please consider,

=

1)      = Does the support of multi-point BFD aid deployments?

2)      Are the suggested = additions to RFC7177 bootstrapping sufficient for this = technology?

3)      Do you feel this = technology is ready for standardization?

 

Sue Hares =

------=_NextPart_000_0103_01D296D0.D6AAFDE0-- From nobody Mon Mar 6 22:56:33 2017 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 607BA1295F1 for ; Mon, 6 Mar 2017 22:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppXwPOzG2DAZ for ; Mon, 6 Mar 2017 22:56:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31FA1295E2 for ; Mon, 6 Mar 2017 22:56:29 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCI02273; Tue, 07 Mar 2017 06:56:27 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Mar 2017 06:54:37 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.77]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Tue, 7 Mar 2017 14:54:30 +0800 From: "Liubing (Remy)" To: "trill@ietf.org" Thread-Topic: RE: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/2016 - Second WG LC (3/7 to 3/20) Thread-Index: AdKXD6tHpmqiZjuzQcWYIOGp+n6/mw== Date: Tue, 7 Mar 2017 06:54:30 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.180.83] Content-Type: multipart/alternative; boundary="_000_BB09947B5326FE42BA3918FA28765C2ECC00D3DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58BE599C.0046, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.77, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 33fb624740b6cc6ce5429e749551454b Archived-At: Subject: Re: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/2016 - Second WG LC (3/7 to 3/20) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 06:56:32 -0000 --_000_BB09947B5326FE42BA3918FA28765C2ECC00D3DGGEMM506MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The mBFD supports the fast detection of faults of a distribution trees so I= believe it aids the deployment of TRILL. The bootstrapping add-on looks fi= ne. Support for its publication. Thanks, Remy From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, March 07, 2017 12:25 PM To: trill@ietf.org Cc: trill-chairs@ietf.org Subject: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/201= 6 - Second WG LC (3/7 to 3/20) We did not receive any comments on the WGLC for draft-ietf-p2mp-bfd-04.txt = (https://www.ietf.org/mail-archive/web/trill/current/msg07692.html). Perha= ps this was because I started the WG LC during Chinese new year. We will = try a second WG LC before declaring "no support for this draft" In your comments please consider, 1) Does the support of multi-point BFD aid deployments? 2) Are the suggested additions to RFC7177 bootstrapping sufficient for= this technology? 3) Do you feel this technology is ready for standardization? Sue Hares --_000_BB09947B5326FE42BA3918FA28765C2ECC00D3DGGEMM506MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The mBFD supports the fast detection of faults of a distribution = trees so I believe it aids the deployment of TRILL. The bootstrapping add-o= n looks fine.

 

Support for its publication.

 

Thanks,

Remy

 

From: trill [mail= to:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, March 07, 2017 12:25 PM
To: trill@ietf.org
Cc: trill-chairs@ietf.org
Subject: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2= /21/2016 - Second WG LC (3/7 to 3/20)

 

We did not receive any comments= on the WGLC for draft-ietf-p2mp-bfd-04.txt (https://www.ietf.org/mail-a= rchive/web/trill/current/msg07692.html).  Perhaps this was because I started the WG LC during Chinese new year. = ;  We will try a second WG LC before declaring “no support for t= his draft”  

 

In your comments please conside= r,

 

1)     = ; Does the support of multi-point BFD aid deployments?

2)     = ; Are the suggested additions to RFC7177 bootstrapping sufficient for this = technology?

3)     = ; Do you feel this technology is ready for standardization?

 

Sue Hares

 

--_000_BB09947B5326FE42BA3918FA28765C2ECC00D3DGGEMM506MBSchina_-- From nobody Mon Mar 6 22:58:04 2017 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 6C2931295F8; Mon, 6 Mar 2017 22:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk_g0WV9T_de; Mon, 6 Mar 2017 22:58:01 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCBF1295F1; Mon, 6 Mar 2017 22:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5473; q=dns/txt; s=iport; t=1488869881; x=1490079481; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iINv0UCpNxJcJX2eVxvCnEHgY7PmaqhAk/tSvoCaWfU=; b=cQeNSRwMsXdJkLcfC59Jq/HlA2KIUc7OPVcrd5FmZZs4gSqqrYF8lLNB YulmxX4Y7VmmHgfFhxBSzDiiWO7c2cwAmQkRoC0EbXdIifuGImxrExs/g 25ypRUA3B5esEH345qyKWN8kclv6hSR/uIGdedUUb37DRUuVV8GERGG5e E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBgWb5Y/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYEKB41kkUqQC4Usgg0qhXgCgio/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEELUwQAgEIDgMEAQEkBAcyFAkIAQEEAQ0FCIl0DrFkinkBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYZOhG+ENwEBUYUvBZwwAZIsggSFIooCjx6EHAEfOIEDVhW?= =?us-ascii?q?FEx0ZgUp1AYdkgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,257,1484006400"; d="scan'208,217";a="394452910" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2017 06:58:00 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v276w0DF025125 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2017 06:58:00 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Mar 2017 00:57:59 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Tue, 7 Mar 2017 00:57:59 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Susan Hares , "trill@ietf.org" Thread-Topic: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/2016 - Second WG LC (3/7 to 3/20) Thread-Index: AdKW+okay2QbsVyDTfmwcEjhs1omWgAFY9pQ Date: Tue, 7 Mar 2017 06:57:59 +0000 Message-ID: References: <010201d296fa$bf7f7f40$3e7e7dc0$@ndzh.com> In-Reply-To: <010201d296fa$bf7f7f40$3e7e7dc0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.25.228] Content-Type: multipart/alternative; boundary="_000_c3cacbc50f8b4613b24b59d3994cc711XCHRCD020ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "trill-chairs@ietf.org" Subject: Re: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/2016 - Second WG LC (3/7 to 3/20) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 06:58:03 -0000 --_000_c3cacbc50f8b4613b24b59d3994cc711XCHRCD020ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as co-author of this draft. Also am not aware of any IP related to = this draft. Thanks Prasad From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, March 07, 2017 9:55 AM To: trill@ietf.org Cc: trill-chairs@ietf.org Subject: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/201= 6 - Second WG LC (3/7 to 3/20) We did not receive any comments on the WGLC for draft-ietf-p2mp-bfd-04.txt = (https://www.ietf.org/mail-archive/web/trill/current/msg07692.html). Perha= ps this was because I started the WG LC during Chinese new year. We will = try a second WG LC before declaring "no support for this draft" In your comments please consider, 1) Does the support of multi-point BFD aid deployments? 2) Are the suggested additions to RFC7177 bootstrapping sufficient for= this technology? 3) Do you feel this technology is ready for standardization? Sue Hares --_000_c3cacbc50f8b4613b24b59d3994cc711XCHRCD020ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support as co-author o= f this draft. Also am not aware of any IP related to this draft.=

Thanks

Prasad

 

From: trill [mailto:trill-bounces@ietf.org] <= b>On Behalf Of Susan Hares
Sent: Tuesday, March 07, 2017 9:55 AM
To: trill@ietf.org
Cc: trill-chairs@ietf.org
Subject: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2= /21/2016 - Second WG LC (3/7 to 3/20)

 

We did not receive any comments on the WGLC for draf= t-ietf-p2mp-bfd-04.txt (https://www.ietf.org/mail-archive/web/trill/curr= ent/msg07692.html).  Perhaps this was because I started the WG LC during Chinese new year.   We wi= ll try a second WG LC before declaring “no support for this draftR= 21;  

 

In your comments please consider,

 

1)      Does the support of= multi-point BFD aid deployments?

2)      Are the suggested a= dditions to RFC7177 bootstrapping sufficient for this technology?

3)      Do you feel this te= chnology is ready for standardization?

 

Sue Hares

--_000_c3cacbc50f8b4613b24b59d3994cc711XCHRCD020ciscocom_-- From nobody Wed Mar 8 09:20:18 2017 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 5C9CB1294D0; Wed, 8 Mar 2017 09:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzS2HgaIZHxg; Wed, 8 Mar 2017 09:20:16 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDC5129463; Wed, 8 Mar 2017 09:20:16 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: Date: Wed, 8 Mar 2017 12:15:13 -0500 Message-ID: <01ca01d2982f$8cd2b630$a6782290$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CB_01D29805.A3FDBFA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKYL28VjGBUmISHQZKKnx7STBxb/g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: trill-chairs@ietf.org Subject: Re: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017) - No consensus X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:20:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01CB_01D29805.A3FDBFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit TRILL WG: Draft-ietf-trill-address-flush has no consensus. After a new revision is published, we will try the WG last call. Sue Hares ------=_NextPart_000_01CB_01D29805.A3FDBFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TRILL WG: =

 

Draft-ietf-trill-address-flush has no = consensus.   After a new revision is published, we will try = the WG last call.

 

Sue Hares =

------=_NextPart_000_01CB_01D29805.A3FDBFA0-- From nobody Thu Mar 9 05:38:11 2017 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 9D8281295FE; Thu, 9 Mar 2017 05:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJiQKESU91CG; Thu, 9 Mar 2017 05:38:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91E81295E2; Thu, 9 Mar 2017 05:38:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIO83239; Thu, 09 Mar 2017 13:38:00 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 9 Mar 2017 13:37:59 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.160]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 9 Mar 2017 21:37:55 +0800 From: "Zhangmingui (Martin)" To: "Vengada Prasad Govindan (venggovi)" , Susan Hares , "trill@ietf.org" Thread-Topic: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/2016 - Second WG LC (3/7 to 3/20) Thread-Index: AdKW+okay2QbsVyDTfmwcEjhs1omWgAFY9pQAHJnzkM= Date: Thu, 9 Mar 2017 13:37:55 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A63DF569@NKGEML515-MBS.china.huawei.com> References: <010201d296fa$bf7f7f40$3e7e7dc0$@ndzh.com>, 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.46.117.65] Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E7A63DF569NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58C15ABA.008D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3c3d6827ae97df7b850dc016d04eccef Archived-At: Cc: "trill-chairs@ietf.org" Subject: Re: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/2016 - Second WG LC (3/7 to 3/20) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 13:38:09 -0000 --_000_4552F0907735844E9204A62BBDD325E7A63DF569NKGEML515MBSchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support. Multi-poing BFD can be used by TRILL distribution trees. Thanks, Mingui ________________________________ From: trill [trill-bounces@ietf.org] on behalf of Vengada Prasad Govindan (= venggovi) [venggovi@cisco.com] Sent: Tuesday, March 07, 2017 14:57 To: Susan Hares; trill@ietf.org Cc: trill-chairs@ietf.org Subject: Re: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21= /2016 - Second WG LC (3/7 to 3/20) Support as co-author of this draft. Also am not aware of any IP related to = this draft. Thanks Prasad From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, March 07, 2017 9:55 AM To: trill@ietf.org Cc: trill-chairs@ietf.org Subject: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/201= 6 - Second WG LC (3/7 to 3/20) We did not receive any comments on the WGLC for draft-ietf-p2mp-bfd-04.txt = (https://www.ietf.org/mail-archive/web/trill/current/msg07692.html). Perha= ps this was because I started the WG LC during Chinese new year. We will = try a second WG LC before declaring =93no support for this draft=94 In your comments please consider, 1) Does the support of multi-point BFD aid deployments? 2) Are the suggested additions to RFC7177 bootstrapping sufficient for= this technology? 3) Do you feel this technology is ready for standardization? Sue Hares --_000_4552F0907735844E9204A62BBDD325E7A63DF569NKGEML515MBSchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Support.

 

Multi-poing BFD can be used by TRILL distribution trees.

 

Thanks,

Mingui

From: trill [trill-bounces@ietf.org] on beha= lf of Vengada Prasad Govindan (venggovi) [venggovi@cisco.com]
Sent: Tuesday, March 07, 2017 14:57
To: Susan Hares; trill@ietf.org
Cc: trill-chairs@ietf.org
Subject: Re: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 = to 2/21/2016 - Second WG LC (3/7 to 3/20)

Support as co-author = of this draft. Also am not aware of any IP related to this draft.

Thanks

Prasad

 

From: trill [mailto:trill-bounces@ietf.org] <= b>On Behalf Of Susan Hares
Sent: Tuesday, March 07, 2017 9:55 AM
To: trill@ietf.org
Cc: trill-chairs@ietf.org
Subject: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2= /21/2016 - Second WG LC (3/7 to 3/20)

 

We did not receive any comments on the WGLC for draf= t-ietf-p2mp-bfd-04.txt (https://www.ietf.org/mail-arch= ive/web/trill/current/msg07692.html).  Perhaps this was because I started the WG LC during Chinese new year. = ;  We will try a second WG LC before declaring =93no support for this = draft=94  

 

In your comments please consider,

 

1)      Does the support of= multi-point BFD aid deployments?

2)      Are the suggested a= dditions to RFC7177 bootstrapping sufficient for this technology?

3)      Do you feel this te= chnology is ready for standardization?

 

Sue Hares

--_000_4552F0907735844E9204A62BBDD325E7A63DF569NKGEML515MBSchi_-- From nobody Thu Mar 9 22:39:48 2017 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 836761294DB; Thu, 9 Mar 2017 22:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsO3y_zT0KHy; Thu, 9 Mar 2017 22:39:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B996F12940B; Thu, 9 Mar 2017 22:39:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIP83157; Fri, 10 Mar 2017 06:39:41 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 10 Mar 2017 06:39:39 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.105]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Fri, 10 Mar 2017 14:39:31 +0800 From: Vero Zheng To: "Zhangmingui (Martin)" , "Vengada Prasad Govindan (venggovi)" , Susan Hares , "trill@ietf.org" Thread-Topic: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/2016 - Second WG LC (3/7 to 3/20) Thread-Index: AdKW+okay2QbsVyDTfmwcEjhs1omWgAFY9pQAHJnzkMAI6B98A== Date: Fri, 10 Mar 2017 06:39:30 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5CAA9427C3@SZXEMA504-MBS.china.huawei.com> References: <010201d296fa$bf7f7f40$3e7e7dc0$@ndzh.com>, <4552F0907735844E9204A62BBDD325E7A63DF569@NKGEML515-MBS.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E7A63DF569@NKGEML515-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.118] Content-Type: multipart/alternative; boundary="_000_2EEA459CD95CCB4988BFAFC0F2287B5CAA9427C3SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58C24A2E.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 34ab9fd46bed0ccc52a36fbde3b2880a Archived-At: Cc: "trill-chairs@ietf.org" Subject: [trill] =?gb2312?b?tPC4tDogIFdHIExDIG9uIGRyYWZ0LWlldGYtcDJtcC1i?= =?gb2312?b?ZmQtMDQudHh0IC0gMi83LzIwMTYgdG8gMi8yMS8yMDE2IC0gU2Vjb25kIFdH?= =?gb2312?b?IExDICgzLzcgdG8gMy8yMCk=?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 06:39:46 -0000 --_000_2EEA459CD95CCB4988BFAFC0F2287B5CAA9427C3SZXEMA504MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NClRoZSBzdXBwb3J0IG9mIFAyTVAgQkZEIGluIFRSSUxMIGlzIGVzc2VudGlhbCBm b3IgVFJJTEwgbXVsdGljYXN0IGZhaWx1cmUgZGV0ZWN0aW9uLg0KDQpSZWdhcmRzLA0KVmVybw0K DQq3orz+yMs6IHRyaWxsIFttYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBaaGFu Z21pbmd1aSAoTWFydGluKQ0Kt6LLzcqxvOQ6IDIwMTfE6jPUwjnI1SAyMTozOA0KytW8/sjLOiBW ZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiAodmVuZ2dvdmkpOyBTdXNhbiBIYXJlczsgdHJpbGxAaWV0 Zi5vcmcNCrOty806IHRyaWxsLWNoYWlyc0BpZXRmLm9yZw0K1vfM4jogUmU6IFt0cmlsbF0gV0cg TEMgb24gZHJhZnQtaWV0Zi1wMm1wLWJmZC0wNC50eHQgLSAyLzcvMjAxNiB0byAyLzIxLzIwMTYg LSBTZWNvbmQgV0cgTEMgKDMvNyB0byAzLzIwKQ0KDQoNClN1cHBvcnQuDQoNCg0KDQpNdWx0aS1w b2luZyBCRkQgY2FuIGJlIHVzZWQgYnkgVFJJTEwgZGlzdHJpYnV0aW9uIHRyZWVzLg0KDQoNCg0K VGhhbmtzLA0KDQpNaW5ndWkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IHRyaWxsIFt0cmlsbC1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgVmVuZ2FkYSBQ cmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKSBbdmVuZ2dvdmlAY2lzY28uY29tXQ0KU2VudDogVHVl c2RheSwgTWFyY2ggMDcsIDIwMTcgMTQ6NTcNClRvOiBTdXNhbiBIYXJlczsgdHJpbGxAaWV0Zi5v cmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPg0KQ2M6IHRyaWxsLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86dHJpbGwtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmlsbF0gV0cgTEMgb24g ZHJhZnQtaWV0Zi1wMm1wLWJmZC0wNC50eHQgLSAyLzcvMjAxNiB0byAyLzIxLzIwMTYgLSBTZWNv bmQgV0cgTEMgKDMvNyB0byAzLzIwKQ0KU3VwcG9ydCBhcyBjby1hdXRob3Igb2YgdGhpcyBkcmFm dC4gQWxzbyBhbSBub3QgYXdhcmUgb2YgYW55IElQIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC4NClRo YW5rcw0KUHJhc2FkDQoNCkZyb206IHRyaWxsIFttYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFN1c2FuIEhhcmVzDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwNywgMjAx NyA5OjU1IEFNDQpUbzogdHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPg0KQ2M6 IHRyaWxsLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86dHJpbGwtY2hhaXJzQGlldGYub3JnPg0KU3Vi amVjdDogW3RyaWxsXSBXRyBMQyBvbiBkcmFmdC1pZXRmLXAybXAtYmZkLTA0LnR4dCAtIDIvNy8y MDE2IHRvIDIvMjEvMjAxNiAtIFNlY29uZCBXRyBMQyAoMy83IHRvIDMvMjApDQoNCldlIGRpZCBu b3QgcmVjZWl2ZSBhbnkgY29tbWVudHMgb24gdGhlIFdHTEMgZm9yIGRyYWZ0LWlldGYtcDJtcC1i ZmQtMDQudHh0IChodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3RyaWxsL2N1 cnJlbnQvbXNnMDc2OTIuaHRtbCkuICBQZXJoYXBzIHRoaXMgd2FzIGJlY2F1c2UgSSBzdGFydGVk IHRoZSBXRyBMQyBkdXJpbmcgQ2hpbmVzZSBuZXcgeWVhci4gICBXZSB3aWxsIHRyeSBhIHNlY29u ZCBXRyBMQyBiZWZvcmUgZGVjbGFyaW5nIKGwbm8gc3VwcG9ydCBmb3IgdGhpcyBkcmFmdKGxDQoN CkluIHlvdXIgY29tbWVudHMgcGxlYXNlIGNvbnNpZGVyLA0KDQoxKSAgICAgIERvZXMgdGhlIHN1 cHBvcnQgb2YgbXVsdGktcG9pbnQgQkZEIGFpZCBkZXBsb3ltZW50cz8NCjIpICAgICAgQXJlIHRo ZSBzdWdnZXN0ZWQgYWRkaXRpb25zIHRvIFJGQzcxNzcgYm9vdHN0cmFwcGluZyBzdWZmaWNpZW50 IGZvciB0aGlzIHRlY2hub2xvZ3k/DQozKSAgICAgIERvIHlvdSBmZWVsIHRoaXMgdGVjaG5vbG9n eSBpcyByZWFkeSBmb3Igc3RhbmRhcmRpemF0aW9uPw0KDQpTdWUgSGFyZXMNCg== --_000_2EEA459CD95CCB4988BFAFC0F2287B5CAA9427C3SZXEMA504MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

The support of P2MP BFD in TRILL is essential for TRILL multicast= failure detection.

 

Regards,

Vero

 

=B7=A2=BC=FE=C8=CB: trill [= mailto:trill-bounces@ietf.org] =B4=FA= =B1=ED Zhangmingui (Martin)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2017=C4=EA3=D4=C29=C8=D5 21:38
=CA=D5=BC=FE=C8=CB: Vengada Prasad Govindan (venggovi); Susan Hares; trill@ietf.org
=B3=AD=CB=CD: trill-chairs@ietf.org
=D6=F7=CC=E2: Re: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 to 2/21/2016 -= Second WG LC (3/7 to 3/20)

 

Support.

 

Multi-poing BFD can be used = by TRILL distribution trees.

 

Thanks,

Mingui

From: trill [trill-bounces@ietf.org] on behalf of Vengada Prasad Govindan (venggovi) [venggovi@cisco.com]
Sent: Tuesday, March 07, 2017 14:57
To: Susan Hares; trill@ietf.org
Cc: trill-chairs@ietf.org
Subject: Re: [trill] WG LC on draft-ietf-p2mp-bfd-04.txt - 2/7/2016 = to 2/21/2016 - Second WG LC (3/7 to 3/20)

Support= as co-author of this draft. Also am not aware of any IP related to this dr= aft.

Thanks<= /span>

Prasad<= /span>

 

 

We did no= t receive any comments on the WGLC for draft-ietf-p2mp-bfd-04.txt (https://www.ietf.org/mail-archive/web/trill/current/msg07692.= html).  Perhaps this was because I started the WG LC during Chinese new year. = ;  We will try a second WG LC before declaring =A1=B0no support for th= is draft=A1=B1  

 

In your c= omments please consider,

 

1) &= nbsp;    Does the support of multi-point BFD aid deployments= ?

2) &= nbsp;    Are the suggested additions to RFC7177 bootstrappin= g sufficient for this technology?

3) &= nbsp;    Do you feel this technology is ready for standardiz= ation?

 

Sue Hares=

--_000_2EEA459CD95CCB4988BFAFC0F2287B5CAA9427C3SZXEMA504MBSchi_-- From nobody Fri Mar 10 07:03:28 2017 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 3BCD112996F; Fri, 10 Mar 2017 07:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=qAP8TcEK; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=CBerxPjc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRT4WLdLTaVH; Fri, 10 Mar 2017 07:03:25 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6375012997E; Fri, 10 Mar 2017 07:03:24 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E4D3220B3D; Fri, 10 Mar 2017 10:03:22 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Fri, 10 Mar 2017 10:03:22 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=1E5T3Ck3lUEHjPr oq0W6fiVtxHA=; b=qAP8TcEKWDTyygXUm45mzwxDcUk7WvoWc0MdJR9z+vHxvcY 4YifIPUbKogLL+ZbLA+8LO/pY7djDkE/7OgA5jhxRB/Jc9W2e6DqWls3MV5/Vk8m IcT3s0G5UCvw3G41Eyqt6CQqZANIIwpaH4ehzmIS9z8JVb6cbjGrTJNnuMGY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=1E5T3Ck3lUEHjProq0W6fiVtxHA=; b=CBerxPjcFOG5QmLmVy5u N7VZ5nChvUD/A9f+0rs2dL3BI4qQGofM68mWPyGxcxRXf/WiyGmltQqVUvSBBIB6 RNi6zGKke1T5/r/9P91bu/10QfSV2sNKlJQpQ61Njc+Kfr8THMPM2fovlVWIIa3O fJYw7KIKFLwlrPcn6IMbkuM= X-ME-Sender: X-Sasl-enc: EN7MsyL5oxQhFf3u1SDg9qB6GheVAdR75qaUgECIBCCs 1489158202 Received: from [10.234.90.71] (unknown [148.252.129.110]) by mail.messagingengine.com (Postfix) with ESMTPA id 90451244DA; Fri, 10 Mar 2017 10:03:22 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Fri, 10 Mar 2017 15:16:10 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <305DABD1-0E6E-4145-A21C-2D7BE390B7D8@fastmail.fm> References: <148476684392.2033.546851999767154453.idtracker@ietfa.amsl.com> <09692183-AC90-4862-8EA9-86A176C69EF8@fastmail.fm> To: Donald Eastlake Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:03:26 -0000 Hi Donald, > On 2 Mar 2017, at 22:45, Donald Eastlake wrote: >=20 > Hi Alexey, >=20 > Version -12, just posted, is intended to resolve your DISCUSS. My > apologies for taking so long. Could you take a look? I cleared. Thank you for the extra text. > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >=20 >> On Thu, Jan 19, 2017 at 4:48 AM, Alexey Melnikov = wrote: >> Hi Donald, >>=20 >>> On 19 Jan 2017, at 05:16, Donald Eastlake wrote: >>>=20 >>> Hi Alexey, >>>=20 >>>> On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov wrote: >>>> Alexey Melnikov has entered the following ballot position for >>>> draft-ietf-trill-directory-assist-mechanisms-11: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this= >>>> introductory paragraph, however.) >>>>=20 >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> In Section 3.1 there is a Version field. What are the condition(s) for >>>> bumping this version number? What backward compatibility guaranties are= >>>> expected (if any)? How would version negotiation be done? >>>=20 >>> Well, I could say that the answers to all of your questions are about >>> the same for this Version field as they are for the RBridge Channel >>> Header version field [RFC7178], the TRILL Header version field >>> [RFC6325], and many other version fields in IETF protocols but you >>> probably wouldn't consider that a very good answer. >>>=20 >>> I suppose if text was being added along this lines, it should say that >>> the version number must be incremented for a specification that does >>> not just specify new field values where that is allowed in version >>> zero but cannot be correctly parsed beyond the version nibble. Since >>> the protocol is a request/response protocol, the responder should >>> indicate the highest version number they understand but the response >>> must be valid in the version number specified in the request including >>> the possibility of indicating a valid error saying that the version is >>> not implemented. Thus all implementations of version X would need to >>> be able to at least send such an error for all versions from 0 through >>> X-1. Then you would add an explicit suberror code in Section 3.6.3 for >>> unimplemented version. For a version zero implementation, that would >>> be returned for any higher version. >>>=20 >>> However, I don't expect an incremented version number to be needed >>> anytime soon. Was it your intent with this DISCUSS to get something >>> like the above added to the draft? >>=20 >> Yes, exactly along the lines of your text above. >>=20 >>=20 From nobody Fri Mar 10 09:40:19 2017 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 508AE129417; Fri, 10 Mar 2017 09:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSdik3VYLOCa; Fri, 10 Mar 2017 09:40:16 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA79127077; Fri, 10 Mar 2017 09:40:15 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id m27so573890iti.0; Fri, 10 Mar 2017 09:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=KF+ALBcFEmSi4E3xNyfoYwUOKhld8O9uIW69kSA7+5g=; b=suxeOTjRBWABOahhhY/RrzA7RB/ivmHI7DjCHQ2VDJdW+qimJvQAZexumFX0ydIJ3r 7QQ+y0BcKv19emNmDpZ2JCY7k3/AMh17GlRh2TAuCskLpBGMia7/FNRbD7umn1pVlf5N xMjAfxS6xMScjNhQgEpcl7881lN3RvQxcxlZN9ZAsz1UlWrb2oMzU/2UrCh+998ba45f WVum94E3PTBmSysWlpzFzXo0gbJ3+1j6lKzIDvEcv4La53FRxEIb8f0MlHEt0AY7HeNV s9H4i/Hi5X3OwzP6uzepZO99dRQRj7dV/qumfZjwKEJdO1sAiwiSfKkrbQ/4Km/KkAVt CI4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=KF+ALBcFEmSi4E3xNyfoYwUOKhld8O9uIW69kSA7+5g=; b=n6Hj+D3ZAZXErAsP5q6pHdBnnVXDWuIn2AC66EdlmAxWVCsHCuBgwBXIsOwwnPxgEv yn369BgJJ3ggnkOEdJMVbj1GYiZETKIO9dfN+LbeHU8ObQA5/99I4YLFRyLBHv7Bv0XF u0lrcrhTdFQ0NqZdNcnxN1z92DAm7jyumdERzUAW/NwulUke23unc5qouwm/Ti8afebb lmmINY25Mz6juSi5dp2hEBjTv3SjgVLv8r/N3GA6sw1B5vshfiP0+UKLpMzSuJFbIc8m EmtkNpG/5eY2AJBxaycsSNiqhzz/Ck2ms8nDVC5ICrCUqf5dJhdaw1fjiqEzJad+np7e qRtg== X-Gm-Message-State: AFeK/H0rfXRYq0/Qmf4/bBeF1s+2PoG5fxYLz6DybQjTOqA9bMmww5ZI1xE3z09+T8nS+fJTYH2iIIBRYk4uFw== X-Received: by 10.36.170.68 with SMTP id y4mr145716iti.7.1489167615172; Fri, 10 Mar 2017 09:40:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Fri, 10 Mar 2017 09:39:59 -0800 (PST) From: Donald Eastlake Date: Fri, 10 Mar 2017 12:39:59 -0500 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" Subject: [trill] Call for TRILL Presentations X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:40:17 -0000 Hi, If you would like to present to the TRILL WG meeting the afternoon of 27 March at the upcoming IETF meeting in Chicago, Illinois, please contact trill-chair@ietf.org or post to this list by replying to this email. Arrangements can be made for remote presentations. Thanks, Donald (TRILL WG Secretary) =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Mar 3, 2017 at 6:55 PM, "IETF Secretariat" wrote: > Dear Donald Eastlake, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > trill Session 1 (1:30:00) > Monday, Afternoon Session II 1520-1650 > Room Name: Zurich B size: 100 > --------------------------------------------- > > > Request Information: > > --------------------------------------------------------- > Working Group Name: Transparent Interconnection of Lots of Links > Area Name: Routing Area > Session Requester: Donald Eastlake > > Number of Sessions: 1 > Length of Session(s): 1.5 Hours > Number of Attendees: 35 > Conflicts to Avoid: > First Priority: saag intarea idr i2rs netconf netmod bess i2nsf lpwan babel grow > Second Priority: isis sfc spring sidr dnsop > > > People who must be present: > Susan Hares > Donald E. Eastlake 3rd > Alia Atlas > Jon Hudson > > Resources Requested: > Meetecho support in room From nobody Fri Mar 10 20:40:41 2017 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 A1C11129470; Fri, 10 Mar 2017 20:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYneXSRGMVeP; Fri, 10 Mar 2017 20:40:34 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FDC120727; Fri, 10 Mar 2017 20:40:31 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id w124so1863290itb.0; Fri, 10 Mar 2017 20:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p0njDvUvVrGTvukYkjW8m8V1DR+dRJHFTaYneXpDl3Y=; b=VZ9Q7MJ+9geo5v1mnglIvAX+75Q1TVwbk8QXdNPfxGAVeBKxeXgXfl5TgH2PsFGYJ3 HWLJaA5o8Hv2hmL60tYaRYUXcwl5ZRuw1J7iwt2xzwoj9MsR6TTVKJYC1PG99dwDPG1R uZWcfo68A4PmA7dQfsXh+rh7aGF3itmDnT8U5YIuVtC1ERgX+OBtOjfMB5Iw/t41CeMI u0gQZttTLr+3/2V9JMq/mv+F0CDJbQ73tw77fZroQQazBKh3n8JoFor/DBOLR7DgIUfK wGfOSDqBtB8zs87P75zD6NpbTn/bd1mUPydxfUvC+WkPScSbQaJFfv549t1SWqKPQ9gg 4cwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p0njDvUvVrGTvukYkjW8m8V1DR+dRJHFTaYneXpDl3Y=; b=X3dolf4GSkabCcjgAV6w1iDCRHJsfUWEEVdxiLqg3t38I51GroxpH50ceN6tEiJBVF dkK7+vWGOE7UVd7o68juLqqJGhwDdkxytXqR6cbKZ0T4+hu9slalpS7QpMyzizFurgiE OSYxK0xyR+8Mitkw6eKGErYLgMk8i4dyH08FQiZtKXxBCK7tnoywl1MfTQYg8VT2Jljk XhLTtorrh2uH+ufg4Sxbl8SSZ1IU5UxlfFR3uRif/gPDIvDjcsDFDg+QFuMTw11Sm12v eC2PBUpyW19Kgh1jIk5q5GkFk4510FPEy92qPT7I9Y3RjoAyZGTv0hJKW1tkW5aCtAZ8 6z3g== X-Gm-Message-State: AFeK/H1qkWFWbi8gfJyRylAOwU0zHy3cr7v/VRs8u5qX8esHIwga8FgIGbP6LRYUvYI+V9DlLbGDZod+52GNbg== X-Received: by 10.36.88.202 with SMTP id f193mr2082495itb.14.1489207230669; Fri, 10 Mar 2017 20:40:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Fri, 10 Mar 2017 20:40:15 -0800 (PST) In-Reply-To: References: <148423706509.29345.14522113109638417885.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Fri, 10 Mar 2017 23:40:15 -0500 Message-ID: To: Dan Romascanu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benoit Claise , "ops-dir@ietf.org" , draft-ietf-trill-rfc6439bis.all@ietf.org, IETF Discussion , "trill@ietf.org" Subject: Re: [trill] Review of draft-ietf-trill-rfc6439bis-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 04:40:35 -0000 Hi Dan, Could you look at the recently posted version -05 to see if this resolves your comments? Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Jan 18, 2017 at 2:16 PM, Donald Eastlake wrote: > Hi Dan, > > On Tue, Jan 17, 2017 at 3:45 AM, Dan Romascanu wrote: >> Hi Donald, >> >> Thank you for your answer and explanations. They make sense to me, but I >> still beleive that the document may benefit if some edits are being done to >> clarify what may be the obvious for the people who know all details and >> history, but not for the other users of the document in the future - >> implementers and operators. > > Sure, I agree that it would benefit for the addition of some text here > and there./ > >> Specifically: >> >>> I am not aware of any case where this draft replaces a TLV in the >> sense of requiring use of a new TLV. It does provide some new TLVs >> and procedures that are believed to be superior to or useful additions >> to previous ones. But I am not aware of any case where it "obsoletes" >> previous provisions in the sense of prohibiting their use. >> >> The header of the document includes Obsoletes 6439. If part of the content >> of 6439 remains valid this needs to be clarified, If some superior TLVs and >> procedures are introduced there is a need to explain what will happen with >> the previous ones. Should they be implemented? deployed? activated? > > OK. Stating that essentially all of RFC 6439 is incorporated and > outlining what parts of the new draft are optional improvements over > which part of RFC 6439, etc. would probably be a good addition. > >>> I don't know that much is really required to be said about >> "transition" when you specify an optional optimization. Since it is >> optional, by implication the implementer is free to use it or not and >> things will work either way. This could be stated explicitly in those >> cases. >> >> If I understand what you say, the new features are optional (although the >> status of the document is Proposed Standard), they can or cannot be >> implemented (one, the other, both?) and the network will still work. Yes, I >> suggest to explicitly state this). > > OK. > >>> RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges) >> SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs >> 6850 and 7784. However, there are also YANG modules underway in >> draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and >> draft-ietf-trill-yang-pm. >> >>> It does not seem best for this rfc6439bis draft to change the >> implementation requirement level for SNMP or NETCONF for TRILL. If that >> were to be done, it seems like something more appropriate for the base >> TRILL YANG draft (draft-ietf-trill-yang-*) to do. >> >> If I was an implementer of TRILL, or an operator considering to deploy >> TRILL, I would have a hard time trying to understand what to implement and >> what to deploy as management interfaces. Maybe this is not the place but I >> believe that there need to be some documentation on this respect. > > OK. I think it would be reasonable to say something about the current > implementation requirement level of SNMPv3 and to say that YANG > modules are under development, so implementers will know more about > what is going on. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> Thanks and Regards, >> Dan >> >> >> On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake wrote: >>> >>> Hi Dan, >>> >>> Thanks for your review. As per my further response below, while the >>> draft could perhaps use some clarifying additions related to >>> operations, I do not believe it is as bad as you say. >>> >>> On Thu, Jan 12, 2017 at 11:04 AM, Dan Romascanu >>> wrote: >>> > >>> > Reviewer: Dan Romascanu >>> > Review result: Has Issues >>> > >>> > I have reviewed this document as part of the Operational >>> > directorate's ongoing effort to review all IETF documents being >>> > processed by the IESG. These comments were written with the intent >>> > of improving the operational aspects of the IETF drafts. Comments >>> > that are not addressed in last call may be included in AD reviews >>> > during the IESG review. Document editors and WG chairs should treat >>> > these comments just like any other last call comments. >>> > >>> > This document clarifies and updates the TRILL Appointed >>> > Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and >>> > obsoletes RFC 6439. >>> > >>> > It's a complex document which requires extra reading to understand >>> > the context and the interraction with other RFCs. I believe that >>> > from an OPS-DIR perspective there are issues that need to be >>> > discussed before the document can be approved. >>> > >>> > The main issues with the document in its current form are: >>> > >>> > 1. The document makes consistent changes in the way TRILL >>> > operates. It replaces TLVs and procedures, define new ones, >>> > obsoletes previous mechanisms that define VLAN mapping, and >>> >>> I am not aware of any case where this draft replaces a TLV in the >>> sense of requiring use of a new TLV. It does provide some new TLVs >>> and procedures that are believed to be superior to or useful additions >>> to previous ones. But I am not aware of any case where it "obsoletes" >>> previous provisions in the sense of prohibiting their use. >>> >>> > incorporates updated material from other RFCs. There is however no >>> > indication in the text about the transition between existing >>> > deployed versions of TRILL based on RFC 6439 and related protocols >>> > with the current updated mechanisms. Are these backward compatible? >>> >>> I don't know that much is really required to be said about >>> "transition" when you specify an optional optimization. Since it is >>> optional, by implication the implementer is free to use it or not and >>> things will work either way. This could be stated explicitly in those >>> cases. >>> >>> Much of the material in this draft comes from RFC 6439 or the parts of >>> RFC 7177 that updated RFC 6439. Most of the new material is optional >>> improved behaviors. >>> >>> The only mandatory new behavior is the mandatory support of the link >>> local E-L1CS flooding scope [RFC7357] specified in Section 8. There is >>> material in this draft covering backwards compatibility for this new >>> mandatory behavior. Section 8 already explains how to determine >>> whether or not all TRILL switches on a link support E-L1CS flooding >>> scope. The only use of E-L1CS flooding scope in this draft is as part >>> of a mechanism for the DRB (Designated RBridge (TRILL switch)) to >>> advertise Forwarder Appointments and, as stated in Section 2.1 (see >>> paragraph at the bottom of page 8 in draft -04), if any RBridge on the >>> link does not support E-L1CS, then the DRB MUST fall back to >>> advertising those appointments in Hellos. Section 8, which mandates >>> support of E-L1CS, also requires that any use of E-L1CS specified in >>> the future must provide for backward compatibility. >>> >>> > Do they need a simultaneous upgrade of the whole network? >>> >>> No. >>> >>> > 2. The document lacks a section or even minimal text concerning >>> > operational and manageability considerations. There are several >>> >>> Such a section can be added but there is not much to say. For example, >>> as explained below, there is very little specified in this document to >>> configure. >>> >>> > mentions in the text concerning network managers or operator >>> > actions, but there is no indication or reference to what management >>> > protocols and data models are to be used for configuration, >>> >>> RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges) >>> SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs >>> 6850 and 7784. However, there are also YANG modules underway in >>> draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and >>> draft-ietf-trill-yang-pm. >>> >>> It does not seem best for this rfc6439bis draft to change the >>> implementation requirement level for SNMP or NETCONF for TRILL. If that >>> were to be done, it seems like something more appropriate for the base >>> TRILL YANG draft (draft-ietf-trill-yang-*) to do. >>> >>> > retrieval of operational status information, or alerts. I believe >>> > that these need to be added explicitly or by reference. >>> >>> Reviewing the significant protocol additions in this draft at a high >>> level: >>> >>> - There is significant material about the various ways the Designated >>> RBridge on a link can announce who it is selecting as the Appointed >>> Forwarder on the link for various VLANs. The election of the >>> Designated RBridge depends on a configurable priority but that >>> election is unchanged from RFC 7177 and in fact is identical to the >>> election of the designated router on any IS-IS link. The decision on >>> which RBridges to appointer as forwarder for which VLAN is out of >>> scope. I don't see that there is anything to configure here, other >>> than RBridge priority to be DRB, which is already specified in other >>> RFCs. >>> >>> - There are some optional optimizations to the inhibition mechanism. >>> The inhibition mechanism is necessary for loop safety but any >>> RBridge can use or not use any of these optimizations, as they >>> choose, and things will work fine. >>> >>> - Port Shutdown message: There are two new configuration parameters >>> here, namely how many copies of the Port Shutdown message to send >>> and at what interval. These are listed, along with units and default >>> value in Section 6.6. >>> >>> - FGL-VLAN mapping consistency check: As specified in RFC 7172, in a >>> TRILL campus supporting Fine Grained Labels (FGL), the VLAN of a >>> native frame can be mapped to an FGL on ingress and an FGL is mapped >>> to a VLAN on egress. This draft makes no changes to that mechanism. >>> It merely provides that an RBridge performing such mapping can >>> optionally advertise the mapping it is performing at a port to other >>> RBridges with ports on the same link which can then check it for >>> consistency with any mapping they are performing. It is recommended >>> that the network operator be alerted to such inconsistency and there >>> is a configurable parameter for how long the inconsistency needs to >>> exist before such alert. Is it your position that some specific >>> protocol mechanism must be specified by which the network operator >>> is alerted? >>> >>> Thanks, >>> Donald >>> =============================== >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> d3e3e3@gmail.com >> >> From nobody Fri Mar 10 20:53:51 2017 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 CE77D128E18; Fri, 10 Mar 2017 20:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFmODp5q5_59; Fri, 10 Mar 2017 20:53:46 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0D1128874; Fri, 10 Mar 2017 20:53:46 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id h10so7130783ith.1; Fri, 10 Mar 2017 20:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Gny7FjKIjUK/gDtgLoARfJm5hzkXeDcHtWJDBP1nYP4=; b=l/g+W6g34UL7HhNn7oCd0XK87djDFp1dW8qO5eadgEcTTj5JZkCnFGscod7jlzzLpP 9aKdLl5jx9x6DI+mQ2l5ryKKFjUeT47eZhRWoWc5PL3yNjvHRxHYnISxFSznWvGgap6D 3I01QqTc9OW1l4/P43xMj8IJnJAZbAa/q2yHDa90DUqkuI3dlrfGWPeEipdtUwkFGX9/ W/mqyV6mJYQMmYBjnARenxjgaWmk8YWyJUpjoCFSN0tTdTS1YLT1ealn6mLqgAFfx6Y+ uEvZg/1H5S+OizJzHrWK1dH10zVn4p28B08ah6UIXzFSi1rA5vVlRYNu2+wyqgWoTYCj a5UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Gny7FjKIjUK/gDtgLoARfJm5hzkXeDcHtWJDBP1nYP4=; b=E4eeyI4oAyUZnBdRoHpVNBqQUDgjW3/T3bZ+yIVCp6bxo1VfKArRtrZHu9O+uMbbTM IIUCAxll9zfcfKWuFacuaKXRoyBLbzRXMSHWubNuA7Aed60lycELFrdyAa6DBPGyXaBi zIXECyk04bAGnS2Y6EiTzU1m/rvnKyv6U/1iomOXLFab8mqAdsyQ3a8opPLigDk5XSE4 UL+EL5wLeSk0jOPA3VWKSIZo4zi2KLU4kxWORnhHF19jGjiwPBLnCE/QU84+nPmMQO39 EmeSDcM6MX0ac6upldOvHcJ6ME3QD1OKMsat8f9D1hgT3EwuFmFyZHBqovkSKpb7kCZI Y8+A== X-Gm-Message-State: AFeK/H0dQ1X7PWYJhWjwLodes3yocHYw5E7aUFWGYqLDCXPQSwyJxu7L8D1HyeIt/p3gKuMTQVOb2W5v2tiXGA== X-Received: by 10.36.118.68 with SMTP id z65mr2165779itb.59.1489208025749; Fri, 10 Mar 2017 20:53:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Fri, 10 Mar 2017 20:53:30 -0800 (PST) In-Reply-To: References: <148477153647.2298.16876633792182475280.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Fri, 10 Mar 2017 23:53:30 -0500 Message-ID: To: "Alvaro Retana (aretana)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "trill-chairs@ietf.org" , "trill@ietf.org" , The IESG , "draft-ietf-trill-rfc6439bis@ietf.org" , Susan Hares Subject: Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 04:53:48 -0000 H Alvaro, Could you look at version -05 which is intended to resolve your DISCUSS as discussed below. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Feb 21, 2017 at 2:33 PM, Donald Eastlake wrote: > Hi Alvaro, > > On Thu, Jan 19, 2017 at 9:18 AM, Alvaro Retana (aretana) > wrote: >> Donald: >> >> Hi! >> >> I am not concerned about the case you described below: where the source = and >> destination are attached to the same switch. Nor am I concerned about >> transit TRILL data packets. > > OK. I guess I was mislead by your reference to the IS-IS standard that > a router in overload "shall not" be considered for transit. I thought > that your comment had to do with building shortest cost paths which is > not particularly relevant here. > >> I am concerned about the case where the other end stations are not attac= hed >> to any of the local switches, but are somewhere else in the campus (or t= he >> mixed case where some of the other end stations are attached to an >> overloaded switch, but others are elsewhere). In that case, if I am not >> missing anything, the appointed forwarder for the local link will accept= the >> native frame and will have to send a TRILL Data Packet across the campus= =E2=80=93 >> the information to do that may not be available if the switch is overloa= ded. > > Yes. The case you cite is one where the designated router really, as > the draft says, SHOULD NOT appoint the router in overload as appointed > forwarder. (Note that if it violates this "SHOULD NOT" the appointed > forwarder becomes, as far as IS-IS routing is concerned, a source and > sink, not a transit node.) But, in any case, it may be that the > designated router on the link is the only router on the link and is in > overload or it may be that all the routers on the link are in > overloaded or it may be the case I cite where the best routed to > appointer forwarder for VLAN-x is one that is in overload because all > the end stations in VLAN-x are attached to that router. So there are > plenty of cases where either it is a good idea or is unavoidable to > appoint a router in overload as the appointed forwarder for some VLAN. > You ask for the reason the draft says "SHOULD NOT" rather than "MUST > NOT" and that's the reason. > > I can make some changes to Section 2.4 to try to clarify this. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> Thanks! >> Alvaro. >> >> >> >> On 1/18/17, 11:43 PM, "Donald Eastlake" wrote: >> >> >> >> Hi Alvaro, >> >> >> >> On Wed, Jan 18, 2017 at 3:32 PM, Alvaro Retana wrote= : >> >> Alvaro Retana has entered the following ballot position for >> >> draft-ietf-trill-rfc6439bis-04: Discuss >> >> >> >> When responding, please keep the subject line intact and reply to all >> >> email addresses included in the To and CC lines. (Feel free to cut this >> >> introductory paragraph, however.) >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> >> ---------------------------------------------------------------------- >> >> >> >> Section 2.4 (Overload and Appointed Forwarders) talks about potential >> >> Appointed Forwarders which are overloaded. In IS-IS, a node with the >> >> overload bit set "shall not" (ISO 10589) be considered for transit. >> >> However, the use of "SHOULD NOT appoint an RBridge in overload" and >> >> "SHOULD re-assign VLANs from the overloaded RBridge" leaves a potential >> >> hole in the proper forwarding of TRILL data packers. Why aren't MUST >> >> NOT/MUST used? Is there something in the specific use of IS-IS by TRILL >> >> that I am missing? >> >> >> >> The Appointed Forwarder function has to do with accepting frames from >> >> end stations for ingress and egressing frames to end stations. It does >> >> not have anything to do with TRILL Data packet transit routing. >> >> >> >> Consider the following case: two TRILL switches (RBridges) RB1 and RB2 >> >> are connected by a link L1 that also has end stations on it. The end >> >> stations are all in VLAN X. There are other end stations in VLAN X in >> >> the TRILL campus not on L1 but all of these other end stations are >> >> directly connected to RB2. RB2 is in overload. >> >> >> >> Under these circumstances, RB2 should be the Appointed Forwarder for >> >> VLAN X as that way traffic between all of the VLAN X end stations can >> >> be forwarded by RB2 without any IS-IS routing at all. RB2 will just >> >> be, in effect, forwarding native frames between RB2 ports (although, >> >> for consistency, the TRILL specifications say that RB2 ingresses this >> >> VLAN X traffic by encapsulating it into a TRILL Data frame, and then >> >> notices it is destined for an end station on a local port, immediately >> >> decapsulates it, and sends it out that port). >> >> >> >> I think this should be an easy DISCUSS to clear; either point to the >> >> piece I'm missing, or don't use an overloaded node. >> >> >> >> Thanks, >> >> Donald >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> >> 155 Beaver Street, Milford, MA 01757 USA >> >> d3e3e3@gmail.com >> >> From nobody Fri Mar 10 23:46:24 2017 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 22FE91293FD; Fri, 10 Mar 2017 23:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b_1SChq73Cn; Fri, 10 Mar 2017 23:46:15 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9751279EB; Fri, 10 Mar 2017 23:46:15 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id i34so4514097qtc.0; Fri, 10 Mar 2017 23:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ICJ+EcScPd72SuZ8IkMuzT22IW52Gv3IHbqRl7Xr6Rs=; b=Tqs8qUKigkeQkmJuFGvNX1kcsbh2cQKmEzOQcspuqGrlaDAN9LMUY94vygdUJ2j5Is /fRpd6tzOEXeL29ZI1xEQ/mU0+D7VIJS8KRzPDdud8pMouAIkoEAgvvjQ6l6zpU6VoMP d++ILsuvPy0p3JDWdbaSsjtalmufKtyPrpDaXeG4f6guQNjdQ1zB53wM6kS1B8q64G0P CTpVlsSCpkE0EIqiRE7RDlRc+8Owrd8Wr9FCWuSiqOAuag3vFdhvYnMI4VQ7TT7aAY3+ DURZj+jiPNoxIerILsR8Lo/rCZArxPqYTo4b0nM6hfeQySkB+of6LDukuOSZBV3Rm7aU XFwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ICJ+EcScPd72SuZ8IkMuzT22IW52Gv3IHbqRl7Xr6Rs=; b=hmSVo5sJfPS6oQjv0wUX+I46MFj3X1Lk1Uvxv3hoDLOtgT8OykygZpsezW5rIXPxPF nr611gPscPJh6djEF0qnh4Jo2Jzw52lTDKKke93f+Q12OoyRnJzVI3CROJf69XBIhbOx gP5lZIzNWbnvaz31XnbsZlYMagYRdkzDCn4dT8KQVnGfBPeLAiqdbIVueu+AaWE8nJkP WKr4oBgRWC5yXwS1Nv6VRgTNqZKKjuhQqbzuUs+yKh2heqgX0WIt8HYN63xRLUKn5aH1 MrprhUQUXJd3M/dLlzI/DliFTgFjdDCepV68uH93doMUlMSkj4tIKJB3dBA5UGlC/WA+ 4fng== X-Gm-Message-State: AMke39n70ra3dQJ0ajVgQirsMgtVODdVammrnWyv9NnO7K5GsuZCRtlVNqu59xnGLoCnddKXdkWYeIZfcOveHQ== X-Received: by 10.200.40.210 with SMTP id j18mr25282067qtj.272.1489218374429; Fri, 10 Mar 2017 23:46:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.41.170 with HTTP; Fri, 10 Mar 2017 23:46:13 -0800 (PST) In-Reply-To: References: <148423706509.29345.14522113109638417885.idtracker@ietfa.amsl.com> From: Dan Romascanu Date: Sat, 11 Mar 2017 18:16:13 +1030 Message-ID: To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a11405b4e337449054a6fac2d Archived-At: Cc: Benoit Claise , "ops-dir@ietf.org" , draft-ietf-trill-rfc6439bis.all@ietf.org, IETF Discussion , "trill@ietf.org" Subject: Re: [trill] Review of draft-ietf-trill-rfc6439bis-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 07:46:18 -0000 --001a11405b4e337449054a6fac2d Content-Type: text/plain; charset=UTF-8 Looks good now. Thanks for addressing my concerns. Dan On Sat, Mar 11, 2017 at 3:10 PM, Donald Eastlake wrote: > Hi Dan, > > Could you look at the recently posted version -05 to see if this > resolves your comments? > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Wed, Jan 18, 2017 at 2:16 PM, Donald Eastlake wrote: > > Hi Dan, > > > > On Tue, Jan 17, 2017 at 3:45 AM, Dan Romascanu > wrote: > >> Hi Donald, > >> > >> Thank you for your answer and explanations. They make sense to me, but I > >> still beleive that the document may benefit if some edits are being > done to > >> clarify what may be the obvious for the people who know all details and > >> history, but not for the other users of the document in the future - > >> implementers and operators. > > > > Sure, I agree that it would benefit for the addition of some text here > > and there./ > > > >> Specifically: > >> > >>> I am not aware of any case where this draft replaces a TLV in the > >> sense of requiring use of a new TLV. It does provide some new TLVs > >> and procedures that are believed to be superior to or useful additions > >> to previous ones. But I am not aware of any case where it "obsoletes" > >> previous provisions in the sense of prohibiting their use. > >> > >> The header of the document includes Obsoletes 6439. If part of the > content > >> of 6439 remains valid this needs to be clarified, If some superior TLVs > and > >> procedures are introduced there is a need to explain what will happen > with > >> the previous ones. Should they be implemented? deployed? activated? > > > > OK. Stating that essentially all of RFC 6439 is incorporated and > > outlining what parts of the new draft are optional improvements over > > which part of RFC 6439, etc. would probably be a good addition. > > > >>> I don't know that much is really required to be said about > >> "transition" when you specify an optional optimization. Since it is > >> optional, by implication the implementer is free to use it or not and > >> things will work either way. This could be stated explicitly in those > >> cases. > >> > >> If I understand what you say, the new features are optional (although > the > >> status of the document is Proposed Standard), they can or cannot be > >> implemented (one, the other, both?) and the network will still work. > Yes, I > >> suggest to explicitly state this). > > > > OK. > > > >>> RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges) > >> SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs > >> 6850 and 7784. However, there are also YANG modules underway in > >> draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and > >> draft-ietf-trill-yang-pm. > >> > >>> It does not seem best for this rfc6439bis draft to change the > >> implementation requirement level for SNMP or NETCONF for TRILL. If that > >> were to be done, it seems like something more appropriate for the base > >> TRILL YANG draft (draft-ietf-trill-yang-*) to do. > >> > >> If I was an implementer of TRILL, or an operator considering to deploy > >> TRILL, I would have a hard time trying to understand what to implement > and > >> what to deploy as management interfaces. Maybe this is not the place > but I > >> believe that there need to be some documentation on this respect. > > > > OK. I think it would be reasonable to say something about the current > > implementation requirement level of SNMPv3 and to say that YANG > > modules are under development, so implementers will know more about > > what is going on. > > > > Thanks, > > Donald > > =============================== > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > d3e3e3@gmail.com > > > >> Thanks and Regards, > >> Dan > >> > >> > >> On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake > wrote: > >>> > >>> Hi Dan, > >>> > >>> Thanks for your review. As per my further response below, while the > >>> draft could perhaps use some clarifying additions related to > >>> operations, I do not believe it is as bad as you say. > >>> > >>> On Thu, Jan 12, 2017 at 11:04 AM, Dan Romascanu > >>> wrote: > >>> > > >>> > Reviewer: Dan Romascanu > >>> > Review result: Has Issues > >>> > > >>> > I have reviewed this document as part of the Operational > >>> > directorate's ongoing effort to review all IETF documents being > >>> > processed by the IESG. These comments were written with the intent > >>> > of improving the operational aspects of the IETF drafts. Comments > >>> > that are not addressed in last call may be included in AD reviews > >>> > during the IESG review. Document editors and WG chairs should treat > >>> > these comments just like any other last call comments. > >>> > > >>> > This document clarifies and updates the TRILL Appointed > >>> > Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and > >>> > obsoletes RFC 6439. > >>> > > >>> > It's a complex document which requires extra reading to understand > >>> > the context and the interraction with other RFCs. I believe that > >>> > from an OPS-DIR perspective there are issues that need to be > >>> > discussed before the document can be approved. > >>> > > >>> > The main issues with the document in its current form are: > >>> > > >>> > 1. The document makes consistent changes in the way TRILL > >>> > operates. It replaces TLVs and procedures, define new ones, > >>> > obsoletes previous mechanisms that define VLAN mapping, and > >>> > >>> I am not aware of any case where this draft replaces a TLV in the > >>> sense of requiring use of a new TLV. It does provide some new TLVs > >>> and procedures that are believed to be superior to or useful additions > >>> to previous ones. But I am not aware of any case where it "obsoletes" > >>> previous provisions in the sense of prohibiting their use. > >>> > >>> > incorporates updated material from other RFCs. There is however no > >>> > indication in the text about the transition between existing > >>> > deployed versions of TRILL based on RFC 6439 and related protocols > >>> > with the current updated mechanisms. Are these backward compatible? > >>> > >>> I don't know that much is really required to be said about > >>> "transition" when you specify an optional optimization. Since it is > >>> optional, by implication the implementer is free to use it or not and > >>> things will work either way. This could be stated explicitly in those > >>> cases. > >>> > >>> Much of the material in this draft comes from RFC 6439 or the parts of > >>> RFC 7177 that updated RFC 6439. Most of the new material is optional > >>> improved behaviors. > >>> > >>> The only mandatory new behavior is the mandatory support of the link > >>> local E-L1CS flooding scope [RFC7357] specified in Section 8. There is > >>> material in this draft covering backwards compatibility for this new > >>> mandatory behavior. Section 8 already explains how to determine > >>> whether or not all TRILL switches on a link support E-L1CS flooding > >>> scope. The only use of E-L1CS flooding scope in this draft is as part > >>> of a mechanism for the DRB (Designated RBridge (TRILL switch)) to > >>> advertise Forwarder Appointments and, as stated in Section 2.1 (see > >>> paragraph at the bottom of page 8 in draft -04), if any RBridge on the > >>> link does not support E-L1CS, then the DRB MUST fall back to > >>> advertising those appointments in Hellos. Section 8, which mandates > >>> support of E-L1CS, also requires that any use of E-L1CS specified in > >>> the future must provide for backward compatibility. > >>> > >>> > Do they need a simultaneous upgrade of the whole network? > >>> > >>> No. > >>> > >>> > 2. The document lacks a section or even minimal text concerning > >>> > operational and manageability considerations. There are several > >>> > >>> Such a section can be added but there is not much to say. For example, > >>> as explained below, there is very little specified in this document to > >>> configure. > >>> > >>> > mentions in the text concerning network managers or operator > >>> > actions, but there is no indication or reference to what management > >>> > protocols and data models are to be used for configuration, > >>> > >>> RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges) > >>> SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs > >>> 6850 and 7784. However, there are also YANG modules underway in > >>> draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and > >>> draft-ietf-trill-yang-pm. > >>> > >>> It does not seem best for this rfc6439bis draft to change the > >>> implementation requirement level for SNMP or NETCONF for TRILL. If that > >>> were to be done, it seems like something more appropriate for the base > >>> TRILL YANG draft (draft-ietf-trill-yang-*) to do. > >>> > >>> > retrieval of operational status information, or alerts. I believe > >>> > that these need to be added explicitly or by reference. > >>> > >>> Reviewing the significant protocol additions in this draft at a high > >>> level: > >>> > >>> - There is significant material about the various ways the Designated > >>> RBridge on a link can announce who it is selecting as the Appointed > >>> Forwarder on the link for various VLANs. The election of the > >>> Designated RBridge depends on a configurable priority but that > >>> election is unchanged from RFC 7177 and in fact is identical to the > >>> election of the designated router on any IS-IS link. The decision on > >>> which RBridges to appointer as forwarder for which VLAN is out of > >>> scope. I don't see that there is anything to configure here, other > >>> than RBridge priority to be DRB, which is already specified in other > >>> RFCs. > >>> > >>> - There are some optional optimizations to the inhibition mechanism. > >>> The inhibition mechanism is necessary for loop safety but any > >>> RBridge can use or not use any of these optimizations, as they > >>> choose, and things will work fine. > >>> > >>> - Port Shutdown message: There are two new configuration parameters > >>> here, namely how many copies of the Port Shutdown message to send > >>> and at what interval. These are listed, along with units and default > >>> value in Section 6.6. > >>> > >>> - FGL-VLAN mapping consistency check: As specified in RFC 7172, in a > >>> TRILL campus supporting Fine Grained Labels (FGL), the VLAN of a > >>> native frame can be mapped to an FGL on ingress and an FGL is mapped > >>> to a VLAN on egress. This draft makes no changes to that mechanism. > >>> It merely provides that an RBridge performing such mapping can > >>> optionally advertise the mapping it is performing at a port to other > >>> RBridges with ports on the same link which can then check it for > >>> consistency with any mapping they are performing. It is recommended > >>> that the network operator be alerted to such inconsistency and there > >>> is a configurable parameter for how long the inconsistency needs to > >>> exist before such alert. Is it your position that some specific > >>> protocol mechanism must be specified by which the network operator > >>> is alerted? > >>> > >>> Thanks, > >>> Donald > >>> =============================== > >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >>> 155 Beaver Street, Milford, MA 01757 USA > >>> d3e3e3@gmail.com > >> > >> > --001a11405b4e337449054a6fac2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks good now. Thanks for addressing my concern= s.

Dan

=C2=A0

On Sat, Mar 11, 2017 at 3:10 PM, Donald Eas= tlake <d3e3e3@gmail.com> wrote:
Hi Dan,

Could you look at the recently posted version -05 to see if this
resolves your comments?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com


On Wed, Jan 18, 2017 at 2:16= PM, Donald Eastlake <d3e3e3@gmail.c= om> wrote:
> Hi Dan,
>
> On Tue, Jan 17, 2017 at 3:45 AM, Dan Romascanu <dromasca@gmail.com> wrote:
>> Hi Donald,
>>
>> Thank you for your answer and explanations. They make sense to me,= but I
>> still beleive that the document may benefit if some edits are bein= g done to
>> clarify what may be the obvious for the people who know all detail= s and
>> history, but not for the other users of the document in the future= -
>> implementers and operators.
>
> Sure, I agree that it would benefit for the addition of some text here=
> and there./
>
>> Specifically:
>>
>>> I am not aware of any case where this draft replaces a TLV in = the
>> sense of requiring use of a new TLV.=C2=A0 It does provide some ne= w TLVs
>> and procedures that are believed to be superior to or useful addit= ions
>> to previous ones. But I am not aware of any case where it "ob= soletes"
>> previous provisions in the sense of prohibiting their use.
>>
>> The header of the document includes Obsoletes 6439. If part of the= content
>> of 6439 remains valid this needs to be clarified, If some superior= TLVs and
>> procedures are introduced there is a need to explain what will hap= pen with
>> the previous ones. Should they be implemented? deployed? activated= ?
>
> OK. Stating that essentially all of RFC 6439 is incorporated and
> outlining what parts of the new draft are optional improvements over > which part of RFC 6439, etc. would probably be a good addition.
>
>>> I don't know that much is really required to be said about=
>> "transition" when you specify an optional optimization. = Since it is
>> optional, by implication the implementer is free to use it or not = and
>> things will work either way. This could be stated explicitly in th= ose
>> cases.
>>
>> If I understand what you say, the new features are optional (altho= ugh the
>> status of the document is Proposed Standard), they can or cannot b= e
>> implemented (one, the other, both?) and the network will=C2=A0 sti= ll work. Yes, I
>> suggest to explicitly state this).
>
> OK.
>
>>> RFC 6325, the base TRILL protocol RFC, says TRILL switches (RB= ridges)
>> SHOULD support SNMPv3 and there are TRILL MIB specifications in RF= Cs
>> 6850 and 7784. However, there are also YANG modules underway in >> draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and
>> draft-ietf-trill-yang-pm.
>>
>>> It does not seem best for this rfc6439bis draft to change the<= br> >> implementation requirement level for SNMP or NETCONF for TRILL. If= that
>> were to be done, it seems like something more appropriate for the = base
>> TRILL YANG draft (draft-ietf-trill-yang-*) to do.
>>
>> If I was an implementer of TRILL, or an operator considering to de= ploy
>> TRILL, I would have a hard time trying to understand what to imple= ment and
>> what to deploy as management interfaces. Maybe this is not the pla= ce but I
>> believe that there need to be some documentation on this respect.<= br> >
> OK. I think it would be reasonable to say something about the current<= br> > implementation requirement level of SNMPv3 and to say that YANG
> modules are under development, so implementers will know more about > what is going on.
>
> Thanks,
> Donald
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
>=C2=A0 Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
>=C2=A0 155 Beaver Street, Milford, MA 01757 USA
>=C2=A0 d3e3e3@gmail.com
>
>> Thanks and Regards,
>> Dan
>>
>>
>> On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>>>
>>> Hi Dan,
>>>
>>> Thanks for your review. As per my further response below, whil= e the
>>> draft could perhaps use some clarifying additions related to >>> operations, I do not believe it is as bad as you say.
>>>
>>> On Thu, Jan 12, 2017 at 11:04 AM, Dan Romascanu <dromasca@gmail.com>
>>> wrote:
>>> >
>>> > Reviewer: Dan Romascanu
>>> > Review result: Has Issues
>>> >
>>> > I have reviewed this document as part of the Operational<= br> >>> > directorate's ongoing effort to review all IETF docum= ents being
>>> > processed by the IESG.=C2=A0 These comments were written = with the intent
>>> > of improving the operational aspects of the IETF drafts. = Comments
>>> > that are not addressed in last call may be included in AD= reviews
>>> > during the IESG review.=C2=A0 Document editors and WG cha= irs should treat
>>> > these comments just like any other last call comments. >>> >
>>> > This document clarifies and updates the TRILL Appointed >>> >=C2=A0 Forwarder mechanism. It updates RFC 6325, updates R= FC 7177, and
>>> >=C2=A0 obsoletes RFC 6439.
>>> >
>>> > It's a complex document which requires extra reading = to understand
>>> > the context and the interraction with other RFCs. I belie= ve that
>>> > from an OPS-DIR perspective there are issues that need to= be
>>> > discussed before the document can be approved.
>>> >
>>> > The main issues with the document in its current form are= :
>>> >
>>> > 1. The document makes consistent changes in the way TRILL=
>>> > operates. It replaces TLVs and procedures, define new one= s,
>>> > obsoletes previous mechanisms that define VLAN mapping, a= nd
>>>
>>> I am not aware of any case where this draft replaces a TLV in = the
>>> sense of requiring use of a new TLV.=C2=A0 It does provide som= e new TLVs
>>> and procedures that are believed to be superior to or useful a= dditions
>>> to previous ones. But I am not aware of any case where it &quo= t;obsoletes"
>>> previous provisions in the sense of prohibiting their use.
>>>
>>> > incorporates updated material from other RFCs. There is h= owever no
>>> > indication in the text about the transition between exist= ing
>>> > deployed versions of TRILL based on RFC 6439 and related = protocols
>>> > with the current updated mechanisms. Are these backward c= ompatible?
>>>
>>> I don't know that much is really required to be said about=
>>> "transition" when you specify an optional optimizati= on. Since it is
>>> optional, by implication the implementer is free to use it or = not and
>>> things will work either way. This could be stated explicitly i= n those
>>> cases.
>>>
>>> Much of the material in this draft comes from RFC 6439 or the = parts of
>>> RFC 7177 that updated RFC 6439. Most of the new material is op= tional
>>> improved behaviors.
>>>
>>> The only mandatory new behavior is the mandatory support of th= e link
>>> local E-L1CS flooding scope [RFC7357] specified in Section 8. = There is
>>> material in this draft covering backwards compatibility for th= is new
>>> mandatory behavior.=C2=A0 Section 8 already explains how to de= termine
>>> whether or not all TRILL switches on a link support E-L1CS flo= oding
>>> scope. The only use of E-L1CS flooding scope in this draft is = as part
>>> of a mechanism for the DRB (Designated RBridge (TRILL switch))= to
>>> advertise Forwarder Appointments and, as stated in Section 2.1= (see
>>> paragraph at the bottom of page 8 in draft -04), if any RBridg= e on the
>>> link does not support E-L1CS, then the DRB MUST fall back to >>> advertising those appointments in Hellos. Section 8, which man= dates
>>> support of E-L1CS, also requires that any use of E-L1CS specif= ied in
>>> the future must provide for backward compatibility.
>>>
>>> > Do they need a simultaneous upgrade of the whole network?=
>>>
>>> No.
>>>
>>> > 2. The document lacks a section or even minimal text conc= erning
>>> > operational and manageability considerations.=C2=A0 There= are several
>>>
>>> Such a section can be added but there is not much to say. For = example,
>>> as explained below, there is very little specified in this doc= ument to
>>> configure.
>>>
>>> > mentions in the text concerning network managers or opera= tor
>>> > actions, but there is no indication or reference to what = management
>>> > protocols and data models are to be used for configuratio= n,
>>>
>>> RFC 6325, the base TRILL protocol RFC, says TRILL switches (RB= ridges)
>>> SHOULD support SNMPv3 and there are TRILL MIB specifications i= n RFCs
>>> 6850 and 7784. However, there are also YANG modules underway i= n
>>> draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and
>>> draft-ietf-trill-yang-pm.
>>>
>>> It does not seem best for this rfc6439bis draft to change the<= br> >>> implementation requirement level for SNMP or NETCONF for TRILL= . If that
>>> were to be done, it seems like something more appropriate for = the base
>>> TRILL YANG draft (draft-ietf-trill-yang-*) to do.
>>>
>>> > retrieval of operational status information, or alerts. I= believe
>>> > that these need to be added explicitly or by reference. >>>
>>> Reviewing the significant protocol additions in this draft at = a high
>>> level:
>>>
>>> - There is significant material about the various ways the Des= ignated
>>>=C2=A0 =C2=A0RBridge on a link can announce who it is selecting= as the Appointed
>>>=C2=A0 =C2=A0Forwarder on the link for various VLANs. The elect= ion of the
>>>=C2=A0 =C2=A0Designated RBridge depends on a configurable prior= ity but that
>>>=C2=A0 =C2=A0election is unchanged from RFC 7177 and in fact is= identical to the
>>>=C2=A0 =C2=A0election of the designated router on any IS-IS lin= k. The decision on
>>>=C2=A0 =C2=A0which RBridges to appointer as forwarder for which= VLAN is out of
>>>=C2=A0 =C2=A0scope. I don't see that there is anything to c= onfigure here, other
>>>=C2=A0 =C2=A0than RBridge priority to be DRB, which is already = specified in other
>>>=C2=A0 =C2=A0RFCs.
>>>
>>> - There are some optional optimizations to the inhibition mech= anism.
>>>=C2=A0 =C2=A0The inhibition mechanism is necessary for loop saf= ety but any
>>>=C2=A0 =C2=A0RBridge can use or not use any of these optimizati= ons, as they
>>>=C2=A0 =C2=A0choose, and things will work fine.
>>>
>>> - Port Shutdown message: There are two new configuration param= eters
>>>=C2=A0 =C2=A0here, namely how many copies of the Port Shutdown = message to send
>>>=C2=A0 =C2=A0and at what interval. These are listed, along with= units and default
>>>=C2=A0 =C2=A0value in Section 6.6.
>>>
>>> - FGL-VLAN mapping consistency check: As specified in RFC 7172= , in a
>>>=C2=A0 =C2=A0TRILL campus supporting Fine Grained Labels (FGL),= the VLAN of a
>>>=C2=A0 =C2=A0native frame can be mapped to an FGL on ingress an= d an FGL is mapped
>>>=C2=A0 =C2=A0to a VLAN on egress. This draft makes no changes t= o that mechanism.
>>>=C2=A0 =C2=A0It merely provides that an RBridge performing such= mapping can
>>>=C2=A0 =C2=A0optionally advertise the mapping it is performing = at a port to other
>>>=C2=A0 =C2=A0RBridges with ports on the same link which can the= n check it for
>>>=C2=A0 =C2=A0consistency with any mapping they are performing. = It is recommended
>>>=C2=A0 =C2=A0that the network operator be alerted to such incon= sistency and there
>>>=C2=A0 =C2=A0is a configurable parameter for how long the incon= sistency needs to
>>>=C2=A0 =C2=A0exist before such alert. Is it your position that = some specific
>>>=C2=A0 =C2=A0protocol mechanism must be specified by which the = network operator
>>>=C2=A0 =C2=A0is alerted?
>>>
>>> Thanks,
>>> Donald
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=C2=A0 Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell= )
>>>=C2=A0 155 Beaver Street, Milford, MA 01757 USA
>>>=C2=A0 d3e3e3@gmail.com=
>>
>>

--001a11405b4e337449054a6fac2d-- From nobody Sat Mar 11 00:05:29 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 419DF129409; Sat, 11 Mar 2017 00:05:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148921952924.10708.5632990959999657897.idtracker@ietfa.amsl.com> Date: Sat, 11 Mar 2017 00:05:29 -0800 Archived-At: Cc: dromasca@gmail.com, trill-chairs@ietf.org, shares@ndzh.com, draft-ietf-trill-rfc6439bis@ietf.org, trill@ietf.org Subject: [trill] Benoit Claise's No Objection on draft-ietf-trill-rfc6439bis-05: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 08:05:29 -0000 Benoit Claise has entered the following ballot position for draft-ietf-trill-rfc6439bis-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for solving my DISCUSS From nobody Sun Mar 12 14:36:42 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0F126DFB; Sun, 12 Mar 2017 14:36:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148935460100.24770.401532061052236711@ietfa.amsl.com> Date: Sun, 12 Mar 2017 14:36:41 -0700 Archived-At: Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-ecn-support-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:36:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL: ECN (Explicit Congestion Notification) Support Authors : Donald E. Eastlake Bob Briscoe Filename : draft-ietf-trill-ecn-support-02.txt Pages : 19 Date : 2017-03-12 Abstract: Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better flow control without packet drops. This document extends ECN to TRILL switches, including integration with IP ECN, and provides for ECN marking in the TRILL Header Extension Flags Word (see RFC 7179). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trill-ecn-support-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-ecn-support-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 12 14:43:16 2017 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 D7AD2129503; Sun, 12 Mar 2017 14:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0Drol9FSeQS; Sun, 12 Mar 2017 14:43:08 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A3E1294B0; Sun, 12 Mar 2017 14:43:04 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id l7so74262295ioe.3; Sun, 12 Mar 2017 14:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/chdG33t3R+6Cr0AG8WPlY4SwKd6Pb6MmjjNRnW/BTM=; b=TiGtfLgKGz7hrCdVCXZUEdQOPIeSzHQXYCw3Ag+XUR6ESHjpNBzTFKzAKsVaj3AgLW 9++bv/Mb8E+E82VMew/uENeAWr+UqGQ/ceaQTzDe+Mu97XceyT6C/9iEuLynsDGMlhBg 2AzIxFX+Wdod2yxQ/9zUhf8xg7cOAJWpNzDtcQFdsXN3pruUX2M8awlCKP4CWwPJSjwW kvPBOAiPAb9InBhJ3FPVSBhmXZdmtbKhkcmgM8VRcLTex3kANk4GAoBKO2kHeCbDes7R WxFIeYimveR5FQ293bMpxFqW0ah+iQGhPQCavnE5UMV/wvi8HY29TXNAgEQGIVYSgdf5 Ol1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/chdG33t3R+6Cr0AG8WPlY4SwKd6Pb6MmjjNRnW/BTM=; b=KXWsRVAzObu6bupdKE/17QRz8uWpzuNcG3quTQLsk1GScAumUm+lOOGaw6tBj7TEHZ QanJr71ZWixsos9MvxUiQLijqwkZUY7yOcQCdUPdITUh96t/8glkGllcDTNTYIw91ygV uHL6haU2YUlz2cxOqQqWoAGjuexuB1Q+IfxN4J3O/PfaqQ6fDljAcd7jtKKeGo7FoH5D F04D55Zpvvs9O9aayma48QnLZd3sCHay/K2rHSoXLDA0zKgDeo56Uw4yWYSofCxFs1Tf pSle2hy5skgNj8hwCWRvemnDA/BcN3M3lrZIdoB53I1jDp9xRaFtXsOFAfxQpJ7iY7fJ AYUw== X-Gm-Message-State: AMke39l+0gRm45UYuPd95aTfybyx6Nqs9V2kANConx73Ux8QBX+sL500ug6qZqsorxh2yi6P1pUP+HRjNIR+1g== X-Received: by 10.107.30.3 with SMTP id e3mr23663710ioe.12.1489354983939; Sun, 12 Mar 2017 14:43:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Sun, 12 Mar 2017 14:42:48 -0700 (PDT) In-Reply-To: <2a67b907-bba6-31c9-2d53-7581df97cac4@pi.nu> References: <2a67b907-bba6-31c9-2d53-7581df97cac4@pi.nu> From: Donald Eastlake Date: Sun, 12 Mar 2017 17:42:48 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11408e4ec328e4054a8f7a39 Archived-At: Cc: "rtg-dir@ietf.org" , draft-ietf-trill-ecn-support@ietf.org, "trill-chairs@ietf.org" , "Yemin \(Amy" , "trill@ietf.org" Subject: Re: [trill] QA review of draft-ietf-trill-ecn-support X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:43:11 -0000 --001a11408e4ec328e4054a8f7a39 Content-Type: text/plain; charset=UTF-8 Hi Loa, The -02 version of draft-ietf-trill-ecn-support, just posted, included the improvements we have discussed. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sat, Jan 28, 2017 at 3:44 AM, Loa Andersson wrote: > Donald, > > I'm pretty happy with your response on my comments. I think that the > agreed updates will go a long way to improve readability of the > document. > > /Loa > > > On 2017-01-27 06:09, Donald Eastlake wrote: > >> Hi Loa, >> >> Thanks for your comments. See below >> >> On Sat, Jan 21, 2017 at 12:02 AM, Loa Andersson wrote: >> >>> Authors, >>> >>> I have been asked to do a Routing Area Directorate QA review of >>> draft-ietf-trill-ecn-support. >>> >>> Caveat - I'm not a congestion control expert, and this will show up in >>> my comments. The place where I ask for clarifications might be perfectly >>> clear for a reader that is up to speed in the area. >>> >>> Summary: >>> >>> I think the document is on the right track, for a reader not an >>> expert in the area there are a lot of abbreviations that are not >>> properly expanded. I also think that it would be a good idea to more >>> clearly make the the case why the document is needed (abstract >>> and/or introduction). >>> >>> After a while I stop trying to distinguish between "Minor issues" >>> and "Nits" and placed everything as Minor Issues. I guess I could >>> have done everything as Nits :). >>> >> >> OK :-) >> >> Other than the Comment/Minor Issues I find the document pretty solid, >>> >> >> Thanks. >> >> though I sometimes found it hard to parse sentences. >>> If you want I can take a look at that aspect once what is in this >>> review has been addressed. >>> >>> Comments: >>> >>> Last paragraph of the Introduction >>> ---------------------------------- >>> >>> Whichever RBridges do not support ECN, this >>> specification ensures congestion notification will propagate safely >>> to Destination because the packet will be dropped if explicit >>> congestion notification cannot be propagated and drop is itself an >>> implicit form of congestion notification. >>> >>> Is this logic really watertight? What if the packet is dropped because >>> of a >>> checksum error? >>> >> >> I think the point of that paragraph is to overcome the presumption >> many readers might have that ECN marking would be useless if the >> Destination does not understand ECN marking. >> >> Major Issues: >>> >>> >>> Minor Issues: >>> >>> Abstract >>> -------- >>> I find the Abstract a bit meager, a little more context would be good. >>> >>> Maybe lead with some short words about what ECN is good for. >>> >>> And maybe use this from the Introduction: >>> >>> This specification provides for any ECN marking in the traffic at the >>> ingress to be copied into the TRILL Extension Header Flags Word. It >>> also enables congestion marking by a congested RBridge such as RBn or >>> RB1 above in the TRILL Header Extension Flags Word [RFC7179]. >>> >> >> OK. How about this: >> >> Explicit congestion notification (ECN) allows a forwarding element >> to notify downstream devices, including the destination, of the >> onset of congestion without having to drop packets. This can >> improve network efficiency through better flow control without >> packet drops. This document extends ECN to TRILL switches, >> including integration with IP ECN, and provides for ECN marking in >> the TRILL Header Extension Flags Word (see RFC 7179). >> >> ECNencapGuide >>> ------------- >>> >>> This reference has expired, probably not a problem since Bob is a >>> co-author of both documents. >>> >>> TRILL Header >>> ------------ >>> >>> Referred to in section in the Introduction, I think a reference would be >>> good. >>> >> >> OK. >> >> The ECN Specific Extended Header Flags >>> -------------------------------------- >>> >>> The pictures is less than intuitive, it took me quite some time de-code >>> it. >>> I did the following: >>> Critical (?) flags >>> 0 - CRHbH (no expansion found in document) >>> 1 - CRItE (no expansion found in document) >>> 2 - CRRsv (no expansion found in document) >>> >>> CHbH flags (Critical Hop by Hop flags - no expansion found in document) >>> 3 - unassigned >>> 4 - unassigned >>> 5 - unassigned >>> 6 - unassigned >>> 7 - CRCAF (no expansion found in document) >>> >>> NCHbH flags = Non-Critical Hop-by-Hop flags >>> 8 - NCCAF (no expansion found in document) >>> 9 - unassigned >>> 10 - unassigned >>> 11 - unassigned >>> ------------------------------------------- >>> 12 - ECN = Explicit Congestion Notification >>> 13 (two bit flags) >>> ------------------------------------------- >>> >>> CRSV flags (no expansion found in document) >>> ------------------------------------------- >>> 14 - Ext Hop Cnt (no expansion found in document) >>> 15 three bit field >>> 16 >>> ------------------------------------------ >>> >>> NCRSV flags (no expansion found in document) >>> 17 - unassigned >>> 18 - unassigned >>> 19 - unassigned >>> 20 - unassigned >>> ------------------------------------------ >>> >>> CItE flags = Critical Ingress-to-Egress >>> ------------------------------------------ >>> 21 - unassigned >>> 22 - unassigned >>> 23 - unassigned >>> 24 - unassigned >>> 25 - unassigned >>> 26 - CCE = Critical Congestion Experienced >>> ------------------------------------------ >>> >>> NCItE flags = Non Critical Ingress-to-Egress >>> -------------------------------------------- >>> 27 - Ext Clr (no expansion found in document) >>> 28 two bit field >>> -------------------------------------------- >>> 29 - unassigned >>> 30 - unassigned >>> 31 - unassigned >>> >> >> I'm not sure how much explanation/definition needs to appear in this >> document for bits that are irrelevant to the document. All of your "no >> expansion found in document" comments are true and probably a bit more >> should be said but the draft does, in connection with bits other than >> those it specifies, say >> >> See [RFC7780] and [RFC7179] for the meaning of the other >> bits. >> >> The format seems moderately clear and is the same as in Section 10.2 >> of RFC 7780. Adding a mention that the TRILL Header Extension Flags >> Word is 32-bits and the bit numbers are across the top might >> help. Also, for those wishing to see a more tabular presentation, a >> pointer to the IANA Registry >> http://www.iana.org/assignments/trill-parameters/trill- >> parameters.xhtml#extended-header-flags >> might help. >> >> Multi-bit flags >>> --------------- >>> >>> In the context I've been active "flags" are one bit, if there are >>> multiple >>> bits they are called fields. I understand that in the context >>> this is written there are multiple bit flags. >>> >> >> At the beginning of Section 2, it says "a two-bit TRILL-ECN >> field". Since the name of the TRILL Header "Extension Flags Word" is >> now embedded in multiple RFCs, I don't think that should be changed >> but I wouldn't have any problem reviewing the draft to see that >> multi-bit regions of that 32-bit word are consistently referred to as >> fields. >> >> Bit 11 and 12 >>> ------------- >>> >>> Bit 11 and 12 has the following code points: >>> >>> Binary Name Meaning >>> ------ ------- ----------------------------------- >>> 00 Not-ECT Not ECN-Capable Transport >>> 01 ECT(1) ECN-Capable Transport (1) >>> 10 ECT(0) ECN-Capable Transport (0) >>> 11 NCCE Non-Critical Congestion Experienced >>> >>> Table 1. TRILL-ECN Field Codepoints >>> >>> There is no good explanation what ECT(0) and ECT(1) means, even though >>> it is (page 9) said that "ECT(1) as a lesser severity level, termed the >>> Threshold-Marked (ThM) codepoint". It could be inferred that ECT(0) is >>> a higher severity level, but this should be clearly spelled out. >>> >> >> That distinction between ECT(0) and ECT(1) only applies if the PCN >> variant of ECN is in use which is why the text you quote is in a >> subsection of Section 4 (TRILL Support for ECN Variants). There is a >> reference to RFC 6660 which talks about this. Perhaps we can make that >> clearer. >> >> RFC 3168 does not make the distinction between ECT(0) and ECT(1), but >>> says that it will be done in future RFCs; since this is about 3000 RFCs >>> ago it might have happened but I couldn't find it. If this has been done >>> I think a reference would be good. >>> >> >> This distincition is in RFC 6660 on PCN (Pre-Congestion Notification). >> >> Code Point 0b11 >>> --------------- >>> The text above Table 1 says: >>> OLD >>> "However codepoint 11 is called Non-Critical Congestion Experienced >>> (NCCE)..." >>> I think this should be: >>> However code point 0b11 is called Non-Critical Congestion Experienced >>> (NCCE)..." >>> >> >> OK. >> >> The text further says that the code point is call NCCE to distinguish >>> it from Congestion Experienced in IP. The question I have is why it is >>> necessary to distinguish code point 0b11, but not 0b00, 0b01 and 0b10? >>> >> >> Because the meaning of the other three code points is the same in >> TRILL and IP. >> >> ECN SUpport >>> ----------- >>> >>> The first paragraph has "logically" at three places, what would be the >>> difference if these "logically" are dropped? >>> >> >> Probably not. I think that word was included to be careful not to >> overly constrain the order of processing within a TRILL switch. >> >> First sentence in sectuion 3.1 >>> ------------------------------ >>> >>> The sentence says: >>> "The ingress behavior is as follows:" >>> >>> I would say >>> "The behavior of an ingress RBridge is as follows:" >>> or even >>> "The behavior of an ingress RBridge MUST be as follows:" >>> >> >> OK. >> >> cleared vs set to zero >>> ---------------------- >>> The last sub-bullet in the first main bullet of section 3.1 says: >>> "ensure the CCE flag is cleared to zero (Flags Word bit 26)." I would >>> have used "cleared" or "swt to zero". >>> >> >> I think "set to zero" is clearer. >> >> First line section 3,2 >>> ---------------------- >>> s/ahow/shown >>> Caveat I normally don't English grammar reviews, but sometimes I can't >>> stop >>> myself :) >>> >> >> OK. >> >> Second line first main bullet in section 3.2 >>> -------------------------------------------- >>> >>> I prefer the format "guidelines in RFC 7567 [RFC7567]" >>> >> >> I really don't see any benefit to that and I think "RFC xxxx >> [RFCxxxx]" is not used in TRILL RFCs. >> >> Third sub-bullet in the third main bullet of section 3.2 >>> --------------------------------------------------------- >>> >>> It says: >>> "+ set the TRILL-ECN field to Not-ECT (00);" >>> >>> Here you use "field" instead of "flag", which is fine, but the document >>> should be consistent. Either: >>> + set the TRILL-ECN field to Not-ECT (0b00); >>> or >>> + set the TRILL-ECN flag to Not-ECT (0b00); >>> >> >> I agree with your earlier comment that "field" is generally better. >> >> Egress ECN Support >>> ------------------ >>> First sentence: >>> "If the egress RBridge does not support ECN, it will ignore bits 12 >>> and 13 of any Flags Word that is present, because it does not contain >>> any special ECN logic." >>> >>> in "it will ignore" what does "it" refer to? >>> >>> SHould it be: >>> >>> "If the egress RBridge does not support ECN, the RBridge will ignore >>> the TRILL-ECN field (bits 12 and 13) if a Flags Word that is >>> present, because it has no ECN logic." >>> >> >> Yes, although it might be even clearer in the first line to say >> "... ECN, that RBridge will ..." >> >> TRILL Support for ECN Variants >>> ------------------------------ >>> The second sentence of section four says: >>> >>> Section 3 specifies interworking between TRILL and the original >>> standardized form of ECN in IP [RFC3168]. >>> >>> RFC 3168 is updated by RFC 4301, RFC 6040, does section 3 relate to >>> RFC 3168 or does the updates come into plan. IF the updates are in >>> scope I think the sentence should say: >>> >>> Section 3 specifies interworking between TRILL and the original >>> standardized form of ECN in IP RFC 3168 [RFC3168], and the updates >>> in RFC4310 [RFC4301] and RFC 6040 [6040]. >>> >> >> Interestingly, although RFC Editor meta-data consistencly shows RFC >> 4301 as updating RFC 3168, this is not indicated on the first page of >> RFC 4301. While ECN is mentioned a number of times in RFC 4301 and >> that RFC could be viewed as extending ECN, I'm not quite sure what, if >> any, change RFC 4301 makes to the behavior standardized RFC in 3168. >> >> I'll look at this more closely but I think the text currently in the >> draft is OK and need not refer to either RFC 4301 or RFC 6040. >> >> Nits: >>> >>> Codepoints >>> ---------- >>> at several places "codepoint(s)" I think the words IANA and the >>> RFC Editor use is "code point(s)" >>> >> >> While I didn't to an exhaustive search, everywhere I looked in the ECN >> and PCN RFCs, "codepoint" is used so I would prefer to leave this >> unchanged for now. >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> /Loa >>> -- >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a11408e4ec328e4054a8f7a39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Loa,

The -02 version of draft-ietf-t= rill-ecn-support, just posted, included the improvements we have discussed.=

Thanks,
Donald
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)<= br>=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Sat, Jan 28, 2017 at 3:44 AM, Loa Anderss= on <loa= @pi.nu> wrote:
Donald,

I'm pretty happy with your response on my comments. I think that the ag= reed updates will go a long way to improve readability of the
document.

/Loa


On 2017-01-27 06:09, Donald Eastlake wrote:
Hi Loa,

Thanks for your comments. See below

On Sat, Jan 21, 2017 at 12:02 AM, Loa Andersson <loa@pi.nu> wrote:
Authors,

I have been asked to do a Routing Area Directorate QA review of
draft-ietf-trill-ecn-support.

Caveat - I'm not a congestion control expert, and this will show up in<= br> my comments. The place where I ask for clarifications might be perfectly clear for a reader that is up to speed in the area.

Summary:

I think the document is on the right track, for a reader not an
expert in the area there are a lot of abbreviations that are not
properly expanded. I also think that it would be a good idea to more
clearly make the the case why the document is needed (abstract
and/or introduction).

After a while I stop trying to distinguish between "Minor issues"=
and "Nits" and placed everything as Minor Issues. I guess I could=
have done everything as Nits :).

OK :-)

Other than the Comment/Minor Issues I find the document pretty solid,

Thanks.

though I sometimes found it hard to parse sentences.
If you want I can take a look at that aspect once what is in this
review has been addressed.

Comments:

Last paragraph of the Introduction
----------------------------------

=C2=A0 =C2=A0Whichever RBridges do not support ECN, this
=C2=A0 =C2=A0specification ensures congestion notification will propagate s= afely
=C2=A0 =C2=A0to Destination because the packet will be dropped if explicit<= br> =C2=A0 =C2=A0congestion notification cannot be propagated and drop is itsel= f an
=C2=A0 =C2=A0implicit form of congestion notification.

Is this logic really watertight? What if the packet is dropped because of a=
checksum error?

I think the point of that paragraph is to overcome the presumption
many readers might have that ECN marking would be useless if the
Destination does not understand ECN marking.

Major Issues:


Minor Issues:

Abstract
--------
I find the Abstract a bit meager, a little more context would be good.

=C2=A0 =C2=A0Maybe lead with some short words about what ECN is good for.
And maybe use this from the Introduction:

=C2=A0 =C2=A0This specification provides for any ECN marking in the traffic= at the
=C2=A0 =C2=A0ingress to be copied into the TRILL Extension Header Flags Wor= d. It
=C2=A0 =C2=A0also enables congestion marking by a congested RBridge such as= RBn or
=C2=A0 =C2=A0RB1 above in the TRILL Header Extension Flags Word [RFC7179].<= br>

OK. How about this:

=C2=A0 =C2=A0Explicit congestion notification (ECN) allows a forwarding ele= ment
=C2=A0 =C2=A0to notify downstream devices, including the destination, of th= e
=C2=A0 =C2=A0onset of congestion without having to drop packets. This can =C2=A0 =C2=A0improve network efficiency through better flow control without=
=C2=A0 =C2=A0packet drops. This document extends ECN to TRILL switches,
=C2=A0 =C2=A0including integration with IP ECN, and provides for ECN markin= g in
=C2=A0 =C2=A0the TRILL Header Extension Flags Word (see RFC 7179).

ECNencapGuide
-------------

This reference has expired, probably not a problem since Bob is a
co-author of both documents.

TRILL Header
------------

Referred to in section in the Introduction, I think a reference would be good.

OK.

The ECN Specific Extended Header Flags
--------------------------------------

The pictures is less than intuitive, it took me quite some time de-code it.=
I did the following:
Critical (?) flags
=C2=A00 - CRHbH (no expansion found in document)
=C2=A01 - CRItE (no expansion found in document)
=C2=A02 - CRRsv (no expansion found in document)

CHbH flags (Critical Hop by Hop flags - no expansion found in document)
=C2=A03 - unassigned
=C2=A04 - unassigned
=C2=A05 - unassigned
=C2=A06 - unassigned
=C2=A07 - CRCAF (no expansion found in document)

NCHbH flags =3D Non-Critical Hop-by-Hop flags
=C2=A08 - NCCAF (no expansion found in document)
=C2=A09 - unassigned
10 - unassigned
11 - unassigned
-------------------------------------------
12 - ECN =3D Explicit Congestion Notification
13=C2=A0 =C2=A0(two bit flags)
-------------------------------------------

CRSV flags (no expansion found in document)
-------------------------------------------
14 - Ext Hop Cnt (no expansion found in document)
15=C2=A0 =C2=A0three bit field
16
------------------------------------------

NCRSV flags (no expansion found in document)
17 - unassigned
18 - unassigned
19 - unassigned
20 - unassigned
------------------------------------------

CItE flags =3D Critical Ingress-to-Egress
------------------------------------------
21 - unassigned
22 - unassigned
23 - unassigned
24 - unassigned
25 - unassigned
26 - CCE =3D Critical Congestion Experienced
------------------------------------------

NCItE flags =3D Non Critical Ingress-to-Egress
--------------------------------------------
27 - Ext Clr (no expansion found in document)
28=C2=A0 =C2=A0two bit field
--------------------------------------------
29 - unassigned
30 - unassigned
31 - unassigned

I'm not sure how much explanation/definition needs to appear in this document for bits that are irrelevant to the document. All of your "no=
expansion found in document" comments are true and probably a bit more=
should be said but the draft does, in connection with bits other than
those it specifies, say

=C2=A0 =C2=A0See [RFC7780] and [RFC7179] for the meaning of the other
=C2=A0 =C2=A0bits.

The format seems moderately clear and is the same as in Section 10.2
of RFC 7780. Adding a mention that the TRILL Header Extension Flags
Word is 32-bits and the bit numbers are across the top might
help. Also, for those wishing to see a more tabular presentation, a
pointer to the IANA Registry
http://= www.iana.org/assignments/trill-parameters/trill-parameters.xhtml#= extended-header-flags
might help.

Multi-bit flags
---------------

In the context I've been active "flags" are one bit, if there= are multiple
bits they are called fields. I understand that in the context
this is written there are multiple bit flags.

At the beginning of Section 2, it says "a two-bit TRILL-ECN
field". Since the name of the TRILL Header "Extension Flags Word&= quot; is
now embedded in multiple RFCs, I don't think that should be changed
but I wouldn't have any problem reviewing the draft to see that
multi-bit regions of that 32-bit word are consistently referred to as
fields.

Bit 11 and 12
-------------

Bit 11 and 12 has the following code points:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Binary=C2=A0 Name=C2=A0 =C2=A0 =C2=A0Mea= ning
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ------=C2=A0 -------=C2=A0 -------------= ----------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 00=C2=A0 =C2=A0 =C2=A0Not-ECT Not= ECN-Capable Transport
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 01=C2=A0 =C2=A0 =C2=A0ECT(1)=C2= =A0 ECN-Capable Transport (1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10=C2=A0 =C2=A0 =C2=A0ECT(0)=C2= =A0 ECN-Capable Transport (0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11=C2=A0 =C2=A0 =C2=A0NCCE=C2=A0 = =C2=A0 Non-Critical Congestion Experienced

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Table= 1. TRILL-ECN Field Codepoints

There is no good explanation what ECT(0) and ECT(1) means, even though
it is (page 9) said that "ECT(1) as a lesser severity level, termed th= e
Threshold-Marked (ThM) codepoint". It could be inferred that ECT(0) is=
a higher severity level, but this should be clearly spelled out.

That distinction between ECT(0) and ECT(1) only applies if the PCN
variant of ECN is in use which is why the text you quote is in a
subsection of Section 4 (TRILL Support for ECN Variants). There is a
reference to RFC 6660 which talks about this. Perhaps we can make that
clearer.

RFC 3168 does not make the distinction between ECT(0) and ECT(1), but
says that it will be done in future RFCs; since this is about 3000 RFCs
ago it might have happened but I couldn't find it. If this has been don= e
I think a reference would be good.

This distincition is in RFC 6660 on PCN (Pre-Congestion Notification).

Code Point 0b11
---------------
The text above Table 1 says:
OLD
"However codepoint 11 is called Non-Critical Congestion Experienced (NCCE)..."
I think this should be:
However code point 0b11 is called Non-Critical Congestion Experienced
(NCCE)..."

OK.

The text further says that the code point is call NCCE to distinguish
it from Congestion Experienced in IP. The question I have is why it is
necessary to distinguish code point 0b11, but not 0b00, 0b01 and 0b10?

Because the meaning of the other three code points is the same in
TRILL and IP.

ECN SUpport
-----------

The first paragraph has "logically" at three places, what would b= e the
difference if these "logically" are dropped?

Probably not. I think that word was included to be careful not to
overly constrain the order of processing within a TRILL switch.

First sentence in sectuion 3.1
------------------------------

The sentence says:
"The ingress behavior is as follows:"

I would say
"The behavior of an ingress RBridge is as follows:"
or even
"The behavior of an ingress RBridge MUST be as follows:"

OK.

cleared vs set to zero
----------------------
The last sub-bullet in the first main bullet of section 3.1 says:
"ensure the CCE flag is cleared to zero (Flags Word bit 26)." I w= ould
have used "cleared" or "swt to zero".

I think "set to zero" is clearer.

First line section 3,2
----------------------
s/ahow/shown
Caveat I normally don't English grammar reviews, but sometimes I can= 9;t stop
myself :)

OK.

Second line first main bullet in section 3.2
--------------------------------------------

I prefer the format "guidelines in RFC 7567 [RFC7567]"

I really don't see any benefit to that and I think "RFC xxxx
[RFCxxxx]" is not used in TRILL RFCs.

Third sub-bullet in the third main bullet of section 3.2
---------------------------------------------------------

It says:
"+=C2=A0 set the TRILL-ECN field to Not-ECT (00);"

Here you use "field" instead of "flag", which is fine, = but the document
should be consistent. Either:
+=C2=A0 set the TRILL-ECN field to Not-ECT (0b00);
or
+=C2=A0 set the TRILL-ECN flag to Not-ECT (0b00);

I agree with your earlier comment that "field" is generally bette= r.

Egress ECN Support
------------------
First sentence:
=C2=A0 "If the egress RBridge does not support ECN, it will ignore bit= s 12
=C2=A0 =C2=A0and 13 of any Flags Word that is present, because it does not = contain
=C2=A0 =C2=A0any special ECN logic."

in "it will ignore" what does "it" refer to?

SHould it be:

=C2=A0 "If the egress RBridge does not support ECN, the RBridge will i= gnore
=C2=A0 =C2=A0the TRILL-ECN field (bits 12 and 13) if a Flags Word that is =C2=A0 =C2=A0present, because it has no ECN logic."

Yes, although it might be even clearer in the first line to say
"... ECN, that RBridge will ..."

TRILL Support for ECN Variants
------------------------------
The second sentence of section four says:

=C2=A0 =C2=A0Section 3 specifies interworking between TRILL and the origina= l
=C2=A0 =C2=A0standardized form of ECN in IP [RFC3168].

RFC 3168 is updated by RFC 4301, RFC 6040, does section 3 relate to
RFC 3168 or does the updates come into plan. IF the updates are in
scope I think the sentence should say:

=C2=A0 =C2=A0Section 3 specifies interworking between TRILL and the origina= l
=C2=A0 =C2=A0standardized form of ECN in IP RFC 3168 [RFC3168], and the upd= ates
=C2=A0 =C2=A0in RFC4310 [RFC4301] and RFC 6040 [6040].

Interestingly, although RFC Editor meta-data consistencly shows RFC
4301 as updating RFC 3168, this is not indicated on the first page of
RFC 4301. While ECN is mentioned a number of times in RFC 4301 and
that RFC could be viewed as extending ECN, I'm not quite sure what, if<= br> any, change RFC 4301 makes to the behavior standardized RFC in 3168.

I'll look at this more closely but I think the text currently in the draft is OK and need not refer to either RFC 4301 or RFC 6040.

Nits:

Codepoints
----------
at several places "codepoint(s)" I think the words IANA and the RFC Editor use is "code point(s)"

While I didn't to an exhaustive search, everywhere I looked in the ECN<= br> and PCN RFCs, "codepoint" is used so I would prefer to leave this=
unchanged for now.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.co= m

/Loa
--

Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--001a11408e4ec328e4054a8f7a39-- From nobody Mon Mar 13 09:08:26 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B140129705; Mon, 13 Mar 2017 09:08:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148942129463.16823.6051005677244961865.idtracker@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:08:14 -0700 Archived-At: Cc: draft-ietf-trill-directory-assist-mechanisms@ietf.org, akatlas@gmail.com, trill-chairs@ietf.org, The IESG , trill@ietf.org, shares@ndzh.com, rfc-editor@rfc-editor.org Subject: [trill] Protocol Action: 'TRILL: Edge Directory Assist Mechanisms' to Proposed Standard (draft-ietf-trill-directory-assist-mechanisms-12.txt) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:08:17 -0000 The IESG has approved the following document: - 'TRILL: Edge Directory Assist Mechanisms' (draft-ietf-trill-directory-assist-mechanisms-12.txt) as Proposed Standard This document is the product of the Transparent Interconnection of Lots of Links Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/ Technical Summary This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi- destination traffic, particularly ARP/ND and unknown unicast flooding. It can also be used to detect traffic with forged source addresses. Directory Service can utilize either a push or a pull mechanism. Working Group Summary This document is the result of 3 years of intensive discussion. The WG consensus was complete even if the WG discussion at the end of the three years was "Time to send this to IESG". Document Quality The Shepherd's review at 2/8/2016 https://mailarchive.ietf.org/arch/msg/trill/HZ5p1GTo_2vJT6xOPPDyVB15P3Q Authors response: https://mailarchive.ietf.org/arch/msg/trill/ezH1lwbqOwTBuC4h_WtcZ_QNaxw Shepherd's review of changes and acceptance of changes (minus 2 editorial nits) https://mailarchive.ietf.org/arch/msg/trill/oQjR3jwAKkayHvPRdKznCmOf8u4 Final resolution by Authors: https://mailarchive.ietf.org/arch/msg/trill/FkSuXx4ugHIzYsuVIhE3xlOizZM Shepherds post IETF LC review: https://mailarchive.ietf.org/arch/msg/trill/SUMuYIuHz0bg1bSxXEZz9Vsnqjc - Based on draft-ietf-trill-directory-assist-mechanism-10.txt + Suresh Krishnan's comments on SEND in https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ballot/ This review look for SEND and anything unspecified. Routing QA reviewer (follow email thread for review) http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02676.html AD review: https://www.ietf.org/mail-archive/web/trill/current/msg07605.html Personnel Document Shepherd: Susan Hares (WG co-chair) Responsible Area Director: (Alia Atlas) From nobody Sun Mar 19 13:35:54 2017 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 54FCF126C83; Sun, 19 Mar 2017 13:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x899DJUXRWBW; Sun, 19 Mar 2017 13:35:48 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE6512709D; Sun, 19 Mar 2017 13:35:48 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id u132so49887585wmg.0; Sun, 19 Mar 2017 13:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=No/ewTmh8pH5rQ1hGy2f6ZFZ7cXdi2qEbbMq4BkRfQs=; b=RN1ceAXNYSAxwmOAk9A7Z61OVRWiAihT+eakv6JpTMfCEvQAlg7gF85ULxeM34VjZ0 k3OoD8A1KbpZtYgHadpF4W6khEMvRgpDzcavz/kd51OsC93pQ5Xgnfnlf217viYFjhm9 QMniwlNw+6/++tBLrORC8Vq+v2mtXJpAWGU30cw99EIAHLLmIX1ndeD5COQtRmbFo4Bz TA5d0zbXcc/B85T9DK77cgAT1sKmJnwQ1ppuht+bFohbiCXoht3G9Ko3rUrsJ523dwKo 740zt5bMOR//RWSgO1mKqEJ9egOlQDKBIACuzfKgatbJ8mh2oXXL7oVUT9C27cgZqRg0 TIVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=No/ewTmh8pH5rQ1hGy2f6ZFZ7cXdi2qEbbMq4BkRfQs=; b=J25ZtV/YF6oQthgp2vZLiA2gMkbmSKlr6GV2nUq5hjFSn5NJHBMPRN3qQuHUucDnMw euVeTVa3oGMGwcusc4i4sxTpggzWPK/hXYLvjMKeSMjUFnNO0bhI0hPdRX2vk6XxfvBY XY8BByDhiH/32tj7ian55k1EH/iL6jNMM/iXglLT/gKcbAFK00hfFmQ9RSO9QcISxVtJ d49OaqhDk51wJ8WlbS4skIeBU0Q1+Er+cPcnZEqBzu1+HtSXKYIz4Qhe1nAabgAT261g LQi2OnfrPkKikn+67HvyJUHHTvjYee+suHXabuUddVymBSOu2K9+Mn81EyhNqsksFY1K ys/w== X-Gm-Message-State: AFeK/H0D3ohOTt/LLR0BAVVZY1i416jyQHhI46I65+KrnMnjzWruXiT5zhplbvyxU4dxY9K6sdEnjRp/c9noPw== X-Received: by 10.28.50.6 with SMTP id y6mr7288829wmy.112.1489955746893; Sun, 19 Mar 2017 13:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.153.164 with HTTP; Sun, 19 Mar 2017 13:35:46 -0700 (PDT) In-Reply-To: References: <8FA0B47D-32C0-41D0-BBDD-35F430DC44EE@nokia.com> From: Kingston Smiler Date: Mon, 20 Mar 2017 02:05:46 +0530 Message-ID: To: "Andrew G. Malis" Cc: "Bocci, Matthew (Nokia - GB)" , "draft-ietf-trill-transport-over-mpls@ietf.org" , "rtg-dir@ietf.org" , "trill@ietf.org" Content-Type: multipart/alternative; boundary=001a1140dc560658b5054b1b5bfd Archived-At: Subject: Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 20:35:53 -0000 --001a1140dc560658b5054b1b5bfd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andy and Mathew, Thanks for your comments. Plz find our response inline between tags P.S: Sorry. Was tied up with some work and hence the delay. Regards, S. Kingston Smiler. On Mon, Feb 27, 2017 at 10:12 PM, Andrew G. Malis wrote= : > I=E2=80=99ve got some comments on Matthew=E2=80=99s review, inline. > > On Mon, Feb 27, 2017 at 10:44 AM, Bocci, Matthew (Nokia - GB) < > matthew.bocci@nokia.com> wrote: > >> Routing Area Directorate QA review of draft-ietf-trill-transport-ove >> r-mpls-02 >> >> >> >> Hi, >> >> >> >> I have been assigned the QA reviewer for this draft. The general >> guidelines for QA reviews >> >> can be found at: >> >> https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa >> >> >> >> These state: >> >> >> >> "When reviewing a draft at WG Adoption, the QA Reviewer should >> >> determine whether the draft is readable, understandable, makes sense >> >> and is a good start for a WG draft. Any issues the QA Reviewer finds >> >> are written down, sent to the mailing list and discussed for future >> >> versions" >> >> >> >> Here is my review of this draft: >> >> >> >> ** Summary. >> >> Generally, the draft is well written - thank you. I have a few minor >> comments below, >> >> mostly related to the relationship between TRILL over MPLS and >> established VPLS mechanisms. >> >> >> >> ** Is the draft readable? >> >> >> >> Yes. There are a few minor grammatical errors and it would help if the >> draft was proof-read >> >> to weed-out these. An example is: >> >> Abstract >> >> "..that are separated by MPLS provider network." >> >> s/by MPLS/by an MPLS >> >> >> >> >> >> ** Is the draft understandable? >> >> >> >> Yes, provided the reader is familiar with TRILL, MPLS and VPLS. >> >> >> >> ** Does it make sense? >> >> I think it is mostly clear, but I have a few comments, as follows: >> >> >> >> Section 3.4. MPLS encapsulation for VPLS model >> >> >> >> "Use of VPLS [RFC4762] to interconnect TRILL sites requires no changes t= o >> >> a VPLS implementation, in particular the use of Ethernet pseudowires >> >> between VPLS PEs. A VPLS PE receives normal Ethernet frames from an >> >> RBridge (i.e., CE) and is not aware that the CE is an RBridge device. As >> >> a result, an MPLS-encapsulated TRILL packet within the MPLS network will >> >> use the format illustrated in Appendix A of [RFC7173]." >> >> >> >> It doesn't look like the encapsulation shown in Appendix A of >> >> RFC7173 takes account of the case where PBB VPLS [RFC7041] is used in th= e >> provider's >> >> MPLS network, but I would have thought this would still be a valid VPLS >> type to transport >> >> TRILL. It might be worth qualifying your reference with some text to >> state that >> >> this is just an example in the non-PBB case. >> > > Andy: As the author of this paragraph, I agree with Matthew=E2=80=99s com= ment. We > can change the last sentence to say: > > "As an example, an MPLS-encapsulated TRILL packet within the MPLS network > will > use the format illustrated in Appendix A of [RFC7173] for the non-PBB > case, or > in the PBB case, with the additional header fields illustrated in > [RFC7041]." > > Typically PBB-VPLS is used to avoid exposing the customer MAC in service provider network. In case of TRILL packet over MPLS, already the customer MAC is encapsulated inside the TRILL header. Having said that, do we really need to consider TRILL over PBB-VPLS. > >> >> Section 4.1.1: >> >> "TIR devices are a superset of the VPLS-PE devices defined in [RFC4026] >> with the >> >> additional functionality of TRILL." >> >> Is this really true? Later you state that TIRs use PPP PWs, not the >> Ethernet PWs used in >> >> VPLS. It is also not clear if TRILL needs some of the LDP or BGP >> signaling extensions >> >> used for VPLS. Wouldn't it be cleaner just to define a TIR as a new kind >> of PE? >> > > Andy: I also agree with this comment. > > >> >> > Agreed to your comment. We need to consider ethernet encapsulation. Will update the draft Section 6. VPTS Model Versus VPLS Model >> >> "An issue with the above rule is that if a pseudowire between PEs fails, >> >> frames will not get forwarded between the PEs where pseudowire went >> >> down." >> >> >> >> I think this is only true for a simple full mesh VPLS where there are no= t >> other protection >> >> mechanisms. I am not sure this is applicable to H-VPLS with PW >> redundancy, for example, >> >> which I think is likely to be a widespread deployment case for the VPLS >> model of TRILL >> >> over MPLS. >> > > Andy: I agree. In addition, see section 4.4 of RFC 4742, which allows the > use of spanning tree in a VPLS network to provide redundancy in the case = of > a failure in the VPLS. > > Agreed to your comment. Will update the same in next version of the draft > > >> >> Best regards >> >> Matthew >> > > Cheers, > Andy > > > --001a1140dc560658b5054b1b5bfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy and Mathew,

Thanks for your com= ments. Plz find our response inline between <Kin= gston> tags

P.S: Sorry. Was tied up with= some work and hence the delay.

Regards,
S. Kingston Smiler.

On Mon, Feb 27, 2017 at 10:12 PM, Andrew G. Malis <agmalis@gmail.= com> wrote:
I=E2=80=99ve got some comments on Matthew=E2=80=99s re= view, inline.

On Mon, Feb 27, 2017 at 10:44 AM, Bocci, Matthew (= Nokia - GB) <matthew.bocci@nokia.com> wrote:

Routing Area Director= ate QA review of draft-ietf-trill-transport-over-mpls-02=

=C2=A0<= /span>

Hi,

=C2=A0<= /span>

I have been assigned = the QA reviewer for this draft. The general guidelines for QA reviews

can be found at:

https://trac.ietf.= org/trac/rtg/wiki/RtgDirDocQa

=C2=A0<= /span>

These state:

=C2=A0<= /span>

=C2=A0 "When rev= iewing a draft at WG Adoption, the QA Reviewer should<= /p>

=C2=A0 determine whet= her the draft is readable, understandable, makes sense=

=C2=A0 and is a good = start for a WG draft. Any issues the QA Reviewer finds=

=C2=A0 are written do= wn, sent to the mailing list and discussed for future<= /p>

=C2=A0 versions"=

=C2=A0<= /span>

Here is my review of = this draft:

=C2=A0<= /span>

** Summary.=

Generally, the draft = is well written - thank you. I have a few minor comments below,

mostly related to the= relationship between TRILL over MPLS and established VPLS mechanisms.

=C2=A0<= /span>

** Is the draft reada= ble?

=C2=A0<= /span>

Yes. There are a few = minor grammatical errors and it would help if the draft was proof-read

to weed-out these. An= example is:

Abstract

"..that are sepa= rated by MPLS provider network."

s/by MPLS/by an MPLS<= u>

=C2=A0<= /span>

=C2=A0<= /span>

** Is the draft under= standable?

=C2=A0<= /span>

Yes, provided the rea= der is familiar with TRILL, MPLS and VPLS.

=C2=A0<= /span>

** Does it make sense= ?

I think it is mostly = clear, but I have a few comments, as follows:

=C2=A0<= /span>

Section 3.4. MPLS enc= apsulation for VPLS model

=C2=A0<= /span>

"Use of VPLS [RF= C4762] to interconnect TRILL sites requires no changes to

a VPLS implementation= , in particular the use of Ethernet pseudowires

between VPLS PEs. A V= PLS PE receives normal Ethernet frames from an

RBridge (i.e., CE) an= d is not aware that the CE is an RBridge device. As

a result, an MPLS-enc= apsulated TRILL packet within the MPLS network will

use the format illust= rated in Appendix A of [RFC7173]."

=C2=A0<= /span>

It doesn't look l= ike the encapsulation shown in Appendix A of

RFC7173 takes account= of the case where PBB VPLS [RFC7041] is used in the provider's

MPLS network, but I w= ould have thought this would still be a valid VPLS type to transport

TRILL. It might be wo= rth qualifying your reference with some text to state that

this is just an examp= le in the non-PBB case.



A= ndy: As the author of this paragraph, I agree with Matthew=E2=80=99s commen= t. We can change the last sentence to say:

&q= uot;As an example, an MPLS-encapsulated TRILL packet within the MPLS networ= k will
use the format illustrated in Appendix A of [RFC7173] for = the non-PBB case, or
in the PBB case, with the additional h= eader fields illustrated in [RFC7041]."

<Kingston>
Typically PBB-VPLS is used to avo= id exposing the customer MAC in service provider network. In case of TRILL = packet over MPLS, already the customer MAC is encapsulated inside the TRILL= header. Having said that, do we really need to consider TRILL over PBB-VPL= S. =C2=A0=C2=A0
</Kingston>=C2=A0=C2=A0

=C2=A0<= /span>

Section 4.1.1:=

"TIR devices are= a superset of the VPLS-PE devices defined in [RFC4026] with the

additional functional= ity of TRILL."

Is this really true? = Later you state that TIRs use PPP PWs, not the Ethernet PWs used in

VPLS. It is also not = clear if TRILL needs some of the LDP or BGP signaling extensions

used for VPLS. Wouldn= 't it be cleaner just to define a TIR as a new kind of PE?


Andy: I also agree with t= his comment.
=C2=A0

=C2=A0<= /p>

<Kingston>
Agreed to your comment. We need to cons= ider ethernet encapsulation. Will update the draft
<= div></Kingston>=C2=A0

Section 6. VPTS Model= Versus VPLS Model

"An issue with t= he above rule is that if a pseudowire between PEs fails,

frames will not get f= orwarded between the PEs where pseudowire went

down."=

=C2=A0<= /span>

I think this is only = true for a simple full mesh VPLS where there are not other protection

mechanisms. I am not = sure this is applicable to H-VPLS with PW redundancy, for example,

which I think is like= ly to be a widespread deployment case for the VPLS model of TRILL

over MPLS.

=

Andy: I agree. In addit= ion, see section 4.4 of RFC 4742, which allows the use of spanning tree in = a VPLS network to provide redundancy in the case of a failure in the VPLS.<= /div>

<Kingston>
Agreed to your comment.=C2=A0=C2=A0Will update t= he same in next version of the draft
</Kingston>=C2=A0

=

=C2=A0<= /span>

=C2=A0Best regards

=

=C2=A0Matthew<= /p>


Cheers,
=
Andy
=C2=A0


--001a1140dc560658b5054b1b5bfd-- From nobody Mon Mar 20 00:10:32 2017 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 563E012714F; Mon, 20 Mar 2017 00:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXAYZGrWzumR; Mon, 20 Mar 2017 00:10:28 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5F2127071; Mon, 20 Mar 2017 00:10:27 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id a12so57115929ota.0; Mon, 20 Mar 2017 00:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t+zAJtqwCljomM0iouGXnarfLOcTy6g1YX0P7/+j91I=; b=A0B2g+JTYnp4FPvMBe1dEUovVr8m70CeuK0SBWdVgmbpueHLnDmAyMvWFP8wYoPjxO u/yq4afa0Zu1OoWOFtgqNwfBaHIVPwoADOXcFMMx1FursLeCp4Eg2tNh0HOQyeYq67PM mwBaDjvLaTqrGo7QEJskjWkR1m4FL2kfK6xiFrvbu90gdG1qq5j1zvR3mFDnOp0oeOc8 4QtHwI5UeT5OrA8LeeAADQK8kVcS0zMC6WyCmmgj+a5VJF7GBRBZGLK+TPHsMLhtC4YW Db0Of9S0XSvzQxUJR4BiIgFgJdfXRSHJgVr+KAM4ChVbMzfTj5MvtNsMyjvfSOXu15c2 q1Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t+zAJtqwCljomM0iouGXnarfLOcTy6g1YX0P7/+j91I=; b=L2T74TI6TsB1inhhLhXVOjiwPacOMTUBcaLCJ5Zg7hFyBZvHSboRI3TDouXYPif8pO VQ5xeJm/fpLqJPsIVCcL5Hi3RTmrJRfWgv8t99yauNDUfU2/Ib/ig/0NUWrD7hDgZf9n 1sN/3THVqN5OdYh0Vq28SEwxda2tYpf14/UILdfkNOOgOj2bkpt6a4R8GXrvXFtD9DoF tjlvJ1t4mfqyEFNkn1VrdodB/TH3NI82lfSCSQ/c9g9jnRul6NlV8AX2dLQfxijj3CfS NxeT8e9/ebXl+CCBWVY6jaFXN9g5glvZGfn5bnreVkXvnXa9BkZqay4CrYpWIby15l9o AgQQ== X-Gm-Message-State: AFeK/H2Jqo7eS+3/Msk6W1NstL/j+jf1GTmiqr4MJazvWP2oVC2I+vwFHsjnMHLBS8cdMn33lOhMNihoIWeXnQ== X-Received: by 10.157.82.91 with SMTP id q27mr13136990otg.50.1489993827376; Mon, 20 Mar 2017 00:10:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.201 with HTTP; Mon, 20 Mar 2017 00:10:07 -0700 (PDT) In-Reply-To: References: <8FA0B47D-32C0-41D0-BBDD-35F430DC44EE@nokia.com> From: "Andrew G. Malis" Date: Mon, 20 Mar 2017 03:10:07 -0400 Message-ID: To: Kingston Smiler Cc: "Bocci, Matthew (Nokia - GB)" , "draft-ietf-trill-transport-over-mpls@ietf.org" , "rtg-dir@ietf.org" , "trill@ietf.org" Content-Type: multipart/alternative; boundary=f403043c4028cc6784054b24387d Archived-At: Subject: Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 07:10:30 -0000 --f403043c4028cc6784054b24387d Content-Type: text/plain; charset=UTF-8 Kingston, On Sun, Mar 19, 2017 at 4:35 PM, Kingston Smiler wrote: > > Typically PBB-VPLS is used to avoid exposing the customer MAC in service > provider network. In case of TRILL packet over MPLS, already the customer > MAC is encapsulated inside the TRILL header. Having said that, do we really > need to consider TRILL over PBB-VPLS. > > >> PBB (and by extension, PBB-VPLS) is not just used for C-MAC hiding, but also for provider infrastructure scaling, so I would think the answer is yes. Matthew, do you agree? Cheers, Andy --f403043c4028cc6784054b24387d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kingston,

On Sun, Mar 19, 2017 at 4:35 PM, = Kingston Smiler <kingstonsmiler@gmail.com> wrote:
=
<Kingston>
<= font color=3D"#0000ff">Typically PBB-VPLS is used to avoid exposing the cus= tomer MAC in service provider network. In case of TRILL packet over MPLS, a= lready the customer MAC is encapsulated inside the TRILL header. Having sai= d that, do we really need to consider TRILL over PBB-VPLS. =C2=A0=C2=A0
<= /Kingston>=C2=A0=C2=A0


PBB (and by extension, PBB-VPLS) is not just used for C-MAC hiding, but = also for provider infrastructure scaling, so I would think the answer is ye= s. Matthew, do you agree?

Cheers,
Andy

--f403043c4028cc6784054b24387d-- From nobody Tue Mar 21 09:18:46 2017 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 3278C129BA8; Tue, 21 Mar 2017 09:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqKpL5i0bVtQ; Tue, 21 Mar 2017 09:18:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA51129B97; Tue, 21 Mar 2017 09:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=334; q=dns/txt; s=iport; t=1490113053; x=1491322653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wvJfsRUWMeteELBzgf4fQJyrf2az2ObmAg2Bs75YY1Q=; b=eI7efpxflGOb3jdrQcNMoqVDyrBjffd9mYtc1jQRZBK///cnMiidgP1Z 15WwKIbb0GvSTDk+LNAtsUpyNfRD1vNRkgDaru0bKex1iy/0s/uDxHJwc KqoaMLNee+U64LiQ/URwO5x3nWdEevd64fBAC9KIKTpbxLHRBXhyRl9jU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAQBkUdFY/5NdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBaweDW4oQmXCLI4IPgg6GIgIagnk/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?GIxFFEAIBCA4MAiYCAgIfERUQAgQOBYlsAxWqOYImhz8NgnkBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgQuFQ4IFgmqCUYIDgwYugjEBBJYGhhA6AY4ThDKBYwGPSYp?= =?us-ascii?q?riHMBHziBBFgVUgGGRXWINIENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,200,1486425600"; d="scan'208";a="220943425" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2017 16:17:32 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2LGHWtD017007 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Mar 2017 16:17:32 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Mar 2017 11:17:32 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 21 Mar 2017 11:17:32 -0500 From: "Alvaro Retana (aretana)" To: Donald Eastlake CC: The IESG , "draft-ietf-trill-rfc6439bis@ietf.org" , Susan Hares , "trill-chairs@ietf.org" , "trill@ietf.org" Thread-Topic: Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS) Thread-Index: AQHSccn8d2iuKLA/v0GoMHUkJqLJpaE/nkSAgABMx4CANIidgIAbVDQAgBB2bAA= Date: Tue, 21 Mar 2017 16:17:32 +0000 Message-ID: <47DE0CEC-AB8D-4DAA-82A4-CC2E23D1468E@cisco.com> References: <148477153647.2298.16876633792182475280.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.254.201] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:18:39 -0000 RG9uYWxkOg0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLg0KDQpJIGp1c3QgY2xlYXJl ZC4NCg0KQWx2YXJvLg0KDQoNCg0KT24gMy8xMS8xNywgNTo1MyBBTSwgIkRvbmFsZCBFYXN0bGFr ZSIgPGQzZTNlM0BnbWFpbC5jb20+IHdyb3RlOg0KDQpDb3VsZCB5b3UgbG9vayBhdCB2ZXJzaW9u IC0wNSB3aGljaCBpcyBpbnRlbmRlZCB0byByZXNvbHZlIHlvdXINCkRJU0NVU1MgYXMgZGlzY3Vz c2VkIGJlbG93Lg0KDQo= From nobody Tue Mar 21 11:39:22 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4834D1294FA; Tue, 21 Mar 2017 11:39:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.48.00 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , shares@ndzh.com, akatlas@gmail.com, trill-chairs@ietf.org, draft-ietf-trill-rfc6439bis@ietf.org, trill@ietf.org, Susan Hares , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149012154919.3557.9342713230865279733.idtracker@ietfa.amsl.com> Date: Tue, 21 Mar 2017 11:39:09 -0700 Archived-At: Subject: [trill] Protocol Action: 'TRILL: Appointed Forwarders' to Proposed Standard (draft-ietf-trill-rfc6439bis-05.txt) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 18:39:09 -0000 The IESG has approved the following document: - 'TRILL: Appointed Forwarders' (draft-ietf-trill-rfc6439bis-05.txt) as Proposed Standard This document is the product of the Transparent Interconnection of Lots of Links Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/ Technical Summary TRILL supports multi-access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders", with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and obsoletes RFC 6439. Working Group Summary WG has discussed this for 2 years. The consensus seemed reasonable. Document Quality There are no existing implementations, but Huawei plans to implement this draft. Personnel Document shephered: Susan Hares Responsible AD: Alia Atlas From nobody Thu Mar 23 12:20:31 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 635E7129C0B; Thu, 23 Mar 2017 12:20:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Pignataro To: Cc: draft-ietf-trill-p2mp-bfd.all@ietf.org, ietf@ietf.org, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149029682927.22415.11722241596169339182@ietfa.amsl.com> Date: Thu, 23 Mar 2017 12:20:29 -0700 Archived-At: Subject: [trill] Review of draft-ietf-trill-p2mp-bfd-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:20:29 -0000 Reviewer: Carlos Pignataro Review result: Has Nits Hi, This is a short yet well written document. Looks really good. Just a couple of small questions/comments: 1. It's not clear exactly what from RFC 7175 is being updated by Section 4. This is based on the last paragraph of the Intro, yet Section 5 also seems relevant to that update. 2. In the IANA COnsiderations, it would be useful to explicitly list that the "RBridge Channel Protocols" registry is part of the "Transparent Interconnection of Lots of Links (TRILL) Parameters" Thanks, Carlos Pignataro. From nobody Thu Mar 23 12:24:31 2017 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 992AC129BF3; Thu, 23 Mar 2017 12:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78CSRA3jQIoG; Thu, 23 Mar 2017 12:24:13 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD77B131635; Thu, 23 Mar 2017 12:24:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: "'Carlos Pignataro'" , Cc: , , References: <149029682927.22415.11722241596169339182@ietfa.amsl.com> In-Reply-To: <149029682927.22415.11722241596169339182@ietfa.amsl.com> Date: Thu, 23 Mar 2017 15:18:58 -0400 Message-ID: <00c301d2a40a$52aa0cb0$f7fe2610$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJSSExrVMsGcWq11VRSKhba87ASTqCjhABA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [trill] [RTG-DIR] Review of draft-ietf-trill-p2mp-bfd-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:24:15 -0000 Carlos:=20 Thank you for the quick review.=20 Sue=20 -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Carlos = Pignataro Sent: Thursday, March 23, 2017 3:20 PM To: rtg-dir@ietf.org Cc: draft-ietf-trill-p2mp-bfd.all@ietf.org; ietf@ietf.org; = trill@ietf.org Subject: [RTG-DIR] Review of draft-ietf-trill-p2mp-bfd-04 Reviewer: Carlos Pignataro Review result: Has Nits Hi, This is a short yet well written document. Looks really good. Just a = couple of small questions/comments: 1. It's not clear exactly what from RFC 7175 is being updated by Section = 4. This is based on the last paragraph of the Intro, yet Section 5 also = seems relevant to that update. 2. In the IANA COnsiderations, it would be useful to explicitly list = that the "RBridge Channel Protocols" registry is part of the = "Transparent Interconnection of Lots of Links (TRILL) Parameters"=20 Thanks, Carlos Pignataro. From nobody Thu Mar 23 15:37:36 2017 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 70D4612948D; Thu, 23 Mar 2017 15:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjwB-BMBvTFh; Thu, 23 Mar 2017 15:37:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4DB1292FD; Thu, 23 Mar 2017 15:37:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJM22142; Thu, 23 Mar 2017 22:37:18 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 23 Mar 2017 22:37:17 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 24 Mar 2017 06:37:09 +0800 From: "Zhangmingui (Martin)" To: Carlos Pignataro , "rtg-dir@ietf.org" CC: "draft-ietf-trill-p2mp-bfd.all@ietf.org" , "ietf@ietf.org" , "trill@ietf.org" Thread-Topic: Review of draft-ietf-trill-p2mp-bfd-04 Thread-Index: AQHSpAqM/H6sHj72GE6hAlFdfMbv2aGjAqca Date: Thu, 23 Mar 2017 22:37:09 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A6418619@NKGEML515-MBX.china.huawei.com> References: <149029682927.22415.11722241596169339182@ietfa.amsl.com> In-Reply-To: <149029682927.22415.11722241596169339182@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58D44E1F.00F6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0afbde728a7e0f1dbe61aa7f651780fa Archived-At: Subject: Re: [trill] Review of draft-ietf-trill-p2mp-bfd-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 22:37:24 -0000 Hi Carlos, 1. Yes. Section 5 rather than Seciton 4 is relevant. The last paragraph of = the Intro will be updated to reflect this. 2. OK. The text will be updated. Thanks, Mingui ________________________________________ From: Carlos Pignataro [cpignata@cisco.com] Sent: Friday, March 24, 2017 3:20 To: rtg-dir@ietf.org Cc: draft-ietf-trill-p2mp-bfd.all@ietf.org; ietf@ietf.org; trill@ietf.org Subject: Review of draft-ietf-trill-p2mp-bfd-04 Reviewer: Carlos Pignataro Review result: Has Nits Hi, This is a short yet well written document. Looks really good. Just a couple of small questions/comments: 1. It's not clear exactly what from RFC 7175 is being updated by Section 4. This is based on the last paragraph of the Intro, yet Section 5 also seems relevant to that update. 2. In the IANA COnsiderations, it would be useful to explicitly list that the "RBridge Channel Protocols" registry is part of the "Transparent Interconnection of Lots of Links (TRILL) Parameters" Thanks, Carlos Pignataro.= From nobody Fri Mar 31 12:09:12 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 673C1127B60; Fri, 31 Mar 2017 12:09:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149098735127.4317.7979958256474267556@ietfa.amsl.com> Date: Fri, 31 Mar 2017 12:09:11 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-yang-oam-05.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 19:09:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM) Authors : Deepak Kumar Tissa Senevirathne Norman Finn Samer Salam Liang Xia Weiguo Hao Filename : draft-ietf-trill-yang-oam-05.txt Pages : 21 Date : 2017-03-31 Abstract: This document presents YANG Data model for TRILL OAM. It extends the Generic YANG model for OAM defined in with TRILL technology specifics. Table of Contents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-yang-oam/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-yang-oam-05 https://datatracker.ietf.org/doc/html/draft-ietf-trill-yang-oam-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-yang-oam-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/