From nobody Mon Oct 2 09:54:44 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 7A5F612421A; Mon, 2 Oct 2017 09:54:34 -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, 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 4z2YKDLZSaJ6; Mon, 2 Oct 2017 09:54:31 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 A2A87133052; Mon, 2 Oct 2017 09:54:30 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id s145so4268618oie.1; Mon, 02 Oct 2017 09:54:30 -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=Q5uHCOUHdo400h0VwczK5/d7/o/DczQ8RrTKnoutRxg=; b=Al+tBDgM2yoGeMGSfiR65zK2XKaCa1OjE3KJP0YwC/AwhbUnS/G3G9gA5fbmkriz2B xz5/+DbYqLYoTDJcuRthw8rUuh7zMS6VYfVWChV2dD4JTsN7nfRosOSOmhhgcoPQprUW tGkeGMoXkcmwAaCupPHf7ih+8wh4ul039eU7tvO5fT7JVamqVUxofTy7Y/1QBgZ6tJlJ Mwon2RMz6BebXDMkzN7vrfIi6DxO/PKL0KwLRD0YYFjfBHU0vpEQ0GkGlvcZ1vcJoBTa ncm9129ucPDAs3se2jVmyD9h0yw/+ond9UvQadpwroDb8qtnae1kqjJ6QIVrUx+VvCrY 3VNQ== 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=Q5uHCOUHdo400h0VwczK5/d7/o/DczQ8RrTKnoutRxg=; b=J4UOiSgh93oQ8tl7BwCuZ4dNR6EDfJNVbxqJQ6L6VL/De7gr4KO+WfErb2wwXpZpZW oSYhjnFx6OOej7HsiAMbiEAzWWF2u87d8dlUQO9xjgWIXw0XI/8MgHwO8Vln50R/QbnQ 8+YJb9kfmjje9JSwLt0826JSgmLpJ+xr8DFgZmC+fVNuFlnx3ibtR9PMmQEK9hhNPlmT gU03XTznjstMB9f1ugiRLDdkDuDHO9Iijh4dHcydI6tyk8yfoTOXAmRI3Zd6H0nNP8lt X62EMsFiAyY6DfmmPAZesx7vKXFHCoFS8YNFHV6NEVOxWap1Xx+ZjtPKgSfSXr/fZbgE tMIA== X-Gm-Message-State: AMCzsaVbu+RflX/Afz8t1h8vQD0LEFHQvn13hbsKe9wuPG0fFDBTlmF8 qeiVx2ckIV4qqW/pgAkKzkzVwfWg4pZ/FD2XzqAM9B+2 X-Google-Smtp-Source: AOwi7QATNEpzNCUgyMpVHKsZUCVRwHtFhKzCAW07Hsp9z88v45expkWxIQB9FbuuIdIrGYlzq4TBvQ3UI2z+hI+oUkc= X-Received: by 10.202.83.129 with SMTP id h123mr6450137oib.106.1506963269665; Mon, 02 Oct 2017 09:54:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.134 with HTTP; Mon, 2 Oct 2017 09:54:14 -0700 (PDT) In-Reply-To: References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 2 Oct 2017 12:54:14 -0400 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-trill-arp-optimization@ietf.org, "trill-chairs@ietf.org" , Susan Hares , "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) 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, 02 Oct 2017 16:54:35 -0000 Hi Eric, My apologies for the delay in response. (For part of the time I was on a cruise...) It looks like we are in agreement on most items. See below. On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla wrote: > > > On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake wrote: >> >> Hi Eric, >> >> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla wrote: >> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-trill-arp-optimization-08: Discuss >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> >> As a general comment, the Security Consideration section could use >> clarification and some expansion. >> >> Although one can imagine various mixed modes, to the first approximation >> there are two ways of doing the optimization of various multi-destination >> messages discussed in this document: >> >> + Using data plane learning by observing ARP/ND and similar messages (in >> addition to the learning of MAC addresses from the data plane which is >> enabled by default in TRILL). As described in this document, such data plane >> learning by TRILL switches can be used to sometimes optimize >> ARP/ND/RARP/unknown-destination messages. But the result isn't particularly >> more or less secure than it is when this data plane learning is done by end >> stations rather than by TRILL switches (or bridges or other kinds of >> switches) in the middle doing some optimization of the relevant >> multi-destination messages. Interface address information learned through >> data plane learning by edge TRILL switches can also be propagated via the >> control plane but this is not significantly different from propagating that >> information via the multi-destination messages that are being optimized to >> unicast or optimized away. >> + Using a complete, trusted directory as might be based on an orchestration >> system in a data center. Since the messages between TRILL switches doing >> ARP/ND/RARP/unknown-destination optimization can be secured and the TRILL >> switches can be configured to ignore data plane learning, this enables TRILL >> switches to provide answers that are "correct" in that they correspond to >> the data in this complete, trusted directory. However, there can still be >> various forged messages/addresses on a local link between end station(s) and >> edge TRILL switches. Such a local link can, with TRILL, be a bridged LAN, so >> such forgeries emitted by an end station may be seen by other end stations >> and cause incorrect learning from the data plane. >> >> The existing Security Considerations section is a bit sketchy and >> concentrates more on the data plane case, as that is the one with the >> greatest security challenges. > > Yes, this seems like a reasonable assessment. Alia, does someone have the > action item to make it less sketchy? We are working on a draft revision to reflect the above thinking to a greater extent and decrease sketchiness. >> > It's not clear to me how the security properties of this mechanism >> > compare to existing TRILL. The text says: >> > >> > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be >> > easily forged. Therefore the learning of MAC/IP addresses by RBridges >> > from ARP/ND should not be considered as reliable. See Section 4.1 for >> > SEND Considerations. >> > >> > "not considered as reliable" seems suboptimal. You need to cover how >> > this mechanism compares to the non-use of this mechanism. >> >> As above, the optimization mechanisms do not make any significant >> difference to the inherent insecurities of data plane learning but when used >> with a complete, trusted directory, it improves considerably over data plane >> learning.. > > That had kind of been my impression, but then I don't understand what "not > considered as reliable" is doing here. I'm supposed to be doing something > with it, so while it may be non-secure, I'm still relying on it, no? Well, at some level some elements of your protocol stack are "relying" on it or "trusting" it or whatever term you want, but it's trivially forged unless you use additional security protocols so I guess we could say something about that. TRILL supports different link technologies but if you are using an Ethernet link, I suppose you could use 802.1AE to improve trust in MAC addresses at layer 2. It wouldn't hurt to mention that but it has very little to do with ARP/ND optimization or TRILL. >> > This document seems very sketchy on what you do when you get duplicate >> > IPs. >> >> Why should what you do when you notice a duplicate IP address be >> significantly different just because some multi-destination messages are >> being optimized? Why shouldn't you just do whatever you do now and why is >> that any of TRILL's business? > > Because you're getting the information via different vector, TRILL needs to > specify what you do, > if only to say "do what you would do otherwise". OK. >> > In the case where the former owner replies, a Duplicate Address has >> > been detected. In this case the querying RBridge SHOULD log the >> > duplicate so that the network administrator can take appropriate >> > action. >> > >> > How does logging solve the problem? >> >> It doesn't but it seems better than not logging. >> >> > What do you reply to ARPs with and/or propagate to other nodes? >> >> If you are asking how you reply to ARPs if the IP address being ARPed for >> has been found to be duplicated, there are the two cases outlined above. If >> you are using a complete, trusted directory, you give the presumed correct >> answer provided by that directory. If you are using data plane learning, you >> use whatever you last learned from the data plane (which could have been a >> forgery over writing good information or good information over writing a >> forgery or a forgery overwriting a different forgery or ...). >> >> > Do you tell the originator of the advertisement you have a duplicate? >> >> As far as I know there is no standardized way to tell a station that you >> think it has an IP address that is duplicated locally and I don't think it >> is the job of TRILL to provide such a mechanism. Certainly this document >> does not propose anything of that sort. > > OK. > > >> > When a newly connected end-station exchanges messages with a DHCP >> > [RFC2131] server an edge RBridge should snoop them (mainly the >> > DHCPAck message) and store IP/MAC mapping information in its ARP/ND >> > cache and should also send the information out through the TRILL >> > control plane using ESADI. >> > >> > What happens if the attacker sets up a fake DHCP server and pretends >> > to assign addresses to himself? It seems like maybe that's the same >> > as fake ARPs but maybe not. >> >> This snooping on DHCP messages only applies to the data plane learning >> case. In the case of a complete, trusted directory, edge RBridges already >> know the right answer, so to speak. With data plane learning, if there are >> forged DHCP messages, things are likely to get all screwed up. Of course, >> you could run DHCP over IPsec but, partly due to the localized nature of >> DHCP, I don't think very many people do that. There is also RFC 3118 which >> can be used to authenticate DHCP messages, but that assumes the distribution >> of keying information. >> >> There isn't much difference between the various multi-destination messages >> (ARP / DHCP) advertising the addresses and point of attachment of >> interfaces. But, overall, I'm not sure why a document that is just >> describing ways to optimize the distribution of various multi-destination >> messages needs to analyze the security of the protocols implemented by those >> multi-destination when, as in the data plane learning case, it is not >> significantly changing that security. > > Well, in this case, you have a new threat vector: DHCP. Even if it is the > same kind of threats, it's still a new threat vector. > More generally documents need to contain complete security considerations > sections. If the security considerations > are the same as with some other document, then they need to say that. OK. >> > In general, the security considerations need a complete threat >> > analysis per 3552. >> >> I don't think there is that much new in this document. While the Security >> Considerations section needs clarification and some expansion, I don't think >> it is, for example, the job of this document to do a threat analysis of the >> ARP protocol as long as it can make a reasonable case that the security of >> ARP is not significantly changed by the optimizations specified. > > Sure, but it also doesn't make that case. I'll see what we can do. >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> >> For completeness, I've cut and pasted below the COMMENT responses I sent >> to you a while ago. >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> > S 2. >> > >> > plane on the edge RBridges, it should be possible to completely >> > suppress flooding of ARP/ND messages in a TRILL Campus, When all end- >> > station MAC addresses are similarly known, it should be possible to >> > suppress unknown unicast flooding by dropping any unknown unicast >> > received at an edge RBridge. >> > >> > Are these "should be possibles" normative? Descriptive? >> >> Section 2 of this document is a general discussion of the optimization >> problem which, while it does mention a couple of possible facets of >> potential solutions, is not intended to be normative. >> >> >> > S 4. >> > This is a sequence of steps, so it would be nice to preface them with >> > a list of the steps. It's also odd to have SEND considerations right >> > in the middle here. >> >> Sorry, I don't understand exactly what you are pointing at as a >> sequence of steps. All of Section 4? Just the text between the Section >> 4 heading and the Section 4.1 heading? Something else? > > Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, etc. > It would be nice if they were listed ahead of this as "this is what you do, > now read the sections" OK. We can add some clarifying material to Section 4 before the 4.1 heading. >> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP >> > >> > Please explain what a non-zero IP is and why it's relevant. >> > This graf also needs an introductory sentence or something before >> > the bullets. >> >> Here is a copy of the response that was sent to a similar comment in >> Dale Worley's GENART review: >> >> This section is talking about getting and handling the IP/MAC >> mapping information for a local end station by an edge RBridge. An >> ARP/ND from such a local end station might show a zero source IP >> address if the end station does not have one or is probing for >> duplicates. >> >> Perhaps the title for the Section should be something like >> >> 4.3 Extracting Local End Station IP/MAC Mapping Information >> >> and a new first paragraph could be added something like >> >> Edge RBridges extract and use information about the correspondence >> between local end station IP and MAC addresses from the ARP/ND >> messages those end stations send as described below. An apparent zero >> source IP address means that the end station is probing for duplicate >> IP addresses and messages with such a zero source IP address are not >> used for the extraction of IP/MAC address mapping information > > LGTM > > >> > S 4.4. >> > It is not essential that all RBridges use the same strategy for which >> > option to select for a particular ARP/ND query. It is up to the >> > implementation. >> > >> > This seems inconsistent with the MUST in arm (b) below, because I >> > can just take some other arm. It's also kind of surprising to be this >> > non-prescriptive. >> >> The wording needs to be clarified. Which lettered item listed below >> applies is determined by the circumstances; however, which of the >> numbered strategies associated with these items is followed is an >> implementation choice in handeling any particular ARP/ND. > > OK. > > >> > S 8. >> > some other location (MAC/VM Mobility) and gets connected to egde- >> > >> > Nit: edge is mispelled. >> >> OK. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Mon Oct 2 11:13: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 A6A2A1346CE for ; Mon, 2 Oct 2017 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Z-7W3AubaaVe for ; Mon, 2 Oct 2017 11:12:55 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 A002A1346D3 for ; Mon, 2 Oct 2017 11:12:50 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id x54so8421477qth.12 for ; Mon, 02 Oct 2017 11:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n6tpynfcB19hvnhPhQNmKOaUAFMRlwtz4d3ikIoXJ30=; b=hnHYPasYzHkBMnyK9pgNHqsqGtZ3D0yOX5bVgF792a/E0JgVSq29C4yZaNtFgeWz8S C6U6omsfgiW8Z9dUZlzjmJklegfnxptNB/sZNGPxwwVyuztej+CF75JGhLiYmHpKUDBj Ir+HGb30aiap8vsWuIjZBKyROnzAb0+Xi8/2weqJo3ig7fsAfLjpKdFlOjIEg9QRRcZM 9DwlqUXKlWx5cfDKNjxfKwUd4cwFJ/IYSa/V2DcNsmnyiQzsN6KCeDH/o2Z3GG1XEYuh ivUiLl4eF+tv8BaO9NTtdYFCLz6vUo6aJQd4AehQj2TZMkImvA3jmatvgYhSKBRu7cn2 1pkg== 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=n6tpynfcB19hvnhPhQNmKOaUAFMRlwtz4d3ikIoXJ30=; b=j3rEnSjfySz9HId3rZLIQpRccQ+ml0Nl0RWMcwq+JtW/+MnjOzlUPKSl/0ibhI9PQt J87Me0oDJH64HT5xZVT9cetI14cmnMFNLkayLrQdpoMXGOghSg2t3f3dPUvD2ZrTG1gr 8kC5VXns4fX4DHo9LbgVcio9177Q2V1cMhihJLZ8hUCpOwHp1+htGndH90oLsd31XcuV tNW2UyMwgnw5jgthybNy2Y1T1rw0dcYgoicrPI6T2U5HehCmmuth8/pRwSX3SbAifdnB O5P86HogpwYuBAJjvRVb8ECKpceAzfjkoLcplqmQe0hLdbszw8FqxXBr1un3Vnx2G1qf 6eBg== X-Gm-Message-State: AHPjjUiI1kGFkE1BOwuIVYZBbTgYcc94rV2sfwPMbEm72lFiU9lX0Zbc COghw8aK/eZQXpqLHvvIWY5hBUFGHTUZ7egcVkYUtk0F X-Google-Smtp-Source: AOwi7QBuhNgYoQSa2RGI4Z/ZcEzYRKH9OWqyIgR/vqzUYOsynCzwDt4rvK9OC1DntuAAwHRFTFdQZNPLo6o24HD6tnQ= X-Received: by 10.129.178.69 with SMTP id q66mr13178456ywh.290.1506967969621; Mon, 02 Oct 2017 11:12:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 2 Oct 2017 11:12:09 -0700 (PDT) In-Reply-To: References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 2 Oct 2017 18:12:09 +0000 Message-ID: To: Donald Eastlake Cc: The IESG , draft-ietf-trill-arp-optimization@ietf.org, "trill-chairs@ietf.org" , Susan Hares , "trill@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c14626884813c055a945239" Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) 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, 02 Oct 2017 18:12:58 -0000 --94eb2c14626884813c055a945239 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake wrote: > Hi Eric, > > My apologies for the delay in response. (For part of the time I was on > a cruise...) > > It looks like we are in agreement on most items. > > See below. > > On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla wrote: > > > > > > On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake > wrote: > >> > >> Hi Eric, > >> > >> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla wrote: > >> > Eric Rescorla has entered the following ballot position for > >> > draft-ietf-trill-arp-optimization-08: Discuss > >> > > >> > ------------------------------------------------------------ > ---------- > >> > DISCUSS: > >> > ------------------------------------------------------------ > ---------- > >> > >> As a general comment, the Security Consideration section could use > >> clarification and some expansion. > >> > >> Although one can imagine various mixed modes, to the first approximation > >> there are two ways of doing the optimization of various > multi-destination > >> messages discussed in this document: > >> > >> + Using data plane learning by observing ARP/ND and similar messages (in > >> addition to the learning of MAC addresses from the data plane which is > >> enabled by default in TRILL). As described in this document, such data > plane > >> learning by TRILL switches can be used to sometimes optimize > >> ARP/ND/RARP/unknown-destination messages. But the result isn't > particularly > >> more or less secure than it is when this data plane learning is done by > end > >> stations rather than by TRILL switches (or bridges or other kinds of > >> switches) in the middle doing some optimization of the relevant > >> multi-destination messages. Interface address information learned > through > >> data plane learning by edge TRILL switches can also be propagated via > the > >> control plane but this is not significantly different from propagating > that > >> information via the multi-destination messages that are being optimized > to > >> unicast or optimized away. > >> + Using a complete, trusted directory as might be based on an > orchestration > >> system in a data center. Since the messages between TRILL switches doing > >> ARP/ND/RARP/unknown-destination optimization can be secured and the > TRILL > >> switches can be configured to ignore data plane learning, this enables > TRILL > >> switches to provide answers that are "correct" in that they correspond > to > >> the data in this complete, trusted directory. However, there can still > be > >> various forged messages/addresses on a local link between end > station(s) and > >> edge TRILL switches. Such a local link can, with TRILL, be a bridged > LAN, so > >> such forgeries emitted by an end station may be seen by other end > stations > >> and cause incorrect learning from the data plane. > >> > >> The existing Security Considerations section is a bit sketchy and > >> concentrates more on the data plane case, as that is the one with the > >> greatest security challenges. > > > > Yes, this seems like a reasonable assessment. Alia, does someone have the > > action item to make it less sketchy? > > We are working on a draft revision to reflect the above thinking to a > greater extent and decrease sketchiness. > > >> > It's not clear to me how the security properties of this mechanism > >> > compare to existing TRILL. The text says: > >> > > >> > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can > be > >> > easily forged. Therefore the learning of MAC/IP addresses by > RBridges > >> > from ARP/ND should not be considered as reliable. See Section 4.1 > for > >> > SEND Considerations. > >> > > >> > "not considered as reliable" seems suboptimal. You need to cover how > >> > this mechanism compares to the non-use of this mechanism. > >> > >> As above, the optimization mechanisms do not make any significant > >> difference to the inherent insecurities of data plane learning but when > used > >> with a complete, trusted directory, it improves considerably over data > plane > >> learning.. > > > > That had kind of been my impression, but then I don't understand what > "not > > considered as reliable" is doing here. I'm supposed to be doing something > > with it, so while it may be non-secure, I'm still relying on it, no? > > Well, at some level some elements of your protocol stack are "relying" > on it or "trusting" it or whatever term you want, but it's trivially > forged unless you use additional security protocols so I guess we > could say something about that. TRILL supports different link > technologies but if you are using an Ethernet link, I suppose you > could use 802.1AE to improve trust in MAC addresses at layer 2. It > wouldn't hurt to mention that but it has very little to do with ARP/ND > optimization or TRILL. > I think if you just sort of say "you are using it, but it's not trustworthy and here's why" you have it covered. -Ekr > >> > This document seems very sketchy on what you do when you get duplicate > >> > IPs. > >> > >> Why should what you do when you notice a duplicate IP address be > >> significantly different just because some multi-destination messages are > >> being optimized? Why shouldn't you just do whatever you do now and why > is > >> that any of TRILL's business? > > > > Because you're getting the information via different vector, TRILL needs > to > > specify what you do, > > if only to say "do what you would do otherwise". > > OK. > > >> > In the case where the former owner replies, a Duplicate Address has > >> > been detected. In this case the querying RBridge SHOULD log the > >> > duplicate so that the network administrator can take appropriate > >> > action. > >> > > >> > How does logging solve the problem? > >> > >> It doesn't but it seems better than not logging. > >> > >> > What do you reply to ARPs with and/or propagate to other nodes? > >> > >> If you are asking how you reply to ARPs if the IP address being ARPed > for > >> has been found to be duplicated, there are the two cases outlined > above. If > >> you are using a complete, trusted directory, you give the presumed > correct > >> answer provided by that directory. If you are using data plane > learning, you > >> use whatever you last learned from the data plane (which could have > been a > >> forgery over writing good information or good information over writing a > >> forgery or a forgery overwriting a different forgery or ...). > >> > >> > Do you tell the originator of the advertisement you have a duplicate? > >> > >> As far as I know there is no standardized way to tell a station that you > >> think it has an IP address that is duplicated locally and I don't think > it > >> is the job of TRILL to provide such a mechanism. Certainly this document > >> does not propose anything of that sort. > > > > OK. > > > > > >> > When a newly connected end-station exchanges messages with a DHCP > >> > [RFC2131] server an edge RBridge should snoop them (mainly the > >> > DHCPAck message) and store IP/MAC mapping information in its ARP/ND > >> > cache and should also send the information out through the TRILL > >> > control plane using ESADI. > >> > > >> > What happens if the attacker sets up a fake DHCP server and pretends > >> > to assign addresses to himself? It seems like maybe that's the same > >> > as fake ARPs but maybe not. > >> > >> This snooping on DHCP messages only applies to the data plane learning > >> case. In the case of a complete, trusted directory, edge RBridges > already > >> know the right answer, so to speak. With data plane learning, if there > are > >> forged DHCP messages, things are likely to get all screwed up. Of > course, > >> you could run DHCP over IPsec but, partly due to the localized nature of > >> DHCP, I don't think very many people do that. There is also RFC 3118 > which > >> can be used to authenticate DHCP messages, but that assumes the > distribution > >> of keying information. > >> > >> There isn't much difference between the various multi-destination > messages > >> (ARP / DHCP) advertising the addresses and point of attachment of > >> interfaces. But, overall, I'm not sure why a document that is just > >> describing ways to optimize the distribution of various > multi-destination > >> messages needs to analyze the security of the protocols implemented by > those > >> multi-destination when, as in the data plane learning case, it is not > >> significantly changing that security. > > > > Well, in this case, you have a new threat vector: DHCP. Even if it is the > > same kind of threats, it's still a new threat vector. > > More generally documents need to contain complete security considerations > > sections. If the security considerations > > are the same as with some other document, then they need to say that. > > OK. > > >> > In general, the security considerations need a complete threat > >> > analysis per 3552. > >> > >> I don't think there is that much new in this document. While the > Security > >> Considerations section needs clarification and some expansion, I don't > think > >> it is, for example, the job of this document to do a threat analysis of > the > >> ARP protocol as long as it can make a reasonable case that the security > of > >> ARP is not significantly changed by the optimizations specified. > > > > Sure, but it also doesn't make that case. > > I'll see what we can do. > > >> > ------------------------------------------------------------ > ---------- > >> > COMMENT: > >> > ------------------------------------------------------------ > ---------- > >> > >> For completeness, I've cut and pasted below the COMMENT responses I sent > >> to you a while ago. > >> > >> Thanks, > >> Donald > >> =============================== > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >> 155 Beaver Street, Milford, MA 01757 USA > >> d3e3e3@gmail.com > >> > >> > S 2. > >> > > >> > plane on the edge RBridges, it should be possible to completely > >> > suppress flooding of ARP/ND messages in a TRILL Campus, When all > end- > >> > station MAC addresses are similarly known, it should be possible to > >> > suppress unknown unicast flooding by dropping any unknown unicast > >> > received at an edge RBridge. > >> > > >> > Are these "should be possibles" normative? Descriptive? > >> > >> Section 2 of this document is a general discussion of the optimization > >> problem which, while it does mention a couple of possible facets of > >> potential solutions, is not intended to be normative. > >> > >> > >> > S 4. > >> > This is a sequence of steps, so it would be nice to preface them with > >> > a list of the steps. It's also odd to have SEND considerations right > >> > in the middle here. > >> > >> Sorry, I don't understand exactly what you are pointing at as a > >> sequence of steps. All of Section 4? Just the text between the Section > >> 4 heading and the Section 4.1 heading? Something else? > > > > Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, > etc. > > It would be nice if they were listed ahead of this as "this is what you > do, > > now read the sections" > > OK. We can add some clarifying material to Section 4 before the 4.1 > heading. > > >> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP > >> > > >> > Please explain what a non-zero IP is and why it's relevant. > >> > This graf also needs an introductory sentence or something before > >> > the bullets. > >> > >> Here is a copy of the response that was sent to a similar comment in > >> Dale Worley's GENART review: > >> > >> This section is talking about getting and handling the IP/MAC > >> mapping information for a local end station by an edge RBridge. An > >> ARP/ND from such a local end station might show a zero source IP > >> address if the end station does not have one or is probing for > >> duplicates. > >> > >> Perhaps the title for the Section should be something like > >> > >> 4.3 Extracting Local End Station IP/MAC Mapping Information > >> > >> and a new first paragraph could be added something like > >> > >> Edge RBridges extract and use information about the correspondence > >> between local end station IP and MAC addresses from the ARP/ND > >> messages those end stations send as described below. An apparent zero > >> source IP address means that the end station is probing for duplicate > >> IP addresses and messages with such a zero source IP address are not > >> used for the extraction of IP/MAC address mapping information > > > > LGTM > > > > > >> > S 4.4. > >> > It is not essential that all RBridges use the same strategy for > which > >> > option to select for a particular ARP/ND query. It is up to the > >> > implementation. > >> > > >> > This seems inconsistent with the MUST in arm (b) below, because I > >> > can just take some other arm. It's also kind of surprising to be this > >> > non-prescriptive. > >> > >> The wording needs to be clarified. Which lettered item listed below > >> applies is determined by the circumstances; however, which of the > >> numbered strategies associated with these items is followed is an > >> implementation choice in handeling any particular ARP/ND. > > > > OK. > > > > > >> > S 8. > >> > some other location (MAC/VM Mobility) and gets connected to egde- > >> > > >> > Nit: edge is mispelled. > >> > >> OK. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > --94eb2c14626884813c055a945239 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake <<= a href=3D"mailto:d3e3e3@gmail.com" target=3D"_blank">d3e3e3@gmail.com&g= t; wrote:
Hi Eric,

My apologies for the delay in response. (For part of the time I was on
a cruise...)

It looks like we are in agreement on most items.

See below.

On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>>
>> Hi Eric,
>>
>> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-trill-arp-optimization-08: Discuss
>> >
>> > --------------------------------------------------------= --------------
>> > DISCUSS:
>> > --------------------------------------------------------= --------------
>>
>> As a general comment, the Security Consideration section could use=
>> clarification and some expansion.
>>
>> Although one can imagine various mixed modes, to the first approxi= mation
>> there are two ways of doing the optimization of various multi-dest= ination
>> messages discussed in this document:
>>
>> + Using data plane learning by observing ARP/ND and similar= messages (in
>> addition to the learning of MAC addresses from th= e data plane which is
>> enabled by default in TRILL). As described in this document, such = data plane
>> learning by TRILL switches can be used to sometimes optimize
>> ARP/ND/RARP/unknown-destination messages. But the result isn&= #39;t particularly
>> more or less secure than it is when this data plane learning is do= ne by end
>> stations rather than by TRILL switches (or bridges or other kinds = of
>> switches) in the middle doing some optimization of the relevant >> multi-destination messages. Interface address information learned = through
>> data plane learning by edge TRILL switches can also be propagated = via the
>> control plane but this is not significantly different from propaga= ting that
>> information via the multi-destination messages that are being opti= mized to
>> unicast or optimized away.
>> + Using a complete, trusted directory as might be based on = an orchestration
>> system in a data center. Since the messages betwe= en TRILL switches doing
>> ARP/ND/RARP/unknown-destination optimization can be secured a= nd the TRILL
>> switches can be configured to ignore data plane learning, this ena= bles TRILL
>> switches to provide answers that are "correct" in that t= hey correspond to
>> the data in this complete, trusted directory. However, there can s= till be
>> various forged messages/addresses on a local link between end stat= ion(s) and
>> edge TRILL switches. Such a local link can, with TRILL, be a bridg= ed LAN, so
>> such forgeries emitted by an end station may be seen by other end = stations
>> and cause incorrect learning from the data plane.
>>
>> The existing Security Considerations section is a bit sketchy and<= br> >> concentrates more on the data plane case, as that is the one with = the
>> greatest security challenges.
>
> Yes, this seems like a reasonable assessment. Alia, does someone have = the
> action item to make it less sketchy?

We are working on a draft revision to reflect the above thinking to = a
greater extent and decrease sketchiness.

>> > It's not clear to me how the security properties of this = mechanism
>> > compare to existing TRILL. The text says:
>> >
>> >=C2=A0 =C2=A0 Unless Secure ND (SEND [RFC3971]) is used, ARP a= nd ND messages can be
>> >=C2=A0 =C2=A0 easily forged. Therefore the learning of MAC/IP = addresses by RBridges
>> >=C2=A0 =C2=A0 from ARP/ND should not be considered as reliable= . See Section 4.1 for
>> >=C2=A0 =C2=A0 SEND Considerations.
>> >
>> > "not considered as reliable" seems suboptimal. You = need to cover how
>> > this mechanism compares to the non-use of this mechanism.
>>
>> As above, the optimization mechanisms do not make any significant<= br> >> difference to the inherent insecurities of data plane learning but= when used
>> with a complete, trusted directory, it improves considerably over = data plane
>> learning..
>
> That had kind of been my impression, but then I don't understand w= hat "not
> considered as reliable" is doing here. I'm supposed to be doi= ng something
> with it, so while it may be non-secure, I'm still relying on it, n= o?

Well, at some level some elements of your protocol stack are "r= elying"
on it or "trusting" it or whatever term you want, but it's tr= ivially
forged unless you use additional security protocols so I guess we
could say something about that. TRILL supports different link
technologies but if you are using an Ethernet link, I suppose you
could use 802.1AE to improve trust in MAC addresses at layer 2. It
wouldn't hurt to mention that but it has very little to do with ARP/ND<= br> optimization or TRILL.

I think if you j= ust sort of say "you are using it, but it's not trustworthy and he= re's why" you have it covered.

-Ekr
=


>> > This document seems very sketchy on what you do when you get = duplicate
>> > IPs.
>>
>> Why should what you do when you notice a duplicate IP address be >> significantly different just because some multi-destination messag= es are
>> being optimized? Why shouldn't you just do whatever you do now= and why is
>> that any of TRILL's business?
>
> Because you're getting the information via different vector, TRILL= needs to
> specify what you do,
> if only to say "do what you would do otherwise".

OK.

