From nobody Mon Apr 4 06:20:33 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9934C12D6A9 for ; Fri, 1 Apr 2016 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 kn7iCDhBniFV for ; Fri, 1 Apr 2016 12:54:19 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 4C14712D56E for ; Fri, 1 Apr 2016 12:54:19 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by comcast with SMTP id m58oa6fCg7xvbm598aILAz; Fri, 01 Apr 2016 19:54:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459540458; bh=GoW6J3I9err2ltKCUd6AnI5ywkPWKqbPR94nmE4wv4k=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=jQ7slW8eh2fhCXVswTFnjWOtWkJMEpvx6rnhvmRbwomPLQcuuV4fsqpvAgwh+784j 3c5eYg1hk9YvaY0grTD95rcPgva1uOHyHPTI3UrFzevxRiWXdHXhMJfoorXAPbgCao H2ANmvjOEDioJoUpIS6h56TXlQ+CMXbZ0XV50CURQV3LFmzMzXAk0l1yP4jKuxDLhI /cZG2A/A6bxPQ6s5AKycqwYowqhEmYBfF0VcHv+Df8wNqbvn1YPNS8B1tQP6EXTDmr z/qiXlQbVQMF61nIVvGMlz5McfyQa3Lront1zyPE7MA/59EaDigKqPWFUu5RpgmzQm o1pkRcLf3Xo5w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-08v.sys.comcast.net with comcast id d7uH1s00G1nMCLR017uH4G; Fri, 01 Apr 2016 19:54:18 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u31JsHx4001003; Fri, 1 Apr 2016 15:54:17 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u31JsGna001000; Fri, 1 Apr 2016 15:54:16 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: gen-art@ietf.org, draft-ietf-bfd-seamless-use-case.all@ietf.org, ietf@ietf.org, rtg-bfd@ietf.org Subject: Gen-ART IETF Last Call review of draft-ietf-bfd-seamless-use-case-04 Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 01 Apr 2016 15:54:16 -0400 Message-ID: <87pou9p0k7.fsf@hobgoblin.ariadne.com> Archived-At: X-Mailman-Approved-At: Mon, 04 Apr 2016 06:20:33 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 19:54:21 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-bfd-seamless-use-case-04 Reviewer: Dale R. Worley Review Date: 2016-04-01 IETF LC End Date: 2016-04-12 IESG Telechat date: 2016-05-05 Summary: This draft is on the right track but has open issues, described in the review. Major issues: In various places the description needs to be made clearer. I believe that the authors have a good idea of what is intended, but in some places the descriptions are not clear to the general reader. Nits/editorial comments: There are various problems with English usage (e.g., missing articles) and punctuation (e.g., excessive commas), which can be taken care of by the Editor. But the overall structure and clarity of several paragraphs needs improvement. ---------------------------------------------------------------------- General What is the meaning of "seamless"? The term "seamless BFD" is used in the title and in the title of section 2, "Introduction to Seamless BFD", and in exactly one other place in the document: If this information is already known to the end-points of a potential BFD session, the initial handshake including an exchange of this node-specific information is unnecessary and it is possible for the end points to begin BFD messaging seamlessly. At no point is "seamless BFD" or the specific meaning of "seamless" defined. I suspect that the authors have a strong intuitive sense of the behaviors they identify as "seamless", and it would be helpful if that could be stated in the Introduction. Abstract The Abstract reads: This document provides various use cases for Bidirectional Forwarding Detection (BFD) and various requirements such that extensions could be developed to allow for simplified detection of forwarding failures. It seems unlikely that adding extensions to a protocol will "simplify" it (other than in the case of "MPLS BFD Session Per ECMP Path"), so it seems that the Abstract could be phrased better. It seems like a major goal of the draft is making it possible to accelerate the establishment of a BFD session. But that is not mentioned in the Abstract. Section 1 Bidirectional Forwarding Detection (BFD) is a lightweight protocol, as defined in [RFC5880], used to detect forwarding failures. Various protocols and applications rely on BFD for failure detection. Even though the protocol is simple, there are certain use cases, where faster setting up of sessions and continuity check of the data forwarding paths is necessary. This document identifies various use cases and requirements related to those, such that necessary enhancements could be made to BFD protocol. The phrase "Even though the protocol is simple" is not relevant to the remainder of the sentence it appears in and probably can be deleted. "This document..." would better be "This document identifies these use cases and the consequent requirements for extensions to the BFD protocol." The phrase "continuity check of the data forwarding paths" seems to be disconnected. I suspect the problem is a lack of parallelism, due to "setting up" and "check". You probably want to say "faster setting up of sessions and faster continuity checking of the data forwarding paths". The phrase "complexity, not only from an operations point of view, but also in terms of the speed at which these sessions could be established or deleted" attaches "speed" to "complexity", which isn't quite correct. Better would be "creates operational complexity, but also causes undesirable delay in establishing or deleting sessions" Section 2 The second paragraph says: In order for BFD to be able to initially verify that a connection is valid and that it connects the expected set of end points, it is necessary to provide the node information associated with the connection at each end point prior to initiating BFD sessions, such that this information can be used to verify that the connection is up and verifiable. I think it would help if the nature of the "node information" was made explicit. It seems like this paragraph strongly related to the aspect of BFD that is *not* defined in RFC 5880: The method of demultiplexing the initial packets (in which Your Discriminator is zero) is application dependent, and is thus outside the scope of this specification. Presumably the "node information" is what is used to perform the demultiplexing of the initial packets. Explaining this in more detail might make the design problem(s) clearer to the inexperienced reader. The third paragraph seems to be about accelerating the establishment of a BFD session between two nodes. With baseline BFD, establishing a session requires the two nodes to exchange BFD packets, which include the discriminators assigned by each node to the session. It seems that a goal of this draft is to avoid needing to exchange the initial packets before the BFD session is established, with the goal of getting to the established state more quickly. But this is not explicitly stated, nor is the manner in which "seamless BFD" would avoid it. As far as I can tell, the problem is that before a session is established, BFD is limited to sending one packet per second, and so the establishment of a session requires one or two seconds, regardless of the speed of the link. If the time to establish a BFD session is of central concern, it would be helpful to present an analysis of how long it takes baseline BFD to establish a session, and how long it might take an alternative BFD startup method to establish a session. In addition to the discriminators, the initial BFD packets also include the BFD packet interval parameters, "Detect Mult", "Desired Min TX Interval", "Required Min RX Interval", and "Required Min Echo RX Interval". What allows BFD to have a very short Detection Time in favorable situations is that the interval parameters can be much shorter than one second. But that implies that any system for quick-starting a BFD session has to transmit the interval parameters as well as the discriminators, or the BFD startup process still has to exchange packets before the full sending rate has been established. Then again, perhaps the phrase "node information" in this paragraph includes the interval parameters, instead of just the discriminators mentioned in the previous paragraph, in which case that should be made clearer. Is the fourth paragraph a description of the proposed "seamless BFD" and how it differs from baseline BFD? The fourth paragraph contains "Each of those network entities is assigned a BFD discriminator, to establish a BFD session." But this seems to be incorrect -- each network entity is assigned a BFD discriminator for each BFD session that the entity will participate in (RFC 5880 section 6.3). I can't tell whether this is a fundamental misunderstanding on the part of the authors, merely incorrect wording, or if S-BFD includes a technique by which a node can use the same discriminator for all of its BFD sessions -- that should be clarified. Section 3.1 This section isn't clear about the distinction between "verifying forwarding in one direction only" and "not needing to provision the target node, only the source node" -- the first is a relaxation on the requirements on what BFD detects, the second is a strengthening on the requirements on how BFD can be configured. Despite saying that the target would not need to be configured, as discussed in this section, BFD would still need to be configured at the target node to know the discriminator of the source node: "When the targeted network entity receives the packet, it knows that BFD packet, based on the discriminator and processes it." I am not understanding the sense in which "unidirectional" is being used. It seems that the only need is to verify transmission in one direction between the two nodes. The target node can verify successful transmission if it receives the control packets from the source node. But the source node can only know that transmission is working if it receives reply nodes from the target node. So despite that only needing to test transmission in one direction, transmission must be done in both directions. Or the purpose to send the live/dead determination to the "centralized controller", and it is not required that the source know the state of the path? Section 3.2 The first paragraph is BFD provides data delivery confidence when reachability validation is performed prior to traffic utilizing specific paths/LSPs. However this comes with a cost, where, traffic is prevented to use such paths/LSPs until BFD is able to validate the reachability, which could take seconds due to BFD session bring-up sequences [RFC5880], LSP ping bootstrapping [RFC5884], etc. This use case could be well supported by eliminating the need for session negotiation and discriminator exchanges in order to establish the BFD session. As far as I can tell, the use case is "when reachability validation is performed prior to traffic utilizing specific paths/LSPs". But the first sentence isn't structured to emphasize that, so it's difficult to tell what "This use case" means. Better would be some thing like This use case is when BFD is used to verify reachability before sending traffic via a path/LSP. This comes with a cost, which is that traffic is prevented to use the path/LSP until BFD is able to validate the reachability, which could take seconds ... . This use case would be better supported by eliminating the need for the initial BFD session negotiation. The second paragraph says "All it takes is for the network entities to know what the discriminator values to be used for the session." But as in section 2, the interval parameters must be configured as well before a BFD session is functioning. Section 3.3 The last two paragraphs are Traditional BFD session establishment and validation of the forwarding path must not become a bottleneck in the case of centralized traffic engineering. If the controller or other centralized entity is able to instantly verify a forwarding path of the TE tunnel , it could steer the traffic onto the traffic engineered tunnel very quickly thus minimizing adverse effect on a service. This is especially useful and needed when the scale of the network and number of TE tunnels is very high. Don't use the word "instantly": Nothing happens "instantly" if it involves events at two or more physically distinct locations. (299,792,458 metres per second -- It's not just a good idea, it's the law!) The cost associated with BFD session negotiation and establishment of BFD sessions to identify valid paths is very high and providing network redundancy becomes a critical issue. It would help to specify that the "cost" is primarily due to the time delay: "The cost associated with the time required for BFD session negotiation and ... is very high when providing network redundancy is a critical issue." Section 3.4 The final paragraph is: To support this use case, BFD MUST be able to perform liveness detection initated from centralized controller for any given segment under its domain. This isn't a requirement on BFD per se, it's a requirement on the agents that implement BFD in nodes. But that is not a protocol requirement either, since this document isn't specifying a protocol between a centralized controller and a BFD agent. I think what is intended is that there should be a standard way by which a centralized controller can instruct the two BFD agents in two nodes to initiate a BFD session along a path, and then can then monitor whether the BFD session determines that the path between the nodes is working. But if so, that should be stated clearly. Section 3.5 The final paragraph is: The established BFD session parameters and attributes like transmission interval, receiver interval, etc., MUST be modifiable without changing the state of the session. Unfortunately, the term "state" has this definition (RFC 5880 section 4.1): State (Sta) The current BFD session state as seen by the transmitting system. Values are: 0 -- AdminDown 1 -- Down 2 -- Init 3 -- Up It seems to me that the requirement is better captured by the last sentence of the preceding paragraph: "In these scenarios, it is desirable for BFD to slow down, speed up, stop or resume at will witho minimal [sic] additional BFD packets exchanged to establish a new or modified session." But that sentence is not quite good enough, since what the preceding part of the paragraph asked for was "... with no additional BFD packets exchanged", whereas the final sentence says "minimal". What is the requirement? If it is "no additional packets", that's clear. If what is needed is a reduction in the additional packets, it would help if there was an analysis of how many additional packets are now needed and what potential reduction might be obtained, so that the reader has some idea what "minimal" means. Section 3.6 First, this use case needs to make it clear what it is testing: That a source node can send a packet to an anycast address, and that the target node to which the packet is delivered can send a response packet to the source node. Of course, baseline BFD doesn't verify that, because it does not provide for a set of BFD agents to collectively form one endpoint of a BFD session. Within that goal, there is an additional requirement that there is no need to establish separate BFD sessions between the source node and every node that receives for the anycast address. But there is an ambiguity -- is it required that target nodes that do not happen to receive any of the BFD packets do not need to maintain any state, or is it that the source node does not need to maintain separate state for each target node? Section 3.7 This section talks about fault isolation very abstractly. Is there a definition as to what constitutes fault isolation? (Or is this definition well-known in the routing world?) Section 3.8 With distributed architectures of BFD implementations, this can be protected, if a node was to run multiple BFD sessions to targets, hosted on different parts of the system (ex: different CPU instances). This can reduce BFD false failures, resulting in more stable network. This is true, but it is not clear what the new requirements are. I see in RFC 5880 section 6.3 Since multiple BFD sessions may be running between two systems, there needs to be a mechanism for demultiplexing received BFD packets to the proper session. ... The method of demultiplexing the initial packets (in which Your Discriminator is zero) is application dependent, and is thus outside the scope of this specification. Is the question one of how to demultiplex the initial packets from multiple BFD sessions in the same source device? Section 3.9 [no complaints] Section 4 It would help if there were cross-references between the scenarios/use cases and the requirements. REQ#1 "MUST start processing for the discriminator" is unclear. Does this mean "MUST establish a session", "MUST be able to send a response", or what? REQ#2 See comments on section 3.1. REQ#3 Does this include not needing to exchange interval parameters as well? REQ#4 I suspect this requirement is only operational in the scenario of section 3.4, a Segment Routed network. It might be useful to qualify the requirement this way, since otherwise "centralized controller" and "segment" don't have a context. Or is S-BFD only intended for situations with a centralized controller? REQ#5 See comments for section 3.5. REQ#6 "This requirement does not require BFD session establishment with every node hosting the anycast address." is not what is intended. Rather, it should be something like appending "... without establishing a separate BFD session with every node hosing the anycast address" to the first session. As written, the requirement "does not require session establishment with every node" whereas the intention is to "require that there not be session establishment with every node". REQ#7 See comments for section 3.7. From nobody Mon Apr 4 15:16:13 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B17E12D8D7; Mon, 4 Apr 2016 15:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl9iwtL8y6yN; Mon, 4 Apr 2016 15:16:09 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B9A12D8CC; Mon, 4 Apr 2016 15:16:09 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-b9-5702e7830277 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 9C.C7.22441.387E2075; Tue, 5 Apr 2016 00:15:31 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 18:16:08 -0400 From: Gregory Mirsky To: "rtg-bfd@ietf.org" , "mpls@ietf.org" Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byA== Date: Mon, 4 Apr 2016 22:16:07 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A3CCEDeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPlG7zc6Zwg/e9shafHl5itjiw6SCj xbrLp9gsbi1dyWqx5PY9dovPf7YxOrB57Jx1l91jyZKfTB5fLn9mC2CO4rJJSc3JLEst0rdL 4Mq4tPMxS8Edg4q56xIbGJdpdzFyckgImEh8uT2NBcIWk7hwbz1bFyMXh5DAUUaJXTvnsEI4 yxglZv49ww5SxSZgJPFiYw+YLSLgJbFi8ipmkCJmgXYmiYMP9oGNEhawlXj9/Q1UkZPEhyuL WSFsPYnDazaBxVkEVCSWfZkLVs8r4Ctx8eBLZhCbEeiM76fWMIHYzALiEreezGeCOE9AYsme 88wQtqjEy8f/WCFsJYmPv+ezQ9TnS/SvbWaHmCkocXLmE5YJjMKzkIyahaRsFpIyiLiOxILd n9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7S4ICc33chwEyMwso5JsDnuYNzb63mIUYCDUYmH d8EpxnAh1sSy4srcQ4wSHMxKIrz7HjKFC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1jvwXJiSQ nliSmp2aWpBaBJNl4uCUamDM2Gzw/4e8oJfHB383ua4fTQvXex/IE9R4FXP6l9bXXf33/YVZ C9+F6T88Nr20/YqfX2qOZ1jrFAfXny97VlzrfNi34Meh5N9SNpLJht/O+CQ9O77qo9yZ5XmH by4VEGbTSu1f+88kbXZaDuPOTQePVmxf2s1XJ7Lim9lvBusX/+trxU7ZrLisxFKckWioxVxU nAgAIqprH6gCAAA= Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd-chairs@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:16:11 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A3CCEDeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A3CCEDeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

two new drafts, related to RFC 7130, were published = before the meeting:

·         BFD on MC-LAG interfaces in IP network<= o:p>

·         BFD on MC-LAG interfaces in IP/MPLS netwo= rk

 

Greatly appreciate your reviews, comments, questions= and suggestions.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF11221A3CCEDeusaamb103erics_-- From nobody Mon Apr 4 15:23:18 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C83712D8BE; Mon, 4 Apr 2016 15:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dWzUQcHxFOPG; Mon, 4 Apr 2016 15:23:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CB84F12D190; Mon, 4 Apr 2016 15:23:12 -0700 (PDT) Received: from [172.29.97.1] (unknown [66.129.239.15]) by slice.pfrc.org (Postfix) with ESMTPSA id 88B831E384; Mon, 4 Apr 2016 18:27:16 -0400 (EDT) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FEE1AF2A-A2AE-4E9C-B4FF-7333D4D8EF4F" From: Jeffrey Haas In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> Date: Mon, 4 Apr 2016 19:23:05 -0300 Message-Id: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:23:14 -0000 --Apple-Mail=_FEE1AF2A-A2AE-4E9C-B4FF-7333D4D8EF4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Working Group, These documents reasonably extend the existing BFD on LAG mechanism and = would be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the = other co-authors state whether there's any known IPR on these documents? -- Jeff > On Apr 4, 2016, at 7:16 PM, Gregory Mirsky = wrote: >=20 > Dear All, > two new drafts, related to RFC 7130, were published before the = meeting: > =C2=B7 BFD on MC-LAG interfaces in IP network = > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network = > =20 > Greatly appreciate your reviews, comments, questions and suggestions. > =20 > Regards, > Greg --Apple-Mail=_FEE1AF2A-A2AE-4E9C-B4FF-7333D4D8EF4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Working Group,

These documents reasonably extend the existing BFD on LAG = mechanism and would be reasonably in charter for BFD to pick = up.

Greg, = given that adoption seems a reasonable course, could you and the other = co-authors state whether there's any known IPR on these = documents?

-- = Jeff

On = Apr 4, 2016, at 7:16 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear = All,
two new = drafts, related to RFC 7130, were published before the meeting:
=C2=B7         BFD on = MC-LAG interfaces in IP network
=C2=B7         BFD on = MC-LAG interfaces in IP/MPLS network
 
Greatly appreciate your reviews, = comments, questions and suggestions.
 
Regards,
        = Greg