>> >=C2=A0 =C2=A0 In the case where the former owner replies, a Du= plicate Address has
>> >=C2=A0 =C2=A0 been detected. In this case the querying RBridge= SHOULD log the
>> >=C2=A0 =C2=A0 duplicate so that the network administrator can = take appropriate
>> >=C2=A0 =C2=A0 action.
>> >
>> > How does logging solve the problem?
>>
>> It doesn't but it seems better than not logging.
>>
>> > What do you reply to ARPs with and/or propagate to other node= s?
>>
>> If you are asking how you reply to ARPs if the IP address being AR= Ped for
>> has been found to be duplicated, there are the two cases outlined = above. If
>> you are using a complete, trusted directory, you give the presumed= correct
>> answer provided by that directory. If you are using data plane lea= rning, you
>> use whatever you last learned from the data plane (which could hav= e been a
>> forgery over writing good information or good information over wri= ting a
>> forgery or a forgery overwriting a different forgery or ...).
>>
>> > Do you tell the originator of the advertisement you have a du= plicate?
>>
>> As far as I know there is no standardized way to tell a station th= at you
>> think it has an IP address that is duplicated locally and I don= 9;t think it
>> is the job of TRILL to provide such a mechanism. Certainly this do= cument
>> does not propose anything of that sort.
>
> OK.
>
>
>> >=C2=A0 =C2=A0 When a newly connected end-station exchanges mes= sages with a DHCP
>> >=C2=A0 =C2=A0 [RFC2131] server an edge RBridge should snoop th= em (mainly the
>> >=C2=A0 =C2=A0 DHCPAck message) and store IP/MAC mapping inform= ation in its ARP/ND
>> >=C2=A0 =C2=A0 cache and should also send the information out t= hrough the TRILL
>> >=C2=A0 =C2=A0 control plane using ESADI.
>> >
>> > What happens if the attacker sets up a fake DHCP server and p= retends
>> > to assign addresses to himself? It seems like maybe that'= s the same
>> > as fake ARPs but maybe not.
>>
>> This snooping on DHCP messages only applies to the data plane lear= ning
>> case. In the case of a complete, trusted directory, edge RBridges = already
>> know the right answer, so to speak. With data plane learning, if t= here are
>> forged DHCP messages, things are likely to get all screwed up. Of = course,
>> you could run DHCP over IPsec but, partly due to the localized nat= ure of
>> DHCP, I don't think very many people do that. There is also RF= C 3118 which
>> can be used to authenticate DHCP messages, but that assumes the di= stribution
>> of keying information.
>>
>> There isn't much difference between the various multi-destinat= ion messages
>> (ARP / DHCP) advertising the addresses and point of attachment of<= br> >> interfaces. But, overall, I'm not sure why a document that is = just
>> describing ways to optimize the distribution of various multi-dest= ination
>> messages needs to analyze the security of the protocols implemente= d by those
>> multi-destination when, as in the data plane learning case, it is = not
>> significantly changing that security.
>
> Well, in this case, you have a new threat vector: DHCP. Even if it is = the
> same kind of threats, it's still a new threat vector.
> More generally documents need to contain complete security considerati= ons
> sections. If the security considerations
> are the same as with some other document, then they need to say that.<= br>
OK.

>> > In general, the security considerations need a complete threa= t
>> > analysis per 3552.
>>
>> I don't think there is that much new in this document. While t= he Security
>> Considerations section needs clarification and some expansion, I d= on't think
>> it is, for example, the job of this document to do a threat analys= is of the
>> ARP protocol as long as it can make a reasonable case that the sec= urity of
>> ARP is not significantly changed by the optimizations specified. >
> Sure, but it also doesn't make that case.

I'll see what we can do.

>> > --------------------------------------------------------= --------------
>> > COMMENT:
>> > --------------------------------------------------------= --------------
>>
>> For completeness, I've cut and pasted below the COMMENT respon= ses I sent
>> to you a while ago.
>>
>> 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
>>
>> > S 2.
>> >
>> >=C2=A0 =C2=A0 plane on the edge RBridges, it should be possibl= e to completely
>> >=C2=A0 =C2=A0 suppress flooding of ARP/ND messages in a TRILL = Campus, When all end-
>> >=C2=A0 =C2=A0 station MAC addresses are similarly known, it sh= ould be possible to
>> >=C2=A0 =C2=A0 suppress unknown unicast flooding by dropping an= y unknown unicast
>> >=C2=A0 =C2=A0 received at an edge RBridge.
>> >
>> > Are these "should be possibles" normative? Descript= ive?
>>
>> Section 2 of this document is a general discussion of the optimiza= tion
>> problem which, while it does mention a couple of possible facets o= f
>> potential solutions, is not intended to be normative.
>>
>>
>> > S 4.
>> > This is a sequence of steps, so it would be nice to preface t= hem with
>> > a list of the steps. It's also odd to have SEND considera= tions right
>> > in the middle here.
>>
>> Sorry, I don't understand exactly what you are pointing at as = a
>> sequence of steps. All of Section 4? Just the text between the Sec= tion
>> 4 heading and the Section 4.1 heading? Something else?
>
> Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, = etc.
> It would be nice if they were listed ahead of this as "this is wh= at you do,
> now read the sections"

OK. We can add some clarifying material to Section 4 before the= 4.1 heading.

>> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero = IP
>> >
>> > Please explain what a non-zero IP is and why it's relevan= t.
>> > This graf also needs an introductory sentence or something be= fore
>> > the bullets.
>>
>> Here is a copy of the response that was sent to a similar comment = in
>> Dale Worley's GENART review:
>>
>> This section is talking about getting and handling the IP/MAC
>> mapping information for a local end station by an edge RBridge. An=
>> ARP/ND from such a local end station might show a zero source IP >> address if the end station does not have one or is probing for
>> duplicates.
>>
>> Perhaps the title for the Section should be something like
>>
>>=C2=A0 =C2=A0 4.3 Extracting Local End Station IP/MAC Mapping Infor= mation
>>
>> and a new first paragraph could be added something like
>>
>>=C2=A0 =C2=A0 Edge RBridges extract and use information about the c= orrespondence
>> between local end station IP and MAC addresses from the ARP/ND
>> messages those end stations send as described below. An apparent z= ero
>> source IP address means that the end station is probing for duplic= ate
>> IP addresses and messages with such a zero source IP address are n= ot
>> used for the extraction of IP/MAC address mapping information
>
> LGTM
>
>
>> > S 4.4.
>> >=C2=A0 =C2=A0 It is not essential that all RBridges use the sa= me strategy for which
>> >=C2=A0 =C2=A0 option to select for a particular ARP/ND query. = It is up to the
>> >=C2=A0 =C2=A0 implementation.
>> >
>> > This seems inconsistent with the MUST in arm (b) below, becau= se I
>> > can just take some other arm. It's also kind of surprisin= g to be this
>> > non-prescriptive.
>>
>> The wording needs to be clarified. Which lettered item listed belo= w
>> applies is determined by the circumstances; however, which of the<= br> >> numbered strategies associated with these items is followed is an<= br> >> implementation choice in handeling any particular ARP/ND.
>
> OK.
>
>
>> > S 8.
>> >=C2=A0 =C2=A0 some other location (MAC/VM Mobility) and gets c= onnected to egde-
>> >
>> > Nit: edge is mispelled.
>>
>> OK.

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

--94eb2c14626884813c055a945239-- From nobody Mon Oct 2 12:48:07 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 9CD7D133321; Mon, 2 Oct 2017 12:48:05 -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, 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 y6EWEF2DrVlV; Mon, 2 Oct 2017 12:48:04 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003: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 14107134807; Mon, 2 Oct 2017 12:48:04 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id c77so8808107oig.0; Mon, 02 Oct 2017 12:48: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=IEkg1zjNcDA/sNiXsYwFTft1YL0ED39ZY6UmM6ebypI=; b=OoMOUXqua2Ew+9BwIPFBbDNsGO1ee/aLjntfMx0hp6WcQE62qUdtbgmYEiJI64Q6T+ iJQs9ulqYDk4VtLaR2ZdH8UwvqDbIFqJJpIhLZoM+CnixKXOEJjevtA1IKm0rGGg8SLU 2MZVssHcDwcw7Xw4Fmk//mOyRs1cH0NVgH+0dbOXbprb+xspGH6IWzpaH/kZU7S4slzI 5NsYTCTy+uI1ko8j1xdmaFXGo1IXUdo6KbBGEh+YW+MiVAcmPAaA9Wy2XiARevqx5NfH wOlrc8H3/wLn9hBSZgkfXSQyZSFgnbR8ML+97ljpqzWuDWaRiUE3H3eu/KU3mjTnvRXV aSvA== 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=IEkg1zjNcDA/sNiXsYwFTft1YL0ED39ZY6UmM6ebypI=; b=dCHb/deewo+VWx1vWr4Evdji+TEYy/v9n/iPVHdvx8f4jA0pA/KXY1Yb8KdhzhXuDg tFMg6rXZHuBw3G6e4vmNAM8tqRfK+MsvP0TbdvkUsGIFA5xhhzru29Wo7H+JHZjdQ9SD SF9b8OhRyOOvnMCmduXDy5geYjRvHXfqzKcq2sEIqCjWy+NM4rYMP9c61oALmkPjzq+z xiuxm583N/NQE0cGl2P0BhsKj8uydRx847qcgDIvFEnJRicr86Bc7bzWjRqCidkCHUvx V70+iMBhGt6KE6HSQ9Z1Ld+Vov6VhR6Hup5EzqFhyk9P9IB86LSvL40+udv9PeeRmATi pR2Q== X-Gm-Message-State: AMCzsaXR/vm3YlpdgCsMMvGp0NccVRWLmRZl85jBJZWNaRzUNVKdHbyg njzidNh71MwmN3Vm+27YLeBbryu++QjqSM5vSYs= X-Google-Smtp-Source: AOwi7QCM35iZJ692PUeNpJ9yj4pzb+a6yBTWc+QSQEa7OBcqdj3R5VbV7ZSBNcgfK/l2KaN54AVjB6n9EyWRXfIVeDc= X-Received: by 10.157.81.138 with SMTP id y10mr8563364otg.395.1506973683298; Mon, 02 Oct 2017 12:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.134 with HTTP; Mon, 2 Oct 2017 12:47:47 -0700 (PDT) In-Reply-To: References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 2 Oct 2017 15:47:47 -0400 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-trill-arp-optimization@ietf.org, "trill-chairs@ietf.org" , Susan Hares , "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) 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, 02 Oct 2017 19:48:05 -0000 Hi Eric, On Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorla wrote: > > On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake wrote: >> >> Hi Eric, >> >> ... >> >> >> > It's not clear to me how the security properties of this mechanism >> >> > compare to existing TRILL. The text says: >> >> > >> >> > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can >> >> > be >> >> > easily forged. Therefore the learning of MAC/IP addresses by >> >> > RBridges >> >> > from ARP/ND should not be considered as reliable. See Section 4.1 >> >> > for >> >> > SEND Considerations. >> >> > >> >> > "not considered as reliable" seems suboptimal. You need to cover how >> >> > this mechanism compares to the non-use of this mechanism. >> >> >> >> As above, the optimization mechanisms do not make any significant >> >> difference to the inherent insecurities of data plane learning but when >> >> used >> >> with a complete, trusted directory, it improves considerably over data >> >> plane >> >> learning.. >> > >> > That had kind of been my impression, but then I don't understand what >> > "not >> > considered as reliable" is doing here. I'm supposed to be doing >> > something >> > with it, so while it may be non-secure, I'm still relying on it, no? >> >> Well, at some level some elements of your protocol stack are "relying" >> on it or "trusting" it or whatever term you want, but it's trivially >> forged unless you use additional security protocols so I guess we >> could say something about that. TRILL supports different link >> technologies but if you are using an Ethernet link, I suppose you >> could use 802.1AE to improve trust in MAC addresses at layer 2. It >> wouldn't hurt to mention that but it has very little to do with ARP/ND >> optimization or TRILL. > > > I think if you just sort of say "you are using it, but it's not trustworthy > and here's why" you have it covered. OK. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -Ekr From nobody Mon Oct 2 16:11: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 82CD0134908 for ; Mon, 2 Oct 2017 16:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 qe0vIeRIvq_S for ; Mon, 2 Oct 2017 16:11:14 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003: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 7F48D1342CC for ; Mon, 2 Oct 2017 16:11:14 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id c77so9570421oig.0 for ; Mon, 02 Oct 2017 16:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xHmmfGUOW7tCf+64UFodCMT8Y4grrOGpjBbtg3+xKKc=; b=m3zmFycD2A1UMti3yxGEQdZNHZnxSla0Qe+duvVO+IJVytUZr/uWwaIjzsriz6YjHD EdcfXuX2XHmyKnDkbrWLqTW6yGnyLGXC7s7rmrNGzgGQZSZ/4WLhC5HuIJelD4QOo1ED DFoYfftvyd003lVQFNIoMXLD6CJAIbYbtl21I86R34X8/j7WPQSJuGo+ZJiR88wBLwkl 5XSATbRD6+SpWerZlhbCwJpkKsrs8/676QGHU+gwQEOLrmDv6VvJTS1l8N5EfSmF9g54 1mrPMyS+kKuFGd82rH7CpdU6Mh7DrjBNT9UyDKr0btZU+jjphQP4LSgTt5agObS8zTuh E26A== 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; bh=xHmmfGUOW7tCf+64UFodCMT8Y4grrOGpjBbtg3+xKKc=; b=aAG6KS72j8NSGVBcn7/U9MY2bNGnGPcOztXoMAqW0wtjH/ie7609L+TnOZYW+bD/vr DCYc+HwGAaM1hAOHjRmtZp7EpkcJsQ49dcqOpoLJG6EvEvNUlR1c5Ct3ag+nA9WlNFwU g3fxAD7GW0gydLe6u/aLuvzmXxVd5F7RLHqRcpafxYLtqN7AMlzG3/DrnKELov+F4++p pWmQbPk3tGiX3yNej/ynPzzOcKkebg13l6JWb2qF3u3ASGeCc64sAQNT+Zu1x4wcNHqF UJt0t5YUk6PcSOLnt3ZFW0CvGmgTT1O4Y8auToD8IdU3MYSsMx5fLi2rAy7OlJ4aq/Z0 gSgA== X-Gm-Message-State: AMCzsaUIJawYDwS02firXgJnmYOGtOy2Jwy25lk08MlrfBJw/q6MRAx0 DhTEUKlTiHD8/t6K8tqcRDDJL1vRNw9YDGQcEy84Ng== X-Google-Smtp-Source: AOwi7QAjDAQ75ur65owrLfOtWmKuNNhjC66LdIaHQDf4YurRrCBmWfo7izox013k4uwQ4Bbt8zE9FdWuvqEVBS7DeJU= X-Received: by 10.157.35.11 with SMTP id j11mr2208663otb.167.1506985873594; Mon, 02 Oct 2017 16:11:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.134 with HTTP; Mon, 2 Oct 2017 16:10:58 -0700 (PDT) From: Donald Eastlake Date: Mon, 2 Oct 2017 19:10:58 -0400 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) 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, 02 Oct 2017 23:11:15 -0000 This begins a 2 week WG LC on draft-ietf-trill-address-flush-03.txt. Please indicate if you think the draft is ready for publication and is useful for TRILL deployments. Thanks, Donald (WG Secretary for the Chairs: Sue Hares & Jon Hudson) =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Fri Oct 6 19:53: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 01A5313219C; Fri, 6 Oct 2017 19:53:40 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150734481996.11108.13465747517793143967@ietfa.amsl.com> Date: Fri, 06 Oct 2017 19:53:40 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-parent-selection-00.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: Sat, 07 Oct 2017 02:53: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 WG of the IETF. Title : TRILL: Parent node Shifts in Tree Construction, Mitigation. Author : R. Parameswaran Filename : draft-ietf-trill-parent-selection-00.txt Pages : 11 Date : 2017-10-06 Abstract: This draft documents a known problem in the TRILL tree construction mechanism and offers an approach requiring no change to the TRILL protocol in order to solve the problem. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-parent-selection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-parent-selection-00 https://datatracker.ietf.org/doc/html/draft-ietf-trill-parent-selection-00 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 Oct 8 13:03: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 E609413493D for ; Sun, 8 Oct 2017 13:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, 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 FfAtAGPYgPiH for ; Sun, 8 Oct 2017 13:03:44 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 28B98134939 for ; Sun, 8 Oct 2017 13:03:44 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id j126so13039644oib.8 for ; Sun, 08 Oct 2017 13:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BFi1dA+1az3dElWtJGUC9CpuesC7GBEjr+CffrsB1eI=; b=FVd+/JMikrgx9OAM8ujA+nmUxc78QBYM97LD0akhjvSn+urVEUeVdhjaFvdSMdK76D mKUEbhyohD0wKbZMGV88YE7ib84gpLRY7bVyxAGgGlmZazBpEHthSBCW+wXER3JNi1gC mk+Wf6TVvfSh9hEOVIX2mpmPamt8bHlkztzWpv8YDIDfuygVouueyIqa7e6c7WSh3DZ8 DpzytfvEfTxbPeDk7LIAfOexa4B9b3PTq3hhEiDL0EZ9JsgPq/nuynmpKzHoBEPU7/Yb OkmVDhrwd1Lohwoo8VDhaij0C5bnpzrFKWppedzMbmWDdorbNan18pdtlGk+bD2peMye xA9w== 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; bh=BFi1dA+1az3dElWtJGUC9CpuesC7GBEjr+CffrsB1eI=; b=aDjllhEX/iYBM2QPdSEmx5LAxMZ9aldIY845BbtC6M4sK7YSYlka2OuXsuLAQG34oS wihTNVnrJHyrZutNpG9xpU5BScwUiKrG8FXixaWTwr0FLHWdv1YQFtK9uuUlej81soPX heNhybb0xV7nYx/ysjqmHwQR4Xcv9gPCTC6yPqPHp8EOs4ZJFQnPjbTDGl23489uIm2w x7C5KB+9IsfuwQkVrK230hKyxeDD8Rriv1AZZWi02Rf4ljmptnkKXlEqy/iLH1Rim+ys Ui19JO8HGl1w40ylSzEeXa/+B7aFcthB+Raoy5b2cR6YYd084A+eJ6grMOcce/yAEKm8 Ug2A== X-Gm-Message-State: AMCzsaXS5h0dJjMRHddOmu7y97Qk5cJRG85M3gw+oWRM5iy40+zG4/uz Hzoii0V+QzCFaqKlVeN5H14OJX5KSm/+Z3gpCFo3omPs X-Google-Smtp-Source: AOwi7QBUHmyyQ3Np69GWkxH5VVwsTz9buKZccNsOe/JRNlffvEmyrT4d7/VGGH5R1lMdNLAl7GUfZ1pq82KMEwTx2nQ= X-Received: by 10.157.37.23 with SMTP id k23mr4687714otb.395.1507493023405; Sun, 08 Oct 2017 13:03:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.134 with HTTP; Sun, 8 Oct 2017 13:03:27 -0700 (PDT) From: Donald Eastlake Date: Sun, 8 Oct 2017 16:03:27 -0400 Message-ID: To: "trill@ietf.org" Content-Type: multipart/alternative; boundary="001a113cdb52295ec5055b0e9293" Archived-At: Subject: [trill] Call for presentations at the Singapore IETF TRILL meeting 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, 08 Oct 2017 20:03:46 -0000 --001a113cdb52295ec5055b0e9293 Content-Type: text/plain; charset="UTF-8" Hi, If you would like to present at the TRILL WG meeting in Singapore at IETF 100, please send mail to trill-chairs@ietf.org. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a113cdb52295ec5055b0e9293 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

If you would like to present at the= TRILL WG meeting in Singapore at IETF 100, please send mail to=C2=A0trill-chairs@ietf.org.
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 (cel= l)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com
--001a113cdb52295ec5055b0e9293-- From nobody Sun Oct 8 19:39:58 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 93B62132F30 for ; Sun, 8 Oct 2017 19:39:57 -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, 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 fg7FZLWpNOjr for ; Sun, 8 Oct 2017 19:39:56 -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 B18771321A7 for ; Sun, 8 Oct 2017 19:39:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXC44927; Mon, 09 Oct 2017 02:39:53 +0000 (GMT) Received: from DGGEMI401-HUB.china.huawei.com (10.3.17.134) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 03:39:52 +0100 Received: from DGGEMI501-MBS.china.huawei.com ([169.254.2.48]) by dggemi401-hub.china.huawei.com ([10.3.17.134]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 10:39:49 +0800 From: zhangdacheng To: Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) Thread-Index: AQHTO9PHNdr80aO2EUmJODcKoqmfOaLa1mew Date: Mon, 9 Oct 2017 02:39:49 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C224201635410@dggemi501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.167.227] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0201.59DAE17A.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.48, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: af3ec546a0b19a70d5957ba6f8d4c048 Archived-At: Subject: [trill] =?gb2312?b?tPC4tDogIFdvcmtpbmcgZ3JvdXAgTEMgb24gZHJhZnQt?= =?gb2312?b?aWV0Zi10cmlsbC1hZGRyZXNzLWZsdXNoLTAzICgxMC8yIC0gMTAvMTYp?= 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, 09 Oct 2017 02:39:57 -0000 SSB0aGluayB0aGlzIGRyYWZ0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gDQoNCi0tLS0t08q8 /tStvP4tLS0tLQ0Kt6K8/sjLOiB0cmlsbCBbbWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0gRG9uYWxkIEVhc3RsYWtlDQq3osvNyrG85DogMjAxN8TqMTDUwjPI1SA3OjExDQrK1bz+ yMs6IHRyaWxsQGlldGYub3JnDQrW98ziOiBbdHJpbGxdIFdvcmtpbmcgZ3JvdXAgTEMgb24gZHJh ZnQtaWV0Zi10cmlsbC1hZGRyZXNzLWZsdXNoLTAzICgxMC8yIC0gMTAvMTYpDQoNClRoaXMgYmVn aW5zIGEgMiB3ZWVrIFdHIExDIG9uIGRyYWZ0LWlldGYtdHJpbGwtYWRkcmVzcy1mbHVzaC0wMy50 eHQuDQpQbGVhc2UgaW5kaWNhdGUgaWYgeW91IHRoaW5rIHRoZSBkcmFmdCBpcyByZWFkeSBmb3Ig cHVibGljYXRpb24gYW5kIGlzIHVzZWZ1bCBmb3IgVFJJTEwgZGVwbG95bWVudHMuDQoNClRoYW5r cywNCkRvbmFsZA0KKFdHIFNlY3JldGFyeSBmb3IgdGhlIENoYWlyczogU3VlIEhhcmVzICYgSm9u IEh1ZHNvbikgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIERvbmFsZCBFLiBFYXN0 bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQogMTU1IEJlYXZlciBTdHJlZXQsIE1p bGZvcmQsIE1BIDAxNzU3IFVTQSAgZDNlM2UzQGdtYWlsLmNvbQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmls bEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0K From nobody Sun Oct 8 19:43:12 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 9FC1D133090 for ; Sun, 8 Oct 2017 19:43:10 -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, 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 D0qGR214KhfR for ; Sun, 8 Oct 2017 19:43:09 -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 EA4D91321A7 for ; Sun, 8 Oct 2017 19:43:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQD38928; Mon, 09 Oct 2017 02:43:07 +0000 (GMT) Received: from DGGEMI404-HUB.china.huawei.com (10.3.17.142) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 03:43:06 +0100 Received: from DGGEMI501-MBS.china.huawei.com ([169.254.2.48]) by dggemi404-hub.china.huawei.com ([10.3.17.142]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 10:42:59 +0800 From: zhangdacheng To: Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Working group LC on draft-ietf-trill-multi-topology-04 Thread-Index: AdNAp/mMukiaW39mT0al1L1T1JX80Q== Date: Mon, 9 Oct 2017 02:42:59 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C224201635456@dggemi501-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.130.167.227] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59DAE23B.009C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.48, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 69b6a9bc7ce4e60245062ab10cfdd2c7 Archived-At: Subject: [trill] =?gb2312?b?tPC4tDogIFdvcmtpbmcgZ3JvdXAgTEMgb24gZHJhZnQt?= =?gb2312?b?aWV0Zi10cmlsbC1tdWx0aS10b3BvbG9neS0wNA==?= 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, 09 Oct 2017 02:43:11 -0000 DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0KRnJvbTogIlN1c2FuIEhhcmVzIiA8c2hhcmVzIGF0IG5k emguY29tPiANClRvOiA8dHJpbGwgYXQgaWV0Zi5vcmc+IA0KQ2M6IDx0cmlsbC1jaGFpcnMgYXQg aWV0Zi5vcmc+LCAiJ0RvbmFsZCBFYXN0bGFrZSciIDxkM2UzZTMgYXQgZ21haWwuY29tPiANCkRh dGU6IFdlZCwgMjcgU2VwIDIwMTcgMTY6NDQ6MDggLTA0MDAgDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpUaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBMQyBvbiBkcmFmdC1pZXRmLXRyaWxsLW11 bHRpLXRvcG9sb2d5LTA0LnR4dC4gIER1cmluZyB0aGlzIFdHIGxhc3QgY2FsbCBwbGVhc2UgaW5j bHVkZSBjb21tZW50IG9uIHRoZSBmb2xsb3dpbmcgdGhyZWUgdGhpbmdzIGluIGFkZGl0aW9uIHRv IHlvdXIgbm9ybWFsIGNvbW1lbnRzOg0KDQoNCkRvZXMgdGhpcyBkcmFmdCBzdXBwb3J0IHRoZSB0 aGluZ3MgeW91IGRlc2lyZSB0byBzdXBwb3J0IG11bHRpcGxlIHRvcG9sb2d5IHJvdXRpbmcgb2Yg dW5pY2FzdCBhbmQgbXVsdGktZGVzdGluYXRpb24gdHJhZmZpYyBpbiBUUklMTD8NCg0KWWVzDQoN CkRvIHlvdSB0aGluayB0aGlzIGRyYWZ0IGlzIHJlYWQgZm9yIHB1YmxpY2F0aW9uPyANCg0KWWVz DQoNCkRvIHlvdSB0aGluayB0aGF0IG11bHRpLXRvcG9sb2d5IHRyaWxsIGhhcyBhIHBsYWNlIGlu IHRoZSBkYXRhIGNlbnRlciBkZXBsb3ltZW50cyBvZiBUUklMTD8NCg0KWWVzIA0KDQpTdWUgSGFy ZXMgYW5kIEpvbiBIdWRzb24gDQoNCkNvLWNoYWlycyBUUklMTCANCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJp bGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwN Cg== From nobody Sun Oct 8 23:29:23 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 7EE8013292F; Sun, 8 Oct 2017 23:29:16 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150753055649.18405.1663058866047353052@ietfa.amsl.com> Date: Sun, 08 Oct 2017 23:29:16 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-arp-optimization-09.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: Mon, 09 Oct 2017 06:29:16 -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 WG of the IETF. Title : TRILL: ARP/ND Optimization Authors : Yizhou Li Donald Eastlake Linda Dunbar Radia Perlman Mohammed Umair Filename : draft-ietf-trill-arp-optimization-09.txt Pages : 17 Date : 2017-10-08 Abstract: This document describes mechanisms to optimize the ARP (Address Resolution Protocol) and ND (Neighbor Discovery) traffic in a TRILL campus. TRILL switches maintain a cache of IP/MAC address/Data Label bindings that are learned from ARP/ND requests and responses that pass through them. In many cases, this cache allows an edge RBridge to avoid flooding an ARP/ND request by either responding to it directly or by encapsulating it and unicasting it. Such optimization reduces packet flooding over a TRILL campus. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-arp-optimization-09 https://datatracker.ietf.org/doc/html/draft-ietf-trill-arp-optimization-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-arp-optimization-09 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 Mon Oct 9 16:05:55 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 0DDB5132A89; Mon, 9 Oct 2017 16:05:49 -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 j2SaJSY_k6n1; Mon, 9 Oct 2017 16:05:44 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 4E471133080; Mon, 9 Oct 2017 16:05:44 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id j126so18759268oib.8; Mon, 09 Oct 2017 16:05:44 -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=2FbbY7VlTmXPe95j8vEr0l818AEEEiuDlGkhXm+UjnE=; b=AlV9bkNz64c+mkFqEWCILuHFa/HIUlps5cp86AUAWNZNqY3BbrPNZIk0LjEEW6OsEM AFq39n/0J1dnyF1MoNvmX1PFcuv65VGfhHqRxm3gMTozzn6r7/OPOwPWiJAO+vTzG+oR 3DIlVkbj3q+BratQtwciH4JtkVWGoJTdQH/ccwHW2XlK/9iFDBqY/iYn4G68MEYyH99u kQA+6oxKIXDQbwxiSeqSJCOeTNnu0BQTWbqU6CkKIFhWwQMnKDLZlyZZ5IfTgmQKTddy 2/ITry3dCXsDzEu4wlMv5zN/50rfLDDPwkHDWyhKkAeIebo+6yqFIoBHtSUA4Ts8YwDh vvmA== 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=2FbbY7VlTmXPe95j8vEr0l818AEEEiuDlGkhXm+UjnE=; b=dJts/Mbe9AtLP36czHELlkS+Q0zFQcIl+arVCW+FhscOLWqTftTxnuxx+gnLdVPpKC H/cHJZKMoUvvqDax+mACa3Gf9wIrkzR+RekZgZU91snBrnjs6tTl5qQlPneWJTdPZVPV xhVQLVYEreQveWD7H2HsqEZH6yPiiUW7eX4/jOgBo4yCLoI07P9AtPK5H+YhQUreZau5 6Xm6o61hCoJ+udZ+Y3jYZea7luNTvOxd8n7EN1JY4HVxuH3EW/vCQ8SJ9qgGUfq/FrUJ 3Bak+MzpBKCrLbyK77l2Z5m8Ke/vqDPANM3gF4Y81nUTZbSCqwuVHNhn3dspaozpJjpd wNoQ== X-Gm-Message-State: AMCzsaU/bAPRqmKHfoC4Cry3x9KIEbvEjJktoOgFlZRriLLeeQxve0AP UshFPyG9+NO/doyMjF0gttPKGE2lQf9BGu9HXZmazA== X-Google-Smtp-Source: AOwi7QCOIXMLHJTyMi3JFY7FhUlZuEUgwbNX1FAJC36FTKQGgozGWSL91/7FfCFlkxXepCuniGxvndxTi+/3b27i3BQ= X-Received: by 10.202.95.213 with SMTP id t204mr5524624oib.91.1507590343541; Mon, 09 Oct 2017 16:05:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.134 with HTTP; Mon, 9 Oct 2017 16:05:28 -0700 (PDT) In-Reply-To: References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 9 Oct 2017 19:05:28 -0400 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-trill-arp-optimization@ietf.org, "trill-chairs@ietf.org" , Susan Hares , "trill@ietf.org" Content-Type: multipart/alternative; boundary="001a113d5216e4ca5d055b253a20" Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) 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, 09 Oct 2017 23:05:49 -0000 --001a113d5216e4ca5d055b253a20 Content-Type: text/plain; charset="UTF-8" Hi Eric, A -09 version of draft-ietf-trill-arp-optimization has been posted. Could you look at it to see if it 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 Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorla wrote: > > > On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake wrote: > >> Hi Eric, >> >> My apologies for the delay in response. (For part of the time I was on >> a cruise...) >> >> It looks like we are in agreement on most items. >> >> See below. >> >> On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla wrote: >> > >> > >> > On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake >> wrote: >> >> >> >> Hi Eric, >> >> >> >> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla wrote: >> >> > Eric Rescorla has entered the following ballot position for >> >> > draft-ietf-trill-arp-optimization-08: Discuss >> >> > >> >> > ------------------------------------------------------------ >> ---------- >> >> > DISCUSS: >> >> > ------------------------------------------------------------ >> ---------- >> >> >> >> As a general comment, the Security Consideration section could use >> >> clarification and some expansion. >> >> >> >> Although one can imagine various mixed modes, to the first >> approximation >> >> there are two ways of doing the optimization of various >> multi-destination >> >> messages discussed in this document: >> >> >> >> + Using data plane learning by observing ARP/ND and similar messages >> (in >> >> addition to the learning of MAC addresses from the data plane which is >> >> enabled by default in TRILL). As described in this document, such data >> plane >> >> learning by TRILL switches can be used to sometimes optimize >> >> ARP/ND/RARP/unknown-destination messages. But the result isn't >> particularly >> >> more or less secure than it is when this data plane learning is done >> by end >> >> stations rather than by TRILL switches (or bridges or other kinds of >> >> switches) in the middle doing some optimization of the relevant >> >> multi-destination messages. Interface address information learned >> through >> >> data plane learning by edge TRILL switches can also be propagated via >> the >> >> control plane but this is not significantly different from propagating >> that >> >> information via the multi-destination messages that are being >> optimized to >> >> unicast or optimized away. >> >> + Using a complete, trusted directory as might be based on an >> orchestration >> >> system in a data center. Since the messages between TRILL switches >> doing >> >> ARP/ND/RARP/unknown-destination optimization can be secured and the >> TRILL >> >> switches can be configured to ignore data plane learning, this enables >> TRILL >> >> switches to provide answers that are "correct" in that they correspond >> to >> >> the data in this complete, trusted directory. However, there can still >> be >> >> various forged messages/addresses on a local link between end >> station(s) and >> >> edge TRILL switches. Such a local link can, with TRILL, be a bridged >> LAN, so >> >> such forgeries emitted by an end station may be seen by other end >> stations >> >> and cause incorrect learning from the data plane. >> >> >> >> The existing Security Considerations section is a bit sketchy and >> >> concentrates more on the data plane case, as that is the one with the >> >> greatest security challenges. >> > >> > Yes, this seems like a reasonable assessment. Alia, does someone have >> the >> > action item to make it less sketchy? >> >> We are working on a draft revision to reflect the above thinking to a >> greater extent and decrease sketchiness. >> >> >> > It's not clear to me how the security properties of this mechanism >> >> > compare to existing TRILL. The text says: >> >> > >> >> > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages >> can be >> >> > easily forged. Therefore the learning of MAC/IP addresses by >> RBridges >> >> > from ARP/ND should not be considered as reliable. See Section 4.1 >> for >> >> > SEND Considerations. >> >> > >> >> > "not considered as reliable" seems suboptimal. You need to cover how >> >> > this mechanism compares to the non-use of this mechanism. >> >> >> >> As above, the optimization mechanisms do not make any significant >> >> difference to the inherent insecurities of data plane learning but >> when used >> >> with a complete, trusted directory, it improves considerably over data >> plane >> >> learning.. >> > >> > That had kind of been my impression, but then I don't understand what >> "not >> > considered as reliable" is doing here. I'm supposed to be doing >> something >> > with it, so while it may be non-secure, I'm still relying on it, no? >> >> Well, at some level some elements of your protocol stack are "relying" >> on it or "trusting" it or whatever term you want, but it's trivially >> forged unless you use additional security protocols so I guess we >> could say something about that. TRILL supports different link >> technologies but if you are using an Ethernet link, I suppose you >> could use 802.1AE to improve trust in MAC addresses at layer 2. It >> wouldn't hurt to mention that but it has very little to do with ARP/ND >> optimization or TRILL. >> > > I think if you just sort of say "you are using it, but it's not > trustworthy and here's why" you have it covered. > > -Ekr > > >> >> > This document seems very sketchy on what you do when you get >> duplicate >> >> > IPs. >> >> >> >> Why should what you do when you notice a duplicate IP address be >> >> significantly different just because some multi-destination messages >> are >> >> being optimized? Why shouldn't you just do whatever you do now and why >> is >> >> that any of TRILL's business? >> > >> > Because you're getting the information via different vector, TRILL >> needs to >> > specify what you do, >> > if only to say "do what you would do otherwise". >> >> OK. >> >> >> > In the case where the former owner replies, a Duplicate Address >> has >> >> > been detected. In this case the querying RBridge SHOULD log the >> >> > duplicate so that the network administrator can take appropriate >> >> > action. >> >> > >> >> > How does logging solve the problem? >> >> >> >> It doesn't but it seems better than not logging. >> >> >> >> > What do you reply to ARPs with and/or propagate to other nodes? >> >> >> >> If you are asking how you reply to ARPs if the IP address being ARPed >> for >> >> has been found to be duplicated, there are the two cases outlined >> above. If >> >> you are using a complete, trusted directory, you give the presumed >> correct >> >> answer provided by that directory. If you are using data plane >> learning, you >> >> use whatever you last learned from the data plane (which could have >> been a >> >> forgery over writing good information or good information over writing >> a >> >> forgery or a forgery overwriting a different forgery or ...). >> >> >> >> > Do you tell the originator of the advertisement you have a duplicate? >> >> >> >> As far as I know there is no standardized way to tell a station that >> you >> >> think it has an IP address that is duplicated locally and I don't >> think it >> >> is the job of TRILL to provide such a mechanism. Certainly this >> document >> >> does not propose anything of that sort. >> > >> > OK. >> > >> > >> >> > When a newly connected end-station exchanges messages with a DHCP >> >> > [RFC2131] server an edge RBridge should snoop them (mainly the >> >> > DHCPAck message) and store IP/MAC mapping information in its >> ARP/ND >> >> > cache and should also send the information out through the TRILL >> >> > control plane using ESADI. >> >> > >> >> > What happens if the attacker sets up a fake DHCP server and pretends >> >> > to assign addresses to himself? It seems like maybe that's the same >> >> > as fake ARPs but maybe not. >> >> >> >> This snooping on DHCP messages only applies to the data plane learning >> >> case. In the case of a complete, trusted directory, edge RBridges >> already >> >> know the right answer, so to speak. With data plane learning, if there >> are >> >> forged DHCP messages, things are likely to get all screwed up. Of >> course, >> >> you could run DHCP over IPsec but, partly due to the localized nature >> of >> >> DHCP, I don't think very many people do that. There is also RFC 3118 >> which >> >> can be used to authenticate DHCP messages, but that assumes the >> distribution >> >> of keying information. >> >> >> >> There isn't much difference between the various multi-destination >> messages >> >> (ARP / DHCP) advertising the addresses and point of attachment of >> >> interfaces. But, overall, I'm not sure why a document that is just >> >> describing ways to optimize the distribution of various >> multi-destination >> >> messages needs to analyze the security of the protocols implemented by >> those >> >> multi-destination when, as in the data plane learning case, it is not >> >> significantly changing that security. >> > >> > Well, in this case, you have a new threat vector: DHCP. Even if it is >> the >> > same kind of threats, it's still a new threat vector. >> > More generally documents need to contain complete security >> considerations >> > sections. If the security considerations >> > are the same as with some other document, then they need to say that. >> >> OK. >> >> >> > In general, the security considerations need a complete threat >> >> > analysis per 3552. >> >> >> >> I don't think there is that much new in this document. While the >> Security >> >> Considerations section needs clarification and some expansion, I don't >> think >> >> it is, for example, the job of this document to do a threat analysis >> of the >> >> ARP protocol as long as it can make a reasonable case that the >> security of >> >> ARP is not significantly changed by the optimizations specified. >> > >> > Sure, but it also doesn't make that case. >> >> I'll see what we can do. >> >> >> > ------------------------------------------------------------ >> ---------- >> >> > COMMENT: >> >> > ------------------------------------------------------------ >> ---------- >> >> >> >> For completeness, I've cut and pasted below the COMMENT responses I >> sent >> >> to you a while ago. >> >> >> >> Thanks, >> >> Donald >> >> =============================== >> >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> >> 155 Beaver Street, Milford, MA 01757 USA >> >> >> d3e3e3@gmail.com >> >> >> >> > S 2. >> >> > >> >> > plane on the edge RBridges, it should be possible to completely >> >> > suppress flooding of ARP/ND messages in a TRILL Campus, When all >> end- >> >> > station MAC addresses are similarly known, it should be possible >> to >> >> > suppress unknown unicast flooding by dropping any unknown unicast >> >> > received at an edge RBridge. >> >> > >> >> > Are these "should be possibles" normative? Descriptive? >> >> >> >> Section 2 of this document is a general discussion of the optimization >> >> problem which, while it does mention a couple of possible facets of >> >> potential solutions, is not intended to be normative. >> >> >> >> >> >> > S 4. >> >> > This is a sequence of steps, so it would be nice to preface them with >> >> > a list of the steps. It's also odd to have SEND considerations right >> >> > in the middle here. >> >> >> >> Sorry, I don't understand exactly what you are pointing at as a >> >> sequence of steps. All of Section 4? Just the text between the Section >> >> 4 heading and the Section 4.1 heading? Something else? >> > >> > Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, >> etc. >> > It would be nice if they were listed ahead of this as "this is what you >> do, >> > now read the sections" >> >> OK. We can add some clarifying material to Section 4 before the 4.1 >> heading. >> >> >> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP >> >> > >> >> > Please explain what a non-zero IP is and why it's relevant. >> >> > This graf also needs an introductory sentence or something before >> >> > the bullets. >> >> >> >> Here is a copy of the response that was sent to a similar comment in >> >> Dale Worley's GENART review: >> >> >> >> This section is talking about getting and handling the IP/MAC >> >> mapping information for a local end station by an edge RBridge. An >> >> ARP/ND from such a local end station might show a zero source IP >> >> address if the end station does not have one or is probing for >> >> duplicates. >> >> >> >> Perhaps the title for the Section should be something like >> >> >> >> 4.3 Extracting Local End Station IP/MAC Mapping Information >> >> >> >> and a new first paragraph could be added something like >> >> >> >> Edge RBridges extract and use information about the correspondence >> >> between local end station IP and MAC addresses from the ARP/ND >> >> messages those end stations send as described below. An apparent zero >> >> source IP address means that the end station is probing for duplicate >> >> IP addresses and messages with such a zero source IP address are not >> >> used for the extraction of IP/MAC address mapping information >> > >> > LGTM >> > >> > >> >> > S 4.4. >> >> > It is not essential that all RBridges use the same strategy for >> which >> >> > option to select for a particular ARP/ND query. It is up to the >> >> > implementation. >> >> > >> >> > This seems inconsistent with the MUST in arm (b) below, because I >> >> > can just take some other arm. It's also kind of surprising to be this >> >> > non-prescriptive. >> >> >> >> The wording needs to be clarified. Which lettered item listed below >> >> applies is determined by the circumstances; however, which of the >> >> numbered strategies associated with these items is followed is an >> >> implementation choice in handeling any particular ARP/ND. >> > >> > OK. >> > >> > >> >> > S 8. >> >> > some other location (MAC/VM Mobility) and gets connected to egde- >> >> > >> >> > Nit: edge is mispelled. >> >> >> >> OK. >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> >> d3e3e3@gmail.com >> > > --001a113d5216e4ca5d055b253a20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

A -09 version of draft-ietf-tr= ill-arp-optimization has been posted. Could you look at it to see if it res= olves your comments?

Thanks,<= br>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.co= m

On Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:


On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake <d3e3e3= @gmail.com> wrote:
Hi Eric,=

My apologies for the delay in response. (For part of the time I was on
a cruise...)

It looks like we are in agreement on most items.

See below.

On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>>
>> Hi Eric,
>>
>> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-trill-arp-optimization-08: Discuss
>> >
>> > --------------------------------------------------------= --------------
>> > DISCUSS:
>> > --------------------------------------------------------= --------------
>>
>> As a general comment, the Security Consideration section could use=
>> clarification and some expansion.
>>
>> Although one can imagine various mixed modes, to the first approxi= mation
>> there are two ways of doing the optimization of various multi-dest= ination
>> messages discussed in this document:
>>
>> + Using data plane learning by observing ARP/ND and similar= messages (in
>> addition to the learning of MAC addresses from the data plan= e which is
>> enabled by default in TRILL). As described in this document, such = data plane
>> learning by TRILL switches can be used to sometimes optimize
>> ARP/ND/RARP/unknown-destination messages. But the result isn&= #39;t particularly
>> more or less secure than it is when this data plane learning is do= ne by end
>> stations rather than by TRILL switches (or bridges or other kinds = of
>> switches) in the middle doing some optimization of the relevant >> multi-destination messages. Interface address information learned = through
>> data plane learning by edge TRILL switches can also be propagated = via the
>> control plane but this is not significantly different from propaga= ting that
>> information via the multi-destination messages that are being opti= mized to
>> unicast or optimized away.
>> + Using a complete, trusted directory as might be based on = an orchestration
>> system in a data center. Since the messages between TRILL sw= itches doing
>> ARP/ND/RARP/unknown-destination optimization can be secured a= nd the TRILL
>> switches can be configured to ignore data plane learning, this ena= bles TRILL
>> switches to provide answers that are "correct" in that t= hey correspond to
>> the data in this complete, trusted directory. However, there can s= till be
>> various forged messages/addresses on a local link between end stat= ion(s) and
>> edge TRILL switches. Such a local link can, with TRILL, be a bridg= ed LAN, so
>> such forgeries emitted by an end station may be seen by other end = stations
>> and cause incorrect learning from the data plane.
>>
>> The existing Security Considerations section is a bit sketchy and<= br> >> concentrates more on the data plane case, as that is the one with = the
>> greatest security challenges.
>
> Yes, this seems like a reasonable assessment. Alia, does someone have = the
> action item to make it less sketchy?

We are working on a draft revision to reflect the above thinking to = a
greater extent and decrease sketchiness.

>> > It's not clear to me how the security properties of this = mechanism
>> > compare to existing TRILL. The text says:
>> >
>> >=C2=A0 =C2=A0 Unless Secure ND (SEND [RFC3971]) is used, ARP a= nd ND messages can be
>> >=C2=A0 =C2=A0 easily forged. Therefore the learning of MAC/IP = addresses by RBridges
>> >=C2=A0 =C2=A0 from ARP/ND should not be considered as reliable= . See Section 4.1 for
>> >=C2=A0 =C2=A0 SEND Considerations.
>> >
>> > "not considered as reliable" seems suboptimal. You = need to cover how
>> > this mechanism compares to the non-use of this mechanism.
>>
>> As above, the optimization mechanisms do not make any significant<= br> >> difference to the inherent insecurities of data plane learning but= when used
>> with a complete, trusted directory, it improves considerably over = data plane
>> learning..
>
> That had kind of been my impression, but then I don't understand w= hat "not
> considered as reliable" is doing here. I'm supposed to be doi= ng something
> with it, so while it may be non-secure, I'm still relying on it, n= o?

Well, at some level some elements of your protocol stack are "r= elying"
on it or "trusting" it or whatever term you want, but it's tr= ivially
forged unless you use additional security protocols so I guess we
could say something about that. TRILL supports different link
technologies but if you are using an Ethernet link, I suppose you
could use 802.1AE to improve trust in MAC addresses at layer 2. It
wouldn't hurt to mention that but it has very little to do with ARP/ND<= br> optimization or TRILL.

I th= ink if you just sort of say "you are using it, but it's not trustw= orthy and here's why" you have it covered.

-Ekr


>> > This document seems very sketchy on what you do when you get = duplicate
>> > IPs.
>>
>> Why should what you do when you notice a duplicate IP address be >> significantly different just because some multi-destination messag= es are
>> being optimized? Why shouldn't you just do whatever you do now= and why is
>> that any of TRILL's business?
>
> Because you're getting the information via different vector, TRILL= needs to
> specify what you do,
> if only to say "do what you would do otherwise".

OK.

>> >=C2=A0 =C2=A0 In the case where the former owner replies, a Du= plicate Address has
>> >=C2=A0 =C2=A0 been detected. In this case the querying RBridge= SHOULD log the
>> >=C2=A0 =C2=A0 duplicate so that the network administrator can = take appropriate
>> >=C2=A0 =C2=A0 action.
>> >
>> > How does logging solve the problem?
>>
>> It doesn't but it seems better than not logging.
>>
>> > What do you reply to ARPs with and/or propagate to other node= s?
>>
>> If you are asking how you reply to ARPs if the IP address being AR= Ped for
>> has been found to be duplicated, there are the two cases outlined = above. If
>> you are using a complete, trusted directory, you give the presumed= correct
>> answer provided by that directory. If you are using data plane lea= rning, you
>> use whatever you last learned from the data plane (which could hav= e been a
>> forgery over writing good information or good information over wri= ting a
>> forgery or a forgery overwriting a different forgery or ...).
>>
>> > Do you tell the originator of the advertisement you have a du= plicate?
>>
>> As far as I know there is no standardized way to tell a station th= at you
>> think it has an IP address that is duplicated locally and I don= 9;t think it
>> is the job of TRILL to provide such a mechanism. Certainly this do= cument
>> does not propose anything of that sort.
>
> OK.
>
>
>> >=C2=A0 =C2=A0 When a newly connected end-station exchanges mes= sages with a DHCP
>> >=C2=A0 =C2=A0 [RFC2131] server an edge RBridge should snoop th= em (mainly the
>> >=C2=A0 =C2=A0 DHCPAck message) and store IP/MAC mapping inform= ation in its ARP/ND
>> >=C2=A0 =C2=A0 cache and should also send the information out t= hrough the TRILL
>> >=C2=A0 =C2=A0 control plane using ESADI.
>> >
>> > What happens if the attacker sets up a fake DHCP server and p= retends
>> > to assign addresses to himself? It seems like maybe that'= s the same
>> > as fake ARPs but maybe not.
>>
>> This snooping on DHCP messages only applies to the data plane lear= ning
>> case. In the case of a complete, trusted directory, edge RBridges = already
>> know the right answer, so to speak. With data plane learning, if t= here are
>> forged DHCP messages, things are likely to get all screwed up. Of = course,
>> you could run DHCP over IPsec but, partly due to the localized nat= ure of
>> DHCP, I don't think very many people do that. There is also RF= C 3118 which
>> can be used to authenticate DHCP messages, but that assumes the di= stribution
>> of keying information.
>>
>> There isn't much difference between the various multi-destinat= ion messages
>> (ARP / DHCP) advertising the addresses and point of attachment of<= br> >> interfaces. But, overall, I'm not sure why a document that is = just
>> describing ways to optimize the distribution of various multi-dest= ination
>> messages needs to analyze the security of the protocols implemente= d by those
>> multi-destination when, as in the data plane learning case, it is = not
>> significantly changing that security.
>
> Well, in this case, you have a new threat vector: DHCP. Even if it is = the
> same kind of threats, it's still a new threat vector.
> More generally documents need to contain complete security considerati= ons
> sections. If the security considerations
> are the same as with some other document, then they need to say that.<= br>
OK.

>> > In general, the security considerations need a complete threa= t
>> > analysis per 3552.
>>
>> I don't think there is that much new in this document. While t= he Security
>> Considerations section needs clarification and some expansion, I d= on't think
>> it is, for example, the job of this document to do a threat analys= is of the
>> ARP protocol as long as it can make a reasonable case that the sec= urity of
>> ARP is not significantly changed by the optimizations specified. >
> Sure, but it also doesn't make that case.

I'll see what we can do.

>> > --------------------------------------------------------= --------------
>> > COMMENT:
>> > --------------------------------------------------------= --------------
>>
>> For completeness, I've cut and pasted below the COMMENT respon= ses I sent
>> to you a while ago.
>>
>> 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, M= ilford, MA 01757 USA
>>=C2=A0 d3e3e3= @gmail.com
>>
>> > S 2.
>> >
>> >=C2=A0 =C2=A0 plane on the edge RBridges, it should be possibl= e to completely
>> >=C2=A0 =C2=A0 suppress flooding of ARP/ND messages in a TRILL = Campus, When all end-
>> >=C2=A0 =C2=A0 station MAC addresses are similarly known, it sh= ould be possible to
>> >=C2=A0 =C2=A0 suppress unknown unicast flooding by dropping an= y unknown unicast
>> >=C2=A0 =C2=A0 received at an edge RBridge.
>> >
>> > Are these "should be possibles" normative? Descript= ive?
>>
>> Section 2 of this document is a general discussion of the optimiza= tion
>> problem which, while it does mention a couple of possible facets o= f
>> potential solutions, is not intended to be normative.
>>
>>
>> > S 4.
>> > This is a sequence of steps, so it would be nice to preface t= hem with
>> > a list of the steps. It's also odd to have SEND considera= tions right
>> > in the middle here.
>>
>> Sorry, I don't understand exactly what you are pointing at as = a
>> sequence of steps. All of Section 4? Just the text between the Sec= tion
>> 4 heading and the Section 4.1 heading? Something else?
>
> Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, = etc.
> It would be nice if they were listed ahead of this as "this is wh= at you do,
> now read the sections"

OK. We can add some clarifying material to Section 4 before the= 4.1 heading.

>> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero = IP
>> >
>> > Please explain what a non-zero IP is and why it's relevan= t.
>> > This graf also needs an introductory sentence or something be= fore
>> > the bullets.
>>
>> Here is a copy of the response that was sent to a similar comment = in
>> Dale Worley's GENART review:
>>
>> This section is talking about getting and handling the IP/MAC
>> mapping information for a local end station by an edge RBridge. An=
>> ARP/ND from such a local end station might show a zero source IP >> address if the end station does not have one or is probing for
>> duplicates.
>>
>> Perhaps the title for the Section should be something like
>>
>>=C2=A0 =C2=A0 4.3 Extracting Local End Station IP/MAC Mapping Infor= mation
>>
>> and a new first paragraph could be added something like
>>
>>=C2=A0 =C2=A0 Edge RBridges extract and use information about the c= orrespondence
>> between local end station IP and MAC addresses from the ARP/ND
>> messages those end stations send as described below. An apparent z= ero
>> source IP address means that the end station is probing for duplic= ate
>> IP addresses and messages with such a zero source IP address are n= ot
>> used for the extraction of IP/MAC address mapping information
>
> LGTM
>
>
>> > S 4.4.
>> >=C2=A0 =C2=A0 It is not essential that all RBridges use the sa= me strategy for which
>> >=C2=A0 =C2=A0 option to select for a particular ARP/ND query. = It is up to the
>> >=C2=A0 =C2=A0 implementation.
>> >
>> > This seems inconsistent with the MUST in arm (b) below, becau= se I
>> > can just take some other arm. It's also kind of surprisin= g to be this
>> > non-prescriptive.
>>
>> The wording needs to be clarified. Which lettered item listed belo= w
>> applies is determined by the circumstances; however, which of the<= br> >> numbered strategies associated with these items is followed is an<= br> >> implementation choice in handeling any particular ARP/ND.
>
> OK.
>
>
>> > S 8.
>> >=C2=A0 =C2=A0 some other location (MAC/VM Mobility) and gets c= onnected to egde-
>> >
>> > Nit: edge is mispelled.
>>
>> OK.

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, M= A 01757 USA
=C2=A0d3e3e3@gmail.co= m


--001a113d5216e4ca5d055b253a20-- From nobody Wed Oct 11 08:33:42 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 B6048120720 for ; Wed, 11 Oct 2017 08:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 y8ANIymJDsyY for ; Wed, 11 Oct 2017 08:33:39 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 0CB8412008A for ; Wed, 11 Oct 2017 08:33:39 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id z50so6380390qtj.4 for ; Wed, 11 Oct 2017 08:33:39 -0700 (PDT) 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=6mCkGCewtoHfYHypYlFj/JaNaYC1v9sbZFA96iQUO6w=; b=r3jEpeTbwl2Mj8pp7Tqjle3EqT5d9AKMPnVvWODMz2haFb+leiOTnH3A93W0Y19Qtk nB9XhKcgrsH2YEb+qu9P9lD4jOTQdDzLP6HWX2kChvheFmsKWjxv7WL7o6VvAWWJdjr2 L8rFum85wKfl0HIe5SSkwAZiVsK8bawxaByQXBErEoJ5p9LBxmhKuaDVMpLDzY2Zwk4q vOVTCzYRwJE1E++zXx7Mxs+Nb8kPtG/7j2YsVm0FN3s/+598MixjMEsemGBxs9hG2p23 +AZxexA4+1vo2h46Oc35YA9DoUh7d2eQ/Pxx0nsLjsd4/tRHUKu4jOaYsfi0lP6KR3DQ oHzA== 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=6mCkGCewtoHfYHypYlFj/JaNaYC1v9sbZFA96iQUO6w=; b=rapJERf/zEWSgZGRUKnA0zsiMix/uo6VseUKpBk19j9bsmspF87RsZPl/GdrRGxWkU P8lhXpS3rwjbC6LYZiZ7OvxAn9DL7p5mP36FflM0CcwPicjv5UzXgupEccdCikU9LX5G wztl3tdBeOVEe4OiYUEUtKtndTn8TPyR0FOUbPlW7vNIReuitpfqFoofwCzqK1lKeQT2 0ePxtsVQ3z/fo0ZQAg7EJTpfInQco81ryx+epxv1n0t9bC6NWkxmi1xCumT5FPKFsfEW uRjfF6dhTwYqUOVBWv6XgP5tCP8HLJ7IX89UxJun3Rt2uDlvEdnbc6Lqb9/0Q9DOHt/z 5Z1g== X-Gm-Message-State: AMCzsaVIu24/jDuFofxykSLbg6VYuPehnmh00l+Re6S465cOUqNhnZBb HOAOo6R++i4lst5qCRYtYBbeH94wxXXgthFG77Dz4L6q X-Google-Smtp-Source: ABhQp+SqZ9FlaPVTcYx304rEApAbEmHqs2hTJV55BD4utVA5XYd3LN+7YxrZNZr2OykMesEyEfSWL3hzuckJ9un+qiI= X-Received: by 10.200.38.225 with SMTP id 30mr45612qtp.334.1507736017508; Wed, 11 Oct 2017 08:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.56.225 with HTTP; Wed, 11 Oct 2017 08:33:36 -0700 (PDT) From: R Parameswaran Date: Wed, 11 Oct 2017 08:33:36 -0700 Message-ID: To: trill@ietf.org Cc: Donald Eastlake Content-Type: multipart/alternative; boundary="001a11407326bd1f0e055b472592" Archived-At: Subject: Re: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) 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: Wed, 11 Oct 2017 15:33:41 -0000 --001a11407326bd1f0e055b472592 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I support the adoption/standardization of this draft, use case seems real. Informal review per request, comments: 1. Could probably use a text review prior to the next step. One or two sentences can be tightened up: a. 2.2 item 3 ("The TLVs in an extensible Address Flush message are .. "= ) b. typo in 2.2.8 (type =3D 8 vs 7 in figure). 2. The draft gives a number of ways to specify an address flush e.g. various ways specify vlans, FGLs and MAC addresses (e.g. lists blocks, bitlists). Do we know if valid use cases for all these ways of specifying a flush? Also, for block specifiers what happens if there are overlapping blocks? 3. With a TLV length of 8 bits you cannot really specify more than 192 FGLs and 42 MAC addresses. Are multiple TLVs of the same type allowed? Instead, would it make sense to have a longer TLV length field of say 16 bits? 4. It looks like a spoofed address flush can be used to mount a denial of service attack. If that is protected by encryption or by perimeter security, it might be good to explicitly call this out in Section 4, Security Considerations. thanks, Ramkumar [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16= ) Donald Eastlake Mon, 02 October 2017 23:11 UTCShow heade= r This begins a 2 week WG LC on draft-ietf-trill-address-flush-03.txt. Please indicate if you think the draft is ready for publication and is useful for TRILL deployments. Thanks, Donald (WG Secretary for the Chairs: Sue Hares & Jon Hudson) =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 Replies: - [trill] =E7=AD=94=E5=A4=8D: Working group LC on draft-ietf-trill-addre= ss-flush-03 (10/2 - 10/16) zhangdacheng --001a11407326bd1f0e055b472592 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,


I support the ado= ption/standardization of this draft, use case seems real.
Informal revi= ew per request, comments:

1. Could probably use a text review prior = to the next step. One or
=C2=A0=C2=A0 two sentences can be tightened up:=

=C2=A0=C2=A0 a. 2.2 item 3 ("The TLVs in an extensible Address= Flush message are .. ")

=C2=A0=C2=A0 b. typo in 2.2.8 (type =3D= 8 vs 7 in figure).

2. The draft gives a number of ways to specify = an address flush e.g.
=C2=A0=C2=A0 various ways specify vlans, FGLs and = MAC addresses (e.g. lists
=C2=A0=C2=A0 blocks, bitlists). Do we know if = valid use cases for all these ways of
=C2=A0=C2=A0 specifying a flush? = Also, for block specifiers what happens if there
=C2=A0=C2=A0 are overl= apping blocks?

3. With a TLV length of 8 bits you cannot really spec= ify more than
=C2=A0=C2=A0 192 FGLs and 42 MAC addresses. Are multiple T= LVs of the same type
=C2=A0=C2=A0 allowed? Instead, would it make sense = to have a longer TLV length
=C2=A0=C2=A0 field of say 16 bits?

4= . It looks like a spoofed address flush can be used to mount a denial
= =C2=A0=C2=A0 of service attack. If that is protected by encryption or by pe= rimeter
=C2=A0=C2=A0 security, it might be good to explicitly call this = out in Section 4,
=C2=A0=C2=A0 Security Considerations.

thanks,
Ramkumar


[trill] Working group LC on draft-ie= tf-trill-address-flush-03 (10/2 - 10/16)

Donald Eastlake <= d3e3e3@gmail.com> Mon, 02 October 201= 7 23:11 UTCShow= header

=20
=20 
This begins a 2 week WG LC on draft=
-ietf-trill-address-flush-03.txt.
Please indicate if you think the draft is ready for publication and is
useful for TRILL deployments.