= --Apple-Mail=_FEE1AF2A-A2AE-4E9C-B4FF-7333D4D8EF4F-- From nobody Mon Apr 4 15:31:43 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAE112D8D7; Mon, 4 Apr 2016 15:31:41 -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 cBjfku9MEed7; Mon, 4 Apr 2016 15:31:33 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E84E12D594; Mon, 4 Apr 2016 15:31:33 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-1d-5702e524af96 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id C9.54.30335.425E2075; Tue, 5 Apr 2016 00:05:25 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 18:31:32 -0400 From: Gregory Mirsky To: Jeffrey Haas Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAI06KAAAgpRTA= Date: Mon, 4 Apr 2016 22:31:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A3CD69eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyuXRPoK7qU6Zwg9M7+C0+PbzEbHFg00FG i/0H37JarLt8is3i1tKVrBaf/2xjdGDz2DnrLrvHkiU/mTwu925l9fhy+TNbAEsUl01Kak5m WWqRvl0CV8acrrnMBStSK87uWsXSwHgiqYuRk0NCwERiSm8rM4QtJnHh3no2EFtI4CijxPRD Pl2MXED2MkaJyUdmMIEk2ASMJF5s7GEHsUUEFCXm/+9kAyliFpjFJDHv7k+wbmEBR4nv868x QxQ5SXy4spgVwraS+LBoPQuIzSKgIrFw+S6wOK+Ar8S6r6uZITbXS5zdvgdsGaeAjcTDp9fB bEag676fWgNmMwuIS9x6Mp8J4moBiSV7zkN9ICrx8vE/VghbSeLj7/nsEPX5EmvmLYHaJShx cuYTlgmMorOQjJqFpGwWkrJZjBxAcU2J9bv0IUoUJaZ0P2SHsDUkWufMZUcWX8DIvoqRo7S4 ICc33chgEyMwIo9JsOnuYLw/3fMQowAHoxIP74JTjOFCrIllxZW5hxglOJiVRHj3PWQKF+JN SaysSi3Kjy8qzUktPsQozcGiJM7bGPwvTEggPbEkNTs1tSC1CCbLxMEp1cDYm73ztVinHEfr 0a+WfckPdLm2N7icYi986a2f+nK+t8XD9ra351Xm7uc8GFta9lt6R/I81iOvni6w9hXU4Njt cnuakcPZY3Xx336ycBdyuJlqp2QILhQWr2079+NPy9yqMzKZ0wXOpviofJuTUFVWJvsvs87g ZcuLlxqzuM8u7TFv53qnvV2JpTgj0VCLuag4EQAVidT+xAIAAA== Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:31:41 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A3CD69eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmVmZiwNCndlIGhhdmUgbm90IGV4cGVjdGVkIHRoaXMgcXVlc3Rpb24gdGhhdCBlYXJseSDi mLoNClllcywgdGhlcmXigJlzIElQUiBhc3NvY2lhdGVkIHdpdGggdGhlc2UgZHJhZnRzIHRoYXQg d291bGQgYmUgcHJvcGVybHkgZGlzY2xvc2VkIGFmdGVyIHRoZSBtZWV0aW5nLg0KDQogICAgICAg ICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0K DQpGcm9tOiBKZWZmcmV5IEhhYXMgW21haWx0bzpqaGFhc0BwZnJjLm9yZ10NClNlbnQ6IE1vbmRh eSwgQXByaWwgMDQsIDIwMTYgMzoyMyBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5DQpDYzogcnRnLWJm ZEBpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWct aXBAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnOyBtcGxzLWNoYWlyc0Bp ZXRmLm9yZzsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb20pDQpTdWJqZWN0OiBSZTogVHdv IG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNlcw0KDQpXb3Jr aW5nIEdyb3VwLA0KDQpUaGVzZSBkb2N1bWVudHMgcmVhc29uYWJseSBleHRlbmQgdGhlIGV4aXN0 aW5nIEJGRCBvbiBMQUcgbWVjaGFuaXNtIGFuZCB3b3VsZCBiZSByZWFzb25hYmx5IGluIGNoYXJ0 ZXIgZm9yIEJGRCB0byBwaWNrIHVwLg0KDQpHcmVnLCBnaXZlbiB0aGF0IGFkb3B0aW9uIHNlZW1z IGEgcmVhc29uYWJsZSBjb3Vyc2UsIGNvdWxkIHlvdSBhbmQgdGhlIG90aGVyIGNvLWF1dGhvcnMg c3RhdGUgd2hldGhlciB0aGVyZSdzIGFueSBrbm93biBJUFIgb24gdGhlc2UgZG9jdW1lbnRzPw0K DQotLSBKZWZmDQoNCk9uIEFwciA0LCAyMDE2LCBhdCA3OjE2IFBNLCBHcmVnb3J5IE1pcnNreSA8 Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nv bi5jb20+PiB3cm90ZToNCg0KRGVhciBBbGwsDQp0d28gbmV3IGRyYWZ0cywgcmVsYXRlZCB0byBS RkMgNzEzMCwgd2VyZSBwdWJsaXNoZWQgYmVmb3JlIHRoZSBtZWV0aW5nOg0K4oCiICAgICAgICAg QkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQIG5ldHdvcms8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwLTAwPg0K4oCiICAgICAg ICAgQkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctbXBscy0wMD4N Cg0KR3JlYXRseSBhcHByZWNpYXRlIHlvdXIgcmV2aWV3cywgY29tbWVudHMsIHF1ZXN0aW9ucyBh bmQgc3VnZ2VzdGlvbnMuDQoNClJlZ2FyZHMsDQogICAgICAgIEdyZWcNCg0K --_000_7347100B5761DC41A166AC17F22DF11221A3CD69eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHls ZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBKZWZmLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj53ZSBoYXZlIG5vdCBleHBlY3RlZCB0aGlzIHF1ZXN0aW9uIHRoYXQgZWFybHkNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgdGhlcmXigJlzIElQUiBh c3NvY2lhdGVkIHdpdGggdGhlc2UgZHJhZnRzIHRoYXQgd291bGQgYmUgcHJvcGVybHkgZGlzY2xv c2VkIGFmdGVyIHRoZSBtZWV0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmVmZnJleSBIYWFzIFttYWlsdG86amhh YXNAcGZyYy5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAwNCwgMjAxNiAz OjIzIFBNPGJyPg0KPGI+VG86PC9iPiBHcmVnb3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj4gcnRn LWJmZEBpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1s YWctaXBAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnOyBtcGxzLWNoYWly c0BpZXRmLm9yZzsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb20pPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxBRyBpbnRl cmZhY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V29y a2luZyBHcm91cCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZXNlIGRvY3VtZW50cyByZWFzb25hYmx5IGV4dGVuZCB0aGUgZXhpc3RpbmcgQkZEIG9uIExB RyBtZWNoYW5pc20gYW5kIHdvdWxkIGJlIHJlYXNvbmFibHkgaW4gY2hhcnRlciBmb3IgQkZEIHRv IHBpY2sgdXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkdyZWcsIGdpdmVuIHRoYXQgYWRvcHRpb24gc2VlbXMgYSByZWFzb25hYmxlIGNvdXJz ZSwgY291bGQgeW91IGFuZCB0aGUgb3RoZXIgY28tYXV0aG9ycyBzdGF0ZSB3aGV0aGVyIHRoZXJl J3MgYW55IGtub3duIElQUiBvbiB0aGVzZSBkb2N1bWVudHM/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIEplZmY8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEFwciA0LCAyMDE2LCBhdCA3OjE2IFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSI+Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlYXIgQWxsLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHdvIG5ldyBkcmFmdHMsIHJlbGF0ZWQgdG8gUkZDIDcxMzAs IHdlcmUgcHVibGlzaGVkIGJlZm9yZSB0aGUgbWVldGluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwLTAwIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5CRkQNCiBvbiBNQy1MQUcgaW50ZXJmYWNlcyBpbiBJUCBuZXR3b3JrPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7C tzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRhbm1pci1ydGd3Zy1i ZmQtbWMtbGFnLW1wbHMtMDAiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkJGRA0KIG9uIE1D LUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIHJldmlld3MsIGNvbW1lbnRzLCBxdWVzdGlvbnMgYW5k IHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjI1aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF11221A3CD69eusaamb103erics_-- From nobody Mon Apr 4 15:36:19 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3089F12D8E7 for ; Mon, 4 Apr 2016 15:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LtXwTuIj1UYy for ; Mon, 4 Apr 2016 15:35:52 -0700 (PDT) Received: from BLU004-OMC4S29.hotmail.com (blu004-omc4s29.hotmail.com [65.55.111.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BC712D8E2 for ; Mon, 4 Apr 2016 15:35:51 -0700 (PDT) Received: from BLU436-SMTP177 ([65.55.111.136]) by BLU004-OMC4S29.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 4 Apr 2016 15:35:50 -0700 X-TMN: [5q7lK/Pfu99reJesH1yKmB5Ha0UW7lif] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Mon, 4 Apr 2016 19:35:37 -0300 Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces From: Ashesh Mishra To: Gregory Mirsky , Jeffrey Haas Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_3542643347_2406844" X-OriginalArrivalTime: 04 Apr 2016 22:35:48.0659 (UTC) FILETIME=[55E90830:01D18EC2] Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:36:06 -0000 --B_3542643347_2406844 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Authors, Quick note on both drafts. They do not indicate how the BFD state is coordinated across the MC-LAG. =8B=8B Node B Node A | =8B=8B Node C If one member link between A and B fails, how is the info propagated to BFD on node C? Does the system rely on LACP? Regards, Ashesh From: Rtg-bfd on behalf of Gregory Mirsky Date: Monday, April 4, 2016 at 7:31 PM To: Jeffrey Haas Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas (akatlas@gmail.com)" Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Jeff, we have not expected this question that early J Yes, there=B9s IPR associated with these drafts that would be properly disclosed after the meeting. =20 Regards, Greg =20 From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces =20 Working Group, =20 These documents reasonably extend the existing BFD on LAG mechanism and would be reasonably in charter for BFD to pick up. =20 Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? =20 -- Jeff =20 > On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: > =20 >=20 > Dear All, >=20 > two new drafts, related to RFC 7130, were published before the meeting: >=20 > =B7 BFD on MC-LAG interfaces in IP network > >=20 > =B7 BFD on MC-LAG interfaces in IP/MPLS network > >=20 > =20 >=20 > Greatly appreciate your reviews, comments, questions and suggestions. >=20 > =20 >=20 > Regards, >=20 > Greg =20 --B_3542643347_2406844 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Authors,

<= /div>
Quick note on both drafts. They do not indicate how the BFD state = is coordinated across the MC-LAG. 

  &nbs= p;            —— Node B
= Node A |
               &#= 8212;— Node C

If one member link between A an= d B fails, how is the info propagated to BFD on node C?

=
Does the system rely on LACP? 

Regards,
Ashesh


From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Monday, April 4, 2016 at 7:31 PM<= br>To: Jeffrey Haas <jhaas@pfrc.org>
= Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-la= g-ip@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "mpls-c= hairs@ietf.org" <mpls-chairs@ie= tf.org>, "Alia Atlas (akatlas@gmai= l.com)" <akatlas@gmail.com>=
Subject: RE: Two new drafts on (m= icro-)BFD over MC-LAG interfaces

Hi Jeff,

we have not expected t= his question that early J=

 

&nb= sp;            &= nbsp;  Regards,

            &nb= sp;            &= nbsp;      Greg

 

From= := Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsk= y
Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ie= tf.org; rtg-bfd-chairs@ietf.org= ; mpls-chairs@ietf.org; Alia A= tlas (akatlas@gmail.com)
Subjec= t: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Working Group,

 

These documents reasonably extend th= e existing BFD on LAG mechanism and would be reasonably in charter for BFD t= o pick up.

 

Greg, given that adoption seems a reasonab= le course, could you and the other co-authors state whether there's any know= n IPR on these documents?

 

-- Jeff

 

On Ap= r 4, 2016, at 7:16 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

 

Dear All,

two new drafts, related to RFC 7130, wer= e published before the meeting:

=B7   &nbs= p;     <= /span>BFD on MC-LAG interfaces in IP network

<= div style=3D"margin-left:.5in">

=B7 =         BFD on MC-LAG interfaces in IP/MPLS network

 

Greatly = appreciate your reviews, comments, questions and suggestions.

 

Regards,

   &nbs= p;    Greg

 

<= /body> --B_3542643347_2406844-- From nobody Mon Apr 4 15:41:12 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4B312D8EA for ; Mon, 4 Apr 2016 15:41:10 -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 AJoxZhh8F56y for ; Mon, 4 Apr 2016 15:41:08 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670CD12D8E6 for ; Mon, 4 Apr 2016 15:41:08 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-84-5702e7633dce Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 9C.B4.30335.367E2075; Tue, 5 Apr 2016 00:14:59 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 18:41:06 -0400 From: Gregory Mirsky To: Ashesh Mishra , Jeffrey Haas Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAI06KAAAgpRTD//8I2gIAAQsVg Date: Mon, 4 Apr 2016 22:41:05 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3CDD6@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A3CDD6eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyuXRPlG7yc6Zwg8l3zC0+PbzEbHFg00FG i/0H37JazGqbwmrx+c82RgdWj52z7rJ7LFnyk8lj8+sXzB6Xe7eyeny5/JktgDWKyyYlNSez LLVI3y6BK2NJ8yrGgkNLGStaDto3MC6cytjFyMkhIWAisa/9MBuELSZx4d56IJuLQ0jgKKPE oqcL2SGcZYwSyxdsYwapYhMwknixsYcdxBYR8JG4s78ZrIhZ4ASjxJuzH1lBEsICjhLf519j hihykvhwZTErhO0mcezrRCYQm0VARWLbxENgg3gFfCVW3n4Btfo7o8SNkxPAbuIUsJPY1v4f bBAj0H3fT60Ba2YWEJe49WQ+E8TdAhJL9pxnhrBFJV4+/scKYStJfPw9nx2iPl/i85ejzBDL BCVOznzCMoFRdBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMXKUFhfk 5KYbGWxiBEbmMQk23R2M96d7HmIU4GBU4uFdcIoxXIg1say4MvcQowQHs5II776HTOFCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEeRuD/4UJCaQnlqRmp6YWpBbBZJk4OKUaGCP1d8i8VZzx4KHH ZY7N5jsCVMxDFqesv3G9pfBL2KkXjhNYj68sszTWfvPZL+u1po5LYry2Llfs4d/ynP+MTu/8 Uel0a6aG+w/prMzORSlisp4hHNLhyh7Hdn2XefSgQGeP77zAzgvc/r1Zd1v+umTffNYZf+lj 95/nuswfS9dk3uL/whfRrcRSnJFoqMVcVJwIAHffqTrIAgAA Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:41:10 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A3CDD6eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashesh, as in RFC 7130, each BFD session on an interface is independent. The BFD st= ate change may be available to LACP and/or LAG manager in the node. LAG sta= te coordination is outside of scope but I speculate that one can use ICCP. Regards, Greg From: Ashesh Mishra [mailto:mishra.ashesh@outlook.com] Sent: Monday, April 04, 2016 3:36 PM To: Gregory Mirsky; Jeffrey Haas Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.org; Alia= Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Authors, Quick note on both drafts. They do not indicate how the BFD state is coordi= nated across the MC-LAG. -- Node B Node A | -- Node C If one member link between A and B fails, how is the info propagated to BFD= on node C? Does the system rely on LACP? Regards, Ashesh From: Rtg-bfd > o= n behalf of Gregory Mirsky > Date: Monday, April 4, 2016 at 7:31 PM To: Jeffrey Haas > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "mpls@ie= tf.org" >, "rtg-b= fd@ietf.org" >, "mpls-chairs@ietf.org" >, "Alia Atlas (akatlas@gmail.com)" > Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Jeff, we have not expected this question that early :) Yes, there's IPR associated with these drafts that would be properly disclo= sed after the meeting. Regards, Greg From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Ali= a Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Working Group, These documents reasonably extend the existing BFD on LAG mechanism and wou= ld be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? -- Jeff On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A3CDD6eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ashesh,

as in RFC 7130, each BFD = session on an interface is independent. The BFD state change may be availab= le to LACP and/or LAG manager in the node. LAG state coordination is outside of scope but I speculate that one can use ICCP.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Ashesh M= ishra [mailto:mishra.ashesh@outlook.com]
Sent: Monday, April 04, 2016 3:36 PM
To: Gregory Mirsky; Jeffrey Haas
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.or= g; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Authors,<= /p>

 

Quick note on both drafts. = They do not indicate how the BFD state is coordinated across the MC-LAG.&nb= sp;

 

       =        —— Node B

Node A |<= /p>

       =        —— Node C

 

If one member link between = A and B fails, how is the info propagated to BFD on node C?

 

Does the system rely on LAC= P? 

 

Regards,<= /p>

Ashesh

 

 

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Gregory Mirs= ky <gregory.mirsky@ericss= on.com>
Date: Monday, April 4, 2016 at 7:31 PM
To: Jeffrey Haas <jhaas@pfrc.or= g>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" <draft-tanmir= -rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com>= ;
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Jeff,

we have not expected this= question that early J

Yes, there’s IPR as= sociated with these drafts that would be properly disclosed after the meeti= ng.

 

    &= nbsp;           Regards,<= /span>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 

From: Jeffrey Haas [mailto:jhaa= s@pfrc.org]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-c= hairs@ietf.org; Alia Atlas (akatla= s@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 =

Working Group,

 =

These documents reasonab= ly extend the existing BFD on LAG mechanism and would be reasonably in char= ter for BFD to pick up.

 =

Greg, given that adoptio= n seems a reasonable course, could you and the other co-authors state wheth= er there's any known IPR on these documents?

 =

-- Jeff

 =

On Apr 4, 2016, at 7:16 = PM, Gregory Mirsky <grego= ry.mirsky@ericsson.com> wrote:

 =

Dear All,

two new drafts, related to = RFC 7130, were published before the meeting:

 

Greatly appreciate your rev= iews, comments, questions and suggestions.

 

Regards,

    &nb= sp;   Greg

 =

--_000_7347100B5761DC41A166AC17F22DF11221A3CDD6eusaamb103erics_-- From nobody Mon Apr 4 15:44:37 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62A712D8E6; Mon, 4 Apr 2016 15:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ0JstDY8hIz; Mon, 4 Apr 2016 15:44:31 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A419A12D8D3; Mon, 4 Apr 2016 15:44:31 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-1c-5702ee28737a Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 56.39.22441.82EE2075; Tue, 5 Apr 2016 00:43:52 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 18:44:29 -0400 From: Jeff Tantsura To: Gregory Mirsky Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAI06KAAAgpRTD//4Gh5w== Date: Mon, 4 Apr 2016 22:44:28 +0000 Message-ID: <33673FCF-6DF9-4E0F-9BA2-95D670259F76@ericsson.com> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> , <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_33673FCF6DF94E0F9BA295D670259F76ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyuXRPlK7GO6Zwg+lLTS0+PbzEbHFg00FG i/0H37JarLt8is3i1tKVrBaf/2xjdGDz2DnrLrvHkiU/mTwu925l9fhy+TNbAEsUl01Kak5m WWqRvl0CV8ajWx3sBStCK+Z2tTA1ME7w6WLk5JAQMJE4eWsaC4QtJnHh3nq2LkYODiGBo4wS Z9W7GLmAzGWMEt0vnzGD1LAJGEj8/3YcrF4EyL69bDkzSBGzwF4miRUbD4ElhAUcJY63zIQq cpL4cGUxK4y9eM83sDiLgIrEvfWf2UFsXgF7iZs/j7BBbDvIKPHifxcTSIJTwE9idXMLWBEj 0HXfT60BizMLiEvcejKfCeJqAYkle84zQ9iiEi8f/2OFqEmWWLxtKivEAkGJkzOfsExgFJmF pH0WkrJZSMog4gYS78/NZ4awtSWWLXwNZetLbPxylhFZfAEj+ypGjtLigpzcdCPDTYzA2Dsm wea4g3Fvr+chRgEORiUe3gWnGMOFWBPLiitzDzFKcDArifDue8gULsSbklhZlVqUH19UmpNa fIhRmoNFSZzXO/JfmJBAemJJanZqakFqEUyWiYNTqoFxVtmO4idb+blOPfuYwrqZ6fYmPeZl 9jd4Hyn1dfAI2CU+2HXfovmgypYUxz18X5afYkryfRg2LSp8zyktwxW2TIm57odTDx1qW77I 8+XrwFOT63/Onj/LosDtxrInnUnZ1QxzouX+7HgYt/m5eZVGh/HHyybmF6z2fTi1tbtj3bkv T6IDhdasU2Ipzkg01GIuKk4EAMlmkH65AgAA Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:44:34 -0000 --_000_33673FCF6DF94E0F9BA295D670259F76ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jeff, Thanks! IPR will be disclosed ASAP, we are pushing legal. Regards, Jeff On Apr 4, 2016, at 7:31 PM, Gregory Mirsky > wrote: Hi Jeff, we have not expected this question that early :) Yes, there=92s IPR associated with these drafts that would be properly disc= losed after the meeting. Regards, Greg From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Ali= a Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Working Group, These documents reasonably extend the existing BFD on LAG mechanism and wou= ld be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? -- Jeff On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: Dear All, two new drafts, related to RFC 7130, were published before the meeting: =95 BFD on MC-LAG interfaces in IP network =95 BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_33673FCF6DF94E0F9BA295D670259F76ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Jeff,

Thanks!

IPR will be disclosed ASAP, we are pushing l= egal.

Regards,
Jeff

On Apr 4, 2016, at 7:31 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Jeff,

we have not expected this= question that early J

Yes, there=92s IPR associ= ated with these drafts that would be properly disclosed after the meeting.<= o:p>

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Jeffrey = Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-c= hairs@ietf.org; Alia Atlas (akatla= s@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Working Group,

 

These documents reasonably extend the existing BFD o= n LAG mechanism and would be reasonably in charter for BFD to pick up.=

 

Greg, given that adoption seems a reasonable course,= could you and the other co-authors state whether there's any known IPR on = these documents?

 

-- Jeff

 

On Apr 4, 2016, at 7:16 PM, Gregory Mirsky <gregory.mirsky@ericsson.com&g= t; wrote:

 

Dear All,

two new drafts, related to RFC 7130, we= re published before the meeting:

=B7&nbs= p;        BFD on MC-LAG interfaces in IP network

=B7&nbs= p;        BFD on MC-LAG interfaces in IP/MPLS network

 

Greatly appreciate your reviews, commen= ts, questions and suggestions.

 

Regards,

      &nb= sp; Greg

 

--_000_33673FCF6DF94E0F9BA295D670259F76ericssoncom_-- From nobody Mon Apr 4 15:44:58 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C426F12D5E4 for ; Mon, 4 Apr 2016 15:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Nnc1fHtv4DZZ for ; Mon, 4 Apr 2016 15:44:54 -0700 (PDT) Received: from BLU004-OMC4S7.hotmail.com (blu004-omc4s7.hotmail.com [65.55.111.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2130C12D8F4 for ; Mon, 4 Apr 2016 15:44:53 -0700 (PDT) Received: from BLU436-SMTP212 ([65.55.111.137]) by BLU004-OMC4S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 4 Apr 2016 15:44:51 -0700 X-TMN: [FW5ZUVSSmcjX41T1J915dTZWux0UNjUc] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Mon, 4 Apr 2016 19:44:41 -0300 Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces From: Ashesh Mishra To: Gregory Mirsky , Jeffrey Haas Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A3CDD6@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CDD6@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_3542643889_2436793" X-OriginalArrivalTime: 04 Apr 2016 22:44:50.0154 (UTC) FILETIME=[98AA9CA0:01D18EC3] Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:44:57 -0000 --B_3542643889_2436793 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Fair enough. Perhaps stating this in the draft may be helpful. =8B Ashesh From: Gregory Mirsky Date: Monday, April 4, 2016 at 7:41 PM To: Ashesh Mishra , Jeffrey Haas Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd@ietf.org" , "Alia Atlas (akatlas@gmail.com)" Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Ashesh, as in RFC 7130, each BFD session on an interface is independent. The BFD state change may be available to LACP and/or LAG manager in the node. LAG state coordination is outside of scope but I speculate that one can use ICCP. =20 Regards, Greg =20 From: Ashesh Mishra [mailto:mishra.ashesh@outlook.com] Sent: Monday, April 04, 2016 3:36 PM To: Gregory Mirsky; Jeffrey Haas Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces =20 Authors, =20 Quick note on both drafts. They do not indicate how the BFD state is coordinated across the MC-LAG. =20 =8B=8B Node B Node A | =8B=8B Node C =20 If one member link between A and B fails, how is the info propagated to BFD on node C? =20 Does the system rely on LACP? =20 Regards, Ashesh =20 =20 From: Rtg-bfd on behalf of Gregory Mirsky Date: Monday, April 4, 2016 at 7:31 PM To: Jeffrey Haas Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas (akatlas@gmail.com)" Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces =20 Hi Jeff, we have not expected this question that early J Yes, there=B9s IPR associated with these drafts that would be properly disclosed after the meeting. =20 Regards, Greg =20 From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces =20 Working Group, =20 These documents reasonably extend the existing BFD on LAG mechanism and would be reasonably in charter for BFD to pick up. =20 Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? =20 -- Jeff =20 > On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: > =20 >=20 > Dear All, >=20 > two new drafts, related to RFC 7130, were published before the meeting: >=20 > =B7 BFD on MC-LAG interfaces in IP network > >=20 > =B7 BFD on MC-LAG interfaces in IP/MPLS network > >=20 > =20 >=20 > Greatly appreciate your reviews, comments, questions and suggestions. >=20 > =20 >=20 > Regards, >=20 > Greg =20 --B_3542643889_2436793 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Fair enough. Perhaps stating = this in  the draft may be helpful. 

̵= 2;
Ashesh

From: Gregory Mirsky <gregor= y.mirsky@ericsson.com>
Date: Monday, April 4, 2016 at 7:41 PM
To: Ashesh Mishra <mishra.ash= esh@outlook.com>, Jeffrey Haas <jh= aas@pfrc.org>
Cc: "draft-tanmir-rtgwg-= bfd-mc-lag-ip@tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com>
Subj= ect: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Ashesh,<= o:p>

as in RFC 7130, each= BFD session on an interface is independent. The BFD state change may be ava= ilable to LACP and/or LAG manager in the node. LAG state coordination is outside of scope but I speculate that one can use ICCP.

 

        =         Regards,

       &n= bsp;            =             Greg=

 =

From: Ashesh Mishra [mailto:mishra.ashesh@outlook.com]
Sent: Monday, April 04, 2016 3:36 PM
To: Gregory Mirsk= y; Jeffrey Haas
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new= drafts on (micro-)BFD over MC-LAG interfaces

 

= Authors,

 

Quick note on b= oth drafts. They do not indicate how the BFD state is coordinated across the= MC-LAG. 

 

    =            —— Node B

Node A |

<= /div>

           = ;    —— Node C

 

If one member link between A and B fails, how is the info propagated= to BFD on node C?

 

Does the s= ystem rely on LACP? 

 

Reg= ards,

Ashesh<= /o:p>

 

 

=

From: Rtg-bfd <rtg-bfd= -bounces@ietf.org> on behalf of Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: <= /b>Monday, April 4, 2016 at 7:31 PM
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "draft-tanmir-rtgwg-bfd-mc-= lag-ip@tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>,= "mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "mpls-cha= irs@ietf.org" <mpls-chairs@ietf= .org>, "Alia Atlas (akatlas@gmail.com)" &l= t;akatlas@gmail.com>
Subject= : RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Jeff,

we hav= e not expected this question that early J=

= Yes, there’s IPR associated with these drafts that would= be properly disclosed after the meeting.

 

&= nbsp;            = ;   Regards,

      &nbs= p;            &n= bsp;            Greg<= /span>

<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31= , 73, 125);"> 

From: Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsk= y
Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-cha= irs@ietf.org; Alia Atlas (akatlas@gma= il.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG= interfaces

 

Working Group,

 

These = documents reasonably extend the existing BFD on LAG mechanism and would be r= easonably in charter for BFD to pick up.

 

Greg, given that adopt= ion seems a reasonable course, could you and the other co-authors state whet= her there's any known IPR on these documents?

 

-- Jeff

 =

On Ap= r 4, 2016, at 7:16 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

<= /div>

 =

Dear All,

two new drafts,= related to RFC 7130, were published before the meeting:

=B7  &nbs= p;      BFD on MC-LAG interfaces in IP network

 

Greatly appreciate your reviews, comments, questions and suggestio= ns.

 

Regards,

=

  &nb= sp;     Greg=

 

--B_3542643889_2436793-- From nobody Mon Apr 4 15:46:41 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A56412D8F7 for ; Mon, 4 Apr 2016 15:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEYCVmC3hZA1 for ; Mon, 4 Apr 2016 15:46:35 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0D312D8FC for ; Mon, 4 Apr 2016 15:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26437; q=dns/txt; s=iport; t=1459809995; x=1461019595; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=S8pMYl2oB4FYCMBDiwr0MA3zUtW1CkCcnKe1fl4Zv04=; b=CpPikWSlkEPc91WIy3TNzJGkbVBhrTBPI7fusYjFGG3dTBH8U11qSX49 onTeHZ3JJNWyEbsQrHtY4j8ZyOobWnErO8kC1dGqEm4jKKYae2dbzs6PE K3VuFjhhPlk5bXxfBuwf0oZCI6IDPJMWJyog2o78g3+PGDRSuhWbozzEt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQCO7QJX/4QNJK1dgmtMU30Gr0yLV?= =?us-ascii?q?QENgXIhhWwCgTs4FAEBAQEBAQFlJ4RBAQEBBC1MEAIBCBEDAQEBIQcHIREUCQg?= =?us-ascii?q?CBAENBYgSAxIOuXANC4R3AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIIRKgkGCH?= =?us-ascii?q?g0JhSAFjgWJSzEBhXKGIIF1jw+HRIdVAR4BAUKDZ2yHKH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,442,1454976000"; d="scan'208,217";a="256588460" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 22:46:33 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u34MkW46026017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 22:46:33 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 17:46:31 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 17:46:32 -0500 From: "Reshad Rahman (rrahman)" To: Ashesh Mishra , Gregory Mirsky , Jeffrey Haas Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAK7BOAAABLQAAAACTPgAAAMOCAAAAgL4D//71xAA== Date: Mon, 4 Apr 2016 22:46:32 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A3CDD6@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.252.249] Content-Type: multipart/alternative; boundary="_000_D32866E4138494rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:46:38 -0000 --_000_D32866E4138494rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Reshad (as individual contributor). From: Rtg-bfd > o= n behalf of Ashesh Mishra > Date: Monday, April 4, 2016 at 6:44 PM To: Gregory Mirsky >, Jeffrey Haas > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "rtg-bfd= @ietf.org" >, "Alia Atlas (akatlas@gmail.com)" > Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Fair enough. Perhaps stating this in the draft may be helpful. - Ashesh From: Gregory Mirsky > Date: Monday, April 4, 2016 at 7:41 PM To: Ashesh Mishra >, Jeffrey Haas > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "rtg-bfd= @ietf.org" >, "Alia Atlas (akatlas@gmail.com)" > Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Ashesh, as in RFC 7130, each BFD session on an interface is independent. The BFD st= ate change may be available to LACP and/or LAG manager in the node. LAG sta= te coordination is outside of scope but I speculate that one can use ICCP. Regards, Greg From: Ashesh Mishra [mailto:mishra.ashesh@outlook.com] Sent: Monday, April 04, 2016 3:36 PM To: Gregory Mirsky; Jeffrey Haas Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.org= ; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Authors, Quick note on both drafts. They do not indicate how the BFD state is coordi= nated across the MC-LAG. -- Node B Node A | -- Node C If one member link between A and B fails, how is the info propagated to BFD= on node C? Does the system rely on LACP? Regards, Ashesh From: Rtg-bfd > o= n behalf of Gregory Mirsky > Date: Monday, April 4, 2016 at 7:31 PM To: Jeffrey Haas > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "mpls@ie= tf.org" >, "rtg-b= fd@ietf.org" >, "mpls-chairs@ietf.org" >, "Alia Atlas (akatlas@gmail.com)" > Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Jeff, we have not expected this question that early :) Yes, there's IPR associated with these drafts that would be properly disclo= sed after the meeting. Regards, Greg From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Ali= a Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Working Group, These documents reasonably extend the existing BFD on LAG mechanism and wou= ld be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? -- Jeff On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: Dear All, two new drafts, related to RFC 7130, were published before the meeting: =B7 BFD on MC-LAG interfaces in IP network =B7 BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_D32866E4138494rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
+1 

Reshad (as individual contributor).

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of As= hesh Mishra <mishra.ashesh@= outlook.com>
Date: Monday, April 4, 2016 at 6:44= PM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, Jef= frey Haas <jhaas@pfrc.org>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@= tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>= ;, "rtg-bfd@ietf.org" <<= a href=3D"mailto:rtg-bfd@ietf.org">rtg-bfd@ietf.org>, "Alia Atl= as (akatlas@gmail.com)" <<= a href=3D"mailto:akatlas@gmail.com">akatlas@gmail.com>
Subject: Re: Two new drafts on (mic= ro-)BFD over MC-LAG interfaces

Fair enough. Perhaps stating this in  the draft may be helpful.&n= bsp;

—
Ashesh

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Monday, April 4, 2016 at 7:41= PM
To: Ashesh Mishra <mishra.ashesh@outlook.com>, Jeffrey = Haas <jhaas@pfrc.org>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@= tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>= ;, "rtg-bfd@ietf.org" <<= a href=3D"mailto:rtg-bfd@ietf.org">rtg-bfd@ietf.org>, "Alia Atl= as (akatlas@gmail.com)" <<= a href=3D"mailto:akatlas@gmail.com">akatlas@gmail.com>
Subject: RE: Two new drafts on (mic= ro-)BFD over MC-LAG interfaces

Hi Ashesh,

as in RFC 7130, each BFD session on= an interface is independent. The BFD state change may be available to LACP= and/or LAG manager in the node. LAG state coordination is outside of scope but I speculate that one can use IC= CP.

 

      = ;          Regards,=

      = ;            &n= bsp;            = ; Greg

 

From: Ashesh Mishra [mailto:mishra.ashesh@outlook.com]
Sent: Monday, April 04, 2016 3:36 PM
To: Gregory Mirsky; Jeffrey Haas
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Authors,

 

Quick note on both drafts. They do not indic= ate how the BFD state is coordinated across the MC-LAG. 

 

            &n= bsp;  —— Node B

Node A |

            &n= bsp;  —— Node C

 

If one member link between A and B fails, ho= w is the info propagated to BFD on node C?

 

Does the system rely on LACP? 

 

Regards,

Ashesh

 

 

From: Rtg-bfd <rt= g-bfd-bounces@ietf.org> on behalf of Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Monday, April 4, 2016 at 7:31 PM
To: Jeffrey Haas <jhaas@pfrc.or= g>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" <draft-tanmir= -rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com>= ;
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Jeff,

we have not expected this question = that early J

Yes, there’s IPR associated w= ith these drafts that would be properly disclosed after the meeting.=

 

      = ;          Regards,

      = ;            &n= bsp;            = ; Greg

 

From: Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-c= hairs@ietf.org; Alia Atlas (akatla= s@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 =

Working Group,

 =

These documents reasonab= ly extend the existing BFD on LAG mechanism and would be reasonably in char= ter for BFD to pick up.

 =

Greg, given that adoptio= n seems a reasonable course, could you and the other co-authors state wheth= er there's any known IPR on these documents?

 =

-- Jeff

 =

On Apr 4, 2016, at 7:16 = PM, Gregory Mirsky <grego= ry.mirsky@ericsson.com> wrote:

 =

Dear All,

two new drafts, related to RFC 7130, were publ= ished before the meeting:

 =

Greatly appreciate your reviews, comments, que= stions and suggestions.

 =

Regards,

        Gre= g

 =

--_000_D32866E4138494rrahmanciscocom_-- From nobody Tue Apr 5 06:30:11 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582B112D94B; Tue, 5 Apr 2016 06:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ug-n10O9Nk3J; Tue, 5 Apr 2016 06:30:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C431E12D961; Tue, 5 Apr 2016 06:29:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 79ABE1E83B; Tue, 5 Apr 2016 09:33:52 -0400 (EDT) Date: Tue, 5 Apr 2016 09:33:52 -0400 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Message-ID: <20160405133352.GA13701@pfrc.org> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 13:30:07 -0000 Greg (and Jeff T.): On Mon, Apr 04, 2016 at 10:31:30PM +0000, Gregory Mirsky wrote: > Hi Jeff, > we have not expected this question that early ☺ > Yes, there’s IPR associated with these drafts that would be properly disclosed after the meeting. The ADs have been prodding us extra hard about IPR recently. :-) A relevant section from BCP 79: : 6.2.2. Timing of Disclosure Under Section 6.1.2 : : The IPR disclosure required pursuant to section 6.1.2 must be made as : soon as reasonably possible after the Contribution is published in an : Internet Draft or RFC, unless the required disclosure is already on : file. Participants who realize that the IPR will be or has been : incorporated into a submission to be published in an Internet Draft, : or is seriously being discussed in a working group, are strongly : encouraged to make at least a preliminary disclosure. That : disclosure should be made as soon after coming to the realization as : reasonably possible, not waiting until the document is actually : posted or ready for posting. Thus it's okay to just note on the mailing list that you're aware of IPR and that a formal declaration should be getting filed at some point in the future. -- Jeff From nobody Wed Apr 6 03:36:28 2016 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7F212D187 for ; Wed, 6 Apr 2016 03:36:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406103627.24912.9699.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 03:36:27 -0700 From: IETF Secretariat Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 10:36:27 -0000 Changed milestone "Submit the BFD Seamless Use Case document to the IESG to be considered as a Proposed Standard", resolved as "Done". Changed milestone "Submit the BFD Seamless Base draft to the IESG to be considered as a Proposed Standard", resolved as "Done". Changed milestone "Submit the BFD Seamless IP draft to the IESG to be considered as a Proposed Standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/bfd/charter/ From nobody Wed Apr 6 13:19:05 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B464F12D7D5; Wed, 6 Apr 2016 13:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 FMjZz3hOiZoF; Wed, 6 Apr 2016 13:18:59 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 9CBFC12D74C; Wed, 6 Apr 2016 13:18:59 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u36KGYRE028647; Wed, 6 Apr 2016 16:18:51 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 222xgqxmmv-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Apr 2016 16:18:51 -0400 Received: from MDWVEXCHHT02.ciena.com (10.4.156.176) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Wed, 6 Apr 2016 16:18:50 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by MDWVEXCHHT02.ciena.com (10.4.156.176) with Microsoft SMTP Server (TLS) id 8.3.389.2; Wed, 6 Apr 2016 16:18:50 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Wed, 6 Apr 2016 16:18:50 -0400 From: "Shah, Himanshu" To: Jeff Tantsura , Gregory Mirsky Date: Wed, 6 Apr 2016 16:18:46 -0400 Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAI06KAAAgpRTD//4Gh5//9BFOg Message-ID: <40746B2300A8FC4AB04EE722A593182BA8809AB1@ONWVEXCHMB04.ciena.com> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> , <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> <33673FCF-6DF9-4E0F-9BA2-95D670259F76@ericsson.com> In-Reply-To: <33673FCF-6DF9-4E0F-9BA2-95D670259F76@ericsson.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22244.002 X-TM-AS-Result: No--27.908000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182BA8809AB1ONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-06_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604060294 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:19:02 -0000 --_000_40746B2300A8FC4AB04EE722A593182BA8809AB1ONWVEXCHMB04cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMHO, WG should wait till IPR are disclosed and reviewed before making prog= ress on these drafts. Thanks, Himanshu From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, April 04, 2016 6:44 PM To: Gregory Mirsky Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls-ch= airs@ietf.org; rtg-bfd@ietf.org Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Jeff, Thanks! IPR will be disclosed ASAP, we are pushing legal. Regards, Jeff On Apr 4, 2016, at 7:31 PM, Gregory Mirsky > wrote: Hi Jeff, we have not expected this question that early :) Yes, there's IPR associated with these drafts that would be properly disclo= sed after the meeting. Regards, Greg From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Ali= a Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Working Group, These documents reasonably extend the existing BFD on LAG mechanism and wou= ld be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? -- Jeff On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_40746B2300A8FC4AB04EE722A593182BA8809AB1ONWVEXCHMB04cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMHO, WG = should wait till IPR are disclosed and reviewed before making progress on t= hese drafts.

&nbs= p;

Thanks,

=

Himanshu

=  

= From:= mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeff Tantsura
<= b>Sent: Monday, April 04, 2016 6:44 PM
To: Gregory Mirsky
= Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; = mpls-chairs@ietf.org; rtg-bfd@ietf.org
Subject: Re: [mpls] Two ne= w drafts on (micro-)BFD over MC-LAG interfaces

<= /div>

 

Hi= Jeff,

 

Thanks!

 

IPR will be disclosed ASAP, we are pushing legal.

Regards, =

Jeff


On Apr 4, 2016, a= t 7:31 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

= Hi Jeff,

we have no= t expected this question that early J

Yes, there’s IPR associated with these drafts that would= be properly disclosed after the meeting.

 

&nb= sp;            =    Regards,

&nbs= p;            &= nbsp;           &nbs= p;      Greg

 

 

Working Group,

 

These doc= uments reasonably extend the existing BFD on LAG mechanism and would be rea= sonably in charter for BFD to pick up.

 

Greg, given = that adoption seems a reasonable course, could you and the other co-authors= state whether there's any known IPR on these documents?

 

-- Jeff

 

On Apr 4, 2016, at 7:16 PM, Gregory Mirsky = <gregory.mirsky@ericsson.= com> wrote:

 

Dear All,

two new drafts, related to RFC 7130, were published before the m= eeting:

· &nb= sp;      =  BFD on MC-LAG interfaces in IP n= etwork

 

Greatly apprecia= te your reviews, comments, questions and suggestions.

=

 

Regards,<= o:p>

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> &n= bsp;      Greg

 

= --_000_40746B2300A8FC4AB04EE722A593182BA8809AB1ONWVEXCHMB04cie_-- From nobody Wed Apr 6 15:40:23 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3595812D6C8; Wed, 6 Apr 2016 15:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkI5MsjYrvjv; Wed, 6 Apr 2016 15:40:15 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115C512D71A; Wed, 6 Apr 2016 15:40:11 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-64-570590248a7b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 33.75.22441.42095075; Thu, 7 Apr 2016 00:39:32 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Wed, 6 Apr 2016 18:40:09 -0400 From: Gregory Mirsky To: "Shah, Himanshu" , Jeff Tantsura Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAI06KAAAgpRTD//4Gh5//9BFOg//nhuCA= Date: Wed, 6 Apr 2016 22:40:08 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3EBAA@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> , <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> <33673FCF-6DF9-4E0F-9BA2-95D670259F76@ericsson.com> <40746B2300A8FC4AB04EE722A593182BA8809AB1@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182BA8809AB1@ONWVEXCHMB04.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A3EBAAeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyuXRPlK7KBNZwg4YDYhYHNh1ktNi1cTWj xbrLp9gsbi1dyWrx+c82RgdWj7M3/7F4LFnyk8njy+XPbAHMUVw2Kak5mWWpRfp2CVwZK15+ ZymY0cFYMWX1JsYGxi+VXYwcHBICJhK7X5V2MXICmWISF+6tZ+ti5OIQEjjKKHF38QcWCGcZ o8TpQxeYQKrYBIwkXmzsYQexRQRCJDbteMQIUsQs8IRRYuOJnywgCWEBR4nv868xQxQ5SXy4 spgVwvaT2Ni3BayZRUBFYtqlPYwgNq+Ar8Td889ZIbbtY5L4dvUlWDMnUMPK5TfAGhiB7vt+ ag3YFcwC4hK3nsxngrhbQGLJnvPMELaoxMvH/1ghbCWJOa8hjmAWyJc4uesK1DJBiZMzn7BM YBSdhWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMHKXFBTm56UaGmxiB MXhMgs1xB+PeXs9DjAIcjEo8vAtyWcKFWBPLiitzDzFKcDArifAm9bKGC/GmJFZWpRblxxeV 5qQWH2KU5mBREuf1jvwXJiSQnliSmp2aWpBaBJNl4uCUamDkDd60PDput2X1KvPiNVrO33Lk z0UWXEq0sch9NV/lY3TVK+F56u+UPvHwrReZxC76myeF7Y5tkWreioRmx6lGAUZbJsz7LtZS vmd1StyHxcvlzimKbRXge5FbrxN9rdBDP8BW8Jv3r+D387YrXdygVMxxvdj01K9Ld3c7PLO7 eTynRtRauVWJpTgj0VCLuag4EQCYnSllvQIAAA== Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:40:18 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A3EBAAeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Himanshu, the IPR Disclosures should be published in a day or two. In the meantime, w= hat in particular you suggest the WG should look into - importance of the p= roblem, terms of the Disclosures or claims of the invention? Regards, Greg From: Shah, Himanshu [mailto:hshah@ciena.com] Sent: Wednesday, April 06, 2016 1:19 PM To: Jeff Tantsura; Gregory Mirsky Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls-ch= airs@ietf.org; rtg-bfd@ietf.org Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces IMHO, WG should wait till IPR are disclosed and reviewed before making prog= ress on these drafts. Thanks, Himanshu From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, April 04, 2016 6:44 PM To: Gregory Mirsky Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls= -chairs@ietf.org; rtg-bfd@ietf.org Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Jeff, Thanks! IPR will be disclosed ASAP, we are pushing legal. Regards, Jeff On Apr 4, 2016, at 7:31 PM, Gregory Mirsky > wrote: Hi Jeff, we have not expected this question that early :) Yes, there's IPR associated with these drafts that would be properly disclo= sed after the meeting. Regards, Greg From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Ali= a Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Working Group, These documents reasonably extend the existing BFD on LAG mechanism and wou= ld be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? -- Jeff On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A3EBAAeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Himanshu,

the IPR Disclosures shoul= d be published in a day or two. In the meantime, what in particular you sug= gest the WG should look into – importance of the problem, terms of the Disclosures or claims of the invention?

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Shah, Hi= manshu [mailto:hshah@ciena.com]
Sent: Wednesday, April 06, 2016 1:19 PM
To: Jeff Tantsura; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; = mpls-chairs@ietf.org; rtg-bfd@ietf.org
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

IMHO, WG should wait till I= PR are disclosed and reviewed before making progress on these drafts.<= /o:p>

 

Thanks,

Himanshu

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Monday, April 04, 2016 6:44 PM
To: Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls-chairs@ietf.org; rtg-bfd@ietf.= org
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interf= aces

 

Hi Jeff,

 

Thanks!

 

IPR will be disclosed ASAP, we are pushing legal.
Regards,

Jeff


On Apr 4, 2016, at 7:31 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Jeff,

we have not expected this= question that early J

Yes, there’s IPR as= sociated with these drafts that would be properly disclosed after the meeti= ng.

 <= /p>

    &= nbsp;           Regards,<= /span>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Jeffrey = Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-c= hairs@ietf.org; Alia Atlas (akatla= s@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Working Group,

 

These documents reasonably extend the existing BFD o= n LAG mechanism and would be reasonably in charter for BFD to pick up.=

 

Greg, given that adoption seems a reasonable course,= could you and the other co-authors state whether there's any known IPR on = these documents?

 

-- Jeff

 

On Apr 4, 2016, at 7:16 PM, Gregory Mirsky <gregory.mirsky@ericsson.com&g= t; wrote:

 

Dear All,

two new drafts, related to RFC 7130, we= re published before the meeting:

 

Greatly appreciate your reviews, commen= ts, questions and suggestions.

 

Regards,

      &nb= sp; Greg

 

--_000_7347100B5761DC41A166AC17F22DF11221A3EBAAeusaamb103erics_-- From nobody Thu Apr 7 10:47:05 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD0012D566; Thu, 7 Apr 2016 10:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 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, T_RP_MATCHES_RCVD=-0.01] 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 i8VbxXjZ-Ll2; Thu, 7 Apr 2016 10:46:58 -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 6EB0C12D0EF; Thu, 7 Apr 2016 10:46:56 -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 CGZ94898; Thu, 07 Apr 2016 17:46:54 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 18:46:54 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.171]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 01:46:46 +0800 From: Mach Chen To: Gregory Mirsky , "rtg-bfd@ietf.org" , "mpls@ietf.org" Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+Z Date: Thu, 7 Apr 2016 17:46:46 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.126] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040FSZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57069D0F.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.171, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8a58d68ce27ac53c3e71cd40464a12f0 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd-chairs@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:47:00 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040FSZXEMA510MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [grego= ry.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.or= g; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040FSZXEMA510MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Greg and all,

 

I just have quick review on the drafts. If my understanding is correct, = the idea is to use multicast destination address other than unicast address= when  sending BFD packets over LAG links. And actually this idea= has been proposed in https:/= /tools.ietf.org/html/draft-chen-bfd-interface-00 (the predecessor = of RFC 7130). And at that time, the co-authors of RFC 7130 did discuss=  the idea of using multicast destination address, but for some reason I forget now(I may need to reiterate the discussions o= n the archive), the idea was abandoned, although I still think multicast de= stination address is a smart idea.

 

Best regards,

Mach 

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] o= n behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@= ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces

Dear All,

two new drafts, related to RFC 7130, were published = before the meeting:

=B7=          BFD on MC-LAG interfaces in IP netw= ork

=B7=          BFD on MC-LAG interfaces in IP/MP= LS network

 

Greatly appreciate your reviews, comments, questions= and suggestions.

 

Regards,

   &nbs= p;    Greg

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040FSZXEMA510MBXchi_-- From nobody Thu Apr 7 19:38:45 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1693112D74C; Thu, 7 Apr 2016 19:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ajF7MxP3DF8c; Thu, 7 Apr 2016 19:38:41 -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 80FEE12D773; Thu, 7 Apr 2016 19:38:41 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id i84so113954068ywc.2; Thu, 07 Apr 2016 19:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=XhvHiiyvexnDbqAqjYkebwUb4lybHMXDG3IFTLhuTdQ=; b=m1fPUcTWjQeGDtnjsCSEoFVsXPHsDRCcUblm5UUDAjWxo4gyMIE5fWYCEbR/GwWXY5 ckR8O01z1wBkQvj9XxeIzuFhGyoAJIL4ODzWAa9fhjj29i09HGmUsgUxdVtgxMRZHvF+ v3IODXdwRdj52oIpXqfLedbogZV/GoEkAJTvyATcwLSDXQBYI8y9NcqA7ka/w3VodUyO ae86BnG6TwQpy41BHJWye5Yw1jthBmBBZhycbdS3drXzi4MxNAPj69UJh+yamp6/p8KQ rt6zPFrwPCr6A73Pkccd45rahaRsugcp28kFJHj1aGr7YhVbjpoIYpsjbOYKguCxXCd/ gtDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XhvHiiyvexnDbqAqjYkebwUb4lybHMXDG3IFTLhuTdQ=; b=cnQs6D9H6TX6bnpZhw1P2PwuMLKgI/G6u51chWgPt8n/uFLT5Z9TyypvLaGMn88Ybn WFGR+XAL5YuuGi5XUNgwhpD4DaPLqv6uB3qbGzmlnSVWaP7skco7ROKR1et9hPMB25Fm l0Jx4+4txToTm1fQj2gUW9q81lNq+ekYhuNkau/Fs9vFGpT77hiKSDcGw+Mxdi4srHU4 7IoX4Hyq/wJ+nxJoQqeFhXOFbTxi3+Ei+pkpGyAWakip3uVjBMEyREFTAssnWR6aI1gN ZWkuOQBGc6GUBHut1OdW78+oi0tKPi4Xj5JMMME1D8HuB0UhlBaVtqCM+eJDIqTK6s6v 06Vw== X-Gm-Message-State: AD7BkJKWIDw7jD8HdiGnth+n5qKOyEVNAO8gBg9EXqSEHgzvYHTa6K2auDA/R1tK4ivtufLi1jOFc9Xo9QFcbw== MIME-Version: 1.0 X-Received: by 10.129.29.3 with SMTP id d3mr3520586ywd.190.1460083120750; Thu, 07 Apr 2016 19:38:40 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Thu, 7 Apr 2016 19:38:40 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 08:08:40 +0530 Message-ID: Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces From: Manav Bhatia To: Mach Chen Content-Type: multipart/alternative; boundary=001a11428312c14b1a052ff01772 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 02:38:44 -0000 --001a11428312c14b1a052ff01772 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe it had to do with multicast datapath (especially link local) being different from the unicast datapath in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability. When writing 7130 we spent quite a bit of time ensuring that we dont carve out a special data path for the micro-BFD packets. Using link local would have made it a lot simpler. And this is where i think the current proposal is flawed -- they use link local multicast to ensure IP unicast reachability which is incorrect. Cheers, Manav On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: > Hi Greg and all, > > > > I just have quick review on the drafts. If my understanding is correct, > the idea is to use multicast destination address other than unicast addre= ss > when sending BFD packets over LAG links. And actually this idea has been > proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the > predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 di= d > discuss the idea of using multicast destination address, but for some > reason I forget now(I may need to reiterate the discussions on the > archive), the idea was abandoned, although I still think multicast > destination address is a smart idea. > > > > Best regards, > > Mach > ------------------------------ > *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ > gregory.mirsky@ericsson.com] > *Sent:* Tuesday, April 05, 2016 6:16 > *To:* rtg-bfd@ietf.org; mpls@ietf.org > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; > rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( > akatlas@gmail.com) > *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces > > Dear All, > > two new drafts, related to RFC 7130, were published before the meeting: > > =C2=B7 BFD on MC-LAG interfaces in IP network > > > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network > > > > > Greatly appreciate your reviews, comments, questions and suggestions. > > > > Regards, > > Greg > --001a11428312c14b1a052ff01772 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe it had to do with multicast datapath (especially= link local) being different from the unicast datapath in most routers. Usi= ng link local multicast IP addresses may not necessarily guarantee Unicast = IP reachability.=C2=A0

When writing 7130 we spent quite = a bit of time ensuring that we dont carve out a special data path for the m= icro-BFD packets. Using link local would have made it a lot simpler.
<= div>
And this is where i think the current proposal is flawed= -- they use link local multicast to ensure IP unicast reachability which i= s incorrect.

Cheers, Manav

On Thu, Apr 7, 2016 at 11:1= 6 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,

=C2=A0

I just have quick review on the drafts. If my understanding is correct, = the idea is to use multicast destination address other than unicast address= when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea= has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2= =A0(the predecessor of RFC 7130). And at=C2=A0that time, the co-authors of = RFC 7130 did discuss=C2=A0the idea of using multicast destination address, but for some reason I forget now(I may need to reiterate the discussions o= n the archive), the idea was abandoned, although I still think multicast de= stination address is a smart idea.

=C2=A0

Best regards,

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirs= ky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.or= g
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; <= a href=3D"mailto:rtg-bfd-chairs@ietf.org" target=3D"_blank">rtg-bfd-chairs@= ietf.org; mpl= s-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces

Dear All,

two new drafts, related to RFC 7130, were published = before the meeting:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces in IP netw= ork

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces in IP/MP= LS network

=C2=A0

Greatly appreciate your reviews, comments, questions= and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Greg


--001a11428312c14b1a052ff01772-- From nobody Fri Apr 8 05:39:42 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B55612D682; Fri, 8 Apr 2016 05:39:40 -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 RLHWT1WQKRNR; Fri, 8 Apr 2016 05:39:37 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2448E12D823; Fri, 8 Apr 2016 05:39:17 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-0a-5707a027cc62 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 35.D6.30335.720A7075; Fri, 8 Apr 2016 14:12:24 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 08:39:15 -0400 From: Gregory Mirsky To: Manav Bhatia , Mach Chen Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oA== Date: Fri, 8 Apr 2016 12:39:14 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A40584eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyuXSPt67GAvZwgzkfeSw+PbzEbHFg00FG iwtrhS0uT2pjt1h3+RSbxa2lK1ktlty+x27x+c82RgcOj52z7rJ7tBx5y+qxZMlPJo8vlz+z BbBEcdmkpOZklqUW6dslcGU8uLyOtWDGHMaK7X+72BsYW2YwdjFyckgImEgs+7iOFcIWk7hw bz1bFyMXh5DAUUaJS4sWMEM4yxglvj+8BFbFJmAk8WJjDzuILSLgJbFnyTawDmaBi0wS36Z+ YQJJCAs4Snyff40ZoshJ4sOVxUDNHGD24wOFIGEWARWJEw+OMYGEeQV8JW7eDIXY9YBRYvK+ GWC7OAUCJbqWzAa7lBHouu+n1oCNZxYQl7j1ZD4TxNUCEkv2nGeGsEUlXj7+B/WNksSc1xAn MAvkS7zt2whm8woISpyc+YRlAqPoLCSjZiEpm4WkbBbQecwCmhLrd+lDlChKTOl+yA5ha0i0 zpnLjiy+gJF9FSNHaXFBTm66kcEmRmCcHpNg093BeH+65yFGAQ5GJR7eBQLs4UKsiWXFlbmH GCU4mJVEeLcuAQrxpiRWVqUW5ccXleakFh9ilOZgURLnbQz+FyYkkJ5YkpqdmlqQWgSTZeLg lGpgNH22fE7KWRfFbRY2ZltK98kzLqk+na5WtDpUkW+99Y2KY/kKZl3sfT/qAl9OdLrWwK4Q VCc700Rk9yoTq42PTv6UVXm0TvsFy8TiH/yHZH5yT2LZnu7BIuosu1HKS+TSTTUtFsM5S0sd /MuSxKIfSPROdl6m9uE2Q4979LEq+z2HHFZwCKYpsRRnJBpqMRcVJwIADkxhhM8CAAA= Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:39:40 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A40584eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQp0aGFuayB5b3UgZm9yIHNoYXJpbmcgaW5zaWdodCB2aWV3IG9mIGRpc2N1c3Np b25zIGFyb3VuZCBSRkMgNzEzMCwgZXh0cmVtZWx5IGhlbHBmdWwuDQpXZSBiZWxpZXZlLCBhbmQg SmVmZiBpcyBjby1hdXRob3Igb2YgUkZDIDcxMzAgdG9vLCB0aGF0IE1DLUxBRyBwcmVzZW50cyBk aWZmZXJlbnQgY2FzZSBhbmQgdGhlIGNvbXByb21pc2UgdGhhdCB5b3XigJl2ZSBwb2ludGVkIHRv byBpcyBqdXN0aWZpZWQuIFdlIHdpbGwgYWRkIG1vcmUgZGV0YWlscyBvbiB0aGUgcG90ZW50aWFs IGRpZmZlcmVuY2VzIGJldHdlZW4gdW5pY2FzdCBhbmQgbXVsdGljYXN0IGZhc3QgcGF0aHMgaW4g dGhlIG5leHQgdXBkYXRlLg0KV2UgYXJlIG9wZW4gdG8gdGhlIGRpc2N1c3Npb24gYW5kIGFsd2F5 cyB3ZWxjb21lIGNvbW1lbnRzIGFuZCBhbHRlcm5hdGl2ZSBwcm9wb3NhbHMuDQoNCiAgICAgICAg ICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoN CkZyb206IE1hbmF2IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbV0NClNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiA3OjM5IFBNDQpUbzogTWFjaCBDaGVuDQpDYzogR3Jl Z29yeSBNaXJza3k7IHJ0Zy1iZmRAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LXRhbm1p ci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnOyBydGctYmZkLWNoYWlyc0BpZXRm Lm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IEFsaWEgQXRsYXMgKGFrYXRsYXNAZ21haWwuY29t KQ0KU3ViamVjdDogUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFH IGludGVyZmFjZXMNCg0KSSBiZWxpZXZlIGl0IGhhZCB0byBkbyB3aXRoIG11bHRpY2FzdCBkYXRh cGF0aCAoZXNwZWNpYWxseSBsaW5rIGxvY2FsKSBiZWluZyBkaWZmZXJlbnQgZnJvbSB0aGUgdW5p Y2FzdCBkYXRhcGF0aCBpbiBtb3N0IHJvdXRlcnMuIFVzaW5nIGxpbmsgbG9jYWwgbXVsdGljYXN0 IElQIGFkZHJlc3NlcyBtYXkgbm90IG5lY2Vzc2FyaWx5IGd1YXJhbnRlZSBVbmljYXN0IElQIHJl YWNoYWJpbGl0eS4NCg0KV2hlbiB3cml0aW5nIDcxMzAgd2Ugc3BlbnQgcXVpdGUgYSBiaXQgb2Yg dGltZSBlbnN1cmluZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0IGEgc3BlY2lhbCBkYXRhIHBhdGgg Zm9yIHRoZSBtaWNyby1CRkQgcGFja2V0cy4gVXNpbmcgbGluayBsb2NhbCB3b3VsZCBoYXZlIG1h ZGUgaXQgYSBsb3Qgc2ltcGxlci4NCg0KQW5kIHRoaXMgaXMgd2hlcmUgaSB0aGluayB0aGUgY3Vy cmVudCBwcm9wb3NhbCBpcyBmbGF3ZWQgLS0gdGhleSB1c2UgbGluayBsb2NhbCBtdWx0aWNhc3Qg dG8gZW5zdXJlIElQIHVuaWNhc3QgcmVhY2hhYmlsaXR5IHdoaWNoIGlzIGluY29ycmVjdC4NCg0K Q2hlZXJzLCBNYW5hdg0KDQpPbiBUaHUsIEFwciA3LCAyMDE2IGF0IDExOjE2IFBNLCBNYWNoIENo ZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+IHdy b3RlOg0KDQpIaSBHcmVnIGFuZCBhbGwsDQoNCg0KDQpJIGp1c3QgaGF2ZSBxdWljayByZXZpZXcg b24gdGhlIGRyYWZ0cy4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgaWRlYSBp cyB0byB1c2UgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3RoZXIgdGhhbiB1bmljYXN0 IGFkZHJlc3Mgd2hlbiAgc2VuZGluZyBCRkQgcGFja2V0cyBvdmVyIExBRyBsaW5rcy4gQW5kIGFj dHVhbGx5IHRoaXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwICh0aGUgcHJlZGVjZXNzb3Igb2Yg UkZDIDcxMzApLiBBbmQgYXQgdGhhdCB0aW1lLCB0aGUgY28tYXV0aG9ycyBvZiBSRkMgNzEzMCBk aWQgZGlzY3VzcyB0aGUgaWRlYSBvZiB1c2luZyBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVz cywgYnV0IGZvciBzb21lIHJlYXNvbiBJIGZvcmdldCBub3coSSBtYXkgbmVlZCB0byByZWl0ZXJh dGUgdGhlIGRpc2N1c3Npb25zIG9uIHRoZSBhcmNoaXZlKSwgdGhlIGlkZWEgd2FzIGFiYW5kb25l ZCwgYWx0aG91Z2ggSSBzdGlsbCB0aGluayBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBp cyBhIHNtYXJ0IGlkZWEuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCk1hY2gNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJ0Zy1iZmQgW3J0Zy1iZmQtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIEdy ZWdvcnkgTWlyc2t5IFtncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnku bWlyc2t5QGVyaWNzc29uLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAwNSwgMjAxNiA2OjE2 DQpUbzogcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz47IG1wbHNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpDYzogZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1t Yy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMt bGFnLWlwQHRvb2xzLmlldGYub3JnPjsgcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnJ0 Zy1iZmQtY2hhaXJzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMt Y2hhaXJzQGlldGYub3JnPjsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFr YXRsYXNAZ21haWwuY29tPikNClN1YmplY3Q6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZE IG92ZXIgTUMtTEFHIGludGVyZmFjZXMNCkRlYXIgQWxsLA0KdHdvIG5ldyBkcmFmdHMsIHJlbGF0 ZWQgdG8gUkZDIDcxMzAsIHdlcmUgcHVibGlzaGVkIGJlZm9yZSB0aGUgbWVldGluZzoNCg0K4oCi ICAgICAgICAgQkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQIG5ldHdvcms8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwLTAwPg0K DQrigKIgICAgICAgICBCRkQgb24gTUMtTEFHIGludGVyZmFjZXMgaW4gSVAvTVBMUyBuZXR3b3Jr PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxh Zy1tcGxzLTAwPg0KDQpHcmVhdGx5IGFwcHJlY2lhdGUgeW91ciByZXZpZXdzLCBjb21tZW50cywg cXVlc3Rpb25zIGFuZCBzdWdnZXN0aW9ucy4NCg0KUmVnYXJkcywNCiAgICAgICAgR3JlZw0KDQo= --_000_7347100B5761DC41A166AC17F22DF11221A40584eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj50aGFuayB5b3UgZm9yIHNoYXJpbmcgaW5zaWdodCB2aWV3IG9m IGRpc2N1c3Npb25zIGFyb3VuZCBSRkMgNzEzMCwgZXh0cmVtZWx5IGhlbHBmdWwuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGJlbGlldmUsIGFuZCBKZWZmIGlzIGNvLWF1dGhvciBv ZiBSRkMgNzEzMCB0b28sIHRoYXQgTUMtTEFHIHByZXNlbnRzIGRpZmZlcmVudCBjYXNlIGFuZCB0 aGUgY29tcHJvbWlzZSB0aGF0IHlvdeKAmXZlIHBvaW50ZWQgdG9vIGlzIGp1c3RpZmllZC4gV2Ug d2lsbCBhZGQNCiBtb3JlIGRldGFpbHMgb24gdGhlIHBvdGVudGlhbCBkaWZmZXJlbmNlcyBiZXR3 ZWVuIHVuaWNhc3QgYW5kIG11bHRpY2FzdCBmYXN0IHBhdGhzIGluIHRoZSBuZXh0IHVwZGF0ZS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBhcmUgb3BlbiB0byB0aGUgZGlzY3Vz c2lvbiBhbmQgYWx3YXlzIHdlbGNvbWUgY29tbWVudHMgYW5kIGFsdGVybmF0aXZlIHByb3Bvc2Fs cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFuYXYgQmhhdGlhIFttYWlsdG86 bWFuYXZiaGF0aWFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJp bCAwNywgMjAxNiA3OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBNYWNoIENoZW48YnI+DQo8Yj5DYzo8 L2I+IEdyZWdvcnkgTWlyc2t5OyBydGctYmZkQGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBkcmFm dC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZzsgcnRnLWJmZC1jaGFp cnNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBBbGlhIEF0bGFzIChha2F0bGFzQGdt YWlsLmNvbSk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNy by0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGJlbGlldmUgaXQgaGFkIHRvIGRvIHdpdGggbXVsdGljYXN0IGRhdGFwYXRo IChlc3BlY2lhbGx5IGxpbmsgbG9jYWwpIGJlaW5nIGRpZmZlcmVudCBmcm9tIHRoZSB1bmljYXN0 IGRhdGFwYXRoIGluIG1vc3Qgcm91dGVycy4gVXNpbmcgbGluayBsb2NhbCBtdWx0aWNhc3QgSVAg YWRkcmVzc2VzIG1heSBub3QgbmVjZXNzYXJpbHkgZ3VhcmFudGVlIFVuaWNhc3QgSVAgcmVhY2hh YmlsaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2hlbiB3cml0aW5nIDcxMzAgd2Ugc3BlbnQgcXVpdGUgYSBiaXQgb2YgdGltZSBlbnN1cmlu ZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0IGEgc3BlY2lhbCBkYXRhIHBhdGggZm9yIHRoZSBtaWNy by1CRkQgcGFja2V0cy4gVXNpbmcgbGluayBsb2NhbCB3b3VsZCBoYXZlIG1hZGUgaXQgYSBsb3Qg c2ltcGxlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5kIHRoaXMgaXMgd2hlcmUgaSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBm bGF3ZWQgLS0gdGhleSB1c2UgbGluayBsb2NhbCBtdWx0aWNhc3QgdG8gZW5zdXJlIElQIHVuaWNh c3QgcmVhY2hhYmlsaXR5IHdoaWNoIGlzIGluY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLCBNYW5hdjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciA3 LCAyMDE2IGF0IDExOjE2IFBNLCBNYWNoIENoZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYWNoLmNo ZW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hY2guY2hlbkBodWF3ZWkuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBHcmVnIGFuZCBhbGwsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5JIGp1c3QgaGF2ZSBxdWljayByZXZpZXcgb24gdGhlIGRyYWZ0cy4gSWYgbXkg dW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgaWRlYSBpcyB0byB1c2UgbXVsdGljYXN0IGRl c3RpbmF0aW9uIGFkZHJlc3Mgb3RoZXIgdGhhbiB1bmljYXN0IGFkZHJlc3Mgd2hlbiZuYnNwOyZu YnNwO3NlbmRpbmcgQkZEIHBhY2tldHMgb3Zlcg0KIExBRyBsaW5rcy4gQW5kIGFjdHVhbGx5IHRo aXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwPC9h PiZuYnNwOyh0aGUgcHJlZGVjZXNzb3Igb2YgUkZDIDcxMzApLiBBbmQgYXQmbmJzcDt0aGF0IHRp bWUsIHRoZSBjby1hdXRob3JzIG9mIFJGQyA3MTMwIGRpZCBkaXNjdXNzJm5ic3A7dGhlIGlkZWEg b2YgdXNpbmcgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3MsIGJ1dCBmb3Igc29tZSByZWFz b24gSSBmb3JnZXQgbm93KEkgbWF5IG5lZWQgdG8gcmVpdGVyYXRlIHRoZQ0KIGRpc2N1c3Npb25z IG9uIHRoZSBhcmNoaXZlKSwgdGhlIGlkZWEgd2FzIGFiYW5kb25lZCwgYWx0aG91Z2ggSSBzdGls bCB0aGluayBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhIHNtYXJ0IGlkZWEuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1hY2gmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFu PjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IFJ0Zy1i ZmQgWzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5ydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KIG9uIGJlaGFsZiBvZiBHcmVnb3J5 IE1pcnNreSBbPGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT5dPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEFwcmlsIDA1LCAyMDE2IDY6MTY8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhy ZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBpZXRm Lm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQt dGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij4NCmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ DQpydGctYmZkLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWly c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBB bGlhIEF0bGFzICg8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFR3byBuZXcg ZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+RGVhciBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnR3byBuZXcgZHJhZnRzLCBy ZWxhdGVkIHRvIFJGQyA3MTMwLCB3ZXJlIHB1Ymxpc2hlZCBiZWZvcmUgdGhlIG1lZXRpbmc6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbDtj b2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXAtMDAiIHRhcmdldD0i X2JsYW5rIj5CRkQgb24gTUMtTEFHIGludGVyZmFjZXMgaW4gSVAgbmV0d29yazwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sO2NvbG9y OmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzLTAwIiB0YXJnZXQ9Il9i bGFuayI+QkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdyZWF0bHkgYXBwcmVjaWF0ZSB5b3Vy IHJldmlld3MsIGNvbW1lbnRzLCBxdWVzdGlvbnMgYW5kIHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF11221A40584eusaamb103erics_-- From nobody Fri Apr 8 05:42:53 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388D312D711; Fri, 8 Apr 2016 05:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfVLJdZxdSAV; Fri, 8 Apr 2016 05:42:48 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E277D12D682; Fri, 8 Apr 2016 05:42:47 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-06-5707a720c0cb Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 5D.1C.22441.027A7075; Fri, 8 Apr 2016 14:42:08 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 08:42:46 -0400 From: Gregory Mirsky To: Mach Chen , "rtg-bfd@ietf.org" , "mpls@ietf.org" Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZACgcDOA= Date: Fri, 8 Apr 2016 12:42:45 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A405A9@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A405A9eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyuXSPn67CcvZwg0WbjS0+PbzEbHFg00FG iwtrhS3WXT7FZnFr6UpWi89/tjE6sHnsnHWX3aPlyFtWjyVLfjJ5fLn8mS2AJYrLJiU1J7Ms tUjfLoErY0lrE2vB8viKhYcXsDUwTg7tYuTkkBAwkfh/+gQzhC0mceHeerYuRi4OIYGjjBKn 2tpYQBJCAssYJV7NFwex2QSMJF5s7GEHsUUE8iQObJ3ODNLALHCBUeLbiw1gk4QFHCW+z7/G DFHkJPHhymLWLkYOINtKYvt5c5Awi4CKxJ1jb9hAbF4BX4nDD9qZIRbPZJS4saSXESTBKRAm cWjHQ1YQmxHouu+n1jCB2MwC4hK3nsxngrhaQGLJnvNQH4hKvHz8jxXCVpKY8xrkBg6g+nyJ 15OsIHYJSpyc+YRlAqPoLCSTZiFUzUJSBVGiI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i 5CgtLsjJTTcy3MQIjMZjEmyOOxj39noeYhTgYFTi4V0gwB4uxJpYVlyZe4hRgoNZSYR36xKg EG9KYmVValF+fFFpTmrxIUZpDhYlcV7vyH9hQgLpiSWp2ampBalFMFkmDk6pBkZT8W721Zzv 2KKOym+2SDltbZH38Xvk4aP7mA6eesdlGDdJRPlZLNPh6ILzl72FTEQqDt7c5v44Iv/15BIj CV6XjEc1D3i2cFlFTbp6ZOYO99J3a50Wr6+eueb20T5d+9zYVbbeuvOfO59dsHCZsIPOPVf5 0yukVvUx9uUo5VuxftfxFXvW9FaJpTgj0VCLuag4EQA3Twt/wgIAAA== Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:42:50 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A405A9eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mach, many thanks for your review and the reference. Will study it in details. Wi= ll be glad to continue this work with you. Would you consider joining the a= uthors? Regards, Greg From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Thursday, April 07, 2016 10:47 AM To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.or= g; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [grego= ry.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A405A9eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mach,

many thanks for your r= eview and the reference. Will study it in details. Will be glad to continue= this work with you. Would you consider joining the authors?

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Mach Che= n [mailto:mach.chen@huawei.com]
Sent: Thursday, April 07, 2016 10:47 AM
To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@= ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Greg and all,

 

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach 

From: Rtg-bfd [rtg-bfd-bounces@iet= f.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (= akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,

two new drafts, related = to RFC 7130, were published before the meeting:

·&n= bsp;        BFD on MC-LAG interfa= ces in IP network

·&n= bsp;        BFD on MC-LAG inter= faces in IP/MPLS network

 =

Greatly appreciate your = reviews, comments, questions and suggestions.

 

Regards,

        Greg

--_000_7347100B5761DC41A166AC17F22DF11221A405A9eusaamb103erics_-- From nobody Fri Apr 8 07:14:43 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865D112D65D; Fri, 8 Apr 2016 07:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 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, T_RP_MATCHES_RCVD=-0.01] 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 dHVVZcI4lYo3; Fri, 8 Apr 2016 07:14:38 -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 C3E6612D18C; Fri, 8 Apr 2016 07:14:37 -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 CLU31349; Fri, 08 Apr 2016 14:14:35 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 8 Apr 2016 15:14:35 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.171]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 22:14:29 +0800 From: Mach Chen To: Gregory Mirsky , "rtg-bfd@ietf.org" , "mpls@ietf.org" Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZACgcDOAAAxeN5w== Date: Fri, 8 Apr 2016 14:14:28 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> , <7347100B5761DC41A166AC17F22DF11221A405A9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A405A9@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.189] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F0FB9SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5707BCCC.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.171, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f61e306f4aaeb1cb7f78c1d7fc75009f Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:14:41 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F0FB9SZXEMA510MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for the invitation, I am glad to join and continue the work. Best regards, Mach ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, April 08, 2016 20:42 To: Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls-chairs@ietf.org; = Alia Atlas (akatlas@gmail.com) Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Mach, many thanks for your review and the reference. Will study it in details. Wi= ll be glad to continue this work with you. Would you consider joining the a= uthors? Regards, Greg From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Thursday, April 07, 2016 10:47 AM To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.or= g; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [grego= ry.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F0FB9SZXEMA510MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for the invitation, I am glad to join and continue the work.

 

Best regards,

Mach

 

From: Gregory Mirsky [gregory.mirsky@erics= son.com]
Sent: Friday, April 08, 2016 20:42
To: Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls-chairs@iet= f.org; Alia Atlas (akatlas@gmail.com)
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Mach,

many thanks for your = review and the reference. Will study it in details. Will be glad to continu= e this work with you. Would you consider joining the authors?

 

   &nb= sp;            Regar= ds,

   &nb= sp;            =             &nb= sp;   Greg

 

From: Mach Chen [mailto:mach.chen@huawei.com]
Sent: Thursday, April 07, 2016 10:47 AM
To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@= ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Greg and all,

 

I just have quick review on the drafts. If my understanding is co= rrect, the idea is to use multicast destination address other than unicast = address when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach 

From:= Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,

two new drafts, related= to RFC 7130, were published before the meeting:

=B7   &= nbsp;     BFD on MC-LAG interf= aces in IP network

=B7   &= nbsp;     BFD on MC-LAG inte= rfaces in IP/MPLS network

 

Greatly appreciate your= reviews, comments, questions and suggestions.

 

Regards,

        Greg

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F0FB9SZXEMA510MBXchi_-- From nobody Fri Apr 8 08:04:58 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DDB12D930; Fri, 8 Apr 2016 08:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 nWi7JV1lPD6L; Fri, 8 Apr 2016 08:04:46 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 21BBB12D92F; Fri, 8 Apr 2016 08:04:46 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id i84so131528944ywc.2; Fri, 08 Apr 2016 08:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=T3aQixiktqeCUJ/2KLCpuz9XYc5tbFgJPVvauTBE7oQ=; b=m0GjA4/lo2G/D/qgI7R9W+RPqTZWsSM29e3O5BZWdwK09klW2OLyTCeQxKqefHRpof YN2rcOFkcE1WHgaC55N3lNSn66E9XqFXbVy+SIlY2C4a3QZSdhNhmq3Pc4vKPkpbvFsO eVSN5sSJFAi1HQQRrysBJROZ7gkUgYKKiXqW/ZMaEHrI/Tjq/rDliLErwnrAOmahfqfD 9juaKvNAqWoHOolOVRSLDVkH/GjSj40FzLPMfZf5W6DugW7dxfC5R5z+ujPHw884ISQH DbDZv+HdZ/KVSz67YVXH2/E2OKCDjdssN626CFOa5PiqtXzCVUpGSidnyRH8Wg8n+r4b eRQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=T3aQixiktqeCUJ/2KLCpuz9XYc5tbFgJPVvauTBE7oQ=; b=KY0px3kVWu/6IMbFK5Rpznr/kknVvigVhh1zpIYVI+w3J38hKReXSMITYQXhtpktln pokaKFdTQ9fahm/MuyU3zCO43clj33pgJOaIP7ISJ8jmh67CM4wKdFTmFNfkvUbkM5lx EYD6lp1vPXzsfNE5y6dEuRowwaChGTJxGy4c8PjyZPllWBED/h0ZuXNBg4oho2vvJde4 6QemvifqVBlBri5WGHDznYlGb9wTcVUdILXkwH9kQ9c0Cgx+2FumUdfF2gSH4eWIlAnL ns90hKkLITYcVORl6nCOWd5fkkNx9yPmKQjrMqv0QTX/r/yX006lTETf2grnE+wSptPa PzBw== X-Gm-Message-State: AD7BkJKw9hv2qAfn2q7lA5GD6DkLfl60TzJLLSgm9pAyJNZ+yqe6+p/ndOqq84Xwb9wxzjSn2xPycNzAaE4n9w== MIME-Version: 1.0 X-Received: by 10.37.32.136 with SMTP id g130mr4888962ybg.45.1460127885285; Fri, 08 Apr 2016 08:04:45 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Fri, 8 Apr 2016 08:04:45 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 20:34:45 +0530 Message-ID: Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a1143e5deede1d7052ffa8350 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:04:53 -0000 --001a1143e5deede1d7052ffa8350 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, Why cant different micro-BFD packets use the IP address of the MC-LAG end points? Ones going to router 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which would be configured along with the MC-LAG configs. In fact i would argue that the u-bfd packets going to different routers must use different IP addresses so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it takes is different from the other regular packets? Cheers, Manav On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky wrote: > Hi Manav, > > thank you for sharing insight view of discussions around RFC 7130, > extremely helpful. > > We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents > different case and the compromise that you=E2=80=99ve pointed too is just= ified. We > will add more details on the potential differences between unicast and > multicast fast paths in the next update. > > We are open to the discussion and always welcome comments and alternative > proposals. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Thursday, April 07, 2016 7:39 PM > *To:* Mach Chen > *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > I believe it had to do with multicast datapath (especially link local) > being different from the unicast datapath in most routers. Using link loc= al > multicast IP addresses may not necessarily guarantee Unicast IP > reachability. > > > > When writing 7130 we spent quite a bit of time ensuring that we dont carv= e > out a special data path for the micro-BFD packets. Using link local would > have made it a lot simpler. > > > > And this is where i think the current proposal is flawed -- they use link > local multicast to ensure IP unicast reachability which is incorrect. > > > > Cheers, Manav > > > > On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: > > Hi Greg and all, > > > > I just have quick review on the drafts. If my understanding is correct, > the idea is to use multicast destination address other than unicast addre= ss > when sending BFD packets over LAG links. And actually this idea has been > proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the > predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 di= d > discuss the idea of using multicast destination address, but for some > reason I forget now(I may need to reiterate the discussions on the > archive), the idea was abandoned, although I still think multicast > destination address is a smart idea. > > > > Best regards, > > Mach > ------------------------------ > > *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ > gregory.mirsky@ericsson.com] > *Sent:* Tuesday, April 05, 2016 6:16 > *To:* rtg-bfd@ietf.org; mpls@ietf.org > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; > rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( > akatlas@gmail.com) > *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces > > Dear All, > > two new drafts, related to RFC 7130, were published before the meeting: > > =C2=B7 BFD on MC-LAG interfaces in IP network > > > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network > > > > > Greatly appreciate your reviews, comments, questions and suggestions. > > > > Regards, > > Greg > > > --001a1143e5deede1d7052ffa8350 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

Why cant different micro-BFD p= ackets use the IP address of the MC-LAG end points? Ones going to router 1 = will all carry the same unicast IP address. The ones going towards the othe= r router will all carry some other IP address, which would be configured al= ong with the MC-LAG configs.

In fact i would argue= that the u-bfd packets going to different routers must use different IP ad= dresses so that you can actually verify the data plane liveliness. Whats th= e point in sending a contrived IP address if the path that it takes is diff= erent from the other regular packets?

Cheers, Mana= v

= On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <gregory.mirsky@e= ricsson.com> wrote:

Hi Manav,

thank you for sharing ins= ight view of discussions around RFC 7130, extremely helpful.<= /span>

We believe, and Jeff is c= o-author of RFC 7130 too, that MC-LAG presents different case and the compr= omise that you=E2=80=99ve pointed too is justified. We will add more details on the potential differences between unicast and multicast fa= st paths in the next update.

We are open to the discus= sion and always welcome comments and alternative proposals.

=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=C2=A0=C2=A0=C2=A0 Regards,=

=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=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=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bh= atia [mailto:man= avbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.iet= f.org; rtg= -bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

I believe it had to do with multicast datapath (espe= cially link local) being different from the unicast datapath in most router= s. Using link local multicast IP addresses may not necessarily guarantee Un= icast IP reachability.=C2=A0

=C2=A0

When writing 7130 we spent quite a bit of time ensur= ing that we dont carve out a special data path for the micro-BFD packets. U= sing link local would have made it a lot simpler.

=C2=A0

And this is where i think the current proposal is fl= awed -- they use link local multicast to ensure IP unicast reachability whi= ch is incorrect.

=C2=A0

Cheers, Manav

=C2=A0

On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,

=C2=A0

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0

Best regards,

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 BFD on MC-LAG interfa= ces in IP network

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 BFD on MC-LAG inter= faces in IP/MPLS network

=C2=A0

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0


--001a1143e5deede1d7052ffa8350-- From nobody Fri Apr 8 08:50:58 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668212D517; Fri, 8 Apr 2016 08:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8uQTMJZgNAi; Fri, 8 Apr 2016 08:50:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178E712D101; Fri, 8 Apr 2016 08:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18946; q=dns/txt; s=iport; t=1460130650; x=1461340250; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6fMz7E/0vNhu6f3Ia5f9cH8Dd5oUMw0Fpokd39ey/iU=; b=W01dD/99a95hk3aNNZptaiNQu/WsPBkaPNfHDUmTyeRRY4YOzR5iUXEZ eojdVT5HEVtZ0d66ZGhaLJMmyTAYRdyiYtav7IhI6zYRQRhpTqG9fD54g yr73EALsG+mgbpoExfsYZpRHh4b+LqfN2i08hTs88nyU1GLf2nVZiO9u0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAgD/0gdX/49dJa1cgmtMU30GrmeGZ?= =?us-ascii?q?YRzAQ2BcyGFbAKBMzgUAQEBAQEBAWUnhEEBAQEEeRACAQgRAwEBARoCDAchERQ?= =?us-ascii?q?JCAEBBAENBYgSAxIOuzgNhSEBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuCQ?= =?us-ascii?q?YIeDQknAoR3BY4GiU0xAYV2hiCBdYFnjSaGH4Erh1oBHgEBQoIEGYFKbFqHJD0?= =?us-ascii?q?BfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208,217";a="259150790" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 15:50:48 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u38FomrA009196 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 15:50:48 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 10:50:47 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 10:50:47 -0500 From: "Reshad Rahman (rrahman)" To: Manav Bhatia , Gregory Mirsky Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZAB2XmwAAFPl8AAAFFQWA///JyYA= Date: Fri, 8 Apr 2016 15:50:47 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.167] Content-Type: multipart/alternative; boundary="_000_D32D4A9913B056rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:50:53 -0000 --_000_D32D4A9913B056rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Manav, and nothing in RFC7130 seems to preclude using differen= t unicast IP address as destination on different member links. Regards, Reshad (as individual contributor). From: Rtg-bfd > o= n behalf of Manav Bhatia > Date: Friday, April 8, 2016 at 11:04 AM To: Gregory Mirsky > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "mpls@ie= tf.org" >, "mpls-= chairs@ietf.org" >, "Alia Atlas (akatlas@gmail.com)" >, "rtg-bfd@ietf.org" >, "rtg-b= fd-chairs@ietf.org" > Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg, Why cant different micro-BFD packets use the IP address of the MC-LAG end p= oints? Ones going to router 1 will all carry the same unicast IP address. T= he ones going towards the other router will all carry some other IP address= , which would be configured along with the MC-LAG configs. In fact i would argue that the u-bfd packets going to different routers mus= t use different IP addresses so that you can actually verify the data plane= liveliness. Whats the point in sending a contrived IP address if the path = that it takes is different from the other regular packets? Cheers, Manav On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky > wrote: Hi Manav, thank you for sharing insight view of discussions around RFC 7130, extremel= y helpful. We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents dif= ferent case and the compromise that you've pointed too is justified. We wil= l add more details on the potential differences between unicast and multica= st fast paths in the next update. We are open to the discussion and always welcome comments and alternative p= roposals. Regards, Greg From: Manav Bhatia [mailto:manavbhatia@gmail.com] Sent: Thursday, April 07, 2016 7:39 PM To: Mach Chen Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.or= g; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.= org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces I believe it had to do with multicast datapath (especially link local) bein= g different from the unicast datapath in most routers. Using link local mul= ticast IP addresses may not necessarily guarantee Unicast IP reachability. When writing 7130 we spent quite a bit of time ensuring that we dont carve = out a special data path for the micro-BFD packets. Using link local would h= ave made it a lot simpler. And this is where i think the current proposal is flawed -- they use link l= ocal multicast to ensure IP unicast reachability which is incorrect. Cheers, Manav On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen > wrote: Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] o= n behalf of Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: =B7 BFD on MC-LAG interfaces in IP network =B7 BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_D32D4A9913B056rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <12FD2F8949168049B81EDF4EC0E0A0BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I agree with Manav, and nothing in RFC7130 seems to preclude using dif= ferent unicast IP address as destination on different member links.

Regards,
Reshad (as individual contributor).

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Ma= nav Bhatia <manavbhatia@gmail.c= om>
Date: Friday, April 8, 2016 at 11:0= 4 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@= tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>= ;, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com>, "= rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: Two new drafts on (mic= ro-)BFD over MC-LAG interfaces

Hi Greg,

Why cant different micro-BFD packets use the IP address of the MC-LAG = end points? Ones going to router 1 will all carry the same unicast IP addre= ss. The ones going towards the other router will all carry some other IP ad= dress, which would be configured along with the MC-LAG configs.

In fact i would argue that the u-bfd packets going to different router= s must use different IP addresses so that you can actually verify the data = plane liveliness. Whats the point in sending a contrived IP address if the = path that it takes is different from the other regular packets?

Cheers, Manav

On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <= span dir=3D"ltr"> <gregor= y.mirsky@ericsson.com> wrote:

Hi Manav,

thank you for sharing insight view = of discussions around RFC 7130, extremely helpful.

We believe, and Jeff is co-author o= f RFC 7130 too, that MC-LAG presents different case and the compromise that= you’ve pointed too is justified. We will add more details on the potential differences between unicast and mul= ticast fast paths in the next update.

We are open to the discussion and a= lways welcome comments and alternative proposals.

 

      = ;          Regards,<= /u>

      = ;            &n= bsp;            = ; Greg

 

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

 

I believe it had to do with multicast datapath (espe= cially link local) being different from the unicast datapath in most router= s. Using link local multicast IP addresses may not necessarily guarantee Un= icast IP reachability. 

 

When writing 7130 we spent quite a bit of time ensur= ing that we dont carve out a special data path for the micro-BFD packets. U= sing link local would have made it a lot simpler.

 

And this is where i think the current proposal is fl= awed -- they use link local multicast to ensure IP unicast reachability whi= ch is incorrect.

 

Cheers, Manav

 

On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,

 

I just have quick review on the drafts. If my understanding is corr= ect, the idea is to use multicast destination address other than unicast ad= dress when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach 

From:<= /b> Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=B7         BFD on MC-LAG interfa= ces in IP network

=B7         BFD on MC-LAG inter= faces in IP/MPLS network

 

Greatly appreciate your = reviews, comments, questions and suggestions.

 

Regards,

        Greg

 


 --_000_D32D4A9913B056rrahmanciscocom_-- From nobody Fri Apr 8 09:12:27 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F0E12D1CB; Fri, 8 Apr 2016 09:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsExwUkYxnUK; Fri, 8 Apr 2016 09:12:20 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E787012D1AB; Fri, 8 Apr 2016 09:12:19 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-ab-5707d83c4718 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 12.A7.22441.C38D7075; Fri, 8 Apr 2016 18:11:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 12:12:18 -0400 From: Gregory Mirsky To: Manav Bhatia Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAYagaA= Date: Fri, 8 Apr 2016 16:12:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A40773eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyuXSPt67NDfZwg+k/dSw+PbzEbHFg00FG iwtrhS0uT2pjt1h3+RSbxa2lK1ktlty+x27x+c82RgcOj52z7rJ7tBx5y+qxZMlPJo8vlz+z BbBEcdmkpOZklqUW6dslcGV869vNVvDkMWPFo5+BDYxP7jJ2MXJySAiYSNw9t4kJwhaTuHBv PRuILSRwlFHi1LIkCHsZo8TJp5ogNpuAkcSLjT3sILaIgIZE6/sDzF2MXBzMAl+ZJFqaVrGA JIQFHCW+z7/GDFHkJPHhymJWCNtP4vWhfrAFLAIqEutf3wGL8wr4Ssyc/IYZYtlrJokXN4xA bE6BQImNN+aDHccIdNz3U2vAbGYBcYlbT+ZDHS0gsWTPeWYIW1Ti5eN/rBC2ksTH3/PZIerz JXrezWOC2CUocXLmE5YJjKKzkIyahaRsFpKyWYwcQHFNifW79CFKFCWmdD9kh7CB3p8zlx1Z fAEj+ypGjtLigpzcdCPDTYzAGD0mwea4g3Fvr+chRgEORiUe3gUC7OFCrIllxZW5hxglOJiV RHhZrgCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ83pH/gsTEkhPLEnNTk0tSC2CyTJxcEo1MHIe nV8nU2nStytj71vfd0tPajAUX4t2aK857PtTIEAu7KL5Hc1vvSwBE7SFshetdtj0ctH8jjW5 bPPb93OrN4VlmvyQ+X26drucCN9aS4ane48a1ehu08meyezCyq99t+ShRdgpxv0BDwsvTu3x 3esrFbpWzcOx+lx6yI8nHKVTY+e3vt8xR4mlOCPRUIu5qDgRAM+R1tHNAgAA Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:12:23 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A40773eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQp0aGFuayB5b3UgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4gVGhlIGFkdmFudGFn ZSBvZiB0aGUgTUMtTEFHIGlzIHRoYXQgdGhlcmXigJlzIG5vdGhpbmcgY2hhbmdlcyBmb3IgU0Ug d2hpY2ggc3RpbGwgc2VlcyBpdCBMQUcuIElmIG9uZSB0byB1c2UgZGlmZmVyZW50IGRlc3RpbmF0 aW9uIElQIGFkZHJlc3NlcyBvbiBTRSBzaWRlLCB0aGVuIHRoYXQgYWR2YW50YWdlIHdpbGwgYmUg bG9zdC4gT3VyIHByb3Bvc2FsIGlzIHRvIHByZXNlcnZlIGl0Lg0KDQogICAgICAgICAgICAgICAg UmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBN YW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXks IEFwcmlsIDA4LCAyMDE2IDg6MDUgQU0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IE1hY2ggQ2hl bjsgcnRnLWJmZEBpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtdGFubWlyLXJ0Z3dnLWJm ZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnOyBtcGxz LWNoYWlyc0BpZXRmLm9yZzsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb20pDQpTdWJqZWN0 OiBSZTogVHdvIG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNl cw0KDQpIaSBHcmVnLA0KDQpXaHkgY2FudCBkaWZmZXJlbnQgbWljcm8tQkZEIHBhY2tldHMgdXNl IHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBNQy1MQUcgZW5kIHBvaW50cz8gT25lcyBnb2luZyB0byBy b3V0ZXIgMSB3aWxsIGFsbCBjYXJyeSB0aGUgc2FtZSB1bmljYXN0IElQIGFkZHJlc3MuIFRoZSBv bmVzIGdvaW5nIHRvd2FyZHMgdGhlIG90aGVyIHJvdXRlciB3aWxsIGFsbCBjYXJyeSBzb21lIG90 aGVyIElQIGFkZHJlc3MsIHdoaWNoIHdvdWxkIGJlIGNvbmZpZ3VyZWQgYWxvbmcgd2l0aCB0aGUg TUMtTEFHIGNvbmZpZ3MuDQoNCkluIGZhY3QgaSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSB1LWJmZCBw YWNrZXRzIGdvaW5nIHRvIGRpZmZlcmVudCByb3V0ZXJzIG11c3QgdXNlIGRpZmZlcmVudCBJUCBh ZGRyZXNzZXMgc28gdGhhdCB5b3UgY2FuIGFjdHVhbGx5IHZlcmlmeSB0aGUgZGF0YSBwbGFuZSBs aXZlbGluZXNzLiBXaGF0cyB0aGUgcG9pbnQgaW4gc2VuZGluZyBhIGNvbnRyaXZlZCBJUCBhZGRy ZXNzIGlmIHRoZSBwYXRoIHRoYXQgaXQgdGFrZXMgaXMgZGlmZmVyZW50IGZyb20gdGhlIG90aGVy IHJlZ3VsYXIgcGFja2V0cz8NCg0KQ2hlZXJzLCBNYW5hdg0KDQpPbiBGcmksIEFwciA4LCAyMDE2 IGF0IDY6MDkgUE0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208 bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgTWFuYXYsDQp0 aGFuayB5b3UgZm9yIHNoYXJpbmcgaW5zaWdodCB2aWV3IG9mIGRpc2N1c3Npb25zIGFyb3VuZCBS RkMgNzEzMCwgZXh0cmVtZWx5IGhlbHBmdWwuDQpXZSBiZWxpZXZlLCBhbmQgSmVmZiBpcyBjby1h dXRob3Igb2YgUkZDIDcxMzAgdG9vLCB0aGF0IE1DLUxBRyBwcmVzZW50cyBkaWZmZXJlbnQgY2Fz ZSBhbmQgdGhlIGNvbXByb21pc2UgdGhhdCB5b3XigJl2ZSBwb2ludGVkIHRvbyBpcyBqdXN0aWZp ZWQuIFdlIHdpbGwgYWRkIG1vcmUgZGV0YWlscyBvbiB0aGUgcG90ZW50aWFsIGRpZmZlcmVuY2Vz IGJldHdlZW4gdW5pY2FzdCBhbmQgbXVsdGljYXN0IGZhc3QgcGF0aHMgaW4gdGhlIG5leHQgdXBk YXRlLg0KV2UgYXJlIG9wZW4gdG8gdGhlIGRpc2N1c3Npb24gYW5kIGFsd2F5cyB3ZWxjb21lIGNv bW1lbnRzIGFuZCBhbHRlcm5hdGl2ZSBwcm9wb3NhbHMuDQoNCiAgICAgICAgICAgICAgICBSZWdh cmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IE1hbmF2 IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbTxtYWlsdG86bWFuYXZiaGF0aWFA Z21haWwuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiA3OjM5IFBNDQpUbzog TWFjaCBDaGVuDQpDYzogR3JlZ29yeSBNaXJza3k7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0 Zy1iZmRAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgZHJh ZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPjsgcnRnLWJmZC1jaGFp cnNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPjsgbXBscy1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnPjsgQWxpYSBBdGxhcyAoYWthdGxh c0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPikNClN1YmplY3Q6IFJlOiBUd28g bmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxBRyBpbnRlcmZhY2VzDQoNCkkgYmVs aWV2ZSBpdCBoYWQgdG8gZG8gd2l0aCBtdWx0aWNhc3QgZGF0YXBhdGggKGVzcGVjaWFsbHkgbGlu ayBsb2NhbCkgYmVpbmcgZGlmZmVyZW50IGZyb20gdGhlIHVuaWNhc3QgZGF0YXBhdGggaW4gbW9z dCByb3V0ZXJzLiBVc2luZyBsaW5rIGxvY2FsIG11bHRpY2FzdCBJUCBhZGRyZXNzZXMgbWF5IG5v dCBuZWNlc3NhcmlseSBndWFyYW50ZWUgVW5pY2FzdCBJUCByZWFjaGFiaWxpdHkuDQoNCldoZW4g d3JpdGluZyA3MTMwIHdlIHNwZW50IHF1aXRlIGEgYml0IG9mIHRpbWUgZW5zdXJpbmcgdGhhdCB3 ZSBkb250IGNhcnZlIG91dCBhIHNwZWNpYWwgZGF0YSBwYXRoIGZvciB0aGUgbWljcm8tQkZEIHBh Y2tldHMuIFVzaW5nIGxpbmsgbG9jYWwgd291bGQgaGF2ZSBtYWRlIGl0IGEgbG90IHNpbXBsZXIu DQoNCkFuZCB0aGlzIGlzIHdoZXJlIGkgdGhpbmsgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaXMgZmxh d2VkIC0tIHRoZXkgdXNlIGxpbmsgbG9jYWwgbXVsdGljYXN0IHRvIGVuc3VyZSBJUCB1bmljYXN0 IHJlYWNoYWJpbGl0eSB3aGljaCBpcyBpbmNvcnJlY3QuDQoNCkNoZWVycywgTWFuYXYNCg0KT24g VGh1LCBBcHIgNywgMjAxNiBhdCAxMToxNiBQTSwgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2Vp LmNvbTxtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgR3JlZyBhbmQg YWxsLA0KDQoNCg0KSSBqdXN0IGhhdmUgcXVpY2sgcmV2aWV3IG9uIHRoZSBkcmFmdHMuIElmIG15 IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgdGhlIGlkZWEgaXMgdG8gdXNlIG11bHRpY2FzdCBk ZXN0aW5hdGlvbiBhZGRyZXNzIG90aGVyIHRoYW4gdW5pY2FzdCBhZGRyZXNzIHdoZW4gIHNlbmRp bmcgQkZEIHBhY2tldHMgb3ZlciBMQUcgbGlua3MuIEFuZCBhY3R1YWxseSB0aGlzIGlkZWEgaGFz IGJlZW4gcHJvcG9zZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4t YmZkLWludGVyZmFjZS0wMCAodGhlIHByZWRlY2Vzc29yIG9mIFJGQyA3MTMwKS4gQW5kIGF0IHRo YXQgdGltZSwgdGhlIGNvLWF1dGhvcnMgb2YgUkZDIDcxMzAgZGlkIGRpc2N1c3MgdGhlIGlkZWEg b2YgdXNpbmcgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3MsIGJ1dCBmb3Igc29tZSByZWFz b24gSSBmb3JnZXQgbm93KEkgbWF5IG5lZWQgdG8gcmVpdGVyYXRlIHRoZSBkaXNjdXNzaW9ucyBv biB0aGUgYXJjaGl2ZSksIHRoZSBpZGVhIHdhcyBhYmFuZG9uZWQsIGFsdGhvdWdoIEkgc3RpbGwg dGhpbmsgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgYSBzbWFydCBpZGVhLg0KDQoN Cg0KQmVzdCByZWdhcmRzLA0KDQpNYWNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBSdGctYmZkIFtydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1i ZmQtYm91bmNlc0BpZXRmLm9yZz5dIG9uIGJlaGFsZiBvZiBHcmVnb3J5IE1pcnNreSBbZ3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+ XQ0KU2VudDogVHVlc2RheSwgQXByaWwgMDUsIDIwMTYgNjoxNg0KVG86IHJ0Zy1iZmRAaWV0Zi5v cmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGll dGYub3JnPg0KQ2M6IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYu b3JnPG1haWx0bzpkcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9y Zz47IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPG1haWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9y Zz47IG1wbHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZz47IEFs aWEgQXRsYXMgKGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4pDQpT dWJqZWN0OiBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxBRyBpbnRlcmZh Y2VzDQpEZWFyIEFsbCwNCnR3byBuZXcgZHJhZnRzLCByZWxhdGVkIHRvIFJGQyA3MTMwLCB3ZXJl IHB1Ymxpc2hlZCBiZWZvcmUgdGhlIG1lZXRpbmc6DQoNCuKAoiAgICAgICAgIEJGRCBvbiBNQy1M QUcgaW50ZXJmYWNlcyBpbiBJUCBuZXR3b3JrPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcC0wMD4NCg0K4oCiICAgICAgICAgQkZEIG9u IE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctbXBscy0wMD4NCg0KR3JlYXRs eSBhcHByZWNpYXRlIHlvdXIgcmV2aWV3cywgY29tbWVudHMsIHF1ZXN0aW9ucyBhbmQgc3VnZ2Vz dGlvbnMuDQoNClJlZ2FyZHMsDQogICAgICAgIEdyZWcNCg0KDQo= --_000_7347100B5761DC41A166AC17F22DF11221A40773eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj50aGFuayB5b3UgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4gVGhl IGFkdmFudGFnZSBvZiB0aGUgTUMtTEFHIGlzIHRoYXQgdGhlcmXigJlzIG5vdGhpbmcgY2hhbmdl cyBmb3IgU0Ugd2hpY2ggc3RpbGwgc2VlcyBpdCBMQUcuIElmIG9uZSB0byB1c2UgZGlmZmVyZW50 IGRlc3RpbmF0aW9uDQogSVAgYWRkcmVzc2VzIG9uIFNFIHNpZGUsIHRoZW4gdGhhdCBhZHZhbnRh Z2Ugd2lsbCBiZSBsb3N0LiBPdXIgcHJvcG9zYWwgaXMgdG8gcHJlc2VydmUgaXQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hbmF2IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlh QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDA4LCAyMDE2IDg6 MDUgQU08YnI+DQo8Yj5Ubzo8L2I+IEdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+Q2M6PC9iPiBNYWNo IENoZW47IHJ0Zy1iZmRAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LXRhbm1pci1ydGd3 Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnOyBydGctYmZkLWNoYWlyc0BpZXRmLm9yZzsg bXBscy1jaGFpcnNAaWV0Zi5vcmc7IEFsaWEgQXRsYXMgKGFrYXRsYXNAZ21haWwuY29tKTxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogVHdvIG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBN Qy1MQUcgaW50ZXJmYWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp IEdyZWcsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkg Y2FudCBkaWZmZXJlbnQgbWljcm8tQkZEIHBhY2tldHMgdXNlIHRoZSBJUCBhZGRyZXNzIG9mIHRo ZSBNQy1MQUcgZW5kIHBvaW50cz8gT25lcyBnb2luZyB0byByb3V0ZXIgMSB3aWxsIGFsbCBjYXJy eSB0aGUgc2FtZSB1bmljYXN0IElQIGFkZHJlc3MuIFRoZSBvbmVzIGdvaW5nIHRvd2FyZHMgdGhl IG90aGVyIHJvdXRlciB3aWxsIGFsbCBjYXJyeSBzb21lIG90aGVyIElQIGFkZHJlc3MsIHdoaWNo IHdvdWxkDQogYmUgY29uZmlndXJlZCBhbG9uZyB3aXRoIHRoZSBNQy1MQUcgY29uZmlncy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZmFj dCBpIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHUtYmZkIHBhY2tldHMgZ29pbmcgdG8gZGlmZmVyZW50 IHJvdXRlcnMgbXVzdCB1c2UgZGlmZmVyZW50IElQIGFkZHJlc3NlcyBzbyB0aGF0IHlvdSBjYW4g YWN0dWFsbHkgdmVyaWZ5IHRoZSBkYXRhIHBsYW5lIGxpdmVsaW5lc3MuIFdoYXRzIHRoZSBwb2lu dCBpbiBzZW5kaW5nIGEgY29udHJpdmVkIElQIGFkZHJlc3MgaWYgdGhlIHBhdGggdGhhdCBpdCB0 YWtlcw0KIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvdGhlciByZWd1bGFyIHBhY2tldHM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycywg TWFuYXY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gRnJpLCBBcHIgOCwgMjAxNiBhdCA2OjA5IFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBNYW5hdiw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj50aGFuayB5b3UgZm9yIHNoYXJpbmcgaW5zaWdodCB2aWV3IG9mIGRpc2N1c3Np b25zIGFyb3VuZCBSRkMgNzEzMCwgZXh0cmVtZWx5IGhlbHBmdWwuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+V2UgYmVsaWV2ZSwgYW5kIEplZmYgaXMgY28tYXV0aG9yIG9mIFJGQyA3 MTMwIHRvbywgdGhhdCBNQy1MQUcgcHJlc2VudHMgZGlmZmVyZW50IGNhc2UgYW5kIHRoZSBjb21w cm9taXNlDQogdGhhdCB5b3XigJl2ZSBwb2ludGVkIHRvbyBpcyBqdXN0aWZpZWQuIFdlIHdpbGwg YWRkIG1vcmUgZGV0YWlscyBvbiB0aGUgcG90ZW50aWFsIGRpZmZlcmVuY2VzIGJldHdlZW4gdW5p Y2FzdCBhbmQgbXVsdGljYXN0IGZhc3QgcGF0aHMgaW4gdGhlIG5leHQgdXBkYXRlLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgYXJlIG9wZW4gdG8gdGhlIGRpc2N1c3Npb24g YW5kIGFsd2F5cyB3ZWxjb21lIGNvbW1lbnRzIGFuZCBhbHRlcm5hdGl2ZSBwcm9wb3NhbHMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW5hdiBCaGF0aWEgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWFuYXZiaGF0aWFAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgQXByaWwgMDcsIDIwMTYgNzozOSBQTTxicj4NCjxiPlRvOjwvYj4gTWFjaCBDaGVuPGJyPg0K PGI+Q2M6PC9iPiBHcmVnb3J5IE1pcnNreTsgPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5ydGctYmZkQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0 bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT47IDxhIGhy ZWY9Im1haWx0bzpkcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9v bHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj4NCnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptcGxzLWNoYWly c0BpZXRmLm9yZzwvYT47IEFsaWEgQXRsYXMgKDxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFrYXRsYXNAZ21haWwuY29tPC9hPik8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGlu dGVyZmFjZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIGJlbGlldmUgaXQgaGFkIHRvIGRvIHdpdGggbXVsdGljYXN0IGRhdGFwYXRoIChl c3BlY2lhbGx5IGxpbmsgbG9jYWwpIGJlaW5nIGRpZmZlcmVudCBmcm9tIHRoZSB1bmljYXN0IGRh dGFwYXRoIGluIG1vc3Qgcm91dGVycy4gVXNpbmcgbGluayBsb2NhbCBtdWx0aWNhc3QgSVAgYWRk cmVzc2VzIG1heSBub3QNCiBuZWNlc3NhcmlseSBndWFyYW50ZWUgVW5pY2FzdCBJUCByZWFjaGFi aWxpdHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+V2hlbiB3cml0aW5nIDcxMzAgd2Ugc3BlbnQgcXVpdGUgYSBiaXQgb2YgdGltZSBlbnN1 cmluZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0IGEgc3BlY2lhbCBkYXRhIHBhdGggZm9yIHRoZSBt aWNyby1CRkQgcGFja2V0cy4gVXNpbmcgbGluayBsb2NhbCB3b3VsZCBoYXZlIG1hZGUgaXQgYSBs b3Qgc2ltcGxlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkFuZCB0aGlzIGlzIHdoZXJlIGkgdGhpbmsgdGhlIGN1cnJlbnQgcHJvcG9z YWwgaXMgZmxhd2VkIC0tIHRoZXkgdXNlIGxpbmsgbG9jYWwgbXVsdGljYXN0IHRvIGVuc3VyZSBJ UCB1bmljYXN0IHJlYWNoYWJpbGl0eSB3aGljaCBpcyBpbmNvcnJlY3QuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGVlcnMsIE1hbmF2 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBUaHUsIEFwciA3LCAyMDE2IGF0IDExOjE2IFBNLCBNYWNoIENoZW4gJmx0OzxhIGhyZWY9 Im1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hY2guY2hlbkBo dWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBHcmVnIGFuZCBhbGws PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGp1c3QgaGF2ZSBxdWljayByZXZpZXcgb24gdGhl IGRyYWZ0cy4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgaWRlYSBpcyB0byB1 c2UgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3RoZXIgdGhhbiB1bmljYXN0IGFkZHJl c3Mgd2hlbiZuYnNwOyZuYnNwO3NlbmRpbmcgQkZEIHBhY2tldHMgb3Zlcg0KIExBRyBsaW5rcy4g QW5kIGFjdHVhbGx5IHRoaXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQt aW50ZXJmYWNlLTAwPC9hPiZuYnNwOyh0aGUgcHJlZGVjZXNzb3Igb2YgUkZDIDcxMzApLiBBbmQg YXQmbmJzcDt0aGF0IHRpbWUsIHRoZSBjby1hdXRob3JzIG9mIFJGQyA3MTMwIGRpZCBkaXNjdXNz Jm5ic3A7dGhlIGlkZWEgb2YgdXNpbmcgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3MsIGJ1 dCBmb3Igc29tZSByZWFzb24gSSBmb3JnZXQgbm93KEkgbWF5IG5lZWQgdG8gcmVpdGVyYXRlIHRo ZQ0KIGRpc2N1c3Npb25zIG9uIHRoZSBhcmNoaXZlKSwgdGhlIGlkZWEgd2FzIGFiYW5kb25lZCwg YWx0aG91Z2ggSSBzdGlsbCB0aGluayBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBh IHNtYXJ0IGlkZWEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CZXN0IHJlZ2FyZHMsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPk1hY2gmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJj ZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IFJ0Zy1iZmQgWzxhIGhyZWY9Im1haWx0 bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGctYmZkLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KIG9uIGJlaGFsZiBvZiBHcmVnb3J5IE1pcnNreSBbPGEgaHJlZj0i bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT5dPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFw cmlsIDA1LCAyMDE2IDY6MTY8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGctYmZk QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBpZXRmLm9yZzwvYT47DQo8YSBocmVm PSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1t Yy1sYWctaXBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LXRhbm1pci1y dGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0 Zy1iZmQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGctYmZkLWNoYWlyc0Bp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPg0KbXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBBbGlhIEF0bGFzICg8YSBocmVm PSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ha2F0bGFzQGdtYWls LmNvbTwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0p QkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+RGVhciBBbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnR3byBuZXcgZHJh ZnRzLCByZWxhdGVkIHRvIFJGQyA3MTMwLCB3ZXJlIHB1Ymxpc2hlZCBiZWZvcmUgdGhlIG1lZXRp bmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5 bWJvbDtjb2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXAtMDAiIHRh cmdldD0iX2JsYW5rIj5CRkQgb24gTUMtTEFHIGludGVyZmFjZXMgaW4gSVAgbmV0d29yazwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9s O2NvbG9yOmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzLTAwIiB0YXJn ZXQ9Il9ibGFuayI+QkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazwv YT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdyZWF0bHkgYXBwcmVjaWF0 ZSB5b3VyIHJldmlld3MsIGNvbW1lbnRzLCBxdWVzdGlvbnMgYW5kIHN1Z2dlc3Rpb25zLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVp biI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF11221A40773eusaamb103erics_-- From nobody Fri Apr 8 09:14:20 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A658312D5A5; Fri, 8 Apr 2016 09:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1Xb4mYfwh6Z; Fri, 8 Apr 2016 09:14:15 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351BE12D098; Fri, 8 Apr 2016 09:14:15 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-21-5707d8afc1c3 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 0F.B7.22441.FA8D7075; Fri, 8 Apr 2016 18:13:36 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 12:14:13 -0400 From: Gregory Mirsky To: "Reshad Rahman (rrahman)" , Manav Bhatia Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAGbkoAAB59e4A== Date: Fri, 8 Apr 2016 16:14:13 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A40798eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyuXRPoO6GG+zhBp2POCw+PbzEbHFg00FG i8uT2tgt1l0+xWZxa+lKVotrK1rZLZbcvsdu8fnPNkYHDo8pvzeyeuycdZfdY8mSn0weXy5/ ZgtgieKySUnNySxLLdK3S+DKeLrkP0vB0heMFRf/mTUwrrzI2MXIySEhYCKx+O1xZghbTOLC vfVsXYxcHEICRxkl+v/8ZodwljFKtHZ1gFWxCRhJvNjYww5iiwhESuxtOwPWwSxwkUni057D bCAJYQFHie/zrzFDFDlJfLiymBXCDpNYuGYO2GoWARWJizMegdXzCvhKPJp/gAli20Rmiebp O8EaOAUMJBrnvAezGYHu+35qDROIzSwgLnHryXwmiLsFJJbsOQ/1g6jEy8f/WCFsJYmPv+ez Q9TnSzybupAdYpmgxMmZT1gmMIrOQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZ fAEj+ypGjtLigpzcdCPDTYzAaD0mwea4g3Fvr+chRgEORiUe3gUC7OFCrIllxZW5hxglOJiV RHhZrgCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ83pH/gsTEkhPLEnNTk0tSC2CyTJxcEo1MDZ+ dPjQuF80bv/OVP0Q/wodBtOwwyKygZ8XqgTNX/V6ct3n+qlTz0nF/jJ71vzx+Vp3RefyyOd3 8q/zqUXPydKtXb6uInHjkue/d7vL86yNuPtk/9ktGpWeS1qWt72b4KlsMakh35Xvr7IA6+ZM Q/7oH96KZyt82Nazhwfl14apt/TJv780T4mlOCPRUIu5qDgRAFRVLPbSAgAA Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:14:18 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A40798eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Reshad, thank you for your comments. Indeed, RFC 7130 is restricted and thus hardly= applicable to MC-LAG case. We realize that if this proposal is adopted it = not only enhance applicability on u-BFD but will update RFC 7130. Regards, Greg From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] Sent: Friday, April 08, 2016 8:51 AM To: Manav Bhatia; Gregory Mirsky Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls-ch= airs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; rtg-bfd-ch= airs@ietf.org Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces I agree with Manav, and nothing in RFC7130 seems to preclude using differen= t unicast IP address as destination on different member links. Regards, Reshad (as individual contributor). From: Rtg-bfd > o= n behalf of Manav Bhatia > Date: Friday, April 8, 2016 at 11:04 AM To: Gregory Mirsky > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "mpls@ie= tf.org" >, "mpls-= chairs@ietf.org" >, "Alia Atlas (akatlas@gmail.com)" >, "rtg-bfd@ietf.org" >, "rtg-b= fd-chairs@ietf.org" > Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg, Why cant different micro-BFD packets use the IP address of the MC-LAG end p= oints? Ones going to router 1 will all carry the same unicast IP address. T= he ones going towards the other router will all carry some other IP address= , which would be configured along with the MC-LAG configs. In fact i would argue that the u-bfd packets going to different routers mus= t use different IP addresses so that you can actually verify the data plane= liveliness. Whats the point in sending a contrived IP address if the path = that it takes is different from the other regular packets? Cheers, Manav On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky > wrote: Hi Manav, thank you for sharing insight view of discussions around RFC 7130, extremel= y helpful. We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents dif= ferent case and the compromise that you've pointed too is justified. We wil= l add more details on the potential differences between unicast and multica= st fast paths in the next update. We are open to the discussion and always welcome comments and alternative p= roposals. Regards, Greg From: Manav Bhatia [mailto:manavbhatia@gmail.com] Sent: Thursday, April 07, 2016 7:39 PM To: Mach Chen Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.or= g; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.= org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces I believe it had to do with multicast datapath (especially link local) bein= g different from the unicast datapath in most routers. Using link local mul= ticast IP addresses may not necessarily guarantee Unicast IP reachability. When writing 7130 we spent quite a bit of time ensuring that we dont carve = out a special data path for the micro-BFD packets. Using link local would h= ave made it a lot simpler. And this is where i think the current proposal is flawed -- they use link l= ocal multicast to ensure IP unicast reachability which is incorrect. Cheers, Manav On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen > wrote: Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] o= n behalf of Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A40798eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Reshad,

thank you for your commen= ts. Indeed, RFC 7130 is restricted and thus hardly applicable to MC-LAG cas= e. We realize that if this proposal is adopted it not only enhance applicability on u-BFD but will update RFC 7130.=

 <= /p>

    &= nbsp;            &nb= sp;            =   Greg

 <= /p>

From: Reshad R= ahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; = mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; rtg= -bfd-chairs@ietf.org
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

I agree with Manav, and not= hing in RFC7130 seems to preclude using different unicast IP address as des= tination on different member links.

 

Regards,<= /p>

Reshad (as individual contr= ibutor).

 

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Manav Bhatia= <manavbhatia@gmail.com>=
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" <draft-tanmir= -rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Alia A= tlas (akatlas@gmail.com)" <= ;akatlas@gmail.com>, "rtg-bfd@ietf.org" <<= a href=3D"mailto:rtg-bfd@ietf.org">rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <<= a href=3D"mailto:rtg-bfd-chairs@ietf.org">rtg-bfd-chairs@ietf.org> Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Greg,

 

Why cant different micro-BF= D packets use the IP address of the MC-LAG end points? Ones going to router= 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which= would be configured along with the MC-LAG configs.

 

In fact i would argue that = the u-bfd packets going to different routers must use different IP addresse= s so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it take= s is different from the other regular packets?

 

Cheers, Manav

 

On Fri, Apr 8, 2016 at 6:09= PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:<= /p>

Hi Manav,

thank you for sharing insight view of d= iscussions around RFC 7130, extremely helpful.

We believe, and Jeff is co-author of RF= C 7130 too, that MC-LAG presents different case and the compromise that you’ve pointed too is justified. We will add more details on th= e potential differences between unicast and multicast fast paths in the nex= t update.

We are open to the discussion and alway= s welcome comments and alternative proposals.

 

      &nb= sp;         Regards,

      &nb= sp;            =              Gr= eg

 

From: Manav Bhatia [mailto:= manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

I believe it had to do with multicast = datapath (especially link local) being different from the unicast datapath = in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability. <= o:p>

 

When writing 7130 we spent quite a bit= of time ensuring that we dont carve out a special data path for the micro-= BFD packets. Using link local would have made it a lot simpler.

 

And this is where i think the current = proposal is flawed -- they use link local multicast to ensure IP unicast re= achability which is incorrect.

 

Cheers, Manav

 

On Thu, Apr 7, 2016 at 11:16 PM, Mach = Chen <mach.che= n@huawei.com> wrote:

Hi Greg and all,=

 

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach <= /o:p>

From: Rtg-= bfd [rtg-bfd-= bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,

two new drafts, related to RFC 7130, w= ere published before the meeting:

· &n= bsp;       BFD on MC-LAG interfaces= in IP network

· &n= bsp;       BFD on MC-LAG interfac= es in IP/MPLS network

 

Greatly appreciate your reviews, comme= nts, questions and suggestions.

 

Regards,

        Greg=

 

 

--_000_7347100B5761DC41A166AC17F22DF11221A40798eusaamb103erics_-- From nobody Fri Apr 8 09:28:34 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206B512D5B4; Fri, 8 Apr 2016 09:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgBtdzdPdm8h; Fri, 8 Apr 2016 09:28:30 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2840612D57E; Fri, 8 Apr 2016 09:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26352; q=dns/txt; s=iport; t=1460132910; x=1461342510; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SjgPaxJ8j5MiDVEHbQ7RpIsthtY+Wp/a+WmSourG4ig=; b=MqBOkhC3LkM+uN8N1bBVlHvW5+U8aiFW2iw5JUWMistUrZJlmW1XaD4/ +JSuBfPYWBfbuh0JQymmVWOJtkNwsEfV5670yq9kBXfOE7BjnSxI2Dn6l cRNWKKGKzcgeoRrbIphHzDNLS85Cj5aaG0pdLLTnrq4bH47wwmnHSBtTv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgBw2wdX/4YNJK1cgmtMU30GrmeLW?= =?us-ascii?q?AENgXMhhWwCgTM4FAEBAQEBAQFlJ4RBAQEBBC1MEAIBCBEDAQEBGgIFBwchERQ?= =?us-ascii?q?JCAIEAQ0FH4dzAxIOuz0NhSEBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuCQ?= =?us-ascii?q?YIeDQknAoR3BZMZhDoxAYV2hiCBdYFnjSaGH4Erh1oBHgEBQoIEGYFKbFqHJD0?= =?us-ascii?q?BfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208,217";a="257609769" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 16:28:28 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u38GSStK022743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 16:28:28 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 11:28:27 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 11:28:27 -0500 From: "Reshad Rahman (rrahman)" To: Gregory Mirsky , Manav Bhatia Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZAB2XmwAAFPl8AAAFFQWAAAJbzID//8FyAA== Date: Fri, 8 Apr 2016 16:28:27 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.167] Content-Type: multipart/alternative; boundary="_000_D32D53C813B077rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:28:33 -0000 --_000_D32D53C813B077rrahmanciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Greg, With the proposal in the draft won=92t you need a change to indicate that t= he link-local multicast address should be used? Regards, Reshad. From: Rtg-bfd > o= n behalf of Gregory Mirsky > Date: Friday, April 8, 2016 at 12:12 PM To: Manav Bhatia > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "mpls@ie= tf.org" >, "mpls-= chairs@ietf.org" >, "Alia Atlas (akatlas@gmail.com)" >, "rtg-bfd@ietf.org" >, "rtg-b= fd-chairs@ietf.org" > Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Manav, thank you for your consideration. The advantage of the MC-LAG is that there= =92s nothing changes for SE which still sees it LAG. If one to use differen= t destination IP addresses on SE side, then that advantage will be lost. Ou= r proposal is to preserve it. Regards, Greg From: Manav Bhatia [mailto:manavbhatia@gmail.com] Sent: Friday, April 08, 2016 8:05 AM To: Gregory Mirsky Cc: Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg, Why cant different micro-BFD packets use the IP address of the MC-LAG end p= oints? Ones going to router 1 will all carry the same unicast IP address. T= he ones going towards the other router will all carry some other IP address= , which would be configured along with the MC-LAG configs. In fact i would argue that the u-bfd packets going to different routers mus= t use different IP addresses so that you can actually verify the data plane= liveliness. Whats the point in sending a contrived IP address if the path = that it takes is different from the other regular packets? Cheers, Manav On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky > wrote: Hi Manav, thank you for sharing insight view of discussions around RFC 7130, extremel= y helpful. We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents dif= ferent case and the compromise that you=92ve pointed too is justified. We w= ill add more details on the potential differences between unicast and multi= cast fast paths in the next update. We are open to the discussion and always welcome comments and alternative p= roposals. Regards, Greg From: Manav Bhatia [mailto:manavbhatia@gmail.com] Sent: Thursday, April 07, 2016 7:39 PM To: Mach Chen Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.or= g; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.= org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces I believe it had to do with multicast datapath (especially link local) bein= g different from the unicast datapath in most routers. Using link local mul= ticast IP addresses may not necessarily guarantee Unicast IP reachability. When writing 7130 we spent quite a bit of time ensuring that we dont carve = out a special data path for the micro-BFD packets. Using link local would h= ave made it a lot simpler. And this is where i think the current proposal is flawed -- they use link l= ocal multicast to ensure IP unicast reachability which is incorrect. Cheers, Manav On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen > wrote: Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] o= n behalf of Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: =B7 BFD on MC-LAG interfaces in IP network =B7 BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_D32D53C813B077rrahmanciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7421AA362D82434C88260D7BD7EAE4EB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Greg,

With the proposal in the draft won=92t you need a change to indicate t= hat the link-local multicast address should be used?

Regards,
Reshad.

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Gr= egory Mirsky <gregory.mir= sky@ericsson.com>
Date: Friday, April 8, 2016 at 12:1= 2 PM
To: Manav Bhatia <manavbhatia@gmail.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@= tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>= ;, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com>, "= rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: RE: Two new drafts on (mic= ro-)BFD over MC-LAG interfaces

Hi Manav,

thank you for your consideration. T= he advantage of the MC-LAG is that there=92s nothing changes for SE which s= till sees it LAG. If one to use different destination IP addresses on SE side, then that advantage will be lost. Our= proposal is to preserve it.

 

      = ;          Regards,=

      = ;            &n= bsp;            = ; Greg

 

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Friday, April 08, 2016 8:05 AM
To: Gregory Mirsky
Cc: Mach Chen; rtg-bfd@ietf.org<= /a>; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-c= hairs@ietf.org; Alia Atlas (akatla= s@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Greg,

 

Why cant different micro-BFD packets use the IP addr= ess of the MC-LAG end points? Ones going to router 1 will all carry the sam= e unicast IP address. The ones going towards the other router will all carr= y some other IP address, which would be configured along with the MC-LAG configs.

 

In fact i would argue that the u-bfd packets going t= o different routers must use different IP addresses so that you can actuall= y verify the data plane liveliness. Whats the point in sending a contrived = IP address if the path that it takes is different from the other regular packets?

 

Cheers, Manav

 

On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <<= a href=3D"mailto:gregory.mirsky@ericsson.com" target=3D"_blank">gregory.mir= sky@ericsson.com> wrote:

Hi Manav,

thank you for sharing insight view of discussions= around RFC 7130, extremely helpful.

We believe, and Jeff is co-author of RFC 7130 too= , that MC-LAG presents different case and the compromise that you=92ve pointed too is justified. We will add mor= e details on the potential differences between unicast and multicast fast p= aths in the next update.

We are open to the discussion and always welcome = comments and alternative proposals.

 

        &= nbsp;       Regards,

        &= nbsp;           &nbs= p;           Greg<= o:p>

 

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

I believe it had to do with multicast datapath (especially link lo= cal) being different from the unicast datapath in most routers. Using link = local multicast IP addresses may not necessarily guarantee Unicast IP reachability. 

 

When writing 7130 we spent quite a bit of time ensuring that we do= nt carve out a special data path for the micro-BFD packets. Using link loca= l would have made it a lot simpler.

 

And this is where i think the current proposal is flawed -- they u= se link local multicast to ensure IP unicast reachability which is incorrec= t.

 

Cheers, Manav

 

On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:<= o:p>

Hi Greg and all,

 

I just have quick review on the drafts. If my understanding is corr= ect, the idea is to use multicast destination address other than unicast ad= dress when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach 

From: Rtg-bfd [rtg-bfd-bou= nces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,

two new drafts, related to RFC 7130, w= ere published before the meeting:

=B7         BFD on MC-LAG interfa= ces in IP network

=B7         BFD on MC-LAG inter= faces in IP/MPLS network

 

Greatly appreciate your reviews, comme= nts, questions and suggestions.

 

Regards,

        Greg=

 

 

 --_000_D32D53C813B077rrahmanciscocom_-- From nobody Fri Apr 8 10:34:06 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CB712D0E4; Fri, 8 Apr 2016 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zzaRjKgBHtih; Fri, 8 Apr 2016 10:34:01 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 30A1312D6AD; Fri, 8 Apr 2016 10:34:00 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id o66so51576597ywc.3; Fri, 08 Apr 2016 10:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OciFEvJ+Pi1mb8m8lYvr4NMZKTIi7ti/Tj9W+3Lu40U=; b=Vvre+dhbLpB8dzDKymkPzL0+yVwHhenTejqmWmfruYU1rs8PABvUhCPwRbcd95wu0f yfG8zAU4up3gS4bde/aJ31o5bRcPRBvCmX/5gqaPuk0U6hLjAKB3QhR1u02zrLoYgq6E hRATfjb4hpxpp53veLvcWu/Gc8MQrAEKpTv1v+W2aEtwXCpkHlBwWPrRW+WJOGV1v7gV ZlxwkQAt8LmJBevDcg2j31vujHw6UnkNs7dQWZjL8k93Dcl9nvvlPijpH2fOFltJu/9j r5R26KDCZyl2Mbk5eosqYM7/6tiM+VvctoF4jM329ZKgm5BjrohWD+b5g9A1ClgfuD12 jfIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OciFEvJ+Pi1mb8m8lYvr4NMZKTIi7ti/Tj9W+3Lu40U=; b=Bqq2dxGXZo982Z1IkeDoPU5PT0NYzfU4312hk4mRsCgJqLYFKksk8yg8rkYnMqjb4d XKGkQDmjRpPsRe5Zne117ELnZKQVNUVMx1vZUwRUD4GbJ3m5XMHoRkHSxzaDfYiwA6s2 Qv61k3buLifs9ozevl7zZ+4tg0qm3g9onyVW82pHZHSa18FyrSCLjtz3t5wHjt2w+smn bSWCrQ7lykcoqDnvtTRM7nmZBztfr+HBWzdqMMHFlFfsZiWh7JBf6S6qCU87RDhZbrLH wU4XNF5/vQZ6k+arx+Vnvcep7ByzAkfum90Rq0ehNvFJZFnPCRmxYhoXTIEaIt8w2XI7 dmCA== X-Gm-Message-State: AD7BkJKibIlXyjdAbN2IY9aMCBk0NNZ0NPHvnSQrqWJrBjUsNkgGbeWDstXOxRPHysZ3cr9suZArxfCTpHvUkg== MIME-Version: 1.0 X-Received: by 10.129.77.65 with SMTP id a62mr5067252ywb.87.1460136839397; Fri, 08 Apr 2016 10:33:59 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Fri, 8 Apr 2016 10:33:59 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 23:03:59 +0530 Message-ID: Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a1140b7daa2c76a052ffc99c3 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 17:34:04 -0000 --001a1140b7daa2c76a052ffc99c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, Not sure i understand how it can "update RFC 7130". Is that by using a link local mcast IP instead of a Unicast IP? We know that, that wouldnt work. Cheers, Manav On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky wrote: > Hi Reshad, > > thank you for your comments. Indeed, RFC 7130 is restricted and thus > hardly applicable to MC-LAG case. We realize that if this proposal is > adopted it not only enhance applicability on u-BFD but will update RFC 71= 30. > > > > Regards, > > Greg > > > > *From:* Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] > *Sent:* Friday, April 08, 2016 8:51 AM > *To:* Manav Bhatia; Gregory Mirsky > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; > rtg-bfd-chairs@ietf.org > > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > I agree with Manav, and nothing in RFC7130 seems to preclude using > different unicast IP address as destination on different member links. > > > > Regards, > > Reshad (as individual contributor). > > > > *From: *Rtg-bfd on behalf of Manav Bhatia < > manavbhatia@gmail.com> > *Date: *Friday, April 8, 2016 at 11:04 AM > *To: *Gregory Mirsky > *Cc: *"draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" < > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" < > mpls@ietf.org>, "mpls-chairs@ietf.org" , "Alia > Atlas (akatlas@gmail.com)" , "rtg-bfd@ietf.org" < > rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" > *Subject: *Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > Hi Greg, > > > > Why cant different micro-BFD packets use the IP address of the MC-LAG end > points? Ones going to router 1 will all carry the same unicast IP address= . > The ones going towards the other router will all carry some other IP > address, which would be configured along with the MC-LAG configs. > > > > In fact i would argue that the u-bfd packets going to different routers > must use different IP addresses so that you can actually verify the data > plane liveliness. Whats the point in sending a contrived IP address if th= e > path that it takes is different from the other regular packets? > > > > Cheers, Manav > > > > On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > > Hi Manav, > > thank you for sharing insight view of discussions around RFC 7130, > extremely helpful. > > We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents > different case and the compromise that you=E2=80=99ve pointed too is just= ified. We > will add more details on the potential differences between unicast and > multicast fast paths in the next update. > > We are open to the discussion and always welcome comments and alternative > proposals. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Thursday, April 07, 2016 7:39 PM > *To:* Mach Chen > *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > I believe it had to do with multicast datapath (especially link local) > being different from the unicast datapath in most routers. Using link loc= al > multicast IP addresses may not necessarily guarantee Unicast IP > reachability. > > > > When writing 7130 we spent quite a bit of time ensuring that we dont carv= e > out a special data path for the micro-BFD packets. Using link local would > have made it a lot simpler. > > > > And this is where i think the current proposal is flawed -- they use link > local multicast to ensure IP unicast reachability which is incorrect. > > > > Cheers, Manav > > > > On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: > > Hi Greg and all, > > > > I just have quick review on the drafts. If my understanding is correct, > the idea is to use multicast destination address other than unicast addre= ss > when sending BFD packets over LAG links. And actually this idea has been > proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the > predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 di= d > discuss the idea of using multicast destination address, but for some > reason I forget now(I may need to reiterate the discussions on the > archive), the idea was abandoned, although I still think multicast > destination address is a smart idea. > > > > Best regards, > > Mach > ------------------------------ > > *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ > gregory.mirsky@ericsson.com] > *Sent:* Tuesday, April 05, 2016 6:16 > *To:* rtg-bfd@ietf.org; mpls@ietf.org > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; > rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( > akatlas@gmail.com) > *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces > > Dear All, > > two new drafts, related to RFC 7130, were published before the meeting: > > =C2=B7 BFD on MC-LAG interfaces in IP network > > > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network > > > > > Greatly appreciate your reviews, comments, questions and suggestions. > > > > Regards, > > Greg > > > > > --001a1140b7daa2c76a052ffc99c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a1140b7daa2c76a052ffc99c3-- From nobody Fri Apr 8 11:43:27 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C3612D53A; Fri, 8 Apr 2016 11:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 stlYrNalqw6h; Fri, 8 Apr 2016 11:43:20 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 D497C12D510; Fri, 8 Apr 2016 11:43:19 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t10so144987462ywa.0; Fri, 08 Apr 2016 11:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=BuUKHdXn2DaCPugCE0YhFDsx1ATdIuhVIP/f39XEcgk=; b=JJGIyoJmaTvuW9lVhEbNrC+loMdeYxwsqr31FFyXnyar5oXMEK33ow9qctoHbr2Cd/ STyN11chwfU5LtCsapFOoojjqeoGZN5E/pTcemrvd1XO52duA4Q49+TA1zMPKxQ9PtWZ l1nkKmdrzIYLG+OxEXl7ZzwrllzMJx/T9tnSG76IqyXaQzHCN2gQyrh0goJO1L3jt8zI HLiq2VllX8SNpgA02//XPtdnPFS7/NPagh4IOQbiPsc1YP6I9mNkE4dflW0vAI3/G02q F1O+YdVtFAHREVYt7fR/OqEHd8ZP+3R0i8JotbC4yLvRhAN8RSrYtOkLV+xc6729BxMe kV2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BuUKHdXn2DaCPugCE0YhFDsx1ATdIuhVIP/f39XEcgk=; b=DpLyRbQf6PE4eDGV4sY2VAZHSCX7VGLKe3Nk6n1DWXiF/8VbMwUd/5bnkHY/kwJbRG 4ceJI3BOH0mibPmAdlNfZ2/Z1aomiakVqm24IXcGXOR+U/GHuLqYW4NjSRmnGxYZzH2G cn3KDo8AjdEXqC5NWy+favhWTbcaLdxGLQevV2zp88xI6uzqcpjxfJZwr8OH5FAy7ncT XeJQcBwOLVpbu+y3flLsOFlxteIHPeNeErpPHBAVTXf9aszmQ6cJf2dIUASTqlpS6lDm Sq6j+v2aZbRPr3ufHZ8qSvnjLAI1GVP1joFx2gDi1D6vCmP2EhmGulOFINhL2bfzr1tM xjWg== X-Gm-Message-State: AD7BkJLpHe0KHKeErdQP2f5XmUj8Kdg4EpqEbP+BmATwzbn1zYH13COY4lRtJ1oet4Id+i+BUDO/uxFdv13RBA== MIME-Version: 1.0 X-Received: by 10.129.159.194 with SMTP id w185mr5711357ywg.297.1460140998984; Fri, 08 Apr 2016 11:43:18 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 11:43:18 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 11:43:18 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 11:43:18 -0700 Message-ID: Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces From: Greg Mirsky To: "Reshad Rahman (rrahman)" Content-Type: multipart/alternative; boundary=94eb2c0c0126910dbd052ffd91e1 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 18:43:23 -0000 --94eb2c0c0126910dbd052ffd91e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Reshad, yes, link local multicast may be used in MC-LAG scenario. The draft states that it MAY be used while the broadcast has SHOULD normative. But we are all open to the discussion. Regards, Greg On Apr 8, 2016 11:28 AM, "Reshad Rahman (rrahman)" wrote: > Hi Greg, > > With the proposal in the draft won=E2=80=99t you need a change to indicat= e that > the link-local multicast address should be used? > > Regards, > Reshad. > > From: Rtg-bfd on behalf of Gregory Mirsky < > gregory.mirsky@ericsson.com> > Date: Friday, April 8, 2016 at 12:12 PM > To: Manav Bhatia > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" < > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" < > mpls@ietf.org>, "mpls-chairs@ietf.org" , "Alia > Atlas (akatlas@gmail.com)" , "rtg-bfd@ietf.org" < > rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" > Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces > > Hi Manav, > > thank you for your consideration. The advantage of the MC-LAG is that > there=E2=80=99s nothing changes for SE which still sees it LAG. If one to= use > different destination IP addresses on SE side, then that advantage will b= e > lost. Our proposal is to preserve it. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com ] > > *Sent:* Friday, April 08, 2016 8:05 AM > *To:* Gregory Mirsky > *Cc:* Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org; > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > Hi Greg, > > > > Why cant different micro-BFD packets use the IP address of the MC-LAG end > points? Ones going to router 1 will all carry the same unicast IP address= . > The ones going towards the other router will all carry some other IP > address, which would be configured along with the MC-LAG configs. > > > > In fact i would argue that the u-bfd packets going to different routers > must use different IP addresses so that you can actually verify the data > plane liveliness. Whats the point in sending a contrived IP address if th= e > path that it takes is different from the other regular packets? > > > > Cheers, Manav > > > > On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > > Hi Manav, > > thank you for sharing insight view of discussions around RFC 7130, > extremely helpful. > > We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents > different case and the compromise that you=E2=80=99ve pointed too is just= ified. We > will add more details on the potential differences between unicast and > multicast fast paths in the next update. > > We are open to the discussion and always welcome comments and alternative > proposals. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Thursday, April 07, 2016 7:39 PM > *To:* Mach Chen > *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > I believe it had to do with multicast datapath (especially link local) > being different from the unicast datapath in most routers. Using link loc= al > multicast IP addresses may not necessarily guarantee Unicast IP > reachability. > > > > When writing 7130 we spent quite a bit of time ensuring that we dont carv= e > out a special data path for the micro-BFD packets. Using link local would > have made it a lot simpler. > > > > And this is where i think the current proposal is flawed -- they use link > local multicast to ensure IP unicast reachability which is incorrect. > > > > Cheers, Manav > > > > On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: > > Hi Greg and all, > > > > I just have quick review on the drafts. If my understanding is correct, > the idea is to use multicast destination address other than unicast addre= ss > when sending BFD packets over LAG links. And actually this idea has been > proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the > predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 di= d > discuss the idea of using multicast destination address, but for some > reason I forget now(I may need to reiterate the discussions on the > archive), the idea was abandoned, although I still think multicast > destination address is a smart idea. > > > > Best regards, > > Mach > ------------------------------ > > *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ > gregory.mirsky@ericsson.com] > *Sent:* Tuesday, April 05, 2016 6:16 > *To:* rtg-bfd@ietf.org; mpls@ietf.org > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; > rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( > akatlas@gmail.com) > *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces > > Dear All, > > two new drafts, related to RFC 7130, were published before the meeting: > > =C2=B7 BFD on MC-LAG interfaces in IP network > > > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network > > > > > Greatly appreciate your reviews, comments, questions and suggestions. > > > > Regards, > > Greg > > > > > --94eb2c0c0126910dbd052ffd91e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Reshad,
yes, link local multicast may be used in MC-LAG scenario. The draft states = that it MAY be used while the broadcast has SHOULD normative. But we are al= l open to the discussion.
Regards, Greg

On Apr 8, 2016 11:28 AM, "Reshad Rahman (rr= ahman)" <rrahman@cisco.com= > wrote:
Hi Greg,

With the proposal in the draft won=E2=80=99t you need a change to indi= cate that the link-local multicast address should be used?

Regards,
Reshad.


Hi Manav,

thank you for your consideration. The advant= age of the MC-LAG is that there=E2=80=99s nothing changes for SE which stil= l sees it LAG. If one to use different destination IP addresses on SE side, then that advantage will be lost. Our= proposal is to preserve it.

=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=C2=A0=C2=A0=C2=A0 Regards,

=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg<= u>

=C2=A0

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Friday, April 08, 2016 8:05 AM
To: Gregory Mirsky
Cc: Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

Hi Greg,

=C2=A0

Why cant different micro-BFD packets use the IP addr= ess of the MC-LAG end points? Ones going to router 1 will all carry the sam= e unicast IP address. The ones going towards the other router will all carr= y some other IP address, which would be configured along with the MC-LAG configs.

=C2=A0

In fact i would argue that the u-bfd packets going t= o different routers must use different IP addresses so that you can actuall= y verify the data plane liveliness. Whats the point in sending a contrived = IP address if the path that it takes is different from the other regular packets?

=C2=A0

Cheers, Manav

=C2=A0

On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <<= a href=3D"mailto:gregory.mirsky@ericsson.com" target=3D"_blank">gregory.mir= sky@ericsson.com> wrote:

Hi Manav,

thank you for sharing insight view of discus= sions around RFC 7130, extremely helpful.

We believe, and Jeff is co-author of RFC 713= 0 too, that MC-LAG presents different case and the compromise that you=E2=80=99ve pointed too is justified. We will a= dd more details on the potential differences between unicast and multicast = fast paths in the next update.

We are open to the discussion and always wel= come comments and alternative proposals.

=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=C2=A0=C2=A0=C2=A0 Regards,<= /u>

=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg<= /span>

=C2=A0

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

I believe it had to do with multicast datapath (espe= cially link local) being different from the unicast datapath in most router= s. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability.=C2=A0

=C2=A0

When writing 7130 we spent quite a bit of time ensur= ing that we dont carve out a special data path for the micro-BFD packets. U= sing link local would have made it a lot simpler.

=C2=A0

And this is where i think the current proposal is fl= awed -- they use link local multicast to ensure IP unicast reachability whi= ch is incorrect.

=C2=A0

Cheers, Manav

=C2=A0

On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,

=C2=A0

I just have quick review on the drafts. If my understanding is correct, th= e idea is to use multicast destination address other than unicast address w= hen=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0

Best regards,

Mach=C2=A0

From: Rtg-b= fd [rtg-bfd-bou= nces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= u>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfa= ces in IP network

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG inter= faces in IP/MPLS network

=C2=A0<= /u>

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0

--94eb2c0c0126910dbd052ffd91e1-- From nobody Fri Apr 8 12:01:24 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDED12D5DF; Fri, 8 Apr 2016 12:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Mvt73LMit1lG; Fri, 8 Apr 2016 12:01:20 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 24C7A12D61B; Fri, 8 Apr 2016 12:01:04 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t10so145518967ywa.0; Fri, 08 Apr 2016 12:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=euJG4Y4zwsnPxPTaQ2xlW4mmIOPwK8y5Qk8Ev2buoI8=; b=QsHPFe5W3pkhg040xEDx3mQ/nf9+uuhRQVyMvPkyEC/aLT5sYG4upCRgh8dVE4ygBM guvCBMdIxVsStoKxKYQhI18dw/1Ym/tP/SBV6FpL1aCYFKOEZp9lsHu376lWdhYQkNLP 3F92hi6QfYm0t7cNW801SzLTnecOg8yGKZ2RyVj+ClAwww9VH0rPe3l0xrc18gDfnFaC Hi7MLUmFiTQ23tIwl4Eruw8pday9wbZASvAF47vAzW144dgh67Y9HcHpzicxdfW2hm8v wx+pJxIH8n68dCLtX1l9ufAiF9tPuVjJSNioaC4npaLp0UXHiJhZ/PVlrBg/4ouwP2in Tg3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=euJG4Y4zwsnPxPTaQ2xlW4mmIOPwK8y5Qk8Ev2buoI8=; b=kpa9wiD1eMhn91nBkoeks88UlayuXM1yCK82KIJ8Bzkl+bQ5KCnNkdUX/gsK4nUEuW EfPbiwL1Ev1Vb92Apv/WneGVuVQt2D/MZZLEIYQzJdPNfcV1k/EIp42oCCCEjxW5aZR0 rllnxjf47T9+CUF87kAhtOWD5XMJgV9tINYcE0bTApr1aDHqSblyWTr1aRR5AAVnwd/+ mtWaHzfzHny5JpUNHbnzrcJF5TENvzJFVd4dnnrd7WyGyHBytXm3bJ5dpJFgLEqPno6I 0X/4DGKawwGqWprY9DSk1uifMfzUO4y/zJ/HDlxuxXC3S1reJvNf0AARCHNfzzhL9Uv4 eXpQ== X-Gm-Message-State: AD7BkJLscjatv1B+E1rl0HVCwwriNDM4kofmnsEeWbJ5a5UI9hxT43IWmm9nWVu8EB2VyWQLsah888xfxclfHA== MIME-Version: 1.0 X-Received: by 10.13.220.197 with SMTP id f188mr5232114ywe.172.1460142064034; Fri, 08 Apr 2016 12:01:04 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 12:01:03 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 12:01:03 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 12:01:03 -0700 Message-ID: Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces From: Greg Mirsky To: Manav Bhatia Content-Type: multipart/alternative; boundary=94eb2c07bc900c8772052ffdd182 Archived-At: Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org, "rtg-bfd-chairs@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 19:01:24 -0000 --94eb2c07bc900c8772052ffdd182 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Manav, the update could be in addition of either broadcast or link local multicast or both with appropriate normative language. But I would not agree that these wouldn't work. Regards, Greg On Apr 8, 2016 12:34 PM, "Manav Bhatia" wrote: > Hi Greg, > > Not sure i understand how it can "update RFC 7130". Is that by using a > link local mcast IP instead of a Unicast IP? > > We know that, that wouldnt work. > > Cheers, Manav > > On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > >> Hi Reshad, >> >> thank you for your comments. Indeed, RFC 7130 is restricted and thus >> hardly applicable to MC-LAG case. We realize that if this proposal is >> adopted it not only enhance applicability on u-BFD but will update RFC 7= 130. >> >> >> >> Regards, >> >> Greg >> >> >> >> *From:* Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >> *Sent:* Friday, April 08, 2016 8:51 AM >> *To:* Manav Bhatia; Gregory Mirsky >> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; >> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; >> rtg-bfd-chairs@ietf.org >> >> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> >> >> I agree with Manav, and nothing in RFC7130 seems to preclude using >> different unicast IP address as destination on different member links. >> >> >> >> Regards, >> >> Reshad (as individual contributor). >> >> >> >> *From: *Rtg-bfd on behalf of Manav Bhatia < >> manavbhatia@gmail.com> >> *Date: *Friday, April 8, 2016 at 11:04 AM >> *To: *Gregory Mirsky >> *Cc: *"draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" < >> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" < >> mpls@ietf.org>, "mpls-chairs@ietf.org" , "Alia >> Atlas (akatlas@gmail.com)" , "rtg-bfd@ietf.org" < >> rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" >> *Subject: *Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> >> >> Hi Greg, >> >> >> >> Why cant different micro-BFD packets use the IP address of the MC-LAG en= d >> points? Ones going to router 1 will all carry the same unicast IP addres= s. >> The ones going towards the other router will all carry some other IP >> address, which would be configured along with the MC-LAG configs. >> >> >> >> In fact i would argue that the u-bfd packets going to different routers >> must use different IP addresses so that you can actually verify the data >> plane liveliness. Whats the point in sending a contrived IP address if t= he >> path that it takes is different from the other regular packets? >> >> >> >> Cheers, Manav >> >> >> >> On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky < >> gregory.mirsky@ericsson.com> wrote: >> >> Hi Manav, >> >> thank you for sharing insight view of discussions around RFC 7130, >> extremely helpful. >> >> We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents >> different case and the compromise that you=E2=80=99ve pointed too is jus= tified. We >> will add more details on the potential differences between unicast and >> multicast fast paths in the next update. >> >> We are open to the discussion and always welcome comments and alternativ= e >> proposals. >> >> >> >> Regards, >> >> Greg >> >> >> >> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] >> *Sent:* Thursday, April 07, 2016 7:39 PM >> *To:* Mach Chen >> *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; >> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org= ; >> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) >> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> >> >> I believe it had to do with multicast datapath (especially link local) >> being different from the unicast datapath in most routers. Using link lo= cal >> multicast IP addresses may not necessarily guarantee Unicast IP >> reachability. >> >> >> >> When writing 7130 we spent quite a bit of time ensuring that we dont >> carve out a special data path for the micro-BFD packets. Using link loca= l >> would have made it a lot simpler. >> >> >> >> And this is where i think the current proposal is flawed -- they use lin= k >> local multicast to ensure IP unicast reachability which is incorrect. >> >> >> >> Cheers, Manav >> >> >> >> On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: >> >> Hi Greg and all, >> >> >> >> I just have quick review on the drafts. If my understanding is correct, >> the idea is to use multicast destination address other than unicast addr= ess >> when sending BFD packets over LAG links. And actually this idea has bee= n >> proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the >> predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 d= id >> discuss the idea of using multicast destination address, but for some >> reason I forget now(I may need to reiterate the discussions on the >> archive), the idea was abandoned, although I still think multicast >> destination address is a smart idea. >> >> >> >> Best regards, >> >> Mach >> ------------------------------ >> >> *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ >> gregory.mirsky@ericsson.com] >> *Sent:* Tuesday, April 05, 2016 6:16 >> *To:* rtg-bfd@ietf.org; mpls@ietf.org >> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; >> rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( >> akatlas@gmail.com) >> *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> Dear All, >> >> two new drafts, related to RFC 7130, were published before the meeting: >> >> =C2=B7 BFD on MC-LAG interfaces in IP network >> >> >> =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network >> >> >> >> >> Greatly appreciate your reviews, comments, questions and suggestions. >> >> >> >> Regards, >> >> Greg >> >> >> >> >> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --94eb2c07bc900c8772052ffdd182 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Manav,
the update could be in addition of either broadcast or link local multicast= or both with appropriate normative language. But I would not agree that th= ese wouldn't work.
Regards, Greg

On Apr 8, 2016 12:34 PM, "Manav Bhatia"= ; <manavbhatia@gmail.com>= ; wrote:
Hi Greg,

Not sure i understand how it can "up= date RFC 7130". Is that by using a link local mcast IP instead of a Un= icast IP?

We know that, that wouldnt work.

Cheers, Manav

On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Reshad,<= /span>

thank you for your commen= ts. Indeed, RFC 7130 is restricted and thus hardly applicable to MC-LAG cas= e. We realize that if this proposal is adopted it not only enhance applicability on u-BFD but will update RFC 7130.

=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=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=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Greg

=C2=A0

From: Reshad R= ahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; <= a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatl= as@gmail.com); rt= g-bfd@ietf.org; rtg-bfd-chairs@ietf.org


Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

I agree with Manav, and not= hing in RFC7130 seems to preclude using different unicast IP address as des= tination on different member links.

=C2=A0=

Regards,

Reshad (as individual contr= ibutor).

=C2=A0=

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on beha= lf of Manav Bhatia <manavbhatia@gmail.com>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<= /a>" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org= >, "mpls@ietf.or= g" <mpls@ietf.org&g= t;, "mpls-ch= airs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com&= gt;, "rtg-bfd@ietf.o= rg" <rtg-= bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0=

Hi Greg,

=C2=A0=

Why cant different micro-BF= D packets use the IP address of the MC-LAG end points? Ones going to router= 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which= would be configured along with the MC-LAG configs.

=C2=A0=

In fact i would argue that = the u-bfd packets going to different routers must use different IP addresse= s so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it take= s is different from the other regular packets?

=C2=A0=

Cheers, Manav=

=C2=A0=

On Fri, Apr 8, 2016 at 6:09= PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

thank you for sharing ins= ight view of discussions around RFC 7130, extremely helpful.

We believe, and Jeff is c= o-author of RFC 7130 too, that MC-LAG presents different case and the compr= omise that you=E2=80=99ve pointed too is justified. We will add more details on = the potential differences between unicast and multicast fast paths in the n= ext update.

We are open to the discus= sion and always welcome comments and alternative proposals.

=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=C2=A0=C2=A0=C2=A0 Regards,=

=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=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=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bhatia [mailto:= manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

I believe it had to do w= ith multicast datapath (especially link local) being different from the uni= cast datapath in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability.=C2=A0<= u>

=C2=A0

When writing 7130 we spe= nt quite a bit of time ensuring that we dont carve out a special data path = for the micro-BFD packets. Using link local would have made it a lot simpler.

=C2=A0

And this is where i thin= k the current proposal is flawed -- they use link local multicast to ensure= IP unicast reachability which is incorrect.

=C2=A0

Cheers, Manav<= /u>

=C2=A0

On Thu, Apr 7, 2016 at 1= 1:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,=

=C2=A0=

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0=

Best regards,=

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces= in IP network

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfac= es in IP/MPLS network

=C2=A0

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0=


Hi Greg,

Not sure i understand how it c= an "update RFC 7130". Is that by using a link local mcast IP inst= ead of a Unicast IP?

We know that, that wouldnt wo= rk.

Cheers, Manav

On Fri, Apr 8, 2016 at 9:44 PM, Gregory= Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Reshad,<= /span>

thank you for your commen= ts. Indeed, RFC 7130 is restricted and thus hardly applicable to MC-LAG cas= e. We realize that if this proposal is adopted it not only enhance applicability on u-BFD but will update RFC 7130.

=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=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=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Greg

=C2=A0

From: Reshad R= ahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; <= a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatl= as@gmail.com); rt= g-bfd@ietf.org; rtg-bfd-chairs@ietf.org


Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

I agree with Manav, and not= hing in RFC7130 seems to preclude using different unicast IP address as des= tination on different member links.

=C2=A0=

Regards,

Reshad (as individual contr= ibutor).

=C2=A0=

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on beha= lf of Manav Bhatia <manavbhatia@gmail.com>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<= /a>" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org= >, "mpls@ietf.or= g" <mpls@ietf.org&g= t;, "mpls-ch= airs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com&= gt;, "rtg-bfd@ietf.o= rg" <rtg-= bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0=

Hi Greg,

=C2=A0=

Why cant different micro-BF= D packets use the IP address of the MC-LAG end points? Ones going to router= 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which= would be configured along with the MC-LAG configs.

=C2=A0=

In fact i would argue that = the u-bfd packets going to different routers must use different IP addresse= s so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it take= s is different from the other regular packets?

=C2=A0=

Cheers, Manav=

=C2=A0=

On Fri, Apr 8, 2016 at 6:09= PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

thank you for sharing ins= ight view of discussions around RFC 7130, extremely helpful.

We believe, and Jeff is c= o-author of RFC 7130 too, that MC-LAG presents different case and the compr= omise that you=E2=80=99ve pointed too is justified. We will add more details on = the potential differences between unicast and multicast fast paths in the n= ext update.

We are open to the discus= sion and always welcome comments and alternative proposals.

=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=C2=A0=C2=A0=C2=A0 Regards,=

=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=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=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bhatia [mailto:= manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

I believe it had to do w= ith multicast datapath (especially link local) being different from the uni= cast datapath in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability.=C2=A0<= u>

=C2=A0

When writing 7130 we spe= nt quite a bit of time ensuring that we dont carve out a special data path = for the micro-BFD packets. Using link local would have made it a lot simpler.

=C2=A0

And this is where i thin= k the current proposal is flawed -- they use link local multicast to ensure= IP unicast reachability which is incorrect.

=C2=A0

Cheers, Manav<= /u>

=C2=A0

On Thu, Apr 7, 2016 at 1= 1:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,=

=C2=A0=

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0=

Best regards,=

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces= in IP network

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfac= es in IP/MPLS network

=C2=A0

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0=



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

--94eb2c07bc900c8772052ffdd182-- From nobody Fri Apr 8 17:37:40 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EBF12D51A; Fri, 8 Apr 2016 17:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 M366FEqMTbGe; Fri, 8 Apr 2016 17:37:33 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 B6B2012D0D3; Fri, 8 Apr 2016 17:37:32 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id i84so147062238ywc.2; Fri, 08 Apr 2016 17:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RBgywSpGwniNNMvCbr1dMjIGNSmf9xAUy9sQAzwaaZI=; b=TczCvw2nA5MwKkRR1Ywn2YH0Nh+a6DvvjtjBaZdiOFIhn07sulAQPsqRy34VmcyD2P 0MZQJcwKKd+MzOyToaYXqcgYia8I+mtk85z1/1/d6tuR4hhH7tTWMcN7AuLgiDsht4y9 1Z5itD427KinalnS3OfLA2JjbRMeLXu5fKXQi1UztQKdcaWwR+g7gpfdjMkmWpxEvz6d 53wVfrKyIArK2epFeVSaK+KZHy0ArO1OKdK91jo8d1oep00ofIhqoq4hRvC9ekykJvMm 2kp9h0e/hoY8w+0qVlXc8ZVjpaIwlmK+SxmPw4iRqLeHiwtG8wlXQN9chW6bCGVgVzpa gCdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RBgywSpGwniNNMvCbr1dMjIGNSmf9xAUy9sQAzwaaZI=; b=YRXHtJZVZ29mXUCgd+fJvOyhkCi9ZB3DpvsemreOGpvztXuxwEbS8uDM5nDIxYTvYZ w9ikvgRzfCqjZj0ds/hsmcBYRYrI35OYngmVXSewBfP5+HVYg82syILGJLzjnZCBhSE3 eFKpajMSCIQJSMphuWnpeCYPts3rjBGnS4P6iIgx/6SP7UjGgA4S6FWUzayux4zDb6Ss FgcsnejajFzNCtj/D2qY1OVFHK0zDpftcfzH0/stCSiTDLBTeIfPN/Ai0URYmGADvcNU GKJeHeVPDjHDtfTqqtLy8ezV0Y0cko2eadmnlYHUOi1ialWyGf6RBYlUrG//rp0HDrrg z5RQ== X-Gm-Message-State: AD7BkJIitaegNfb/cifOzvaGnOnGtrHAG6J+I6cjZkBVP1rZWr3IbSpKCeq881230tfT/PDh8op+hBcRiWzEmQ== MIME-Version: 1.0 X-Received: by 10.129.120.23 with SMTP id t23mr6573759ywc.45.1460162251894; Fri, 08 Apr 2016 17:37:31 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Fri, 8 Apr 2016 17:37:31 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> Date: Sat, 9 Apr 2016 06:07:31 +0530 Message-ID: Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces From: Manav Bhatia To: Greg Mirsky Content-Type: multipart/alternative; boundary=94eb2c0b038c56bdfd0530028470 Archived-At: Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org, "rtg-bfd-chairs@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 00:37:36 -0000 --94eb2c0b038c56bdfd0530028470 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, the update could be in addition of either broadcast or link local multicast > or both with appropriate normative language. But I would not agree that > these wouldn't work. > Double negatives make it very hard to parse a sentence. Anyway, why would you NOT agree that this WOULDNT work? I am telling you that link local multicasts and unicasts are dealt with differently in the data plane, so the data path being up for the former may not necessarily mean that its up for the latter as well. So tell me WHY you think this argument isnt valid? I was the L3 data plane architect in my former company for one of the product lines and i am telling you that in my box, which is very very widely deployed, your scheme will NOT work since i punt all link local packets to the CPU differently. In fact, in some cases even the TX path is different. So sure, u-BFD may very well claim that the link is up, but its possible that there may be no IP connectivity. Cheers, Manav Regards, Greg > On Apr 8, 2016 12:34 PM, "Manav Bhatia" wrote: > >> Hi Greg, >> >> Not sure i understand how it can "update RFC 7130". Is that by using a >> link local mcast IP instead of a Unicast IP? >> >> We know that, that wouldnt work. >> >> Cheers, Manav >> >> On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky < >> gregory.mirsky@ericsson.com> wrote: >> >>> Hi Reshad, >>> >>> thank you for your comments. Indeed, RFC 7130 is restricted and thus >>> hardly applicable to MC-LAG case. We realize that if this proposal is >>> adopted it not only enhance applicability on u-BFD but will update RFC = 7130. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> *From:* Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >>> *Sent:* Friday, April 08, 2016 8:51 AM >>> *To:* Manav Bhatia; Gregory Mirsky >>> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; >>> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; >>> rtg-bfd-chairs@ietf.org >>> >>> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >>> >>> >>> >>> I agree with Manav, and nothing in RFC7130 seems to preclude using >>> different unicast IP address as destination on different member links. >>> >>> >>> >>> Regards, >>> >>> Reshad (as individual contributor). >>> >>> >>> >>> *From: *Rtg-bfd on behalf of Manav Bhatia < >>> manavbhatia@gmail.com> >>> *Date: *Friday, April 8, 2016 at 11:04 AM >>> *To: *Gregory Mirsky >>> *Cc: *"draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" < >>> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" < >>> mpls@ietf.org>, "mpls-chairs@ietf.org" , "Alia >>> Atlas (akatlas@gmail.com)" , "rtg-bfd@ietf.org" < >>> rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" >>> *Subject: *Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >>> >>> >>> >>> Hi Greg, >>> >>> >>> >>> Why cant different micro-BFD packets use the IP address of the MC-LAG >>> end points? Ones going to router 1 will all carry the same unicast IP >>> address. The ones going towards the other router will all carry some ot= her >>> IP address, which would be configured along with the MC-LAG configs. >>> >>> >>> >>> In fact i would argue that the u-bfd packets going to different routers >>> must use different IP addresses so that you can actually verify the dat= a >>> plane liveliness. Whats the point in sending a contrived IP address if = the >>> path that it takes is different from the other regular packets? >>> >>> >>> >>> Cheers, Manav >>> >>> >>> >>> On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky < >>> gregory.mirsky@ericsson.com> wrote: >>> >>> Hi Manav, >>> >>> thank you for sharing insight view of discussions around RFC 7130, >>> extremely helpful. >>> >>> We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents >>> different case and the compromise that you=E2=80=99ve pointed too is ju= stified. We >>> will add more details on the potential differences between unicast and >>> multicast fast paths in the next update. >>> >>> We are open to the discussion and always welcome comments and >>> alternative proposals. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] >>> *Sent:* Thursday, April 07, 2016 7:39 PM >>> *To:* Mach Chen >>> *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; >>> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.or= g; >>> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) >>> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >>> >>> >>> >>> I believe it had to do with multicast datapath (especially link local) >>> being different from the unicast datapath in most routers. Using link l= ocal >>> multicast IP addresses may not necessarily guarantee Unicast IP >>> reachability. >>> >>> >>> >>> When writing 7130 we spent quite a bit of time ensuring that we dont >>> carve out a special data path for the micro-BFD packets. Using link loc= al >>> would have made it a lot simpler. >>> >>> >>> >>> And this is where i think the current proposal is flawed -- they use >>> link local multicast to ensure IP unicast reachability which is incorre= ct. >>> >>> >>> >>> Cheers, Manav >>> >>> >>> >>> On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote= : >>> >>> Hi Greg and all, >>> >>> >>> >>> I just have quick review on the drafts. If my understanding is correct, >>> the idea is to use multicast destination address other than unicast add= ress >>> when sending BFD packets over LAG links. And actually this idea has be= en >>> proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (th= e >>> predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 = did >>> discuss the idea of using multicast destination address, but for some >>> reason I forget now(I may need to reiterate the discussions on the >>> archive), the idea was abandoned, although I still think multicast >>> destination address is a smart idea. >>> >>> >>> >>> Best regards, >>> >>> Mach >>> ------------------------------ >>> >>> *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky = [ >>> gregory.mirsky@ericsson.com] >>> *Sent:* Tuesday, April 05, 2016 6:16 >>> *To:* rtg-bfd@ietf.org; mpls@ietf.org >>> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; >>> rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( >>> akatlas@gmail.com) >>> *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces >>> >>> Dear All, >>> >>> two new drafts, related to RFC 7130, were published before the meeting: >>> >>> =C2=B7 BFD on MC-LAG interfaces in IP network >>> >>> >>> =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network >>> >>> >>> >>> >>> Greatly appreciate your reviews, comments, questions and suggestions. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> --94eb2c0b038c56bdfd0530028470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

the update= could be in addition of either broadcast or link local multicast or both w= ith appropriate normative language. But I would not agree that these wouldn= 't work.


Double negatives make= it very hard to parse a sentence.

Anyway, why wou= ld you NOT agree that this WOULDNT work?

I am tell= ing you that link local multicasts and unicasts are dealt with differently = in the data plane, so the data path being up for the former may not necessa= rily mean that its up for the latter as well. So tell me WHY you think this= argument isnt valid? I was the L3 data plane architect in my former compan= y for one of the product lines and i am telling you that in my box, which i= s very very widely deployed, your scheme will NOT work since i punt all lin= k local packets to the CPU differently. In fact, in some cases even the TX = path is different. So sure, u-BFD may very well claim that the link is up, = but its possible that there may be no IP connectivity.

=
Cheers, Manav

Regards, Greg

On Apr 8, 2016 12:34 PM, = "Manav Bhatia" <manavbhatia@gmail.com> wrote:
<= /div>
Hi Greg,

Not sure i understand how it can "= ;update RFC 7130". Is that by using a link local mcast IP instead of a= Unicast IP?

We know that, that wouldnt work.

Cheers, Manav
On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky = <gregory.mirsky@ericsson.com> wrote:

Hi Reshad,<= /span>

thank you for your commen= ts. Indeed, RFC 7130 is restricted and thus hardly applicable to MC-LAG cas= e. We realize that if this proposal is adopted it not only enhance applicability on u-BFD but will update RFC 7130.

=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=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=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Greg

=C2=A0

From: Reshad R= ahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; <= a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatl= as@gmail.com); rt= g-bfd@ietf.org; rtg-bfd-chairs@ietf.org


Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

I agree with Manav, and not= hing in RFC7130 seems to preclude using different unicast IP address as des= tination on different member links.

=C2=A0=

Regards,

Reshad (as individual contr= ibutor).

=C2=A0=

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on beha= lf of Manav Bhatia <manavbhatia@gmail.com>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<= /a>" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org= >, "mpls@ietf.or= g" <mpls@ietf.org&g= t;, "mpls-ch= airs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com&= gt;, "rtg-bfd@ietf.o= rg" <rtg-= bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0=

Hi Greg,

=C2=A0=

Why cant different micro-BF= D packets use the IP address of the MC-LAG end points? Ones going to router= 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which= would be configured along with the MC-LAG configs.

=C2=A0=

In fact i would argue that = the u-bfd packets going to different routers must use different IP addresse= s so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it take= s is different from the other regular packets?

=C2=A0=

Cheers, Manav=

=C2=A0=

On Fri, Apr 8, 2016 at 6:09= PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

thank you for sharing ins= ight view of discussions around RFC 7130, extremely helpful.

We believe, and Jeff is c= o-author of RFC 7130 too, that MC-LAG presents different case and the compr= omise that you=E2=80=99ve pointed too is justified. We will add more details on = the potential differences between unicast and multicast fast paths in the n= ext update.

We are open to the discus= sion and always welcome comments and alternative proposals.

=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=C2=A0=C2=A0=C2=A0 Regards,=

=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=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=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bhatia [mailto:= manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

I believe it had to do w= ith multicast datapath (especially link local) being different from the uni= cast datapath in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability.=C2=A0<= u>

=C2=A0

When writing 7130 we spe= nt quite a bit of time ensuring that we dont carve out a special data path = for the micro-BFD packets. Using link local would have made it a lot simpler.

=C2=A0

And this is where i thin= k the current proposal is flawed -- they use link local multicast to ensure= IP unicast reachability which is incorrect.

=C2=A0

Cheers, Manav<= /u>

=C2=A0

On Thu, Apr 7, 2016 at 1= 1:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,=

=C2=A0=

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0=

Best regards,=

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces= in IP network

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfac= es in IP/MPLS network

=C2=A0

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0=



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


--94eb2c0b038c56bdfd0530028470-- From nobody Sat Apr 9 02:08:23 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3875712D158; Sat, 9 Apr 2016 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 KNXkhRvEo2Dp; Sat, 9 Apr 2016 02:08:21 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 6660412D13B; Sat, 9 Apr 2016 02:08:21 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id o66so68779002ywc.3; Sat, 09 Apr 2016 02:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PXAMq23NHFZylcScxzEupxlGW+FRWogTJxheaijnOEw=; b=aXEodagEAT415mNdSGV5iOy2Jo+FoN6VWbtqUUpmnC95up7x9xYrNkxjHPwVGPY/Tl h18Gp0aHnDoBvHNlGPXq7YXYFLmU/1mTyFq8xhrZTf8A/il+KmFeVDcceUAI3DgEtQRK wXB3MZ2IKNHQIDUdkE4gUv8DQ36AuIennHpkQwQQxiOdoXjRG7sMF6lQ9BZcLlg0XHY2 DURRj0aZoF3fOUzYoslwNfrhTYm5aPDvoReyDwht+USLhEDcQP3moc2U/YXd6rQlva/a Q043hgscylUnk9kjgqMdIaKlwTJthmA6rdn9/rS0IWy1tpUFtZSwOkxaxJP4l1+9TWFg fbpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PXAMq23NHFZylcScxzEupxlGW+FRWogTJxheaijnOEw=; b=j2SOZ9fED86dHuCZenzsCUrPtAjDINQ+JURYVklQRoJcZMB9jBRvpyYqlaxdAfRlW7 bcifu2tW85wZZ6FUq/oCo2kvdn5jhkPw5q4d0yxfmNhazhGGI1klnrVrLAzm3WQ5fn0J DQOkHXkrQgOlBNa9Q9kL+M9lY2Gw1SMct6EGBNPNsE2b9H3N5zswmhfU0ZJtit5XNq60 qaFmdsZtEHINL/14yuCCPjf9MbFfzoMc2/ISiU+fod5CtsS03lrdE8UxAvJ/tKXblLIR rghRjJCJUbIzEZ8UQxN4RuApVWXdddOpyVcpz/ebnC7BkcDQCaR39+LOzjOm9gmE+UbG N1kg== X-Gm-Message-State: AD7BkJLjqAMNu46oUPnJoUQESGp/v9UuIuFfDAPNXT+gYxL6sDhfcwvFVeq/BuXOaRFymV+3VR9rYzirHZhiUQ== MIME-Version: 1.0 X-Received: by 10.129.70.70 with SMTP id t67mr6357220ywa.6.1460192900595; Sat, 09 Apr 2016 02:08:20 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Sat, 9 Apr 2016 02:08:20 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se> Date: Sat, 9 Apr 2016 14:38:20 +0530 Message-ID: Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a114d71ce24c89b053009a715 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 09:08:23 -0000 --001a114d71ce24c89b053009a715 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, There is a difference, a big one. When you use CFM or some other L2 OAM protocol, you dont make any claims about L3 connectivity. However, when you start using BFD it implicitly means that youre talking about L3 connectivity. So, its going to be bizarre debugging complex topologies where BFD sessions never flap and yet MPLS LSPs randomly time out (because there is this one MC-LAG thats dropping packets -- and in the worst case, only sporadically and intermittently drops IP packets) It will NOT produce false negatives (as you claim) but rather introduce false positives, which is more dangerous. The MC-LAG will be up, while it would be dropping all or few IP packets. I have no objections if operators and the community think that this is something that they can live with. I am personally having an out-of-body experience just discussing this! :-) Cheers, Manav On Sat, Apr 9, 2016 at 9:46 AM, Gregory Mirsky wrote: > Hi Manav, > > the use case for the BFD over MC-LAG interfaces that I consider the most > important for this drafts to address is to enable sub-second defect > detection in order to trigger LACP convergence and, subsequently, > switchover within the Redundancy Group in Active-Standby case. Hence both > unicast and multicast L3 addresses are quite distant from L2 fast path an= d > processing usually taken by CCM frames. Of course, one can use CFM per LA= G > Constituent Link, and I have implemented that and it interoperates with > another implementation by other vendor, but operators prefer ease of BFD > provisioning. Thus I=E2=80=99ve to provide them with ability to monitor M= C-LAG and > explain that in some cases it may produce false negative when L2 is > functional and the problem is in L3, unicast or multicast, engine. As you > can see, there=E2=80=99s not much value in continuing argument how much d= ifferent > L3 multicast processing is from L3 unicast as both are different from L2 > path. At the end, as I think, it is up to operators to decide whether the= y > are comfortable with this mechanism or would require defect detection at = L2. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Friday, April 08, 2016 5:38 PM > *To:* Greg Mirsky > *Cc:* Reshad Rahman (rrahman); > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.org; > mpls-chairs@ietf.org; mpls@ietf.org; rtg-bfd-chairs@ietf.org; Gregory > Mirsky > *Subject:* Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interface= s > > > > Hi Greg, > > > > the update could be in addition of either broadcast or link local > multicast or both with appropriate normative language. But I would not > agree that these wouldn't work. > > > > Double negatives make it very hard to parse a sentence. > > > > Anyway, why would you NOT agree that this WOULDNT work? > > > > I am telling you that link local multicasts and unicasts are dealt with > differently in the data plane, so the data path being up for the former m= ay > not necessarily mean that its up for the latter as well. So tell me WHY y= ou > think this argument isnt valid? I was the L3 data plane architect in my > former company for one of the product lines and i am telling you that in = my > box, which is very very widely deployed, your scheme will NOT work since = i > punt all link local packets to the CPU differently. In fact, in some case= s > even the TX path is different. So sure, u-BFD may very well claim that th= e > link is up, but its possible that there may be no IP connectivity. > > > > Cheers, Manav > > > --001a114d71ce24c89b053009a715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

There is a difference, a big o= ne.=C2=A0

When you use CFM or some other L2 OAM pr= otocol, you dont make any claims about L3 connectivity. However, when you s= tart using BFD it implicitly means that youre talking about L3 connectivity= . So, its going to be bizarre debugging complex topologies where BFD sessio= ns never flap and yet MPLS LSPs randomly time out (because there is this on= e MC-LAG thats dropping packets -- and in the worst case, only sporadically= and intermittently drops IP packets)

It will NOT = produce false negatives (as you claim) but rather introduce false positives= , which is more dangerous. The MC-LAG will be up, while it would be droppin= g all or few IP packets.

I have no objections if o= perators and the community think that this is something that they can live = with. I am personally having an out-of-body experience just discussing this= ! :-)

Cheers, Manav

On Sat, Apr 9, 2016 at 9:46 AM, G= regory Mirsky <gregory.mirsky@ericsson.com> wrote:=

Hi Manav,

the use case for the BFD = over MC-LAG interfaces that I consider the most important for this drafts t= o address is to enable sub-second defect detection in order to trigger LACP convergence and, subsequently, switchover within the Redun= dancy Group in Active-Standby case. Hence both unicast and multicast L3 add= resses are quite distant from L2 fast path and processing usually taken by = CCM frames. Of course, one can use CFM per LAG Constituent Link, and I have implemented that and it interoper= ates with another implementation by other vendor, but operators prefer ease= of BFD provisioning. Thus I=E2=80=99ve to provide them with ability to mon= itor MC-LAG and explain that in some cases it may produce false negative when L2 is functional and the problem is in = L3, unicast or multicast, engine. As you can see, there=E2=80=99s not much = value in continuing argument how much different L3 multicast processing is = from L3 unicast as both are different from L2 path. At the end, as I think, it is up to operators to decide whether t= hey are comfortable with this mechanism or would require defect detection a= t L2.

=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=C2=A0=C2=A0=C2=A0 Regards,=

=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=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=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bh= atia [mailto:man= avbhatia@gmail.com]
Sent: Friday, April 08, 2016 5:38 PM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman); draft-tanmir-rtgwg-bfd-mc-lag= -ip@tools.ietf.org; rtg-bfd@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org; rtg-bfd-chairs@ietf.org; Gregory Mirsky
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interf= aces

=C2=A0

Hi Greg,

=C2=A0

the update could be in addition of either broadcast or link local multic= ast or both with appropriate normative language. But I would not agree that= these wouldn't work.

=C2=A0

Double negatives make it very hard to parse a senten= ce.

=C2=A0

Anyway, why would you NOT agree that this WOULDNT wo= rk?

=C2=A0

I am telling you that link local multicasts and unic= asts are dealt with differently in the data plane, so the data path being u= p for the former may not necessarily mean that its up for the latter as wel= l. So tell me WHY you think this argument isnt valid? I was the L3 data plane architect in my former company for one= of the product lines and i am telling you that in my box, which is very ve= ry widely deployed, your scheme will NOT work since i punt all link local p= ackets to the CPU differently. In fact, in some cases even the TX path is different. So sure, u-BFD may very= well claim that the link is up, but its possible that there may be no IP c= onnectivity.

=C2=A0

Cheers, Manav

=C2=A0

--001a114d71ce24c89b053009a715-- From nobody Sat Apr 9 02:56:25 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270312D62B; Fri, 8 Apr 2016 21:16:29 -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 qGCQZwLGqU1W; Fri, 8 Apr 2016 21:16:26 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE8112D5B8; Fri, 8 Apr 2016 21:16:25 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-f4-57087bc4440c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id AB.6D.30335.4CB78075; Sat, 9 Apr 2016 05:49:24 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Sat, 9 Apr 2016 00:16:24 -0400 From: Gregory Mirsky To: Manav Bhatia , Greg Mirsky Subject: RE: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAGbkoAAB59e4P//39qAgAAYVICAAF4BgIAACP5Q Date: Sat, 9 Apr 2016 04:16:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A40D56eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyuXRPrO6Rao5wg6/fTSwObDrIaPFt2lNW i8uT2tgt1l0+xWZxa+lKVotrK1rZLT7/2cbowO4x5fdGVo+ds+6yeyxZ8pPJ48vlz2wBLFFc NimpOZllqUX6dglcGT27L7AVNC1nrri8+jVLA2PDHOYuRk4OCQETiVvvzzFC2GISF+6tZ+ti 5OIQEjjKKLHuyDkWCGcZo8THz20sIFVsAkYSLzb2sHcxcnCICPhKLDiqDlLDLDCVSeLyylWs IDXCAh4StxdMALNFBDwlNr86ywpRnyexb309SJhFQEXi+JEDbCA2L9CY7i2HoHatYpX49G0J E0iCUyBQ4uPzp2BzGIGu+35qDVicWUBc4taT+UwQVwtILNlzHuobUYmXj/+xQthKEh9/z2eH qM+XWHGlkRFimaDEyZlPWCYwis5CMmoWkrJZSMpmAZ3NLKApsX6XPkSJosSU7ofsELaGROuc uezI4gsY2VcxcpQWF+TkphsZbGIExucxCTbdHYz3p3seYhTgYFTi4VVI4ggXYk0sK67MPcQo wcGsJMK7oAIoxJuSWFmVWpQfX1Sak1p8iFGag0VJnLcx+F+YkEB6YklqdmpqQWoRTJaJg1Oq gVFwa83Z5Y9sFum1zp72a7dNP9vuvJfNRskZ/Rve9eh+6viWZMiqNHl78zWxMq4vHGpHco+c qrruq8sokvluYxFv3FWrz0tsPzZNV9Ld/XinrNK8w7JZS987s9lMt6rwsIiIMzR4pOX2KICD mf9gfcTRFkt77uWKesoSz9g2safx5ZzczXPjlRJLcUaioRZzUXEiAC1P3PfLAgAA Archived-At: X-Mailman-Approved-At: Sat, 09 Apr 2016 02:56:23 -0700 Cc: "Reshad Rahman \(rrahman\)" , "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 04:16:29 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A40D56eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQp0aGUgdXNlIGNhc2UgZm9yIHRoZSBCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNl cyB0aGF0IEkgY29uc2lkZXIgdGhlIG1vc3QgaW1wb3J0YW50IGZvciB0aGlzIGRyYWZ0cyB0byBh ZGRyZXNzIGlzIHRvIGVuYWJsZSBzdWItc2Vjb25kIGRlZmVjdCBkZXRlY3Rpb24gaW4gb3JkZXIg dG8gdHJpZ2dlciBMQUNQIGNvbnZlcmdlbmNlIGFuZCwgc3Vic2VxdWVudGx5LCBzd2l0Y2hvdmVy IHdpdGhpbiB0aGUgUmVkdW5kYW5jeSBHcm91cCBpbiBBY3RpdmUtU3RhbmRieSBjYXNlLiBIZW5j ZSBib3RoIHVuaWNhc3QgYW5kIG11bHRpY2FzdCBMMyBhZGRyZXNzZXMgYXJlIHF1aXRlIGRpc3Rh bnQgZnJvbSBMMiBmYXN0IHBhdGggYW5kIHByb2Nlc3NpbmcgdXN1YWxseSB0YWtlbiBieSBDQ00g ZnJhbWVzLiBPZiBjb3Vyc2UsIG9uZSBjYW4gdXNlIENGTSBwZXIgTEFHIENvbnN0aXR1ZW50IExp bmssIGFuZCBJIGhhdmUgaW1wbGVtZW50ZWQgdGhhdCBhbmQgaXQgaW50ZXJvcGVyYXRlcyB3aXRo IGFub3RoZXIgaW1wbGVtZW50YXRpb24gYnkgb3RoZXIgdmVuZG9yLCBidXQgb3BlcmF0b3JzIHBy ZWZlciBlYXNlIG9mIEJGRCBwcm92aXNpb25pbmcuIFRodXMgSeKAmXZlIHRvIHByb3ZpZGUgdGhl bSB3aXRoIGFiaWxpdHkgdG8gbW9uaXRvciBNQy1MQUcgYW5kIGV4cGxhaW4gdGhhdCBpbiBzb21l IGNhc2VzIGl0IG1heSBwcm9kdWNlIGZhbHNlIG5lZ2F0aXZlIHdoZW4gTDIgaXMgZnVuY3Rpb25h bCBhbmQgdGhlIHByb2JsZW0gaXMgaW4gTDMsIHVuaWNhc3Qgb3IgbXVsdGljYXN0LCBlbmdpbmUu IEFzIHlvdSBjYW4gc2VlLCB0aGVyZeKAmXMgbm90IG11Y2ggdmFsdWUgaW4gY29udGludWluZyBh cmd1bWVudCBob3cgbXVjaCBkaWZmZXJlbnQgTDMgbXVsdGljYXN0IHByb2Nlc3NpbmcgaXMgZnJv bSBMMyB1bmljYXN0IGFzIGJvdGggYXJlIGRpZmZlcmVudCBmcm9tIEwyIHBhdGguIEF0IHRoZSBl bmQsIGFzIEkgdGhpbmssIGl0IGlzIHVwIHRvIG9wZXJhdG9ycyB0byBkZWNpZGUgd2hldGhlciB0 aGV5IGFyZSBjb21mb3J0YWJsZSB3aXRoIHRoaXMgbWVjaGFuaXNtIG9yIHdvdWxkIHJlcXVpcmUg ZGVmZWN0IGRldGVjdGlvbiBhdCBMMi4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFuYXYgQmhhdGlhIFtt YWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAx NiA1OjM4IFBNDQpUbzogR3JlZyBNaXJza3kNCkNjOiBSZXNoYWQgUmFobWFuIChycmFobWFuKTsg ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1iZmRA aWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBydGctYmZkLWNo YWlyc0BpZXRmLm9yZzsgR3JlZ29yeSBNaXJza3kNClN1YmplY3Q6IFJlOiBbbXBsc10gVHdvIG5l dyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNlcw0KDQpIaSBHcmVn LA0KDQoNCnRoZSB1cGRhdGUgY291bGQgYmUgaW4gYWRkaXRpb24gb2YgZWl0aGVyIGJyb2FkY2Fz dCBvciBsaW5rIGxvY2FsIG11bHRpY2FzdCBvciBib3RoIHdpdGggYXBwcm9wcmlhdGUgbm9ybWF0 aXZlIGxhbmd1YWdlLiBCdXQgSSB3b3VsZCBub3QgYWdyZWUgdGhhdCB0aGVzZSB3b3VsZG4ndCB3 b3JrLg0KDQpEb3VibGUgbmVnYXRpdmVzIG1ha2UgaXQgdmVyeSBoYXJkIHRvIHBhcnNlIGEgc2Vu dGVuY2UuDQoNCkFueXdheSwgd2h5IHdvdWxkIHlvdSBOT1QgYWdyZWUgdGhhdCB0aGlzIFdPVUxE TlQgd29yaz8NCg0KSSBhbSB0ZWxsaW5nIHlvdSB0aGF0IGxpbmsgbG9jYWwgbXVsdGljYXN0cyBh bmQgdW5pY2FzdHMgYXJlIGRlYWx0IHdpdGggZGlmZmVyZW50bHkgaW4gdGhlIGRhdGEgcGxhbmUs IHNvIHRoZSBkYXRhIHBhdGggYmVpbmcgdXAgZm9yIHRoZSBmb3JtZXIgbWF5IG5vdCBuZWNlc3Nh cmlseSBtZWFuIHRoYXQgaXRzIHVwIGZvciB0aGUgbGF0dGVyIGFzIHdlbGwuIFNvIHRlbGwgbWUg V0hZIHlvdSB0aGluayB0aGlzIGFyZ3VtZW50IGlzbnQgdmFsaWQ/IEkgd2FzIHRoZSBMMyBkYXRh IHBsYW5lIGFyY2hpdGVjdCBpbiBteSBmb3JtZXIgY29tcGFueSBmb3Igb25lIG9mIHRoZSBwcm9k dWN0IGxpbmVzIGFuZCBpIGFtIHRlbGxpbmcgeW91IHRoYXQgaW4gbXkgYm94LCB3aGljaCBpcyB2 ZXJ5IHZlcnkgd2lkZWx5IGRlcGxveWVkLCB5b3VyIHNjaGVtZSB3aWxsIE5PVCB3b3JrIHNpbmNl IGkgcHVudCBhbGwgbGluayBsb2NhbCBwYWNrZXRzIHRvIHRoZSBDUFUgZGlmZmVyZW50bHkuIElu IGZhY3QsIGluIHNvbWUgY2FzZXMgZXZlbiB0aGUgVFggcGF0aCBpcyBkaWZmZXJlbnQuIFNvIHN1 cmUsIHUtQkZEIG1heSB2ZXJ5IHdlbGwgY2xhaW0gdGhhdCB0aGUgbGluayBpcyB1cCwgYnV0IGl0 cyBwb3NzaWJsZSB0aGF0IHRoZXJlIG1heSBiZSBubyBJUCBjb25uZWN0aXZpdHkuDQoNCkNoZWVy cywgTWFuYXYNCg0KDQpSZWdhcmRzLCBHcmVnDQpPbiBBcHIgOCwgMjAxNiAxMjozNCBQTSwgIk1h bmF2IEJoYXRpYSIgPG1hbmF2YmhhdGlhQGdtYWlsLmNvbTxtYWlsdG86bWFuYXZiaGF0aWFAZ21h aWwuY29tPj4gd3JvdGU6DQpIaSBHcmVnLA0KDQpOb3Qgc3VyZSBpIHVuZGVyc3RhbmQgaG93IGl0 IGNhbiAidXBkYXRlIFJGQyA3MTMwIi4gSXMgdGhhdCBieSB1c2luZyBhIGxpbmsgbG9jYWwgbWNh c3QgSVAgaW5zdGVhZCBvZiBhIFVuaWNhc3QgSVA/DQoNCldlIGtub3cgdGhhdCwgdGhhdCB3b3Vs ZG50IHdvcmsuDQoNCkNoZWVycywgTWFuYXYNCg0KT24gRnJpLCBBcHIgOCwgMjAxNiBhdCA5OjQ0 IFBNLCBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpn cmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpIFJlc2hhZCwNCnRoYW5rIHlv dSBmb3IgeW91ciBjb21tZW50cy4gSW5kZWVkLCBSRkMgNzEzMCBpcyByZXN0cmljdGVkIGFuZCB0 aHVzIGhhcmRseSBhcHBsaWNhYmxlIHRvIE1DLUxBRyBjYXNlLiBXZSByZWFsaXplIHRoYXQgaWYg dGhpcyBwcm9wb3NhbCBpcyBhZG9wdGVkIGl0IG5vdCBvbmx5IGVuaGFuY2UgYXBwbGljYWJpbGl0 eSBvbiB1LUJGRCBidXQgd2lsbCB1cGRhdGUgUkZDIDcxMzAuDQoNClJlZ2FyZHMsDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogUmVzaGFkIFJhaG1hbiAocnJh aG1hbikgW21haWx0bzpycmFobWFuQGNpc2NvLmNvbTxtYWlsdG86cnJhaG1hbkBjaXNjby5jb20+ XQ0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiA4OjUxIEFNDQpUbzogTWFuYXYgQmhhdGlh OyBHcmVnb3J5IE1pcnNreQ0KQ2M6IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRv b2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29s cy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNo YWlyc0BpZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAaWV0Zi5vcmc+OyBBbGlhIEF0bGFzIChh a2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+KTsgcnRnLWJmZEBpZXRm Lm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz47IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPG1h aWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFR3byBuZXcgZHJh ZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXMNCg0KSSBhZ3JlZSB3aXRo IE1hbmF2LCBhbmQgbm90aGluZyBpbiBSRkM3MTMwIHNlZW1zIHRvIHByZWNsdWRlIHVzaW5nIGRp ZmZlcmVudCB1bmljYXN0IElQIGFkZHJlc3MgYXMgZGVzdGluYXRpb24gb24gZGlmZmVyZW50IG1l bWJlciBsaW5rcy4NCg0KUmVnYXJkcywNClJlc2hhZCAoYXMgaW5kaXZpZHVhbCBjb250cmlidXRv cikuDQoNCkZyb206IFJ0Zy1iZmQgPHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRn LWJmZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1hbmF2IEJoYXRpYSA8bWFuYXZi aGF0aWFAZ21haWwuY29tPG1haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb20+Pg0KRGF0ZTogRnJp ZGF5LCBBcHJpbCA4LCAyMDE2IGF0IDExOjA0IEFNDQpUbzogR3JlZ29yeSBNaXJza3kgPGdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29t Pj4NCkNjOiAiZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPiIg PGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZz4+LCAibXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPj4sICJtcGxzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAaWV0 Zi5vcmc+IiA8bXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3Jn Pj4sICJBbGlhIEF0bGFzIChha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5j b20+KSIgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+LCAicnRn LWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4iIDxydGctYmZkQGlldGYub3Jn PG1haWx0bzpydGctYmZkQGlldGYub3JnPj4sICJydGctYmZkLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc+IiA8cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8bWFp bHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBUd28gbmV3IGRyYWZ0 cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxBRyBpbnRlcmZhY2VzDQoNCkhpIEdyZWcsDQoNCldo eSBjYW50IGRpZmZlcmVudCBtaWNyby1CRkQgcGFja2V0cyB1c2UgdGhlIElQIGFkZHJlc3Mgb2Yg dGhlIE1DLUxBRyBlbmQgcG9pbnRzPyBPbmVzIGdvaW5nIHRvIHJvdXRlciAxIHdpbGwgYWxsIGNh cnJ5IHRoZSBzYW1lIHVuaWNhc3QgSVAgYWRkcmVzcy4gVGhlIG9uZXMgZ29pbmcgdG93YXJkcyB0 aGUgb3RoZXIgcm91dGVyIHdpbGwgYWxsIGNhcnJ5IHNvbWUgb3RoZXIgSVAgYWRkcmVzcywgd2hp Y2ggd291bGQgYmUgY29uZmlndXJlZCBhbG9uZyB3aXRoIHRoZSBNQy1MQUcgY29uZmlncy4NCg0K SW4gZmFjdCBpIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHUtYmZkIHBhY2tldHMgZ29pbmcgdG8gZGlm ZmVyZW50IHJvdXRlcnMgbXVzdCB1c2UgZGlmZmVyZW50IElQIGFkZHJlc3NlcyBzbyB0aGF0IHlv dSBjYW4gYWN0dWFsbHkgdmVyaWZ5IHRoZSBkYXRhIHBsYW5lIGxpdmVsaW5lc3MuIFdoYXRzIHRo ZSBwb2ludCBpbiBzZW5kaW5nIGEgY29udHJpdmVkIElQIGFkZHJlc3MgaWYgdGhlIHBhdGggdGhh dCBpdCB0YWtlcyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgb3RoZXIgcmVndWxhciBwYWNrZXRzPw0K DQpDaGVlcnMsIE1hbmF2DQoNCk9uIEZyaSwgQXByIDgsIDIwMTYgYXQgNjowOSBQTSwgR3JlZ29y eSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJz a3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBNYW5hdiwNCnRoYW5rIHlvdSBmb3Igc2hhcmlu ZyBpbnNpZ2h0IHZpZXcgb2YgZGlzY3Vzc2lvbnMgYXJvdW5kIFJGQyA3MTMwLCBleHRyZW1lbHkg aGVscGZ1bC4NCldlIGJlbGlldmUsIGFuZCBKZWZmIGlzIGNvLWF1dGhvciBvZiBSRkMgNzEzMCB0 b28sIHRoYXQgTUMtTEFHIHByZXNlbnRzIGRpZmZlcmVudCBjYXNlIGFuZCB0aGUgY29tcHJvbWlz ZSB0aGF0IHlvdeKAmXZlIHBvaW50ZWQgdG9vIGlzIGp1c3RpZmllZC4gV2Ugd2lsbCBhZGQgbW9y ZSBkZXRhaWxzIG9uIHRoZSBwb3RlbnRpYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiB1bmljYXN0IGFu ZCBtdWx0aWNhc3QgZmFzdCBwYXRocyBpbiB0aGUgbmV4dCB1cGRhdGUuDQpXZSBhcmUgb3BlbiB0 byB0aGUgZGlzY3Vzc2lvbiBhbmQgYWx3YXlzIHdlbGNvbWUgY29tbWVudHMgYW5kIGFsdGVybmF0 aXZlIHByb3Bvc2Fscy4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFuYXYgQmhhdGlhIFttYWlsdG86bWFu YXZiaGF0aWFAZ21haWwuY29tPG1haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb20+XQ0KU2VudDog VGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDc6MzkgUE0NClRvOiBNYWNoIENoZW4NCkNjOiBHcmVn b3J5IE1pcnNreTsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz47IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBkcmFmdC10YW5taXItcnRnd2ctYmZk LW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1t Yy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc+OyBydGctYmZkLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86 cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bXBs cy1jaGFpcnNAaWV0Zi5vcmc+OyBBbGlhIEF0bGFzIChha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86 YWthdGxhc0BnbWFpbC5jb20+KQ0KU3ViamVjdDogUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNy by0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXMNCg0KSSBiZWxpZXZlIGl0IGhhZCB0byBkbyB3 aXRoIG11bHRpY2FzdCBkYXRhcGF0aCAoZXNwZWNpYWxseSBsaW5rIGxvY2FsKSBiZWluZyBkaWZm ZXJlbnQgZnJvbSB0aGUgdW5pY2FzdCBkYXRhcGF0aCBpbiBtb3N0IHJvdXRlcnMuIFVzaW5nIGxp bmsgbG9jYWwgbXVsdGljYXN0IElQIGFkZHJlc3NlcyBtYXkgbm90IG5lY2Vzc2FyaWx5IGd1YXJh bnRlZSBVbmljYXN0IElQIHJlYWNoYWJpbGl0eS4NCg0KV2hlbiB3cml0aW5nIDcxMzAgd2Ugc3Bl bnQgcXVpdGUgYSBiaXQgb2YgdGltZSBlbnN1cmluZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0IGEg c3BlY2lhbCBkYXRhIHBhdGggZm9yIHRoZSBtaWNyby1CRkQgcGFja2V0cy4gVXNpbmcgbGluayBs b2NhbCB3b3VsZCBoYXZlIG1hZGUgaXQgYSBsb3Qgc2ltcGxlci4NCg0KQW5kIHRoaXMgaXMgd2hl cmUgaSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBmbGF3ZWQgLS0gdGhleSB1c2UgbGlu ayBsb2NhbCBtdWx0aWNhc3QgdG8gZW5zdXJlIElQIHVuaWNhc3QgcmVhY2hhYmlsaXR5IHdoaWNo IGlzIGluY29ycmVjdC4NCg0KQ2hlZXJzLCBNYW5hdg0KDQpPbiBUaHUsIEFwciA3LCAyMDE2IGF0 IDExOjE2IFBNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNo ZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIaSBHcmVnIGFuZCBhbGwsDQoNCg0KDQpJIGp1c3Qg aGF2ZSBxdWljayByZXZpZXcgb24gdGhlIGRyYWZ0cy4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBj b3JyZWN0LCB0aGUgaWRlYSBpcyB0byB1c2UgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mg b3RoZXIgdGhhbiB1bmljYXN0IGFkZHJlc3Mgd2hlbiAgc2VuZGluZyBCRkQgcGFja2V0cyBvdmVy IExBRyBsaW5rcy4gQW5kIGFjdHVhbGx5IHRoaXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwICh0 aGUgcHJlZGVjZXNzb3Igb2YgUkZDIDcxMzApLiBBbmQgYXQgdGhhdCB0aW1lLCB0aGUgY28tYXV0 aG9ycyBvZiBSRkMgNzEzMCBkaWQgZGlzY3VzcyB0aGUgaWRlYSBvZiB1c2luZyBtdWx0aWNhc3Qg ZGVzdGluYXRpb24gYWRkcmVzcywgYnV0IGZvciBzb21lIHJlYXNvbiBJIGZvcmdldCBub3coSSBt YXkgbmVlZCB0byByZWl0ZXJhdGUgdGhlIGRpc2N1c3Npb25zIG9uIHRoZSBhcmNoaXZlKSwgdGhl IGlkZWEgd2FzIGFiYW5kb25lZCwgYWx0aG91Z2ggSSBzdGlsbCB0aGluayBtdWx0aWNhc3QgZGVz dGluYXRpb24gYWRkcmVzcyBpcyBhIHNtYXJ0IGlkZWEuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoN Ck1hY2gNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJ0Zy1iZmQg W3J0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3Jn Pl0gb24gYmVoYWxmIG9mIEdyZWdvcnkgTWlyc2t5IFtncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBB cHJpbCAwNSwgMjAxNiA2OjE2DQpUbzogcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBp ZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpDYzogZHJhZnQt dGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXRh bm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPjsgcnRnLWJmZC1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnPjsgQWxpYSBBdGxhcyAoYWthdGxhc0Bn bWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPikNClN1YmplY3Q6IFR3byBuZXcgZHJh ZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXMNCkRlYXIgQWxsLA0KdHdv IG5ldyBkcmFmdHMsIHJlbGF0ZWQgdG8gUkZDIDcxMzAsIHdlcmUgcHVibGlzaGVkIGJlZm9yZSB0 aGUgbWVldGluZzoNCg0KwrcgICAgICAgICBCRkQgb24gTUMtTEFHIGludGVyZmFjZXMgaW4gSVAg bmV0d29yazxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJm ZC1tYy1sYWctaXAtMDA+DQoNCsK3ICAgICAgICAgQkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGlu IElQL01QTFMgbmV0d29yazxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFubWly LXJ0Z3dnLWJmZC1tYy1sYWctbXBscy0wMD4NCg0KR3JlYXRseSBhcHByZWNpYXRlIHlvdXIgcmV2 aWV3cywgY29tbWVudHMsIHF1ZXN0aW9ucyBhbmQgc3VnZ2VzdGlvbnMuDQoNClJlZ2FyZHMsDQog ICAgICAgIEdyZWcNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoN Cg== --_000_7347100B5761DC41A166AC17F22DF11221A40D56eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj50aGUgdXNlIGNhc2UgZm9yIHRoZSBCRkQgb3ZlciBNQy1MQUcg aW50ZXJmYWNlcyB0aGF0IEkgY29uc2lkZXIgdGhlIG1vc3QgaW1wb3J0YW50IGZvciB0aGlzIGRy YWZ0cyB0byBhZGRyZXNzIGlzIHRvIGVuYWJsZSBzdWItc2Vjb25kIGRlZmVjdCBkZXRlY3Rpb24g aW4gb3JkZXINCiB0byB0cmlnZ2VyIExBQ1AgY29udmVyZ2VuY2UgYW5kLCBzdWJzZXF1ZW50bHks IHN3aXRjaG92ZXIgd2l0aGluIHRoZSBSZWR1bmRhbmN5IEdyb3VwIGluIEFjdGl2ZS1TdGFuZGJ5 IGNhc2UuIEhlbmNlIGJvdGggdW5pY2FzdCBhbmQgbXVsdGljYXN0IEwzIGFkZHJlc3NlcyBhcmUg cXVpdGUgZGlzdGFudCBmcm9tIEwyIGZhc3QgcGF0aCBhbmQgcHJvY2Vzc2luZyB1c3VhbGx5IHRh a2VuIGJ5IENDTSBmcmFtZXMuIE9mIGNvdXJzZSwgb25lIGNhbiB1c2UNCiBDRk0gcGVyIExBRyBD b25zdGl0dWVudCBMaW5rLCBhbmQgSSBoYXZlIGltcGxlbWVudGVkIHRoYXQgYW5kIGl0IGludGVy b3BlcmF0ZXMgd2l0aCBhbm90aGVyIGltcGxlbWVudGF0aW9uIGJ5IG90aGVyIHZlbmRvciwgYnV0 IG9wZXJhdG9ycyBwcmVmZXIgZWFzZSBvZiBCRkQgcHJvdmlzaW9uaW5nLiBUaHVzIEnigJl2ZSB0 byBwcm92aWRlIHRoZW0gd2l0aCBhYmlsaXR5IHRvIG1vbml0b3IgTUMtTEFHIGFuZCBleHBsYWlu IHRoYXQgaW4gc29tZSBjYXNlcw0KIGl0IG1heSBwcm9kdWNlIGZhbHNlIG5lZ2F0aXZlIHdoZW4g TDIgaXMgZnVuY3Rpb25hbCBhbmQgdGhlIHByb2JsZW0gaXMgaW4gTDMsIHVuaWNhc3Qgb3IgbXVs dGljYXN0LCBlbmdpbmUuIEFzIHlvdSBjYW4gc2VlLCB0aGVyZeKAmXMgbm90IG11Y2ggdmFsdWUg aW4gY29udGludWluZyBhcmd1bWVudCBob3cgbXVjaCBkaWZmZXJlbnQgTDMgbXVsdGljYXN0IHBy b2Nlc3NpbmcgaXMgZnJvbSBMMyB1bmljYXN0IGFzIGJvdGggYXJlIGRpZmZlcmVudCBmcm9tDQog TDIgcGF0aC4gQXQgdGhlIGVuZCwgYXMgSSB0aGluaywgaXQgaXMgdXAgdG8gb3BlcmF0b3JzIHRv IGRlY2lkZSB3aGV0aGVyIHRoZXkgYXJlIGNvbWZvcnRhYmxlIHdpdGggdGhpcyBtZWNoYW5pc20g b3Igd291bGQgcmVxdWlyZSBkZWZlY3QgZGV0ZWN0aW9uIGF0IEwyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBNYW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiA1OjM4IFBNPGJy Pg0KPGI+VG86PC9iPiBHcmVnIE1pcnNreTxicj4NCjxiPkNjOjwvYj4gUmVzaGFkIFJhaG1hbiAo cnJhaG1hbik7IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3Jn OyBydGctYmZkQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsg cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc7IEdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbbXBsc10gVHdvIG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcg aW50ZXJmYWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEdyZWcs PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwPnRoZSB1cGRh dGUgY291bGQgYmUgaW4gYWRkaXRpb24gb2YgZWl0aGVyIGJyb2FkY2FzdCBvciBsaW5rIGxvY2Fs IG11bHRpY2FzdCBvciBib3RoIHdpdGggYXBwcm9wcmlhdGUgbm9ybWF0aXZlIGxhbmd1YWdlLiBC dXQgSSB3b3VsZCBub3QgYWdyZWUgdGhhdCB0aGVzZSB3b3VsZG4ndCB3b3JrLg0KPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb3Vi bGUgbmVnYXRpdmVzIG1ha2UgaXQgdmVyeSBoYXJkIHRvIHBhcnNlIGEgc2VudGVuY2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueXdheSwg d2h5IHdvdWxkIHlvdSBOT1QgYWdyZWUgdGhhdCB0aGlzIFdPVUxETlQgd29yaz88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSB0ZWxsaW5n IHlvdSB0aGF0IGxpbmsgbG9jYWwgbXVsdGljYXN0cyBhbmQgdW5pY2FzdHMgYXJlIGRlYWx0IHdp dGggZGlmZmVyZW50bHkgaW4gdGhlIGRhdGEgcGxhbmUsIHNvIHRoZSBkYXRhIHBhdGggYmVpbmcg dXAgZm9yIHRoZSBmb3JtZXIgbWF5IG5vdCBuZWNlc3NhcmlseSBtZWFuIHRoYXQgaXRzIHVwIGZv ciB0aGUgbGF0dGVyIGFzIHdlbGwuIFNvIHRlbGwgbWUgV0hZIHlvdSB0aGluayB0aGlzIGFyZ3Vt ZW50DQogaXNudCB2YWxpZD8gSSB3YXMgdGhlIEwzIGRhdGEgcGxhbmUgYXJjaGl0ZWN0IGluIG15 IGZvcm1lciBjb21wYW55IGZvciBvbmUgb2YgdGhlIHByb2R1Y3QgbGluZXMgYW5kIGkgYW0gdGVs bGluZyB5b3UgdGhhdCBpbiBteSBib3gsIHdoaWNoIGlzIHZlcnkgdmVyeSB3aWRlbHkgZGVwbG95 ZWQsIHlvdXIgc2NoZW1lIHdpbGwgTk9UIHdvcmsgc2luY2UgaSBwdW50IGFsbCBsaW5rIGxvY2Fs IHBhY2tldHMgdG8gdGhlIENQVSBkaWZmZXJlbnRseS4gSW4NCiBmYWN0LCBpbiBzb21lIGNhc2Vz IGV2ZW4gdGhlIFRYIHBhdGggaXMgZGlmZmVyZW50LiBTbyBzdXJlLCB1LUJGRCBtYXkgdmVyeSB3 ZWxsIGNsYWltIHRoYXQgdGhlIGxpbmsgaXMgdXAsIGJ1dCBpdHMgcG9zc2libGUgdGhhdCB0aGVy ZSBtYXkgYmUgbm8gSVAgY29ubmVjdGl2aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsIE1hbmF2PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwPlJlZ2FyZHMsIEdyZWcgPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgOCwgMjAxNiAx MjozNCBQTSwgJnF1b3Q7TWFuYXYgQmhhdGlhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWFu YXZiaGF0aWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFuYXZiaGF0aWFAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEdyZWcsPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Qgc3VyZSBpIHVu ZGVyc3RhbmQgaG93IGl0IGNhbiAmcXVvdDt1cGRhdGUgUkZDIDcxMzAmcXVvdDsuIElzIHRoYXQg YnkgdXNpbmcgYSBsaW5rIGxvY2FsIG1jYXN0IElQIGluc3RlYWQgb2YgYSBVbmljYXN0IElQPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBr bm93IHRoYXQsIHRoYXQgd291bGRudCB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsIE1hbmF2PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgOCwgMjAxNiBh dCA5OjQ0IFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29u LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSBSZXNoYWQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhhbmsgeW91IGZv ciB5b3VyIGNvbW1lbnRzLiBJbmRlZWQsIFJGQyA3MTMwIGlzIHJlc3RyaWN0ZWQgYW5kIHRodXMg aGFyZGx5IGFwcGxpY2FibGUgdG8gTUMtTEFHDQogY2FzZS4gV2UgcmVhbGl6ZSB0aGF0IGlmIHRo aXMgcHJvcG9zYWwgaXMgYWRvcHRlZCBpdCBub3Qgb25seSBlbmhhbmNlIGFwcGxpY2FiaWxpdHkg b24gdS1CRkQgYnV0IHdpbGwgdXBkYXRlIFJGQyA3MTMwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWluZGVudDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSZXNoYWQgUmFobWFuIChycmFobWFu KSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpycmFobWFuQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnJyYWhtYW5AY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFw cmlsIDA4LCAyMDE2IDg6NTEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hbmF2IEJoYXRpYTsgR3JlZ29y eSBNaXJza3k8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkcmFmdC10YW5taXItcnRn d2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQt dGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBsc0BpZXRmLm9yZzwvYT47 IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1w bHMtY2hhaXJzQGlldGYub3JnPC9hPjsgQWxpYSBBdGxhcyAoPGEgaHJlZj0ibWFpbHRvOmFrYXRs YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWthdGxhc0BnbWFpbC5jb208L2E+KTsNCjxh IGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPg0KcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGlu dGVyZmFjZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgYWdyZWUgd2l0aCBNYW5hdiwgYW5kIG5v dGhpbmcgaW4gUkZDNzEzMCBzZWVtcyB0byBwcmVjbHVkZSB1c2luZyBkaWZmZXJlbnQgdW5pY2Fz dCBJUCBhZGRyZXNzIGFzDQogZGVzdGluYXRpb24gb24gZGlmZmVyZW50IG1lbWJlciBsaW5rcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5S ZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZXNo YWQgKGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3IpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJ0Zy1iZmQgJmx0OzxhIGhy ZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGct YmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgTWFuYXYgQmhhdGlhICZs dDs8YSBocmVmPSJtYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bWFuYXZiaGF0aWFAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBB cHJpbCA4LCAyMDE2IGF0IDExOjA0IEFNPGJyPg0KPGI+VG86IDwvYj5HcmVnb3J5IE1pcnNreSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBA dG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC10YW5taXItcnRnd2ctYmZkLW1j LWxhZy1pcEB0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFm dC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPC9hPiZn dDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5tcGxzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtY2hhaXJz QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVv dDtBbGlhIEF0bGFzICg8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWJm ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+Jmd0OywNCiAm cXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5ydGctYmZkLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpydGctYmZkLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1iZmQtY2hhaXJz QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFR3byBuZXcgZHJhZnRz IG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgR3JlZywNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPldoeSBjYW50IGRpZmZlcmVudCBtaWNyby1CRkQgcGFja2V0 cyB1c2UgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIE1DLUxBRyBlbmQgcG9pbnRzPyBPbmVzIGdvaW5n IHRvIHJvdXRlcg0KIDEgd2lsbCBhbGwgY2FycnkgdGhlIHNhbWUgdW5pY2FzdCBJUCBhZGRyZXNz LiBUaGUgb25lcyBnb2luZyB0b3dhcmRzIHRoZSBvdGhlciByb3V0ZXIgd2lsbCBhbGwgY2Fycnkg c29tZSBvdGhlciBJUCBhZGRyZXNzLCB3aGljaCB3b3VsZCBiZSBjb25maWd1cmVkIGFsb25nIHdp dGggdGhlIE1DLUxBRyBjb25maWdzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+SW4gZmFjdCBpIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHUtYmZkIHBhY2tldHMgZ29pbmcg dG8gZGlmZmVyZW50IHJvdXRlcnMgbXVzdCB1c2UgZGlmZmVyZW50IElQIGFkZHJlc3Nlcw0KIHNv IHRoYXQgeW91IGNhbiBhY3R1YWxseSB2ZXJpZnkgdGhlIGRhdGEgcGxhbmUgbGl2ZWxpbmVzcy4g V2hhdHMgdGhlIHBvaW50IGluIHNlbmRpbmcgYSBjb250cml2ZWQgSVAgYWRkcmVzcyBpZiB0aGUg cGF0aCB0aGF0IGl0IHRha2VzIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvdGhlciByZWd1bGFyIHBh Y2tldHM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsIE1h bmF2PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PbiBGcmksIEFwciA4 LCAyMDE2IGF0IDY6MDkgUE0sIEdyZWdvcnkgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3Jl Z29yeS5taXJza3lAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ29yeS5taXJza3lA ZXJpY3Nzb24uY29tPC9hPiZndDsNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPnRoYW5rIHlvdSBmb3Igc2hhcmluZyBpbnNpZ2h0IHZpZXcgb2YgZGlzY3Vzc2lvbnMgYXJv dW5kIFJGQyA3MTMwLCBleHRyZW1lbHkgaGVscGZ1bC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5XZSBiZWxpZXZlLCBhbmQgSmVmZiBpcyBjby1hdXRob3Igb2YgUkZDIDcxMzAgdG9v LCB0aGF0IE1DLUxBRyBwcmVzZW50cyBkaWZmZXJlbnQgY2FzZSBhbmQgdGhlIGNvbXByb21pc2UN CiB0aGF0IHlvdeKAmXZlIHBvaW50ZWQgdG9vIGlzIGp1c3RpZmllZC4gV2Ugd2lsbCBhZGQgbW9y ZSBkZXRhaWxzIG9uIHRoZSBwb3RlbnRpYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiB1bmljYXN0IGFu ZCBtdWx0aWNhc3QgZmFzdCBwYXRocyBpbiB0aGUgbmV4dCB1cGRhdGUuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5XZSBhcmUgb3BlbiB0byB0aGUgZGlzY3Vzc2lvbiBhbmQgYWx3 YXlzIHdlbGNvbWUgY29tbWVudHMgYW5kIGFsdGVybmF0aXZlIHByb3Bvc2Fscy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ IE1hbmF2DQogQmhhdGlhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmF2YmhhdGlhQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmF2YmhhdGlhQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDc6MzkgUE08YnI+DQo8Yj5Ubzo8 L2I+IE1hY2ggQ2hlbjxicj4NCjxiPkNjOjwvYj4gR3JlZ29yeSBNaXJza3k7IDxhIGhyZWY9Im1h aWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBpZXRmLm9yZzwv YT47DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1s YWctaXBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LXRhbm1pci1ydGd3 Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0Zy1i ZmQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGctYmZkLWNoYWlyc0BpZXRm Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KbXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBBbGlhIEF0bGFzICg8YSBocmVmPSJt YWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ha2F0bGFzQGdtYWlsLmNv bTwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8t KUJGRCBvdmVyIE1DLUxBRyBpbnRlcmZhY2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIGJlbGlldmUgaXQgaGFkIHRvIGRvIHdpdGgg bXVsdGljYXN0IGRhdGFwYXRoIChlc3BlY2lhbGx5IGxpbmsgbG9jYWwpIGJlaW5nIGRpZmZlcmVu dCBmcm9tIHRoZSB1bmljYXN0IGRhdGFwYXRoIGluIG1vc3Qgcm91dGVycy4gVXNpbmcgbGluayBs b2NhbCBtdWx0aWNhc3QNCiBJUCBhZGRyZXNzZXMgbWF5IG5vdCBuZWNlc3NhcmlseSBndWFyYW50 ZWUgVW5pY2FzdCBJUCByZWFjaGFiaWxpdHkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2hlbiB3cml0aW5nIDcxMzAgd2Ug c3BlbnQgcXVpdGUgYSBiaXQgb2YgdGltZSBlbnN1cmluZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0 IGEgc3BlY2lhbCBkYXRhIHBhdGggZm9yIHRoZSBtaWNyby1CRkQgcGFja2V0cy4gVXNpbmcgbGlu ayBsb2NhbCB3b3VsZCBoYXZlDQogbWFkZSBpdCBhIGxvdCBzaW1wbGVyLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QW5k IHRoaXMgaXMgd2hlcmUgaSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBmbGF3ZWQgLS0g dGhleSB1c2UgbGluayBsb2NhbCBtdWx0aWNhc3QgdG8gZW5zdXJlIElQIHVuaWNhc3QgcmVhY2hh YmlsaXR5IHdoaWNoIGlzIGluY29ycmVjdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNoZWVycywgTWFuYXY8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPk9uIFRodSwgQXByIDcsIDIwMTYgYXQgMTE6MTYgUE0sIE1hY2ggQ2hlbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFjaC5jaGVu QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBHcmVn IGFuZCBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGp1c3QgaGF2ZSBxdWljayByZXZp ZXcgb24gdGhlIGRyYWZ0cy4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgaWRl YSBpcyB0byB1c2UgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3RoZXIgdGhhbiB1bmlj YXN0IGFkZHJlc3Mgd2hlbiZuYnNwOyZuYnNwO3NlbmRpbmcgQkZEIHBhY2tldHMgb3Zlcg0KIExB RyBsaW5rcy4gQW5kIGFjdHVhbGx5IHRoaXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNl LTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Y2hlbi1iZmQtaW50ZXJmYWNlLTAwPC9hPiZuYnNwOyh0aGUgcHJlZGVjZXNzb3Igb2YgUkZDIDcx MzApLiBBbmQgYXQmbmJzcDt0aGF0IHRpbWUsIHRoZSBjby1hdXRob3JzIG9mIFJGQyA3MTMwIGRp ZCBkaXNjdXNzJm5ic3A7dGhlIGlkZWEgb2YgdXNpbmcgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFk ZHJlc3MsIGJ1dCBmb3Igc29tZSByZWFzb24gSSBmb3JnZXQgbm93KEkgbWF5IG5lZWQgdG8gcmVp dGVyYXRlIHRoZQ0KIGRpc2N1c3Npb25zIG9uIHRoZSBhcmNoaXZlKSwgdGhlIGlkZWEgd2FzIGFi YW5kb25lZCwgYWx0aG91Z2ggSSBzdGlsbCB0aGluayBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRk cmVzcyBpcyBhIHNtYXJ0IGlkZWEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CZXN0IHJlZ2Fy ZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPk1hY2gmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0i MiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ IFJ0Zy1iZmQgWzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5ydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KIG9uIGJlaGFsZiBvZiBH cmVnb3J5IE1pcnNreSBbPGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT5dPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDA1LCAyMDE2IDY6MTY8YnI+DQo8Yj5Ubzo8L2I+ IDxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJm ZEBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQpydGctYmZkLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxz LWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBscy1jaGFpcnNAaWV0Zi5vcmc8 L2E+OyBBbGlhIEF0bGFzICg8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFR3 byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RGVhciBBbGwsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPnR3byBuZXcgZHJhZnRzLCByZWxhdGVkIHRvIFJGQyA3MTMwLCB3ZXJlIHB1 Ymxpc2hlZCBiZWZvcmUgdGhlIG1lZXRpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXAtMDAiIHRhcmdldD0iX2JsYW5rIj5CRkQgb24gTUMt TEFHIGludGVyZmFjZXMgaW4gSVAgbmV0d29yazwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPsK3PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzLTAwIiB0YXJnZXQ9Il9ibGFuayI+QkZE IG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIHJldmlld3Ms IGNvbW1lbnRzLCBxdWVzdGlvbnMgYW5kIHN1Z2dlc3Rpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF11221A40D56eusaamb103erics_-- From nobody Sat Apr 9 15:32:57 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6075A12D18D; Sat, 9 Apr 2016 15:32:54 -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 HYIyqg2V90Uv; Sat, 9 Apr 2016 15:32:52 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C7112D175; Sat, 9 Apr 2016 15:32:51 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-d2-57097cb47ba4 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id F0.49.30335.4BC79075; Sun, 10 Apr 2016 00:05:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Sat, 9 Apr 2016 18:32:49 -0400 From: Gregory Mirsky To: Manav Bhatia Subject: RE: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAGbkoAAB59e4P//39qAgAAYVICAAF4BgIAACP5QgACFuwD//2O6MA== Date: Sat, 9 Apr 2016 22:32:48 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A4146E@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A4146Eeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyuXSPt+6WGs5wg9+HtS0ObDrIaPFt2lNW i8uT2tgt1l0+xWZxa+lKVotrK1rZLT7/2cbowO4x5fdGVo+ds+6yeyxZ8pPJ48vlz2wBLFFc NimpOZllqUX6dglcGQd+NDEW/NvNWLHz6VymBsaG7YxdjBwcEgImEv2z5LoYOYFMMYkL99az dTFycQgJHGWU+L/7HzOEs4xRYvbyn4wgVWwCRhIvNvawg9giAhoSre8PgBUxC+xiknh24zML SEJYwEPi9oIJrBBFnhKbX52Fsuskdv3rYQKxWQRUJFZfP8sMYvMK+ErMu3+VFWLbVjaJfQcv gxVxCgRK9F9bCNbMCHTf91NrwOLMAuISt57MZ4K4W0BiyZ7zzBC2qMTLx/9YIWwliY+/57ND 1OdLfLt3kR1imaDEyZlPWCYwis5CMmoWkrJZSMpmAUOJWUBTYv0ufYgSRYkp3Q/ZIWyg/+fM ZUcWX8DIvoqRo7S4ICc33chgEyMwQo9JsOnuYLw/3fMQowAHoxIPb0I1Z7gQa2JZcWXuIUYJ DmYlEd5IkBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHexuB/YUIC6YklqdmpqQWpRTBZJg5OqQZG ib27rFYbRvmI7n7afYPp65HwCQb5i/f9sXG4WSL7ojdgnZytmP4j5ovXCpgn+R163hkgvlKc +eLCA0fj5yQezs0RXPPnLYtP1oazE1XZt+lIPcj5+Lj0qfNmrxUz8qffKi8OXHNO4Grat+q3 r2N+Zn1N0JCQW3bXePred5VHip9pxRi9i2h+p8RSnJFoqMVcVJwIAOs/pCHMAgAA Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 22:32:54 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A4146Eeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQpJ4oCZbSBnbGFkIHRoYXQgd2XigJlyZSBjb252ZXJnaW5nIOKAkyB0aGUgZmlu YWwgZGVjaXNpb24gd291bGQgY29tZSBmcm9tIG91ciBjdXN0b21lcnMsIHRoZSBvcGVyYXRvcnMu DQpJIGhvcGUgd2XigJlsbCBoYXZlIHRoZWlyIGNvbW1lbnRzLg0KSW4gdGhlIG1lYW50aW1lLCBJ IGludml0ZSB5b3UgYW5kIG90aGVyIGV4cGVydHMgdG8gcmV2aWV3IHRoZSBzZWNvbmQgZHJhZnQg dGhhdCBsb29rcyBpbnRvIHRoZSBzYW1lIHNjZW5hcmlvIGJ1dCBvdmVyIHRoZSBJUC9NUExTIG5l dHdvcmsuIEl0IG1heSBiZSBsZXNzIGNvbnRyb3ZlcnNpYWwgYXMgbmVpdGhlciBtdWx0aWNhc3Qs IG5vciBicm9hZGNhc3QgYWRkcmVzc2VzIG5lZWQgdG8gYmUgdXNlZCBhcyB0aGUgZGVzdGluYXRp b24gSVAgYWRkcmVzcy4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFuYXYgQmhhdGlhIFttYWlsdG86bWFu YXZiaGF0aWFAZ21haWwuY29tXQ0KU2VudDogU2F0dXJkYXksIEFwcmlsIDA5LCAyMDE2IDI6MDgg QU0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IEdyZWcgTWlyc2t5OyBSZXNoYWQgUmFobWFuIChy cmFobWFuKTsgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc7 IHJ0Zy1iZmRAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW21wbHNdIFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMt TEFHIGludGVyZmFjZXMNCg0KSGkgR3JlZywNCg0KVGhlcmUgaXMgYSBkaWZmZXJlbmNlLCBhIGJp ZyBvbmUuDQoNCldoZW4geW91IHVzZSBDRk0gb3Igc29tZSBvdGhlciBMMiBPQU0gcHJvdG9jb2ws IHlvdSBkb250IG1ha2UgYW55IGNsYWltcyBhYm91dCBMMyBjb25uZWN0aXZpdHkuIEhvd2V2ZXIs IHdoZW4geW91IHN0YXJ0IHVzaW5nIEJGRCBpdCBpbXBsaWNpdGx5IG1lYW5zIHRoYXQgeW91cmUg dGFsa2luZyBhYm91dCBMMyBjb25uZWN0aXZpdHkuIFNvLCBpdHMgZ29pbmcgdG8gYmUgYml6YXJy ZSBkZWJ1Z2dpbmcgY29tcGxleCB0b3BvbG9naWVzIHdoZXJlIEJGRCBzZXNzaW9ucyBuZXZlciBm bGFwIGFuZCB5ZXQgTVBMUyBMU1BzIHJhbmRvbWx5IHRpbWUgb3V0IChiZWNhdXNlIHRoZXJlIGlz IHRoaXMgb25lIE1DLUxBRyB0aGF0cyBkcm9wcGluZyBwYWNrZXRzIC0tIGFuZCBpbiB0aGUgd29y c3QgY2FzZSwgb25seSBzcG9yYWRpY2FsbHkgYW5kIGludGVybWl0dGVudGx5IGRyb3BzIElQIHBh Y2tldHMpDQoNCkl0IHdpbGwgTk9UIHByb2R1Y2UgZmFsc2UgbmVnYXRpdmVzIChhcyB5b3UgY2xh aW0pIGJ1dCByYXRoZXIgaW50cm9kdWNlIGZhbHNlIHBvc2l0aXZlcywgd2hpY2ggaXMgbW9yZSBk YW5nZXJvdXMuIFRoZSBNQy1MQUcgd2lsbCBiZSB1cCwgd2hpbGUgaXQgd291bGQgYmUgZHJvcHBp bmcgYWxsIG9yIGZldyBJUCBwYWNrZXRzLg0KDQpJIGhhdmUgbm8gb2JqZWN0aW9ucyBpZiBvcGVy YXRvcnMgYW5kIHRoZSBjb21tdW5pdHkgdGhpbmsgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0 IHRoZXkgY2FuIGxpdmUgd2l0aC4gSSBhbSBwZXJzb25hbGx5IGhhdmluZyBhbiBvdXQtb2YtYm9k eSBleHBlcmllbmNlIGp1c3QgZGlzY3Vzc2luZyB0aGlzISA6LSkNCg0KQ2hlZXJzLCBNYW5hdg0K DQpPbiBTYXQsIEFwciA5LCAyMDE2IGF0IDk6NDYgQU0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5 Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+ IHdyb3RlOg0KSGkgTWFuYXYsDQp0aGUgdXNlIGNhc2UgZm9yIHRoZSBCRkQgb3ZlciBNQy1MQUcg aW50ZXJmYWNlcyB0aGF0IEkgY29uc2lkZXIgdGhlIG1vc3QgaW1wb3J0YW50IGZvciB0aGlzIGRy YWZ0cyB0byBhZGRyZXNzIGlzIHRvIGVuYWJsZSBzdWItc2Vjb25kIGRlZmVjdCBkZXRlY3Rpb24g aW4gb3JkZXIgdG8gdHJpZ2dlciBMQUNQIGNvbnZlcmdlbmNlIGFuZCwgc3Vic2VxdWVudGx5LCBz d2l0Y2hvdmVyIHdpdGhpbiB0aGUgUmVkdW5kYW5jeSBHcm91cCBpbiBBY3RpdmUtU3RhbmRieSBj YXNlLiBIZW5jZSBib3RoIHVuaWNhc3QgYW5kIG11bHRpY2FzdCBMMyBhZGRyZXNzZXMgYXJlIHF1 aXRlIGRpc3RhbnQgZnJvbSBMMiBmYXN0IHBhdGggYW5kIHByb2Nlc3NpbmcgdXN1YWxseSB0YWtl biBieSBDQ00gZnJhbWVzLiBPZiBjb3Vyc2UsIG9uZSBjYW4gdXNlIENGTSBwZXIgTEFHIENvbnN0 aXR1ZW50IExpbmssIGFuZCBJIGhhdmUgaW1wbGVtZW50ZWQgdGhhdCBhbmQgaXQgaW50ZXJvcGVy YXRlcyB3aXRoIGFub3RoZXIgaW1wbGVtZW50YXRpb24gYnkgb3RoZXIgdmVuZG9yLCBidXQgb3Bl cmF0b3JzIHByZWZlciBlYXNlIG9mIEJGRCBwcm92aXNpb25pbmcuIFRodXMgSeKAmXZlIHRvIHBy b3ZpZGUgdGhlbSB3aXRoIGFiaWxpdHkgdG8gbW9uaXRvciBNQy1MQUcgYW5kIGV4cGxhaW4gdGhh dCBpbiBzb21lIGNhc2VzIGl0IG1heSBwcm9kdWNlIGZhbHNlIG5lZ2F0aXZlIHdoZW4gTDIgaXMg ZnVuY3Rpb25hbCBhbmQgdGhlIHByb2JsZW0gaXMgaW4gTDMsIHVuaWNhc3Qgb3IgbXVsdGljYXN0 LCBlbmdpbmUuIEFzIHlvdSBjYW4gc2VlLCB0aGVyZeKAmXMgbm90IG11Y2ggdmFsdWUgaW4gY29u dGludWluZyBhcmd1bWVudCBob3cgbXVjaCBkaWZmZXJlbnQgTDMgbXVsdGljYXN0IHByb2Nlc3Np bmcgaXMgZnJvbSBMMyB1bmljYXN0IGFzIGJvdGggYXJlIGRpZmZlcmVudCBmcm9tIEwyIHBhdGgu IEF0IHRoZSBlbmQsIGFzIEkgdGhpbmssIGl0IGlzIHVwIHRvIG9wZXJhdG9ycyB0byBkZWNpZGUg d2hldGhlciB0aGV5IGFyZSBjb21mb3J0YWJsZSB3aXRoIHRoaXMgbWVjaGFuaXNtIG9yIHdvdWxk IHJlcXVpcmUgZGVmZWN0IGRldGVjdGlvbiBhdCBMMi4NCg0KICAgICAgICAgICAgICAgIFJlZ2Fy ZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFuYXYg QmhhdGlhIFttYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tPG1haWx0bzptYW5hdmJoYXRpYUBn bWFpbC5jb20+XQ0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiA1OjM4IFBNDQpUbzogR3Jl ZyBNaXJza3kNCkNjOiBSZXNoYWQgUmFobWFuIChycmFobWFuKTsgZHJhZnQtdGFubWlyLXJ0Z3dn LWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXRhbm1pci1ydGd3Zy1i ZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPjsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRn LWJmZEBpZXRmLm9yZz47IG1wbHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0Bp ZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBydGctYmZkLWNo YWlyc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc+OyBHcmVnb3J5IE1p cnNreQ0KU3ViamVjdDogUmU6IFttcGxzXSBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBv dmVyIE1DLUxBRyBpbnRlcmZhY2VzDQoNCkhpIEdyZWcsDQoNCg0KdGhlIHVwZGF0ZSBjb3VsZCBi ZSBpbiBhZGRpdGlvbiBvZiBlaXRoZXIgYnJvYWRjYXN0IG9yIGxpbmsgbG9jYWwgbXVsdGljYXN0 IG9yIGJvdGggd2l0aCBhcHByb3ByaWF0ZSBub3JtYXRpdmUgbGFuZ3VhZ2UuIEJ1dCBJIHdvdWxk IG5vdCBhZ3JlZSB0aGF0IHRoZXNlIHdvdWxkbid0IHdvcmsuDQoNCkRvdWJsZSBuZWdhdGl2ZXMg bWFrZSBpdCB2ZXJ5IGhhcmQgdG8gcGFyc2UgYSBzZW50ZW5jZS4NCg0KQW55d2F5LCB3aHkgd291 bGQgeW91IE5PVCBhZ3JlZSB0aGF0IHRoaXMgV09VTEROVCB3b3JrPw0KDQpJIGFtIHRlbGxpbmcg eW91IHRoYXQgbGluayBsb2NhbCBtdWx0aWNhc3RzIGFuZCB1bmljYXN0cyBhcmUgZGVhbHQgd2l0 aCBkaWZmZXJlbnRseSBpbiB0aGUgZGF0YSBwbGFuZSwgc28gdGhlIGRhdGEgcGF0aCBiZWluZyB1 cCBmb3IgdGhlIGZvcm1lciBtYXkgbm90IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCBpdHMgdXAgZm9y IHRoZSBsYXR0ZXIgYXMgd2VsbC4gU28gdGVsbCBtZSBXSFkgeW91IHRoaW5rIHRoaXMgYXJndW1l bnQgaXNudCB2YWxpZD8gSSB3YXMgdGhlIEwzIGRhdGEgcGxhbmUgYXJjaGl0ZWN0IGluIG15IGZv cm1lciBjb21wYW55IGZvciBvbmUgb2YgdGhlIHByb2R1Y3QgbGluZXMgYW5kIGkgYW0gdGVsbGlu ZyB5b3UgdGhhdCBpbiBteSBib3gsIHdoaWNoIGlzIHZlcnkgdmVyeSB3aWRlbHkgZGVwbG95ZWQs IHlvdXIgc2NoZW1lIHdpbGwgTk9UIHdvcmsgc2luY2UgaSBwdW50IGFsbCBsaW5rIGxvY2FsIHBh Y2tldHMgdG8gdGhlIENQVSBkaWZmZXJlbnRseS4gSW4gZmFjdCwgaW4gc29tZSBjYXNlcyBldmVu IHRoZSBUWCBwYXRoIGlzIGRpZmZlcmVudC4gU28gc3VyZSwgdS1CRkQgbWF5IHZlcnkgd2VsbCBj bGFpbSB0aGF0IHRoZSBsaW5rIGlzIHVwLCBidXQgaXRzIHBvc3NpYmxlIHRoYXQgdGhlcmUgbWF5 IGJlIG5vIElQIGNvbm5lY3Rpdml0eS4NCg0KQ2hlZXJzLCBNYW5hdg0KDQo= --_000_7347100B5761DC41A166AC17F22DF11221A4146Eeusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFuYXYsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPknigJltIGdsYWQgdGhhdCB3ZeKAmXJlIGNvbnZlcmdpbmcg4oCTIHRoZSBmaW5hbCBkZWNp c2lvbiB3b3VsZCBjb21lIGZyb20gb3VyIGN1c3RvbWVycywgdGhlIG9wZXJhdG9ycy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBob3BlIHdl4oCZbGwgaGF2ZSB0aGVpciBjb21tZW50 cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gdGhlIG1lYW50aW1lLCBJIGludml0 ZSB5b3UgYW5kIG90aGVyIGV4cGVydHMgdG8gcmV2aWV3IHRoZSBzZWNvbmQgZHJhZnQgdGhhdCBs b29rcyBpbnRvIHRoZSBzYW1lIHNjZW5hcmlvIGJ1dCBvdmVyIHRoZSBJUC9NUExTIG5ldHdvcmsu IEl0IG1heSBiZSBsZXNzIGNvbnRyb3ZlcnNpYWwNCiBhcyBuZWl0aGVyIG11bHRpY2FzdCwgbm9y IGJyb2FkY2FzdCBhZGRyZXNzZXMgbmVlZCB0byBiZSB1c2VkIGFzIHRoZSBkZXN0aW5hdGlvbiBJ UCBhZGRyZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVn PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW5hdiBCaGF0aWEg W21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJk YXksIEFwcmlsIDA5LCAyMDE2IDI6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IEdyZWdvcnkgTWlyc2t5 PGJyPg0KPGI+Q2M6PC9iPiBHcmVnIE1pcnNreTsgUmVzaGFkIFJhaG1hbiAocnJhaG1hbik7IGRy YWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnOyBydGctYmZkQGll dGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW21wbHNdIFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMt TEFHIGludGVyZmFjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBH cmVnLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUg aXMgYSBkaWZmZXJlbmNlLCBhIGJpZyBvbmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4geW91IHVzZSBDRk0gb3Igc29tZSBv dGhlciBMMiBPQU0gcHJvdG9jb2wsIHlvdSBkb250IG1ha2UgYW55IGNsYWltcyBhYm91dCBMMyBj b25uZWN0aXZpdHkuIEhvd2V2ZXIsIHdoZW4geW91IHN0YXJ0IHVzaW5nIEJGRCBpdCBpbXBsaWNp dGx5IG1lYW5zIHRoYXQgeW91cmUgdGFsa2luZyBhYm91dCBMMyBjb25uZWN0aXZpdHkuIFNvLCBp dHMgZ29pbmcgdG8gYmUgYml6YXJyZSBkZWJ1Z2dpbmcgY29tcGxleA0KIHRvcG9sb2dpZXMgd2hl cmUgQkZEIHNlc3Npb25zIG5ldmVyIGZsYXAgYW5kIHlldCBNUExTIExTUHMgcmFuZG9tbHkgdGlt ZSBvdXQgKGJlY2F1c2UgdGhlcmUgaXMgdGhpcyBvbmUgTUMtTEFHIHRoYXRzIGRyb3BwaW5nIHBh Y2tldHMgLS0gYW5kIGluIHRoZSB3b3JzdCBjYXNlLCBvbmx5IHNwb3JhZGljYWxseSBhbmQgaW50 ZXJtaXR0ZW50bHkgZHJvcHMgSVAgcGFja2V0cyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd2lsbCBOT1QgcHJvZHVjZSBmYWxzZSBuZWdh dGl2ZXMgKGFzIHlvdSBjbGFpbSkgYnV0IHJhdGhlciBpbnRyb2R1Y2UgZmFsc2UgcG9zaXRpdmVz LCB3aGljaCBpcyBtb3JlIGRhbmdlcm91cy4gVGhlIE1DLUxBRyB3aWxsIGJlIHVwLCB3aGlsZSBp dCB3b3VsZCBiZSBkcm9wcGluZyBhbGwgb3IgZmV3IElQIHBhY2tldHMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBubyBvYmplY3Rp b25zIGlmIG9wZXJhdG9ycyBhbmQgdGhlIGNvbW11bml0eSB0aGluayB0aGF0IHRoaXMgaXMgc29t ZXRoaW5nIHRoYXQgdGhleSBjYW4gbGl2ZSB3aXRoLiBJIGFtIHBlcnNvbmFsbHkgaGF2aW5nIGFu IG91dC1vZi1ib2R5IGV4cGVyaWVuY2UganVzdCBkaXNjdXNzaW5nIHRoaXMhIDotKTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsIE1h bmF2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gU2F0LCBBcHIgOSwgMjAxNiBhdCA5OjQ2IEFNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBNYW5hdiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj50aGUgdXNlIGNhc2UgZm9yIHRoZSBCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNlcyB0 aGF0IEkgY29uc2lkZXIgdGhlIG1vc3QgaW1wb3J0YW50IGZvciB0aGlzIGRyYWZ0cw0KIHRvIGFk ZHJlc3MgaXMgdG8gZW5hYmxlIHN1Yi1zZWNvbmQgZGVmZWN0IGRldGVjdGlvbiBpbiBvcmRlciB0 byB0cmlnZ2VyIExBQ1AgY29udmVyZ2VuY2UgYW5kLCBzdWJzZXF1ZW50bHksIHN3aXRjaG92ZXIg d2l0aGluIHRoZSBSZWR1bmRhbmN5IEdyb3VwIGluIEFjdGl2ZS1TdGFuZGJ5IGNhc2UuIEhlbmNl IGJvdGggdW5pY2FzdCBhbmQgbXVsdGljYXN0IEwzIGFkZHJlc3NlcyBhcmUgcXVpdGUgZGlzdGFu dCBmcm9tIEwyIGZhc3QgcGF0aCBhbmQNCiBwcm9jZXNzaW5nIHVzdWFsbHkgdGFrZW4gYnkgQ0NN IGZyYW1lcy4gT2YgY291cnNlLCBvbmUgY2FuIHVzZSBDRk0gcGVyIExBRyBDb25zdGl0dWVudCBM aW5rLCBhbmQgSSBoYXZlIGltcGxlbWVudGVkIHRoYXQgYW5kIGl0IGludGVyb3BlcmF0ZXMgd2l0 aCBhbm90aGVyIGltcGxlbWVudGF0aW9uIGJ5IG90aGVyIHZlbmRvciwgYnV0IG9wZXJhdG9ycyBw cmVmZXIgZWFzZSBvZiBCRkQgcHJvdmlzaW9uaW5nLiBUaHVzIEnigJl2ZSB0byBwcm92aWRlIHRo ZW0NCiB3aXRoIGFiaWxpdHkgdG8gbW9uaXRvciBNQy1MQUcgYW5kIGV4cGxhaW4gdGhhdCBpbiBz b21lIGNhc2VzIGl0IG1heSBwcm9kdWNlIGZhbHNlIG5lZ2F0aXZlIHdoZW4gTDIgaXMgZnVuY3Rp b25hbCBhbmQgdGhlIHByb2JsZW0gaXMgaW4gTDMsIHVuaWNhc3Qgb3IgbXVsdGljYXN0LCBlbmdp bmUuIEFzIHlvdSBjYW4gc2VlLCB0aGVyZeKAmXMgbm90IG11Y2ggdmFsdWUgaW4gY29udGludWlu ZyBhcmd1bWVudCBob3cgbXVjaCBkaWZmZXJlbnQgTDMgbXVsdGljYXN0DQogcHJvY2Vzc2luZyBp cyBmcm9tIEwzIHVuaWNhc3QgYXMgYm90aCBhcmUgZGlmZmVyZW50IGZyb20gTDIgcGF0aC4gQXQg dGhlIGVuZCwgYXMgSSB0aGluaywgaXQgaXMgdXAgdG8gb3BlcmF0b3JzIHRvIGRlY2lkZSB3aGV0 aGVyIHRoZXkgYXJlIGNvbWZvcnRhYmxlIHdpdGggdGhpcyBtZWNoYW5pc20gb3Igd291bGQgcmVx dWlyZSBkZWZlY3QgZGV0ZWN0aW9uIGF0IEwyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gTWFuYXYgQmhhdGlhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmF2 YmhhdGlhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmF2YmhhdGlhQGdtYWlsLmNvbTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiA1OjM4IFBNPGJy Pg0KPGI+VG86PC9iPiBHcmVnIE1pcnNreTxicj4NCjxiPkNjOjwvYj4gUmVzaGFkIFJhaG1hbiAo cnJhaG1hbik7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1p cEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtdGFubWlyLXJ0Z3dnLWJm ZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRnLWJmZEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtY2hhaXJz QGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bXBsc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGctYmZkLWNoYWlyc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBH cmVnb3J5IE1pcnNreTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIFR3byBuZXcgZHJh ZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBHcmVnLDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cD50aGUgdXBkYXRlIGNvdWxkIGJlIGluIGFkZGl0aW9uIG9m IGVpdGhlciBicm9hZGNhc3Qgb3IgbGluayBsb2NhbCBtdWx0aWNhc3Qgb3IgYm90aCB3aXRoIGFw cHJvcHJpYXRlIG5vcm1hdGl2ZSBsYW5ndWFnZS4gQnV0IEkgd291bGQgbm90IGFncmVlIHRoYXQg dGhlc2Ugd291bGRuJ3Qgd29yay4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvdWJsZSBuZWdhdGl2ZXMgbWFrZSBpdCB2 ZXJ5IGhhcmQgdG8gcGFyc2UgYSBzZW50ZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFueXdheSwgd2h5IHdvdWxkIHlvdSBOT1Qg YWdyZWUgdGhhdCB0aGlzIFdPVUxETlQgd29yaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYW0gdGVsbGluZyB5b3UgdGhhdCBsaW5r IGxvY2FsIG11bHRpY2FzdHMgYW5kIHVuaWNhc3RzIGFyZSBkZWFsdCB3aXRoIGRpZmZlcmVudGx5 IGluIHRoZSBkYXRhIHBsYW5lLCBzbyB0aGUgZGF0YSBwYXRoIGJlaW5nIHVwIGZvciB0aGUgZm9y bWVyIG1heSBub3QgbmVjZXNzYXJpbHkgbWVhbiB0aGF0IGl0cw0KIHVwIGZvciB0aGUgbGF0dGVy IGFzIHdlbGwuIFNvIHRlbGwgbWUgV0hZIHlvdSB0aGluayB0aGlzIGFyZ3VtZW50IGlzbnQgdmFs aWQ/IEkgd2FzIHRoZSBMMyBkYXRhIHBsYW5lIGFyY2hpdGVjdCBpbiBteSBmb3JtZXIgY29tcGFu eSBmb3Igb25lIG9mIHRoZSBwcm9kdWN0IGxpbmVzIGFuZCBpIGFtIHRlbGxpbmcgeW91IHRoYXQg aW4gbXkgYm94LCB3aGljaCBpcyB2ZXJ5IHZlcnkgd2lkZWx5IGRlcGxveWVkLCB5b3VyIHNjaGVt ZSB3aWxsIE5PVA0KIHdvcmsgc2luY2UgaSBwdW50IGFsbCBsaW5rIGxvY2FsIHBhY2tldHMgdG8g dGhlIENQVSBkaWZmZXJlbnRseS4gSW4gZmFjdCwgaW4gc29tZSBjYXNlcyBldmVuIHRoZSBUWCBw YXRoIGlzIGRpZmZlcmVudC4gU28gc3VyZSwgdS1CRkQgbWF5IHZlcnkgd2VsbCBjbGFpbSB0aGF0 IHRoZSBsaW5rIGlzIHVwLCBidXQgaXRzIHBvc3NpYmxlIHRoYXQgdGhlcmUgbWF5IGJlIG5vIElQ IGNvbm5lY3Rpdml0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkNoZWVycywgTWFuYXY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_7347100B5761DC41A166AC17F22DF11221A4146Eeusaamb103erics_-- From nobody Mon Apr 11 10:19:17 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872DC12F1EB; Mon, 11 Apr 2016 10:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhAyYEaGanGJ; Mon, 11 Apr 2016 10:19:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 77F6712F1EA; Mon, 11 Apr 2016 10:19:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4AE8B1E83B; Mon, 11 Apr 2016 13:23:32 -0400 (EDT) Date: Mon, 11 Apr 2016 13:23:32 -0400 From: Jeffrey Haas To: Greg Mirsky Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Message-ID: <20160411172332.GA22064@pfrc.org> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 17:19:16 -0000 Greg, This is more of a general comment on discussions from the development from RFC 7130 than any specific comment on your draft. On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote: > yes, link local multicast may be used in MC-LAG scenario. The draft states > that it MAY be used while the broadcast has SHOULD normative. But we are > all open to the discussion. During our discussions across multiple vendors, including some hardware vendors, it was determined that attempts to exercise the layer 3 mechanisms would vary significantly across implementations depending on how packets were encapsulated. Multicast in particular provided some problematic issues for us beyond the initial bootstrapping phase of LAG for BFD wherein we might not have ARP completed. My recommendation is to proceed with your drafts with similar caution. Try to stay as true to pure IP as possible to best insure the L3 data paths are exercised across implementations from various vendors. -- Jeff (speaking as an individual contributor) From nobody Tue Apr 12 15:48:50 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E076012DBD7; Tue, 12 Apr 2016 15:48:45 -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 6ren1AXIExCF; Tue, 12 Apr 2016 15:48:43 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E8D12DDE5; Tue, 12 Apr 2016 15:48:43 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-82-570d74c7d730 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 50.CE.09012.7C47D075; Wed, 13 Apr 2016 00:20:55 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Tue, 12 Apr 2016 18:48:42 -0400 From: Gregory Mirsky To: Jeffrey Haas , Greg Mirsky Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAYagaD//+aOgIAAJa0AgASgtgD//lcisA== Date: Tue, 12 Apr 2016 22:48:40 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A43F14@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> <20160411172332.GA22064@pfrc.org> In-Reply-To: <20160411172332.GA22064@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A43F14eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyuXRPrO7xEt5wg+kzjSw+PbzEbHFg00FG i2/TnrJa7D/4ltVi3eVTbBa3lq5ktbi2opXdYsnte+wWn/9sY3Tg9JjyeyOrx85Zd9k9liz5 yeRxuXcrq8eXy5/ZAlijuGxSUnMyy1KL9O0SuDK2NixiKzhkWbH87wSmBsazhl2MnBwSAiYS L59OZoWwxSQu3FvP1sXIxSEkcJRRYn9DAwuEs5xR4sPbk2BVbAJGEi829rCD2CICbhK3puxl BiliFmhiltg3/xgLSEJYwFHi+/xrzBBFThIfrixmhbCzJA4+XQVmswioSlyfthqsnlfAV+L+ /EVQ2w6wSNy8vYoJJMEpoCcx5f1+NhCbEei+76fWgMWZBcQlbj2ZzwRxt4DEkj3nmSFsUYmX j/9B/aMkMWnpOVaI+nyJh29us0EsE5Q4OfMJywRG0VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSy ha+ZYewzBx4zIYsvYGRfxchRWlyQk5tuZLCJERi/xyTYdHcw3p/ueYhRgINRiYd3QRhPuBBr YllxZe4hRgkOZiUR3pwK3nAh3pTEyqrUovz4otKc1OJDjNIcLErivI3B/8KEBNITS1KzU1ML UotgskwcnFINjHrPb4WnHEv+tMvKfnvWqwVPpI4uWBk4tdfo2D/Jqb+/fWg5uCZayXGP6uND O20rFl59HiXL/sbOM81MyYdt6sqHNx62nrpyyUnEU6cgTy/1cPTRdx9Td+1beaVwbrOTgcL0 Vo9ny/Xe8mmYJr0/euhd6QHF6yqqR2u8UjTstpdfDI4Ifr+I/ZYSS3FGoqEWc1FxIgADdEGL 2wIAAA== Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 22:48:46 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A43F14eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeff, thank you for adding more details to the discussions before RFC 7130. We ha= ve submitted another draft that proposes to use MPLS encapsulation of BFD c= ontrol packets over MC-LAG interfaces. Would greatly appreciate reviews, qu= estions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls. Regards, Greg -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 11, 2016 10:24 AM To: Greg Mirsky Cc: Reshad Rahman (rrahman); draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.or= g; mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg= -bfd@ietf.org; rtg-bfd-chairs@ietf.org Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Greg, This is more of a general comment on discussions from the development from = RFC 7130 than any specific comment on your draft. On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote: > yes, link local multicast may be used in MC-LAG scenario. The draft > states that it MAY be used while the broadcast has SHOULD normative. > But we are all open to the discussion. During our discussions across multiple vendors, including some hardware ven= dors, it was determined that attempts to exercise the layer 3 mechanisms wo= uld vary significantly across implementations depending on how packets were= encapsulated. Multicast in particular provided some problematic issues fo= r us beyond the initial bootstrapping phase of LAG for BFD wherein we might= not have ARP completed. My recommendation is to proceed with your drafts with similar caution. Try= to stay as true to pure IP as possible to best insure the L3 data paths ar= e exercised across implementations from various vendors. -- Jeff (speaking as an individual contributor) --_000_7347100B5761DC41A166AC17F22DF11221A43F14eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeff,

thank you for adding more details to the discussi= ons before RFC 7130. We have submitted another draft that proposes to use M= PLS encapsulation of BFD control packets over MC-LAG interfaces. Would grea= tly appreciate reviews, questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls.

 

        &= nbsp;       Regards,

        &= nbsp;           &nbs= p;           Greg

 

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 11, 2016 10:24 AM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman); draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.or= g; mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg= -bfd@ietf.org; rtg-bfd-chairs@ietf.org
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Greg,

 

This is more of a general comment on discussions = from the development from RFC 7130 than any specific comment on your draft.=  

 

On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mi= rsky wrote:

> yes, link local multicast may be used in MC-= LAG scenario. The draft

> states that it MAY be used while the broadca= st has SHOULD normative.

> But we are all open to the discussion.<= /o:p>

 

During our discussions across multiple vendors, i= ncluding some hardware vendors, it was determined that attempts to exercise= the layer 3 mechanisms would vary significantly across implementations dep= ending on how packets were encapsulated.  Multicast in particular provided some problematic issues for us beyond the= initial bootstrapping phase of LAG for BFD wherein we might not have ARP c= ompleted. 

 

My recommendation is to proceed with your drafts = with similar caution.  Try to stay as true to pure IP as possible to b= est insure the L3 data paths are exercised across implementations from vari= ous vendors.

 

-- Jeff (speaking as an individual contributor)

--_000_7347100B5761DC41A166AC17F22DF11221A43F14eusaamb103erics_-- From nobody Wed Apr 13 06:26:16 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6366612DE26; Wed, 13 Apr 2016 06:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 dWeUoA7UWLQh; Wed, 13 Apr 2016 06:08:16 -0700 (PDT) Received: from mail-ob0-x242.google.com (mail-ob0-x242.google.com [IPv6:2607:f8b0:4003:c01::242]) (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 7DB7512DE0A; Wed, 13 Apr 2016 06:08:16 -0700 (PDT) Received: by mail-ob0-x242.google.com with SMTP id rf6so3046761obc.3; Wed, 13 Apr 2016 06:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jQGfI6CoA1NDL5G+b28rNKIqgv0dUr8+YwTWcSe7Myc=; b=EUbqB1yYDM+ceovJCiehlZg9ZLwHTFT5dpfiw8QBquF/WdhyeJn5pPecL7nvi5iNhO J8+izVPOHpUGzPcj14xjSZ6TWFBQYNjvwx60NyczoIgRGyiwfkYZ6VD4uPN7WTHlbKdc ybwUdGjW/vSCwvVNg3GPbQBHweWFz+uvO1iBkT+Cglku/E8cXo2jsFWdqqTf7cviOY8F wsXm8WesnEyI7UpCXvHY5bzY32jMlf74I6IcoGz7hf+rzy1t4jUd8WIQfGX1dxWYMKG3 3llEOfx+UO2wOJkAFbhCS6ufVcnWyHnUu54tZvCCJbjEsowiyEPWXAF1KnqQYvqwl8P2 ubQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jQGfI6CoA1NDL5G+b28rNKIqgv0dUr8+YwTWcSe7Myc=; b=JMNGV+Yfg7iOTHj2oQMnipT2qmtN7AcY6wJGpbG4jz+bE74iTkpTFMy+LHPQp2NzcZ o/lg7VzryVQffKj8C1M+QyiBSiPFhme77j/+oQTa1gicsIzqRwZ1ICpxddyH18VCHnZL u8SOIYu6xdmtRNkRj2z3by2umjdRHbgwokH9NBd4SuRPvsRl4cNYeOAhU8H6iPEVWfTB 8StgaNj8bIob+gproEWRaJsGPqYTqDpsJiLoBiKQQx5STvX2jcLwjz+T+gBgY08Cug8/ SVwLmzmH2XfnraHfiVAMYAi+IMGSoi6DzpS9h7uK5mGFzkiwHCOg9W5FkebgmyEUUI+r 1d2w== X-Gm-Message-State: AOPr4FWJ1rAmZTBDZqy848IR5IA2UPmLOMI/bhblIt8Kk1lJ+38SgJ/yEwNSoDva/1lS79Ph8wGNLsJw6TkxJw== MIME-Version: 1.0 X-Received: by 10.182.105.65 with SMTP id gk1mr4309394obb.37.1460552895791; Wed, 13 Apr 2016 06:08:15 -0700 (PDT) Received: by 10.202.62.133 with HTTP; Wed, 13 Apr 2016 06:08:15 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A43F14@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> <20160411172332.GA22064@pfrc.org> <7347100B5761DC41A166AC17F22DF11221A43F14@eusaamb103.ericsson.se> Date: Wed, 13 Apr 2016 18:38:15 +0530 Message-ID: Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces From: Glen Kent To: Gregory Mirsky Content-Type: multipart/alternative; boundary=e89a8ff1cf9c87898a05305d78a3 Archived-At: X-Mailman-Approved-At: Wed, 13 Apr 2016 06:26:13 -0700 Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 13:08:19 -0000 --e89a8ff1cf9c87898a05305d78a3 Content-Type: text/plain; charset=UTF-8 Gregory, You are using a special GAL label for BFD packets. This label exists only for the BFD packets. How can you then claim connectivity for other traffic which will not use this label? Glen On Wed, Apr 13, 2016 at 4:18 AM, Gregory Mirsky wrote: > Hi Jeff, > > thank you for adding more details to the discussions before RFC 7130. We > have submitted another draft that proposes to use MPLS encapsulation of BFD > control packets over MC-LAG interfaces. Would greatly appreciate reviews, > questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls > . > > > > Regards, > > Greg > > > > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Monday, April 11, 2016 10:24 AM > To: Greg Mirsky > Cc: Reshad Rahman (rrahman); > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; > rtg-bfd-chairs@ietf.org > Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > Greg, > > > > This is more of a general comment on discussions from the development from > RFC 7130 than any specific comment on your draft. > > > > On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote: > > > yes, link local multicast may be used in MC-LAG scenario. The draft > > > states that it MAY be used while the broadcast has SHOULD normative. > > > But we are all open to the discussion. > > > > During our discussions across multiple vendors, including some hardware > vendors, it was determined that attempts to exercise the layer 3 mechanisms > would vary significantly across implementations depending on how packets > were encapsulated. Multicast in particular provided some problematic > issues for us beyond the initial bootstrapping phase of LAG for BFD wherein > we might not have ARP completed. > > > > My recommendation is to proceed with your drafts with similar caution. > Try to stay as true to pure IP as possible to best insure the L3 data paths > are exercised across implementations from various vendors. > > > > -- Jeff (speaking as an individual contributor) > --e89a8ff1cf9c87898a05305d78a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gregory,

You are using a special GAL la= bel for BFD packets. This label exists only for the BFD packets.=C2=A0

How can you then claim connectivity for other traffic = which will not use this label?

Glen

On Wed, Apr 13, 2016= at 4:18 AM, Gregory Mirsky <gregory.mirsky@ericsson.com>= wrote:

Hi Jeff,

thank you for adding more details to the discussions before RFC 7130. We= have submitted another draft that proposes to use MPLS encapsulation of BF= D control packets over MC-LAG interfaces. Would greatly appreciate reviews,= questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls.

=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= =C2=A0=C2=A0=C2=A0 Regards,

=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg

=C2=A0

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 11, 2016 10:24 AM
To: Greg Mirsky
 Cc: Reshad Rahman (rrahman); draft-tanmir-rtgwg-bfd-mc-lag-ip@too= ls.ietf.org; mpls@ie= tf.org; mpls-= chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; rtg-bfd-chairs@ietf.org
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

Greg,

=C2=A0

This is more of a general comment on discussions from the development fr= om RFC 7130 than any specific comment on your draft.=C2=A0

=C2=A0

On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote:

> yes, link local multicast may be used in MC-LAG scenario. The draft

> states that it MAY be used while the broadcast has SHOULD normative= .

> But we are all open to the discussion.

=C2=A0

During our discussions across multiple vendors, including some hardware = vendors, it was determined that attempts to exercise the layer 3 mechanisms= would vary significantly across implementations depending on how packets w= ere encapsulated.=C2=A0 Multicast in particular provided some problematic issues for us beyond the= initial bootstrapping phase of LAG for BFD wherein we might not have ARP c= ompleted.=C2=A0

=C2=A0

My recommendation is to proceed with your drafts with similar caution.= =C2=A0 Try to stay as true to pure IP as possible to best insure the L3 dat= a paths are exercised across implementations from various vendors.

=C2=A0

-- Jeff (speaking as an individual contributor)


--e89a8ff1cf9c87898a05305d78a3-- From nobody Wed Apr 13 07:56:32 2016 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E3712E3B9; Wed, 13 Apr 2016 07:56:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-ip-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160413145628.6116.18525.idtracker@ietfa.amsl.com> Date: Wed, 13 Apr 2016 07:56:28 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:56:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS Authors : Nobo Akiya Carlos Pignataro Dave Ward Filename : draft-ietf-bfd-seamless-ip-04.txt Pages : 8 Date : 2016-04-13 Abstract: This document defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-ip-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-ip-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 Apr 13 07:58:09 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D954812E40D; Wed, 13 Apr 2016 07:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqqm1Cvxk7S6; Wed, 13 Apr 2016 07:58:04 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F65712E40B; Wed, 13 Apr 2016 07:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1541; q=dns/txt; s=iport; t=1460559484; x=1461769084; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LcjliTTX/y76kyG52QeDGi7di0/uWuLWPppDLs+jlq0=; b=BJ0kVt4wzbuwMCl3hE0gW/NZ+O/qG/bJdaJKrPcyWj0QwZKPofGcZkFE Hsal/bhXtNOgEpj5PZfKCZbEPJSNvTSZB+8qWzlzWGW8mOPdNS7zLBmby H+8PI1k0leZnvb65Tpt1oprVAykqEBBm1wejz47NU9xckc2movoThNaQH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgCeXQ5X/4gNJK1egzdTfQa6RgENg?= =?us-ascii?q?XQihWwCgT84FAEBAQEBAQFlJ4RCAQEEOj0SAgEINhAyJQIEARKIKA7DHQEBAQE?= =?us-ascii?q?BAQEBAgEBAQEBAQEZhiGES4Q9hVgBBI1QijgBhXaIFoFnToQAiFuGIIkGAR4BA?= =?us-ascii?q?UKDZ2wBiHt+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,480,1454976000"; d="scan'208";a="261079070" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2016 14:58:03 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3DEw2uT018171 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 14:58:03 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 10:58:02 -0400 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 10:58:02 -0400 From: "Nitish Gupta (nitisgup)" To: "internet-drafts@ietf.org" , "Aditya Dogra (addogra)" , Colin Docherty , "Greg Mirsky" , Jeff Tantsura , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-03.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-03.txt Thread-Index: AQHRlZR6orPig6ufBEO11re3i3Mt8Z+IncoA Date: Wed, 13 Apr 2016 14:58:02 +0000 Message-ID: References: <20160413145508.6010.3149.idtracker@ietfa.amsl.com> In-Reply-To: <20160413145508.6010.3149.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.78.77] Content-Type: text/plain; charset="us-ascii" Content-ID: <57A62EC358BD844C9D367DB06B8CFDB5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:58:06 -0000 Hi All, We have submitted the new version of the draft. In this version we have just updated just the version to avoid Expiration. We would take care of the comments in few weeks and update another version with comments taken care. We apologize that we have not been able to incorporate the comments in time given by the working group members. Thanks, Nitish On 13/04/16 8:25 pm, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-nitish-vrrp-bfd-03.txt >has been successfully submitted by Nitish Gupta and posted to the >IETF repository. > >Name: draft-nitish-vrrp-bfd >Revision: 03 >Title: Fast failure detection in VRRP with BFD >Document date: 2016-04-13 >Group: Individual Submission >Pages: 10 >URL: =20 >https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-03.txt >Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-03 >Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-= 03 > >Abstract: > This document describes how Bidirectional Forwarding Detection (BFD) > can be used to support sub-second detection of a Master Router > failure in the Virtual Router Redundancy Protocol (VRRP). > > =20 > =20 > > >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. > >The IETF Secretariat > From nobody Wed Apr 13 07:58:23 2016 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 385DF12E40B; Wed, 13 Apr 2016 07:58:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-base-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160413145815.5929.92176.idtracker@ietfa.amsl.com> Date: Wed, 13 Apr 2016 07:58:15 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:58:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Authors : Nobo Akiya Carlos Pignataro Dave Ward Manav Bhatia Santosh Pallagatti Filename : draft-ietf-bfd-seamless-base-09.txt Pages : 21 Date : 2016-04-13 Abstract: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-base-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-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 Wed Apr 13 10:12:25 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF8912B008; Wed, 13 Apr 2016 08:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N79C8PU8eyOZ; Wed, 13 Apr 2016 08:49:24 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6C912D14B; Wed, 13 Apr 2016 08:49:23 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-60-570e6a5aaae7 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 00.00.03614.A5A6E075; Wed, 13 Apr 2016 17:48:43 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Wed, 13 Apr 2016 11:49:22 -0400 From: Gregory Mirsky To: Glen Kent Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAYagaD//+aOgIAAJa0AgASgtgD//lcisIAEhjSAgAAYQ7A= Date: Wed, 13 Apr 2016 15:49:21 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A4498F@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> <20160411172332.GA22064@pfrc.org> <7347100B5761DC41A166AC17F22DF11221A43F14@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A4498Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUyuXRPuG50Fl+4wb5uTotPDy8xWxzYdJDR Ys+J9ywW36Y9ZbXYf/Atq8W6y6fYLG4tXclqcW1FK7vFktv32C0+/9nG6MDlMeX3RlaPnbPu snssWfKTyeNy71ZWjy+XP7MFsEZx2aSk5mSWpRbp2yVwZeyYMY+t4EgrY8WO+4+ZGhh/NDJ2 MXJySAiYSDw68YsFwhaTuHBvPVsXIxeHkMBRRomvu+4yQjjLGSV6JkJ0sAkYSbzY2MPexcjB ISKgLPHmZgpIDbPACWaJTz1/mUFqhAUcJb7PvwZmiwg4SXy4spgVwi6TmNG9HWwbi4CqxP87 rWA2r4CvxMzGUywQy06zSrR2fmIHSXAKBEqcW3oCbBAj0HnfT61hArGZBcQlbj2ZzwRxtoDE kj3nmSFsUYmXj/+xQthKEpOWnmOFqM+XaD7VxAixTFDi5MwnLBMYRWchGTULSdksJGWzgP5k FtCUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYOUqLC3Jy040MNzECI/mYBJvjDsa9vZ6H GAU4GJV4eBMe8IYLsSaWFVfmHmKU4GBWEuEtyuALF+JNSaysSi3Kjy8qzUktPsQozcGiJM7r HfkvTEggPbEkNTs1tSC1CCbLxMEp1cBoY3mtRvzt3Yem8wV0Ztx5wbHD7lq4UPidjY+cK7q+ XXodUCTCNOsSb/xVrRkJ9/VXrE068jlQ7eiJB0fM7j73SLKrlzptImPM+5Jzw32BcubomvyO Fc0Tbczf2k/u2qW38Nbk7OfCSkwr1gkeaD9QwnDT/5Q3w8RQ+5v/rqqqzmtxEwupZO1TYinO SDTUYi4qTgQAvf2/yeACAAA= Archived-At: X-Mailman-Approved-At: Wed, 13 Apr 2016 10:12:25 -0700 Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 15:49:26 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A4498Feusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2xlbiwNCnRoYW5rIHlvdSBmb3IgeW91ciBxdWVzdGlvbi4gSSB3b3VsZCBub3Qgc2F5IHRo YXQgR0FMIGxhYmVsIOKAnGV4aXN0cyBvbmx5IGZvciB0aGUgQkZEIHBhY2tldHPigJ0uIFRoaXMg c3BlY2lhbCBwdXJwb3NlIGxhYmVsIGNhbiBiZSB1c2VkIGluIGluZmluaXRlIG51bWJlciBvZiBz Y2VuYXJpb3MsIGluY2x1ZGluZyBNQy1MQUcgZW52aXJvbm1lbnQuIEJ1dCBJIGFncmVlLCBhcyBp biB0aGUgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXAsIHdlIG1ha2UgY2VydGFpbiBh c3N1bXB0aW9ucyBhYm91dCB0aGUgZm9yd2FyZGluZyBlbmdpbmVzIGFuZCB3aGV0aGVyIHByb3Bl ciBwcm9jZXNzaW5nIG9mIE1QTFMgZW5jYXBzdWxhdGVkIHBhY2tldCBtYXkgYmUgaW50ZXJwcmV0 ZWQgYXMgaW5kaWNhdGlvbiBvZiBwcm9wZXJseSBmdW5jdGlvbmluZyBMYXllciAyIGFuZC9vciBM YXllciAzLiBPciwgd2hhdCBtYXkgbW9yZSBpbXBvcnRhbnQgZm9yIG1vbml0b3JpbmcgbGluayBs YXllciwgZmFpbHVyZSBkZXRlY3RlZCB3aXRoIE1QTFMgZW5jYXBzdWxhdGlvbiBtYXkgYmUgaW50 ZXJwcmV0ZWQgYXMgaW5kaWNhdGlvbiBvZiBhIGRlZmVjdCBpbiBMYXllciAyIGFuZC9vciBMYXll ciAzLg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgR3JlZw0KDQpGcm9tOiBHbGVuIEtlbnQgW21haWx0bzpnbGVuLmtlbnRAZ21haWwu Y29tXQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMywgMjAxNiA2OjA4IEFNDQpUbzogR3JlZ29y eSBNaXJza3kNCkNjOiBKZWZmcmV5IEhhYXM7IEdyZWcgTWlyc2t5OyBkcmFmdC10YW5taXItcnRn d2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFp cnNAaWV0Zi5vcmc7IEFsaWEgQXRsYXMgKGFrYXRsYXNAZ21haWwuY29tKTsgUmVzaGFkIFJhaG1h biAocnJhaG1hbik7IHJ0Zy1iZmRAaWV0Zi5vcmc7IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogVHdvIG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcgaW50 ZXJmYWNlcw0KDQpHcmVnb3J5LA0KDQpZb3UgYXJlIHVzaW5nIGEgc3BlY2lhbCBHQUwgbGFiZWwg Zm9yIEJGRCBwYWNrZXRzLiBUaGlzIGxhYmVsIGV4aXN0cyBvbmx5IGZvciB0aGUgQkZEIHBhY2tl dHMuDQoNCkhvdyBjYW4geW91IHRoZW4gY2xhaW0gY29ubmVjdGl2aXR5IGZvciBvdGhlciB0cmFm ZmljIHdoaWNoIHdpbGwgbm90IHVzZSB0aGlzIGxhYmVsPw0KDQpHbGVuDQoNCk9uIFdlZCwgQXBy IDEzLCAyMDE2IGF0IDQ6MTggQU0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmlj c3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpI aSBKZWZmLA0KDQp0aGFuayB5b3UgZm9yIGFkZGluZyBtb3JlIGRldGFpbHMgdG8gdGhlIGRpc2N1 c3Npb25zIGJlZm9yZSBSRkMgNzEzMC4gV2UgaGF2ZSBzdWJtaXR0ZWQgYW5vdGhlciBkcmFmdCB0 aGF0IHByb3Bvc2VzIHRvIHVzZSBNUExTIGVuY2Fwc3VsYXRpb24gb2YgQkZEIGNvbnRyb2wgcGFj a2V0cyBvdmVyIE1DLUxBRyBpbnRlcmZhY2VzLiBXb3VsZCBncmVhdGx5IGFwcHJlY2lhdGUgcmV2 aWV3cywgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBvbiBkcmFmdC10YW5taXItcnRnd2ctYmZkLW1j LWxhZy1tcGxzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5taXItcnRnd2ct YmZkLW1jLWxhZy1tcGxzLTAwPi4NCg0KDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBKZWZmcmV5IEhhYXMgW21haWx0bzpqaGFhc0BwZnJjLm9yZzxt YWlsdG86amhhYXNAcGZyYy5vcmc+XQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxMSwgMjAxNiAxMDoy NCBBTQ0KVG86IEdyZWcgTWlyc2t5DQpDYzogUmVzaGFkIFJhaG1hbiAocnJhaG1hbik7IGRyYWZ0 LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC10 YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bXBscy1j aGFpcnNAaWV0Zi5vcmc+OyBBbGlhIEF0bGFzIChha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWth dGxhc0BnbWFpbC5jb20+KTsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9y Zz47IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPG1haWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxB RyBpbnRlcmZhY2VzDQoNCg0KDQpHcmVnLA0KDQoNCg0KVGhpcyBpcyBtb3JlIG9mIGEgZ2VuZXJh bCBjb21tZW50IG9uIGRpc2N1c3Npb25zIGZyb20gdGhlIGRldmVsb3BtZW50IGZyb20gUkZDIDcx MzAgdGhhbiBhbnkgc3BlY2lmaWMgY29tbWVudCBvbiB5b3VyIGRyYWZ0Lg0KDQoNCg0KT24gRnJp LCBBcHIgMDgsIDIwMTYgYXQgMTE6NDM6MThBTSAtMDcwMCwgR3JlZyBNaXJza3kgd3JvdGU6DQoN Cj4geWVzLCBsaW5rIGxvY2FsIG11bHRpY2FzdCBtYXkgYmUgdXNlZCBpbiBNQy1MQUcgc2NlbmFy aW8uIFRoZSBkcmFmdA0KDQo+IHN0YXRlcyB0aGF0IGl0IE1BWSBiZSB1c2VkIHdoaWxlIHRoZSBi cm9hZGNhc3QgaGFzIFNIT1VMRCBub3JtYXRpdmUuDQoNCj4gQnV0IHdlIGFyZSBhbGwgb3BlbiB0 byB0aGUgZGlzY3Vzc2lvbi4NCg0KDQoNCkR1cmluZyBvdXIgZGlzY3Vzc2lvbnMgYWNyb3NzIG11 bHRpcGxlIHZlbmRvcnMsIGluY2x1ZGluZyBzb21lIGhhcmR3YXJlIHZlbmRvcnMsIGl0IHdhcyBk ZXRlcm1pbmVkIHRoYXQgYXR0ZW1wdHMgdG8gZXhlcmNpc2UgdGhlIGxheWVyIDMgbWVjaGFuaXNt cyB3b3VsZCB2YXJ5IHNpZ25pZmljYW50bHkgYWNyb3NzIGltcGxlbWVudGF0aW9ucyBkZXBlbmRp bmcgb24gaG93IHBhY2tldHMgd2VyZSBlbmNhcHN1bGF0ZWQuICBNdWx0aWNhc3QgaW4gcGFydGlj dWxhciBwcm92aWRlZCBzb21lIHByb2JsZW1hdGljIGlzc3VlcyBmb3IgdXMgYmV5b25kIHRoZSBp bml0aWFsIGJvb3RzdHJhcHBpbmcgcGhhc2Ugb2YgTEFHIGZvciBCRkQgd2hlcmVpbiB3ZSBtaWdo dCBub3QgaGF2ZSBBUlAgY29tcGxldGVkLg0KDQoNCg0KTXkgcmVjb21tZW5kYXRpb24gaXMgdG8g cHJvY2VlZCB3aXRoIHlvdXIgZHJhZnRzIHdpdGggc2ltaWxhciBjYXV0aW9uLiAgVHJ5IHRvIHN0 YXkgYXMgdHJ1ZSB0byBwdXJlIElQIGFzIHBvc3NpYmxlIHRvIGJlc3QgaW5zdXJlIHRoZSBMMyBk YXRhIHBhdGhzIGFyZSBleGVyY2lzZWQgYWNyb3NzIGltcGxlbWVudGF0aW9ucyBmcm9tIHZhcmlv dXMgdmVuZG9ycy4NCg0KDQoNCi0tIEplZmYgKHNwZWFraW5nIGFzIGFuIGluZGl2aWR1YWwgY29u dHJpYnV0b3IpDQoNCg== --_000_7347100B5761DC41A166AC17F22DF11221A4498Feusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgR2xlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+dGhhbmsgeW91IGZvciB5b3VyIHF1ZXN0aW9uLiBJIHdvdWxkIG5vdCBzYXkgdGhhdCBHQUwg bGFiZWwg4oCcZXhpc3RzIG9ubHkgZm9yIHRoZSBCRkQgcGFja2V0c+KAnS4gVGhpcyBzcGVjaWFs IHB1cnBvc2UgbGFiZWwgY2FuIGJlIHVzZWQgaW4gaW5maW5pdGUgbnVtYmVyIG9mDQogc2NlbmFy aW9zLCBpbmNsdWRpbmcgTUMtTEFHIGVudmlyb25tZW50LiBCdXQgSSBhZ3JlZSwgYXMgaW4gdGhl IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwLCB3ZSBtYWtlIGNlcnRhaW4gYXNzdW1w dGlvbnMgYWJvdXQgdGhlIGZvcndhcmRpbmcgZW5naW5lcyBhbmQgd2hldGhlciBwcm9wZXIgcHJv Y2Vzc2luZyBvZiBNUExTIGVuY2Fwc3VsYXRlZCBwYWNrZXQgbWF5IGJlIGludGVycHJldGVkIGFz IGluZGljYXRpb24gb2YgcHJvcGVybHkNCiBmdW5jdGlvbmluZyBMYXllciAyIGFuZC9vciBMYXll ciAzLiBPciwgd2hhdCBtYXkgbW9yZSBpbXBvcnRhbnQgZm9yIG1vbml0b3JpbmcgbGluayBsYXll ciwgZmFpbHVyZSBkZXRlY3RlZCB3aXRoIE1QTFMgZW5jYXBzdWxhdGlvbiBtYXkgYmUgaW50ZXJw cmV0ZWQgYXMgaW5kaWNhdGlvbiBvZiBhIGRlZmVjdCBpbiBMYXllciAyIGFuZC9vciBMYXllciAz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBHbGVuIEtlbnQgW21haWx0bzpnbGVu LmtlbnRAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTMs IDIwMTYgNjowOCBBTTxicj4NCjxiPlRvOjwvYj4gR3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8 L2I+IEplZmZyZXkgSGFhczsgR3JlZyBNaXJza3k7IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMt bGFnLWlwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9y ZzsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb20pOyBSZXNoYWQgUmFobWFuIChycmFobWFu KTsgcnRnLWJmZEBpZXRmLm9yZzsgcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGlu dGVyZmFjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnb3J5LDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGFyZSB1c2lu ZyBhIHNwZWNpYWwgR0FMIGxhYmVsIGZvciBCRkQgcGFja2V0cy4gVGhpcyBsYWJlbCBleGlzdHMg b25seSBmb3IgdGhlIEJGRCBwYWNrZXRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgY2FuIHlvdSB0aGVuIGNsYWltIGNvbm5l Y3Rpdml0eSBmb3Igb3RoZXIgdHJhZmZpYyB3aGljaCB3aWxsIG5vdCB1c2UgdGhpcyBsYWJlbD88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2xl bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBXZWQsIEFwciAxMywgMjAxNiBhdCA0OjE4IEFNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cD5IaSBKZWZmLDxvOnA+PC9vOnA+PC9wPg0KPHA+dGhhbmsgeW91IGZv ciBhZGRpbmcgbW9yZSBkZXRhaWxzIHRvIHRoZSBkaXNjdXNzaW9ucyBiZWZvcmUgUkZDIDcxMzAu IFdlIGhhdmUgc3VibWl0dGVkIGFub3RoZXIgZHJhZnQgdGhhdCBwcm9wb3NlcyB0byB1c2UgTVBM UyBlbmNhcHN1bGF0aW9uIG9mIEJGRCBjb250cm9sIHBhY2tldHMgb3ZlciBNQy1MQUcgaW50ZXJm YWNlcy4gV291bGQgZ3JlYXRseSBhcHByZWNpYXRlIHJldmlld3MsIHF1ZXN0aW9ucyBhbmQgY29t bWVudHMgb24NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5t aXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzLTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC10YW5t aXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzPC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9w Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IEplZmZyZXkgSGFhcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqaGFhc0Bw ZnJjLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpoYWFzQHBmcmMub3JnPC9hPl0NCjxicj4NClNlbnQ6 IE1vbmRheSwgQXByaWwgMTEsIDIwMTYgMTA6MjQgQU08YnI+DQpUbzogR3JlZyBNaXJza3k8YnI+ DQpDYzogUmVzaGFkIFJhaG1hbiAocnJhaG1hbik7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC10YW5t aXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0K ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBsc0BpZXRmLm9y ZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1wbHMtY2hhaXJzQGlldGYub3JnPC9hPjsgQWxpYSBBdGxhcyAoPGEgaHJlZj0ibWFpbHRv OmFrYXRsYXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWthdGxhc0BnbWFpbC5jb208L2E+ KTsNCjxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRn LWJmZEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KU3Vi amVjdDogUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVy ZmFjZXM8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+R3JlZyw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cD5UaGlzIGlzIG1vcmUgb2YgYSBnZW5lcmFsIGNvbW1lbnQgb24gZGlzY3Vzc2lvbnMgZnJvbSB0 aGUgZGV2ZWxvcG1lbnQgZnJvbSBSRkMgNzEzMCB0aGFuIGFueSBzcGVjaWZpYyBjb21tZW50IG9u IHlvdXIgZHJhZnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+T24gRnJpLCBBcHIgMDgsIDIwMTYgYXQgMTE6NDM6MThBTSAtMDcwMCwgR3JlZyBN aXJza3kgd3JvdGU6PG86cD48L286cD48L3A+DQo8cD4mZ3Q7IHllcywgbGluayBsb2NhbCBtdWx0 aWNhc3QgbWF5IGJlIHVzZWQgaW4gTUMtTEFHIHNjZW5hcmlvLiBUaGUgZHJhZnQgPG86cD48L286 cD48L3A+DQo8cD4mZ3Q7IHN0YXRlcyB0aGF0IGl0IE1BWSBiZSB1c2VkIHdoaWxlIHRoZSBicm9h ZGNhc3QgaGFzIFNIT1VMRCBub3JtYXRpdmUuIDxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyBCdXQg d2UgYXJlIGFsbCBvcGVuIHRvIHRoZSBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD5EdXJpbmcgb3VyIGRpc2N1c3Npb25zIGFjcm9zcyBtdWx0 aXBsZSB2ZW5kb3JzLCBpbmNsdWRpbmcgc29tZSBoYXJkd2FyZSB2ZW5kb3JzLCBpdCB3YXMgZGV0 ZXJtaW5lZCB0aGF0IGF0dGVtcHRzIHRvIGV4ZXJjaXNlIHRoZSBsYXllciAzIG1lY2hhbmlzbXMg d291bGQgdmFyeSBzaWduaWZpY2FudGx5IGFjcm9zcyBpbXBsZW1lbnRhdGlvbnMgZGVwZW5kaW5n IG9uIGhvdyBwYWNrZXRzIHdlcmUgZW5jYXBzdWxhdGVkLiZuYnNwOyBNdWx0aWNhc3QgaW4NCiBw YXJ0aWN1bGFyIHByb3ZpZGVkIHNvbWUgcHJvYmxlbWF0aWMgaXNzdWVzIGZvciB1cyBiZXlvbmQg dGhlIGluaXRpYWwgYm9vdHN0cmFwcGluZyBwaGFzZSBvZiBMQUcgZm9yIEJGRCB3aGVyZWluIHdl IG1pZ2h0IG5vdCBoYXZlIEFSUCBjb21wbGV0ZWQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+TXkgcmVjb21tZW5kYXRpb24gaXMgdG8gcHJvY2Vl ZCB3aXRoIHlvdXIgZHJhZnRzIHdpdGggc2ltaWxhciBjYXV0aW9uLiZuYnNwOyBUcnkgdG8gc3Rh eSBhcyB0cnVlIHRvIHB1cmUgSVAgYXMgcG9zc2libGUgdG8gYmVzdCBpbnN1cmUgdGhlIEwzIGRh dGEgcGF0aHMgYXJlIGV4ZXJjaXNlZCBhY3Jvc3MgaW1wbGVtZW50YXRpb25zIGZyb20gdmFyaW91 cyB2ZW5kb3JzLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4t LSBKZWZmIChzcGVha2luZyBhcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yKTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF11221A4498Feusaamb103erics_-- From nobody Fri Apr 15 20:18:11 2016 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 343C512E080; Fri, 15 Apr 2016 20:18:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-use-case-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160416031810.17418.81750.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 20:18:10 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 03:18:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases Authors : Sam Aldrin Carlos Pignataro Greg Mirsky Nagendra Kumar Filename : draft-ietf-bfd-seamless-use-case-05.txt Pages : 15 Date : 2016-04-15 Abstract: This document describes various use cases for a Seamless Bidirectional Forwarding Detection (S-BFD), and provides requirements such that protocol mechanisms allow for a simplified detection of forwarding failures. These use cases support S-BFD, as a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, accelerating the establishment of a BFD session. S-BFD benefits include quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-use-case-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 17 23:54:24 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BB512D6C0; Sun, 17 Apr 2016 23:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTQ4o74RJIz7; Sun, 17 Apr 2016 23:54:19 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4D012D18B; Sun, 17 Apr 2016 23:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2268; q=dns/txt; s=iport; t=1460962458; x=1462172058; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Mr1V9NBKUaFM9B8Y4WpK1Q+agUwyixYLPt5w6yLOB4w=; b=NSZStBUGAanqOTM/XESV+EgxxeHQ2HXSaH/6Nm1ZsgEShpXeQZBGyO/s U9Yed8zS183X78/rA7quSr0dSFQnGk9c+AnEP0eFbSi368WQ18CEIuJiW s0f9JAmDc6FxbCQwoe6c2HIVkJcltFr45hpPKoAS5/bTPYYuPrSM5ICnG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgDogxRX/4ENJK1bgzhTfQauRItZA?= =?us-ascii?q?Q2BcSKFbAIcgQs4FAEBAQEBAQFlJ4RBAQEBBCMRQw4EAgEIEQQBAQMCIwMCAgI?= =?us-ascii?q?fERQBBgEBBQMCBAESCIgMAxIOqBCLbg2FEgEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RV8hSWES4JBghSCaoJWBY1TigoxAYV3hiGBboFuToQAiFyHTodcAR4BAUKDaGw?= =?us-ascii?q?BiDt+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,501,1454976000"; d="scan'208";a="262549919" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2016 06:54:18 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3I6sIiw021833 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Apr 2016 06:54:18 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Apr 2016 01:54:17 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Mon, 18 Apr 2016 01:54:17 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "rtg-bfd@ietf.org" , "nvo3@ietf.org" Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Index: AQHRl6WciNHVZdJ56Ea6UL/h2rjPOZ+PTmkg Date: Mon, 18 Apr 2016 06:54:16 +0000 Message-ID: <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> In-Reply-To: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.25.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 06:54:20 -0000 SGVsbG8gYWxsLA0KICBUaGUgYXV0aG9ycyByZXF1ZXN0IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCBi ZWxvdy4NClRoYW5rcw0KUHJhc2FkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIA0KU2VudDogU2F0dXJkYXksIEFwcmlsIDE2LCAyMDE2IDExOjMzIEFNDQpUbzogTUFMTElL IE1VRElHT05EQSAobW11ZGlnb24pIDxtbXVkaWdvbkBjaXNjby5jb20+OyBCYXNpbCBTYWppIDxz YmFzaWxAanVuaXBlci5uZXQ+OyBHcmVnIE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tPjsgVmVuZ2FkYSBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKSA8dmVuZ2dvdmlAY2lzY28u Y29tPjsgSnVuaXBlciBOZXR3b3JrcyA8c2FudG9zaHBrQGp1bmlwZXIubmV0PjsgU3VkYXJzYW4g UGFyYWdpcmkgPHNwYXJhZ2lyaUBqdW5pcGVyLm5ldD47IFNhbnRvc2ggUGFsbGFnYXR0aSA8c2Fu dG9zaHBrQGp1bmlwZXIubmV0Pjsgc2FqaWJhc2lsQGdtYWlsLmNvbSA8c2Jhc2lsQGp1bmlwZXIu bmV0Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFsbGFn YXR0aS1iZmQtdnhsYW4tMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNw YWxsYWdhdHRpLWJmZC12eGxhbi0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgVmVuZ2FkYSBQcmFzYWQgR292aW5kYW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuDQpSZXZpc2lvbjoJ MDMNClRpdGxlOgkJQkZEIGZvciBWWExBTg0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wNC0xNQ0KR3Jv dXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOQ0KVVJMOiAgICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zcGFsbGFnYXR0aS1iZmQt dnhsYW4tMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMNCkRp ZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3Bh bGxhZ2F0dGktYmZkLXZ4bGFuLTAzDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgdXNlIG9mIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24NCiAgIChCRkQp IHByb3RvY29sIGZvciBWWExBTiAuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Mon Apr 18 12:33:56 2016 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FC312DCD7; Mon, 18 Apr 2016 12:33:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-multipoint-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160418193352.11083.22635.idtracker@ietfa.amsl.com> Date: Mon, 18 Apr 2016 12:33:52 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 19:33:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection of the IETF. Title : BFD for Multipoint Networks Authors : Dave Katz Dave Ward Santosh Pallagatti Filename : draft-ietf-bfd-multipoint-08.txt Pages : 18 Date : 2016-04-12 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-08 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 Fri Apr 22 14:13:58 2016 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F339A12DD7C; Fri, 22 Apr 2016 14:13:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-use-case-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160422211353.7722.41833.idtracker@ietfa.amsl.com> Date: Fri, 22 Apr 2016 14:13:53 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 21:13:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases Authors : Sam Aldrin Carlos Pignataro Greg Mirsky Nagendra Kumar Filename : draft-ietf-bfd-seamless-use-case-06.txt Pages : 15 Date : 2016-04-22 Abstract: This document describes various use cases for a Seamless Bidirectional Forwarding Detection (S-BFD), and provides requirements such that protocol mechanisms allow for a simplified detection of forwarding failures. These use cases support S-BFD, as a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, accelerating the establishment of a BFD session. S-BFD benefits include quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-use-case-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 28 13:32:21 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BC612D9E7 for ; Thu, 28 Apr 2016 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 vS1hJgOJ8ftS for ; Thu, 28 Apr 2016 13:32:18 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 65B8F12D6F2 for ; Thu, 28 Apr 2016 13:32:18 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by comcast with SMTP id vsZaasT5fp1BevsbhatFTH; Thu, 28 Apr 2016 20:32:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461875537; bh=Y3O99cEnRxisuJO/nSCu6JSD25KarDQWoWsHatoEcL4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=JPrJ4fmMBW4PW+FHstdgxwFII87bqM3Qi5IIigpsL4gBWJohxyYXZ+PcEH85DnYJ2 n2U1yQV8dikt0gorzJEJJaUEkgD/PcnSvX8YYLsjq7HZCvAfcGqPpVLTT5hPjBElq7 rzoI6+x/OtNjfnoeTpC+g/Knzcwh705gqOxSa5AQRu6DNIG4bPNyzpaaD3uwAIzXV4 OC5K67yJ36IRGSRE8ac7cxMcr74GYKp3lE/m7YJjI4qSHigeoXB7guqx23fFaDiwbF JxJ9+HbSf8+gZRwGuFmjkQeXIXdn5bIG+nkkOIHIMlMbONi4B4MBUzcyrqACaq7Qjf iZUgxQVQPe8PQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-06v.sys.comcast.net with comcast id nwYH1s0081nMCLR01wYHy0; Thu, 28 Apr 2016 20:32:17 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u3SKWGFA003033 for ; Thu, 28 Apr 2016 16:32:16 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3SKWGRO003030; Thu, 28 Apr 2016 16:32:16 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: rtg-bfd@ietf.org Subject: Gen-ART Telechat review of draft-ietf-bfd-seamless-use-case-06 Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 28 Apr 2016 16:32:16 -0400 Message-ID: <87twilzd7z.fsf@hobgoblin.ariadne.com> Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 20:32:20 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-bfd-seamless-use-case-06 Reviewer: Dale R. Worley Review Date: 2016-04-28 IESG Telechat date: 2016-05-05 Summary: Ready. Thanks for the thorough reworking of section 2, which makes clear the way that SBFD is organized, and forms the context within which the use cases are described. Also, many nits were fixed. There are still some wording problems, but the RFC Editor can help clean those up. Dale