Thanks,
Donald
(WG Secretary for the Chairs: Sue Hares & Jon Hudson)
=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
=20 =20 =20 =20 =20 =20 =20 =20
--001a11407326bd1f0e055b472592-- From nobody Sun Oct 15 17:58:02 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 9C8671332E3 for ; Sun, 15 Oct 2017 17:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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, 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 Ovi_2VGN147I for ; Sun, 15 Oct 2017 17:57:59 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 6E3841332DA for ; Sun, 15 Oct 2017 17:57:59 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o187so10987041qke.7 for ; Sun, 15 Oct 2017 17:57:59 -0700 (PDT) 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=e7pQXjBaBKIdtJVAjKCEKAVTeVxml0fdOmP6tW1hjJQ=; b=a4GcOCSyALk1jAFNRVr7I6HPBTOee7Oyryu6jTCdZF2TJKA8+rHDiVFMr/OMLpz5u7 zzJ5ltWmAyoN28uXqLRnrXb5WicFJou6idDM5gngyLKqEyeOqFG7JnO2CwccmqQnJKJh dUUjMtgsF9EmQLO6Lgabc/ikVhzUqj0gcYqdceSMjT5iHaA3wUP04mn3Qh46QKRqCQg6 b48vb34agJZ39Rw5SM9bLQGtQiwWa8kYaqrppNDWoi62DrFRwKoAmrMiBYhjUXm1Zu8r 0fgcbkvHi0Zgy6VLeRFL0jvBh4ewbegaOQuiGocZS03VpZM2QZowd009xTA3Salq2pxO XwyA== 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=e7pQXjBaBKIdtJVAjKCEKAVTeVxml0fdOmP6tW1hjJQ=; b=aAVYXXDSZsZouEacuw2zPWmjAq4KSgyDyepN1Q7EpLN/iKbYOu5OUr7iVSNyvhlVap 5oEf7KmGPJFBaKBGuB8nIjMD8omNZ1V2OIqKAEXK/v0yFZR9vSQ9oGUTEW9sIaxp0XCe 1UKnFkCLziv9shR6nkk+k3Oq3UkVrh6BESwwR7pqmCyJjooEgyXVUkPMmfVy4MPX+n99 p9ZEiSdwRpD0jqUP8Du2uiXtCfbQHWPFqxaNLKe9Gw6OcfQpjyMSY+rxWkGqeJKRQhcm oapJLv3f0Hvug4PHdLX5k5rxeWiqYvEFsoVp3FBT0xUF4uyiCRlT0v12W9t8NOnX8fx9 8baQ== X-Gm-Message-State: AMCzsaW5qXtjqiCnc15fnihJKCkuMoy19tofdO1F8hocSS1iqs2fnuDb 5EgwRq8rLDwHP7TUdugdN3POjuANe7PHMOlPVZB6bg== X-Google-Smtp-Source: AOwi7QBDc+dAPCopOvgiZy4h6KtYKp9hH2NcUeW6gRsyIL2qfXGJ3EI24yQn25J7La79OMnfgqaJK25q5eqGGlNzNHo= X-Received: by 10.55.49.143 with SMTP id x137mr10882233qkx.138.1508115478175; Sun, 15 Oct 2017 17:57:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.56.231 with HTTP; Sun, 15 Oct 2017 17:57:57 -0700 (PDT) From: R Parameswaran Date: Sun, 15 Oct 2017 17:57:57 -0700 Message-ID: To: trill@ietf.org Cc: Donald Eastlake Content-Type: multipart/alternative; boundary="001a1146edbc5b6370055b9f7f93" Archived-At: Subject: [trill] Working group LC on draft-ietf-trill-multi-topology-04 (9/27 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, 16 Oct 2017 00:58:01 -0000 --001a1146edbc5b6370055b9f7f93 Content-Type: text/plain; charset="UTF-8" Hi, I support the adoption/standardization of this draft. Comments inline. thanks, Ramkumar This begins a 2 week WG LC on draft-ietf-trill-multi-topology-04.txt. During this WG last call please include comment on the following three things in addition to your normal comments: 1) Does this draft support the things you desire to support multiple topology routing of unicast and multi-destination traffic in TRILL? [RP]: Yes. 2) Do you think this draft is read for publication? [RP]: Yes, quick look-through, seems correct. 3) Do you think that multi-topology trill has a place in the data center deployments of TRILL? [RP] Yes. Sue Hares and Jon Hudson Co-chairs TRILL --001a1146edbc5b6370055b9f7f93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 


=
Hi,

I support the adoption/standardization of this draft. Comments  =
inline.

thanks,

Ramkumar


This be=
gins a 2 week WG LC on draft-ietf-trill-multi-topology-04.txt.
During this WG last call please include comment on the following three
things in addition to your normal comments:

1)      Does this draft support the things you desire to support multiple
topology routing of unicast and multi-destination traffic in TRILL?

=

[RP]: Yes.

=C2=A02)      Do you think this draft is read for publication? 
[RP]: Yes, quick look-through, seems correct.=20

3)      Do you think that multi-topology trill has a place in the data
center deployments of TRILL?

[RP] Yes=
.

=C2=A0Sue Hares and Jon Hudson=20

Co-chairs TRILL=20





--001a1146edbc5b6370055b9f7f93-- From nobody Tue Oct 17 10:58:23 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 C485E126B6E for ; Tue, 17 Oct 2017 10:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 FPlEhtbYe7Vr for ; Tue, 17 Oct 2017 10:58:20 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBC9132D4E for ; Tue, 17 Oct 2017 10:58:20 -0700 (PDT) Received: from localhost.localdomain (imgmt2.lax.icann.org [10.32.11.180]) by smtp01.icann.org (Postfix) with ESMTP id 0E374E0E59 for ; Tue, 17 Oct 2017 17:58:19 +0000 (UTC) From: Marilia Hirano To: trill@ietf.org Message-Id: <20171017175820.CFBC9132D4E@ietfa.amsl.com> Date: Tue, 17 Oct 2017 10:58:20 -0700 (PDT) Archived-At: Subject: [trill] The 2017 IANA annual survey is coming 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, 17 Oct 2017 17:58:22 -0000 Dear valued customer, We strive to continuously improve our delivery of the IANA functions. We have engaged Ebiquity, an independent research firm to run our 2017 customer survey and Judy.Bromley@ebiquity.com will send you an invitation to participate early next week. Ebiquity is committed to protecting the confidentiality of all respondents in line with the Code of Conduct of ESOMAR (a membership organization representing the interests of the data, research and insights profession at an international level). We appreciate your time and helping us improve the delivery of the IANA functions. If you have any questions, please contact me at marilia.hirano@iana.org. Yours faithfully, Marilia Hirano Manager, Continuous Improvement ICANN From nobody Wed Oct 18 09:43:05 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 35EA913234B for ; Wed, 18 Oct 2017 09:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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, 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 dqXiEqpNAh9q for ; Wed, 18 Oct 2017 09:43:01 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 A84FE1321CB for ; Wed, 18 Oct 2017 09:43:01 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id j126so9985361oib.8 for ; Wed, 18 Oct 2017 09:43:01 -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=RJiwIzgGneD5vM0SYSnJLpupisYAG1jCxgliEseoEPs=; b=gx0PXUG/S95Z6PPhls1z7b/212oe7C2bHViIyyiZS83hAp7zVVjf2/0bFusFjAYkB5 S/YfR7mr8Kc1tcHuBJFLWt4+BqWYNyGPFZuxsrc9V4sRxZrstqC51+VNbbSHS46aI4G2 zIAS/+XTM+yYmTtPdI/aEg66xd7ZZGOxGrEDhwls+k3TzwPrZH5HaCGWNIqWMp6LjCCY v9OtpV9OVK7vWX9VsBuzLQCrVdVTxHAtGC/gchmIuqlRFvj35Zm2LzjQNZvfqK4x1kCH nEgc97tC/hJJQT5yMwsVLvss7tuvVq/cjWC/IIVcIZBzG+R35BTge+ELvHIo7g5lUtVB yL+A== 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=RJiwIzgGneD5vM0SYSnJLpupisYAG1jCxgliEseoEPs=; b=rOfkJwqiFZN+QwcYXtpsNf1bX1QcyzSv1C0jsNY04XOERrBcG7phuCESe+VGQNXZnF KxEMvkrGWBYnkQYz4Vgm6c/4oWWYZe+cGQPYK3SIH2H8zLR1JSAgFYUeKpbcuWB3/Z9l pdjksnhm9NhwCbjG6nTmZZbh8Z6Bp+W5RXsqPTAozEqtDO0nBQIofBHnU0UVZ3QCaLQV Q0/bJDEZtXhasA8qldMic/iqJdaj3sMU/qdKpjNBFjTfXRVsUcPZAFxGnVK+wb4iSaC5 VG/Sf7Wh0bQlGs0KwwR9zQup3o9Tb06GQLYGT4HdHj5Yhy6/HR2QiH1JKwtcCD3uc2g/ CB1w== X-Gm-Message-State: AMCzsaVzLgIgx3lLKIPG/RhDf2n6thbsSqF3KS8xnWyJdNpd7A8XL3P4 Qh+ca2ZYiMnNn5DDSVOymcL8aEyhre68W4N+NB8= X-Google-Smtp-Source: ABhQp+Q9yFNKX5EuV/LuKJMQ2eOaWrL5GA0JBCr6zrKGLMBs/2pR5jWsibbukgDLwP21n3Ust/h5JzhSr0dTP/35DTY= X-Received: by 10.202.173.76 with SMTP id w73mr8618897oie.106.1508344980965; Wed, 18 Oct 2017 09:43:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.194 with HTTP; Wed, 18 Oct 2017 09:42:45 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Wed, 18 Oct 2017 12:42:45 -0400 Message-ID: To: R Parameswaran Cc: "trill@ietf.org" Content-Type: multipart/alternative; boundary="001a113cf020ca0f4d055bd4ee63" Archived-At: Subject: Re: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) 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: Wed, 18 Oct 2017 16:43:04 -0000 --001a113cf020ca0f4d055bd4ee63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ramkumar, On Wed, Oct 11, 2017 at 11:33 AM, R Parameswaran wrote: > Hi, > > I support the adoption/standardization of this draft, use case seems real= . > Informal review per request, comments: > Thanks for your support and thoughtful comments. > 1. Could probably use a text review prior to the next step. One or > two sentences can be tightened up: > > a. 2.2 item 3 ("The TLVs in an extensible Address Flush message are .. > ") > I think the existing sentence is correct but perhaps a bit hard to understand. It can be re-written to be a bit more clear. > b. typo in 2.2.8 (type =3D 8 vs 7 in figure). > Thanks for catching that. > 2. The draft gives a number of ways to specify an address flush e.g. > various ways specify vlans, FGLs and MAC addresses (e.g. lists > blocks, bitlists). Do we know if valid use cases for all these ways of > specifying a flush? Also, for block specifiers what happens if there > are overlapping blocks? > For overlapping blocks, the address flush message should be considered to be applicable to the data label or MAC address (depending on the type of block) if that data label or MAC address appears in any one or more blocks. This should be stated in the draft. The different formats are provided for efficiency of encoding. A block is most efficient if there are a number of consecutive values. A bit map is most efficient if there are scattered values within a limited range. And a list of single values if most efficient if there are widely scattered values. There does not seem to be a statement saying this in the draft so probably one should be added. > 3. With a TLV length of 8 bits you cannot really specify more than > 192 FGLs and 42 MAC addresses. Are multiple TLVs of the same type > allowed? Instead, would it make sense to have a longer TLV length > field of say 16 bits? > Yes, multiple TLVs of the same type are allowed and their is no ordering restriction on the TLVs. The draft is written to say what addresses are flushed based on the cumulative result of parsing the TLVs so there is no inherent difficulty in having multiple TLVs of the same type. But this should be explicitly stated for clarity. I think in most cases there will be one or a few blocks of VLANs/FGLs (or MACs if the optional ability to specify MAC addresses is implemented) and it would be rare to have large lists of explicit separate FGLs or MACs. And if you really do have a lot of widely scattered FGL/MAC values you want to specify, you are probably going to have to send multiple address flush messages anyway due to MTU limitations. So I think an 8 bit TLV length field is OK. > 4. It looks like a spoofed address flush can be used to mount a denial > of service attack. If that is protected by encryption or by perimeter > security, it might be good to explicitly call this out in Section 4, > Security Considerations. > Yes, that was meant to be implied by the comment about spoofed address flush messages reducing "network efficiency" but it should be more clearly stated. Also, the draft needs to make it clear that protection from forged/spoofed messages is obtained by requiring unsecured Address Flush messages to be ignored by receivers. 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 <(508)%20333-2270> (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > thanks, > Ramkumar > [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - > 10/16) > > Donald Eastlake Mon, 02 October 2017 23:11 UTCShow > header > > This begins a 2 week WG LC on draft-ietf-trill-address-flush-03.txt. > Please indicate if you think the draft is ready for publication and is > useful for TRILL deployments. > > Thanks, > Donald > (WG Secretary for the Chairs: Sue Hares & Jon Hudson) > =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 <(508)%20333-2270> (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > Replies: > > - [trill] =E7=AD=94=E5=A4=8D: Working group LC on draft-ietf-trill-add= ress-flush-03 > (10/2 - 10/16) > > zhangdacheng > > --001a113cf020ca0f4d055bd4ee63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ramkumar,

On Wed, Oct 11, 2017 at 11:33 AM, R Parameswaran <parameswaran.r7@gmail.com> wrote:
= Hi,

I support the adoption/standardization of this draft, use case seems = real.
Informal review per request, comments:

=C2=A0Thanks for your support and thoughtful comments.

1. Could probably use a text review prior to the next step.= One or
=C2=A0=C2=A0 two sentences can be tightened up:

=C2=A0=C2= =A0 a. 2.2 item 3 ("The TLVs in an extensible Address Flush message ar= e .. ")

I think the existing sentence= is correct but perhaps a bit hard to understand. It can be re-written to b= e a bit more clear.

=C2=A0=C2=A0 b. typo in 2.2.8 (type = =3D 8 vs 7 in figure).

Thanks for cat= ching that.=C2=A0

2. The draft gives a number of w= ays to specify an address flush e.g.
=C2=A0=C2=A0 various ways specify v= lans, FGLs and MAC addresses (e.g. lists
=C2=A0=C2=A0 blocks, bitlists).= Do we know if valid use cases for all these ways of
=C2=A0=C2=A0 speci= fying a flush? Also, for block specifiers what happens if there
=C2=A0= =C2=A0 are overlapping blocks?

For ove= rlapping blocks, the address flush message should be considered to be appli= cable to the data label or MAC address (depending on the type of block) if = that data label or MAC address appears in any one or more blocks. This shou= ld be stated in the draft.

The different formats a= re provided for efficiency of encoding. A block is most efficient if there = are a number of consecutive values. A bit map is most efficient if there ar= e scattered values within a limited range. And a list of single values if m= ost efficient if there are widely scattered values. There does not seem to = be a statement saying this in the draft so probably one should be added.

3. With a TLV length of 8 bits you cannot really spe= cify more than
=C2=A0=C2=A0 192 FGLs and 42 MAC addresses. Are multiple = TLVs of the same type
=C2=A0=C2=A0 allowed? Instead, would it make sense= to have a longer TLV length
=C2=A0=C2=A0 field of say 16 bits?

=
Yes, multiple TLVs of the same type are allow= ed and their is no ordering restriction on the TLVs. The draft is written t= o say what addresses are flushed based on the cumulative result of parsing = the TLVs so there is no inherent difficulty in having multiple TLVs of the = same type. But this should be explicitly stated for clarity.

=
I think in most cases there will be one or a few blocks of VLANs= /FGLs (or MACs if the optional ability to specify MAC addresses is implemen= ted) and it would be rare to have large lists of explicit separate FGLs or = MACs. And if you really do have a lot of widely scattered FGL/MAC values yo= u want to specify, you are probably going to have to send multiple address = flush messages anyway due to MTU limitations. So I think an 8 bit TLV lengt= h field is OK.

4. It looks like a spoofed address = flush can be used to mount a denial
=C2=A0=C2=A0 of service attack. If t= hat is protected by encryption or by perimeter
=C2=A0=C2=A0 security, it= might be good to explicitly call this out in Section 4,
=C2=A0=C2=A0 Se= curity Considerations.

Yes, that was meant= to be implied by the comment about spoofed address flush messages reducing= "network efficiency" but it should be more clearly stated. Also,= the draft needs to make it clear that protection from forged/spoofed messa= ges is obtained by requiring unsecured Address Flush messages to be ignored= by receivers.
=C2=A0
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 (c= ell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com=C2=A0
=

thanks,
Ramkumar

[trill] Working group LC on = draft-ietf-trill-address-flush-03 (10/2 - 10/16)

Donald Eastlake <d3e3e3@gmail.com><= /span> Mon, 02 October 2017 23= :11 UTCShow header

=20
=20 
This begins a 2 week WG LC on draft-i=
etf-trill-address-flush-03.txt.
Please indicate if you think the draft is ready for publication and is
useful for TRILL deployments.

Thanks,
Donald
(WG Secretary for the Chairs: Sue Hares & Jon Hudson)
=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 Stree=
t, Milford, MA 01757 USA
 d3e3e3@gmail.com
=20
=20
=20 =20 =20 =20 =20 =20 =20 =20

--001a113cf020ca0f4d055bd4ee63-- From nobody Wed Oct 18 11:57:35 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 91F97133059; Wed, 18 Oct 2017 11:57:27 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150835304752.12539.13265694411334120173@ietfa.amsl.com> Date: Wed, 18 Oct 2017 11:57:27 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-address-flush-04.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: Wed, 18 Oct 2017 18:57:28 -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 WG of the IETF. Title : TRILL: Address Flush Message Authors : Weiguo Hao Donald E. Eastlake Yizhou Li Mohammed Umair Filename : draft-ietf-trill-address-flush-04.txt Pages : 20 Date : 2017-10-18 Abstract: The TRILL (TRansparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local MAC addresses and edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and edge switch of attachment from the decapsulation of remotely sourced TRILL Data packets. This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets. This is a supplement to the TRILL automatic address forgetting and can assist in achieving more rapid convergence in case of topology or configuration change. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-address-flush-04 https://datatracker.ietf.org/doc/html/draft-ietf-trill-address-flush-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-address-flush-04 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 Wed Oct 18 12:12: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 70617132D49 for ; Wed, 18 Oct 2017 12:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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, 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 UKeeJyBD3AOA for ; Wed, 18 Oct 2017 12:12:41 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 688FB132F2E for ; Wed, 18 Oct 2017 12:12:41 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id h6so10737657oia.10 for ; Wed, 18 Oct 2017 12:12:41 -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; bh=iAYgQp6f22xv8n42nRu+1jVUn5HcuEh5e2yT0kxeiwA=; b=OKlO0GDtSUGbakOTm9kVjtnEtmzhOEBSYLo38jgJnc4zZkEsuJgzr1nfhaINF79KSK LQkobfqvQHWDJDFObsmGfux3o8YStNJjgO/+xbBq0kTVuuNh+HpRmdjJ+2wiU8fSIEN5 y+681Qol52cw1e1m2MPEgl38e7Sqt6Kxr842RCNdQmh8Gfzntn+W9zeexQc7IEjeB5OG cg1U9ZsnzR/Pa2VmaD6lID+Id7pI+TqDjzImvw1XhOzdPvi/emX7Cdg+fM6o4v0GCTfG edx5mjT9PONMEEmZfSsuC+JRsokocdCu+IImjrqOY33kGeFNUrDLqQC6Ru4l0ZiCOjHf P/XA== 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; bh=iAYgQp6f22xv8n42nRu+1jVUn5HcuEh5e2yT0kxeiwA=; b=aiGgGu5Z65jR+ple0xywmn3TSvaKuGr6jmUGJsLfpjglPIle3BMZ0Gm2mZ4Vg8+Aqm CGpT40/ERdIPNiKm9bdeGRDmX9ArVlUVG0dA+GR2JFPBDvVHYum8OfZH+QIO4Tl2u4QT MbtgHYWlkvbMLS7fRsL+XsqOzy9xTCIWxCK55GnFURR3WAj9myhlvlfC3vMipGmX/lwK HajcRysxeJ6YjTM4YFvVN3qTgmiqyw6UwRMqw0uuRS1D7pv334XnBDhHH8Ba9c9aCHdG WH6sqkB8QLiTwgWkFXfXjsFAzqXbQcr82EzMkSpU+RGu1Lf+IInBoajpuBf08sbapCQ4 /OMQ== X-Gm-Message-State: AMCzsaV5/v4sZVLjNgGZnHCLy7Wm36UItovh7tLu9eauuThCT17PGiiW sPf6VzCq4NIzaZ1+QBG9dWB/d/dYJNS9zOkj/Ux4Og== X-Google-Smtp-Source: ABhQp+Rmf1tOStpaHKaXwzKacs562uk2vdl/zKZlU0ROTdhz6znNPddGDkOXAfu5RDZaUy/mGr13f4qdFZIk3g2qgVo= X-Received: by 10.202.83.8 with SMTP id h8mr8688435oib.91.1508353960423; Wed, 18 Oct 2017 12:12:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.194 with HTTP; Wed, 18 Oct 2017 12:12:24 -0700 (PDT) In-Reply-To: <150835304752.12539.13265694411334120173@ietfa.amsl.com> References: <150835304752.12539.13265694411334120173@ietfa.amsl.com> From: Donald Eastlake Date: Wed, 18 Oct 2017 15:12:24 -0400 Message-ID: To: "trill@ietf.org" Content-Type: multipart/alternative; boundary="001a113d292a01b825055bd70667" Archived-At: Subject: Re: [trill] I-D Action: draft-ietf-trill-address-flush-04.txt 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: Wed, 18 Oct 2017 19:12:43 -0000 --001a113d292a01b825055bd70667 Content-Type: text/plain; charset="UTF-8" This revision is intended to resolve Ramkumar's comments. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Oct 18, 2017 at 2:57 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transparent Interconnection of Lots of > Links WG of the IETF. > > Title : TRILL: Address Flush Message > Authors : Weiguo Hao > Donald E. Eastlake > Yizhou Li > Mohammed Umair > Filename : draft-ietf-trill-address-flush-04.txt > Pages : 20 > Date : 2017-10-18 > > Abstract: > The TRILL (TRansparent Interconnection of Lots of Links) protocol, by > default, learns end station addresses from observing the data plane. > In particular, it learns local MAC addresses and edge switch port of > attachment from the receipt of local data frames and learns remote > MAC addresses and edge switch of attachment from the decapsulation of > remotely sourced TRILL Data packets. > > This document specifies a message by which a TRILL switch can > explicitly request other TRILL switches to flush certain MAC > reachability learned through the decapsulation of TRILL Data packets. > This is a supplement to the TRILL automatic address forgetting and > can assist in achieving more rapid convergence in case of topology or > configuration change. > > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-trill-address-flush-04 > https://datatracker.ietf.org/doc/html/draft-ietf-trill-address-flush-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-address-flush-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --001a113d292a01b825055bd70667 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This revision is intended to resolve Ramkumar's commen= ts.

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 Wed, Oct 18, 2017 at 2:57 PM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Transparent Interconnection of Lots of Lin= ks WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= TRILL: Address Flush Message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Weig= uo Hao
=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 Donald E. Eastlake
=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 Yizhou Li
=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 Mohammed Umair
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-trill-address-flush-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-18

Abstract:
=C2=A0 =C2=A0The TRILL (TRansparent Interconnection of Lots of Links) proto= col, by
=C2=A0 =C2=A0default, learns end station addresses from observing the data = plane.
=C2=A0 =C2=A0In particular, it learns local MAC addresses and edge switch p= ort of
=C2=A0 =C2=A0attachment from the receipt of local data frames and learns re= mote
=C2=A0 =C2=A0MAC addresses and edge switch of attachment from the decapsula= tion of
=C2=A0 =C2=A0remotely sourced TRILL Data packets.

=C2=A0 =C2=A0This document specifies a message by which a TRILL switch can<= br> =C2=A0 =C2=A0explicitly request other TRILL switches to flush certain MAC =C2=A0 =C2=A0reachability learned through the decapsulation of TRILL Data p= ackets.
=C2=A0 =C2=A0This is a supplement to the TRILL automatic address forgetting= and
=C2=A0 =C2=A0can assist in achieving more rapid convergence in case of topo= logy or
=C2=A0 =C2=A0configuration change.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-trill-address-flush/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-trill-address-flush-04
https://datatracker.ietf.org/= doc/html/draft-ietf-trill-address-flush-04

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


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

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

_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

--001a113d292a01b825055bd70667-- From nobody Thu Oct 19 07:34: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 39326134696; Thu, 19 Oct 2017 07:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 e9aDRkb_HEzo; Thu, 19 Oct 2017 07:34:02 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6D7132D79; Thu, 19 Oct 2017 07:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+0g6E6WWzRrdE6OUvEwIqgRk2v2/3k3gUhpn/EfxBzw=; b=Qni1FaI3RTEJDzwhR6HTu+aL4HreRr2NJ+MzXko4LB6LFR9+qsRs5NGxGqpjiWhBlyewXwnbVlJ2ZCV7Li9TA1bW0eBqpF88ElhqgNGx/BwEmFBQN+CiEgKTv46KBXsbay0Ox1zgLdc5iYC5eO+cKMa9tN5jp6N1ABEh5n9lVpM= Received: from [172.29.67.174] (193.110.55.12) by BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 19 Oct 2017 14:33:55 +0000 From: John Scudder Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 19 Oct 2017 17:33:46 +0300 Cc: draft-ietf-idr-ls-trill@ietf.org, trill@ietf.org To: "idr@ietf. org" X-Mailer: Apple Mail (2.3273) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: AM0PR0202CA0032.eurprd02.prod.outlook.com (52.133.32.173) To BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7ea138bd-5879-4093-98fd-08d516fe6e2a X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254163)(48565401081)(4534011)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229)(201703131423086); SRVR:BN3PR05MB2499; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 3:ehvlKyAconbM/5ehh1G7rt69XMISYw2P2K4W+Sw4JfjEwcGnLWsvp/ZVYZ1HmxIGJJ+YZuSK5oo08DtTy3vt4QFNUTT3BsHLf6F37Ea5KHKcrXDuc+/Zs8bS2qqo52S89jUFBPbUvIxvr2YK2aX3NXONvOYXlnNCNZKsXdreMJ5oEl5L0OWdvIwWgxdx7/ZL62CAGnuXv7+YerH4fgE5ljbTDcsTo3jknvZhVclyXU3zqeqiDbsqWV1fDK/uUIO3; 25:GjRi+vf44gzZ7O6T0p3SFUoY8OAmrxR4GrW20s9r/qlUyHIv4Jk3UGcQIWy3nbRjhO/dkck3JK9/J5FqWI5DTiYRiZiPEfsqJBuT7+jYfgaNyGgwgUZX6e4yuOcV4U4Y4GSS7jqsh0cPH7QlokGg/g9X16Fjo96QGuZ76/+WXScHEh1C45lOCV9c6qjw8yxhLe2F/cVJ67b4J7gBn6WTM8UQI8NJf1wB68SAwmu5Eh01jkNi6FfFGdSTvUJXhvliT7g1d80HcMsBT1eIxQ3WteKrTan/uCSUvPxmaBhgZYujJxTD9SLg8YOPZFes5wDRXh9Q/zE4rhAkT8SDlSbIXQ==; 31:CafI9C57Zm9usP7zaY2cCOYAiHltjd0epGMRgRtNKfEnq96QLWIVh6ALHwAS3odTSJN2W/lgEW1ZBweJo6V+C2ot0MXMhqT7cc2meY+FpM0lJYNDV6Qq6Qxn/174f8A2SJza6Gzvio4QvlZZk1xrDcHpe/7LbNXUVCkVcn10Y+af9CfwOVm5XqAd7F4MoQjtRNLvt1Qv3PXTvlKIkuDFuLTnoM14L0XdzwYTB95JbKQ= X-MS-TrafficTypeDiagnostic: BN3PR05MB2499: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 20:f4u9iJR9VnrvR13ihRZImc7BIZboIqVuId1Qjm+vkP3yNnuPd+1GmFGRbWRZiJ+NKDed73md9EZLjAyWWd3Gp2CfTUeS3rYrKH9JdFgqyc+eP6ZRo66dBiU3znJLn1TPV2DpXUloNh9ORUoOlBu8YW6ZgK/psU+gMAL6KFHKfgeX6eVEqnxsBW2Ze+yUReW8iL5BnxCR4XAy/UB87xu0frk78bcFvO+JgGY7USFHmHvznpoqyAZWN82lmcTpYCpYw2zFscgZrpMsXUNZdNYMKC7vLirsVX5jnzJqcaIEHuJaPLIsKceMJjwo8+HNGRTvoTXGpcBDtP0dyZkeFGWkTYkkje5LIrvoAI2wmgUSRv+ZW01M2iY1wjdTX07J+zsfi6ynB/4Jm1IjQYqIUxFZ22ns+ICnhOr5tPNur7ek+lKnijsxarMrLYIKU0LI7odeymNgpJYqVZMXC3jNHRRY9xN5rtbWy4iFP1FNjDSu+8cv37FWdCuAlD5whnjgIkJP; 4:/men4eab2NLNn2ozLUmI7/0KDfkGvVd+b54w6+0uIsYA8gGMkd/nuH7NKlPR6wYzvWCwd65P+rHgexbKUyoVU9HCaVjPlkTRdGbD6ufB2oXFICqDSVsUvxPFSV5CaYjbo59ijKsa8RTig0SRvlijrPU0IviLrGLO0qrScK0uE0axITVfihBFBHfpalKnNM2WqHbpiWWvpunAkItvvN42+yumhSarj7hJCkXXE4Ag3TDrdMOUz8wYGlD3kG3zBKpf X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2499; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2499; X-Forefront-PRVS: 0465429B7F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(346002)(376002)(39860400002)(53754006)(199003)(189002)(81166006)(5660300001)(66066001)(966005)(316002)(16576012)(4326008)(2906002)(97736004)(81156014)(83716003)(450100002)(6916009)(77096006)(8676002)(6486002)(16526018)(478600001)(86362001)(47776003)(8746002)(8936002)(90366009)(25786009)(230783001)(50226002)(33656002)(82746002)(101416001)(50466002)(50986999)(6666003)(36756003)(57306001)(3846002)(6116002)(23726003)(68736007)(7736002)(105586002)(106356001)(189998001)(305945005)(53936002)(6306002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2499; H:[172.29.67.174]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2499; 23:S/HpsqhvaaxDFOvRQ7TU1BtcxIW3Tah/iNUEARz2b?= =?us-ascii?Q?fGhq4euv5o2t0xEZqQ+m4KBXSUdhjD8GgqVJcJ92iQom9UYyJiOY1ZI+ZqES?= =?us-ascii?Q?uPnxdmH5rSBQp1VFU3g12aQyebKjSoYX5hgzjTMF/+Ms6r99VAES5WD6IRZR?= =?us-ascii?Q?+DhMOrzfvWYmZSaRitWvmfBM4/wLbS9bkU9abkCZM6bbDcD7nIiC9N4RCu9L?= =?us-ascii?Q?IpqDiCuUCCq9dBDuJ7wxdBjxRHIfeXklnfTofEg+5o+2u50Y5ayxDfhc1Xz4?= =?us-ascii?Q?B0WBBcvVF92O3En39ZYpKo0E74S+FcT/miGHzXXFyp/qR9q84hX1+6IzVGB9?= =?us-ascii?Q?UenA/VzZpLdvg1lFP0Tqi4BwvF9irvbfzxNSs0G31fsRtZio1qjHCRIFf6g4?= =?us-ascii?Q?8DeXv9FqkCzWh3LPinuSlVMzM2tH9CBAA44crN7eHKvZsmETLEkhfwH6s1cx?= =?us-ascii?Q?RcWZbdUXEwEYAjEiJWAWw5ooZ0QIrvH9gpwxcM+iCTwj2W+PufgENPtx56ED?= =?us-ascii?Q?AQLYvwqf9VoAMKKicQ7f4/ilU+SvyadhC0V1mUlVViihr5pHo0tJ4IbbsVAi?= =?us-ascii?Q?A21IEFZoAlImAwIzEiyyCBeubalakzYDQxO9WsT9CL8kxrmpYB2FsxVrIJNG?= =?us-ascii?Q?98Im9OPkA71yhpKjI+qlsw37GsnQ6BOMMOsqGLJbcZvi6eYy56P0VHn1u1qT?= =?us-ascii?Q?KpbRUe275ArIQnHfg22GqmxwcpU+z3Z0Dv1wvb0IHIAcV44MnPBJuvG45T2X?= =?us-ascii?Q?Dv92LD0C21HdLrAlPDL7vY4718DftuUZF+tODLrG/sb/IkI4xVJPx+yagJLd?= =?us-ascii?Q?aUQDo5V58D+t1jvAatJo2Qqbx1zgcag815nlFV90nIWypszwdMWMHg/gwwlI?= =?us-ascii?Q?GuZQOHiWUSxZ2Ixl+94Vh/QRnGJHrOXnY3BBqDPZR0WZq/wmN5pipr8C741k?= =?us-ascii?Q?MKEs0tims+oEIE7w7ekqpyoFymiLveRJ/W5ZGyuOSynhqkO/X3kV+gPJJjxk?= =?us-ascii?Q?+ULiyIkpCzybz9H0xRmkLWQGOvDZ4ToKglsIvXwrhGTcrbIHyAgCbE1tqqxn?= =?us-ascii?Q?7SKPiG2sWLtAmVsQ9xenpbXlcrjTHnZrcA5xE5zh1RU5gJSHAw9GKARxTgZn?= =?us-ascii?Q?Ye1nP/lJMBijLSJSGFPesNgOPy2ddGaQlX99VACTW3lhuVC35QgG8dwop3V3?= =?us-ascii?Q?eZHgPHQRpfZWj40cqYm1W6piaHYZN/n9NPOGkBSOEC23znqY5jvIFbpFtCRY?= =?us-ascii?Q?3Ot4YHTLlJP3LQ4wpo=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 6:I0uVMxPdXqc+Xofg0uYRyCfJNU5+Wh3y1MZ0MDsazfJTU4KA+E/UkaZPEyRySEhNztnK+u+0zGxIm6Yls97zChdzw8gGs5zNQjKcCza3WroIVIiJsAHIYS1iAqoY8vKvLfxX8GKdgngU/NdbOvFN0LGO41wt6IEj/DhBFzzzVk2BKfjGPTjcZgyAyYeHW3gF841QW6amKVF0Eh4814XYXuGgWmu0bswZApCgAFQv/DeGnsGTR498F0a1Ts7Xom1YgtXQ8c8FyIKPP5BfE6jql3tp4Q2zrtp8eaV2AZ9GkHmDIPShDFhOtUE+UcRuO+UgeFz/917F2JPsgIS3ljlH8g==; 5:d8WoGIu5rYvCwqKBCk1QQMOnrYo9u3yWNIG7Xz6NYMxoxc0qseAxtdxkFou+53DEn4FZqGVyPRGXQlWBOwi/P61YO77giSPLKVCITVI5H7nYht96vwOsvb5cohxqlKFN1WOP7FB9+w59cWwTF2GNjg==; 24:bhwRP7GbAteHHU7w8mON5aj1HL+L1RC/vLs8Fjrkqi9wgMIGc/yVTo1BR7ZEAwF1nEYE+6cpUPI0lFAJ0iBZq4wLfxjcVNMHHmmX5KjAlKo=; 7:4WaZMnICW/j9eXM0UjutH/DYWTqjVYnPGyP++NcY/Mm8GDXMnK0z5Fs9CWQ5VG+TkAOtXN64o+8jZ4zSDuvWtHzSyUE/+c8EJwQCOsehgqMfNa6NuJOIAqy3YKkxl6IGCyXmrfXqvs2rGMGAx9Oa1FWKdcJ4kUMn494oPyq3AYUGWE23UQg31AGTFsaG0PiJ/gvp5O3YA5xQz9FYxk+gdy1I6gpT61aLegpluG7+FII= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2017 14:33:55.8739 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7ea138bd-5879-4093-98fd-08d516fe6e2a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2499 Archived-At: Subject: [trill] WGLC for draft-ietf-idr-ls-trill-03 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, 19 Oct 2017 14:34:04 -0000 Hi All, An IDR working group last call has been requested for = draft-ietf-idr-ls-trill-03. Please reply to the list with your comments. = As usual note we cannot advance the draft without participation from the = group. Please get your comments in before November 3, 2017. Authors, please confirm that any relevant IPR has been disclosed.=20 https://tools.ietf.org/html/draft-ietf-idr-ls-trill-03 Thanks, --John From nobody Thu Oct 19 08:08:10 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 E1537134944; Thu, 19 Oct 2017 08:08:02 -0700 (PDT) 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, 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 81V6g7oxYRpL; Thu, 19 Oct 2017 08:08:01 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 7D077134941; Thu, 19 Oct 2017 08:08:01 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id h200so15401978oib.4; Thu, 19 Oct 2017 08:08:01 -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=5EvO6s0CfJpS1jCXP7mrXNwzDK8pf3Tc3Db9yTPFT0A=; b=qO8x0ln0OA4VoPC115P/YUTdaPEJoQbPt83BU/oT3GN/JuOqWsh1UI8ZwNjfzV47Qw wrDopr1vRQNg+mYHmfwBKfotlJU698dAMtYSfuM3tY64QNxsdX8ygwwtY+KqpOZ3691x H4xRrR6i5Jk2FVL5Q2eQPJoCrLCGMIkzpbadYeebZKgoKVN49R/B2HwEaBtNAFMqngmP VTRxNuuQD2MN3Erlqhzzg8M76pySkC0wr4NK85LIHUHAMM5KZswcHTysutVOFR8dfqy8 mR+4RfRJyqxUpJ8N7w5J6Dvoh4wKj3oqoREfYq07417g9Pqb9ng5HtytApcT1QXESyAI h4Ig== 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=5EvO6s0CfJpS1jCXP7mrXNwzDK8pf3Tc3Db9yTPFT0A=; b=oRc273uc0oRVIvR0PKqJr4sa5eVUIuz626iLeeCnANqBj+hADZMhEZPMNRELDWYo8D BdoodN7GZKdd8CZR5CvnTDUl64PAIGz0QGssbDEB5SWMVATKI7gS4WwQKf1mfIQ55YTm wo6dCmXhYuOWpR0h2H+0QS5rheAVYbunLlTX1Z4PI3A+d88CfD1rmLrZPCRveLXnn/xP O2nRmLwccBAnSw/D1Rbea+bLi7PaY0BjnFos5OQ4xT08d/GqBpHzGJwGrKo3+Y5Tkxsb 9GeuCTmb26j7ceclT9dClF7DI0MTCOYd2jVayMNBg/kjHGDBrw2SNnWgRAJGhBPbpSxy FSjA== X-Gm-Message-State: AMCzsaWSP/UzhliWbnuwR7bTnn1J4PKWWFTv7xHyoWQQjwFNLds1xOI5 bAUYhjLBXQ3XYsJHqSEfg/QgMCfxKiGunvJVCq0= X-Google-Smtp-Source: ABhQp+R1k6KWztYP9vZ92RlR//Ke05e8w3XcndEe0BhZ408PtYnPPt+kErPtP+7oITHrWEkhUdIp+S/zqejMdV5Hyd8= X-Received: by 10.202.11.3 with SMTP id 3mr1061145oil.125.1508425680860; Thu, 19 Oct 2017 08:08:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.194 with HTTP; Thu, 19 Oct 2017 08:07:45 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 19 Oct 2017 11:07:45 -0400 Message-ID: To: John Scudder Cc: "idr@ietf. org" , draft-ietf-idr-ls-trill@ietf.org, "trill@ietf.org" Content-Type: multipart/alternative; boundary="089e0824839ce0ba3a055be7b80d" Archived-At: Subject: Re: [trill] WGLC for draft-ietf-idr-ls-trill-03 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, 19 Oct 2017 15:08:03 -0000 --089e0824839ce0ba3a055be7b80d Content-Type: text/plain; charset="UTF-8" I support this draft as an author. I am not aware of any IPR in this draft that needs to be declared. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Oct 19, 2017 at 10:33 AM, John Scudder wrote: > Hi All, > > An IDR working group last call has been requested for > draft-ietf-idr-ls-trill-03. Please reply to the list with your comments. As > usual note we cannot advance the draft without participation from the > group. Please get your comments in before November 3, 2017. > > Authors, please confirm that any relevant IPR has been disclosed. > > https://tools.ietf.org/html/draft-ietf-idr-ls-trill-03 > > Thanks, > > --John > --089e0824839ce0ba3a055be7b80d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support this draft as an author.

I am= not aware of any IPR in this draft that needs to be declared.
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 Be= aver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Thu, Oct 19, 2017 at 10:33 AM, John Scudd= er <jgs@juniper.net> wrote:
= Hi All,

An IDR working group last call has been requested for draft-ietf-idr-ls-tri= ll-03. Please reply to the list with your comments. As usual note we cannot= advance the draft without participation from the group. Please get your co= mments in before November 3, 2017.

Authors, please confirm that any relevant IPR has been disclosed.

https://tools.ietf.org/html/draft-ietf-id= r-ls-trill-03

Thanks,

--John

--089e0824839ce0ba3a055be7b80d-- From nobody Thu Oct 19 18:06:37 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 AB4CE1321D8; Thu, 19 Oct 2017 18:06:16 -0700 (PDT) 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, 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 T3JJCleiqS4f; Thu, 19 Oct 2017 18:06:10 -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 44EE11330B0; Thu, 19 Oct 2017 18:06:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQZ23504; Fri, 20 Oct 2017 01:06:07 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 20 Oct 2017 02:06:07 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.105]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 20 Oct 2017 09:06:02 +0800 From: Haoweiguo To: Donald Eastlake , John Scudder CC: "idr@ietf. org" , "draft-ietf-idr-ls-trill@ietf.org" , "trill@ietf.org" Thread-Topic: WGLC for draft-ietf-idr-ls-trill-03 Thread-Index: AdNJP4gJKQ2xxq0aTfujfKBXAh7tuQ== Date: Fri, 20 Oct 2017 01:06:02 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.30.193] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB55173366101C75nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59E94BFF.0135, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4023dbb5b40f996f186488dae39e6a9d Archived-At: Subject: Re: [trill] WGLC for draft-ietf-idr-ls-trill-03 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: Fri, 20 Oct 2017 01:06:16 -0000 --_000_DD5FC8DE455C3348B94340C0AB55173366101C75nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIHN1cHBvcnQgdGhpcyBkcmFmdCBhcyBhbiBjby1hdXRob3IuDQoNCkkgYW0gbm90IGF3 YXJlIG9mIGFueSBJUFIgaW4gdGhpcyBkcmFmdCB0aGF0IG5lZWRzIHRvIGJlIGRlY2xhcmVkLg0K DQpUaGFua3MsDQpXZWlndW8NCg0KDQrlj5Hku7bkuro6IERvbmFsZCBFYXN0bGFrZSBbbWFpbHRv OmQzZTNlM0BnbWFpbC5jb21dDQrlj5HpgIHml7bpl7Q6IDE5IHVNZnVtZnUgMjAxNyAxMTowOCBQ TQ0K5pS25Lu25Lq6OiBKb2huIFNjdWRkZXIgPGpnc0BqdW5pcGVyLm5ldD4NCuaKhOmAgTogaWRy QGlldGYuIG9yZyA8aWRyQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1pZHItbHMtdHJpbGxAaWV0Zi5v cmc7IHRyaWxsQGlldGYub3JnDQrkuLvpopg6IFJlOiBXR0xDIGZvciBkcmFmdC1pZXRmLWlkci1s cy10cmlsbC0wMw0KDQpJIHN1cHBvcnQgdGhpcyBkcmFmdCBhcyBhbiBhdXRob3IuDQoNCkkgYW0g bm90IGF3YXJlIG9mIGFueSBJUFIgaW4gdGhpcyBkcmFmdCB0aGF0IG5lZWRzIHRvIGJlIGRlY2xh cmVkLg0KDQpUaGFua3MsDQpEb25hbGQNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N CiBEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMzMy0yMjcwIChjZWxsKQ0KIDE1NSBC ZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0ENCiBkM2UzZTNAZ21haWwuY29tPG1h aWx0bzpkM2UzZTNAZ21haWwuY29tPg0KDQpPbiBUaHUsIE9jdCAxOSwgMjAxNyBhdCAxMDozMyBB TSwgSm9obiBTY3VkZGVyIDxqZ3NAanVuaXBlci5uZXQ8bWFpbHRvOmpnc0BqdW5pcGVyLm5ldD4+ IHdyb3RlOg0KSGkgQWxsLA0KDQpBbiBJRFIgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJl ZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1pZXRmLWlkci1scy10cmlsbC0wMy4gUGxlYXNlIHJlcGx5 IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cy4gQXMgdXN1YWwgbm90ZSB3ZSBjYW5ub3Qg YWR2YW5jZSB0aGUgZHJhZnQgd2l0aG91dCBwYXJ0aWNpcGF0aW9uIGZyb20gdGhlIGdyb3VwLiBQ bGVhc2UgZ2V0IHlvdXIgY29tbWVudHMgaW4gYmVmb3JlIE5vdmVtYmVyIDMsIDIwMTcuDQoNCkF1 dGhvcnMsIHBsZWFzZSBjb25maXJtIHRoYXQgYW55IHJlbGV2YW50IElQUiBoYXMgYmVlbiBkaXNj bG9zZWQuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1scy10 cmlsbC0wMw0KDQpUaGFua3MsDQoNCi0tSm9obg0KDQo= --_000_DD5FC8DE455C3348B94340C0AB55173366101C75nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+SSBhbHNvIHN1cHBvcnQgdGhpcyBkcmFmdCBhcyBhbiBjby1hdXRo b3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGluIHRoaXMg ZHJhZnQgdGhhdCBuZWVkcyB0byBiZSBkZWNsYXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5r cyw8YnI+DQpXZWlndW88YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IERvbmFsZCBFYXN0bGFrZSBb bWFpbHRvOmQzZTNlM0BnbWFpbC5jb21dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWYiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gMTkgdU1mdW1mdSAyMDE3IDExOjA4 IFBNPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7mlLbku7bkuro8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZiI+IEpvaG4gU2N1ZGRlciAmbHQ7amdzQGp1bmlwZXIubmV0Jmd0Ozxicj4NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBpZHJAaWV0 Zi4gb3JnICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRmLWlkci1scy10cmlsbEBpZXRm Lm9yZzsgdHJpbGxAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYi PuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmIj4gUmU6IFdHTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLXRy aWxsLTAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBzdXBwb3J0IHRoaXMgZHJhZnQgYXMg YW4gYXV0aG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0g bm90IGF3YXJlIG9mIGFueSBJUFIgaW4gdGhpcyBkcmFmdCB0aGF0IG5lZWRzIHRvIGJlIGRlY2xh cmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGFua3MsPGJyPg0KRG9uYWxkPGJyPg0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4NCiZuYnNwO0RvbmFsZCBFLiBFYXN0bGFrZSAzcmQgJm5ic3A7ICYjNDM7 MS01MDgtMzMzLTIyNzAgKGNlbGwpPGJyPg0KJm5ic3A7MTU1IEJlYXZlciBTdHJlZXQsIE1pbGZv cmQsIE1BIDAxNzU3IFVTQTxicj4NCiZuYnNwOzxhIGhyZWY9Im1haWx0bzpkM2UzZTNAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZDNlM2UzQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBPY3QgMTksIDIwMTcgYXQgMTA6MzMg QU0sIEpvaG4gU2N1ZGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpnc0BqdW5pcGVyLm5ldCIgdGFy Z2V0PSJfYmxhbmsiPmpnc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SGkgQWxsLDxicj4NCjxicj4NCkFuIElEUiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBo YXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLXRyaWxsLTAzLiBQbGVhc2Ug cmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLiBBcyB1c3VhbCBub3RlIHdlIGNh bm5vdCBhZHZhbmNlIHRoZSBkcmFmdCB3aXRob3V0IHBhcnRpY2lwYXRpb24gZnJvbSB0aGUgZ3Jv dXAuIFBsZWFzZSBnZXQgeW91ciBjb21tZW50cyBpbiBiZWZvcmUgTm92ZW1iZXIgMywgMjAxNy48 YnI+DQo8YnI+DQpBdXRob3JzLCBwbGVhc2UgY29uZmlybSB0aGF0IGFueSByZWxldmFudCBJUFIg aGFzIGJlZW4gZGlzY2xvc2VkLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1scy10cmlsbC0wMyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1scy10cmlsbC0wMzwvYT48 YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KLS1Kb2huPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DD5FC8DE455C3348B94340C0AB55173366101C75nkgeml513mbxchi_-- From nobody Thu Oct 19 19:29:43 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 D1395132153 for ; Thu, 19 Oct 2017 19:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral (2048-bit key) reason="invalid (public key: syntax error)" header.d=ipinfusion.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 OfEBuMTHEP48 for ; Thu, 19 Oct 2017 19:29:35 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 71005132EA7 for ; Thu, 19 Oct 2017 19:29:33 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id o44so10062351wrf.11 for ; Thu, 19 Oct 2017 19:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipinfusion.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=pyOglLd2dAD+5wTCf4dGEP4Zdb/5KVQuaEd9k1OAXuo=; b=gkDYAVxdbwTeO1BFHKpl4U54iEkzjCvV3qpRs99l9/OBz+Va2jaAGyRUSAiH8pPYp4 Va1M+/G66VA+Hi5O2EvSoeKwkpU2BWAfwlUb08nRch9pbQG7DtGoztWc44BN2nfGIWfc Lq1tzahAPmAuZ4bT2S9sADH5RWrKnDukr1fJAu/oxIhzO5OUsxPRwEPD/KfDgo/KcEAi cKRPmdJ4lOa+F0+1XIuVG/cIBGZE+F463F3ZmV2bxQlhfNJxkHbWliVLpByPeyZB4B8+ EBac+FHOJZ7aCF3RqTPG36eB/m/IXQN8pnV6HfuJqCINrxcQbrlMmei3goctCgbxgGNu Olfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=pyOglLd2dAD+5wTCf4dGEP4Zdb/5KVQuaEd9k1OAXuo=; b=lVjXx4dk4trP45CEziyl0JYni2iF+2JfVv9LK7zhKnkT9i+yPKEJWcGUer70VgZtX7 Ztsgr2rqTWuJdNZbnYvJXY1shpt2zwXmtAW7A2RSwXerg5aWS+8ptnM8UOspkS/bnq8G tz6GEs/NHg2VON94hi+alqPXAm7mhct3tKK4c0DeAG1AGIzndqufYsvrS8xgrdOxRfF6 A4D9mjXzan9928E7A/EegPSUfYVz338LFzABhF4soAGm8E03w/gCKtJ1fg2Vy2+8aery jC6ADMAXXZe4tPdVFGp828qrjE5/MG5t1gvLGgXE+ajrDRnBYiI88TE9D9W5u4cnl3vb VdnQ== X-Gm-Message-State: AMCzsaXWuxsP2TadXbAeeH+Ddjwcv4WF6yqu2Q+zvUhBW7GDRhR0AHNo 9biLb/+nC9uQ/w7VIwgpS5TdkuZ5Ku+Xo2Ji/n3679jzserS0zOBzXxY++m/L+NU9lNqx6RqELT ZQMMBAnHc6aiOF8314SxbWa/j6zyIZLzlDj1vJv6ubHj0tB67AGAbHb5kA/xBUtOcF3SDPWRjTb HQRcJxxkT58grHIAmx1T6J X-Google-Smtp-Source: ABhQp+SK+GCKseB+0+v8K7yssD6ebAqZ7L1Wv7q9LQDakrNqmCE7vXBsakg28JS2vEF/Su4qjvseW8QJL9kxbkfK8mg= X-Received: by 10.223.167.76 with SMTP id e12mr2910609wrd.259.1508466571868; Thu, 19 Oct 2017 19:29:31 -0700 (PDT) From: Sujay Gupta References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGw0Z8DhRupT5RyFwlASEG+AhlrVqMw8ykA Date: Fri, 20 Oct 2017 07:59:29 +0530 Message-ID: To: Haoweiguo , Donald Eastlake , John Scudder Cc: "idr@ietf. org" , draft-ietf-idr-ls-trill@ietf.org, trill@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1cd1002c15ed055bf13e70" Archived-At: Subject: Re: [trill] WGLC for draft-ietf-idr-ls-trill-03 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: Fri, 20 Oct 2017 02:29:37 -0000 --94eb2c1cd1002c15ed055bf13e70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support this draft and have no known IPR related to it. Regards -Sujay *From:* Haoweiguo [mailto:haoweiguo@huawei.com] *Sent:* Friday, October 20, 2017 6:36 AM *To:* Donald Eastlake ; John Scudder *Cc:* idr@ietf. org ; draft-ietf-idr-ls-trill@ietf.org; trill@ietf.org *Subject:* Re: WGLC for draft-ietf-idr-ls-trill-03 I also support this draft as an co-author. I am not aware of any IPR in this draft that needs to be declared. Thanks, Weiguo *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* Donald Eastlake [mailto:d3e3e3@gmail.com <= d3e3e3@gmail.com>] *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 19 uMfumfu 2017 11:08 PM *=E6=94=B6=E4=BB=B6=E4=BA=BA:* John Scudder *=E6=8A=84=E9=80=81:* idr@ietf. org ; draft-ietf-idr-ls-trill= @ietf.org; trill@ietf.org *=E4=B8=BB=E9=A2=98:* Re: WGLC for draft-ietf-idr-ls-trill-03 I support this draft as an author. I am not aware of any IPR in this draft that needs to be declared. 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 Thu, Oct 19, 2017 at 10:33 AM, John Scudder wrote: Hi All, An IDR working group last call has been requested for draft-ietf-idr-ls-trill-03. Please reply to the list with your comments. As usual note we cannot advance the draft without participation from the group. Please get your comments in before November 3, 2017. Authors, please confirm that any relevant IPR has been disclosed. https://tools.ietf.org/html/draft-ietf-idr-ls-trill-03 Thanks, --John --=20 . --94eb2c1cd1002c15ed055bf13e70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I support this draft and hav= e no known IPR related to it.

=C2=A0

Regards

-S= ujay

=C2=A0

From: Haoweiguo [mailto:haoweiguo@huawei.com]
Sent: Friday, O= ctober 20, 2017 6:36 AM
To: Donald Eastlake <d3e3e3@gmail.com>; John Scudder <jgs@juniper.net>
Cc: idr@ietf. org &= lt;idr@ietf.org>; draft-ietf-idr-ls-trill@ietf.org; trill@ietf.org
Subject: Re: WG= LC for draft-ietf-idr-ls-trill-03

=C2=A0

I also support this draft as an co-author.

=C2=A0

I am not aware of= any IPR in this draft that needs to be declared.

=C2=A0

Thanks,
Weiguo

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA:<= /span> Donald Eastlake [ma= ilto:d3e3e3@gmail.com]
=E5=8F=91=E9=80=81= =E6=97=B6=E9=97=B4: 19 uMfumfu 2017 11:08 PM
=E6=94=B6=E4=BB=B6=E4=BA=BA: John Scudder <jgs@juniper.net>
=E6=8A=84=E9=80=81: idr@ietf. org <idr@ietf.org>; draft-ietf-idr-ls-trill@ietf.org; trill@ietf.org
=E4=B8=BB=E9=A2=98:= Re: WGLC for draft-ietf-idr-ls-trill-03

=C2=A0

I support this d= raft as an author.

=C2=A0

I am not aware of any IPR in th= is draft that needs to be declared.

=C2=A0

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

=C2=A0

On Thu, Oct 19, 2017 at 10:33 AM, J= ohn Scudder <jgs@ju= niper.net> wrote:

Hi All,

An IDR working group= last call has been requested for draft-ietf-idr-ls-trill-03. Please reply = to the list with your comments. As usual note we cannot advance the draft w= ithout participation from the group. Please get your comments in before Nov= ember 3, 2017.

Authors, please confirm that any relevant IPR has bee= n disclosed.

https://tools.ietf.org/html/draft-ietf-idr-ls= -trill-03

Thanks,

--John

=C2=A0


. --94eb2c1cd1002c15ed055bf13e70-- From nobody Fri Oct 20 06:52:49 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 DA97F1286C7 for ; Fri, 20 Oct 2017 06:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Pza-MNYGXe9V for ; Fri, 20 Oct 2017 06:52:46 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 7454D1270AE for ; Fri, 20 Oct 2017 06:52:46 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id n38so8348424uai.11 for ; Fri, 20 Oct 2017 06:52:46 -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=GfAcTKLRj2wTnEJfLlaDqqm/wU8T+JXoe53FhGKjTiw=; b=jnljGzt2Bfd1HanYysTfXtQNzuuetPCzbov/vdKvoegtxxuIvFMBfD9QxF/lHQ0N4y smRB4Pw5Lu6SQd2wTeVIgDpqofkuGfvVXU0fKIke4cH1oCUVvexL1WJlO5zsQOHyGxYn dTomkY3MBnRPnJWZNmO8DcvvS4UpEmVp8iz08oo6eHc1XDAKxyjjBDRu6QmGxaieeGG3 Xb0Wgpi99l6XMx09QEk500y8EUppZ9g22YoXGe9Jkj3rqiEikGwK9u2KYw8AY8JQDAhw qEsasCRPk10D9VoparDfHPfIHUkfAvPjfD22eAdpZQHrw0Hngns04J18P5vOWks52aa+ J3NQ== 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=GfAcTKLRj2wTnEJfLlaDqqm/wU8T+JXoe53FhGKjTiw=; b=WwNuIPqNrjoUakwUzMLxlc4Y/VE7wbwwu+FMTQ+xZChfkoezliwsg9fZ/lu/wjGASE hyCH83vmhyOJHzOxqGbgytvLvyrI2r4TbHG6rnxkHUYjzohXtd1xnasHGw5Lfne5sLNW v7GePjkZjif7+ixbvKyYzHdJ4GINaxqrf1DwCFZBKz1uHzQGu2UOhWoRrxsly5TsII05 1+/J9DpQu4nGPKbZym6CZ7TyCUmdB6JmHCGZnPODcyOEhLHQ7IRr7XE1L2b9VYQdKojf ck7leT14/LzJRP7VC9qf/YKgcvrqCWeq6WHV8GptO/K+W/hP+w/N/NYxiR85mBkyCABp vZVQ== X-Gm-Message-State: AMCzsaUveOiw539csQi/p8g0zo9CIZsQ6gS2jKOFiv89LN6X2snx/v2q QdfApfWwaISngA908TsqgxJGFVL10UdwuRHglH0= X-Google-Smtp-Source: ABhQp+T5O9zvOcl9bcWQmuMJ6yPIBJbtpff97i1AxZuNLj0b+LhnUyiQoa2YSE2zMyMEq+J9aTd7wBlSP3UAdg5w+aY= X-Received: by 10.176.18.70 with SMTP id s6mr3910582uac.8.1508507565352; Fri, 20 Oct 2017 06:52:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.16.158 with HTTP; Fri, 20 Oct 2017 06:52:44 -0700 (PDT) Received: by 10.31.16.158 with HTTP; Fri, 20 Oct 2017 06:52:44 -0700 (PDT) In-Reply-To: References: From: Mohammed Umair Date: Fri, 20 Oct 2017 19:22:44 +0530 Message-ID: To: Donald Eastlake Cc: trill@ietf.org Content-Type: multipart/alternative; boundary="f403043655ac92eac3055bfac970" Archived-At: Subject: Re: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) 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: Fri, 20 Oct 2017 13:52:48 -0000 --f403043655ac92eac3055bfac970 Content-Type: text/plain; charset="UTF-8" Support this draft as Co-Author. Regards, Umair On Oct 3, 2017 4:41 AM, "Donald Eastlake" wrote: > This begins a 2 week WG LC on draft-ietf-trill-address-flush-03.txt. > Please indicate if you think the draft is ready for publication and is > useful for TRILL deployments. > > Thanks, > Donald > (WG Secretary for the Chairs: Sue Hares & Jon Hudson) > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --f403043655ac92eac3055bfac970 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support this draft as Co-Author.


Regards,=C2=A0
Umair

On Oct 3, 2017 4:41 AM, "Donald Eastlake" <d3e3e3@gmail.com> wrote:
This begins a 2 week WG LC on draf= t-ietf-trill-address-flush-03.txt.
Please indicate if you think the draft is ready for publication and is
useful for TRILL deployments.

Thanks,
Donald
(WG Secretary for the Chairs: Sue Hares & Jon Hudson)
=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

_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
--f403043655ac92eac3055bfac970-- From nobody Fri Oct 20 08:14: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 08A5E133343 for ; Fri, 20 Oct 2017 08:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 ZY34SyeOfpXm for ; Fri, 20 Oct 2017 08:13:57 -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 D2E561320D9 for ; Fri, 20 Oct 2017 08:13:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYD54165; Fri, 20 Oct 2017 15:13:54 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 20 Oct 2017 16:13:54 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Fri, 20 Oct 2017 08:13:45 -0700 From: Linda Dunbar To: Mohammed Umair , Donald Eastlake CC: "trill@ietf.org" Thread-Topic: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) Thread-Index: AQHTSarBKYSDWadrtEGkvNfukZ+PaKLs2J2A Date: Fri, 20 Oct 2017 15:13:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66AFC2294@sjceml521-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.178] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66AFC2294sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.59EA12B3.0085, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6a6ffac996e2383624c57a561ee41ffe Archived-At: Subject: Re: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) 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: Fri, 20 Oct 2017 15:13:59 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66AFC2294sjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KTGluZGENCg0KDQpPbiBPY3QgMywgMjAxNyA0OjQxIEFNLCAiRG9uYWxkIEVh c3RsYWtlIiA8ZDNlM2UzQGdtYWlsLmNvbTxtYWlsdG86ZDNlM2UzQGdtYWlsLmNvbT4+IHdyb3Rl Og0KVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTEMgb24gZHJhZnQtaWV0Zi10cmlsbC1hZGRyZXNz LWZsdXNoLTAzLnR4dC4NClBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgdGhpbmsgdGhlIGRyYWZ0IGlz IHJlYWR5IGZvciBwdWJsaWNhdGlvbiBhbmQgaXMNCnVzZWZ1bCBmb3IgVFJJTEwgZGVwbG95bWVu dHMuDQoNClRoYW5rcywNCkRvbmFsZA0KKFdHIFNlY3JldGFyeSBmb3IgdGhlIENoYWlyczogU3Vl IEhhcmVzICYgSm9uIEh1ZHNvbikNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBE b25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMzMy0yMjcwIChjZWxsKQ0KIDE1NSBCZWF2 ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0ENCiBkM2UzZTNAZ21haWwuY29tPG1haWx0 bzpkM2UzZTNAZ21haWwuY29tPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZzxtYWlsdG86 dHJpbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry aWxsDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F66AFC2294sjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ U3VwcG9ydC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TGlu ZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE9jdCAzLCAy MDE3IDQ6NDEgQU0sICZxdW90O0RvbmFsZCBFYXN0bGFrZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmQzZTNlM0BnbWFpbC5jb20iPmQzZTNlM0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGJlZ2lu cyBhIDIgd2VlayBXRyBMQyBvbiBkcmFmdC1pZXRmLXRyaWxsLWFkZHJlc3MtZmx1c2gtMDMudHh0 Ljxicj4NClBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgdGhpbmsgdGhlIGRyYWZ0IGlzIHJlYWR5IGZv ciBwdWJsaWNhdGlvbiBhbmQgaXM8YnI+DQp1c2VmdWwgZm9yIFRSSUxMIGRlcGxveW1lbnRzLjxi cj4NCjxicj4NClRoYW5rcyw8YnI+DQpEb25hbGQ8YnI+DQooV0cgU2VjcmV0YXJ5IGZvciB0aGUg Q2hhaXJzOiBTdWUgSGFyZXMgJmFtcDsgSm9uIEh1ZHNvbik8YnI+DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KJm5ic3A7RG9uYWxkIEUuIEVhc3RsYWtlIDNyZCZuYnNwOyAm bmJzcDsmIzQzOzEtNTA4LTMzMy0yMjcwIChjZWxsKTxicj4NCiZuYnNwOzE1NSBCZWF2ZXIgU3Ry ZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0E8YnI+DQombmJzcDs8YSBocmVmPSJtYWlsdG86ZDNl M2UzQGdtYWlsLmNvbSI+ZDNlM2UzQGdtYWlsLmNvbTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyaWxsIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+dHJpbGxAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 cmlsbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJpbGw8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F66AFC2294sjceml521mbschi_-- From nobody Fri Oct 20 17:31:25 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 770F3134581; Fri, 20 Oct 2017 17:24:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: akatlas@gmail.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854547048.20809.9957661384031511453.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:30 -0700 Archived-At: Subject: [trill] trill - Requested session has been scheduled for IETF 100 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: Sat, 21 Oct 2017 00:24:30 -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:00:00) Thursday, Afternoon Session III 1810-1910 Room Name: Bras Basah 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 Hour Number of Attendees: 24 Conflicts to Avoid: First Priority: saag netconf netmod bess isis Second Priority: sfc spring sidr babel i2rs idr Third Priority: intarea lpwan dnsop grow i2nsf People who must be present: Susan Hares Donald E. Eastlake 3rd Alia Atlas Jon Hudson Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 21 13:25: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 064B4132F46; Sat, 21 Oct 2017 13:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[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 0QdAPjI2YDwz; Sat, 21 Oct 2017 13:25:24 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 7D646132D41; Sat, 21 Oct 2017 13:25:24 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id v132so25102044oie.1; Sat, 21 Oct 2017 13:25:24 -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=bJEpHnSyhPizPJr2ymWkYMnb+1a4hIv/9GMBG2mLHTk=; b=WIQRnGZ+tEMEn9W/kT33sqSYXscNvFChRIsXBfJ3rza2B+8VQkRGaauenyVBrDmAOE gz25eSNcs4fzqLhcT98EVeh+2RRBJkvo8KR8mLSfznidX7QgQvMUEo2p0R5GWBjSifYV lt+S//xRW2LDxe3rw7CAaBZT6kF9Hu01wE+BsfRpbVIuY3vXS5tXBsmTSDQoKpFB+lBS 5lQzQ6JIk8Y7w3TxRBbt4IO5OE27GkXq3XsiCR+PP3mhS+PAYswCplC50sS+jpXs9lgU +O+iOzftyLt5DG9Vy9GGHwDrdhhdHhVv7zyTDo/KDJipLbwVqiXszxWCvMQq9/0ErNt1 GlFQ== 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=bJEpHnSyhPizPJr2ymWkYMnb+1a4hIv/9GMBG2mLHTk=; b=TviXXyW9s6nMCsideYstqzL3U6UXxYvS6Y1VmHlHTqtRpa4qZ8+s/QHlgw9BRgj/3Y RKNJ9EnDjO8K7h6Uqs3zf9XNal0/ETJ0EZw05GtLWSpDItd6MZF7UEoWl3K73La1Bcsn BMwpIS2FhFuJrBwRHJwpB0m1c5tW3g+z2jGYp1GnN1jgIpKB5k9Jvn7nHh3kpHECLkOE ohPCeURqtqJWiIz8HJxpcLYSvcMAGtVE/O9ybkV7y3DLTrogvQmqQFbfRPRt6MnexmcW pD0fwVQxan8VCsRfT27GG/9FEArfnCH1zEv/jcrW2gPmdn8HnYxkhEA6f/bELaFJvNvt YLYw== X-Gm-Message-State: AMCzsaVBRAPUlh6xTNjIiMtViw/belNa0k9IP5ljf0HMVXVZ+pN7AJUR jfvmPThI2FyTGccBB4+5O+vE4DlUbTsRS43cLzBlvg== X-Google-Smtp-Source: ABhQp+SUbPO4cH9MC+4K+i0E/lfpf0WO9hfXQemJ4Kt5w3bjJDaqJHKPSzYZTjl0HER9KDot2KiTPvYwewy/AgFja3k= X-Received: by 10.157.20.171 with SMTP id d40mr5180354ote.48.1508617523568; Sat, 21 Oct 2017 13:25:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.194 with HTTP; Sat, 21 Oct 2017 13:25:08 -0700 (PDT) In-Reply-To: <150854547048.20809.9957661384031511453.idtracker@ietfa.amsl.com> References: <150854547048.20809.9957661384031511453.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Sat, 21 Oct 2017 16:25:08 -0400 Message-ID: To: "trill@ietf.org" Cc: "trill-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a1136e61c98239f055c1463dd" Archived-At: Subject: Re: [trill] trill - Requested session has been scheduled for IETF 100 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: Sat, 21 Oct 2017 20:25:26 -0000 --001a1136e61c98239f055c1463dd Content-Type: text/plain; charset="UTF-8" Hi, We have a one hour slot at the Singapore meeting. People who would like to present should contact trill-chairs@ietf.org. 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, Oct 20, 2017 at 8:24 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:00:00) > Thursday, Afternoon Session III 1810-1910 > Room Name: Bras Basah 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 Hour > Number of Attendees: 24 > Conflicts to Avoid: > First Priority: saag netconf netmod bess isis > Second Priority: sfc spring sidr babel i2rs idr > Third Priority: intarea lpwan dnsop grow i2nsf > > > People who must be present: > Susan Hares > Donald E. Eastlake 3rd > Alia Atlas > Jon Hudson > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > --001a1136e61c98239f055c1463dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We have a one hour slot at the Sing= apore meeting. People who would like to present should contact trill-chairs@ietf.org.

Thanks,
Donald (TRILL WG Secretary)
=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 Fri, Oct 20, 2017 at 8:24 PM, "IETF = Secretariat" <agenda@ietf.org> 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:00:00)
=C2=A0 =C2=A0 Thursday, Afternoon Session III 1810-1910
=C2=A0 =C2=A0 Room Name: Bras Basah size: 100
=C2=A0 =C2=A0 ---------------------------------------------



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):=C2=A0 1 Hour
Number of Attendees: 24
Conflicts to Avoid:
=C2=A0First Priority: saag netconf netmod bess isis
=C2=A0Second Priority: sfc spring sidr babel i2rs idr
=C2=A0Third Priority: intarea lpwan dnsop grow i2nsf


People who must be present:
=C2=A0 Susan Hares
=C2=A0 Donald E. Eastlake 3rd
=C2=A0 Alia Atlas
=C2=A0 Jon Hudson

Resources Requested:

Special Requests:

---------------------------------------------------------


--001a1136e61c98239f055c1463dd-- From nobody Sun Oct 22 18:37:35 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 28B1213C845 for ; Sun, 22 Oct 2017 18:37:34 -0700 (PDT) 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, 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 RBQGydUkEp1w for ; Sun, 22 Oct 2017 18:37:32 -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 98BDA13C878 for ; Sun, 22 Oct 2017 18:37:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYG12562; Mon, 23 Oct 2017 01:37:29 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 23 Oct 2017 02:37:28 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.105]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 23 Oct 2017 09:37:18 +0800 From: Liyizhou To: Mohammed Umair , Donald Eastlake CC: "trill@ietf.org" Thread-Topic: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) Thread-Index: AQHTO9PHQ1o2l+ieu0mPe+KIeKXetaLsV6QAgARvkpA= Date: Mon, 23 Oct 2017 01:37:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.180.237] Content-Type: multipart/alternative; boundary="_000_D408889639FC5E4FADB4E00A3E01FA8FA6AA21A2nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010206.59ED47D9.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6a6ffac996e2383624c57a561ee41ffe Archived-At: Subject: Re: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) 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, 23 Oct 2017 01:37:34 -0000 --_000_D408889639FC5E4FADB4E00A3E01FA8FA6AA21A2nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KVGhhbmtzLA0KWWl6aG91DQoNCkZyb206IHRyaWxsIFttYWlsdG86dHJpbGwt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1vaGFtbWVkIFVtYWlyDQpTZW50OiBGcmlk YXksIE9jdG9iZXIgMjAsIDIwMTcgOTo1MyBQTQ0KVG86IERvbmFsZCBFYXN0bGFrZQ0KQ2M6IHRy aWxsQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyaWxsXSBXb3JraW5nIGdyb3VwIExDIG9uIGRy YWZ0LWlldGYtdHJpbGwtYWRkcmVzcy1mbHVzaC0wMyAoMTAvMiAtIDEwLzE2KQ0KDQpTdXBwb3J0 IHRoaXMgZHJhZnQgYXMgQ28tQXV0aG9yLg0KDQoNClJlZ2FyZHMsDQpVbWFpcg0KDQpPbiBPY3Qg MywgMjAxNyA0OjQxIEFNLCAiRG9uYWxkIEVhc3RsYWtlIiA8ZDNlM2UzQGdtYWlsLmNvbTxtYWls dG86ZDNlM2UzQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTEMg b24gZHJhZnQtaWV0Zi10cmlsbC1hZGRyZXNzLWZsdXNoLTAzLnR4dC4NClBsZWFzZSBpbmRpY2F0 ZSBpZiB5b3UgdGhpbmsgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBhbmQgaXMN CnVzZWZ1bCBmb3IgVFJJTEwgZGVwbG95bWVudHMuDQoNClRoYW5rcywNCkRvbmFsZA0KKFdHIFNl Y3JldGFyeSBmb3IgdGhlIENoYWlyczogU3VlIEhhcmVzICYgSm9uIEh1ZHNvbikNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiBEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4 LTMzMy0yMjcwIChjZWxsKQ0KIDE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBV U0ENCiBkM2UzZTNAZ21haWwuY29tPG1haWx0bzpkM2UzZTNAZ21haWwuY29tPg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBs aXN0DQp0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQo= --_000_D408889639FC5E4FADB4E00A3E01FA8FA6AA21A2nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3VwcG9ydC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWl6aG91PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiB0cmlsbCBbbWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPk1vaGFtbWVkIFVtYWlyPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0 b2JlciAyMCwgMjAxNyA5OjUzIFBNPGJyPg0KPGI+VG86PC9iPiBEb25hbGQgRWFzdGxha2U8YnI+ DQo8Yj5DYzo8L2I+IHRyaWxsQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJp bGxdIFdvcmtpbmcgZ3JvdXAgTEMgb24gZHJhZnQtaWV0Zi10cmlsbC1hZGRyZXNzLWZsdXNoLTAz ICgxMC8yIC0gMTAvMTYpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdXBwb3J0IHRoaXMgZHJhZnQgYXMgQ28tQXV0aG9yLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLCZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW1haXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gT2N0IDMsIDIwMTcg NDo0MSBBTSwgJnF1b3Q7RG9uYWxkIEVhc3RsYWtlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 ZDNlM2UzQGdtYWlsLmNvbSI+ZDNlM2UzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTEMg b24gZHJhZnQtaWV0Zi10cmlsbC1hZGRyZXNzLWZsdXNoLTAzLnR4dC48YnI+DQpQbGVhc2UgaW5k aWNhdGUgaWYgeW91IHRoaW5rIHRoZSBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gYW5k IGlzPGJyPg0KdXNlZnVsIGZvciBUUklMTCBkZXBsb3ltZW50cy48YnI+DQo8YnI+DQpUaGFua3Ms PGJyPg0KRG9uYWxkPGJyPg0KKFdHIFNlY3JldGFyeSBmb3IgdGhlIENoYWlyczogU3VlIEhhcmVz ICZhbXA7IEpvbiBIdWRzb24pPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxi cj4NCiZuYnNwO0RvbmFsZCBFLiBFYXN0bGFrZSAzcmQmbmJzcDsgJm5ic3A7JiM0MzsxLTUwOC0z MzMtMjI3MCAoY2VsbCk8YnI+DQombmJzcDsxNTUgQmVhdmVyIFN0cmVldCwgTWlsZm9yZCwgTUEg MDE3NTcgVVNBPGJyPg0KJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmQzZTNlM0BnbWFpbC5jb20iPmQz ZTNlM0BnbWFpbC5jb208L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86dHJpbGxAaWV0Zi5vcmciPnRyaWxsQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D408889639FC5E4FADB4E00A3E01FA8FA6AA21A2nkgeml513mbxchi_-- From nobody Sun Oct 22 18:48:06 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 9F9B913C8D5 for ; Sun, 22 Oct 2017 18:48:05 -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, 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 C28pSPV4v_NE for ; Sun, 22 Oct 2017 18:48:03 -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 664C613C8D3 for ; Sun, 22 Oct 2017 18:48:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYG13154; Mon, 23 Oct 2017 01:48:01 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 23 Oct 2017 02:48:01 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.249]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 23 Oct 2017 09:47:59 +0800 From: "Zhangmingui (Martin)" To: Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) Thread-Index: AQHTO9PHZbKut79XBEO79jOQp2lr8KLwyejw Date: Mon, 23 Oct 2017 01:47:58 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7AAEB70C0@NKGEML515-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] 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.0A010205.59ED4A52.000E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.249, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6a6ffac996e2383624c57a561ee41ffe Archived-At: Subject: Re: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16) 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, 23 Oct 2017 01:48:06 -0000 Support.=20 Yes, this feature is useful for TRILL deployment. Thanks, Mingui > -----Original Message----- > From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake > Sent: Tuesday, October 03, 2017 7:11 AM > To: trill@ietf.org > Subject: [trill] Working group LC on draft-ietf-trill-address-flush-03 (1= 0/2 - 10/16) >=20 > This begins a 2 week WG LC on draft-ietf-trill-address-flush-03.txt. > Please indicate if you think the draft is ready for publication and is us= eful for > TRILL deployments. >=20 > Thanks, > Donald > (WG Secretary for the Chairs: Sue Hares & Jon Hudson) > =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 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nobody Mon Oct 23 11:57:15 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 3572A139A22; Mon, 23 Oct 2017 11:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.645 X-Spam-Level: *** X-Spam-Status: No, score=3.645 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845] 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 s2lqq3zj3wwZ; Mon, 23 Oct 2017 11:57:06 -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 A2416132055; Mon, 23 Oct 2017 11:57:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.15.200; From: "Susan Hares" To: "'John Scudder'" , "'idr@ietf. org'" Cc: , References: In-Reply-To: Date: Mon, 23 Oct 2017 14:57:03 -0400 Message-ID: <044901d34c30$b7417d60$25c47820$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgRQ3jOqXHvI65Vhy4aLGqtk7RZKNX0kpQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [trill] WGLC for draft-ietf-idr-ls-trill-03 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, 23 Oct 2017 18:57:07 -0000 I do not know of any IPR on draft-ietf-idr-ls-trill-03.txt. As Co-author, I believe this draft is complete and ready for publication. As co-chair of TRILL, I note that TRILL has requested that IDR complete this work. TRILL is winding down its work having completed most of its milestones. Sue Hares -----Original Message----- From: John Scudder [mailto:jgs@juniper.net] Sent: Thursday, October 19, 2017 10:34 AM To: idr@ietf. org Cc: draft-ietf-idr-ls-trill@ietf.org; trill@ietf.org Subject: WGLC for draft-ietf-idr-ls-trill-03 Hi All, An IDR working group last call has been requested for draft-ietf-idr-ls-trill-03. Please reply to the list with your comments. As usual note we cannot advance the draft without participation from the group. Please get your comments in before November 3, 2017. Authors, please confirm that any relevant IPR has been disclosed. https://tools.ietf.org/html/draft-ietf-idr-ls-trill-03 Thanks, --John From nobody Thu Oct 26 10:56: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 98F6213F5E6; Thu, 26 Oct 2017 10:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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, 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 S6VVNiXIUS5n; Thu, 26 Oct 2017 10:55:54 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 C823F13F5D7; Thu, 26 Oct 2017 10:55:53 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id a132so7046055oih.11; Thu, 26 Oct 2017 10:55:53 -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=3huBlicLOej18W2vUA+WuDTW3dGYHqH18idJN6nzo+8=; b=roQTYBMHJhqnevHJZh8EXDaKA1pPPPl03gGG0AH970qhiYWQ2Z5if5A45UeIHsmkSY DyXPefNLP2iL6YcbmynjJ7DxkwjOVBElRThDiK8E5tVBL/t/9j9TIRwDdBWsMoyOoG4N DF/6iC3bTNsXeMpiWRdHgcBP1MKPOI/biTc6zdnGjA21snsnYvDIZ3NxRzW5pI7SdG7y REYyqVRPhUG7pcjihl9LnNPcxcLHJ5pYrHYF6hb0lJraEHTNxRlJWxgNYOUIUQPk33Ko rnOevgJ97iG9UTtG2g947kkT8JNVAGw9D173rhO9C03lonjT9vqChtUfyIXLtAZx3F8P 8AAg== 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=3huBlicLOej18W2vUA+WuDTW3dGYHqH18idJN6nzo+8=; b=JrWVr2fKIs06/pcU/32ddCkgDipOr0miInu8R+guXAg+vR6G89MDYGqQEiZU67NZ/8 +oRuUnp7N7gWK+SbJ13Vv6/38/e3G9yAk0IJ37XL1W7msnYfPKtGKLDU9978arNe6EQ8 cCoSaFDYVOWJAIUyrAzBuyk6k7lGtYvXTgatepuIvOHcQtLRpsRDV8ByA/I1K7ymqX/U 3Xp2dU6jp92qAmtq9wH0N8JFHXs0z0F50FMU/SyG7dHfSmrx4BKseu0n9kG6S2hz2zqe 28WKjBYd6h49fk2ihW6e2LVbW60AKDisVxT6OUIvpZEdRy4L3YFjYhYET5UuC5xx9kkO xg1w== X-Gm-Message-State: AMCzsaWJoqWZo1TsIBEf4ZWOdETmpdtcHl52dx4g0vyLhEwV9QHjgLJD r96QgQwLfcexzeO9c71hHYjhUnRf3ubbf1n+7Kc= X-Google-Smtp-Source: ABhQp+Tz/HG4A9Y0JlJKkvQFig+XEccl9mkz67lA7R/mmpBslj/z+a7pV744OuOSIc66pFPdoOxHxOHkmY9STtmUiko= X-Received: by 10.157.35.92 with SMTP id k28mr3333240otd.121.1509040553015; Thu, 26 Oct 2017 10:55:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.194 with HTTP; Thu, 26 Oct 2017 10:55:37 -0700 (PDT) In-Reply-To: References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 26 Oct 2017 13:55:37 -0400 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-trill-arp-optimization@ietf.org, "trill-chairs@ietf.org" , Susan Hares , "trill@ietf.org" Content-Type: multipart/alternative; boundary="001a11390ff81d3f24055c76e26e" Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) 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, 26 Oct 2017 17:55:59 -0000 --001a11390ff81d3f24055c76e26e Content-Type: text/plain; charset="UTF-8" Hi Eric, I realize that most of the delay has been on the TRILL WG end but I hope you don't mind if I ping you again on looking at the -09 revision of this draft... Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Oct 9, 2017 at 7:05 PM, Donald Eastlake wrote: > Hi Eric, > > A -09 version of draft-ietf-trill-arp-optimization has been posted. Could > you look at it to see if it resolves 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 Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorla wrote: > >> >> >> On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake wrote: >> >>> Hi Eric, >>> >>> My apologies for the delay in response. (For part of the time I was on >>> a cruise...) >>> >>> It looks like we are in agreement on most items. >>> >>> See below. >>> >>> On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla wrote: >>> > >>> > >>> > On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake >>> wrote: >>> >> >>> >> Hi Eric, >>> >> >>> >> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla wrote: >>> >> > Eric Rescorla has entered the following ballot position for >>> >> > draft-ietf-trill-arp-optimization-08: Discuss >>> >> > >>> >> > ------------------------------------------------------------ >>> ---------- >>> >> > DISCUSS: >>> >> > ------------------------------------------------------------ >>> ---------- >>> >> >>> >> As a general comment, the Security Consideration section could use >>> >> clarification and some expansion. >>> >> >>> >> Although one can imagine various mixed modes, to the first >>> approximation >>> >> there are two ways of doing the optimization of various >>> multi-destination >>> >> messages discussed in this document: >>> >> >>> >> + Using data plane learning by observing ARP/ND and similar messages >>> (in >>> >> addition to the learning of MAC addresses from the data plane which is >>> >> enabled by default in TRILL). As described in this document, such >>> data plane >>> >> learning by TRILL switches can be used to sometimes optimize >>> >> ARP/ND/RARP/unknown-destination messages. But the result isn't >>> particularly >>> >> more or less secure than it is when this data plane learning is done >>> by end >>> >> stations rather than by TRILL switches (or bridges or other kinds of >>> >> switches) in the middle doing some optimization of the relevant >>> >> multi-destination messages. Interface address information learned >>> through >>> >> data plane learning by edge TRILL switches can also be propagated via >>> the >>> >> control plane but this is not significantly different from >>> propagating that >>> >> information via the multi-destination messages that are being >>> optimized to >>> >> unicast or optimized away. >>> >> + Using a complete, trusted directory as might be based on an >>> orchestration >>> >> system in a data center. Since the messages between TRILL switches >>> doing >>> >> ARP/ND/RARP/unknown-destination optimization can be secured and the >>> TRILL >>> >> switches can be configured to ignore data plane learning, this >>> enables TRILL >>> >> switches to provide answers that are "correct" in that they >>> correspond to >>> >> the data in this complete, trusted directory. However, there can >>> still be >>> >> various forged messages/addresses on a local link between end >>> station(s) and >>> >> edge TRILL switches. Such a local link can, with TRILL, be a bridged >>> LAN, so >>> >> such forgeries emitted by an end station may be seen by other end >>> stations >>> >> and cause incorrect learning from the data plane. >>> >> >>> >> The existing Security Considerations section is a bit sketchy and >>> >> concentrates more on the data plane case, as that is the one with the >>> >> greatest security challenges. >>> > >>> > Yes, this seems like a reasonable assessment. Alia, does someone have >>> the >>> > action item to make it less sketchy? >>> >>> We are working on a draft revision to reflect the above thinking to a >>> greater extent and decrease sketchiness. >>> >>> >> > It's not clear to me how the security properties of this mechanism >>> >> > compare to existing TRILL. The text says: >>> >> > >>> >> > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages >>> can be >>> >> > easily forged. Therefore the learning of MAC/IP addresses by >>> RBridges >>> >> > from ARP/ND should not be considered as reliable. See Section >>> 4.1 for >>> >> > SEND Considerations. >>> >> > >>> >> > "not considered as reliable" seems suboptimal. You need to cover how >>> >> > this mechanism compares to the non-use of this mechanism. >>> >> >>> >> As above, the optimization mechanisms do not make any significant >>> >> difference to the inherent insecurities of data plane learning but >>> when used >>> >> with a complete, trusted directory, it improves considerably over >>> data plane >>> >> learning.. >>> > >>> > That had kind of been my impression, but then I don't understand what >>> "not >>> > considered as reliable" is doing here. I'm supposed to be doing >>> something >>> > with it, so while it may be non-secure, I'm still relying on it, no? >>> >>> Well, at some level some elements of your protocol stack are "relying" >>> on it or "trusting" it or whatever term you want, but it's trivially >>> forged unless you use additional security protocols so I guess we >>> could say something about that. TRILL supports different link >>> technologies but if you are using an Ethernet link, I suppose you >>> could use 802.1AE to improve trust in MAC addresses at layer 2. It >>> wouldn't hurt to mention that but it has very little to do with ARP/ND >>> optimization or TRILL. >>> >> >> I think if you just sort of say "you are using it, but it's not >> trustworthy and here's why" you have it covered. >> >> -Ekr >> >> >>> >> > This document seems very sketchy on what you do when you get >>> duplicate >>> >> > IPs. >>> >> >>> >> Why should what you do when you notice a duplicate IP address be >>> >> significantly different just because some multi-destination messages >>> are >>> >> being optimized? Why shouldn't you just do whatever you do now and >>> why is >>> >> that any of TRILL's business? >>> > >>> > Because you're getting the information via different vector, TRILL >>> needs to >>> > specify what you do, >>> > if only to say "do what you would do otherwise". >>> >>> OK. >>> >>> >> > In the case where the former owner replies, a Duplicate Address >>> has >>> >> > been detected. In this case the querying RBridge SHOULD log the >>> >> > duplicate so that the network administrator can take appropriate >>> >> > action. >>> >> > >>> >> > How does logging solve the problem? >>> >> >>> >> It doesn't but it seems better than not logging. >>> >> >>> >> > What do you reply to ARPs with and/or propagate to other nodes? >>> >> >>> >> If you are asking how you reply to ARPs if the IP address being ARPed >>> for >>> >> has been found to be duplicated, there are the two cases outlined >>> above. If >>> >> you are using a complete, trusted directory, you give the presumed >>> correct >>> >> answer provided by that directory. If you are using data plane >>> learning, you >>> >> use whatever you last learned from the data plane (which could have >>> been a >>> >> forgery over writing good information or good information over >>> writing a >>> >> forgery or a forgery overwriting a different forgery or ...). >>> >> >>> >> > Do you tell the originator of the advertisement you have a >>> duplicate? >>> >> >>> >> As far as I know there is no standardized way to tell a station that >>> you >>> >> think it has an IP address that is duplicated locally and I don't >>> think it >>> >> is the job of TRILL to provide such a mechanism. Certainly this >>> document >>> >> does not propose anything of that sort. >>> > >>> > OK. >>> > >>> > >>> >> > When a newly connected end-station exchanges messages with a DHCP >>> >> > [RFC2131] server an edge RBridge should snoop them (mainly the >>> >> > DHCPAck message) and store IP/MAC mapping information in its >>> ARP/ND >>> >> > cache and should also send the information out through the TRILL >>> >> > control plane using ESADI. >>> >> > >>> >> > What happens if the attacker sets up a fake DHCP server and pretends >>> >> > to assign addresses to himself? It seems like maybe that's the same >>> >> > as fake ARPs but maybe not. >>> >> >>> >> This snooping on DHCP messages only applies to the data plane learning >>> >> case. In the case of a complete, trusted directory, edge RBridges >>> already >>> >> know the right answer, so to speak. With data plane learning, if >>> there are >>> >> forged DHCP messages, things are likely to get all screwed up. Of >>> course, >>> >> you could run DHCP over IPsec but, partly due to the localized nature >>> of >>> >> DHCP, I don't think very many people do that. There is also RFC 3118 >>> which >>> >> can be used to authenticate DHCP messages, but that assumes the >>> distribution >>> >> of keying information. >>> >> >>> >> There isn't much difference between the various multi-destination >>> messages >>> >> (ARP / DHCP) advertising the addresses and point of attachment of >>> >> interfaces. But, overall, I'm not sure why a document that is just >>> >> describing ways to optimize the distribution of various >>> multi-destination >>> >> messages needs to analyze the security of the protocols implemented >>> by those >>> >> multi-destination when, as in the data plane learning case, it is not >>> >> significantly changing that security. >>> > >>> > Well, in this case, you have a new threat vector: DHCP. Even if it is >>> the >>> > same kind of threats, it's still a new threat vector. >>> > More generally documents need to contain complete security >>> considerations >>> > sections. If the security considerations >>> > are the same as with some other document, then they need to say that. >>> >>> OK. >>> >>> >> > In general, the security considerations need a complete threat >>> >> > analysis per 3552. >>> >> >>> >> I don't think there is that much new in this document. While the >>> Security >>> >> Considerations section needs clarification and some expansion, I >>> don't think >>> >> it is, for example, the job of this document to do a threat analysis >>> of the >>> >> ARP protocol as long as it can make a reasonable case that the >>> security of >>> >> ARP is not significantly changed by the optimizations specified. >>> > >>> > Sure, but it also doesn't make that case. >>> >>> I'll see what we can do. >>> >>> >> > ------------------------------------------------------------ >>> ---------- >>> >> > COMMENT: >>> >> > ------------------------------------------------------------ >>> ---------- >>> >> >>> >> For completeness, I've cut and pasted below the COMMENT responses I >>> sent >>> >> to you a while ago. >>> >> >>> >> Thanks, >>> >> Donald >>> >> =============================== >>> >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> >> 155 Beaver Street, Milford, MA 01757 USA >>> >>> >> d3e3e3@gmail.com >>> >> >>> >> > S 2. >>> >> > >>> >> > plane on the edge RBridges, it should be possible to completely >>> >> > suppress flooding of ARP/ND messages in a TRILL Campus, When all >>> end- >>> >> > station MAC addresses are similarly known, it should be possible >>> to >>> >> > suppress unknown unicast flooding by dropping any unknown unicast >>> >> > received at an edge RBridge. >>> >> > >>> >> > Are these "should be possibles" normative? Descriptive? >>> >> >>> >> Section 2 of this document is a general discussion of the optimization >>> >> problem which, while it does mention a couple of possible facets of >>> >> potential solutions, is not intended to be normative. >>> >> >>> >> >>> >> > S 4. >>> >> > This is a sequence of steps, so it would be nice to preface them >>> with >>> >> > a list of the steps. It's also odd to have SEND considerations right >>> >> > in the middle here. >>> >> >>> >> Sorry, I don't understand exactly what you are pointing at as a >>> >> sequence of steps. All of Section 4? Just the text between the Section >>> >> 4 heading and the Section 4.1 heading? Something else? >>> > >>> > Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, >>> etc. >>> > It would be nice if they were listed ahead of this as "this is what >>> you do, >>> > now read the sections" >>> >>> OK. We can add some clarifying material to Section 4 before the 4.1 >>> heading. >>> >>> >> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP >>> >> > >>> >> > Please explain what a non-zero IP is and why it's relevant. >>> >> > This graf also needs an introductory sentence or something before >>> >> > the bullets. >>> >> >>> >> Here is a copy of the response that was sent to a similar comment in >>> >> Dale Worley's GENART review: >>> >> >>> >> This section is talking about getting and handling the IP/MAC >>> >> mapping information for a local end station by an edge RBridge. An >>> >> ARP/ND from such a local end station might show a zero source IP >>> >> address if the end station does not have one or is probing for >>> >> duplicates. >>> >> >>> >> Perhaps the title for the Section should be something like >>> >> >>> >> 4.3 Extracting Local End Station IP/MAC Mapping Information >>> >> >>> >> and a new first paragraph could be added something like >>> >> >>> >> Edge RBridges extract and use information about the correspondence >>> >> between local end station IP and MAC addresses from the ARP/ND >>> >> messages those end stations send as described below. An apparent zero >>> >> source IP address means that the end station is probing for duplicate >>> >> IP addresses and messages with such a zero source IP address are not >>> >> used for the extraction of IP/MAC address mapping information >>> > >>> > LGTM >>> > >>> > >>> >> > S 4.4. >>> >> > It is not essential that all RBridges use the same strategy for >>> which >>> >> > option to select for a particular ARP/ND query. It is up to the >>> >> > implementation. >>> >> > >>> >> > This seems inconsistent with the MUST in arm (b) below, because I >>> >> > can just take some other arm. It's also kind of surprising to be >>> this >>> >> > non-prescriptive. >>> >> >>> >> The wording needs to be clarified. Which lettered item listed below >>> >> applies is determined by the circumstances; however, which of the >>> >> numbered strategies associated with these items is followed is an >>> >> implementation choice in handeling any particular ARP/ND. >>> > >>> > OK. >>> > >>> > >>> >> > S 8. >>> >> > some other location (MAC/VM Mobility) and gets connected to egde- >>> >> > >>> >> > Nit: edge is mispelled. >>> >> >>> >> OK. >>> >>> Thanks, >>> Donald >>> =============================== >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> >>> d3e3e3@gmail.com >>> >> >> > --001a11390ff81d3f24055c76e26e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

I realize t= hat most of the delay has been on the TRILL WG end but I hope you don't= mind if I ping you again on looking at the -09 revision of this draft...

Thanks,
Donald
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
=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 Mon, Oct 9, 2017 at 7:05 PM, Donald Eastl= ake <d3e3e3@gmail.com> wrote:
Hi Eric,

A -09 version of draft-ietf= -trill-arp-optimization has been posted. Could you look at it to see i= f it 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 +1-508-333-2270 (cell)=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Mon, Oct 2,= 2017 at 2:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:


=
On Mo= n, Oct 2, 2017 at 4:54 PM, Donald Eastlake <d3e3e3@gmail.com>= wrote:
Hi Eric,

My apologies for the delay in response. (For part of the time I was on
a cruise...)

It looks like we are in agreement on most items.

See below.

On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>>
>> Hi Eric,
>>
>> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-trill-arp-optimization-08: Discuss
>> >
>> > --------------------------------------------------------= --------------
>> > DISCUSS:
>> > --------------------------------------------------------= --------------
>>
>> As a general comment, the Security Consideration section could use=
>> clarification and some expansion.
>>
>> Although one can imagine various mixed modes, to the first approxi= mation
>> there are two ways of doing the optimization of various multi-dest= ination
>> messages discussed in this document:
>>
>> + Using data plane learning by observing ARP/ND and similar= messages (in
>> addition to the learning of MAC addresses from the data plan= e which is
>> enabled by default in TRILL). As described in this document, such = data plane
>> learning by TRILL switches can be used to sometimes optimize
>> ARP/ND/RARP/unknown-destination messages. But the result isn&= #39;t particularly
>> more or less secure than it is when this data plane learning is do= ne by end
>> stations rather than by TRILL switches (or bridges or other kinds = of
>> switches) in the middle doing some optimization of the relevant >> multi-destination messages. Interface address information learned = through
>> data plane learning by edge TRILL switches can also be propagated = via the
>> control plane but this is not significantly different from propaga= ting that
>> information via the multi-destination messages that are being opti= mized to
>> unicast or optimized away.
>> + Using a complete, trusted directory as might be based on = an orchestration
>> system in a data center. Since the messages between TRILL sw= itches doing
>> ARP/ND/RARP/unknown-destination optimization can be secured a= nd the TRILL
>> switches can be configured to ignore data plane learning, this ena= bles TRILL
>> switches to provide answers that are "correct" in that t= hey correspond to
>> the data in this complete, trusted directory. However, there can s= till be
>> various forged messages/addresses on a local link between end stat= ion(s) and
>> edge TRILL switches. Such a local link can, with TRILL, be a bridg= ed LAN, so
>> such forgeries emitted by an end station may be seen by other end = stations
>> and cause incorrect learning from the data plane.
>>
>> The existing Security Considerations section is a bit sketchy and<= br> >> concentrates more on the data plane case, as that is the one with = the
>> greatest security challenges.
>
> Yes, this seems like a reasonable assessment. Alia, does someone have = the
> action item to make it less sketchy?

We are working on a draft revision to reflect the above thinking to = a
greater extent and decrease sketchiness.

>> > It's not clear to me how the security properties of this = mechanism
>> > compare to existing TRILL. The text says:
>> >
>> >=C2=A0 =C2=A0 Unless Secure ND (SEND [RFC3971]) is used, ARP a= nd ND messages can be
>> >=C2=A0 =C2=A0 easily forged. Therefore the learning of MAC/IP = addresses by RBridges
>> >=C2=A0 =C2=A0 from ARP/ND should not be considered as reliable= . See Section 4.1 for
>> >=C2=A0 =C2=A0 SEND Considerations.
>> >
>> > "not considered as reliable" seems suboptimal. You = need to cover how
>> > this mechanism compares to the non-use of this mechanism.
>>
>> As above, the optimization mechanisms do not make any significant<= br> >> difference to the inherent insecurities of data plane learning but= when used
>> with a complete, trusted directory, it improves considerably over = data plane
>> learning..
>
> That had kind of been my impression, but then I don't understand w= hat "not
> considered as reliable" is doing here. I'm supposed to be doi= ng something
> with it, so while it may be non-secure, I'm still relying on it, n= o?

Well, at some level some elements of your protocol stack are "r= elying"
on it or "trusting" it or whatever term you want, but it's tr= ivially
forged unless you use additional security protocols so I guess we
could say something about that. TRILL supports different link
technologies but if you are using an Ethernet link, I suppose you
could use 802.1AE to improve trust in MAC addresses at layer 2. It
wouldn't hurt to mention that but it has very little to do with ARP/ND<= br> optimization or TRILL.

I th= ink if you just sort of say "you are using it, but it's not trustw= orthy and here's why" you have it covered.

-Ekr


>> > This document seems very sketchy on what you do when you get = duplicate
>> > IPs.
>>
>> Why should what you do when you notice a duplicate IP address be >> significantly different just because some multi-destination messag= es are
>> being optimized? Why shouldn't you just do whatever you do now= and why is
>> that any of TRILL's business?
>
> Because you're getting the information via different vector, TRILL= needs to
> specify what you do,
> if only to say "do what you would do otherwise".

OK.

>> >=C2=A0 =C2=A0 In the case where the former owner replies, a Du= plicate Address has
>> >=C2=A0 =C2=A0 been detected. In this case the querying RBridge= SHOULD log the
>> >=C2=A0 =C2=A0 duplicate so that the network administrator can = take appropriate
>> >=C2=A0 =C2=A0 action.
>> >
>> > How does logging solve the problem?
>>
>> It doesn't but it seems better than not logging.
>>
>> > What do you reply to ARPs with and/or propagate to other node= s?
>>
>> If you are asking how you reply to ARPs if the IP address being AR= Ped for
>> has been found to be duplicated, there are the two cases outlined = above. If
>> you are using a complete, trusted directory, you give the presumed= correct
>> answer provided by that directory. If you are using data plane lea= rning, you
>> use whatever you last learned from the data plane (which could hav= e been a
>> forgery over writing good information or good information over wri= ting a
>> forgery or a forgery overwriting a different forgery or ...).
>>
>> > Do you tell the originator of the advertisement you have a du= plicate?
>>
>> As far as I know there is no standardized way to tell a station th= at you
>> think it has an IP address that is duplicated locally and I don= 9;t think it
>> is the job of TRILL to provide such a mechanism. Certainly this do= cument
>> does not propose anything of that sort.
>
> OK.
>
>
>> >=C2=A0 =C2=A0 When a newly connected end-station exchanges mes= sages with a DHCP
>> >=C2=A0 =C2=A0 [RFC2131] server an edge RBridge should snoop th= em (mainly the
>> >=C2=A0 =C2=A0 DHCPAck message) and store IP/MAC mapping inform= ation in its ARP/ND
>> >=C2=A0 =C2=A0 cache and should also send the information out t= hrough the TRILL
>> >=C2=A0 =C2=A0 control plane using ESADI.
>> >
>> > What happens if the attacker sets up a fake DHCP server and p= retends
>> > to assign addresses to himself? It seems like maybe that'= s the same
>> > as fake ARPs but maybe not.
>>
>> This snooping on DHCP messages only applies to the data plane lear= ning
>> case. In the case of a complete, trusted directory, edge RBridges = already
>> know the right answer, so to speak. With data plane learning, if t= here are
>> forged DHCP messages, things are likely to get all screwed up. Of = course,
>> you could run DHCP over IPsec but, partly due to the localized nat= ure of
>> DHCP, I don't think very many people do that. There is also RF= C 3118 which
>> can be used to authenticate DHCP messages, but that assumes the di= stribution
>> of keying information.
>>
>> There isn't much difference between the various multi-destinat= ion messages
>> (ARP / DHCP) advertising the addresses and point of attachment of<= br> >> interfaces. But, overall, I'm not sure why a document that is = just
>> describing ways to optimize the distribution of various multi-dest= ination
>> messages needs to analyze the security of the protocols implemente= d by those
>> multi-destination when, as in the data plane learning case, it is = not
>> significantly changing that security.
>
> Well, in this case, you have a new threat vector: DHCP. Even if it is = the
> same kind of threats, it's still a new threat vector.
> More generally documents need to contain complete security considerati= ons
> sections. If the security considerations
> are the same as with some other document, then they need to say that.<= br>
OK.

>> > In general, the security considerations need a complete threa= t
>> > analysis per 3552.
>>
>> I don't think there is that much new in this document. While t= he Security
>> Considerations section needs clarification and some expansion, I d= on't think
>> it is, for example, the job of this document to do a threat analys= is of the
>> ARP protocol as long as it can make a reasonable case that the sec= urity of
>> ARP is not significantly changed by the optimizations specified. >
> Sure, but it also doesn't make that case.

I'll see what we can do.

>> > --------------------------------------------------------= --------------
>> > COMMENT:
>> > --------------------------------------------------------= --------------
>>
>> For completeness, I've cut and pasted below the COMMENT respon= ses I sent
>> to you a while ago.
>>
>> 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 15= 5 Beaver Street, Milford, MA 01757 USA
>>=C2=A0 d3e3e3= @gmail.com
>>
>> > S 2.
>> >
>> >=C2=A0 =C2=A0 plane on the edge RBridges, it should be possibl= e to completely
>> >=C2=A0 =C2=A0 suppress flooding of ARP/ND messages in a TRILL = Campus, When all end-
>> >=C2=A0 =C2=A0 station MAC addresses are similarly known, it sh= ould be possible to
>> >=C2=A0 =C2=A0 suppress unknown unicast flooding by dropping an= y unknown unicast
>> >=C2=A0 =C2=A0 received at an edge RBridge.
>> >
>> > Are these "should be possibles" normative? Descript= ive?
>>
>> Section 2 of this document is a general discussion of the optimiza= tion
>> problem which, while it does mention a couple of possible facets o= f
>> potential solutions, is not intended to be normative.
>>
>>
>> > S 4.
>> > This is a sequence of steps, so it would be nice to preface t= hem with
>> > a list of the steps. It's also odd to have SEND considera= tions right
>> > in the middle here.
>>
>> Sorry, I don't understand exactly what you are pointing at as = a
>> sequence of steps. All of Section 4? Just the text between the Sec= tion
>> 4 heading and the Section 4.1 heading? Something else?
>
> Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, = etc.
> It would be nice if they were listed ahead of this as "this is wh= at you do,
> now read the sections"

OK. We can add some clarifying material to Section 4 before the= 4.1 heading.

>> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero = IP
>> >
>> > Please explain what a non-zero IP is and why it's relevan= t.
>> > This graf also needs an introductory sentence or something be= fore
>> > the bullets.
>>
>> Here is a copy of the response that was sent to a similar comment = in
>> Dale Worley's GENART review:
>>
>> This section is talking about getting and handling the IP/MAC
>> mapping information for a local end station by an edge RBridge. An=
>> ARP/ND from such a local end station might show a zero source IP >> address if the end station does not have one or is probing for
>> duplicates.
>>
>> Perhaps the title for the Section should be something like
>>
>>=C2=A0 =C2=A0 4.3 Extracting Local End Station IP/MAC Mapping Infor= mation
>>
>> and a new first paragraph could be added something like
>>
>>=C2=A0 =C2=A0 Edge RBridges extract and use information about the c= orrespondence
>> between local end station IP and MAC addresses from the ARP/ND
>> messages those end stations send as described below. An apparent z= ero
>> source IP address means that the end station is probing for duplic= ate
>> IP addresses and messages with such a zero source IP address are n= ot
>> used for the extraction of IP/MAC address mapping information
>
> LGTM
>
>
>> > S 4.4.
>> >=C2=A0 =C2=A0 It is not essential that all RBridges use the sa= me strategy for which
>> >=C2=A0 =C2=A0 option to select for a particular ARP/ND query. = It is up to the
>> >=C2=A0 =C2=A0 implementation.
>> >
>> > This seems inconsistent with the MUST in arm (b) below, becau= se I
>> > can just take some other arm. It's also kind of surprisin= g to be this
>> > non-prescriptive.
>>
>> The wording needs to be clarified. Which lettered item listed belo= w
>> applies is determined by the circumstances; however, which of the<= br> >> numbered strategies associated with these items is followed is an<= br> >> implementation choice in handeling any particular ARP/ND.
>
> OK.
>
>
>> > S 8.
>> >=C2=A0 =C2=A0 some other location (MAC/VM Mobility) and gets c= onnected to egde-
>> >
>> > Nit: edge is mispelled.
>>
>> OK.

=
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



--001a11390ff81d3f24055c76e26e-- From nobody Thu Oct 26 10:57:15 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 1E14B13F5D4 for ; Thu, 26 Oct 2017 10:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 OygINnRplx1Y for ; Thu, 26 Oct 2017 10:57:05 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 7EC4113F5D8 for ; Thu, 26 Oct 2017 10:57:05 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id k3so3635119ywk.8 for ; Thu, 26 Oct 2017 10:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZsejCSwMUcEz7EOR/7GnA7LAH3L8MU78G5fEMe6w3aU=; b=L24UzjdZlo5IXppZm+GEuF6cM7OLJw45a145016jk3vHNHZkGQAV7m8SKMv52XFAuw AaDQR50XM3GhonTfxnhIxCHxLIvFl68IKiAp8LL+Ufv6UXFiGCSLiFs6D3Q4s4+4lt2g rlSjydCWOFge2abxYM1F4Hd7BEclKuafNn7NkreEXjs4KNsYlCLkxTXFiLbrq15kCbJp BlU2eDVh1STIPXk4uWDHfdVY5YhF5JMerBqxnV/KolgK0xLoaUh8O8a6D4RBu8YJX1cH tB7uKq8d0orCQzv1ZR/LiMIv24TrThxaFNUemxMZpHNM0kJ+gIls4YQ4yR3AYjvuvmBa ZPjw== 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=ZsejCSwMUcEz7EOR/7GnA7LAH3L8MU78G5fEMe6w3aU=; b=O4qBY8TzVHw4W+MbwkC8EBikIAF1cS2cCdq18ll6BjdAV6AAdXmkTWNyedqGEyKXaW 0ATaV8vS8qzkjleZU/zuPHRx8D9fxtzi2WSi8UzhLG9I2kUOslBy5qWFvzcPAYofPnJ9 DqKf11RVMeOGWAC9p1SOI6FExMmJv4kOX/K9qcakCrkDEIDP8Pk2sFA34HYQBngbg81l KrA6VYJrv12Y4E61DMkUo3TuHuF/J7X/u0V+yueCeXKbsomqYkrLdP5r+QPIhIUeRvJE rPYG3Bn0sAx7TXX34vcTZKocyJn2ASBnLNtighTqkPb9Glw/UM5HFrnPwtvG4E/BmWtu ZsJg== X-Gm-Message-State: AMCzsaVtheS8Vor09HEJuhlWWb4zs/7KP/+yQDEX6ePJfc5DlUf60/GZ 54bo6mIe+s+XipLvNFqBfouafLs5gdob5rIZvU90Sg== X-Google-Smtp-Source: ABhQp+SniFJNN3Hd2dx1iZ85a/t+UG2gz/Mw9oozkiYEPCQbHA9OldZcApH4CsO5hpa8xewVZdBOZ+AHYKt+4SzIBqM= X-Received: by 10.37.230.200 with SMTP id d191mr3815367ybh.348.1509040624618; Thu, 26 Oct 2017 10:57:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Thu, 26 Oct 2017 10:56:24 -0700 (PDT) In-Reply-To: References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 26 Oct 2017 10:56:24 -0700 Message-ID: To: Donald Eastlake Cc: The IESG , draft-ietf-trill-arp-optimization@ietf.org, "trill-chairs@ietf.org" , Susan Hares , "trill@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0afb1461e699055c76e6a5" Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) 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, 26 Oct 2017 17:57:09 -0000 --94eb2c0afb1461e699055c76e6a5 Content-Type: text/plain; charset="UTF-8" Thanks for reminding me. I had indeed forgotten. On Thu, Oct 26, 2017 at 10:55 AM, Donald Eastlake wrote: > Hi Eric, > > I realize that most of the delay has been on the TRILL WG end but I hope > you don't mind if I ping you again on looking at the -09 revision of this > draft... > > 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 Mon, Oct 9, 2017 at 7:05 PM, Donald Eastlake wrote: > >> Hi Eric, >> >> A -09 version of draft-ietf-trill-arp-optimization has been posted. >> Could you look at it to see if it resolves 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 Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorla wrote: >> >>> >>> >>> On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake >>> wrote: >>> >>>> Hi Eric, >>>> >>>> My apologies for the delay in response. (For part of the time I was on >>>> a cruise...) >>>> >>>> It looks like we are in agreement on most items. >>>> >>>> See below. >>>> >>>> On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla wrote: >>>> > >>>> > >>>> > On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake >>>> wrote: >>>> >> >>>> >> Hi Eric, >>>> >> >>>> >> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla wrote: >>>> >> > Eric Rescorla has entered the following ballot position for >>>> >> > draft-ietf-trill-arp-optimization-08: Discuss >>>> >> > >>>> >> > ------------------------------------------------------------ >>>> ---------- >>>> >> > DISCUSS: >>>> >> > ------------------------------------------------------------ >>>> ---------- >>>> >> >>>> >> As a general comment, the Security Consideration section could use >>>> >> clarification and some expansion. >>>> >> >>>> >> Although one can imagine various mixed modes, to the first >>>> approximation >>>> >> there are two ways of doing the optimization of various >>>> multi-destination >>>> >> messages discussed in this document: >>>> >> >>>> >> + Using data plane learning by observing ARP/ND and similar messages >>>> (in >>>> >> addition to the learning of MAC addresses from the data plane which >>>> is >>>> >> enabled by default in TRILL). As described in this document, such >>>> data plane >>>> >> learning by TRILL switches can be used to sometimes optimize >>>> >> ARP/ND/RARP/unknown-destination messages. But the result isn't >>>> particularly >>>> >> more or less secure than it is when this data plane learning is done >>>> by end >>>> >> stations rather than by TRILL switches (or bridges or other kinds of >>>> >> switches) in the middle doing some optimization of the relevant >>>> >> multi-destination messages. Interface address information learned >>>> through >>>> >> data plane learning by edge TRILL switches can also be propagated >>>> via the >>>> >> control plane but this is not significantly different from >>>> propagating that >>>> >> information via the multi-destination messages that are being >>>> optimized to >>>> >> unicast or optimized away. >>>> >> + Using a complete, trusted directory as might be based on an >>>> orchestration >>>> >> system in a data center. Since the messages between TRILL switches >>>> doing >>>> >> ARP/ND/RARP/unknown-destination optimization can be secured and the >>>> TRILL >>>> >> switches can be configured to ignore data plane learning, this >>>> enables TRILL >>>> >> switches to provide answers that are "correct" in that they >>>> correspond to >>>> >> the data in this complete, trusted directory. However, there can >>>> still be >>>> >> various forged messages/addresses on a local link between end >>>> station(s) and >>>> >> edge TRILL switches. Such a local link can, with TRILL, be a bridged >>>> LAN, so >>>> >> such forgeries emitted by an end station may be seen by other end >>>> stations >>>> >> and cause incorrect learning from the data plane. >>>> >> >>>> >> The existing Security Considerations section is a bit sketchy and >>>> >> concentrates more on the data plane case, as that is the one with the >>>> >> greatest security challenges. >>>> > >>>> > Yes, this seems like a reasonable assessment. Alia, does someone have >>>> the >>>> > action item to make it less sketchy? >>>> >>>> We are working on a draft revision to reflect the above thinking to a >>>> greater extent and decrease sketchiness. >>>> >>>> >> > It's not clear to me how the security properties of this mechanism >>>> >> > compare to existing TRILL. The text says: >>>> >> > >>>> >> > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages >>>> can be >>>> >> > easily forged. Therefore the learning of MAC/IP addresses by >>>> RBridges >>>> >> > from ARP/ND should not be considered as reliable. See Section >>>> 4.1 for >>>> >> > SEND Considerations. >>>> >> > >>>> >> > "not considered as reliable" seems suboptimal. You need to cover >>>> how >>>> >> > this mechanism compares to the non-use of this mechanism. >>>> >> >>>> >> As above, the optimization mechanisms do not make any significant >>>> >> difference to the inherent insecurities of data plane learning but >>>> when used >>>> >> with a complete, trusted directory, it improves considerably over >>>> data plane >>>> >> learning.. >>>> > >>>> > That had kind of been my impression, but then I don't understand what >>>> "not >>>> > considered as reliable" is doing here. I'm supposed to be doing >>>> something >>>> > with it, so while it may be non-secure, I'm still relying on it, no? >>>> >>>> Well, at some level some elements of your protocol stack are "relying" >>>> on it or "trusting" it or whatever term you want, but it's trivially >>>> forged unless you use additional security protocols so I guess we >>>> could say something about that. TRILL supports different link >>>> technologies but if you are using an Ethernet link, I suppose you >>>> could use 802.1AE to improve trust in MAC addresses at layer 2. It >>>> wouldn't hurt to mention that but it has very little to do with ARP/ND >>>> optimization or TRILL. >>>> >>> >>> I think if you just sort of say "you are using it, but it's not >>> trustworthy and here's why" you have it covered. >>> >>> -Ekr >>> >>> >>>> >> > This document seems very sketchy on what you do when you get >>>> duplicate >>>> >> > IPs. >>>> >> >>>> >> Why should what you do when you notice a duplicate IP address be >>>> >> significantly different just because some multi-destination messages >>>> are >>>> >> being optimized? Why shouldn't you just do whatever you do now and >>>> why is >>>> >> that any of TRILL's business? >>>> > >>>> > Because you're getting the information via different vector, TRILL >>>> needs to >>>> > specify what you do, >>>> > if only to say "do what you would do otherwise". >>>> >>>> OK. >>>> >>>> >> > In the case where the former owner replies, a Duplicate Address >>>> has >>>> >> > been detected. In this case the querying RBridge SHOULD log the >>>> >> > duplicate so that the network administrator can take appropriate >>>> >> > action. >>>> >> > >>>> >> > How does logging solve the problem? >>>> >> >>>> >> It doesn't but it seems better than not logging. >>>> >> >>>> >> > What do you reply to ARPs with and/or propagate to other nodes? >>>> >> >>>> >> If you are asking how you reply to ARPs if the IP address being >>>> ARPed for >>>> >> has been found to be duplicated, there are the two cases outlined >>>> above. If >>>> >> you are using a complete, trusted directory, you give the presumed >>>> correct >>>> >> answer provided by that directory. If you are using data plane >>>> learning, you >>>> >> use whatever you last learned from the data plane (which could have >>>> been a >>>> >> forgery over writing good information or good information over >>>> writing a >>>> >> forgery or a forgery overwriting a different forgery or ...). >>>> >> >>>> >> > Do you tell the originator of the advertisement you have a >>>> duplicate? >>>> >> >>>> >> As far as I know there is no standardized way to tell a station that >>>> you >>>> >> think it has an IP address that is duplicated locally and I don't >>>> think it >>>> >> is the job of TRILL to provide such a mechanism. Certainly this >>>> document >>>> >> does not propose anything of that sort. >>>> > >>>> > OK. >>>> > >>>> > >>>> >> > When a newly connected end-station exchanges messages with a >>>> DHCP >>>> >> > [RFC2131] server an edge RBridge should snoop them (mainly the >>>> >> > DHCPAck message) and store IP/MAC mapping information in its >>>> ARP/ND >>>> >> > cache and should also send the information out through the TRILL >>>> >> > control plane using ESADI. >>>> >> > >>>> >> > What happens if the attacker sets up a fake DHCP server and >>>> pretends >>>> >> > to assign addresses to himself? It seems like maybe that's the same >>>> >> > as fake ARPs but maybe not. >>>> >> >>>> >> This snooping on DHCP messages only applies to the data plane >>>> learning >>>> >> case. In the case of a complete, trusted directory, edge RBridges >>>> already >>>> >> know the right answer, so to speak. With data plane learning, if >>>> there are >>>> >> forged DHCP messages, things are likely to get all screwed up. Of >>>> course, >>>> >> you could run DHCP over IPsec but, partly due to the localized >>>> nature of >>>> >> DHCP, I don't think very many people do that. There is also RFC 3118 >>>> which >>>> >> can be used to authenticate DHCP messages, but that assumes the >>>> distribution >>>> >> of keying information. >>>> >> >>>> >> There isn't much difference between the various multi-destination >>>> messages >>>> >> (ARP / DHCP) advertising the addresses and point of attachment of >>>> >> interfaces. But, overall, I'm not sure why a document that is just >>>> >> describing ways to optimize the distribution of various >>>> multi-destination >>>> >> messages needs to analyze the security of the protocols implemented >>>> by those >>>> >> multi-destination when, as in the data plane learning case, it is not >>>> >> significantly changing that security. >>>> > >>>> > Well, in this case, you have a new threat vector: DHCP. Even if it is >>>> the >>>> > same kind of threats, it's still a new threat vector. >>>> > More generally documents need to contain complete security >>>> considerations >>>> > sections. If the security considerations >>>> > are the same as with some other document, then they need to say that. >>>> >>>> OK. >>>> >>>> >> > In general, the security considerations need a complete threat >>>> >> > analysis per 3552. >>>> >> >>>> >> I don't think there is that much new in this document. While the >>>> Security >>>> >> Considerations section needs clarification and some expansion, I >>>> don't think >>>> >> it is, for example, the job of this document to do a threat analysis >>>> of the >>>> >> ARP protocol as long as it can make a reasonable case that the >>>> security of >>>> >> ARP is not significantly changed by the optimizations specified. >>>> > >>>> > Sure, but it also doesn't make that case. >>>> >>>> I'll see what we can do. >>>> >>>> >> > ------------------------------------------------------------ >>>> ---------- >>>> >> > COMMENT: >>>> >> > ------------------------------------------------------------ >>>> ---------- >>>> >> >>>> >> For completeness, I've cut and pasted below the COMMENT responses I >>>> sent >>>> >> to you a while ago. >>>> >> >>>> >> Thanks, >>>> >> Donald >>>> >> =============================== >>>> >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>> >> 155 Beaver Street, Milford, MA 01757 USA >>>> >>>> >> d3e3e3@gmail.com >>>> >> >>>> >> > S 2. >>>> >> > >>>> >> > plane on the edge RBridges, it should be possible to completely >>>> >> > suppress flooding of ARP/ND messages in a TRILL Campus, When >>>> all end- >>>> >> > station MAC addresses are similarly known, it should be >>>> possible to >>>> >> > suppress unknown unicast flooding by dropping any unknown >>>> unicast >>>> >> > received at an edge RBridge. >>>> >> > >>>> >> > Are these "should be possibles" normative? Descriptive? >>>> >> >>>> >> Section 2 of this document is a general discussion of the >>>> optimization >>>> >> problem which, while it does mention a couple of possible facets of >>>> >> potential solutions, is not intended to be normative. >>>> >> >>>> >> >>>> >> > S 4. >>>> >> > This is a sequence of steps, so it would be nice to preface them >>>> with >>>> >> > a list of the steps. It's also odd to have SEND considerations >>>> right >>>> >> > in the middle here. >>>> >> >>>> >> Sorry, I don't understand exactly what you are pointing at as a >>>> >> sequence of steps. All of Section 4? Just the text between the >>>> Section >>>> >> 4 heading and the Section 4.1 heading? Something else? >>>> > >>>> > Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, >>>> etc. >>>> > It would be nice if they were listed ahead of this as "this is what >>>> you do, >>>> > now read the sections" >>>> >>>> OK. We can add some clarifying material to Section 4 before the 4.1 >>>> heading. >>>> >>>> >> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP >>>> >> > >>>> >> > Please explain what a non-zero IP is and why it's relevant. >>>> >> > This graf also needs an introductory sentence or something before >>>> >> > the bullets. >>>> >> >>>> >> Here is a copy of the response that was sent to a similar comment in >>>> >> Dale Worley's GENART review: >>>> >> >>>> >> This section is talking about getting and handling the IP/MAC >>>> >> mapping information for a local end station by an edge RBridge. An >>>> >> ARP/ND from such a local end station might show a zero source IP >>>> >> address if the end station does not have one or is probing for >>>> >> duplicates. >>>> >> >>>> >> Perhaps the title for the Section should be something like >>>> >> >>>> >> 4.3 Extracting Local End Station IP/MAC Mapping Information >>>> >> >>>> >> and a new first paragraph could be added something like >>>> >> >>>> >> Edge RBridges extract and use information about the correspondence >>>> >> between local end station IP and MAC addresses from the ARP/ND >>>> >> messages those end stations send as described below. An apparent zero >>>> >> source IP address means that the end station is probing for duplicate >>>> >> IP addresses and messages with such a zero source IP address are not >>>> >> used for the extraction of IP/MAC address mapping information >>>> > >>>> > LGTM >>>> > >>>> > >>>> >> > S 4.4. >>>> >> > It is not essential that all RBridges use the same strategy for >>>> which >>>> >> > option to select for a particular ARP/ND query. It is up to the >>>> >> > implementation. >>>> >> > >>>> >> > This seems inconsistent with the MUST in arm (b) below, because I >>>> >> > can just take some other arm. It's also kind of surprising to be >>>> this >>>> >> > non-prescriptive. >>>> >> >>>> >> The wording needs to be clarified. Which lettered item listed below >>>> >> applies is determined by the circumstances; however, which of the >>>> >> numbered strategies associated with these items is followed is an >>>> >> implementation choice in handeling any particular ARP/ND. >>>> > >>>> > OK. >>>> > >>>> > >>>> >> > S 8. >>>> >> > some other location (MAC/VM Mobility) and gets connected to >>>> egde- >>>> >> > >>>> >> > Nit: edge is mispelled. >>>> >> >>>> >> OK. >>>> >>>> Thanks, >>>> Donald >>>> =============================== >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>> 155 Beaver Street, Milford, MA 01757 USA >>>> >>>> d3e3e3@gmail.com >>>> >>> >>> >> > --94eb2c0afb1461e699055c76e6a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for reminding me. I had indeed forgotten.

On Thu, Oct 26, 2017 = at 10:55 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi Eric,

I realize that most of the delay has been on the TRILL WG = end but I hope you don't mind if I ping you again on looking at the -09= revision of this draft...

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

On Mon, Oct 9,= 2017 at 7:05 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi Eric,

A -09 version of draft-ietf-trill-arp-optimization has been posted.= Could you look at it to see if it 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 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorla <= ekr@rtfm.com> wrote:


On Mon, Oct 2, 2017 at 4:54 PM, Donald= Eastlake <d3e3e3@gmail.com> wrote:
Hi Eric,

My apologies for the delay in response. (For part of the time I was on
a cruise...)

It looks like we are in agreement on most items.

See below.

On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>>
>> Hi Eric,
>>
>> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-trill-arp-optimization-08: Discuss
>> >
>> > --------------------------------------------------------= --------------
>> > DISCUSS:
>> > --------------------------------------------------------= --------------
>>
>> As a general comment, the Security Consideration section could use=
>> clarification and some expansion.
>>
>> Although one can imagine various mixed modes, to the first approxi= mation
>> there are two ways of doing the optimization of various multi-dest= ination
>> messages discussed in this document:
>>
>> + Using data plane learning by observing ARP/ND and similar= messages (in
>> addition to the learning of MAC addresses from the data plan= e which is
>> enabled by default in TRILL). As described in this document, such = data plane
>> learning by TRILL switches can be used to sometimes optimize
>> ARP/ND/RARP/unknown-destination messages. But the result isn&= #39;t particularly
>> more or less secure than it is when this data plane learning is do= ne by end
>> stations rather than by TRILL switches (or bridges or other kinds = of
>> switches) in the middle doing some optimization of the relevant >> multi-destination messages. Interface address information learned = through
>> data plane learning by edge TRILL switches can also be propagated = via the
>> control plane but this is not significantly different from propaga= ting that
>> information via the multi-destination messages that are being opti= mized to
>> unicast or optimized away.
>> + Using a complete, trusted directory as might be based on = an orchestration
>> system in a data center. Since the messages between TRILL sw= itches doing
>> ARP/ND/RARP/unknown-destination optimization can be secured a= nd the TRILL
>> switches can be configured to ignore data plane learning, this ena= bles TRILL
>> switches to provide answers that are "correct" in that t= hey correspond to
>> the data in this complete, trusted directory. However, there can s= till be
>> various forged messages/addresses on a local link between end stat= ion(s) and
>> edge TRILL switches. Such a local link can, with TRILL, be a bridg= ed LAN, so
>> such forgeries emitted by an end station may be seen by other end = stations
>> and cause incorrect learning from the data plane.
>>
>> The existing Security Considerations section is a bit sketchy and<= br> >> concentrates more on the data plane case, as that is the one with = the
>> greatest security challenges.
>
> Yes, this seems like a reasonable assessment. Alia, does someone have = the
> action item to make it less sketchy?

We are working on a draft revision to reflect the above thinking to = a
greater extent and decrease sketchiness.

>> > It's not clear to me how the security properties of this = mechanism
>> > compare to existing TRILL. The text says:
>> >
>> >=C2=A0 =C2=A0 Unless Secure ND (SEND [RFC3971]) is used, ARP a= nd ND messages can be
>> >=C2=A0 =C2=A0 easily forged. Therefore the learning of MAC/IP = addresses by RBridges
>> >=C2=A0 =C2=A0 from ARP/ND should not be considered as reliable= . See Section 4.1 for
>> >=C2=A0 =C2=A0 SEND Considerations.
>> >
>> > "not considered as reliable" seems suboptimal. You = need to cover how
>> > this mechanism compares to the non-use of this mechanism.
>>
>> As above, the optimization mechanisms do not make any significant<= br> >> difference to the inherent insecurities of data plane learning but= when used
>> with a complete, trusted directory, it improves considerably over = data plane
>> learning..
>
> That had kind of been my impression, but then I don't understand w= hat "not
> considered as reliable" is doing here. I'm supposed to be doi= ng something
> with it, so while it may be non-secure, I'm still relying on it, n= o?

Well, at some level some elements of your protocol stack are "r= elying"
on it or "trusting" it or whatever term you want, but it's tr= ivially
forged unless you use additional security protocols so I guess we
could say something about that. TRILL supports different link
technologies but if you are using an Ethernet link, I suppose you
could use 802.1AE to improve trust in MAC addresses at layer 2. It
wouldn't hurt to mention that but it has very little to do with ARP/ND<= br> optimization or TRILL.

I th= ink if you just sort of say "you are using it, but it's not trustw= orthy and here's why" you have it covered.

-Ekr


>> > This document seems very sketchy on what you do when you get = duplicate
>> > IPs.
>>
>> Why should what you do when you notice a duplicate IP address be >> significantly different just because some multi-destination messag= es are
>> being optimized? Why shouldn't you just do whatever you do now= and why is
>> that any of TRILL's business?
>
> Because you're getting the information via different vector, TRILL= needs to
> specify what you do,
> if only to say "do what you would do otherwise".

OK.

>> >=C2=A0 =C2=A0 In the case where the former owner replies, a Du= plicate Address has
>> >=C2=A0 =C2=A0 been detected. In this case the querying RBridge= SHOULD log the
>> >=C2=A0 =C2=A0 duplicate so that the network administrator can = take appropriate
>> >=C2=A0 =C2=A0 action.
>> >
>> > How does logging solve the problem?
>>
>> It doesn't but it seems better than not logging.
>>
>> > What do you reply to ARPs with and/or propagate to other node= s?
>>
>> If you are asking how you reply to ARPs if the IP address being AR= Ped for
>> has been found to be duplicated, there are the two cases outlined = above. If
>> you are using a complete, trusted directory, you give the presumed= correct
>> answer provided by that directory. If you are using data plane lea= rning, you
>> use whatever you last learned from the data plane (which could hav= e been a
>> forgery over writing good information or good information over wri= ting a
>> forgery or a forgery overwriting a different forgery or ...).
>>
>> > Do you tell the originator of the advertisement you have a du= plicate?
>>
>> As far as I know there is no standardized way to tell a station th= at you
>> think it has an IP address that is duplicated locally and I don= 9;t think it
>> is the job of TRILL to provide such a mechanism. Certainly this do= cument
>> does not propose anything of that sort.
>
> OK.
>
>
>> >=C2=A0 =C2=A0 When a newly connected end-station exchanges mes= sages with a DHCP
>> >=C2=A0 =C2=A0 [RFC2131] server an edge RBridge should snoop th= em (mainly the
>> >=C2=A0 =C2=A0 DHCPAck message) and store IP/MAC mapping inform= ation in its ARP/ND
>> >=C2=A0 =C2=A0 cache and should also send the information out t= hrough the TRILL
>> >=C2=A0 =C2=A0 control plane using ESADI.
>> >
>> > What happens if the attacker sets up a fake DHCP server and p= retends
>> > to assign addresses to himself? It seems like maybe that'= s the same
>> > as fake ARPs but maybe not.
>>
>> This snooping on DHCP messages only applies to the data plane lear= ning
>> case. In the case of a complete, trusted directory, edge RBridges = already
>> know the right answer, so to speak. With data plane learning, if t= here are
>> forged DHCP messages, things are likely to get all screwed up. Of = course,
>> you could run DHCP over IPsec but, partly due to the localized nat= ure of
>> DHCP, I don't think very many people do that. There is also RF= C 3118 which
>> can be used to authenticate DHCP messages, but that assumes the di= stribution
>> of keying information.
>>
>> There isn't much difference between the various multi-destinat= ion messages
>> (ARP / DHCP) advertising the addresses and point of attachment of<= br> >> interfaces. But, overall, I'm not sure why a document that is = just
>> describing ways to optimize the distribution of various multi-dest= ination
>> messages needs to analyze the security of the protocols implemente= d by those
>> multi-destination when, as in the data plane learning case, it is = not
>> significantly changing that security.
>
> Well, in this case, you have a new threat vector: DHCP. Even if it is = the
> same kind of threats, it's still a new threat vector.
> More generally documents need to contain complete security considerati= ons
> sections. If the security considerations
> are the same as with some other document, then they need to say that.<= br>
OK.

>> > In general, the security considerations need a complete threa= t
>> > analysis per 3552.
>>
>> I don't think there is that much new in this document. While t= he Security
>> Considerations section needs clarification and some expansion, I d= on't think
>> it is, for example, the job of this document to do a threat analys= is of the
>> ARP protocol as long as it can make a reasonable case that the sec= urity of
>> ARP is not significantly changed by the optimizations specified. >
> Sure, but it also doesn't make that case.

I'll see what we can do.

>> > --------------------------------------------------------= --------------
>> > COMMENT:
>> > --------------------------------------------------------= --------------
>>
>> For completeness, I've cut and pasted below the COMMENT respon= ses I sent
>> to you a while ago.
>>
>> 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 15= 5 Beaver Street, Milford, MA 01757 USA
>>=C2=A0 d3e3e3= @gmail.com
>>
>> > S 2.
>> >
>> >=C2=A0 =C2=A0 plane on the edge RBridges, it should be possibl= e to completely
>> >=C2=A0 =C2=A0 suppress flooding of ARP/ND messages in a TRILL = Campus, When all end-
>> >=C2=A0 =C2=A0 station MAC addresses are similarly known, it sh= ould be possible to
>> >=C2=A0 =C2=A0 suppress unknown unicast flooding by dropping an= y unknown unicast
>> >=C2=A0 =C2=A0 received at an edge RBridge.
>> >
>> > Are these "should be possibles" normative? Descript= ive?
>>
>> Section 2 of this document is a general discussion of the optimiza= tion
>> problem which, while it does mention a couple of possible facets o= f
>> potential solutions, is not intended to be normative.
>>
>>
>> > S 4.
>> > This is a sequence of steps, so it would be nice to preface t= hem with
>> > a list of the steps. It's also odd to have SEND considera= tions right
>> > in the middle here.
>>
>> Sorry, I don't understand exactly what you are pointing at as = a
>> sequence of steps. All of Section 4? Just the text between the Sec= tion
>> 4 heading and the Section 4.1 heading? Something else?
>
> Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, = etc.
> It would be nice if they were listed ahead of this as "this is wh= at you do,
> now read the sections"

OK. We can add some clarifying material to Section 4 before the= 4.1 heading.

>> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero = IP
>> >
>> > Please explain what a non-zero IP is and why it's relevan= t.
>> > This graf also needs an introductory sentence or something be= fore
>> > the bullets.
>>
>> Here is a copy of the response that was sent to a similar comment = in
>> Dale Worley's GENART review:
>>
>> This section is talking about getting and handling the IP/MAC
>> mapping information for a local end station by an edge RBridge. An=
>> ARP/ND from such a local end station might show a zero source IP >> address if the end station does not have one or is probing for
>> duplicates.
>>
>> Perhaps the title for the Section should be something like
>>
>>=C2=A0 =C2=A0 4.3 Extracting Local End Station IP/MAC Mapping Infor= mation
>>
>> and a new first paragraph could be added something like
>>
>>=C2=A0 =C2=A0 Edge RBridges extract and use information about the c= orrespondence
>> between local end station IP and MAC addresses from the ARP/ND
>> messages those end stations send as described below. An apparent z= ero
>> source IP address means that the end station is probing for duplic= ate
>> IP addresses and messages with such a zero source IP address are n= ot
>> used for the extraction of IP/MAC address mapping information
>
> LGTM
>
>
>> > S 4.4.
>> >=C2=A0 =C2=A0 It is not essential that all RBridges use the sa= me strategy for which
>> >=C2=A0 =C2=A0 option to select for a particular ARP/ND query. = It is up to the
>> >=C2=A0 =C2=A0 implementation.
>> >
>> > This seems inconsistent with the MUST in arm (b) below, becau= se I
>> > can just take some other arm. It's also kind of surprisin= g to be this
>> > non-prescriptive.
>>
>> The wording needs to be clarified. Which lettered item listed belo= w
>> applies is determined by the circumstances; however, which of the<= br> >> numbered strategies associated with these items is followed is an<= br> >> implementation choice in handeling any particular ARP/ND.
>
> OK.
>
>
>> > S 8.
>> >=C2=A0 =C2=A0 some other location (MAC/VM Mobility) and gets c= onnected to egde-
>> >
>> > Nit: edge is mispelled.
>>
>> OK.

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




--94eb2c0afb1461e699055c76e6a5-- From nobody Thu Oct 26 19:30:15 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 E892813F60E; Thu, 26 Oct 2017 19:30:12 -0700 (PDT) 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 PV4xMKRCnlE6; Thu, 26 Oct 2017 19:30:10 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 5579C13F4F2; Thu, 26 Oct 2017 19:30:10 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id h6so8842877oia.10; Thu, 26 Oct 2017 19:30:10 -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:content-transfer-encoding; bh=vtGj9cBZ47OFsR43DUcilxQH5DbuLYO7GVdGq/V6LVo=; b=WuSQLA1nV1aKJKzHZOpg3IzF23Zuy7UqKM3svCHQN3ZZzNppF5VtEIlMPhG2Z2/mli x07HuGBmhS4Rb0a8nALuqIVYGxt/DIRR/eDzjFgzgDyLZA6Q6uw1AxrYG2uBUfZtN3or MABBYoRQYdyZSpNa0fwRLi/MefUf+fbl/OGlafnts2/4PwzoLhPBPsZvigf/eGEeGOBI A9oYxr9YigVPfWTB784nSENcn5/adfp48w5a/K82H28PEN2Bz3qhQI0F2QDS0QTnaYKp r73pKG9h9eM+AydLcLakrVls/tYZ2VIVujp0Ku5+ZRgyknIE2q2OzQId21nlHb0ditFy 1T7g== 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=vtGj9cBZ47OFsR43DUcilxQH5DbuLYO7GVdGq/V6LVo=; b=PARat+Rx9MfNEAW5b1YAhjE5it7ahFfJzoDFQep3LIoA06Pp7TG+PDbhalCq9Vzh74 HkdjUnK3j6hCeWjF8PmhH6OtbHtnArJJaxO6PHKZ6Fxmg2pb70+Jek1Ztg896p3TYQi/ 23KDjKdJaGVlr43CpIhKfCwLqriwraOOpGEDAwSx+aLoeRTTsXACPg0zGHY6SycOZhvr d01kcdWUSWF6cjXJTDLQPbpF2kXRbNo30IKD3FuSgIt+omIKGNUU/aTnn5ToI5jQFsiT BirxrulEmDntnHUglFUDuOKjllzFaX14VbQBf+D2+n1dwa6qY/vB2j57XjqkiiMLvvfS INOQ== X-Gm-Message-State: AMCzsaVC+VViTKFR39GjinHUJfgfwnEHW3ZWjpJCpMdEKBnzdKAd24Ju cFjzVK8dwkV2ZvA8r2bPg9PggzoZvLlP4ruV9kmX/FrA X-Google-Smtp-Source: ABhQp+TF4tQsH7Kvm7iHQXXwB3lX9Ztry+B01C7PaTIHrSx0KuUPWO/1UYT92uoePnmjsnczvkTKl/JzXhgJaCahKtE= X-Received: by 10.157.82.65 with SMTP id q1mr3916412otg.33.1509071409268; Thu, 26 Oct 2017 19:30:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.194 with HTTP; Thu, 26 Oct 2017 19:29:53 -0700 (PDT) In-Reply-To: <719932B6-AA05-47A4-99BA-EBB842D3AFF0@niven-jenkins.co.uk> References: <719932B6-AA05-47A4-99BA-EBB842D3AFF0@niven-jenkins.co.uk> From: Donald Eastlake Date: Thu, 26 Oct 2017 22:29:53 -0400 Message-ID: To: Ben Niven-Jenkins Cc: " (rtg-ads@ietf.org)" , "rtg-dir@ietf.org" , draft-ietf-trill-directory-assisted-encap-02.all@ietf.org, "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [trill] RtgDir review: draft-ietf-trill-directory-assisted-encap-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: Fri, 27 Oct 2017 02:30:13 -0000 Hi Ben, Thanks for your review. It appears that is was not responded to in a timely fashion. Apologies on behalf of the authors. (Your review was of the -02 version. The current version is -05.) On Sun, Apr 24, 2016 at 4:28 AM, Ben Niven-Jenkins wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review. The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, > please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > > Document: draft-ietf-trill-directory-assisted-encap-02.txt > Reviewer: Ben Niven-Jenkins > Review Date: 21 April 2016 > Intended Status: Proposed Standard > > Summary: > I have significant concerns about this document and recommend that > the Routing ADs discuss these issues further with the authors. Hopefully the changes made between the version -02 you reviewed and the current -05 have made some improvements and, based on your comments and WG LC comments, further improvements can be made. > Comments: > Overall this is not the easiest document to read although some of > that might be due to my lack of background in TRILL and its > terminology. > > Major Issues: > > 1) The document has an Intended Status of Proposed Standard, however > it does not contain any RFC2119 keywords and does not seem to make > any normative statements about required behaviour which I would have > expected in a Proposed Standard. Well, in version -05 there is at least one keyword instance. Furthermore, I don't know that such keywords need to always be used when an implementation requirement level is being specified. That said, we could see if additional RFC 2119 keywords are warranted. > 2) Section 4: If I understand correctly the TRILL-EN spoofs the > Ingress RBridge edge node's nickname in the source address field of > the TRILL header. Is this likely to introduce problems? E.g. if > RBridges will accept & forward frames that have their own source > address in, does it perpetuate routing loops or present security > considerations that the document should discuss? TRILL goes to great lengths to avoid loops and has a hop count in the TRILL header so that, should there be a transient loop, a TRILL packet in that loop (i.e., an encapsulated frame) will be discarded. In the potentially more dangerous case of multi-destination packets, as compared with known unicast, where copies could multiply due to forks in the distribution tree, a Reverse Path Forwarding Check is used to discard packets that appear to be on the wrong link or when there is disagreement about the distribution tree. Security Considerations should probably say more on this. > Section 8 on Security Considerations also looks very light on > text. If you are allowing TRILL-ENs to spoof RBridge source > addresses (which I think you are, see comment above) I think you > should have a discussion about that somewhere in the document. I agree that some further discussion is needed in the Security Considerations section. > Minor Issues: > > 1) Section 3. I am not sure what Figure 2 is trying to convey and it > is not referred to by the main text. Is it required? Figure 2 is intended to show the header of a pre-encapsulated frame going from a TRILL-EN to an edge TRILL switch. If it is retained in the draft, there should be clarifying text that references it. > 2) Section 3 says: > > Editor's note: [Directory] has defined Push and Pull methods for edge > RBridges to get directory mapping information. The Pull Model is > relative simple for TRILL-EN to implement (see Section 9). Pushing > Directory information requires some reliable flooding mechanism, like > the one used by IS-IS, between the edge RBridge and the TRILL > encapsulating node. > > which gives me the impression the authors prefer pull and discourage > push as it would require something extra like IS-IS. That note no longer exists in the draft. Also the "[Directory]" draft referred to has been issued as RFC 8171 and the draft should be updated to reflect that. > However, Section 4 says > > The TRILL-EN learns this nickname by listening > to the TRILL IS-IS Hellos from the Ingress RBridge. > > which makes me think if the TRILL-EN is running IS-IS for hellos, is > pushing the directory such an obstacle? That text refers to snooping on IS-IS messages, not running IS-IS. There are problems with using IS-IS, designed for communication between routers (Intermediate Systems) and the end station implementing pre-encapsulation as described in this draft. At first throught, you might want is an extension of ES-IS but the Memorandum of Understanding between the IETF and ISO/IEC only covers IS-IS, not ES-IS. So TRILL has specified a "TRILL ES-IS" in Section 5 of RFC 8171. However, even then, push uses ESADI [RFC7357], which involves encapsulation and VLAN/FGL scoping and which would need to be extended for end stations so push is out of scope for this document. > Is whether the directory is pulled or pushed something this document > needs to discuss at all? If it does need to discuss push vs pull, > should the document be stronger and make a clearer recommendation on > which method should be used (or implemented by default) to aid with > interoperability? The reasons for using push or pull or some sort of hybrid are discussed in RFC 8171. The -05 version of the Directory Assisted TRILL Encapsulation document only covers pull. > 3) Section 5.1 states > > setting TRILL boundary at aggregation > switches that have many virtualized servers attached can limit the > number of RBridge nodes in a TRILL domain, but introduce the issues > of very large MAC&VLAN<->RBridgeEdge mapping table to be maintained > by RBridge edge nodes and the necessity of enforcing AF ports. > > Allowing Non-RBridge nodes to pre-encapsulate data frames with TRILL > header makes it possible to have a TRILL domain with a reasonable > number of RBridge nodes in a large data center. All the TRILL-ENs > attached to one RBridge are represented by one TRILL nickname, which > can avoid the Nickname exhaustion problem. > > As I understand it TRILL-ENs pre-encapsulate packets that they send, > but when receiving packets the RBridge attached to the TRILL-EN > decapsulates the TRILL packet and forwards it to the TRILL-EN > =E2=80=9Cnatively=E2=80=9D (without TRILL encapsulation), as stated in se= ction 3: > > When a TRILL frame arrives at an RBridge whose nickname matches with > the destination nickname in the TRILL header of the frame, the > processing is exactly same as normal, i.e. as specified in [RFC6325] > the RBridge decapsulates the received TRILL frame and forwards the > decapsulated frame to the target attached to its edge ports. > > Therefore all the RBridges still need to maintain a very large > "MAC&VLAN<->RBridgeEdge mapping table=E2=80=9D? If that is the case, what > advantage does this approach give over the =E2=80=9Cbase case=E2=80=9D of= setting > TRILL boundary at aggregation switches? With pre-encapsulation, although edge RBridges need to learn local MAC addresses so they can de-capsulate, they do not need to learn the typically much larger number of remote MAC address because they do not need to encapsulate. This should be explained more clearly. > 4) Section 7 on Manageability Considerations only states that in > order for the solution to work requires the availability of a > directory service, which seems a bit redundant when the entire > document is about "Directory Assisted TRILL Encapsulation=E2=80=9D. Is th= is > section required? I agree that the Manageability Considerations section should have some material added concerning configuration or be dropped. 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 > Regards > Ben From nobody Fri Oct 27 02:37:10 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 0885413A902; Fri, 27 Oct 2017 02:37:09 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150909702899.22189.16008637935476374283@ietfa.amsl.com> Date: Fri, 27 Oct 2017 02:37:09 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-centralized-replication-09.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, 27 Oct 2017 09:37:09 -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 WG of the IETF. Title : Centralized Replication for Active-Active BUM Traffic Authors : Weiguo Hao Yizhou Li Muhammad Durrani Sujay Gupta Andrew Qu Filename : draft-ietf-trill-centralized-replication-09.txt Pages : 17 Date : 2017-10-27 Abstract: In TRILL active-active access, an RPF check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This draft describes a solution to resolve this RPF check failure issue through centralized replication. All ingress RBridges send BUM (Broadcast, Unknown unicast and Mutlicast) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established as per TRILL base protocol RFC 6325. To avoid RPF check failure on a RBridge sitting between the ingress RBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge should be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-centralized-replication/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-centralized-replication-09 https://datatracker.ietf.org/doc/html/draft-ietf-trill-centralized-replication-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-centralized-replication-09 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 Oct 29 19:07:19 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 6AFAD139435; Sun, 29 Oct 2017 19:07:12 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150932923239.3413.13034886750370110266@ietfa.amsl.com> Date: Sun, 29 Oct 2017 19:07:12 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-centralized-replication-10.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: Mon, 30 Oct 2017 02:07:12 -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 WG of the IETF. Title : Centralized Replication for Active-Active BUM Traffic Authors : Weiguo Hao Yizhou Li Muhammad Durrani Sujay Gupta Andrew Qu Filename : draft-ietf-trill-centralized-replication-10.txt Pages : 17 Date : 2017-10-29 Abstract: In TRILL active-active access, an RPF check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This draft describes a solution to resolve this RPF check failure issue through centralized replication. All ingress RBridges send BUM (Broadcast, Unknown unicast and Mutlicast) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established as per TRILL base protocol RFC 6325. To avoid RPF check failure on a RBridge sitting between the ingress RBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge should be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-centralized-replication/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-centralized-replication-10 https://datatracker.ietf.org/doc/html/draft-ietf-trill-centralized-replication-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-centralized-replication-10 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 Oct 29 19:51: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 108F413F492 for ; Sun, 29 Oct 2017 19:51:15 -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, 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 gDpJanegCVpD for ; Sun, 29 Oct 2017 19:51:13 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 19B6413FD71 for ; Sun, 29 Oct 2017 19:51:13 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id c202so19720321oih.9 for ; Sun, 29 Oct 2017 19:51:13 -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; bh=rCz/Zk5q+A+f1EbSbZGT3X23ZOnx0t2SF18WGwpQyUc=; b=vAxMHUAavW9PH3k5pjySMJd6xwv4xkoYAt7x7CRTs0S947Iu7eSMsNOmSPSLKvMaNF KXhexEkP7u1b7HT6H6svHKAerUhSejdJxN/YeBYZOTOWPWs7LO9ZhrQZ/9Pb4ecf+rK9 YhBYhMHOhlT7+NCOO0Yx/hDYPvIycTVQvnxGXAMXiGmYCzuSHckqXdqMAbeOYk43xYuQ tjkeMUK7XhkcdzbAGBjoiZLunzpjZAi9MeChvKChqmfMDfXuKDKPmT5B1UUQuBePLajC oxJ29Alg7Tmghr58p5poxq0cZvn24HITLk2E11G0lo/To32bmfXQkEtZ6FXy25dk8hU8 rQzg== 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; bh=rCz/Zk5q+A+f1EbSbZGT3X23ZOnx0t2SF18WGwpQyUc=; b=aKA10tomV2PRHqaeURI89fCOklIG2JboOhy86UgsrfsK+JwBndEh6PeD+X0oW00CGf gn7kgw7A9OAqip1Tg2Q6P5LjUyr2YwnSDyF+oq5kx7R8HN8clW1Gp8+uRu39lY9UHhoE G7Yt2nvHAtlLpz8GN/TdxtQO4mHceq0cO4pr4Il/R+GakYL2MEpj8IN3Zi4p2cu8p5eR jMN/CgFj04Ol1aJgGdDRFTqjWh/dWZPbiKmYLjzOYdZAKyZlzr2G0llkzRALuSRkcIwH prOUOMRSECFS4YsLhZ2RvquR6KPnqc3RopaKHOCgXSTre9RbR1O6V3hmkDCxh5edmlbm 9DGg== X-Gm-Message-State: AMCzsaWbB8KUglCvqAJVjWqPbPU8UdZZ4+//De49KWoMRtt/H45gauKQ Pe1dXaxPJ8e0j52YfGWN6cAmHb2kQsW8hu5PJ2+iKg== X-Google-Smtp-Source: ABhQp+Tp5qNTXg3hB+TvxGRmBfS0//XtGxiNzqLXMAEKtxejgCMq6jSmdiikb9NC4ek+ysytG9IQQZ9gwQ9jefRfa6s= X-Received: by 10.202.83.8 with SMTP id h8mr3732583oib.91.1509331872143; Sun, 29 Oct 2017 19:51:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.194 with HTTP; Sun, 29 Oct 2017 19:50:56 -0700 (PDT) In-Reply-To: <150932923239.3413.13034886750370110266@ietfa.amsl.com> References: <150932923239.3413.13034886750370110266@ietfa.amsl.com> From: Donald Eastlake Date: Sun, 29 Oct 2017 22:50:56 -0400 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [trill] I-D Action: draft-ietf-trill-centralized-replication-10.txt 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, 30 Oct 2017 02:51:15 -0000 Hi, Thanks to Hao Weiguo for updating this draft. The -09 version had changes intended to resolve the comments in Alia's AD review. This -10 version just fixes a few small nits. Thanks, Donald (document Shepherd) =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sun, Oct 29, 2017 at 10:07 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transparent Interconnection of Lots of Links WG of the IETF. > > Title : Centralized Replication for Active-Active BUM Traffic > Authors : Weiguo Hao > Yizhou Li > Muhammad Durrani > Sujay Gupta > Andrew Qu > Filename : draft-ietf-trill-centralized-replication-10.txt > Pages : 17 > Date : 2017-10-29 > > Abstract: > In TRILL active-active access, an RPF check failure issue may occur > when using the pseudo-nickname mechanism specified in RFC 7781. This > draft describes a solution to resolve this RPF check failure issue > through centralized replication. All ingress RBridges send BUM > (Broadcast, Unknown unicast and Mutlicast) traffic to a centralized > node with unicast TRILL encapsulation. When the centralized node > receives the BUM traffic, it decapsulates the packets and forwards > them to their destination RBridges using a distribution tree > established as per TRILL base protocol RFC 6325. To avoid RPF check > failure on a RBridge sitting between the ingress RBridge and the > centralized replication node, some change in the RPF calculation > algorithm is required. RPF checks on each RBridge should be > calculated as if the centralized node was the ingress RBridge, > instead of being calculated using the actual ingress RBridge. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trill-centralized-replication/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-trill-centralized-replication-10 > https://datatracker.ietf.org/doc/html/draft-ietf-trill-centralized-replication-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-centralized-replication-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nobody Sun Oct 29 23:00:32 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 7881913FDAE; Sun, 29 Oct 2017 23:00:25 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150934322544.3290.1340992674959131551@ietfa.amsl.com> Date: Sun, 29 Oct 2017 23:00:25 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-parent-selection-01.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: Mon, 30 Oct 2017 06:00:25 -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 WG of the IETF. Title : TRILL: Parent node Shifts in Tree Construction, Mitigation. Author : R. Parameswaran Filename : draft-ietf-trill-parent-selection-01.txt Pages : 10 Date : 2017-10-29 Abstract: This draft documents a known problem in the TRILL tree construction mechanism and offers an approach requiring no change to the TRILL protocol in order to solve the problem. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-parent-selection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-parent-selection-01 https://datatracker.ietf.org/doc/html/draft-ietf-trill-parent-selection-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-parent-selection-01 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/