From nobody Mon Dec 1 00:08:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02D61A1A8D for ; Mon, 1 Dec 2014 00:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 yceRmeZRygLn for ; Mon, 1 Dec 2014 00:08:08 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FA71A0397 for ; Mon, 1 Dec 2014 00:08:08 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 19AE62AA0F; Mon, 1 Dec 2014 08:08:04 +0000 (GMT) Date: Mon, 1 Dec 2014 00:11:20 -0800 From: Marc Binderberger To: Vengada Prasad Govindan (venggovi) Message-ID: <20141201001120931824.3c66eb2f@sniff.de> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D3476B1A4@xmb-rcd-x15.cisco.com> References: <20141126005002.GL20330@pfrc> <20141125234256188865.aafe8a3f@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1A4@xmb-rcd-x15.cisco.com> Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/F9IfMaZ6xils1kIkyYSlqC1F7vM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 08:08:11 -0000 Hello Prasad and authors, okay, I see our differences come from the wording and the interpretation of RFC5884. In section 1 you write ... [...] While Section 4 of [RFC5884] specifies that multiple BFD sessions can be established for a tuple, [...] ... and I do not agree that 5884 make this statement for one LSP. For one FEC and "multiple alternate paths", yes. That's exactly the ambiguity you mention :-) : what does "multiple alternate paths" mean? At the time RFC5884 was written you either had the ECMP decision at the ingress LSR - then you have different , i.e. LSPs - or you had to use explicit LSPs (plural) when the ECMP was somewhere along the path behind the ingress LSR. A bit nitpicking from my side but I don't think your draft clarifies RFC5884, it adds new details (which is perfectly fine, IMHO). Anyway, the procedure you describe in section 2.1 seems okay to me, although you create a new question: [...] Since the BFD local discriminator of either ends cannot change as long as the session is in the UP state, a new discriminator received in the LSP ping unambiguously conveys the intent of the LSR ingress to bootstrap a new BFD session for the FEC specified in the LSP ping. so how do I interpret a new discriminator when one of the other, already existing sessions, is in Down state? My assumption is you want _always_ the interpretation above? You also mention in section 1 [...] is useful in scenarios such as Segment Routing based LSPs or LSPs having Equal-Cost Multipath (ECMP). maybe these scenarios are obvious to you but e.g. for Segment Routing, when would I want multiple BFD sessions for the same ? And when for ECMP? This may be described in use-case documents - could you add references then? For section 2.3 you write: The BFD session MAY be removed in the egress LSR if the BFD session transitions from UP to DOWN. This can be done after the expiry of a configurable timer started after the BFD session state transitions from UP to DOWN at the egress LSR. My guess is what you mean is if a session is long enough in Down state then one can assume it's being "obsolete" and remove it? Or is there a reason to limit the removal procedure to sessions that have been in Up state before? The other method in section 2.3 you describe as The BFD session on the egress LSR MAY be gracefully removed by the ingress LSR by using the BFD diagnostic code AdminDown(7) specified in [RFC5880]. When the ingress LSR wants to gracefully remove a session, it MAY transmit BFD packets containing the diagnostic code AdminDown(7) detectMultiplier number of times. Upon receiving such a packet, the egress LSR MAY remove the BFD session gracefully, without triggering a change of state. Do you mean sending packets with state AdminDown and diagnostic code 7 or do you mean literally that the diagnostic code controls the removal alone, e.g. send detectMultiplier Up packets with diagnostic code 7 and the egress LSR still removes the session? If the latter: this creates more questions, especially if the ingress LSR must keep the current state unchanged or if e.g. a state change on the ingress LSR to AdminDown together with a diagnostic code of AdminDown is something the egress LSR must support as well (in a graceful way, without triggering the client) ? Regards, Marc On Thu, 27 Nov 2014 12:54:53 +0000, Vengada Prasad Govindan (venggovi) wrote: > Hello Marc, > Thank you for the note, please see replies inline marked with GVP1>. I > would be happy to discuss further comments you may have regarding the draft. > Thanks > Prasad > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > Binderberger > Sent: Wednesday, November 26, 2014 1:13 PM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends > December 12, 2014) > > Hello Jeff et al., > > hmm. I'm not against the adoption of this draft as a workgroup draft but - > and I hope I don't step on anybodies toes - the draft seems to be in an > early stage. Nor can I see much of a discussion on this list about the > topic. > > There are for sure some interesting aspects. If enough people consider the > BFD session removal as relevant for RFC5884 then we have a good reason as a > workgroup to move on. > GVP1> The issue of BFD session removal at the egress is one of the issues > that the draft attempts to clarify. But more importantly clarifying the > mechanisms for establishing and maintaining multiple sessions per LSP> is the main motivation. Please see next point as well. > > I have my doubts about the multiple session per as I don't see > how you tackle ECMP without multiple . In other words while section > 2.1 may be a correct procedure for multiple BFD sessions I wonder what > problem you try to solve? Maybe this needs more discussion. > GVP1> There are no new problems that this draft attempts to solve. In > particular, no claim is made to solve the problem of connectivity/ fault > monitoring for ECMP paths. However, the draft provides clarifies the > mechanisms to establish multiple sessions for the already > specified in RFC5884. Some implementations assumed the presence of only one > session per partly due to the notion that discriminators cannot > be changed after a session was established. This draft was an attempt at > clarifying these (mis)understandings. Please note that the concept of > establishing multiple sessions to (possibly) track non-congruent paths was > outlined in RFC5884 itself. > ---snip from RFC5884--- > If there are multiple alternate paths from an ingress LSR to an > egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to > determine each of these alternate paths. A BFD session SHOULD be > established for each alternate path that is discovered. > ---snip from RFC5884--- > > Long story short: while I can see this draft becoming a workgroup draft I > find the poll - well - premature. > > > Regards, Marc > > > > > On Tue, 25 Nov 2014 19:50:02 -0500, Jeffrey Haas wrote: >> Working Group, >> >> Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was >> presented at IETF-91 in Honolulu and was positively received. We'd like to >> ask the Working Group whether we should formally adopt this draft as a >> Working Group item. >> >> Please indicate your support or lack thereof to the mail list by >> December 12, 2014. >> >> Also, please supply feedback to the authors. I believe the perception of >> this document is that it's very nearly complete and thus should have a >> short >> lifetime prior to publication as an RFC. >> >> -- Jeff & Nobo. >> > From nobody Mon Dec 1 00:51:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB2C1A0120 for ; Mon, 1 Dec 2014 00:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 hABenCiw_rNn for ; Mon, 1 Dec 2014 00:51:40 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4217F1A044D for ; Mon, 1 Dec 2014 00:51:40 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 18F9B2AA0F; Mon, 1 Dec 2014 08:51:37 +0000 (GMT) Date: Mon, 1 Dec 2014 00:54:54 -0800 From: Marc Binderberger To: Manav Bhatia Message-ID: <20141201005454102977.238caa76@sniff.de> In-Reply-To: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> Subject: Re: BFD stability follow-up from IETF-91 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/54q6TJehmMmYVyR0yaaexXtuwlM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 08:51:42 -0000 Hello Manav! quite some emails about this topic :-) Let me nevertheless reply to this one: > Now given just the sequence numbers its almost impossible for A to > know whether the issue was at the RX or the TX side. ... or in between (the link/Internet). For the Rx side: you timestamp the packets when the hardware receives them. This stamp could be in some additional "pak header", something that implementations probably have (but yes, it's an implementation detail for me, not an aspect of the BFD packet). Then you timestamp the packet whenever you receive it in your software path, assuming the BFD implementation is in software. You may even have additional time stamps while the packet proceeds through the various functions. You have a rotating buffer for these information and save the last N packet informations of the session when it goes down. Plus unexpected packets like the delayed "Up" packets while you are already in Down. If the sender does something equivalent on the Tx side and also saving N packet information after receiving the first "Down" packet back from the Rx node you have Tx and Rx delta times and you can correlate them based on the sequence number. If N is large enough, e.g. N = 10 or 50 or such, then you should be able to debug the session how it went down. For your example the Rx timestamps would tell that "101", "102" and "103" arrived at your Rx hardware with a delay. If the Tx timestamps show no delay in the Tx path then you would conclude it's the link/Internet in between. If you manage to synchronize the systems down to a few milliseconds then the timestamps would even allow to explicitly measure the link delay, that Tx packet generation happened without a delay etc.. True, this requires you have the information from both, the Rx and the Tx node. This sounds clumsy, compared to the elegant all-in-one-packet but at the end both the Tx and Rx side may need multiple timestamps and some history anyway to debug their system if a problem shows up. Regards, Marc > My claim is that just using sequence numbers may NOT help. > > A BFD session with an interval of 33ms on router A will flap if it > does not see any BFD packet for 100ms. > > Assume that the last seq number that A sees from the remote end is, > say 100. A will bring down the BFD session if it now does not see 101, > 102 and 103 in the next 100ms. > > Further assume that these packets were not seen by A and the session > flaps. However, we get these 3 BFD packets immediately after this flap > -- at 100ms + some_delta. > > Now given just the sequence numbers its almost impossible for A to > know whether the issue was at the RX or the TX side. > > Am i missing something? > > Cheers, Manav > > > On Wed, Nov 26, 2014 at 2:20 PM, Marc Binderberger wrote: >> Hello Manav, >> >>> I believe the work is important and addresses something thats really >>> required (spent too much time debugging why BFD flapped!). >> >> agree :-) we should keep the discussion alive. >> >> >>> side Time stamping would have helped in debugging whether the BFD >>> packet was sent late, or whether the packet was sent on time and also >>> arrived on time but was delayed when passing it up the BFD >>> stack/processor (lay in the RX buffer for tad too long) >> >> well, I can see a point in having the Tx timestamps in the packet mainly >> for >> the purpose of knowing "this" packet was okay/not okay on the Tx side and >> to >> correlate it with your local Rx measurement. >> >> And even this point is less relevant with sequence numbers as this number >> allows the identification of packets and thus the correlation of >> information >> from the Tx and Rx system. >> >> >> Regards, Marc >> >> >> >> >> >> >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: >>> Hi Jeff, >>> >>> I vividly remember the original intent of the stability draft was to >>> help debug BFD failures -- to isolate the issue at the RX or the TX >>> side Time stamping would have helped in debugging whether the BFD >>> packet was sent late, or whether the packet was sent on time and also >>> arrived on time but was delayed when passing it up the BFD >>> stack/processor (lay in the RX buffer for tad too long), etc. But then >>> time stamping came with its own set of issues, and was hence dropped >>> from the original draft. >>> >>> Can the authors send a summary on the list on why time stamping was >>> dropped so that we're all clear on that one. >>> >>> The current proposal does help but is not complete. >>> >>> Assume that the RX end loses a BFD session and learns later that it >>> did eventually receive the missing BFD packets (based on the seq #). >>> How would it know which end was misbehaving? Was it a delay at the TX >>> side, or was it the RX that delayed passing the packets to the BFD >>> process(or). This is usually what we want to debug and i want to >>> understand how this draft with sequence numbers can unequivocally tell >>> me that. >>> >>> I believe the work is important and addresses something thats really >>> required (spent too much time debugging why BFD flapped!). Clearly >>> what would help is putting a small section that describes how we can >>> use the sequence numbers to debug what and where things went wrong. >>> >>> Cheers, Manav >>> >>> >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote: >>>> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in >>>> Honolulu. The slides can be viewed here: >>>> >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx >>>> >>>> To attempt to simplify the presentation, the contentious portion of the >>>> timers were removed from the proposal, leaving only the sequence >>>> numbering >>>> for detecting loss of BFD async packets. >>>> >>>> When the room was polled to see whether the draft should be adopted as a >>>> WG >>>> item, the sense of the room was very quiet. As promised, this is to >>>> inquire >>>> for support for this draft on the WG mailing list to make sure the whole >>>> group has a voice. >>>> >>>> It should be noted that post-meeting discussion on the fate of this draft >>>> noted that BFD authentication code points are plentiful and are available >>>> with expert review. Should the draft authors wish to continue this work >>>> as >>>> Experimental, that is an option. >>>> >>>> -- Jeff >>>> >>> > From nobody Mon Dec 1 01:35:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842441A1AD0 for ; Mon, 1 Dec 2014 01:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 xHsNSKhGEisG for ; Mon, 1 Dec 2014 01:35:28 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D746B1A1AA9 for ; Mon, 1 Dec 2014 01:35:27 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 584162AA0F; Mon, 1 Dec 2014 09:35:25 +0000 (GMT) Date: Mon, 1 Dec 2014 01:38:41 -0800 From: Marc Binderberger To: Manav Bhatia Message-ID: <20141201013841551442.5a9df5b9@sniff.de> In-Reply-To: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> Subject: Re: BFD stability follow-up from IETF-91 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/mxnHNUjnwNgY6Zph3zaZI0LIOCA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 09:35:30 -0000 Hello Manav, > One way to solve this problem is by attaching a debug trailer that > only carries the seq numbers at the *end* of the BFD packet. This > would not be covered in the Length field carried in the BFD header but > would be accounted for in the length carried in the IP header. BFD itself is not related to IP, i.e. there is not always an IP header. Sure, the encapsulating "frame" may provide a length but actually, why not covering the debug trailer with the BFD length? If this is solely for debug purpose than this may work. For simple copying-out into e.g. a packet trace buffer it would be even simpler to have the BFD length covering the trailer. If hardware is supposed to process the trailer information (other than copying out) then it's getting ugly - having fixed position, fixed length extension headers would be preferable for simple access. Another idea is to use the 0x80 bit of the auth type to distinguish between a "normal" authentication header and a "sequence + authentication". Regards, Marc On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > Hi Santosh, > > You could use the crypto sequence numbers carried in the meticulous > cryptographic auth for detecting packet losses. However, this breaks > when you use non-meticulous crypto authentication since the sequence > number is only incremented occasionally there. This i believe is a > deal breaker since i really envision non meticulous mode to be the one > being widely deployed. In fact we were supposed to write a draft on > that and i guess it just fell through the cracks (lemme ping my > co-author on that !) > > One way to solve this problem is by attaching a debug trailer that > only carries the seq numbers at the *end* of the BFD packet. This > would not be covered in the Length field carried in the BFD header but > would be accounted for in the length carried in the IP header. The > concept of attaching a trailer is documented well and is used in the > IGPs. RFC 6506 describes one such trailer for OSPFv3. The catch > however is that this debug trailer will NOT be covered by the BFD > authentication. Is this acceptable to the WG? > > I think the problem of diagnosing a BFD flap becomes all the more > important with BFD authentication turned on since then we have more > points where a delay can be inserted. > > Cheers, Manav > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K wrote: >> Manav, >> This is good question. >> >>> Can the authors add some text on how this debugging mechanism would >>> work if somebody employs BFD authentication? >> >> Right now we have considered without authentication (we are setting A >> bit). We should add some text on how we can use both Auth and de bug TLV. >> Is there any suggestion you have? I will get back to you on this. >> >> >> Thanks >> Santosh P K >> >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach Chen >>>> Sent: Thursday, November 27, 2014 2:13 PM >>>> To: Marc Binderberger >>>> Cc: rtg-bfd@ietf.org >>>> Subject: RE: BFD stability follow-up from IETF-91 >>>> >>>> Hi Marc, >>>> >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>> Sent: Thursday, November 27, 2014 1:43 AM >>>>> To: Mach Chen >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org >>>>> Subject: RE: BFD stability follow-up from IETF-91 >>>>> >>>>> Hello Mach, >>>>> >>>>>> This triggers me think out there should be another solution for >>>>>> getting the Tx and Rx timestamps without encoding the timestamps in >>>>>> the BFD >>>>> packets. >>>>>> For example, the Tx and Rx systems could just save timestamps >>>>>> locally or send them to a centralized entity and then use the >>>>>> sequence numbers to correlate them for further analyzing. >>>>> >>>>> I remember some discussion on NVO3 about how many bits it takes ;-) - >>>>> could you send the links/draft names you are working on to this list? >>>>> May be useful for further discussions. >>>> >>>> Sure, here is the >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- >>> based-ipfpm-framework-02) for the reference. >>>> >>>> But here I want to say is that since we have sequence number, we may not >>> need the marking based solution. Suppose that someone want to monitor >>> the delay of a BFD packet , just record and save the timestamp at the Tx >>> side, >>> which indexed by the sequence number. Similarly, do the same at the Rx >>> side. Then based on the timestamps from both Tx and Rx, and using the >>> sequence number to correlate the timestamps, it can also provide a way to >>> monitor the delay of the BFD packet. >>>> >>>> That means, only if there is sequence number, even if without carrying >>>> the >>> timestamp in the BFD packet, BFD packet delay can be measured. >>>> >>>> Best regards, >>>> Mach >>>> >>>>> >>>>> >>>>> Thanks & Regards, >>>>> Marc >>>>> >>>>> >>>>> >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: >>>>>> Hi Marc and Manav, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >>>>>>> Binderberger >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM >>>>>>> To: Manav Bhatia >>>>>>> Cc: rtg-bfd@ietf.org >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 >>>>>>> >>>>>>> Hello Manav, >>>>>>> >>>>>>>> I believe the work is important and addresses something thats >>>>>>>> really required (spent too much time debugging why BFD flapped!). >>>>>>> >>>>>>> agree :-) we should keep the discussion alive. >>>>>>> >>>>>>> >>>>>>>> side Time stamping would have helped in debugging whether the >>> BFD >>>>>>>> packet was sent late, or whether the packet was sent on time and >>>>>>>> also arrived on time but was delayed when passing it up the BFD >>>>>>>> stack/processor (lay in the RX buffer for tad too long) >>>>>>> >>>>>>> well, I can see a point in having the Tx timestamps in the packet >>>>>>> mainly for the purpose of knowing "this" packet was okay/not okay >>>>>>> on the Tx side and to correlate it with your local Rx measurement. >>>>>> >>>>>> Yes, this is one solution if people think BFD delay is needed. If >>>>>> allow to have Tx timestamps to be carried in the packets, seems it >>>>>> should be no problem to leave a seat for the Rx timestamps as well >>>>>> :-). After all, with both Tx and Rx timestamp, it may simplify the >>>>> implementation. >>>>>> >>>>>>> >>>>>>> And even this point is less relevant with sequence numbers as this >>>>>>> number allows the identification of packets and thus the >>>>>>> correlation of information from the Tx and Rx system. >>>>>> >>>>>> Indeed, the sequence number helps a lot for the correlation between >>>>>> the Tx and Rx system. >>>>>> >>>>>> This triggers me think out there should be another solution for >>>>>> getting the Tx and Rx timestamps without encoding the timestamps in >>>>>> the BFD >>>>> packets. >>>>>> For example, the Tx and Rx systems could just save timestamps >>>>>> locally or send them to a centralized entity and then use the >>>>>> sequence numbers to correlate them for further analyzing. >>>>>> >>>>>> Best regards, >>>>>> Mach >>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, Marc >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: >>>>>>>> Hi Jeff, >>>>>>>> >>>>>>>> I vividly remember the original intent of the stability draft was >>>>>>>> to help debug BFD failures -- to isolate the issue at the RX or >>>>>>>> the TX side Time stamping would have helped in debugging whether >>>>>>>> the BFD packet was sent late, or whether the packet was sent on >>>>>>>> time and also arrived on time but was delayed when passing it up >>>>>>>> the BFD stack/processor (lay in the RX buffer for tad too long), >>>>>>>> etc. But then time stamping came with its own set of issues, and >>>>>>>> was hence dropped from the original draft. >>>>>>>> >>>>>>>> Can the authors send a summary on the list on why time stamping >>>>>>>> was dropped so that we're all clear on that one. >>>>>>>> >>>>>>>> The current proposal does help but is not complete. >>>>>>>> >>>>>>>> Assume that the RX end loses a BFD session and learns later that >>>>>>>> it did eventually receive the missing BFD packets (based on the seq >>> #). >>>>>>>> How would it know which end was misbehaving? Was it a delay at >>>>>>>> the TX side, or was it the RX that delayed passing the packets to >>>>>>>> the BFD process(or). This is usually what we want to debug and i >>>>>>>> want to understand how this draft with sequence numbers can >>>>>>>> unequivocally tell me that. >>>>>>>> >>>>>>>> I believe the work is important and addresses something thats >>>>>>>> really required (spent too much time debugging why BFD flapped!). >>>>>>>> Clearly what would help is putting a small section that describes >>>>>>>> how we can use the sequence numbers to debug what and where >>> things went wrong. >>>>>>>> >>>>>>>> Cheers, Manav >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas >>> wrote: >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during IETF-91 >>>>>>>>> in Honolulu. The slides can be viewed here: >>>>>>>>> >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx >>>>>>>>> >>>>>>>>> To attempt to simplify the presentation, the contentious portion >>>>>>>>> of the timers were removed from the proposal, leaving only the >>>>>>>>> sequence numbering for detecting loss of BFD async packets. >>>>>>>>> >>>>>>>>> When the room was polled to see whether the draft should be >>>>>>>>> adopted as a WG item, the sense of the room was very quiet. As >>>>>>>>> promised, this is to inquire for support for this draft on the >>>>>>>>> WG mailing list to make sure the whole group has a voice. >>>>>>>>> >>>>>>>>> It should be noted that post-meeting discussion on the fate of >>>>>>>>> this draft noted that BFD authentication code points are >>>>>>>>> plentiful and are available with expert review. Should the >>>>>>>>> draft authors wish to continue this work as Experimental, that is an >>> option. >>>>>>>>> >>>>>>>>> -- Jeff >>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From nobody Mon Dec 1 02:25:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC6C1A1B28 for ; Mon, 1 Dec 2014 02:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 OImX6M59YmUn for ; Mon, 1 Dec 2014 02:25:22 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC461A1B1F for ; Mon, 1 Dec 2014 02:25:22 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E41722AA0F; Mon, 1 Dec 2014 10:25:19 +0000 (GMT) Date: Mon, 1 Dec 2014 02:28:35 -0800 From: Marc Binderberger To: Gregory Mirsky Message-ID: <20141201022835893859.2b253881@sniff.de> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B89C865@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <20141128195536.GG1274@pfrc> <7347100B5761DC41A166AC17F22DF1121B89C865@eusaamb103.ericsson.se> Subject: RE: BFD stability follow-up from IETF-91 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zE1UczitAb6BmxJaFIH4vV5uF1k Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 10:25:24 -0000 Hello Gregory, the test of "do we _really_ need this" is always a good idea :-) >> I'm convinced that overloading BFD with performance measurement provisions >> is counter-productive and is inappropriate. BFD is successful because it is so simple. And because we focused on doing this one thing right. Agree with your comment. It does not exclude to think about debug improvements though. And as I claimed in several emails ;-), I think that at least some aspects of the discussion can be covered by "implementation", e.g. local time stamps and some common set of information collected in implementations. I.e. an informal draft could cover this. To identify a packet though, so we can correlate Tx and Rx debug data, I don't see a good alternative to a sequence number yet. Which has the additional benefit that it tells us about packet loss (but for me the main reason is identification). But what is the alternative to introducing an extra field - reusing existing fields instead? (*) Nevertheless, I prefer an "70%" debug solution with small BFD changes to a more complex "100%" solution. My $0.02 Regards, Marc P.S.: well, you know a v2 header would offer more options ;-) but looking at the v1 packet: Local discriminator: some RFCs don't allow this to change (e.g. RFC5884). Otherwise it would be a nice identifier not only of a session but even of a single packet. Required Min Echo RX Interval: my favourite as this field is effectively wasted for async BFD. The top bits translate into very large echo intervals (read: not very useful) and could be used as flags instead. The least significant bits translate into usec values, much faster than any implementation (yet?) and could also be used as flags instead. E.g. values of 0x80000000 - 0xFFFFFFFF could translate into an echo interval of zero and a 31 bit sequence number. But I don't see how to guarantee there won't be any interop problems with older implementations :-) On Sat, 29 Nov 2014 03:17:54 +0000, Gregory Mirsky wrote: > Hi Jeff, > I absolutely agree with continuing discussion and sharing experiences from > real-life deployments and interoperability of BFD in IP and MPLS networks, > single-, multi-hop and over LAG constituents. From that we're learning and > that helps us make our implementations more robust, reliable, and > interoperable. And certainly, where it benefits the community informational > RFCs, like BFD intervals or RFC 7325 MPLS Forwarding Compliance and > Performance Requirements, to document the cases and our recommendations. > But I'm somewhat concerned with anything that targets standard status, even > as optional functionality, even though it is not proven that the problem is > in the standard, not in an implementation. > > Regards, > Greg > > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Friday, November 28, 2014 11:56 AM > To: Gregory Mirsky > Cc: Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org > Subject: Re: BFD stability follow-up from IETF-91 > > [Speaking as an individual contributor...] > > On Fri, Nov 28, 2014 at 07:36:30PM +0000, Gregory Mirsky wrote: >> this is very interesting scenario. I think that if BFD experiences ~30% >> packet loss, then highly likely so are affected other applications. Then >> it is not just BFD issue but condition that should be detected by >> performance measurement method, whether active or passive packet loss >> measurement. >> I'm convinced that overloading BFD with performance measurement provisions >> is counter-productive and is inappropriate. > > My opinion is about halfway between your opinion, Greg. > > I agree that we wish to be very cautious about overloading BFD with > components that are in other OAM mechanisms. Among my desire for such > caution is that IEEE has expressed interest in not having us step on their > technologies and this would create paperwork for the chairs. :-) > > But where I think we diverge slightly comes from experience in helping the > working group and vendors wend their way through implementing BFD for LAG. > During that discussion, it was very clear that depending on the vendor, the > architecture and sometimes specific chipsets that "BFD" lived in very > different pieces of underlying architecture. > > What this means is that trying to do very tight timing things will run into > practical issues in having to figure out what the perspective of the > timings are. Is it some underlying L2? L3? Something between? At what > point do you realize you are measuring contradictory things? > > But similarly, when trying to measure and account for loss, having some > data is useful simply because it helps you determine that the component > that is *responsible for BFD* may be experiencing loss. Depending on your > architecture, this may be the underlying layer-1, layer-2 or something else. > In such cases, the lower-layer OAM is better to troubleshoot. But in cases > where your lower-layer OAM doesn't indicate the loss, you still need to > understand that there is BFD-level loss. > > I encourage participants in this discussion to remember this detail: We are > trying to help measure BFD loss. Trying to read too much detail into what > that means outside of BFD may lead you to erroneous conclusions depending > on a given implementation. > > Thus, consider what is best for BFD. > > -- Jeff > From nobody Mon Dec 1 04:44:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED5A1A1AD0 for ; Mon, 1 Dec 2014 04:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4lfmoYJXF144 for ; Mon, 1 Dec 2014 04:44:27 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with SMTP id B56091A0398 for ; Mon, 1 Dec 2014 04:44:26 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app08-12008 (RichMail) with SMTP id 2ee8547c62a7aad-53fc3; Mon, 01 Dec 2014 20:44:23 +0800 (CST) X-RM-TRANSID: 2ee8547c62a7aad-53fc3 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.54.42]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea547c62a6bdd-c5e6c; Mon, 01 Dec 2014 20:44:23 +0800 (CST) X-RM-TRANSID: 2eea547c62a6bdd-c5e6c From: "Fan, Peng" To: "'Gregory Mirsky'" , "'MALLIK MUDIGONDA \(mmudigon\)'" , References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> Subject: RE: BFD stability follow-up from IETF-91 Date: Mon, 1 Dec 2014 20:43:51 +0800 Message-ID: <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01D00DA7.855C42A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKBPMpCL0+8d4y34TY+mEve1uhqkgK7LgWhAWSMorMCsCwT1Zrhz+Uw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bnbhImdujYiibF-BoSmhRUpKwbk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 12:44:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A1_01D00DA7.855C42A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Gregory, I was just giving an example :) Application traffic usually cannot stand small packet loss, not to say 30% loss. I am actually asking for a debug function that could give us some useful hints of poor connection with small protocol change, besides the basic connectivity information. If it measures something, it measures packets of BFD itself. So I don't expect it to be considered as a performance measurement tool. Best regards, Peng From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, November 29, 2014 3:37 AM To: Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Peng, this is very interesting scenario. I think that if BFD experiences ~30% packet loss, then highly likely so are affected other applications. Then it is not just BFD issue but condition that should be detected by performance measurement method, whether active or passive packet loss measurement. I'm convinced that overloading BFD with performance measurement provisions is counter-productive and is inappropriate. Regards, Greg From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Fan, Peng Sent: Friday, November 28, 2014 4:34 AM To: 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Mallik, Exactly. Packets may be experiencing slight loss, but the link can hardly be regarded as connected. More importantly, the experience of upper-level applications can be degraded severely (e.g. TCP traffic is not able to go fast in face of even small continuous loss). But what if one BFD frame is lost every three frames? Then the loss rate is 30% on average, which is already a very severe value. Best regards, Peng From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Friday, November 28, 2014 7:53 PM To: Fan, Peng; rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Peng, If the BFD packets are lost, doesn't the BFD session go DOWN? Are you saying that packet loss is not big enough to make BFD session go DOWN? Thanks Regards Mallik From: , Peng Date: Friday, 28 November 2014 4:20 pm To: "rtg-bfd@ietf.org" Subject: RE: BFD stability follow-up from IETF-91 Hi Jeff, all, I have been following this stability extension from the beginning, and as an operator I would like to express that this draft enables the "advanced feature" we desire for BFD to provide additional useful information that helps operators understand network issues. A relevant use case is detecting lossy or "quasi-disconnected" links or member LAG links. An example of such situation we experienced was a loosely connected fiber link resulting in continuous, small amount of packet loss. BFD could get the information of lost BFD frames on such unstable link, and probably report when a target level is reached, say a certain number of frames are lost over a period or among a total number of frames. Best regards, Peng ------=_NextPart_000_00A1_01D00DA7.855C42A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gregory,

 

I was just giving an example :) Application traffic usually cannot = stand small packet loss, not to say 30% loss.

 

I am actually asking for a debug function that could give us some = useful hints of poor connection with small protocol change, besides the = basic connectivity information. If it measures something, it measures = packets of BFD itself. So I don’t expect it to be considered as a = performance measurement tool.

 

Best regards,

Peng

 

From:= Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Saturday, = November 29, 2014 3:37 AM
To: Fan, Peng; 'MALLIK MUDIGONDA = (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: BFD stability = follow-up from IETF-91

 

Hi Peng,

this is very interesting scenario. I think that if BFD experiences = ~30% packet loss, then highly likely so are affected other applications. = Then it is not just BFD issue but condition that should be = detected  by performance measurement method, whether active or = passive packet loss measurement.

I’m convinced that overloading BFD with performance measurement = provisions is counter-productive and is inappropriate. =

 

           &nbs= p;    Regards,

           &nbs= p;            = ;        Greg

 

From:= Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Fan, = Peng
Sent: Friday, November 28, 2014 4:34 AM
To: = 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: = BFD stability follow-up from IETF-91

 

Hi Mallik,

 

Exactly. Packets may be experiencing slight loss, but the link can = hardly be regarded as connected. More importantly, the experience of = upper-level applications can be degraded severely (e.g. TCP traffic is = not able to go fast in face of even small continuous loss). But what if = one BFD frame is lost every three frames? Then the loss rate is 30% on = average, which is already a very severe value.

 

Best regards,

Peng

 

From:= MALLIK = MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] =
Sent: Friday, November 28, 2014 7:53 PM
To: Fan, = Peng; rtg-bfd@ietf.org
Subject: = Re: BFD stability follow-up from = IETF-91

 

H= i Peng,

<= o:p> 

I= f the BFD packets are lost, doesn’t the BFD session go DOWN? Are = you saying that packet loss is not big enough to make BFD session go = DOWN?

<= o:p> 

T= hanks

<= o:p> 

R= egards

M= allik

<= o:p> 

From: <Fan>, Peng <fanpeng@chinamobile.com>Date: Friday, 28 November 2014 4:20 pm
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: = RE: BFD stability follow-up from = IETF-91

<= o:p> 

H= i Jeff, all,

<= o:p> 

I= have been following this stability extension from the beginning, and as = an

o= perator I would like to express that this draft enables the = "advanced

f= eature" we desire for BFD to provide additional useful information = that

h= elps operators understand network issues. A relevant use case is = detecting

l= ossy or "quasi-disconnected" links or member LAG links. An = example of such

s= ituation we experienced was a loosely connected fiber link resulting = in

c= ontinuous, small amount of packet loss. BFD could get the information = of

l= ost BFD frames on such unstable link, and probably report when a = target

l= evel is reached, say a certain number of frames are lost over a period = or

a= mong a total number of frames.

<= o:p> 

B= est regards,

P= eng

<= o:p> 

<= o:p> 

<= o:p> 

<= o:p> 

------=_NextPart_000_00A1_01D00DA7.855C42A0-- From nobody Mon Dec 1 09:53:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1B51A1BCF for ; Mon, 1 Dec 2014 09:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 K1hxvVb15CNP for ; Mon, 1 Dec 2014 09:53:28 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 3FD341A1A7E for ; Mon, 1 Dec 2014 09:53:28 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-7b-547c579b6e3f Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 81.C1.03307.B975C745; Mon, 1 Dec 2014 12:57:16 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 12:38:07 -0500 From: Gregory Mirsky To: "Fan, Peng" , "'MALLIK MUDIGONDA (mmudigon)'" , "rtg-bfd@ietf.org" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAjSUAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAF9PggASh4oD///wSUA== Date: Mon, 1 Dec 2014 17:38:06 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> In-Reply-To: <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> 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_7347100B5761DC41A166AC17F22DF1121B8A87E6eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPuO6c8JoQg79NPBbrG16wWxx5dYzZ 4vOfbYwOzB7zLixk85jyeyOrx5IlP5kCmKO4bFJSczLLUov07RK4Mg73KBfsPc1YsfdTO3sD 44ZtjF2MnBwSAiYSd2etZoWwxSQu3FvP1sXIxSEkcIRRYu/CU0wQzjJGiRkTn7GBVLEJGEm8 2NjDDpIQEehglFj6cikzSEJYwFBiVfdidhBbBKjo2Iy5UHadxPfZZ8FsFgEViVU/JrB0MXJw 8Ar4SmyYkwOxoJ9J4uT2N2ALOAXsJE5cfwtmMwKd9P3UGiYQm1lAXOLWk/lMEKcKSCzZc54Z whaVePn4H9QLShKTlp5jhajPl9i/9ybYXl4BQYmTM5+wTGAUmYVk1CwkZbOQlEHEdSQW7P7E BmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxalluelGBpsYgXF1TIJNdwfjnpeWhxgFOBiVeHgN MqtDhFgTy4orcw8xSnOwKInzzqqdFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsdzj3co+ HqNmm6Jop7kKPwNCUg60Xt043W3aDck7HE7FrziW5C/MEHN0agrcukve9I9/pfqCvw+sCrW3 r87+wdZedfNe0oqi6UxnZwq+fnJbUm7+PEOBiYa7TIr5WVmE1mwtPVTdeycvNjeoxqo8pCjl SHDTK+tyq0ee3wN+nd/2LnZf1D8+JZbijERDLeai4kQATg2Gn4wCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/3pkzHR43poIfucTk7pRIP7btbJE X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 17:53:32 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8A87E6eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peng, and still, you're looking for a tool to measure BFD performance. Then you'l= l be looking for a tool to verify the BFD performance measurement, and on, = and on. Operators do need complete set of FCAPS tools, including performanc= e measurement. Note that passive performance measurement through marking me= thod that Mach Chen referred to can monitor BFD flow(s) and be used to do L= oss and/or Delay Measurement. And active Synthetic Loss Measurement may sim= ulate flow of small packets as well as relatively large packets. And the sa= me goes for active measurement method of Delay Measurement. I like Swiss Ar= my knives but let us not turn BFD into one. Regards, Greg From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Monday, December 01, 2014 4:44 AM To: Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Gregory, I was just giving an example :) Application traffic usually cannot stand sm= all packet loss, not to say 30% loss. I am actually asking for a debug function that could give us some useful hi= nts of poor connection with small protocol change, besides the basic connec= tivity information. If it measures something, it measures packets of BFD it= self. So I don't expect it to be considered as a performance measurement to= ol. Best regards, Peng From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, November 29, 2014 3:37 AM To: Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Peng, this is very interesting scenario. I think that if BFD experiences ~30% pac= ket loss, then highly likely so are affected other applications. Then it is= not just BFD issue but condition that should be detected by performance m= easurement method, whether active or passive packet loss measurement. I'm convinced that overloading BFD with performance measurement provisions = is counter-productive and is inappropriate. Regards, Greg From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Fan, Peng Sent: Friday, November 28, 2014 4:34 AM To: 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Mallik, Exactly. Packets may be experiencing slight loss, but the link can hardly b= e regarded as connected. More importantly, the experience of upper-level ap= plications can be degraded severely (e.g. TCP traffic is not able to go fas= t in face of even small continuous loss). But what if one BFD frame is lost= every three frames? Then the loss rate is 30% on average, which is already= a very severe value. Best regards, Peng From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Friday, November 28, 2014 7:53 PM To: Fan, Peng; rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Peng, If the BFD packets are lost, doesn't the BFD session go DOWN? Are you sayin= g that packet loss is not big enough to make BFD session go DOWN? Thanks Regards Mallik From: , Peng > Date: Friday, 28 November 2014 4:20 pm To: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Jeff, all, I have been following this stability extension from the beginning, and as a= n operator I would like to express that this draft enables the "advanced feature" we desire for BFD to provide additional useful information that helps operators understand network issues. A relevant use case is detecting lossy or "quasi-disconnected" links or member LAG links. An example of such situation we experienced was a loosely connected fiber link resulting in continuous, small amount of packet loss. BFD could get the information of lost BFD frames on such unstable link, and probably report when a target level is reached, say a certain number of frames are lost over a period or among a total number of frames. Best regards, Peng --_000_7347100B5761DC41A166AC17F22DF1121B8A87E6eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peng,

and still, you’re l= ooking for a tool to measure BFD performance. Then you’ll be looking = for a tool to verify the BFD performance measurement, and on, and on. Operators do need complete set of FCAPS tools, including performance measu= rement. Note that passive performance measurement through marking method th= at Mach Chen referred to can monitor BFD flow(s) and be used to do Loss and= /or Delay Measurement. And active Synthetic Loss Measurement may simulate flow of small packets as well as r= elatively large packets. And the same goes for active measurement method of= Delay Measurement. I like Swiss Army knives but let us not turn BFD into o= ne.

 <= /p>

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

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

 <= /p>

From: Fan, Pen= g [mailto:fanpeng@chinamobile.com]
Sent: Monday, December 01, 2014 4:44 AM
To: Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org<= br> Subject: RE: BFD stability follow-up from IETF-91<= /p>

 

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Saturday, November 29, 2014 3:37 AM
To: Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up from IETF-91<= /p>

&nbs= p;

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Fan, Peng
Sent: Friday, November 28, 2014 4:34 AM
To: 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up from IETF-91<= /p>

&nbs= p;

From: MALLIK MUDIGONDA (mmudigon) [= mailto:mmudigon@cisco.com]
Sent: Friday, November 28, 2014 7:53 PM
To: Fan, Peng; rtg-bfd@ietf.org<= /a>
Subject: Re: BFD stability follow-up from IETF-91<= /p>

&nbs= p;

Hi= Peng,

 

If= the BFD packets are lost, doesn’t the BFD session go DOWN? Are you s= aying that packet loss is not big enough to make BFD session go DOWN?

 

Th= anks

 

Re= gards

Ma= llik

 

From: <Fan>,= Peng <fanpeng@chinamobile.co= m>
Date: Friday, 28 November 2014 4:20 pm
To: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91<= /p>

 

Hi= Jeff, all,

 

I = have been following this stability extension from the beginning, and as an<= o:p>

op= erator I would like to express that this draft enables the "advanced

fe= ature" we desire for BFD to provide additional useful information that=

he= lps operators understand network issues. A relevant use case is detecting

lo= ssy or "quasi-disconnected" links or member LAG links. An example= of such

si= tuation we experienced was a loosely connected fiber link resulting in=

co= ntinuous, small amount of packet loss. BFD could get the information of

lo= st BFD frames on such unstable link, and probably report when a target=

le= vel is reached, say a certain number of frames are lost over a period or

am= ong a total number of frames.

 

Be= st regards,

Pe= ng

 

 

 

 

--_000_7347100B5761DC41A166AC17F22DF1121B8A87E6eusaamb103erics_-- From nobody Tue Dec 2 02:06:31 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233351A1A57 for ; Tue, 2 Dec 2014 02:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 WvL6ncS3l3PE for ; Tue, 2 Dec 2014 02:06:26 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE821A1A58 for ; Tue, 2 Dec 2014 02:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9573; q=dns/txt; s=iport; t=1417514787; x=1418724387; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Jlrwr6/meDu+3MHgLneibgMw/eANdbN6ddMHdxa/xDA=; b=kR97FKenZLEt4NlJCJR0oHwhiDmjK0L86/+wpEFDMBs7m+7FjYWRG68U /Dp4bF9iMbdXNo6xF8pTnUjgSmq06LHybV3hPapstyhw3mrq2n9jkkWNP zcrv05xw0r81BV1/UaQhqa1uTtbqokQBBgQVgGMzPxmrvpOu3XZR+THEi 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKOOfVStJA2H/2dsb2JhbABbgwaBKQTEYohFAoEeFgEBAQEBfYQCAQEBBCcTOgUMBAIBCBEEAQEBChQJBzIUCQgCBA4FCIg41UABAQEBAQEBAQEBAQEBAQEBAQEBAQEXjSSCdAYBAR4GKwcGgyOBHwEEkGGMUYM4hys1hFuEAoI3gURvgQUIFyKBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="101842996" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP; 02 Dec 2014 10:06:26 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sB2A6Pme023019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 10:06:25 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 04:06:25 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Marc Binderberger Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Topic: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Index: AQHQCRLwLqZvDFdkwECOCg+XQQBjhZxy654AgAGBgECABmIYAIAAyJPg Date: Tue, 2 Dec 2014 10:06:24 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3476ED15@xmb-rcd-x15.cisco.com> References: <20141126005002.GL20330@pfrc> <20141125234256188865.aafe8a3f@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1A4@xmb-rcd-x15.cisco.com> <20141201001120931824.3c66eb2f@sniff.de> In-Reply-To: <20141201001120931824.3c66eb2f@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zVT_HTjhLuqYv1qxNSGX7O4tZbY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 10:06:29 -0000 -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 Sent: Monday, December 01, 2014 1:41 PM To: Vengada Prasad Govindan (venggovi) Cc: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends= December 12, 2014) Hello Prasad and authors, okay, I see our differences come from the wording and the interpretation of= RFC5884. In section 1 you write ... [...] While Section 4 of [RFC5884] specifies that multiple BFD sessions can be established for a tuple, [...] ... and I do not agree that 5884 make this statement for one LSP. For one F= EC and "multiple alternate paths", yes. That's exactly the ambiguity you me= ntion :-) : what does "multiple alternate paths" mean? At the time RFC5884 was w= ritten you either had the ECMP decision at the ingress LSR - then you have = different , i.e. LSPs - or you had to use explicit= LSPs (plural) when the ECMP was somewhere along the path behind the ingres= s LSR. A bit nitpicking from my side but I don't think your draft clarifies RFC588= 4, it adds new details (which is perfectly fine, IMHO). Anyway, the procedure you describe in section 2.1 seems okay to me, althoug= h=20 you create a new question: [...] Since the BFD local discriminator of either ends cannot change as long as the session is in the UP state, a new discriminator received in the LSP ping unambiguously conveys the intent of the LSR ingress to bootstrap a new BFD session for the FEC specified in the LSP ping. so how do I interpret a new discriminator when one of the other, already=20 existing sessions, is in Down state? My assumption is you want _always_ th= e=20 interpretation above? GVP1> Agreed, the behavior need not be influenced by the state of the exist= ing BFD session(s). The text in this section has scope for improvement. The= egress node needs some freedom in accepting new session requests. It could= apply policy to limit resources (e.g. pps budget, memory etc) being alloca= ted to new session request. While the notion of applying the policy could b= e a local matter, the behavior of the egress LSR needs to defined for cases= where the new discriminator request is not accepted. Could it simply drop = the LSP Echo request until it is ready to create the BFD session? (I assume= that the ingress LSR will continue re-transmission of the LSP ping for the= new session until it becomes successful or give-up creating the BFD sessio= n after a given number of retries). Comments are welcome about this aspect.= =20 You also mention in section 1 [...] is useful in scenarios such as Segment Routing based LSPs or LSPs having Equal-Cost Multipath (ECMP). maybe these scenarios are obvious to you but e.g. for Segment Routing, when= =20 would I want multiple BFD sessions for the same ? And when for= =20 ECMP? This may be described in use-case documents - could you add referenc= es=20 then? GVP1> I do not know if this draft is required to establish the need for mul= tiple sessions per since the base RFC5884 already saw the need f= or multiple sessions for the . But, I will try and find reference= s as you suggest.=20 For section 2.3 you write: The BFD session MAY be removed in the egress LSR if the BFD session transitions from UP to DOWN. This can be done after the expiry of a configurable timer started after the BFD session state transitions from UP to DOWN at the egress LSR. My guess is what you mean is if a session is long enough in Down state then= =20 one can assume it's being "obsolete" and remove it? Or is there a reason t= o=20 limit the removal procedure to sessions that have been in Up state before? GVP> The intent here is to conserve resources by maintaining the optimal nu= mber of BFD sessions. Sessions that have transitioned from UP->DOWN and rem= ained in DOWN are candidates for removal. Sessions that have always remaine= d DOWN for a long enough time are also candidates for removal. However the = latter is currently an open item (please see Sec 2.3, Ed Note). The other method in section 2.3 you describe as The BFD session on the egress LSR MAY be gracefully removed by the ingress LSR by using the BFD diagnostic code AdminDown(7) specified in [RFC5880]. When the ingress LSR wants to gracefully remove a session, it MAY transmit BFD packets containing the diagnostic code AdminDown(7) detectMultiplier number of times. Upon receiving such a packet, the egress LSR MAY remove the BFD session gracefully, without triggering a change of state. Do you mean sending packets with state AdminDown and diagnostic code 7 or d= o=20 you mean literally that the diagnostic code controls the removal alone, e.g= .=20 send detectMultiplier Up packets with diagnostic code 7 and the egress LSR= =20 still removes the session? GVP1> We do not intend to redefine states or diagnostic codes specified in = RFC 5880. The draft proposes a method of gracefully removing the BFD sessio= ns at the egress (from the LSR ingress) by sending packets with diag code 7= , State=3DDown. If you think this text needs clarification or do not agree = with the proposal, please let me know. =20 If the latter: this creates more questions, especially if the ingress LSR=20 must keep the current state unchanged or if e.g. a state change on the=20 ingress LSR to AdminDown together with a diagnostic code of AdminDown is=20 something the egress LSR must support as well (in a graceful way, without=20 triggering the client) ? Regards, Marc On Thu, 27 Nov 2014 12:54:53 +0000, Vengada Prasad Govindan (venggovi) wrot= e: > Hello Marc, > Thank you for the note, please see replies inline marked with GVP1>. I=20 > would be happy to discuss further comments you may have regarding the dra= ft. > Thanks > Prasad >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc=20 > Binderberger > Sent: Wednesday, November 26, 2014 1:13 PM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (en= ds=20 > December 12, 2014) >=20 > Hello Jeff et al., >=20 > hmm. I'm not against the adoption of this draft as a workgroup draft but = -=20 > and I hope I don't step on anybodies toes - the draft seems to be in an=20 > early stage. Nor can I see much of a discussion on this list about the=20 > topic. >=20 > There are for sure some interesting aspects. If enough people consider th= e=20 > BFD session removal as relevant for RFC5884 then we have a good reason as= a=20 > workgroup to move on. > GVP1> The issue of BFD session removal at the egress is one of the issues= =20 > that the draft attempts to clarify. But more importantly clarifying the=20 > mechanisms for establishing and maintaining multiple sessions per LSP> is the main motivation. Please see next point as well. >=20 > I have my doubts about the multiple session per as I don't se= e=20 > how you tackle ECMP without multiple . In other words while section= =20 > 2.1 may be a correct procedure for multiple BFD sessions I wonder what=20 > problem you try to solve? Maybe this needs more discussion. > GVP1> There are no new problems that this draft attempts to solve. In=20 > particular, no claim is made to solve the problem of connectivity/ fault= =20 > monitoring for ECMP paths. However, the draft provides clarifies the=20 > mechanisms to establish multiple sessions for the already=20 > specified in RFC5884. Some implementations assumed the presence of only o= ne=20 > session per partly due to the notion that discriminators canno= t=20 > be changed after a session was established. This draft was an attempt at= =20 > clarifying these (mis)understandings. Please note that the concept of=20 > establishing multiple sessions to (possibly) track non-congruent paths wa= s=20 > outlined in RFC5884 itself.=20 > ---snip from RFC5884--- > If there are multiple alternate paths from an ingress LSR to an > egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to > determine each of these alternate paths. A BFD session SHOULD be > established for each alternate path that is discovered. > ---snip from RFC5884--- >=20 > Long story short: while I can see this draft becoming a workgroup draft I= =20 > find the poll - well - premature. >=20 >=20 > Regards, Marc > =20 >=20 >=20 >=20 > On Tue, 25 Nov 2014 19:50:02 -0500, Jeffrey Haas wrote: >> Working Group, >>=20 >> Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was >> presented at IETF-91 in Honolulu and was positively received. We'd like= to >> ask the Working Group whether we should formally adopt this draft as a >> Working Group item. >>=20 >> Please indicate your support or lack thereof to the mail list by=20 >> December 12, 2014. =20 >>=20 >> Also, please supply feedback to the authors. I believe the perception o= f >> this document is that it's very nearly complete and thus should have a=20 >> short >> lifetime prior to publication as an RFC. >>=20 >> -- Jeff & Nobo. >>=20 >=20 From nobody Tue Dec 2 02:07:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838D31A1A3B for ; Tue, 2 Dec 2014 02:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 8w7uCqm_-iuT for ; Tue, 2 Dec 2014 02:07:08 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524081A1A4F for ; Tue, 2 Dec 2014 02:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9936; q=dns/txt; s=iport; t=1417514828; x=1418724428; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=AUhd4k+7nKz1ws4wzGOhwe2MAKoFXhU/++WjG1Cn1ys=; b=PQuaj3hYnx5xRF6Ef9d9mZzmNXw+Xub4d2wnZicqXjRan75sgZRmP+ss T40e944mr82ZNDTLErxkzfvP2gMAihaYj+xH3uz3PS53AIFbBtZysNOXq z9DvCFbftgvifwW5t4nMCeyCPp8PkD2YnewLue/ct82zemltl1KrDVd5j o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKOOfVStJA2F/2dsb2JhbABbgwaBKQTEYohFAoEeFgEBAQEBfYQCAQEBBCcTOgUMBAIBCBEEAQEBChQJBzIUCQgCBA4FCIg41UABAQEBAQEBAQEBAQEBAQEBAQEBAQEXjSSCdAYBAR4GKw2DI4EfBZBhjFGDOIcrNYRbhAKCN4FEb4EFCBcigQEBAQE X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="101829655" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 02 Dec 2014 10:07:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sB2A77FO005440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 10:07:07 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 04:07:07 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Marc Binderberger Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Topic: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Index: AQHQCRLwLqZvDFdkwECOCg+XQQBjhZxy654AgAGBgECABmIYAIAAyJPggACFYDA= Date: Tue, 2 Dec 2014 10:07:06 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3476ED27@xmb-rcd-x15.cisco.com> References: <20141126005002.GL20330@pfrc> <20141125234256188865.aafe8a3f@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1A4@xmb-rcd-x15.cisco.com> <20141201001120931824.3c66eb2f@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4b-TCNf8IIQQH55EEzY4AshIvsU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 10:07:11 -0000 Hello Marc, Sorry for pressing the send button early, please find a few replies inlin= e with GVP1> Thanks Prasad -----Original Message----- From: Vengada Prasad Govindan (venggovi)=20 Sent: Tuesday, December 02, 2014 3:36 PM To: 'Marc Binderberger' Cc: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends= December 12, 2014) -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Monday, December 01, 2014 1:41 PM To: Vengada Prasad Govindan (venggovi) Cc: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends= December 12, 2014) Hello Prasad and authors, okay, I see our differences come from the wording and the interpretation of= RFC5884. In section 1 you write ... [...] While Section 4 of [RFC5884] specifies that multiple BFD sessions can be established for a tuple, [...] ... and I do not agree that 5884 make this statement for one LSP. For one F= EC and "multiple alternate paths", yes. That's exactly the ambiguity you me= ntion :-) : what does "multiple alternate paths" mean? At the time RFC5884 was w= ritten you either had the ECMP decision at the ingress LSR - then you have = different , i.e. LSPs - or you had to use explicit= LSPs (plural) when the ECMP was somewhere along the path behind the ingres= s LSR. A bit nitpicking from my side but I don't think your draft clarifies RFC588= 4, it adds new details (which is perfectly fine, IMHO). Anyway, the procedure you describe in section 2.1 seems okay to me, althoug= h you create a new question: [...] Since the BFD local discriminator of either ends cannot change as long as the session is in the UP state, a new discriminator received in the LSP ping unambiguously conveys the intent of the LSR ingress to bootstrap a new BFD session for the FEC specified in the LSP ping. so how do I interpret a new discriminator when one of the other, already ex= isting sessions, is in Down state? My assumption is you want _always_ the = interpretation above? GVP1> Agreed, the behavior need not be influenced by the state of the exist= ing BFD session(s). The text in this section has scope for improvement. The= egress node needs some freedom in accepting new session requests. It could= apply policy to limit resources (e.g. pps budget, memory etc) being alloca= ted to new session request. While the notion of applying the policy could b= e a local matter, the behavior of the egress LSR needs to defined for cases= where the new discriminator request is not accepted. Could it simply drop = the LSP Echo request until it is ready to create the BFD session? (I assume= that the ingress LSR will continue re-transmission of the LSP ping for the= new session until it becomes successful or give-up creating the BFD sessio= n after a given number of retries). Comments are welcome about this aspect.= =20 You also mention in section 1 [...] is useful in scenarios such as Segment Routing based LSPs or LSPs having Equal-Cost Multipath (ECMP). maybe these scenarios are obvious to you but e.g. for Segment Routing, when= would I want multiple BFD sessions for the same ? And when for= ECMP? This may be described in use-case documents - could you add referen= ces then? GVP1> I do not know if this draft is required to establish the need for mul= tiple sessions per since the base RFC5884 already saw the need f= or multiple sessions for the . But, I will try and find reference= s as you suggest.=20 For section 2.3 you write: The BFD session MAY be removed in the egress LSR if the BFD session transitions from UP to DOWN. This can be done after the expiry of a configurable timer started after the BFD session state transitions from UP to DOWN at the egress LSR. My guess is what you mean is if a session is long enough in Down state then= one can assume it's being "obsolete" and remove it? Or is there a reason = to limit the removal procedure to sessions that have been in Up state befor= e? GVP> The intent here is to conserve resources by maintaining the optimal nu= mber of BFD sessions. Sessions that have transitioned from UP->DOWN and rem= ained in DOWN are candidates for removal. Sessions that have always remaine= d DOWN for a long enough time are also candidates for removal. However the = latter is currently an open item (please see Sec 2.3, Ed Note). The other method in section 2.3 you describe as The BFD session on the egress LSR MAY be gracefully removed by the ingress LSR by using the BFD diagnostic code AdminDown(7) specified in [RFC5880]. When the ingress LSR wants to gracefully remove a session, it MAY transmit BFD packets containing the diagnostic code AdminDown(7) detectMultiplier number of times. Upon receiving such a packet, the egress LSR MAY remove the BFD session gracefully, without triggering a change of state. Do you mean sending packets with state AdminDown and diagnostic code 7 or d= o you mean literally that the diagnostic code controls the removal alone, e= .g.=20 send detectMultiplier Up packets with diagnostic code 7 and the egress LSR = still removes the session? GVP1> We do not intend to redefine states or diagnostic codes specified in = RFC 5880. The draft proposes a method of gracefully removing the BFD sessio= ns at the egress (from the LSR ingress) by sending packets with diag code 7= , State=3DDown. If you think this text needs clarification or do not agree = with the proposal, please let me know. =20 If the latter: this creates more questions, especially if the ingress LSR=20 must keep the current state unchanged or if e.g. a state change on the=20 ingress LSR to AdminDown together with a diagnostic code of AdminDown is=20 something the egress LSR must support as well (in a graceful way, without=20 triggering the client) ? Regards, Marc On Thu, 27 Nov 2014 12:54:53 +0000, Vengada Prasad Govindan (venggovi) wrot= e: > Hello Marc, > Thank you for the note, please see replies inline marked with GVP1>. I=20 > would be happy to discuss further comments you may have regarding the dra= ft. > Thanks > Prasad >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc=20 > Binderberger > Sent: Wednesday, November 26, 2014 1:13 PM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (en= ds=20 > December 12, 2014) >=20 > Hello Jeff et al., >=20 > hmm. I'm not against the adoption of this draft as a workgroup draft but = -=20 > and I hope I don't step on anybodies toes - the draft seems to be in an=20 > early stage. Nor can I see much of a discussion on this list about the=20 > topic. >=20 > There are for sure some interesting aspects. If enough people consider th= e=20 > BFD session removal as relevant for RFC5884 then we have a good reason as= a=20 > workgroup to move on. > GVP1> The issue of BFD session removal at the egress is one of the issues= =20 > that the draft attempts to clarify. But more importantly clarifying the=20 > mechanisms for establishing and maintaining multiple sessions per LSP> is the main motivation. Please see next point as well. >=20 > I have my doubts about the multiple session per as I don't se= e=20 > how you tackle ECMP without multiple . In other words while section= =20 > 2.1 may be a correct procedure for multiple BFD sessions I wonder what=20 > problem you try to solve? Maybe this needs more discussion. > GVP1> There are no new problems that this draft attempts to solve. In=20 > particular, no claim is made to solve the problem of connectivity/ fault= =20 > monitoring for ECMP paths. However, the draft provides clarifies the=20 > mechanisms to establish multiple sessions for the already=20 > specified in RFC5884. Some implementations assumed the presence of only o= ne=20 > session per partly due to the notion that discriminators canno= t=20 > be changed after a session was established. This draft was an attempt at= =20 > clarifying these (mis)understandings. Please note that the concept of=20 > establishing multiple sessions to (possibly) track non-congruent paths wa= s=20 > outlined in RFC5884 itself.=20 > ---snip from RFC5884--- > If there are multiple alternate paths from an ingress LSR to an > egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to > determine each of these alternate paths. A BFD session SHOULD be > established for each alternate path that is discovered. > ---snip from RFC5884--- >=20 > Long story short: while I can see this draft becoming a workgroup draft I= =20 > find the poll - well - premature. >=20 >=20 > Regards, Marc > =20 >=20 >=20 >=20 > On Tue, 25 Nov 2014 19:50:02 -0500, Jeffrey Haas wrote: >> Working Group, >>=20 >> Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was >> presented at IETF-91 in Honolulu and was positively received. We'd like= to >> ask the Working Group whether we should formally adopt this draft as a >> Working Group item. >>=20 >> Please indicate your support or lack thereof to the mail list by=20 >> December 12, 2014. =20 >>=20 >> Also, please supply feedback to the authors. I believe the perception o= f >> this document is that it's very nearly complete and thus should have a=20 >> short >> lifetime prior to publication as an RFC. >>=20 >> -- Jeff & Nobo. >>=20 >=20 From nobody Tue Dec 2 20:46:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D2A1A007D for ; Tue, 2 Dec 2014 20:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 nDZTlFUr3nFw for ; Tue, 2 Dec 2014 20:46:18 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010061A007E for ; Tue, 2 Dec 2014 20:46:17 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id l89so10213971qgf.38 for ; Tue, 02 Dec 2014 20:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=dOA1EYqDv/hMve5NUt286SJZTZEmxadCBefJ7HYRkP8=; b=hZaTLaAuMbCc3yfIHmEtlkRxpEWebKl05CeyecT9MNqy2UR37xciMZ4ylgMgFCfWuq GhT3CFx0bW9eMxhG/KUxCLA6gq1yY+OYT5HufQllvIMG5kx+FbLIzVqNc6NXN5KFCsZJ w5Df2Lwwl0ahz36elCBoiwB+XCZdNd93sHb5ymfF9+FhLVqoa8CN1P1nkDJJSRxWsl5P b+QPiWR7pNLDE6qeR5umGqo2BfSCYGX2ll7zHFBgMDkDFlm9UI+jbQNRC4syRbH1BSxL iv2Uh9DByS2qIrvpNLBUqNz8Aa8hHE5wEPvz+/wz8KT1b0ent7SvBg6/Uqcl9IiIjYRj tQXA== X-Received: by 10.224.34.73 with SMTP id k9mr4638554qad.33.1417581977153; Tue, 02 Dec 2014 20:46:17 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id b17sm22451424qah.35.2014.12.02.20.46.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 20:46:16 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D81CB5EE-037D-4F42-B3F6-2025FE282E8A" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: BFD stability follow-up from IETF-91 From: Mahesh Jethanandani In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> Date: Tue, 2 Dec 2014 20:46:13 -0800 Message-Id: <730769BB-D021-4E22-878A-2C289822A156@gmail.com> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lOQm2WPfDD-cRRITLLBEi_npaPk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 04:46:21 -0000 --Apple-Mail=_D81CB5EE-037D-4F42-B3F6-2025FE282E8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greg, What is Peng referring to is a way to figure out why a particular BFD = session flapped, particularly if the packet(s) for that session arrive = late. I do not see how that can be performance measurement. It is basic = BFD debug ability. Running a separate DM does tell you why a particular = BFD session flapped. Now we can debate what methods can be employed to measure that delay and = I am open to ways to doing it, including local loopback to measure = transmit delays or time stamping of packets in hardware. But in cases, = where there is no support for either of the capabilities, one of the = suggested solutions is to use the time stamps carried in the BFD = payload.=20 Cheers. > On Dec 1, 2014, at 9:38 AM, Gregory Mirsky = wrote: >=20 > Hi Peng, > and still, you=E2=80=99re looking for a tool to measure BFD = performance. Then you=E2=80=99ll be looking for a tool to verify the BFD = performance measurement, and on, and on. Operators do need complete set = of FCAPS tools, including performance measurement. Note that passive = performance measurement through marking method that Mach Chen referred = to can monitor BFD flow(s) and be used to do Loss and/or Delay = Measurement. And active Synthetic Loss Measurement may simulate flow of = small packets as well as relatively large packets. And the same goes for = active measurement method of Delay Measurement. I like Swiss Army knives = but let us not turn BFD into one. > =20 > Regards, > Greg > =20 > From: Fan, Peng [mailto:fanpeng@chinamobile.com]=20 > Sent: Monday, December 01, 2014 4:44 AM > To: Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 > =20 > Hi Gregory, > =20 > I was just giving an example :) Application traffic usually cannot = stand small packet loss, not to say 30% loss. > =20 > I am actually asking for a debug function that could give us some = useful hints of poor connection with small protocol change, besides the = basic connectivity information. If it measures something, it measures = packets of BFD itself. So I don=E2=80=99t expect it to be considered as = a performance measurement tool. > =20 > Best regards, > Peng > =20 > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com = ]=20 > Sent: Saturday, November 29, 2014 3:37 AM > To: Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org = > Subject: RE: BFD stability follow-up from IETF-91 > =20 > Hi Peng, > this is very interesting scenario. I think that if BFD experiences = ~30% packet loss, then highly likely so are affected other applications. = Then it is not just BFD issue but condition that should be detected by = performance measurement method, whether active or passive packet loss = measurement. > I=E2=80=99m convinced that overloading BFD with performance = measurement provisions is counter-productive and is inappropriate. > =20 > Regards, > Greg > =20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] On Behalf Of Fan, Peng > Sent: Friday, November 28, 2014 4:34 AM > To: 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org = > Subject: RE: BFD stability follow-up from IETF-91 > =20 > Hi Mallik, > =20 > Exactly. Packets may be experiencing slight loss, but the link can = hardly be regarded as connected. More importantly, the experience of = upper-level applications can be degraded severely (e.g. TCP traffic is = not able to go fast in face of even small continuous loss). But what if = one BFD frame is lost every three frames? Then the loss rate is 30% on = average, which is already a very severe value. > =20 > Best regards, > Peng > =20 > From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com = ]=20 > Sent: Friday, November 28, 2014 7:53 PM > To: Fan, Peng; rtg-bfd@ietf.org > Subject: Re: BFD stability follow-up from IETF-91 > =20 > Hi Peng, > =20 > If the BFD packets are lost, doesn=E2=80=99t the BFD session go DOWN? = Are you saying that packet loss is not big enough to make BFD session go = DOWN? > =20 > Thanks > =20 > Regards > Mallik > =20 > From: , Peng > > Date: Friday, 28 November 2014 4:20 pm > To: "rtg-bfd@ietf.org " > > Subject: RE: BFD stability follow-up from IETF-91 > =20 > Hi Jeff, all, > =20 > I have been following this stability extension from the beginning, and = as an > operator I would like to express that this draft enables the "advanced > feature" we desire for BFD to provide additional useful information = that > helps operators understand network issues. A relevant use case is = detecting > lossy or "quasi-disconnected" links or member LAG links. An example of = such > situation we experienced was a loosely connected fiber link resulting = in > continuous, small amount of packet loss. BFD could get the information = of > lost BFD frames on such unstable link, and probably report when a = target > level is reached, say a certain number of frames are lost over a = period or > among a total number of frames. > =20 > Best regards, > Peng Mahesh Jethanandani Co-chair, NETCONF WG mjethanandani@gmail.com --Apple-Mail=_D81CB5EE-037D-4F42-B3F6-2025FE282E8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Greg,

What = is Peng referring to is a way to figure out why a particular BFD session = flapped, particularly if the packet(s) for that session arrive late. I = do not see how that can be performance measurement. It is basic BFD = debug ability. Running a separate DM does tell you why a particular BFD = session flapped.

Now we can debate what methods can be employed to measure = that delay and I am open to ways to doing it, including local loopback = to measure transmit delays or time stamping of packets in hardware. But = in cases, where there is no support for either of the capabilities, one = of the suggested solutions is to use the time stamps carried in the BFD = payload. 

Cheers.

On Dec 1, 2014, at 9:38 AM, = Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Peng,
and still, you=E2=80=99re looking for a = tool to measure BFD performance. Then you=E2=80=99ll be looking for a = tool to verify the BFD performance measurement, and on, and on. = Operators do need complete set of FCAPS tools, including performance = measurement. Note that passive performance measurement through marking = method that Mach Chen referred to can monitor BFD flow(s) and be used to = do Loss and/or Delay Measurement. And active Synthetic Loss Measurement = may simulate flow of small packets as well as relatively large packets. = And the same goes for active measurement method of Delay Measurement. I = like Swiss Army knives but let us not turn BFD into one.
 
          &nb= sp;     Regards,
          &nb= sp;            = ;         Greg
 
From: Fan, Peng = [mailto:fanpeng@chinamobile.com] 
Sent: Monday, December 01, 2014 = 4:44 AM
To: Gregory Mirsky; 'MALLIK = MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up = from IETF-91
 
Hi = Gregory,
 
I = was just giving an example :) Application traffic usually cannot stand = small packet loss, not to say 30% loss.
 
I am actually = asking for a debug function that could give us some useful hints of poor = connection with small protocol change, besides the basic connectivity = information. If it measures something, it measures packets of BFD = itself. So I don=E2=80=99t expect it to be considered as a performance = measurement tool.
 
Best regards,
Peng
 
From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] 
Sent: Saturday, November 29, 2014 = 3:37 AM
To: Fan, Peng; 'MALLIK = MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up = from IETF-91
 
Hi = Peng,
this is very = interesting scenario. I think that if BFD experiences ~30% packet loss, = then highly likely so are affected other applications. Then it is not = just BFD issue but condition that should be detected  by = performance measurement method, whether active or passive packet loss = measurement.
I=E2=80=99m convinced = that overloading BFD with performance measurement provisions is = counter-productive and is inappropriate.
 
          &nb= sp;     Regards,
          &nb= sp;            = ;         Greg
 
From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Fan, Peng
Sent: Friday, November 28, 2014 = 4:34 AM
To: 'MALLIK MUDIGONDA = (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up = from IETF-91
 
Hi = Mallik,
 
Exactly. Packets may be experiencing slight loss, but the = link can hardly be regarded as connected. More importantly, the = experience of upper-level applications can be degraded severely (e.g. = TCP traffic is not able to go fast in face of even small continuous = loss). But what if one BFD frame is lost every three frames? Then the = loss rate is 30% on average, which is already a very severe value.
 
Best = regards,
Peng
 
From: MALLIK = MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] 
Sent: Friday, November 28, 2014 = 7:53 PM
To: Fan, Peng; rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up = from IETF-91
 
Hi= Peng,
 
If= the BFD packets are lost, doesn=E2=80=99t the BFD session go DOWN? Are = you saying that packet loss is not big enough to make BFD session go = DOWN?
 
Thanks
 
Regards
Mallik
 
From: <Fan>, Peng <fanpeng@chinamobile.com>Date: Friday, 28 November = 2014 4:20 pm
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: BFD stability = follow-up from IETF-91
 
Hi= Jeff, all,
 
I = have been following this stability extension from the beginning, and as = an
operator I would like to = express that this draft enables the "advanced
feature" we desire for BFD to provide additional = useful information that
helps operators understand network issues. A relevant use = case is detecting
lossy or "quasi-disconnected" links or member LAG links. An = example of such
situation we experienced was a loosely connected fiber link = resulting in
continuous, small amount of = packet loss. BFD could get the information of
lost BFD frames on such unstable link, and = probably report when a target
level is reached, say a certain number of frames are lost = over a period or
among a total number of frames.
 
Best regards,
Peng

Mahesh Jethanandani
Co-chair, NETCONF WG
mjethanandani@gmail.com




= --Apple-Mail=_D81CB5EE-037D-4F42-B3F6-2025FE282E8A-- From nobody Wed Dec 3 05:39:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29571A1B17 for ; Wed, 3 Dec 2014 05:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 78pn9bxwz-_v for ; Wed, 3 Dec 2014 05:39:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:741]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012E11A1B15 for ; Wed, 3 Dec 2014 05:39:52 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 3 Dec 2014 13:39:29 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Wed, 3 Dec 2014 13:39:29 +0000 From: Santosh P K To: Marc Binderberger , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuCAAAvZAIAF49GAgANl6hA= Date: Wed, 3 Dec 2014 13:39:29 +0000 Message-ID: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <20141201013841551442.5a9df5b9@sniff.de> In-Reply-To: <20141201013841551442.5a9df5b9@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(199003)(189002)(13464003)(24454002)(33656002)(99396003)(54206007)(46102003)(15975445006)(86362001)(561944003)(97736003)(31966008)(92726001)(92566001)(4396001)(101416001)(19580405001)(19580395003)(21056001)(87936001)(120916001)(2656002)(66066001)(93886004)(40100003)(1720100001)(74316001)(106116001)(64706001)(105586002)(76576001)(106356001)(54606007)(68736005)(50986999)(54356999)(20776003)(62966003)(77096005)(77156002)(122556002)(15202345003)(76176999)(107046002)(99286002)(95666004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/k8ZwmpaRI1cERcCxP9swfyiSa6o Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 13:39:57 -0000 Hello Manav and Marc, =20 > > One way to solve this problem is by attaching a debug trailer that > > only carries the seq numbers at the *end* of the BFD packet. This > > would not be covered in the Length field carried in the BFD header but > > would be accounted for in the length carried in the IP header. >=20 > BFD itself is not related to IP, i.e. there is not always an IP header. > Sure, the encapsulating "frame" may provide a length but actually, why no= t > covering the debug trailer with the BFD length? >=20 > If this is solely for debug purpose than this may work. For simple copyin= g-out > into e.g. a packet trace buffer it would be even simpler to have the BFD > length covering the trailer. > If hardware is supposed to process the trailer information (other than > copying out) then it's getting ugly - having fixed position, fixed length > extension headers would be preferable for simple access. Fixed length would be easy to process in hardware. Problem is when we have = many have extensions in future. If we want to use only one extension that i= s at the last then I will be forced to pad all the other extension ahead of= it? This might not be a problem if we have fewer extensions but might beco= me problem when there are too many extensions.=20 >=20 > Another idea is to use the 0x80 bit of the auth type to distinguish betwe= en a > "normal" authentication header and a "sequence + authentication". >=20 I think this is good. In the BFD extension TLV we still have many reserved = bits that can be used as well? Thanks Santosh P K=20 >=20 > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > Hi Santosh, > > > > You could use the crypto sequence numbers carried in the meticulous > > cryptographic auth for detecting packet losses. However, this breaks > > when you use non-meticulous crypto authentication since the sequence > > number is only incremented occasionally there. This i believe is a > > deal breaker since i really envision non meticulous mode to be the one > > being widely deployed. In fact we were supposed to write a draft on > > that and i guess it just fell through the cracks (lemme ping my > > co-author on that !) > > > > One way to solve this problem is by attaching a debug trailer that > > only carries the seq numbers at the *end* of the BFD packet. This > > would not be covered in the Length field carried in the BFD header but > > would be accounted for in the length carried in the IP header. The > > concept of attaching a trailer is documented well and is used in the > > IGPs. RFC 6506 describes one such trailer for OSPFv3. The catch > > however is that this debug trailer will NOT be covered by the BFD > > authentication. Is this acceptable to the WG? > > > > I think the problem of diagnosing a BFD flap becomes all the more > > important with BFD authentication turned on since then we have more > > points where a delay can be inserted. > > > > Cheers, Manav > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > wrote: > >> Manav, > >> This is good question. > >> > >>> Can the authors add some text on how this debugging mechanism would > >>> work if somebody employs BFD authentication? > >> > >> Right now we have considered without authentication (we are setting A > >> bit). We should add some text on how we can use both Auth and de bug > TLV. > >> Is there any suggestion you have? I will get back to you on this. > >> > >> > >> Thanks > >> Santosh P K > >> > >>>> -----Original Message----- > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach > Chen > >>>> Sent: Thursday, November 27, 2014 2:13 PM > >>>> To: Marc Binderberger > >>>> Cc: rtg-bfd@ietf.org > >>>> Subject: RE: BFD stability follow-up from IETF-91 > >>>> > >>>> Hi Marc, > >>>> > >>>>> -----Original Message----- > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > >>>>> To: Mach Chen > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > >>>>> > >>>>> Hello Mach, > >>>>> > >>>>>> This triggers me think out there should be another solution for > >>>>>> getting the Tx and Rx timestamps without encoding the timestamps > in > >>>>>> the BFD > >>>>> packets. > >>>>>> For example, the Tx and Rx systems could just save timestamps > >>>>>> locally or send them to a centralized entity and then use the > >>>>>> sequence numbers to correlate them for further analyzing. > >>>>> > >>>>> I remember some discussion on NVO3 about how many bits it takes ;- > ) - > >>>>> could you send the links/draft names you are working on to this lis= t? > >>>>> May be useful for further discussions. > >>>> > >>>> Sure, here is the > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > >>> based-ipfpm-framework-02) for the reference. > >>>> > >>>> But here I want to say is that since we have sequence number, we may > not > >>> need the marking based solution. Suppose that someone want to > monitor > >>> the delay of a BFD packet , just record and save the timestamp at the= Tx > >>> side, > >>> which indexed by the sequence number. Similarly, do the same at the R= x > >>> side. Then based on the timestamps from both Tx and Rx, and using the > >>> sequence number to correlate the timestamps, it can also provide a wa= y > to > >>> monitor the delay of the BFD packet. > >>>> > >>>> That means, only if there is sequence number, even if without carryi= ng > >>>> the > >>> timestamp in the BFD packet, BFD packet delay can be measured. > >>>> > >>>> Best regards, > >>>> Mach > >>>> > >>>>> > >>>>> > >>>>> Thanks & Regards, > >>>>> Marc > >>>>> > >>>>> > >>>>> > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > >>>>>> Hi Marc and Manav, > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Marc > >>>>>>> Binderberger > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > >>>>>>> To: Manav Bhatia > >>>>>>> Cc: rtg-bfd@ietf.org > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > >>>>>>> > >>>>>>> Hello Manav, > >>>>>>> > >>>>>>>> I believe the work is important and addresses something thats > >>>>>>>> really required (spent too much time debugging why BFD > flapped!). > >>>>>>> > >>>>>>> agree :-) we should keep the discussion alive. > >>>>>>> > >>>>>>> > >>>>>>>> side Time stamping would have helped in debugging whether the > >>> BFD > >>>>>>>> packet was sent late, or whether the packet was sent on time and > >>>>>>>> also arrived on time but was delayed when passing it up the BFD > >>>>>>>> stack/processor (lay in the RX buffer for tad too long) > >>>>>>> > >>>>>>> well, I can see a point in having the Tx timestamps in the packet > >>>>>>> mainly for the purpose of knowing "this" packet was okay/not okay > >>>>>>> on the Tx side and to correlate it with your local Rx measurement= . > >>>>>> > >>>>>> Yes, this is one solution if people think BFD delay is needed. If > >>>>>> allow to have Tx timestamps to be carried in the packets, seems it > >>>>>> should be no problem to leave a seat for the Rx timestamps as well > >>>>>> :-). After all, with both Tx and Rx timestamp, it may simplify the > >>>>> implementation. > >>>>>> > >>>>>>> > >>>>>>> And even this point is less relevant with sequence numbers as thi= s > >>>>>>> number allows the identification of packets and thus the > >>>>>>> correlation of information from the Tx and Rx system. > >>>>>> > >>>>>> Indeed, the sequence number helps a lot for the correlation > between > >>>>>> the Tx and Rx system. > >>>>>> > >>>>>> This triggers me think out there should be another solution for > >>>>>> getting the Tx and Rx timestamps without encoding the timestamps > in > >>>>>> the BFD > >>>>> packets. > >>>>>> For example, the Tx and Rx systems could just save timestamps > >>>>>> locally or send them to a centralized entity and then use the > >>>>>> sequence numbers to correlate them for further analyzing. > >>>>>> > >>>>>> Best regards, > >>>>>> Mach > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Regards, Marc > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > >>>>>>>> Hi Jeff, > >>>>>>>> > >>>>>>>> I vividly remember the original intent of the stability draft wa= s > >>>>>>>> to help debug BFD failures -- to isolate the issue at the RX or > >>>>>>>> the TX side Time stamping would have helped in debugging > whether > >>>>>>>> the BFD packet was sent late, or whether the packet was sent on > >>>>>>>> time and also arrived on time but was delayed when passing it up > >>>>>>>> the BFD stack/processor (lay in the RX buffer for tad too long), > >>>>>>>> etc. But then time stamping came with its own set of issues, and > >>>>>>>> was hence dropped from the original draft. > >>>>>>>> > >>>>>>>> Can the authors send a summary on the list on why time stamping > >>>>>>>> was dropped so that we're all clear on that one. > >>>>>>>> > >>>>>>>> The current proposal does help but is not complete. > >>>>>>>> > >>>>>>>> Assume that the RX end loses a BFD session and learns later that > >>>>>>>> it did eventually receive the missing BFD packets (based on the > seq > >>> #). > >>>>>>>> How would it know which end was misbehaving? Was it a delay at > >>>>>>>> the TX side, or was it the RX that delayed passing the packets t= o > >>>>>>>> the BFD process(or). This is usually what we want to debug and i > >>>>>>>> want to understand how this draft with sequence numbers can > >>>>>>>> unequivocally tell me that. > >>>>>>>> > >>>>>>>> I believe the work is important and addresses something thats > >>>>>>>> really required (spent too much time debugging why BFD > flapped!). > >>>>>>>> Clearly what would help is putting a small section that describe= s > >>>>>>>> how we can use the sequence numbers to debug what and > where > >>> things went wrong. > >>>>>>>> > >>>>>>>> Cheers, Manav > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > >>> wrote: > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during IETF-9= 1 > >>>>>>>>> in Honolulu. The slides can be viewed here: > >>>>>>>>> > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx > >>>>>>>>> > >>>>>>>>> To attempt to simplify the presentation, the contentious portio= n > >>>>>>>>> of the timers were removed from the proposal, leaving only the > >>>>>>>>> sequence numbering for detecting loss of BFD async packets. > >>>>>>>>> > >>>>>>>>> When the room was polled to see whether the draft should be > >>>>>>>>> adopted as a WG item, the sense of the room was very quiet. As > >>>>>>>>> promised, this is to inquire for support for this draft on the > >>>>>>>>> WG mailing list to make sure the whole group has a voice. > >>>>>>>>> > >>>>>>>>> It should be noted that post-meeting discussion on the fate of > >>>>>>>>> this draft noted that BFD authentication code points are > >>>>>>>>> plentiful and are available with expert review. Should the > >>>>>>>>> draft authors wish to continue this work as Experimental, that = is > an > >>> option. > >>>>>>>>> > >>>>>>>>> -- Jeff > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> > > From nobody Wed Dec 3 12:52:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E851A7008 for ; Wed, 3 Dec 2014 12:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 f1HsTuBPmnBd for ; Wed, 3 Dec 2014 12:52:30 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 98FD41A89EB for ; Wed, 3 Dec 2014 12:52:30 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-d1-547f1bd2824b Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0B.67.25146.5DB1F745; Wed, 3 Dec 2014 15:19:01 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 15:52:25 -0500 From: Gregory Mirsky To: Santosh P K , Marc Binderberger , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQDUqXQ6amXjPuFEmbPIOgLl4p2px+NluAgAAjMzA= Date: Wed, 3 Dec 2014 20:52:25 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AA51B@eusaamb103.ericsson.se> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <20141201013841551442.5a9df5b9@sniff.de> 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.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPrO5V6foQg7XztS0uT2pjt5h95T+z xec/2xgtrt3dyuzA4rFz1l12jyVLfjJ5XG+6yu7RurqbJYAlissmJTUnsyy1SN8ugStjx9YP 7AWTEis2b1zL3sA427eLkZNDQsBE4uf/mywQtpjEhXvr2boYuTiEBI4wSnzavZ0RwlnGKNHV O4cVpIpNwEjixcYedhBbRKBIYtbsh2BxZgFNiaYTn8HiwgKGEqu6F0PVGEkcmzEXyraS2Njb AWazCKhITJjczAZi8wr4Sny+eAZq819WiZbNM5lAEpwC8RKXdy0DsxmBzvt+ag0TxDJxiVtP 5jNBnC0gsWTPeWYIW1Ti5eN/rBC2osS+/unsEPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMY xWYhGTsLScssJC2zkLQsYGRZxchRWpxalptuZLiJERhRxyTYHHcwLvhkeYhRgINRiYfXgKcu RIg1say4MvcQozQHi5I4r2b1vGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKrObP+n3Y0t ucJ7zfT2TPWznDvKTzF92H5bqa25gFuYhV8za4+c9rxEc6s9O//MaNqtxbToodNzV67QXJle hq+vnz4ItfttrHS4ts1WL0flaiivSxOzbXrjP4XrUgFKB5smFeo1aBn8daio6lmQ0KmuM6P2 UleVx/mCCvPz19fu+ut28mmpEktxRqKhFnNRcSIAiTsBxYkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/wT6yGNL03biI2KdGESkLvJ0Ki00 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 20:52:36 -0000 Dear All, had authors of the proposal or we already dismissed use of BFD Echo? I've s= canned the thread and couldn't find trace of us discussing BFD Echo mode. I= think that it is more suitable for experimentation and unorthodox use. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Wednesday, December 03, 2014 5:39 AM To: Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Manav and Marc, =20 > > One way to solve this problem is by attaching a debug trailer that=20 > > only carries the seq numbers at the *end* of the BFD packet. This=20 > > would not be covered in the Length field carried in the BFD header=20 > > but would be accounted for in the length carried in the IP header. >=20 > BFD itself is not related to IP, i.e. there is not always an IP header. > Sure, the encapsulating "frame" may provide a length but actually, why=20 > not covering the debug trailer with the BFD length? >=20 > If this is solely for debug purpose than this may work. For simple=20 > copying-out into e.g. a packet trace buffer it would be even simpler=20 > to have the BFD length covering the trailer. > If hardware is supposed to process the trailer information (other than=20 > copying out) then it's getting ugly - having fixed position, fixed=20 > length extension headers would be preferable for simple access. Fixed length would be easy to process in hardware. Problem is when we have = many have extensions in future. If we want to use only one extension that i= s at the last then I will be forced to pad all the other extension ahead of= it? This might not be a problem if we have fewer extensions but might beco= me problem when there are too many extensions.=20 >=20 > Another idea is to use the 0x80 bit of the auth type to distinguish=20 > between a "normal" authentication header and a "sequence + authentication= ". >=20 I think this is good. In the BFD extension TLV we still have many reserved = bits that can be used as well? Thanks Santosh P K=20 >=20 > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > Hi Santosh, > > > > You could use the crypto sequence numbers carried in the meticulous=20 > > cryptographic auth for detecting packet losses. However, this breaks=20 > > when you use non-meticulous crypto authentication since the sequence=20 > > number is only incremented occasionally there. This i believe is a=20 > > deal breaker since i really envision non meticulous mode to be the=20 > > one being widely deployed. In fact we were supposed to write a draft=20 > > on that and i guess it just fell through the cracks (lemme ping my=20 > > co-author on that !) > > > > One way to solve this problem is by attaching a debug trailer that=20 > > only carries the seq numbers at the *end* of the BFD packet. This=20 > > would not be covered in the Length field carried in the BFD header=20 > > but would be accounted for in the length carried in the IP header.=20 > > The concept of attaching a trailer is documented well and is used in=20 > > the IGPs. RFC 6506 describes one such trailer for OSPFv3. The catch=20 > > however is that this debug trailer will NOT be covered by the BFD=20 > > authentication. Is this acceptable to the WG? > > > > I think the problem of diagnosing a BFD flap becomes all the more=20 > > important with BFD authentication turned on since then we have more=20 > > points where a delay can be inserted. > > > > Cheers, Manav > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > wrote: > >> Manav, > >> This is good question. > >> > >>> Can the authors add some text on how this debugging mechanism=20 > >>> would work if somebody employs BFD authentication? > >> > >> Right now we have considered without authentication (we are setting=20 > >> A bit). We should add some text on how we can use both Auth and de=20 > >> bug > TLV. > >> Is there any suggestion you have? I will get back to you on this. > >> > >> > >> Thanks > >> Santosh P K > >> > >>>> -----Original Message----- > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach > Chen > >>>> Sent: Thursday, November 27, 2014 2:13 PM > >>>> To: Marc Binderberger > >>>> Cc: rtg-bfd@ietf.org > >>>> Subject: RE: BFD stability follow-up from IETF-91 > >>>> > >>>> Hi Marc, > >>>> > >>>>> -----Original Message----- > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > >>>>> To: Mach Chen > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > >>>>> > >>>>> Hello Mach, > >>>>> > >>>>>> This triggers me think out there should be another solution for=20 > >>>>>> getting the Tx and Rx timestamps without encoding the=20 > >>>>>> timestamps > in > >>>>>> the BFD > >>>>> packets. > >>>>>> For example, the Tx and Rx systems could just save timestamps=20 > >>>>>> locally or send them to a centralized entity and then use the=20 > >>>>>> sequence numbers to correlate them for further analyzing. > >>>>> > >>>>> I remember some discussion on NVO3 about how many bits it takes=20 > >>>>> ;- > ) - > >>>>> could you send the links/draft names you are working on to this lis= t? > >>>>> May be useful for further discussions. > >>>> > >>>> Sure, here is the > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > >>> based-ipfpm-framework-02) for the reference. > >>>> > >>>> But here I want to say is that since we have sequence number, we=20 > >>>> may > not > >>> need the marking based solution. Suppose that someone want to > monitor > >>> the delay of a BFD packet , just record and save the timestamp at=20 > >>> the Tx side, which indexed by the sequence number. Similarly, do=20 > >>> the same at the Rx side. Then based on the timestamps from both Tx=20 > >>> and Rx, and using the sequence number to correlate the timestamps,=20 > >>> it can also provide a way > to > >>> monitor the delay of the BFD packet. > >>>> > >>>> That means, only if there is sequence number, even if without=20 > >>>> carrying the > >>> timestamp in the BFD packet, BFD packet delay can be measured. > >>>> > >>>> Best regards, > >>>> Mach > >>>> > >>>>> > >>>>> > >>>>> Thanks & Regards, > >>>>> Marc > >>>>> > >>>>> > >>>>> > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > >>>>>> Hi Marc and Manav, > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Marc > >>>>>>> Binderberger > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > >>>>>>> To: Manav Bhatia > >>>>>>> Cc: rtg-bfd@ietf.org > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > >>>>>>> > >>>>>>> Hello Manav, > >>>>>>> > >>>>>>>> I believe the work is important and addresses something thats=20 > >>>>>>>> really required (spent too much time debugging why BFD > flapped!). > >>>>>>> > >>>>>>> agree :-) we should keep the discussion alive. > >>>>>>> > >>>>>>> > >>>>>>>> side Time stamping would have helped in debugging whether the > >>> BFD > >>>>>>>> packet was sent late, or whether the packet was sent on time=20 > >>>>>>>> and also arrived on time but was delayed when passing it up=20 > >>>>>>>> the BFD stack/processor (lay in the RX buffer for tad too=20 > >>>>>>>> long) > >>>>>>> > >>>>>>> well, I can see a point in having the Tx timestamps in the=20 > >>>>>>> packet mainly for the purpose of knowing "this" packet was=20 > >>>>>>> okay/not okay on the Tx side and to correlate it with your local = Rx measurement. > >>>>>> > >>>>>> Yes, this is one solution if people think BFD delay is needed.=20 > >>>>>> If allow to have Tx timestamps to be carried in the packets,=20 > >>>>>> seems it should be no problem to leave a seat for the Rx=20 > >>>>>> timestamps as well :-). After all, with both Tx and Rx=20 > >>>>>> timestamp, it may simplify the > >>>>> implementation. > >>>>>> > >>>>>>> > >>>>>>> And even this point is less relevant with sequence numbers as=20 > >>>>>>> this number allows the identification of packets and thus the=20 > >>>>>>> correlation of information from the Tx and Rx system. > >>>>>> > >>>>>> Indeed, the sequence number helps a lot for the correlation > between > >>>>>> the Tx and Rx system. > >>>>>> > >>>>>> This triggers me think out there should be another solution for=20 > >>>>>> getting the Tx and Rx timestamps without encoding the=20 > >>>>>> timestamps > in > >>>>>> the BFD > >>>>> packets. > >>>>>> For example, the Tx and Rx systems could just save timestamps=20 > >>>>>> locally or send them to a centralized entity and then use the=20 > >>>>>> sequence numbers to correlate them for further analyzing. > >>>>>> > >>>>>> Best regards, > >>>>>> Mach > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Regards, Marc > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > >>>>>>>> Hi Jeff, > >>>>>>>> > >>>>>>>> I vividly remember the original intent of the stability draft=20 > >>>>>>>> was to help debug BFD failures -- to isolate the issue at the=20 > >>>>>>>> RX or the TX side Time stamping would have helped in=20 > >>>>>>>> debugging > whether > >>>>>>>> the BFD packet was sent late, or whether the packet was sent=20 > >>>>>>>> on time and also arrived on time but was delayed when passing=20 > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad=20 > >>>>>>>> too long), etc. But then time stamping came with its own set=20 > >>>>>>>> of issues, and was hence dropped from the original draft. > >>>>>>>> > >>>>>>>> Can the authors send a summary on the list on why time=20 > >>>>>>>> stamping was dropped so that we're all clear on that one. > >>>>>>>> > >>>>>>>> The current proposal does help but is not complete. > >>>>>>>> > >>>>>>>> Assume that the RX end loses a BFD session and learns later=20 > >>>>>>>> that it did eventually receive the missing BFD packets (based=20 > >>>>>>>> on the > seq > >>> #). > >>>>>>>> How would it know which end was misbehaving? Was it a delay=20 > >>>>>>>> at the TX side, or was it the RX that delayed passing the=20 > >>>>>>>> packets to the BFD process(or). This is usually what we want=20 > >>>>>>>> to debug and i want to understand how this draft with=20 > >>>>>>>> sequence numbers can unequivocally tell me that. > >>>>>>>> > >>>>>>>> I believe the work is important and addresses something thats=20 > >>>>>>>> really required (spent too much time debugging why BFD > flapped!). > >>>>>>>> Clearly what would help is putting a small section that=20 > >>>>>>>> describes how we can use the sequence numbers to debug what=20 > >>>>>>>> and > where > >>> things went wrong. > >>>>>>>> > >>>>>>>> Cheers, Manav > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas=20 > >>>>>>>> > >>> wrote: > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during=20 > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > >>>>>>>>> > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pp > >>>>>>>>> tx > >>>>>>>>> > >>>>>>>>> To attempt to simplify the presentation, the contentious=20 > >>>>>>>>> portion of the timers were removed from the proposal,=20 > >>>>>>>>> leaving only the sequence numbering for detecting loss of BFD a= sync packets. > >>>>>>>>> > >>>>>>>>> When the room was polled to see whether the draft should be=20 > >>>>>>>>> adopted as a WG item, the sense of the room was very quiet. =20 > >>>>>>>>> As promised, this is to inquire for support for this draft=20 > >>>>>>>>> on the WG mailing list to make sure the whole group has a voice= . > >>>>>>>>> > >>>>>>>>> It should be noted that post-meeting discussion on the fate=20 > >>>>>>>>> of this draft noted that BFD authentication code points are=20 > >>>>>>>>> plentiful and are available with expert review. Should the=20 > >>>>>>>>> draft authors wish to continue this work as Experimental,=20 > >>>>>>>>> that is > an > >>> option. > >>>>>>>>> > >>>>>>>>> -- Jeff > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> > > From nobody Wed Dec 3 15:25:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8536C1A6EE9 for ; Wed, 3 Dec 2014 15:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 CWHUQsGfA2QF for ; Wed, 3 Dec 2014 15:25:32 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 3B91F1A3BA4 for ; Wed, 3 Dec 2014 15:25:27 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-3f-547f3fac6cd8 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6C.AF.25146.CAF3F745; Wed, 3 Dec 2014 17:51:57 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 18:25:25 -0500 From: Gregory Mirsky To: Mahesh Jethanandani Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAjSUAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAF9PggASh4oD///wSUIACoyWAgADg8VA= Date: Wed, 3 Dec 2014 23:25:25 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> In-Reply-To: <730769BB-D021-4E22-878A-2C289822A156@gmail.com> 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_7347100B5761DC41A166AC17F22DF1121B8AA754eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXSPt+5a+/oQgy2NihbrG16wW5x+s47N 4sirY8wWn/9sY3Rg8Zh3YSGbx5TfG1k9ds66y+6xZMlPpgCWKC6blNSczLLUIn27BK6MU8sf MBYsOMZU8WH9RMYGxjt7mboYOTkkBEwkHr5ezwphi0lcuLeeDcQWEjjCKDHtoFMXIxeQvYxR ovfbEbAEm4CRxIuNPewgtoiAocSpAy+YQIqYBdoYJRreTAIrEgZKrOpeDFVkJHFsxlx2kCIR gS5GiSXXVoKtZhFQkbj3ZwMLiM0r4Cux6NhXJoh1bcwSK7YeA7uJU8BWYsmxO4wgNiPQfd9P rQFrZhYQl7j1ZD7UDwISS/acZ4awRSVePv4H9Y+SxKSl51gh6vMlth16zw6xTFDi5MwnLBMY RWchGTULSdksJGWzGDmA4poS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRUjR2lxalluupHh JkZgFB6TYHPcwbjgk+UhRgEORiUeXgOeuhAh1sSy4srcQ4zSHCxK4rya1fOChQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTAu/Cmu0hapf34Tt+jVHqsbDy80i0zv3Xixb7LzASUf3eINTBNu qJczuAhYRc5+t7DzxtxnNrq8xyecVzbbZH183tOqtIa/D66pdp9+eDeuKpPrfdJOuV+LN1Qy L7sUs1dJ6sWGjNLn2aqtvuUuYou7dxq+rVlSZZ/IdC3Pab1NOMMOb+UfokZKLMUZiYZazEXF iQBEaQ3NowIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fQ4lT9zh3TcXUSXmjxhutkzvTiM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 23:25:37 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AA754eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KSSBjb25zaWRlciBpc3N1ZXMgb2YgZGVidWdhYmlsaXR5LCBub3Qgb2YganVz dCBCRkQgYnV0IGFueSBvdGhlciBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wsIHRvIGJlIG91dHNpZGUg b2YgU3RhbmRhcmQgdHJhY2ssIGF0IG1vc3QgdG8gYmUgc3VpdGFibGUgZm9yIEluZm9ybWF0aW9u YWwgb3IgRXhwZXJpbWVudGFsIHRyYWNrLiBJZiB3ZSBhZ3JlZSBvbiB0aGF0LCB0aGVuIHdlIGNh biBkaXNjdXNzIHNjZW5hcmlvcyB0aGF0IHByZXNlbnQgcHJvYmxlbSBhbmQgaW52ZXN0aWdhdGUg d2hldGhlciBhbnl0aGluZyBpbiB0aGUgcHJvdG9jb2wgcmVxdWlyZXMgY2xhcmlmaWNhdGlvbiB0 byBoZWxwIHZlbmRvcnMgaW4gYnVpbGRpbmcgd2VsbC1wZXJmb3JtaW5nLCBzY2FsYWJsZSBhbmQg aW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgYW5kIHByb3ZpZGUgb3BlcmF0aW9uYWwgZ3Vp ZGVsaW5lcyBmb3Igb3BlcmF0b3JzLg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBNYWhlc2ggSmV0aGFuYW5k YW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBEZWNl bWJlciAwMiwgMjAxNCA4OjQ2IFBNDQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBGYW4sIFBlbmc7 IE1BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKTsgcnRnLWJmZEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KDQpHcmVnLA0KDQpXaGF0 IGlzIFBlbmcgcmVmZXJyaW5nIHRvIGlzIGEgd2F5IHRvIGZpZ3VyZSBvdXQgd2h5IGEgcGFydGlj dWxhciBCRkQgc2Vzc2lvbiBmbGFwcGVkLCBwYXJ0aWN1bGFybHkgaWYgdGhlIHBhY2tldChzKSBm b3IgdGhhdCBzZXNzaW9uIGFycml2ZSBsYXRlLiBJIGRvIG5vdCBzZWUgaG93IHRoYXQgY2FuIGJl IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LiBJdCBpcyBiYXNpYyBCRkQgZGVidWcgYWJpbGl0eS4g UnVubmluZyBhIHNlcGFyYXRlIERNIGRvZXMgdGVsbCB5b3Ugd2h5IGEgcGFydGljdWxhciBCRkQg c2Vzc2lvbiBmbGFwcGVkLg0KDQpOb3cgd2UgY2FuIGRlYmF0ZSB3aGF0IG1ldGhvZHMgY2FuIGJl IGVtcGxveWVkIHRvIG1lYXN1cmUgdGhhdCBkZWxheSBhbmQgSSBhbSBvcGVuIHRvIHdheXMgdG8g ZG9pbmcgaXQsIGluY2x1ZGluZyBsb2NhbCBsb29wYmFjayB0byBtZWFzdXJlIHRyYW5zbWl0IGRl bGF5cyBvciB0aW1lIHN0YW1waW5nIG9mIHBhY2tldHMgaW4gaGFyZHdhcmUuIEJ1dCBpbiBjYXNl cywgd2hlcmUgdGhlcmUgaXMgbm8gc3VwcG9ydCBmb3IgZWl0aGVyIG9mIHRoZSBjYXBhYmlsaXRp ZXMsIG9uZSBvZiB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9ucyBpcyB0byB1c2UgdGhlIHRpbWUgc3Rh bXBzIGNhcnJpZWQgaW4gdGhlIEJGRCBwYXlsb2FkLg0KDQpDaGVlcnMuDQoNCk9uIERlYyAxLCAy MDE0LCBhdCA5OjM4IEFNLCBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KSGkgUGVu ZywNCmFuZCBzdGlsbCwgeW914oCZcmUgbG9va2luZyBmb3IgYSB0b29sIHRvIG1lYXN1cmUgQkZE IHBlcmZvcm1hbmNlLiBUaGVuIHlvdeKAmWxsIGJlIGxvb2tpbmcgZm9yIGEgdG9vbCB0byB2ZXJp ZnkgdGhlIEJGRCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCwgYW5kIG9uLCBhbmQgb24uIE9wZXJh dG9ycyBkbyBuZWVkIGNvbXBsZXRlIHNldCBvZiBGQ0FQUyB0b29scywgaW5jbHVkaW5nIHBlcmZv cm1hbmNlIG1lYXN1cmVtZW50LiBOb3RlIHRoYXQgcGFzc2l2ZSBwZXJmb3JtYW5jZSBtZWFzdXJl bWVudCB0aHJvdWdoIG1hcmtpbmcgbWV0aG9kIHRoYXQgTWFjaCBDaGVuIHJlZmVycmVkIHRvIGNh biBtb25pdG9yIEJGRCBmbG93KHMpIGFuZCBiZSB1c2VkIHRvIGRvIExvc3MgYW5kL29yIERlbGF5 IE1lYXN1cmVtZW50LiBBbmQgYWN0aXZlIFN5bnRoZXRpYyBMb3NzIE1lYXN1cmVtZW50IG1heSBz aW11bGF0ZSBmbG93IG9mIHNtYWxsIHBhY2tldHMgYXMgd2VsbCBhcyByZWxhdGl2ZWx5IGxhcmdl IHBhY2tldHMuIEFuZCB0aGUgc2FtZSBnb2VzIGZvciBhY3RpdmUgbWVhc3VyZW1lbnQgbWV0aG9k IG9mIERlbGF5IE1lYXN1cmVtZW50LiBJIGxpa2UgU3dpc3MgQXJteSBrbml2ZXMgYnV0IGxldCB1 cyBub3QgdHVybiBCRkQgaW50byBvbmUuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IEZhbiwgUGVuZyBbbWFp bHRvOmZhbnBlbmdAY2hpbmFtb2JpbGUuY29tXQ0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMSwg MjAxNCA0OjQ0IEFNDQpUbzogR3JlZ29yeSBNaXJza3k7ICdNQUxMSUsgTVVESUdPTkRBIChtbXVk aWdvbiknOyBydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPg0KU3ViamVj dDogUkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KDQpIaSBHcmVnb3J5 LA0KDQpJIHdhcyBqdXN0IGdpdmluZyBhbiBleGFtcGxlIDopIEFwcGxpY2F0aW9uIHRyYWZmaWMg dXN1YWxseSBjYW5ub3Qgc3RhbmQgc21hbGwgcGFja2V0IGxvc3MsIG5vdCB0byBzYXkgMzAlIGxv c3MuDQoNCkkgYW0gYWN0dWFsbHkgYXNraW5nIGZvciBhIGRlYnVnIGZ1bmN0aW9uIHRoYXQgY291 bGQgZ2l2ZSB1cyBzb21lIHVzZWZ1bCBoaW50cyBvZiBwb29yIGNvbm5lY3Rpb24gd2l0aCBzbWFs bCBwcm90b2NvbCBjaGFuZ2UsIGJlc2lkZXMgdGhlIGJhc2ljIGNvbm5lY3Rpdml0eSBpbmZvcm1h dGlvbi4gSWYgaXQgbWVhc3VyZXMgc29tZXRoaW5nLCBpdCBtZWFzdXJlcyBwYWNrZXRzIG9mIEJG RCBpdHNlbGYuIFNvIEkgZG9u4oCZdCBleHBlY3QgaXQgdG8gYmUgY29uc2lkZXJlZCBhcyBhIHBl cmZvcm1hbmNlIG1lYXN1cmVtZW50IHRvb2wuDQoNCkJlc3QgcmVnYXJkcywNClBlbmcNCg0KRnJv bTogR3JlZ29yeSBNaXJza3kgW21haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb21dDQpT ZW50OiBTYXR1cmRheSwgTm92ZW1iZXIgMjksIDIwMTQgMzozNyBBTQ0KVG86IEZhbiwgUGVuZzsg J01BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKSc7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0 Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJv bSBJRVRGLTkxDQoNCkhpIFBlbmcsDQp0aGlzIGlzIHZlcnkgaW50ZXJlc3Rpbmcgc2NlbmFyaW8u IEkgdGhpbmsgdGhhdCBpZiBCRkQgZXhwZXJpZW5jZXMgfjMwJSBwYWNrZXQgbG9zcywgdGhlbiBo aWdobHkgbGlrZWx5IHNvIGFyZSBhZmZlY3RlZCBvdGhlciBhcHBsaWNhdGlvbnMuIFRoZW4gaXQg aXMgbm90IGp1c3QgQkZEIGlzc3VlIGJ1dCBjb25kaXRpb24gdGhhdCBzaG91bGQgYmUgZGV0ZWN0 ZWQgIGJ5IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IG1ldGhvZCwgd2hldGhlciBhY3RpdmUgb3Ig cGFzc2l2ZSBwYWNrZXQgbG9zcyBtZWFzdXJlbWVudC4NCknigJltIGNvbnZpbmNlZCB0aGF0IG92 ZXJsb2FkaW5nIEJGRCB3aXRoIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IHByb3Zpc2lvbnMgaXMg Y291bnRlci1wcm9kdWN0aXZlIGFuZCBpcyBpbmFwcHJvcHJpYXRlLg0KDQogICAgICAgICAgICAg ICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9t OiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RmFuLCBQZW5nDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDI4LCAyMDE0IDQ6MzQgQU0NClRvOiAn TUFMTElLIE1VRElHT05EQSAobW11ZGlnb24pJzsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRn LWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9t IElFVEYtOTENCg0KSGkgTWFsbGlrLA0KDQpFeGFjdGx5LiBQYWNrZXRzIG1heSBiZSBleHBlcmll bmNpbmcgc2xpZ2h0IGxvc3MsIGJ1dCB0aGUgbGluayBjYW4gaGFyZGx5IGJlIHJlZ2FyZGVkIGFz IGNvbm5lY3RlZC4gTW9yZSBpbXBvcnRhbnRseSwgdGhlIGV4cGVyaWVuY2Ugb2YgdXBwZXItbGV2 ZWwgYXBwbGljYXRpb25zIGNhbiBiZSBkZWdyYWRlZCBzZXZlcmVseSAoZS5nLiBUQ1AgdHJhZmZp YyBpcyBub3QgYWJsZSB0byBnbyBmYXN0IGluIGZhY2Ugb2YgZXZlbiBzbWFsbCBjb250aW51b3Vz IGxvc3MpLiBCdXQgd2hhdCBpZiBvbmUgQkZEIGZyYW1lIGlzIGxvc3QgZXZlcnkgdGhyZWUgZnJh bWVzPyBUaGVuIHRoZSBsb3NzIHJhdGUgaXMgMzAlIG9uIGF2ZXJhZ2UsIHdoaWNoIGlzIGFscmVh ZHkgYSB2ZXJ5IHNldmVyZSB2YWx1ZS4NCg0KQmVzdCByZWdhcmRzLA0KUGVuZw0KDQpGcm9tOiBN QUxMSUsgTVVESUdPTkRBIChtbXVkaWdvbikgW21haWx0bzptbXVkaWdvbkBjaXNjby5jb21dDQpT ZW50OiBGcmlkYXksIE5vdmVtYmVyIDI4LCAyMDE0IDc6NTMgUE0NClRvOiBGYW4sIFBlbmc7IHJ0 Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQkZE IHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIFBlbmcsDQoNCklmIHRoZSBC RkQgcGFja2V0cyBhcmUgbG9zdCwgZG9lc27igJl0IHRoZSBCRkQgc2Vzc2lvbiBnbyBET1dOPyBB cmUgeW91IHNheWluZyB0aGF0IHBhY2tldCBsb3NzIGlzIG5vdCBiaWcgZW5vdWdoIHRvIG1ha2Ug QkZEIHNlc3Npb24gZ28gRE9XTj8NCg0KVGhhbmtzDQoNClJlZ2FyZHMNCk1hbGxpaw0KDQpGcm9t OiA8RmFuPiwgUGVuZyA8ZmFucGVuZ0BjaGluYW1vYmlsZS5jb208bWFpbHRvOmZhbnBlbmdAY2hp bmFtb2JpbGUuY29tPj4NCkRhdGU6IEZyaWRheSwgMjggTm92ZW1iZXIgMjAxNCA0OjIwIHBtDQpU bzogInJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+IiA8cnRnLWJmZEBp ZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogQkZEIHN0YWJp bGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIEplZmYsIGFsbCwNCg0KSSBoYXZlIGJl ZW4gZm9sbG93aW5nIHRoaXMgc3RhYmlsaXR5IGV4dGVuc2lvbiBmcm9tIHRoZSBiZWdpbm5pbmcs IGFuZCBhcyBhbg0Kb3BlcmF0b3IgSSB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhhdCB0aGlzIGRy YWZ0IGVuYWJsZXMgdGhlICJhZHZhbmNlZA0KZmVhdHVyZSIgd2UgZGVzaXJlIGZvciBCRkQgdG8g cHJvdmlkZSBhZGRpdGlvbmFsIHVzZWZ1bCBpbmZvcm1hdGlvbiB0aGF0DQpoZWxwcyBvcGVyYXRv cnMgdW5kZXJzdGFuZCBuZXR3b3JrIGlzc3Vlcy4gQSByZWxldmFudCB1c2UgY2FzZSBpcyBkZXRl Y3RpbmcNCmxvc3N5IG9yICJxdWFzaS1kaXNjb25uZWN0ZWQiIGxpbmtzIG9yIG1lbWJlciBMQUcg bGlua3MuIEFuIGV4YW1wbGUgb2Ygc3VjaA0Kc2l0dWF0aW9uIHdlIGV4cGVyaWVuY2VkIHdhcyBh IGxvb3NlbHkgY29ubmVjdGVkIGZpYmVyIGxpbmsgcmVzdWx0aW5nIGluDQpjb250aW51b3VzLCBz bWFsbCBhbW91bnQgb2YgcGFja2V0IGxvc3MuIEJGRCBjb3VsZCBnZXQgdGhlIGluZm9ybWF0aW9u IG9mDQpsb3N0IEJGRCBmcmFtZXMgb24gc3VjaCB1bnN0YWJsZSBsaW5rLCBhbmQgcHJvYmFibHkg cmVwb3J0IHdoZW4gYSB0YXJnZXQNCmxldmVsIGlzIHJlYWNoZWQsIHNheSBhIGNlcnRhaW4gbnVt YmVyIG9mIGZyYW1lcyBhcmUgbG9zdCBvdmVyIGEgcGVyaW9kIG9yDQphbW9uZyBhIHRvdGFsIG51 bWJlciBvZiBmcmFtZXMuDQoNCkJlc3QgcmVnYXJkcywNClBlbmcNCg0KTWFoZXNoIEpldGhhbmFu ZGFuaQ0KQ28tY2hhaXIsIE5FVENPTkYgV0cNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg== --_000_7347100B5761DC41A166AC17F22DF1121B8AA754eusaamb103erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGkgTWFoZXNoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGNvbnNpZGVyIGlzc3Vl cyBvZiBkZWJ1Z2FiaWxpdHksIG5vdCBvZiBqdXN0IEJGRCBidXQgYW55IG90aGVyIHN0YW5kYXJk aXplZCBwcm90b2NvbCwgdG8gYmUgb3V0c2lkZSBvZiBTdGFuZGFyZCB0cmFjaywgYXQgbW9zdCB0 byBiZSBzdWl0YWJsZSBmb3IgSW5mb3JtYXRpb25hbA0KIG9yIEV4cGVyaW1lbnRhbCB0cmFjay4g SWYgd2UgYWdyZWUgb24gdGhhdCwgdGhlbiB3ZSBjYW4gZGlzY3VzcyBzY2VuYXJpb3MgdGhhdCBw cmVzZW50IHByb2JsZW0gYW5kIGludmVzdGlnYXRlIHdoZXRoZXIgYW55dGhpbmcgaW4gdGhlIHBy b3RvY29sIHJlcXVpcmVzIGNsYXJpZmljYXRpb24gdG8gaGVscCB2ZW5kb3JzIGluIGJ1aWxkaW5n IHdlbGwtcGVyZm9ybWluZywgc2NhbGFibGUgYW5kIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRp b25zIGFuZA0KIHByb3ZpZGUgb3BlcmF0aW9uYWwgZ3VpZGVsaW5lcyBmb3Igb3BlcmF0b3JzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gTWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDAyLCAyMDE0IDg6NDYg UE08YnI+DQo8Yj5Ubzo8L2I+IEdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+Q2M6PC9iPiBGYW4sIFBl bmc7IE1BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKTsgcnRnLWJmZEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3JlZyw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgaXMgUGVuZyByZWZl cnJpbmcgdG8gaXMgYSB3YXkgdG8gZmlndXJlIG91dCB3aHkgYSBwYXJ0aWN1bGFyIEJGRCBzZXNz aW9uIGZsYXBwZWQsIHBhcnRpY3VsYXJseSBpZiB0aGUgcGFja2V0KHMpIGZvciB0aGF0IHNlc3Np b24gYXJyaXZlIGxhdGUuIEkgZG8gbm90IHNlZSBob3cgdGhhdCBjYW4gYmUgcGVyZm9ybWFuY2Ug bWVhc3VyZW1lbnQuIEl0IGlzIGJhc2ljIEJGRCBkZWJ1ZyBhYmlsaXR5LiBSdW5uaW5nDQogYSBz ZXBhcmF0ZSBETSBkb2VzIHRlbGwgeW91IHdoeSBhIHBhcnRpY3VsYXIgQkZEIHNlc3Npb24gZmxh cHBlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Tm93IHdlIGNhbiBkZWJhdGUgd2hhdCBtZXRob2RzIGNhbiBiZSBlbXBsb3llZCB0byBtZWFz dXJlIHRoYXQgZGVsYXkgYW5kIEkgYW0gb3BlbiB0byB3YXlzIHRvIGRvaW5nIGl0LCBpbmNsdWRp bmcgbG9jYWwgbG9vcGJhY2sgdG8gbWVhc3VyZSB0cmFuc21pdCBkZWxheXMgb3IgdGltZSBzdGFt cGluZyBvZiBwYWNrZXRzIGluIGhhcmR3YXJlLiBCdXQgaW4gY2FzZXMsIHdoZXJlIHRoZXJlIGlz IG5vIHN1cHBvcnQNCiBmb3IgZWl0aGVyIG9mIHRoZSBjYXBhYmlsaXRpZXMsIG9uZSBvZiB0aGUg c3VnZ2VzdGVkIHNvbHV0aW9ucyBpcyB0byB1c2UgdGhlIHRpbWUgc3RhbXBzIGNhcnJpZWQgaW4g dGhlIEJGRCBwYXlsb2FkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBEZWMgMSwgMjAxNCwgYXQgOTozOCBBTSwgR3Jl Z29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b20iPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFBlbmcsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPmFuZCBzdGlsbCwgeW914oCZcmUgbG9va2luZyBmb3IgYSB0b29s IHRvIG1lYXN1cmUgQkZEIHBlcmZvcm1hbmNlLiBUaGVuIHlvdeKAmWxsIGJlIGxvb2tpbmcgZm9y IGEgdG9vbCB0byB2ZXJpZnkgdGhlIEJGRCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCwgYW5kIG9u LCBhbmQgb24uDQogT3BlcmF0b3JzIGRvIG5lZWQgY29tcGxldGUgc2V0IG9mIEZDQVBTIHRvb2xz LCBpbmNsdWRpbmcgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQuIE5vdGUgdGhhdCBwYXNzaXZlIHBl cmZvcm1hbmNlIG1lYXN1cmVtZW50IHRocm91Z2ggbWFya2luZyBtZXRob2QgdGhhdCBNYWNoIENo ZW4gcmVmZXJyZWQgdG8gY2FuIG1vbml0b3IgQkZEIGZsb3cocykgYW5kIGJlIHVzZWQgdG8gZG8g TG9zcyBhbmQvb3IgRGVsYXkgTWVhc3VyZW1lbnQuIEFuZCBhY3RpdmUNCiBTeW50aGV0aWMgTG9z cyBNZWFzdXJlbWVudCBtYXkgc2ltdWxhdGUgZmxvdyBvZiBzbWFsbCBwYWNrZXRzIGFzIHdlbGwg YXMgcmVsYXRpdmVseSBsYXJnZSBwYWNrZXRzLiBBbmQgdGhlIHNhbWUgZ29lcyBmb3IgYWN0aXZl IG1lYXN1cmVtZW50IG1ldGhvZCBvZiBEZWxheSBNZWFzdXJlbWVudC4gSSBsaWtlIFN3aXNzIEFy bXkga25pdmVzIGJ1dCBsZXQgdXMgbm90IHR1cm4gQkZEIGludG8gb25lLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GYW4sDQogUGVuZyBbPGEg aHJlZj0ibWFpbHRvOmZhbnBlbmdAY2hpbmFtb2JpbGUuY29tIj5tYWlsdG86ZmFucGVuZ0BjaGlu YW1vYmlsZS5jb208L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBEZWNlbWJlciAwMSwgMjAxNCA0OjQ0IEFNPGJyPg0K PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5HcmVnb3J5IE1pcnNreTsgJ01BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKSc7DQo8YSBocmVm PSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+cnRnLWJmZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+UkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBHcmVn b3J5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3YXMganVzdCBn aXZpbmcgYW4gZXhhbXBsZSA6KSBBcHBsaWNhdGlvbiB0cmFmZmljIHVzdWFsbHkgY2Fubm90IHN0 YW5kIHNtYWxsIHBhY2tldCBsb3NzLCBub3QgdG8gc2F5IDMwJSBsb3NzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBhY3R1YWxseSBhc2tpbmcgZm9yIGEgZGVi dWcgZnVuY3Rpb24gdGhhdCBjb3VsZCBnaXZlIHVzIHNvbWUgdXNlZnVsIGhpbnRzIG9mIHBvb3Ig Y29ubmVjdGlvbiB3aXRoIHNtYWxsIHByb3RvY29sIGNoYW5nZSwgYmVzaWRlcyB0aGUgYmFzaWMg Y29ubmVjdGl2aXR5DQogaW5mb3JtYXRpb24uIElmIGl0IG1lYXN1cmVzIHNvbWV0aGluZywgaXQg bWVhc3VyZXMgcGFja2V0cyBvZiBCRkQgaXRzZWxmLiBTbyBJIGRvbuKAmXQgZXhwZWN0IGl0IHRv IGJlIGNvbnNpZGVyZWQgYXMgYSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCB0b29sLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZW5nPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5HcmVnb3J5DQogTWlyc2t5IFs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nz b24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86Z3JlZ29yeS5taXJza3lA ZXJpY3Nzb24uY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TYXR1cmRheSwgTm92ZW1iZXIgMjksIDIwMTQgMzoz NyBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+RmFuLCBQZW5nOyAnTUFMTElLIE1VRElHT05EQSAobW11ZGlnb24pJzs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Zy1iZmRA aWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ct dXAgZnJvbSBJRVRGLTkxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFBlbmcsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoaXMgaXMgdmVyeSBpbnRlcmVzdGluZyBzY2VuYXJpby4gSSB0 aGluayB0aGF0IGlmIEJGRCBleHBlcmllbmNlcyB+MzAlIHBhY2tldCBsb3NzLCB0aGVuIGhpZ2hs eSBsaWtlbHkgc28gYXJlIGFmZmVjdGVkIG90aGVyIGFwcGxpY2F0aW9ucy4gVGhlbiBpdCBpcyBu b3QganVzdA0KIEJGRCBpc3N1ZSBidXQgY29uZGl0aW9uIHRoYXQgc2hvdWxkIGJlIGRldGVjdGVk Jm5ic3A7IGJ5IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IG1ldGhvZCwgd2hldGhlciBhY3RpdmUg b3IgcGFzc2l2ZSBwYWNrZXQgbG9zcyBtZWFzdXJlbWVudC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gY29udmluY2VkIHRoYXQgb3ZlcmxvYWRpbmcg QkZEIHdpdGggcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgcHJvdmlzaW9ucyBpcyBjb3VudGVyLXBy b2R1Y3RpdmUgYW5kIGlzIGluYXBwcm9wcmlhdGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJ0Zy1iZmQNCiBbPGEgaHJlZj0ibWFpbHRvOnJ0 Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRv OnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkZhbiwgUGVuZzxicj4NCjxi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5GcmlkYXksIE5vdmVtYmVyIDI4LCAyMDE0IDQ6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPidNQUxMSUsgTVVESUdP TkRBIChtbXVkaWdvbiknOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBC RkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFsbGlrLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXhhY3RseS4gUGFja2V0cyBtYXkg YmUgZXhwZXJpZW5jaW5nIHNsaWdodCBsb3NzLCBidXQgdGhlIGxpbmsgY2FuIGhhcmRseSBiZSBy ZWdhcmRlZCBhcyBjb25uZWN0ZWQuIE1vcmUgaW1wb3J0YW50bHksIHRoZSBleHBlcmllbmNlIG9m IHVwcGVyLWxldmVsIGFwcGxpY2F0aW9ucw0KIGNhbiBiZSBkZWdyYWRlZCBzZXZlcmVseSAoZS5n LiBUQ1AgdHJhZmZpYyBpcyBub3QgYWJsZSB0byBnbyBmYXN0IGluIGZhY2Ugb2YgZXZlbiBzbWFs bCBjb250aW51b3VzIGxvc3MpLiBCdXQgd2hhdCBpZiBvbmUgQkZEIGZyYW1lIGlzIGxvc3QgZXZl cnkgdGhyZWUgZnJhbWVzPyBUaGVuIHRoZSBsb3NzIHJhdGUgaXMgMzAlIG9uIGF2ZXJhZ2UsIHdo aWNoIGlzIGFscmVhZHkgYSB2ZXJ5IHNldmVyZSB2YWx1ZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TUFMTElLDQogTVVE SUdPTkRBIChtbXVkaWdvbikgWzxhIGhyZWY9Im1haWx0bzptbXVkaWdvbkBjaXNjby5jb20iPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzptbXVkaWdvbkBjaXNjby5jb208L3NwYW4+ PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPkZyaWRheSwgTm92ZW1iZXIgMjgsIDIwMTQgNzo1MyBQTTxicj4NCjxiPlRvOjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RmFuLCBQZW5n OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRn LWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBCRkQgc3RhYmlsaXR5IGZv bGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SGkgUGVuZyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5JZiB0aGUgQkZEIHBhY2tldHMgYXJlIGxvc3QsIGRvZXNu4oCZdCB0aGUgQkZEIHNl c3Npb24gZ28gRE9XTj8gQXJlIHlvdSBzYXlpbmcgdGhhdCBwYWNrZXQgbG9zcyBpcyBub3QgYmln IGVub3VnaCB0byBtYWtlIEJGRCBzZXNzaW9uIGdvIERPV04/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pk1hbGxpazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmx0O0Zh biZndDssIFBlbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpmYW5wZW5nQGNoaW5hbW9iaWxlLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZmFucGVuZ0BjaGluYW1vYmlsZS5jb208L3NwYW4+ PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L2I+RnJpZGF5LCAyOCBOb3ZlbWJlciAyMDE0IDQ6MjAgcG08YnI+DQo8 Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9i PiZxdW90OzxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5ydGctYmZkQGlldGYub3JnPC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpydGctYmZkQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGct YmZkQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJFOiBCRkQgc3RhYmlsaXR5 IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkhpIEplZmYsIGFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5JIGhhdmUgYmVlbiBmb2xsb3dpbmcgdGhpcyBzdGFiaWxpdHkgZXh0ZW5z aW9uIGZyb20gdGhlIGJlZ2lubmluZywgYW5kIGFzIGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+b3BlcmF0b3IgSSB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhh dCB0aGlzIGRyYWZ0IGVuYWJsZXMgdGhlICZxdW90O2FkdmFuY2VkPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZmVhdHVyZSZxdW90OyB3ZSBkZXNpcmUgZm9yIEJG RCB0byBwcm92aWRlIGFkZGl0aW9uYWwgdXNlZnVsIGluZm9ybWF0aW9uIHRoYXQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5oZWxwcyBvcGVyYXRvcnMgdW5kZXJz dGFuZCBuZXR3b3JrIGlzc3Vlcy4gQSByZWxldmFudCB1c2UgY2FzZSBpcyBkZXRlY3Rpbmc8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5sb3NzeSBvciAmcXVvdDtx dWFzaS1kaXNjb25uZWN0ZWQmcXVvdDsgbGlua3Mgb3IgbWVtYmVyIExBRyBsaW5rcy4gQW4gZXhh bXBsZSBvZiBzdWNoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ c2l0dWF0aW9uIHdlIGV4cGVyaWVuY2VkIHdhcyBhIGxvb3NlbHkgY29ubmVjdGVkIGZpYmVyIGxp bmsgcmVzdWx0aW5nIGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Y29udGludW91cywgc21hbGwgYW1vdW50IG9mIHBhY2tldCBsb3NzLiBCRkQgY291bGQgZ2V0 IHRoZSBpbmZvcm1hdGlvbiBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmxvc3QgQkZEIGZyYW1lcyBvbiBzdWNoIHVuc3RhYmxlIGxpbmssIGFuZCBwcm9iYWJs eSByZXBvcnQgd2hlbiBhIHRhcmdldDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPmxldmVsIGlzIHJlYWNoZWQsIHNheSBhIGNlcnRhaW4gbnVtYmVyIG9mIGZyYW1l cyBhcmUgbG9zdCBvdmVyIGEgcGVyaW9kIG9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+YW1vbmcgYSB0b3RhbCBudW1iZXIgb2YgZnJhbWVzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QZW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPk1haGVzaCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNvLWNo YWlyLCBORVRDT05GIFdHPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWls dG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B8AA754eusaamb103erics_-- From nobody Wed Dec 3 16:35:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22E71AD03C for ; Wed, 3 Dec 2014 16:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 bBcI5F1rPaXY for ; Wed, 3 Dec 2014 16:34:31 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F3D1AD034 for ; Wed, 3 Dec 2014 16:34:31 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so6741088wid.5 for ; Wed, 03 Dec 2014 16:34:30 -0800 (PST) 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 :content-type; bh=AL73h0EXWkHX5vxyBQHzJ/3ma1h/IOIAnewMbJ3wfOM=; b=Xa1Qfb4GxntjfJlYz7lwAt4jknPs0vl6lYoT91Bmw97wSIV1cnLKxyZ7lUokLzQzDL 9Zsh8Hys4FpON7+qZJPaUm09RBUFxvTGj994ksVKE5FgJg+qgePIyHsDKviLGxtNYrig ptItk0JPej25xrjuSWVixKEXYNTWQH/CfWjf1b0VT5kWrJiTTLYMERljgpwfg7mvCEST JKd9GsOqisC2TFeoE6MLKMC+tR4G4RyV088X8YhzuWM4EI54ytccdezFhIzT9A1Jt292 GP3DeG8yEnNE1bNVThHGV8myolG9DzvoNPMxh/NNdw1ACPk05PqHe7VW3WdRP+ILJ3E8 Cx+A== MIME-Version: 1.0 X-Received: by 10.180.73.175 with SMTP id m15mr17492560wiv.0.1417653269956; Wed, 03 Dec 2014 16:34:29 -0800 (PST) Received: by 10.194.14.130 with HTTP; Wed, 3 Dec 2014 16:34:29 -0800 (PST) In-Reply-To: <1693791C-89AF-4023-9FCE-013F2532927E@gmail.com> References: <20141124194751.GD28464@pfrc> <1693791C-89AF-4023-9FCE-013F2532927E@gmail.com> Date: Wed, 3 Dec 2014 16:34:29 -0800 Message-ID: Subject: Fwd: BFD statistics for BFD-MPLS sessions (fate of MIB) From: venkatesan mahalingam To: Jeffrey Haas , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7e52920c0f0509591f03 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VA5cyJqo1MlKFoC1fQhWN54apwE X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 00:34:34 -0000 --f46d043c7e52920c0f0509591f03 Content-Type: text/plain; charset=UTF-8 Hi Jeff, Thanks for questions. Sorry for the delayed response. Does your implementation provide statistics for connectivity issues in your UI for BFD over MPLS sessions? Yes. Our implementation provides statistics for connectivity issues. >> Let's use these data points to discuss whether the WG will continue to spend >> effort on the MIB. Sure. We are pretty much done the MIB work for BFD over MPLS sessions, please take this MIB to the next level. -Venkat. *From:* Jeffrey Haas *Date:* November 24, 2014 at 11:47:51 AM PST *To:* rtg-bfd@ietf.org *Subject:* *BFD statistics for BFD-MPLS sessions (fate of MIB)* Working Group, One of the topics broached during our status update at IETF-91 was the fate of the BFD MPLS MIB. ( https://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-04) MIBs often don't get a lot of attention within IETF and there is often a cyclic dependency issue for customer demand based on the publication of an RFC, but no demand because there's no RFC. There is also the issue that while BFD for MPLS is obviously a popular protocol and supported across multiple vendors, MIBs are being generally supplanted by Yang. However, existing operational infrastructure still heavily depends on SNMP polling. ------8<---- cut here ---->8------ I would like to thus turn this into a different question: Does your implementation provide statistics for connectivity issues in your UI for BFD over MPLS sessions? If so, please compare them to the performance counters in the MIB. ------8<---- cut here ---->8------ The MIB obviously covers additional information, but performance counters are usually the primary motivator for the MIB. Let's use these data points to discuss whether the WG will continue to spend effort on the MIB. -- Jeff --f46d043c7e52920c0f0509591f03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jeff,

Thanks for questions. Sorry fo= r the delayed response.
Does your imple= mentation provide statistics for connectivity issues in your
UI for BFD = over MPLS sessions?

Yes. Our implementation provides statistics for = connectivity issues.

>> Let's use these data points to dis= cuss whether the WG will continue to spend
>> effort on t= he MIB.

Sure. We are pretty much done the MIB work for BFD over MPLS= sessions, please take this MIB to the next level.

-Venkat.
From: Jeffrey Haas <jhaas@pfrc.org>
Date:= November 24, 2014 at 11:47:51 AM PST
To: rtg-bfd@ietf.org
Subject: B= FD statistics for BFD-MPLS sessions (fate of MIB)

<= blockquote type=3D"cite">
Working Group,
<= br>One of the topics broached during our status update at IETF-91 was= the fate
of the BFD MPLS MIB. =C2=A0(https://too= ls.ietf.org/html/draft-ietf-bfd-mpls-mib-04)
MIBs often don't get a lot of attention within IETF and there is= often a
cyclic dependency issue for customer demand based = on the publication of an
RFC, but no demand because there&#= 39;s no RFC. =C2=A0

There is also the issu= e that while BFD for MPLS is obviously a popular
protocol a= nd supported across multiple vendors, MIBs are being generally
supplanted by Yang.=C2=A0 However, existing operational infrastructure = still
heavily depends on SNMP polling.

------8<---- cut here ---->8------

I would like to thus turn this into a different question:

Does your implementation provide statistics for= connectivity issues in your
UI for BFD over MPLS sessions?=

If so, please compare them to the perform= ance counters in the MIB.

------8<---- = cut here ---->8------

The MIB obviously= covers additional information, but performance counters
ar= e usually the primary motivator for the MIB.

Let's use these data points to discuss whether the WG will continue = to spend
effort on the MIB.

-- Jeff


--f46d043c7e52920c0f0509591f03-- From nobody Wed Dec 3 21:53:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3233C1A88C7 for ; Wed, 3 Dec 2014 21:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 NTumzMIz3ytW for ; Wed, 3 Dec 2014 21:53:41 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855531A87AD for ; Wed, 3 Dec 2014 21:53:40 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 05:53:37 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 4 Dec 2014 05:53:37 +0000 From: Santosh P K To: Gregory Mirsky , Marc Binderberger , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuCAAAvZAIAF49GAgANl6hCAAHr8gIAAli8Q Date: Thu, 4 Dec 2014 05:53:37 +0000 Message-ID: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <20141201013841551442.5a9df5b9@sniff.de> <7347100B5761DC41A166AC17F22DF1121B8AA51B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AA51B@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(189002)(199003)(51704005)(54356999)(76176999)(561944003)(50986999)(62966003)(74316001)(68736005)(66066001)(64706001)(86362001)(20776003)(77096005)(33656002)(101416001)(15975445006)(107046002)(31966008)(77156002)(106356001)(99286002)(95666004)(105586002)(106116001)(15202345003)(122556002)(40100003)(76576001)(46102003)(92726001)(92566001)(4396001)(1720100001)(21056001)(97736003)(120916001)(87936001)(93886004)(19580395003)(19580405001)(2656002)(99396003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4vrRw0PBhexm-OcV2faOAnUcAu4 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 05:53:44 -0000 Greg, I don't think we have discussed about echo in this context. Echo is good= thing but payload of BFD echo packet is decided by local system. Did you m= ean to add suggestion on how echo packet should look like? Or how echo can = help in BFD loss/delay issue?=20 Thanks Santosh P K =20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, December 04, 2014 2:22 AM > To: Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Dear All, > had authors of the proposal or we already dismissed use of BFD Echo? I've > scanned the thread and couldn't find trace of us discussing BFD Echo mode= . I > think that it is more suitable for experimentation and unorthodox use. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K > Sent: Wednesday, December 03, 2014 5:39 AM > To: Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Hello Manav and Marc, >=20 >=20 > > > One way to solve this problem is by attaching a debug trailer that > > > only carries the seq numbers at the *end* of the BFD packet. This > > > would not be covered in the Length field carried in the BFD header > > > but would be accounted for in the length carried in the IP header. > > > > BFD itself is not related to IP, i.e. there is not always an IP header. > > Sure, the encapsulating "frame" may provide a length but actually, why > > not covering the debug trailer with the BFD length? > > > > If this is solely for debug purpose than this may work. For simple > > copying-out into e.g. a packet trace buffer it would be even simpler > > to have the BFD length covering the trailer. > > If hardware is supposed to process the trailer information (other than > > copying out) then it's getting ugly - having fixed position, fixed > > length extension headers would be preferable for simple access. >=20 > Fixed length would be easy to process in hardware. Problem is when we > have many have extensions in future. If we want to use only one extension > that is at the last then I will be forced to pad all the other extension = ahead of > it? This might not be a problem if we have fewer extensions but might > become problem when there are too many extensions. >=20 >=20 > > > > Another idea is to use the 0x80 bit of the auth type to distinguish > > between a "normal" authentication header and a "sequence + > authentication". > > >=20 > I think this is good. In the BFD extension TLV we still have many reserve= d bits > that can be used as well? >=20 > Thanks > Santosh P K >=20 >=20 >=20 > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > Hi Santosh, > > > > > > You could use the crypto sequence numbers carried in the meticulous > > > cryptographic auth for detecting packet losses. However, this breaks > > > when you use non-meticulous crypto authentication since the sequence > > > number is only incremented occasionally there. This i believe is a > > > deal breaker since i really envision non meticulous mode to be the > > > one being widely deployed. In fact we were supposed to write a draft > > > on that and i guess it just fell through the cracks (lemme ping my > > > co-author on that !) > > > > > > One way to solve this problem is by attaching a debug trailer that > > > only carries the seq numbers at the *end* of the BFD packet. This > > > would not be covered in the Length field carried in the BFD header > > > but would be accounted for in the length carried in the IP header. > > > The concept of attaching a trailer is documented well and is used in > > > the IGPs. RFC 6506 describes one such trailer for OSPFv3. The catch > > > however is that this debug trailer will NOT be covered by the BFD > > > authentication. Is this acceptable to the WG? > > > > > > I think the problem of diagnosing a BFD flap becomes all the more > > > important with BFD authentication turned on since then we have more > > > points where a delay can be inserted. > > > > > > Cheers, Manav > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > wrote: > > >> Manav, > > >> This is good question. > > >> > > >>> Can the authors add some text on how this debugging mechanism > > >>> would work if somebody employs BFD authentication? > > >> > > >> Right now we have considered without authentication (we are setting > > >> A bit). We should add some text on how we can use both Auth and de > > >> bug > > TLV. > > >> Is there any suggestion you have? I will get back to you on this. > > >> > > >> > > >> Thanks > > >> Santosh P K > > >> > > >>>> -----Original Message----- > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach > > Chen > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > >>>> To: Marc Binderberger > > >>>> Cc: rtg-bfd@ietf.org > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>> > > >>>> Hi Marc, > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > >>>>> To: Mach Chen > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>>> > > >>>>> Hello Mach, > > >>>>> > > >>>>>> This triggers me think out there should be another solution for > > >>>>>> getting the Tx and Rx timestamps without encoding the > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > >>>>>> locally or send them to a centralized entity and then use the > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>> > > >>>>> I remember some discussion on NVO3 about how many bits it takes > > >>>>> ;- > > ) - > > >>>>> could you send the links/draft names you are working on to this l= ist? > > >>>>> May be useful for further discussions. > > >>>> > > >>>> Sure, here is the > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > >>> based-ipfpm-framework-02) for the reference. > > >>>> > > >>>> But here I want to say is that since we have sequence number, we > > >>>> may > > not > > >>> need the marking based solution. Suppose that someone want to > > monitor > > >>> the delay of a BFD packet , just record and save the timestamp at > > >>> the Tx side, which indexed by the sequence number. Similarly, do > > >>> the same at the Rx side. Then based on the timestamps from both Tx > > >>> and Rx, and using the sequence number to correlate the timestamps, > > >>> it can also provide a way > > to > > >>> monitor the delay of the BFD packet. > > >>>> > > >>>> That means, only if there is sequence number, even if without > > >>>> carrying the > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > >>>> > > >>>> Best regards, > > >>>> Mach > > >>>> > > >>>>> > > >>>>> > > >>>>> Thanks & Regards, > > >>>>> Marc > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > >>>>>> Hi Marc and Manav, > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > Marc > > >>>>>>> Binderberger > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > >>>>>>> To: Manav Bhatia > > >>>>>>> Cc: rtg-bfd@ietf.org > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > >>>>>>> > > >>>>>>> Hello Manav, > > >>>>>>> > > >>>>>>>> I believe the work is important and addresses something thats > > >>>>>>>> really required (spent too much time debugging why BFD > > flapped!). > > >>>>>>> > > >>>>>>> agree :-) we should keep the discussion alive. > > >>>>>>> > > >>>>>>> > > >>>>>>>> side Time stamping would have helped in debugging whether > the > > >>> BFD > > >>>>>>>> packet was sent late, or whether the packet was sent on time > > >>>>>>>> and also arrived on time but was delayed when passing it up > > >>>>>>>> the BFD stack/processor (lay in the RX buffer for tad too > > >>>>>>>> long) > > >>>>>>> > > >>>>>>> well, I can see a point in having the Tx timestamps in the > > >>>>>>> packet mainly for the purpose of knowing "this" packet was > > >>>>>>> okay/not okay on the Tx side and to correlate it with your loca= l Rx > measurement. > > >>>>>> > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > >>>>>> If allow to have Tx timestamps to be carried in the packets, > > >>>>>> seems it should be no problem to leave a seat for the Rx > > >>>>>> timestamps as well :-). After all, with both Tx and Rx > > >>>>>> timestamp, it may simplify the > > >>>>> implementation. > > >>>>>> > > >>>>>>> > > >>>>>>> And even this point is less relevant with sequence numbers as > > >>>>>>> this number allows the identification of packets and thus the > > >>>>>>> correlation of information from the Tx and Rx system. > > >>>>>> > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > between > > >>>>>> the Tx and Rx system. > > >>>>>> > > >>>>>> This triggers me think out there should be another solution for > > >>>>>> getting the Tx and Rx timestamps without encoding the > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > >>>>>> locally or send them to a centralized entity and then use the > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Mach > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Regards, Marc > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > >>>>>>>> Hi Jeff, > > >>>>>>>> > > >>>>>>>> I vividly remember the original intent of the stability draft > > >>>>>>>> was to help debug BFD failures -- to isolate the issue at the > > >>>>>>>> RX or the TX side Time stamping would have helped in > > >>>>>>>> debugging > > whether > > >>>>>>>> the BFD packet was sent late, or whether the packet was sent > > >>>>>>>> on time and also arrived on time but was delayed when passing > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad > > >>>>>>>> too long), etc. But then time stamping came with its own set > > >>>>>>>> of issues, and was hence dropped from the original draft. > > >>>>>>>> > > >>>>>>>> Can the authors send a summary on the list on why time > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > >>>>>>>> > > >>>>>>>> The current proposal does help but is not complete. > > >>>>>>>> > > >>>>>>>> Assume that the RX end loses a BFD session and learns later > > >>>>>>>> that it did eventually receive the missing BFD packets (based > > >>>>>>>> on the > > seq > > >>> #). > > >>>>>>>> How would it know which end was misbehaving? Was it a delay > > >>>>>>>> at the TX side, or was it the RX that delayed passing the > > >>>>>>>> packets to the BFD process(or). This is usually what we want > > >>>>>>>> to debug and i want to understand how this draft with > > >>>>>>>> sequence numbers can unequivocally tell me that. > > >>>>>>>> > > >>>>>>>> I believe the work is important and addresses something thats > > >>>>>>>> really required (spent too much time debugging why BFD > > flapped!). > > >>>>>>>> Clearly what would help is putting a small section that > > >>>>>>>> describes how we can use the sequence numbers to debug > what > > >>>>>>>> and > > where > > >>> things went wrong. > > >>>>>>>> > > >>>>>>>> Cheers, Manav > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > > >>>>>>>> > > >>> wrote: > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > >>>>>>>>> > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pp > > >>>>>>>>> tx > > >>>>>>>>> > > >>>>>>>>> To attempt to simplify the presentation, the contentious > > >>>>>>>>> portion of the timers were removed from the proposal, > > >>>>>>>>> leaving only the sequence numbering for detecting loss of BFD > async packets. > > >>>>>>>>> > > >>>>>>>>> When the room was polled to see whether the draft should be > > >>>>>>>>> adopted as a WG item, the sense of the room was very quiet. > > >>>>>>>>> As promised, this is to inquire for support for this draft > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > voice. > > >>>>>>>>> > > >>>>>>>>> It should be noted that post-meeting discussion on the fate > > >>>>>>>>> of this draft noted that BFD authentication code points are > > >>>>>>>>> plentiful and are available with expert review. Should the > > >>>>>>>>> draft authors wish to continue this work as Experimental, > > >>>>>>>>> that is > > an > > >>> option. > > >>>>>>>>> > > >>>>>>>>> -- Jeff > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > From nobody Wed Dec 3 22:13:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D131A88C3 for ; Wed, 3 Dec 2014 22:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 0DzBj4v11PAe for ; Wed, 3 Dec 2014 22:13:42 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 A92841A88C8 for ; Wed, 3 Dec 2014 22:13:42 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-17-547f9f57895a Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BC.08.25146.75F9F745; Thu, 4 Dec 2014 00:40:07 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 01:13:39 -0500 From: Gregory Mirsky To: Santosh P K , Marc Binderberger , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQDUqXQ6amXjPuFEmbPIOgLl4p2px+NluAgAAjMzCAAOz5gP//rP5g Date: Thu, 4 Dec 2014 06:13:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AA9A5@eusaamb103.ericsson.se> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <20141201013841551442.5a9df5b9@sniff.de> <7347100B5761DC41A166AC17F22DF1121B8AA51B@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXRPgm74/PoQg09PzSwuT2pjt5h95T+z xec/2xgtrt3dyuzA4rFz1l12jyVLfjJ5XG+6yu7RurqbJYAlissmJTUnsyy1SN8ugSvj9c8T jAX/Cyo2P73I2sB4OKKLkZNDQsBE4uWpNywQtpjEhXvr2boYuTiEBI4wSlw7fIIRwlnGKLGl r5kVpIpNwEjixcYedhBbRKBIYtbsh2BxZgFNiaYTn8HiwgKGEqu6F0PVGEkcmzEXynaT6Nr+ FWgbBweLgIrE4h4fkDCvgK/EhmNToHZNY5e4uuE+2EWcAvESdx9sAJvPCHTd91NrmCB2iUvc ejKfCeJqAYkle84zQ9iiEi8f/2OFsJUk5ry+xgxRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIy gVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UaGmxiB8XRMgs1xB+OCT5aHGAU4GJV4eDfE 1ocIsSaWFVfmHmKU5mBREufVrJ4XLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRsOJKJqdd nmwyo8G6Qv+KlclcifcdsyrsK27f2xywYK3DuvrDx670q5ZW8ISLrm4TffTifsLKB5JMuoxX rYQ0ne5lbF9wRePpZx3d5ACOoxtC1H+v0mCdulg3upkp9rbRCQuNGfPP2DObmde4zgs0aCk0 jLV7Xvnv5h2Fxv1r0lYVMal21SixFGckGmoxFxUnAgBiOx3TiAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KJZgocuG7E59ZFnNF0G6AZjE5Xs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 06:13:46 -0000 Hi Santosh, yes, the format and thus interpretation of payload in Echo mode is not defi= ned and that, in my view, is what we need - some open space. And Echo well = could be exactly that - no legacy, no backward compatibility (addressee tha= t doesn't support "extended Echo" will simply loop the packet back to sende= r). Perhaps that will be direction we can discuss and, hopefully, agree on. Regards, Greg -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Wednesday, December 03, 2014 9:54 PM To: Gregory Mirsky; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Greg, I don't think we have discussed about echo in this context. Echo is good= thing but payload of BFD echo packet is decided by local system. Did you m= ean to add suggestion on how echo packet should look like? Or how echo can = help in BFD loss/delay issue?=20 Thanks Santosh P K =20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, December 04, 2014 2:22 AM > To: Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Dear All, > had authors of the proposal or we already dismissed use of BFD Echo?=20 > I've scanned the thread and couldn't find trace of us discussing BFD=20 > Echo mode. I think that it is more suitable for experimentation and unort= hodox use. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P=20 > K > Sent: Wednesday, December 03, 2014 5:39 AM > To: Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Hello Manav and Marc, >=20 >=20 > > > One way to solve this problem is by attaching a debug trailer that=20 > > > only carries the seq numbers at the *end* of the BFD packet. This=20 > > > would not be covered in the Length field carried in the BFD header=20 > > > but would be accounted for in the length carried in the IP header. > > > > BFD itself is not related to IP, i.e. there is not always an IP header. > > Sure, the encapsulating "frame" may provide a length but actually,=20 > > why not covering the debug trailer with the BFD length? > > > > If this is solely for debug purpose than this may work. For simple=20 > > copying-out into e.g. a packet trace buffer it would be even simpler=20 > > to have the BFD length covering the trailer. > > If hardware is supposed to process the trailer information (other=20 > > than copying out) then it's getting ugly - having fixed position,=20 > > fixed length extension headers would be preferable for simple access. >=20 > Fixed length would be easy to process in hardware. Problem is when we=20 > have many have extensions in future. If we want to use only one=20 > extension that is at the last then I will be forced to pad all the=20 > other extension ahead of it? This might not be a problem if we have=20 > fewer extensions but might become problem when there are too many extensi= ons. >=20 >=20 > > > > Another idea is to use the 0x80 bit of the auth type to distinguish=20 > > between a "normal" authentication header and a "sequence + > authentication". > > >=20 > I think this is good. In the BFD extension TLV we still have many=20 > reserved bits that can be used as well? >=20 > Thanks > Santosh P K >=20 >=20 >=20 > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > Hi Santosh, > > > > > > You could use the crypto sequence numbers carried in the=20 > > > meticulous cryptographic auth for detecting packet losses.=20 > > > However, this breaks when you use non-meticulous crypto=20 > > > authentication since the sequence number is only incremented=20 > > > occasionally there. This i believe is a deal breaker since i=20 > > > really envision non meticulous mode to be the one being widely=20 > > > deployed. In fact we were supposed to write a draft on that and i=20 > > > guess it just fell through the cracks (lemme ping my co-author on=20 > > > that !) > > > > > > One way to solve this problem is by attaching a debug trailer that=20 > > > only carries the seq numbers at the *end* of the BFD packet. This=20 > > > would not be covered in the Length field carried in the BFD header=20 > > > but would be accounted for in the length carried in the IP header. > > > The concept of attaching a trailer is documented well and is used=20 > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The=20 > > > catch however is that this debug trailer will NOT be covered by=20 > > > the BFD authentication. Is this acceptable to the WG? > > > > > > I think the problem of diagnosing a BFD flap becomes all the more=20 > > > important with BFD authentication turned on since then we have=20 > > > more points where a delay can be inserted. > > > > > > Cheers, Manav > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K=20 > > > > > wrote: > > >> Manav, > > >> This is good question. > > >> > > >>> Can the authors add some text on how this debugging mechanism=20 > > >>> would work if somebody employs BFD authentication? > > >> > > >> Right now we have considered without authentication (we are=20 > > >> setting A bit). We should add some text on how we can use both=20 > > >> Auth and de bug > > TLV. > > >> Is there any suggestion you have? I will get back to you on this. > > >> > > >> > > >> Thanks > > >> Santosh P K > > >> > > >>>> -----Original Message----- > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > > >>>> Mach > > Chen > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > >>>> To: Marc Binderberger > > >>>> Cc: rtg-bfd@ietf.org > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>> > > >>>> Hi Marc, > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > >>>>> To: Mach Chen > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>>> > > >>>>> Hello Mach, > > >>>>> > > >>>>>> This triggers me think out there should be another solution=20 > > >>>>>> for getting the Tx and Rx timestamps without encoding the=20 > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps=20 > > >>>>>> locally or send them to a centralized entity and then use the=20 > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>> > > >>>>> I remember some discussion on NVO3 about how many bits it=20 > > >>>>> takes > > >>>>> ;- > > ) - > > >>>>> could you send the links/draft names you are working on to this l= ist? > > >>>>> May be useful for further discussions. > > >>>> > > >>>> Sure, here is the > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > >>> based-ipfpm-framework-02) for the reference. > > >>>> > > >>>> But here I want to say is that since we have sequence number,=20 > > >>>> we may > > not > > >>> need the marking based solution. Suppose that someone want to > > monitor > > >>> the delay of a BFD packet , just record and save the timestamp=20 > > >>> at the Tx side, which indexed by the sequence number. Similarly,=20 > > >>> do the same at the Rx side. Then based on the timestamps from=20 > > >>> both Tx and Rx, and using the sequence number to correlate the=20 > > >>> timestamps, it can also provide a way > > to > > >>> monitor the delay of the BFD packet. > > >>>> > > >>>> That means, only if there is sequence number, even if without=20 > > >>>> carrying the > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > >>>> > > >>>> Best regards, > > >>>> Mach > > >>>> > > >>>>> > > >>>>> > > >>>>> Thanks & Regards, > > >>>>> Marc > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > >>>>>> Hi Marc and Manav, > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > Marc > > >>>>>>> Binderberger > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > >>>>>>> To: Manav Bhatia > > >>>>>>> Cc: rtg-bfd@ietf.org > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > >>>>>>> > > >>>>>>> Hello Manav, > > >>>>>>> > > >>>>>>>> I believe the work is important and addresses something=20 > > >>>>>>>> thats really required (spent too much time debugging why=20 > > >>>>>>>> BFD > > flapped!). > > >>>>>>> > > >>>>>>> agree :-) we should keep the discussion alive. > > >>>>>>> > > >>>>>>> > > >>>>>>>> side Time stamping would have helped in debugging whether > the > > >>> BFD > > >>>>>>>> packet was sent late, or whether the packet was sent on=20 > > >>>>>>>> time and also arrived on time but was delayed when passing=20 > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad=20 > > >>>>>>>> too > > >>>>>>>> long) > > >>>>>>> > > >>>>>>> well, I can see a point in having the Tx timestamps in the=20 > > >>>>>>> packet mainly for the purpose of knowing "this" packet was=20 > > >>>>>>> okay/not okay on the Tx side and to correlate it with your=20 > > >>>>>>> local Rx > measurement. > > >>>>>> > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > >>>>>> If allow to have Tx timestamps to be carried in the packets,=20 > > >>>>>> seems it should be no problem to leave a seat for the Rx=20 > > >>>>>> timestamps as well :-). After all, with both Tx and Rx=20 > > >>>>>> timestamp, it may simplify the > > >>>>> implementation. > > >>>>>> > > >>>>>>> > > >>>>>>> And even this point is less relevant with sequence numbers=20 > > >>>>>>> as this number allows the identification of packets and thus=20 > > >>>>>>> the correlation of information from the Tx and Rx system. > > >>>>>> > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > between > > >>>>>> the Tx and Rx system. > > >>>>>> > > >>>>>> This triggers me think out there should be another solution=20 > > >>>>>> for getting the Tx and Rx timestamps without encoding the=20 > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps=20 > > >>>>>> locally or send them to a centralized entity and then use the=20 > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Mach > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Regards, Marc > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > >>>>>>>> Hi Jeff, > > >>>>>>>> > > >>>>>>>> I vividly remember the original intent of the stability=20 > > >>>>>>>> draft was to help debug BFD failures -- to isolate the=20 > > >>>>>>>> issue at the RX or the TX side Time stamping would have=20 > > >>>>>>>> helped in debugging > > whether > > >>>>>>>> the BFD packet was sent late, or whether the packet was=20 > > >>>>>>>> sent on time and also arrived on time but was delayed when=20 > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer=20 > > >>>>>>>> for tad too long), etc. But then time stamping came with=20 > > >>>>>>>> its own set of issues, and was hence dropped from the original= draft. > > >>>>>>>> > > >>>>>>>> Can the authors send a summary on the list on why time=20 > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > >>>>>>>> > > >>>>>>>> The current proposal does help but is not complete. > > >>>>>>>> > > >>>>>>>> Assume that the RX end loses a BFD session and learns later=20 > > >>>>>>>> that it did eventually receive the missing BFD packets=20 > > >>>>>>>> (based on the > > seq > > >>> #). > > >>>>>>>> How would it know which end was misbehaving? Was it a delay=20 > > >>>>>>>> at the TX side, or was it the RX that delayed passing the=20 > > >>>>>>>> packets to the BFD process(or). This is usually what we=20 > > >>>>>>>> want to debug and i want to understand how this draft with=20 > > >>>>>>>> sequence numbers can unequivocally tell me that. > > >>>>>>>> > > >>>>>>>> I believe the work is important and addresses something=20 > > >>>>>>>> thats really required (spent too much time debugging why=20 > > >>>>>>>> BFD > > flapped!). > > >>>>>>>> Clearly what would help is putting a small section that=20 > > >>>>>>>> describes how we can use the sequence numbers to debug > what > > >>>>>>>> and > > where > > >>> things went wrong. > > >>>>>>>> > > >>>>>>>> Cheers, Manav > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas=20 > > >>>>>>>> > > >>> wrote: > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > >>>>>>>>> > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > >>>>>>>>> pp > > >>>>>>>>> tx > > >>>>>>>>> > > >>>>>>>>> To attempt to simplify the presentation, the contentious=20 > > >>>>>>>>> portion of the timers were removed from the proposal,=20 > > >>>>>>>>> leaving only the sequence numbering for detecting loss of=20 > > >>>>>>>>> BFD > async packets. > > >>>>>>>>> > > >>>>>>>>> When the room was polled to see whether the draft should=20 > > >>>>>>>>> be adopted as a WG item, the sense of the room was very quiet= . > > >>>>>>>>> As promised, this is to inquire for support for this draft=20 > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > voice. > > >>>>>>>>> > > >>>>>>>>> It should be noted that post-meeting discussion on the=20 > > >>>>>>>>> fate of this draft noted that BFD authentication code=20 > > >>>>>>>>> points are plentiful and are available with expert review. =20 > > >>>>>>>>> Should the draft authors wish to continue this work as=20 > > >>>>>>>>> Experimental, that is > > an > > >>> option. > > >>>>>>>>> > > >>>>>>>>> -- Jeff > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > From nobody Thu Dec 4 03:15:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6B91A0164 for ; Thu, 4 Dec 2014 03:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Ym3WuHt6CeGh for ; Thu, 4 Dec 2014 03:15:09 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61BEF1A0162 for ; Thu, 4 Dec 2014 03:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15007; q=dns/txt; s=iport; t=1417691710; x=1418901310; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=03iPNwJ2skNvEDk+0lPhOCLjhwBOApNkNvCLETvvjFA=; b=GT/pSrCD0G7ZRa/OBCX3MZmsUyBuZpS4jZu7jZaUr2XfHi5Mcmh6DGXM vOcerrz6qb2BR/VJcCzmENk3ct4qNTWEOMWCZAHYLFmsLJtcjnKpQZZV/ 1p5UbHBCUJQSo5Tde7TaBOPPexVXVfaGpPTdJcspTAE5x019/KlbCM6G/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAFRBgFStJV2c/2dsb2JhbABagwZSWATEKYImgXsBhBoCgRgWAQEBAQF9hAIBAQEEOi0EAwsMBAIBCBEEAQEBChQJBzIUCQgCBAENBQgBEogjDdYkAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5A1LAUHBoMegR4FjgaCCoQWh1Y4gnWDQIgfg2mDeW+BRYEAAQEB X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="102600957" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 04 Dec 2014 11:15:07 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sB4BF73L030262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 11:15:07 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 05:15:06 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Gregory Mirsky , Santosh P K , Marc Binderberger , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6sIVMf6rgiwEKxHqHxEi4wkpxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQD//+KccIAAacAAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYD//+8mUA== Date: Thu, 4 Dec 2014 11:15:06 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D347719A2@xmb-rcd-x15.cisco.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <20141201013841551442.5a9df5b9@sniff.de> <7347100B5761DC41A166AC17F22DF1121B8AA51B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AA9A5@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AA9A5@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.26.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/16z2Pu6R8b_2eXzCWEKGS0tpYPU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 11:15:13 -0000 Hello Greg/ Santosh, It was my understanding that BFD Async was chosen for stability since the= re are configurations where BFD echo mode is not supported (e.g. Multi-hop,= BFD on LAGs and BFD over MPLS). Am I missing something here, please let me= know. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, December 04, 2014 11:44 AM To: Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, yes, the format and thus interpretation of payload in Echo mode is not defi= ned and that, in my view, is what we need - some open space. And Echo well = could be exactly that - no legacy, no backward compatibility (addressee tha= t doesn't support "extended Echo" will simply loop the packet back to sende= r). Perhaps that will be direction we can discuss and, hopefully, agree on. Regards, Greg -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Wednesday, December 03, 2014 9:54 PM To: Gregory Mirsky; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Greg, I don't think we have discussed about echo in this context. Echo is good= thing but payload of BFD echo packet is decided by local system. Did you m= ean to add suggestion on how echo packet should look like? Or how echo can = help in BFD loss/delay issue?=20 Thanks Santosh P K =20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, December 04, 2014 2:22 AM > To: Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Dear All, > had authors of the proposal or we already dismissed use of BFD Echo?=20 > I've scanned the thread and couldn't find trace of us discussing BFD=20 > Echo mode. I think that it is more suitable for experimentation and unort= hodox use. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P=20 > K > Sent: Wednesday, December 03, 2014 5:39 AM > To: Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Hello Manav and Marc, >=20 >=20 > > > One way to solve this problem is by attaching a debug trailer that=20 > > > only carries the seq numbers at the *end* of the BFD packet. This=20 > > > would not be covered in the Length field carried in the BFD header=20 > > > but would be accounted for in the length carried in the IP header. > > > > BFD itself is not related to IP, i.e. there is not always an IP header. > > Sure, the encapsulating "frame" may provide a length but actually,=20 > > why not covering the debug trailer with the BFD length? > > > > If this is solely for debug purpose than this may work. For simple=20 > > copying-out into e.g. a packet trace buffer it would be even simpler=20 > > to have the BFD length covering the trailer. > > If hardware is supposed to process the trailer information (other=20 > > than copying out) then it's getting ugly - having fixed position,=20 > > fixed length extension headers would be preferable for simple access. >=20 > Fixed length would be easy to process in hardware. Problem is when we=20 > have many have extensions in future. If we want to use only one=20 > extension that is at the last then I will be forced to pad all the=20 > other extension ahead of it? This might not be a problem if we have=20 > fewer extensions but might become problem when there are too many extensi= ons. >=20 >=20 > > > > Another idea is to use the 0x80 bit of the auth type to distinguish=20 > > between a "normal" authentication header and a "sequence + > authentication". > > >=20 > I think this is good. In the BFD extension TLV we still have many=20 > reserved bits that can be used as well? >=20 > Thanks > Santosh P K >=20 >=20 >=20 > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > Hi Santosh, > > > > > > You could use the crypto sequence numbers carried in the=20 > > > meticulous cryptographic auth for detecting packet losses. > > > However, this breaks when you use non-meticulous crypto=20 > > > authentication since the sequence number is only incremented=20 > > > occasionally there. This i believe is a deal breaker since i=20 > > > really envision non meticulous mode to be the one being widely=20 > > > deployed. In fact we were supposed to write a draft on that and i=20 > > > guess it just fell through the cracks (lemme ping my co-author on=20 > > > that !) > > > > > > One way to solve this problem is by attaching a debug trailer that=20 > > > only carries the seq numbers at the *end* of the BFD packet. This=20 > > > would not be covered in the Length field carried in the BFD header=20 > > > but would be accounted for in the length carried in the IP header. > > > The concept of attaching a trailer is documented well and is used=20 > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The=20 > > > catch however is that this debug trailer will NOT be covered by=20 > > > the BFD authentication. Is this acceptable to the WG? > > > > > > I think the problem of diagnosing a BFD flap becomes all the more=20 > > > important with BFD authentication turned on since then we have=20 > > > more points where a delay can be inserted. > > > > > > Cheers, Manav > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K=20 > > > > > wrote: > > >> Manav, > > >> This is good question. > > >> > > >>> Can the authors add some text on how this debugging mechanism=20 > > >>> would work if somebody employs BFD authentication? > > >> > > >> Right now we have considered without authentication (we are=20 > > >> setting A bit). We should add some text on how we can use both=20 > > >> Auth and de bug > > TLV. > > >> Is there any suggestion you have? I will get back to you on this. > > >> > > >> > > >> Thanks > > >> Santosh P K > > >> > > >>>> -----Original Message----- > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > > >>>> Mach > > Chen > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > >>>> To: Marc Binderberger > > >>>> Cc: rtg-bfd@ietf.org > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>> > > >>>> Hi Marc, > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > >>>>> To: Mach Chen > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>>> > > >>>>> Hello Mach, > > >>>>> > > >>>>>> This triggers me think out there should be another solution=20 > > >>>>>> for getting the Tx and Rx timestamps without encoding the=20 > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps=20 > > >>>>>> locally or send them to a centralized entity and then use the=20 > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>> > > >>>>> I remember some discussion on NVO3 about how many bits it=20 > > >>>>> takes > > >>>>> ;- > > ) - > > >>>>> could you send the links/draft names you are working on to this l= ist? > > >>>>> May be useful for further discussions. > > >>>> > > >>>> Sure, here is the > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > >>> based-ipfpm-framework-02) for the reference. > > >>>> > > >>>> But here I want to say is that since we have sequence number,=20 > > >>>> we may > > not > > >>> need the marking based solution. Suppose that someone want to > > monitor > > >>> the delay of a BFD packet , just record and save the timestamp=20 > > >>> at the Tx side, which indexed by the sequence number. Similarly,=20 > > >>> do the same at the Rx side. Then based on the timestamps from=20 > > >>> both Tx and Rx, and using the sequence number to correlate the=20 > > >>> timestamps, it can also provide a way > > to > > >>> monitor the delay of the BFD packet. > > >>>> > > >>>> That means, only if there is sequence number, even if without=20 > > >>>> carrying the > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > >>>> > > >>>> Best regards, > > >>>> Mach > > >>>> > > >>>>> > > >>>>> > > >>>>> Thanks & Regards, > > >>>>> Marc > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > >>>>>> Hi Marc and Manav, > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > Marc > > >>>>>>> Binderberger > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > >>>>>>> To: Manav Bhatia > > >>>>>>> Cc: rtg-bfd@ietf.org > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > >>>>>>> > > >>>>>>> Hello Manav, > > >>>>>>> > > >>>>>>>> I believe the work is important and addresses something=20 > > >>>>>>>> thats really required (spent too much time debugging why=20 > > >>>>>>>> BFD > > flapped!). > > >>>>>>> > > >>>>>>> agree :-) we should keep the discussion alive. > > >>>>>>> > > >>>>>>> > > >>>>>>>> side Time stamping would have helped in debugging whether > the > > >>> BFD > > >>>>>>>> packet was sent late, or whether the packet was sent on=20 > > >>>>>>>> time and also arrived on time but was delayed when passing=20 > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad=20 > > >>>>>>>> too > > >>>>>>>> long) > > >>>>>>> > > >>>>>>> well, I can see a point in having the Tx timestamps in the=20 > > >>>>>>> packet mainly for the purpose of knowing "this" packet was=20 > > >>>>>>> okay/not okay on the Tx side and to correlate it with your=20 > > >>>>>>> local Rx > measurement. > > >>>>>> > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > >>>>>> If allow to have Tx timestamps to be carried in the packets,=20 > > >>>>>> seems it should be no problem to leave a seat for the Rx=20 > > >>>>>> timestamps as well :-). After all, with both Tx and Rx=20 > > >>>>>> timestamp, it may simplify the > > >>>>> implementation. > > >>>>>> > > >>>>>>> > > >>>>>>> And even this point is less relevant with sequence numbers=20 > > >>>>>>> as this number allows the identification of packets and thus=20 > > >>>>>>> the correlation of information from the Tx and Rx system. > > >>>>>> > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > between > > >>>>>> the Tx and Rx system. > > >>>>>> > > >>>>>> This triggers me think out there should be another solution=20 > > >>>>>> for getting the Tx and Rx timestamps without encoding the=20 > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps=20 > > >>>>>> locally or send them to a centralized entity and then use the=20 > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Mach > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Regards, Marc > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > >>>>>>>> Hi Jeff, > > >>>>>>>> > > >>>>>>>> I vividly remember the original intent of the stability=20 > > >>>>>>>> draft was to help debug BFD failures -- to isolate the=20 > > >>>>>>>> issue at the RX or the TX side Time stamping would have=20 > > >>>>>>>> helped in debugging > > whether > > >>>>>>>> the BFD packet was sent late, or whether the packet was=20 > > >>>>>>>> sent on time and also arrived on time but was delayed when=20 > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer=20 > > >>>>>>>> for tad too long), etc. But then time stamping came with=20 > > >>>>>>>> its own set of issues, and was hence dropped from the original= draft. > > >>>>>>>> > > >>>>>>>> Can the authors send a summary on the list on why time=20 > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > >>>>>>>> > > >>>>>>>> The current proposal does help but is not complete. > > >>>>>>>> > > >>>>>>>> Assume that the RX end loses a BFD session and learns later=20 > > >>>>>>>> that it did eventually receive the missing BFD packets=20 > > >>>>>>>> (based on the > > seq > > >>> #). > > >>>>>>>> How would it know which end was misbehaving? Was it a delay=20 > > >>>>>>>> at the TX side, or was it the RX that delayed passing the=20 > > >>>>>>>> packets to the BFD process(or). This is usually what we=20 > > >>>>>>>> want to debug and i want to understand how this draft with=20 > > >>>>>>>> sequence numbers can unequivocally tell me that. > > >>>>>>>> > > >>>>>>>> I believe the work is important and addresses something=20 > > >>>>>>>> thats really required (spent too much time debugging why=20 > > >>>>>>>> BFD > > flapped!). > > >>>>>>>> Clearly what would help is putting a small section that=20 > > >>>>>>>> describes how we can use the sequence numbers to debug > what > > >>>>>>>> and > > where > > >>> things went wrong. > > >>>>>>>> > > >>>>>>>> Cheers, Manav > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas=20 > > >>>>>>>> > > >>> wrote: > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > >>>>>>>>> > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > >>>>>>>>> pp > > >>>>>>>>> tx > > >>>>>>>>> > > >>>>>>>>> To attempt to simplify the presentation, the contentious=20 > > >>>>>>>>> portion of the timers were removed from the proposal,=20 > > >>>>>>>>> leaving only the sequence numbering for detecting loss of=20 > > >>>>>>>>> BFD > async packets. > > >>>>>>>>> > > >>>>>>>>> When the room was polled to see whether the draft should=20 > > >>>>>>>>> be adopted as a WG item, the sense of the room was very quiet= . > > >>>>>>>>> As promised, this is to inquire for support for this draft=20 > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > voice. > > >>>>>>>>> > > >>>>>>>>> It should be noted that post-meeting discussion on the=20 > > >>>>>>>>> fate of this draft noted that BFD authentication code=20 > > >>>>>>>>> points are plentiful and are available with expert review. > > >>>>>>>>> Should the draft authors wish to continue this work as=20 > > >>>>>>>>> Experimental, that is > > an > > >>> option. > > >>>>>>>>> > > >>>>>>>>> -- Jeff > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > From nobody Thu Dec 4 03:44:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFB81A0271 for ; Thu, 4 Dec 2014 03:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 iJs2Q0ko9Cn7 for ; Thu, 4 Dec 2014 03:44:41 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C771A0266 for ; Thu, 4 Dec 2014 03:44:40 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB824.namprd05.prod.outlook.com (10.141.244.146) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 11:44:16 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 4 Dec 2014 11:44:16 +0000 From: Santosh P K To: Gregory Mirsky , Marc Binderberger , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuCAAAvZAIAF49GAgANl6hCAAHr8gIAAli8QgAAGoICAAFs+YA== Date: Thu, 4 Dec 2014 11:44:15 +0000 Message-ID: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <20141201013841551442.5a9df5b9@sniff.de> <7347100B5761DC41A166AC17F22DF1121B8AA51B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AA9A5@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AA9A5@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(57704003)(51444003)(24454002)(189002)(377454003)(199003)(51704005)(62966003)(77156002)(77096005)(107046002)(74316001)(76576001)(101416001)(97736003)(99286002)(95666004)(106356001)(4396001)(106116001)(105586002)(64706001)(50986999)(46102003)(54206007)(86362001)(20776003)(40100003)(54606007)(1720100001)(92566001)(2656002)(92726001)(99396003)(66066001)(19580405001)(122556002)(31966008)(33656002)(68736005)(87936001)(54356999)(561944003)(120916001)(21056001)(93886004)(76176999)(19580395003)(15202345003)(15975445006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB824; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/78g3FOO-NE0_QZWDU7za--R22fQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 11:44:45 -0000 Hi Greg, Since packet is processed in local system and remote system will just lo= op it back, packet can be anything right? I mean do we need to standardized= how a packet should look like? There won't be any backward compatibility i= ssues with this. More over on some system it may be possible that looping b= ack packets on same interface might not be allowed. =20 Thanks Santosh P K=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, December 04, 2014 11:44 AM > To: Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Hi Santosh, > yes, the format and thus interpretation of payload in Echo mode is not > defined and that, in my view, is what we need - some open space. And Echo > well could be exactly that - no legacy, no backward compatibility (addres= see > that doesn't support "extended Echo" will simply loop the packet back to > sender). Perhaps that will be direction we can discuss and, hopefully, ag= ree > on. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Wednesday, December 03, 2014 9:54 PM > To: Gregory Mirsky; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Greg, > I don't think we have discussed about echo in this context. Echo is go= od > thing but payload of BFD echo packet is decided by local system. Did you > mean to add suggestion on how echo packet should look like? Or how echo > can help in BFD loss/delay issue? >=20 > Thanks > Santosh P K >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, December 04, 2014 2:22 AM > > To: Santosh P K; Marc Binderberger; Manav Bhatia > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD stability follow-up from IETF-91 > > > > Dear All, > > had authors of the proposal or we already dismissed use of BFD Echo? > > I've scanned the thread and couldn't find trace of us discussing BFD > > Echo mode. I think that it is more suitable for experimentation and > unorthodox use. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P > > K > > Sent: Wednesday, December 03, 2014 5:39 AM > > To: Marc Binderberger; Manav Bhatia > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD stability follow-up from IETF-91 > > > > Hello Manav and Marc, > > > > > > > > One way to solve this problem is by attaching a debug trailer that > > > > only carries the seq numbers at the *end* of the BFD packet. This > > > > would not be covered in the Length field carried in the BFD header > > > > but would be accounted for in the length carried in the IP header. > > > > > > BFD itself is not related to IP, i.e. there is not always an IP heade= r. > > > Sure, the encapsulating "frame" may provide a length but actually, > > > why not covering the debug trailer with the BFD length? > > > > > > If this is solely for debug purpose than this may work. For simple > > > copying-out into e.g. a packet trace buffer it would be even simpler > > > to have the BFD length covering the trailer. > > > If hardware is supposed to process the trailer information (other > > > than copying out) then it's getting ugly - having fixed position, > > > fixed length extension headers would be preferable for simple access. > > > > Fixed length would be easy to process in hardware. Problem is when we > > have many have extensions in future. If we want to use only one > > extension that is at the last then I will be forced to pad all the > > other extension ahead of it? This might not be a problem if we have > > fewer extensions but might become problem when there are too many > extensions. > > > > > > > > > > Another idea is to use the 0x80 bit of the auth type to distinguish > > > between a "normal" authentication header and a "sequence + > > authentication". > > > > > > > I think this is good. In the BFD extension TLV we still have many > > reserved bits that can be used as well? > > > > Thanks > > Santosh P K > > > > > > > > > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > > Hi Santosh, > > > > > > > > You could use the crypto sequence numbers carried in the > > > > meticulous cryptographic auth for detecting packet losses. > > > > However, this breaks when you use non-meticulous crypto > > > > authentication since the sequence number is only incremented > > > > occasionally there. This i believe is a deal breaker since i > > > > really envision non meticulous mode to be the one being widely > > > > deployed. In fact we were supposed to write a draft on that and i > > > > guess it just fell through the cracks (lemme ping my co-author on > > > > that !) > > > > > > > > One way to solve this problem is by attaching a debug trailer that > > > > only carries the seq numbers at the *end* of the BFD packet. This > > > > would not be covered in the Length field carried in the BFD header > > > > but would be accounted for in the length carried in the IP header. > > > > The concept of attaching a trailer is documented well and is used > > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The > > > > catch however is that this debug trailer will NOT be covered by > > > > the BFD authentication. Is this acceptable to the WG? > > > > > > > > I think the problem of diagnosing a BFD flap becomes all the more > > > > important with BFD authentication turned on since then we have > > > > more points where a delay can be inserted. > > > > > > > > Cheers, Manav > > > > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > > > > > > wrote: > > > >> Manav, > > > >> This is good question. > > > >> > > > >>> Can the authors add some text on how this debugging mechanism > > > >>> would work if somebody employs BFD authentication? > > > >> > > > >> Right now we have considered without authentication (we are > > > >> setting A bit). We should add some text on how we can use both > > > >> Auth and de bug > > > TLV. > > > >> Is there any suggestion you have? I will get back to you on this. > > > >> > > > >> > > > >> Thanks > > > >> Santosh P K > > > >> > > > >>>> -----Original Message----- > > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > >>>> Mach > > > Chen > > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > > >>>> To: Marc Binderberger > > > >>>> Cc: rtg-bfd@ietf.org > > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > > >>>> > > > >>>> Hi Marc, > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > > >>>>> To: Mach Chen > > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > > >>>>> > > > >>>>> Hello Mach, > > > >>>>> > > > >>>>>> This triggers me think out there should be another solution > > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > > >>>>>> timestamps > > > in > > > >>>>>> the BFD > > > >>>>> packets. > > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > > >>>>>> locally or send them to a centralized entity and then use the > > > >>>>>> sequence numbers to correlate them for further analyzing. > > > >>>>> > > > >>>>> I remember some discussion on NVO3 about how many bits it > > > >>>>> takes > > > >>>>> ;- > > > ) - > > > >>>>> could you send the links/draft names you are working on to this > list? > > > >>>>> May be useful for further discussions. > > > >>>> > > > >>>> Sure, here is the > > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > > >>> based-ipfpm-framework-02) for the reference. > > > >>>> > > > >>>> But here I want to say is that since we have sequence number, > > > >>>> we may > > > not > > > >>> need the marking based solution. Suppose that someone want to > > > monitor > > > >>> the delay of a BFD packet , just record and save the timestamp > > > >>> at the Tx side, which indexed by the sequence number. Similarly, > > > >>> do the same at the Rx side. Then based on the timestamps from > > > >>> both Tx and Rx, and using the sequence number to correlate the > > > >>> timestamps, it can also provide a way > > > to > > > >>> monitor the delay of the BFD packet. > > > >>>> > > > >>>> That means, only if there is sequence number, even if without > > > >>>> carrying the > > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > > >>>> > > > >>>> Best regards, > > > >>>> Mach > > > >>>> > > > >>>>> > > > >>>>> > > > >>>>> Thanks & Regards, > > > >>>>> Marc > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > > >>>>>> Hi Marc and Manav, > > > >>>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > Marc > > > >>>>>>> Binderberger > > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > > >>>>>>> To: Manav Bhatia > > > >>>>>>> Cc: rtg-bfd@ietf.org > > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > > >>>>>>> > > > >>>>>>> Hello Manav, > > > >>>>>>> > > > >>>>>>>> I believe the work is important and addresses something > > > >>>>>>>> thats really required (spent too much time debugging why > > > >>>>>>>> BFD > > > flapped!). > > > >>>>>>> > > > >>>>>>> agree :-) we should keep the discussion alive. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>> side Time stamping would have helped in debugging whether > > the > > > >>> BFD > > > >>>>>>>> packet was sent late, or whether the packet was sent on > > > >>>>>>>> time and also arrived on time but was delayed when passing > > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad > > > >>>>>>>> too > > > >>>>>>>> long) > > > >>>>>>> > > > >>>>>>> well, I can see a point in having the Tx timestamps in the > > > >>>>>>> packet mainly for the purpose of knowing "this" packet was > > > >>>>>>> okay/not okay on the Tx side and to correlate it with your > > > >>>>>>> local Rx > > measurement. > > > >>>>>> > > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > > >>>>>> If allow to have Tx timestamps to be carried in the packets, > > > >>>>>> seems it should be no problem to leave a seat for the Rx > > > >>>>>> timestamps as well :-). After all, with both Tx and Rx > > > >>>>>> timestamp, it may simplify the > > > >>>>> implementation. > > > >>>>>> > > > >>>>>>> > > > >>>>>>> And even this point is less relevant with sequence numbers > > > >>>>>>> as this number allows the identification of packets and thus > > > >>>>>>> the correlation of information from the Tx and Rx system. > > > >>>>>> > > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > > between > > > >>>>>> the Tx and Rx system. > > > >>>>>> > > > >>>>>> This triggers me think out there should be another solution > > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > > >>>>>> timestamps > > > in > > > >>>>>> the BFD > > > >>>>> packets. > > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > > >>>>>> locally or send them to a centralized entity and then use the > > > >>>>>> sequence numbers to correlate them for further analyzing. > > > >>>>>> > > > >>>>>> Best regards, > > > >>>>>> Mach > > > >>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Regards, Marc > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > > >>>>>>>> Hi Jeff, > > > >>>>>>>> > > > >>>>>>>> I vividly remember the original intent of the stability > > > >>>>>>>> draft was to help debug BFD failures -- to isolate the > > > >>>>>>>> issue at the RX or the TX side Time stamping would have > > > >>>>>>>> helped in debugging > > > whether > > > >>>>>>>> the BFD packet was sent late, or whether the packet was > > > >>>>>>>> sent on time and also arrived on time but was delayed when > > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer > > > >>>>>>>> for tad too long), etc. But then time stamping came with > > > >>>>>>>> its own set of issues, and was hence dropped from the origin= al > draft. > > > >>>>>>>> > > > >>>>>>>> Can the authors send a summary on the list on why time > > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > > >>>>>>>> > > > >>>>>>>> The current proposal does help but is not complete. > > > >>>>>>>> > > > >>>>>>>> Assume that the RX end loses a BFD session and learns later > > > >>>>>>>> that it did eventually receive the missing BFD packets > > > >>>>>>>> (based on the > > > seq > > > >>> #). > > > >>>>>>>> How would it know which end was misbehaving? Was it a > delay > > > >>>>>>>> at the TX side, or was it the RX that delayed passing the > > > >>>>>>>> packets to the BFD process(or). This is usually what we > > > >>>>>>>> want to debug and i want to understand how this draft with > > > >>>>>>>> sequence numbers can unequivocally tell me that. > > > >>>>>>>> > > > >>>>>>>> I believe the work is important and addresses something > > > >>>>>>>> thats really required (spent too much time debugging why > > > >>>>>>>> BFD > > > flapped!). > > > >>>>>>>> Clearly what would help is putting a small section that > > > >>>>>>>> describes how we can use the sequence numbers to debug > > what > > > >>>>>>>> and > > > where > > > >>> things went wrong. > > > >>>>>>>> > > > >>>>>>>> Cheers, Manav > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > > > >>>>>>>> > > > >>> wrote: > > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > > >>>>>>>>> > > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > > >>>>>>>>> pp > > > >>>>>>>>> tx > > > >>>>>>>>> > > > >>>>>>>>> To attempt to simplify the presentation, the contentious > > > >>>>>>>>> portion of the timers were removed from the proposal, > > > >>>>>>>>> leaving only the sequence numbering for detecting loss of > > > >>>>>>>>> BFD > > async packets. > > > >>>>>>>>> > > > >>>>>>>>> When the room was polled to see whether the draft should > > > >>>>>>>>> be adopted as a WG item, the sense of the room was very > quiet. > > > >>>>>>>>> As promised, this is to inquire for support for this draft > > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > > voice. > > > >>>>>>>>> > > > >>>>>>>>> It should be noted that post-meeting discussion on the > > > >>>>>>>>> fate of this draft noted that BFD authentication code > > > >>>>>>>>> points are plentiful and are available with expert review. > > > >>>>>>>>> Should the draft authors wish to continue this work as > > > >>>>>>>>> Experimental, that is > > > an > > > >>> option. > > > >>>>>>>>> > > > >>>>>>>>> -- Jeff > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>> > > > >>>> > > > >> > > > > From nobody Thu Dec 4 03:46:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B931A0211 for ; Thu, 4 Dec 2014 03:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zsrFAN4Gk_0B for ; Thu, 4 Dec 2014 03:45:58 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2251A0248 for ; Thu, 4 Dec 2014 03:45:57 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 11:45:34 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 4 Dec 2014 11:45:34 +0000 From: Santosh P K To: "Vengada Prasad Govindan (venggovi)" , Gregory Mirsky , Marc Binderberger , "Manav Bhatia" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuCAAAvZAIAF49GAgANl6hCAAHr8gIAAli8QgAAGoICAAFQ5AIAACCOw Date: Thu, 4 Dec 2014 11:45:34 +0000 Message-ID: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <20141201013841551442.5a9df5b9@sniff.de> <7347100B5761DC41A166AC17F22DF1121B8AA51B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AA9A5@eusaamb103.ericsson.se> <315041E4211CB84E86EF7C25A2AB583D347719A2@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D347719A2@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(199003)(51704005)(377454003)(13464003)(57704003)(189002)(24454002)(46102003)(76576001)(15202345003)(122556002)(40100003)(2656002)(19580405001)(87936001)(120916001)(19580395003)(93886004)(99396003)(4396001)(92566001)(92726001)(97736003)(21056001)(1720100001)(64706001)(20776003)(86362001)(33656002)(77096005)(101416001)(66066001)(561944003)(76176999)(54356999)(68736005)(50986999)(74316001)(62966003)(106356001)(99286002)(77156002)(105586002)(95666004)(106116001)(15975445006)(31966008)(107046002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OL8UFsAU85ZHJ2MW3k9wfOMa8HQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 11:46:01 -0000 Hi Prasad, That's right. We echo has limitations but for single hop we can still use= it. I was trying to understand even for single hop do we need to define an= y packet format for echo? Thanks Santosh P K=20 > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > Sent: Thursday, December 04, 2014 4:45 PM > To: Gregory Mirsky; Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Hello Greg/ Santosh, > It was my understanding that BFD Async was chosen for stability since t= here > are configurations where BFD echo mode is not supported (e.g. Multi-hop, > BFD on LAGs and BFD over MPLS). Am I missing something here, please let > me know. > Thanks > Prasad >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory > Mirsky > Sent: Thursday, December 04, 2014 11:44 AM > To: Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Hi Santosh, > yes, the format and thus interpretation of payload in Echo mode is not > defined and that, in my view, is what we need - some open space. And Echo > well could be exactly that - no legacy, no backward compatibility (addres= see > that doesn't support "extended Echo" will simply loop the packet back to > sender). Perhaps that will be direction we can discuss and, hopefully, ag= ree > on. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Wednesday, December 03, 2014 9:54 PM > To: Gregory Mirsky; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Greg, > I don't think we have discussed about echo in this context. Echo is go= od > thing but payload of BFD echo packet is decided by local system. Did you > mean to add suggestion on how echo packet should look like? Or how echo > can help in BFD loss/delay issue? >=20 > Thanks > Santosh P K >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, December 04, 2014 2:22 AM > > To: Santosh P K; Marc Binderberger; Manav Bhatia > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD stability follow-up from IETF-91 > > > > Dear All, > > had authors of the proposal or we already dismissed use of BFD Echo? > > I've scanned the thread and couldn't find trace of us discussing BFD > > Echo mode. I think that it is more suitable for experimentation and > unorthodox use. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P > > K > > Sent: Wednesday, December 03, 2014 5:39 AM > > To: Marc Binderberger; Manav Bhatia > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD stability follow-up from IETF-91 > > > > Hello Manav and Marc, > > > > > > > > One way to solve this problem is by attaching a debug trailer that > > > > only carries the seq numbers at the *end* of the BFD packet. This > > > > would not be covered in the Length field carried in the BFD header > > > > but would be accounted for in the length carried in the IP header. > > > > > > BFD itself is not related to IP, i.e. there is not always an IP heade= r. > > > Sure, the encapsulating "frame" may provide a length but actually, > > > why not covering the debug trailer with the BFD length? > > > > > > If this is solely for debug purpose than this may work. For simple > > > copying-out into e.g. a packet trace buffer it would be even simpler > > > to have the BFD length covering the trailer. > > > If hardware is supposed to process the trailer information (other > > > than copying out) then it's getting ugly - having fixed position, > > > fixed length extension headers would be preferable for simple access. > > > > Fixed length would be easy to process in hardware. Problem is when we > > have many have extensions in future. If we want to use only one > > extension that is at the last then I will be forced to pad all the > > other extension ahead of it? This might not be a problem if we have > > fewer extensions but might become problem when there are too many > extensions. > > > > > > > > > > Another idea is to use the 0x80 bit of the auth type to distinguish > > > between a "normal" authentication header and a "sequence + > > authentication". > > > > > > > I think this is good. In the BFD extension TLV we still have many > > reserved bits that can be used as well? > > > > Thanks > > Santosh P K > > > > > > > > > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > > Hi Santosh, > > > > > > > > You could use the crypto sequence numbers carried in the > > > > meticulous cryptographic auth for detecting packet losses. > > > > However, this breaks when you use non-meticulous crypto > > > > authentication since the sequence number is only incremented > > > > occasionally there. This i believe is a deal breaker since i > > > > really envision non meticulous mode to be the one being widely > > > > deployed. In fact we were supposed to write a draft on that and i > > > > guess it just fell through the cracks (lemme ping my co-author on > > > > that !) > > > > > > > > One way to solve this problem is by attaching a debug trailer that > > > > only carries the seq numbers at the *end* of the BFD packet. This > > > > would not be covered in the Length field carried in the BFD header > > > > but would be accounted for in the length carried in the IP header. > > > > The concept of attaching a trailer is documented well and is used > > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The > > > > catch however is that this debug trailer will NOT be covered by > > > > the BFD authentication. Is this acceptable to the WG? > > > > > > > > I think the problem of diagnosing a BFD flap becomes all the more > > > > important with BFD authentication turned on since then we have > > > > more points where a delay can be inserted. > > > > > > > > Cheers, Manav > > > > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > > > > > > wrote: > > > >> Manav, > > > >> This is good question. > > > >> > > > >>> Can the authors add some text on how this debugging mechanism > > > >>> would work if somebody employs BFD authentication? > > > >> > > > >> Right now we have considered without authentication (we are > > > >> setting A bit). We should add some text on how we can use both > > > >> Auth and de bug > > > TLV. > > > >> Is there any suggestion you have? I will get back to you on this. > > > >> > > > >> > > > >> Thanks > > > >> Santosh P K > > > >> > > > >>>> -----Original Message----- > > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > >>>> Mach > > > Chen > > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > > >>>> To: Marc Binderberger > > > >>>> Cc: rtg-bfd@ietf.org > > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > > >>>> > > > >>>> Hi Marc, > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > > >>>>> To: Mach Chen > > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > > >>>>> > > > >>>>> Hello Mach, > > > >>>>> > > > >>>>>> This triggers me think out there should be another solution > > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > > >>>>>> timestamps > > > in > > > >>>>>> the BFD > > > >>>>> packets. > > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > > >>>>>> locally or send them to a centralized entity and then use the > > > >>>>>> sequence numbers to correlate them for further analyzing. > > > >>>>> > > > >>>>> I remember some discussion on NVO3 about how many bits it > > > >>>>> takes > > > >>>>> ;- > > > ) - > > > >>>>> could you send the links/draft names you are working on to this > list? > > > >>>>> May be useful for further discussions. > > > >>>> > > > >>>> Sure, here is the > > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > > >>> based-ipfpm-framework-02) for the reference. > > > >>>> > > > >>>> But here I want to say is that since we have sequence number, > > > >>>> we may > > > not > > > >>> need the marking based solution. Suppose that someone want to > > > monitor > > > >>> the delay of a BFD packet , just record and save the timestamp > > > >>> at the Tx side, which indexed by the sequence number. Similarly, > > > >>> do the same at the Rx side. Then based on the timestamps from > > > >>> both Tx and Rx, and using the sequence number to correlate the > > > >>> timestamps, it can also provide a way > > > to > > > >>> monitor the delay of the BFD packet. > > > >>>> > > > >>>> That means, only if there is sequence number, even if without > > > >>>> carrying the > > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > > >>>> > > > >>>> Best regards, > > > >>>> Mach > > > >>>> > > > >>>>> > > > >>>>> > > > >>>>> Thanks & Regards, > > > >>>>> Marc > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > > >>>>>> Hi Marc and Manav, > > > >>>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > Marc > > > >>>>>>> Binderberger > > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > > >>>>>>> To: Manav Bhatia > > > >>>>>>> Cc: rtg-bfd@ietf.org > > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > > >>>>>>> > > > >>>>>>> Hello Manav, > > > >>>>>>> > > > >>>>>>>> I believe the work is important and addresses something > > > >>>>>>>> thats really required (spent too much time debugging why > > > >>>>>>>> BFD > > > flapped!). > > > >>>>>>> > > > >>>>>>> agree :-) we should keep the discussion alive. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>> side Time stamping would have helped in debugging whether > > the > > > >>> BFD > > > >>>>>>>> packet was sent late, or whether the packet was sent on > > > >>>>>>>> time and also arrived on time but was delayed when passing > > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad > > > >>>>>>>> too > > > >>>>>>>> long) > > > >>>>>>> > > > >>>>>>> well, I can see a point in having the Tx timestamps in the > > > >>>>>>> packet mainly for the purpose of knowing "this" packet was > > > >>>>>>> okay/not okay on the Tx side and to correlate it with your > > > >>>>>>> local Rx > > measurement. > > > >>>>>> > > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > > >>>>>> If allow to have Tx timestamps to be carried in the packets, > > > >>>>>> seems it should be no problem to leave a seat for the Rx > > > >>>>>> timestamps as well :-). After all, with both Tx and Rx > > > >>>>>> timestamp, it may simplify the > > > >>>>> implementation. > > > >>>>>> > > > >>>>>>> > > > >>>>>>> And even this point is less relevant with sequence numbers > > > >>>>>>> as this number allows the identification of packets and thus > > > >>>>>>> the correlation of information from the Tx and Rx system. > > > >>>>>> > > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > > between > > > >>>>>> the Tx and Rx system. > > > >>>>>> > > > >>>>>> This triggers me think out there should be another solution > > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > > >>>>>> timestamps > > > in > > > >>>>>> the BFD > > > >>>>> packets. > > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > > >>>>>> locally or send them to a centralized entity and then use the > > > >>>>>> sequence numbers to correlate them for further analyzing. > > > >>>>>> > > > >>>>>> Best regards, > > > >>>>>> Mach > > > >>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Regards, Marc > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > > >>>>>>>> Hi Jeff, > > > >>>>>>>> > > > >>>>>>>> I vividly remember the original intent of the stability > > > >>>>>>>> draft was to help debug BFD failures -- to isolate the > > > >>>>>>>> issue at the RX or the TX side Time stamping would have > > > >>>>>>>> helped in debugging > > > whether > > > >>>>>>>> the BFD packet was sent late, or whether the packet was > > > >>>>>>>> sent on time and also arrived on time but was delayed when > > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer > > > >>>>>>>> for tad too long), etc. But then time stamping came with > > > >>>>>>>> its own set of issues, and was hence dropped from the origin= al > draft. > > > >>>>>>>> > > > >>>>>>>> Can the authors send a summary on the list on why time > > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > > >>>>>>>> > > > >>>>>>>> The current proposal does help but is not complete. > > > >>>>>>>> > > > >>>>>>>> Assume that the RX end loses a BFD session and learns later > > > >>>>>>>> that it did eventually receive the missing BFD packets > > > >>>>>>>> (based on the > > > seq > > > >>> #). > > > >>>>>>>> How would it know which end was misbehaving? Was it a > delay > > > >>>>>>>> at the TX side, or was it the RX that delayed passing the > > > >>>>>>>> packets to the BFD process(or). This is usually what we > > > >>>>>>>> want to debug and i want to understand how this draft with > > > >>>>>>>> sequence numbers can unequivocally tell me that. > > > >>>>>>>> > > > >>>>>>>> I believe the work is important and addresses something > > > >>>>>>>> thats really required (spent too much time debugging why > > > >>>>>>>> BFD > > > flapped!). > > > >>>>>>>> Clearly what would help is putting a small section that > > > >>>>>>>> describes how we can use the sequence numbers to debug > > what > > > >>>>>>>> and > > > where > > > >>> things went wrong. > > > >>>>>>>> > > > >>>>>>>> Cheers, Manav > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > > > >>>>>>>> > > > >>> wrote: > > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > > >>>>>>>>> > > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > > >>>>>>>>> pp > > > >>>>>>>>> tx > > > >>>>>>>>> > > > >>>>>>>>> To attempt to simplify the presentation, the contentious > > > >>>>>>>>> portion of the timers were removed from the proposal, > > > >>>>>>>>> leaving only the sequence numbering for detecting loss of > > > >>>>>>>>> BFD > > async packets. > > > >>>>>>>>> > > > >>>>>>>>> When the room was polled to see whether the draft should > > > >>>>>>>>> be adopted as a WG item, the sense of the room was very > quiet. > > > >>>>>>>>> As promised, this is to inquire for support for this draft > > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > > voice. > > > >>>>>>>>> > > > >>>>>>>>> It should be noted that post-meeting discussion on the > > > >>>>>>>>> fate of this draft noted that BFD authentication code > > > >>>>>>>>> points are plentiful and are available with expert review. > > > >>>>>>>>> Should the draft authors wish to continue this work as > > > >>>>>>>>> Experimental, that is > > > an > > > >>> option. > > > >>>>>>>>> > > > >>>>>>>>> -- Jeff > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>> > > > >>>> > > > >> > > > > From nobody Thu Dec 4 04:32:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B551A0302 for ; Thu, 4 Dec 2014 04:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 5X_tArDjaehm for ; Thu, 4 Dec 2014 04:32:06 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085CC1A026E for ; Thu, 4 Dec 2014 04:32:06 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id a141so12395274oig.32 for ; Thu, 04 Dec 2014 04:32:05 -0800 (PST) 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:content-type; bh=t5TvztbNPaalKt/zuiqxqipoNN0UhHq+mWAxAYn0zIg=; b=oxUo4BvdP2hFIN8UDur3dVSgSRtqeNL+VAl6LecmCUzE6OwlbhvIbQ2YZkyf13gwb3 FKU/WHl1SFY9dVE0IL+JJpQJJ6PiQDbVqtazhFQWyELWxQTi6JF5pC7pG/6ebQhz+S2H stHE+RrXwfCfP+wnJkWI9kyJj/N8mwICpntFRSb2jAockJclxOf9kL/exhtKefQg+WAC ErAiQga2RmhtwlDLG7/Al7gar8Oko3IXcismFN1CHYI29CKwRP/LBVkRon1jxOSOi7IF 4LipShCTx7VECBG1W2vCzLu7BeRsO/k6JsiBtp9sgaeaws3rDLJYLjnJePjWZiaBlQf5 Yvug== MIME-Version: 1.0 X-Received: by 10.60.146.231 with SMTP id tf7mr6683483oeb.48.1417696325255; Thu, 04 Dec 2014 04:32:05 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 04:32:05 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AA9A5@eusaamb103.ericsson.se> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <20141201013841551442.5a9df5b9@sniff.de> <7347100B5761DC41A166AC17F22DF1121B8AA51B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AA9A5@eusaamb103.ericsson.se> Date: Thu, 4 Dec 2014 18:02:05 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=047d7b5d341addc91e050963252b Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/XRVlkDncHh4cvilLZ4_z3lK6etU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 12:32:12 -0000 --047d7b5d341addc91e050963252b Content-Type: text/plain; charset=UTF-8 Greg, This is not what we want. We wanted some additional data carried in the BFD packets that can help us diagnose BFD failures. We dont want an out-of-band mechanism to tell us whether BFD packets are getting dropped or not (there are other OAM tools for that). We're not even interested in that. What we want to know is why a particular BFD session flapped -- whether the issue was at the TX or the RX. Sending ECHOs will not help you there -- You need to send some data along with your regular BFD packet for it to be meaningful. Cheers, Manav On Thu, Dec 4, 2014 at 11:43 AM, Gregory Mirsky wrote: > Hi Santosh, > yes, the format and thus interpretation of payload in Echo mode is not > defined and that, in my view, is what we need - some open space. And Echo > well could be exactly that - no legacy, no backward compatibility > (addressee that doesn't support "extended Echo" will simply loop the packet > back to sender). Perhaps that will be direction we can discuss and, > hopefully, agree on. > > Regards, > Greg > > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Wednesday, December 03, 2014 9:54 PM > To: Gregory Mirsky; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 > > Greg, > I don't think we have discussed about echo in this context. Echo is > good thing but payload of BFD echo packet is decided by local system. Did > you mean to add suggestion on how echo packet should look like? Or how echo > can help in BFD loss/delay issue? > > Thanks > Santosh P K > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, December 04, 2014 2:22 AM > > To: Santosh P K; Marc Binderberger; Manav Bhatia > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD stability follow-up from IETF-91 > > > > Dear All, > > had authors of the proposal or we already dismissed use of BFD Echo? > > I've scanned the thread and couldn't find trace of us discussing BFD > > Echo mode. I think that it is more suitable for experimentation and > unorthodox use. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P > > K > > Sent: Wednesday, December 03, 2014 5:39 AM > > To: Marc Binderberger; Manav Bhatia > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD stability follow-up from IETF-91 > > > > Hello Manav and Marc, > > > > > > > > One way to solve this problem is by attaching a debug trailer that > > > > only carries the seq numbers at the *end* of the BFD packet. This > > > > would not be covered in the Length field carried in the BFD header > > > > but would be accounted for in the length carried in the IP header. > > > > > > BFD itself is not related to IP, i.e. there is not always an IP header. > > > Sure, the encapsulating "frame" may provide a length but actually, > > > why not covering the debug trailer with the BFD length? > > > > > > If this is solely for debug purpose than this may work. For simple > > > copying-out into e.g. a packet trace buffer it would be even simpler > > > to have the BFD length covering the trailer. > > > If hardware is supposed to process the trailer information (other > > > than copying out) then it's getting ugly - having fixed position, > > > fixed length extension headers would be preferable for simple access. > > > > Fixed length would be easy to process in hardware. Problem is when we > > have many have extensions in future. If we want to use only one > > extension that is at the last then I will be forced to pad all the > > other extension ahead of it? This might not be a problem if we have > > fewer extensions but might become problem when there are too many > extensions. > > > > > > > > > > Another idea is to use the 0x80 bit of the auth type to distinguish > > > between a "normal" authentication header and a "sequence + > > authentication". > > > > > > > I think this is good. In the BFD extension TLV we still have many > > reserved bits that can be used as well? > > > > Thanks > > Santosh P K > > > > > > > > > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > > Hi Santosh, > > > > > > > > You could use the crypto sequence numbers carried in the > > > > meticulous cryptographic auth for detecting packet losses. > > > > However, this breaks when you use non-meticulous crypto > > > > authentication since the sequence number is only incremented > > > > occasionally there. This i believe is a deal breaker since i > > > > really envision non meticulous mode to be the one being widely > > > > deployed. In fact we were supposed to write a draft on that and i > > > > guess it just fell through the cracks (lemme ping my co-author on > > > > that !) > > > > > > > > One way to solve this problem is by attaching a debug trailer that > > > > only carries the seq numbers at the *end* of the BFD packet. This > > > > would not be covered in the Length field carried in the BFD header > > > > but would be accounted for in the length carried in the IP header. > > > > The concept of attaching a trailer is documented well and is used > > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The > > > > catch however is that this debug trailer will NOT be covered by > > > > the BFD authentication. Is this acceptable to the WG? > > > > > > > > I think the problem of diagnosing a BFD flap becomes all the more > > > > important with BFD authentication turned on since then we have > > > > more points where a delay can be inserted. > > > > > > > > Cheers, Manav > > > > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > > > > > > wrote: > > > >> Manav, > > > >> This is good question. > > > >> > > > >>> Can the authors add some text on how this debugging mechanism > > > >>> would work if somebody employs BFD authentication? > > > >> > > > >> Right now we have considered without authentication (we are > > > >> setting A bit). We should add some text on how we can use both > > > >> Auth and de bug > > > TLV. > > > >> Is there any suggestion you have? I will get back to you on this. > > > >> > > > >> > > > >> Thanks > > > >> Santosh P K > > > >> > > > >>>> -----Original Message----- > > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > >>>> Mach > > > Chen > > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > > >>>> To: Marc Binderberger > > > >>>> Cc: rtg-bfd@ietf.org > > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > > >>>> > > > >>>> Hi Marc, > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > > >>>>> To: Mach Chen > > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > > >>>>> > > > >>>>> Hello Mach, > > > >>>>> > > > >>>>>> This triggers me think out there should be another solution > > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > > >>>>>> timestamps > > > in > > > >>>>>> the BFD > > > >>>>> packets. > > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > > >>>>>> locally or send them to a centralized entity and then use the > > > >>>>>> sequence numbers to correlate them for further analyzing. > > > >>>>> > > > >>>>> I remember some discussion on NVO3 about how many bits it > > > >>>>> takes > > > >>>>> ;- > > > ) - > > > >>>>> could you send the links/draft names you are working on to this > list? > > > >>>>> May be useful for further discussions. > > > >>>> > > > >>>> Sure, here is the > > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > > >>> based-ipfpm-framework-02) for the reference. > > > >>>> > > > >>>> But here I want to say is that since we have sequence number, > > > >>>> we may > > > not > > > >>> need the marking based solution. Suppose that someone want to > > > monitor > > > >>> the delay of a BFD packet , just record and save the timestamp > > > >>> at the Tx side, which indexed by the sequence number. Similarly, > > > >>> do the same at the Rx side. Then based on the timestamps from > > > >>> both Tx and Rx, and using the sequence number to correlate the > > > >>> timestamps, it can also provide a way > > > to > > > >>> monitor the delay of the BFD packet. > > > >>>> > > > >>>> That means, only if there is sequence number, even if without > > > >>>> carrying the > > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > > >>>> > > > >>>> Best regards, > > > >>>> Mach > > > >>>> > > > >>>>> > > > >>>>> > > > >>>>> Thanks & Regards, > > > >>>>> Marc > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > > >>>>>> Hi Marc and Manav, > > > >>>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > Marc > > > >>>>>>> Binderberger > > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > > >>>>>>> To: Manav Bhatia > > > >>>>>>> Cc: rtg-bfd@ietf.org > > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > > >>>>>>> > > > >>>>>>> Hello Manav, > > > >>>>>>> > > > >>>>>>>> I believe the work is important and addresses something > > > >>>>>>>> thats really required (spent too much time debugging why > > > >>>>>>>> BFD > > > flapped!). > > > >>>>>>> > > > >>>>>>> agree :-) we should keep the discussion alive. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>> side Time stamping would have helped in debugging whether > > the > > > >>> BFD > > > >>>>>>>> packet was sent late, or whether the packet was sent on > > > >>>>>>>> time and also arrived on time but was delayed when passing > > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad > > > >>>>>>>> too > > > >>>>>>>> long) > > > >>>>>>> > > > >>>>>>> well, I can see a point in having the Tx timestamps in the > > > >>>>>>> packet mainly for the purpose of knowing "this" packet was > > > >>>>>>> okay/not okay on the Tx side and to correlate it with your > > > >>>>>>> local Rx > > measurement. > > > >>>>>> > > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > > >>>>>> If allow to have Tx timestamps to be carried in the packets, > > > >>>>>> seems it should be no problem to leave a seat for the Rx > > > >>>>>> timestamps as well :-). After all, with both Tx and Rx > > > >>>>>> timestamp, it may simplify the > > > >>>>> implementation. > > > >>>>>> > > > >>>>>>> > > > >>>>>>> And even this point is less relevant with sequence numbers > > > >>>>>>> as this number allows the identification of packets and thus > > > >>>>>>> the correlation of information from the Tx and Rx system. > > > >>>>>> > > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > > between > > > >>>>>> the Tx and Rx system. > > > >>>>>> > > > >>>>>> This triggers me think out there should be another solution > > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > > >>>>>> timestamps > > > in > > > >>>>>> the BFD > > > >>>>> packets. > > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > > >>>>>> locally or send them to a centralized entity and then use the > > > >>>>>> sequence numbers to correlate them for further analyzing. > > > >>>>>> > > > >>>>>> Best regards, > > > >>>>>> Mach > > > >>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Regards, Marc > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > > >>>>>>>> Hi Jeff, > > > >>>>>>>> > > > >>>>>>>> I vividly remember the original intent of the stability > > > >>>>>>>> draft was to help debug BFD failures -- to isolate the > > > >>>>>>>> issue at the RX or the TX side Time stamping would have > > > >>>>>>>> helped in debugging > > > whether > > > >>>>>>>> the BFD packet was sent late, or whether the packet was > > > >>>>>>>> sent on time and also arrived on time but was delayed when > > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer > > > >>>>>>>> for tad too long), etc. But then time stamping came with > > > >>>>>>>> its own set of issues, and was hence dropped from the > original draft. > > > >>>>>>>> > > > >>>>>>>> Can the authors send a summary on the list on why time > > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > > >>>>>>>> > > > >>>>>>>> The current proposal does help but is not complete. > > > >>>>>>>> > > > >>>>>>>> Assume that the RX end loses a BFD session and learns later > > > >>>>>>>> that it did eventually receive the missing BFD packets > > > >>>>>>>> (based on the > > > seq > > > >>> #). > > > >>>>>>>> How would it know which end was misbehaving? Was it a delay > > > >>>>>>>> at the TX side, or was it the RX that delayed passing the > > > >>>>>>>> packets to the BFD process(or). This is usually what we > > > >>>>>>>> want to debug and i want to understand how this draft with > > > >>>>>>>> sequence numbers can unequivocally tell me that. > > > >>>>>>>> > > > >>>>>>>> I believe the work is important and addresses something > > > >>>>>>>> thats really required (spent too much time debugging why > > > >>>>>>>> BFD > > > flapped!). > > > >>>>>>>> Clearly what would help is putting a small section that > > > >>>>>>>> describes how we can use the sequence numbers to debug > > what > > > >>>>>>>> and > > > where > > > >>> things went wrong. > > > >>>>>>>> > > > >>>>>>>> Cheers, Manav > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > > > >>>>>>>> > > > >>> wrote: > > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > > >>>>>>>>> > > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > > >>>>>>>>> pp > > > >>>>>>>>> tx > > > >>>>>>>>> > > > >>>>>>>>> To attempt to simplify the presentation, the contentious > > > >>>>>>>>> portion of the timers were removed from the proposal, > > > >>>>>>>>> leaving only the sequence numbering for detecting loss of > > > >>>>>>>>> BFD > > async packets. > > > >>>>>>>>> > > > >>>>>>>>> When the room was polled to see whether the draft should > > > >>>>>>>>> be adopted as a WG item, the sense of the room was very > quiet. > > > >>>>>>>>> As promised, this is to inquire for support for this draft > > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > > voice. > > > >>>>>>>>> > > > >>>>>>>>> It should be noted that post-meeting discussion on the > > > >>>>>>>>> fate of this draft noted that BFD authentication code > > > >>>>>>>>> points are plentiful and are available with expert review. > > > >>>>>>>>> Should the draft authors wish to continue this work as > > > >>>>>>>>> Experimental, that is > > > an > > > >>> option. > > > >>>>>>>>> > > > >>>>>>>>> -- Jeff > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>> > > > >>>> > > > >> > > > > > > --047d7b5d341addc91e050963252b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greg,

This is not what we want.

We wanted some additional data carried in the BFD packets= that can help us diagnose BFD failures. We dont want an out-of-band mechan= ism to tell us whether BFD packets are getting dropped or not (there are ot= her OAM tools for that). We're not even interested in that. What we wan= t to know is why a particular BFD session flapped -- whether the issue was = at the TX or the RX. Sending ECHOs will not help you there -- You need to s= end some data along with your regular BFD packet for it to be meaningful.

Cheers, Manav

On Thu, Dec 4, 2014 at 11:43 AM, Gregory Mi= rsky <gregory.mirsky@ericsson.com> wrote:
Hi Santosh,
yes, the format and thus interpretation of payload in Echo mode is not defi= ned and that, in my view, is what we need - some open space. And Echo well = could be exactly that - no legacy, no backward compatibility (addressee tha= t doesn't support "extended Echo" will simply loop the packet= back to sender). Perhaps that will be direction we can discuss and, hopefu= lly, agree on.

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

-----Original Message-----
From: Santosh P K [mailto:santoshp= k@juniper.net]
Sent: Wednesday, December 03, 2014 9:54 PM
To: Gregory Mirsky; Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up from IETF-91

Greg,
=C2=A0 =C2=A0I don't think we have discussed about echo in this context= . Echo is good thing but payload of BFD echo packet is decided by local sys= tem. Did you mean to add suggestion on how echo packet should look like? Or= how echo can help in BFD loss/delay issue?

Thanks
Santosh P K

> -----Original Message-----
> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> Sent: Thursday, December 04, 2014 2:22 AM
> To: Santosh P K; Marc Binderberger; Manav Bhatia
> Cc: rtg-bfd@ietf.org
> Subject: RE: BFD stability follow-up from IETF-91
>
> Dear All,
> had authors of the proposal or we already dismissed use of BFD Echo? > I've scanned the thread and couldn't find trace of us discussi= ng BFD
> Echo mode. I think that it is more suitable for experimentation and un= orthodox use.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Santosh P
> K
> Sent: Wednesday, December 03, 2014 5:39 AM
> To: Marc Binderberger; Manav Bhatia
> Cc: rtg-bfd@ietf.org
> Subject: RE: BFD stability follow-up from IETF-91
>
> Hello Manav and Marc,
>
>
> > > One way to solve this problem is by attaching a debug traile= r that
> > > only carries the seq numbers at the *end* of the BFD packet.= This
> > > would not be covered in the Length field carried in the BFD = header
> > > but would be accounted for in the length carried in the IP h= eader.
> >
> > BFD itself is not related to IP, i.e. there is not always an IP h= eader.
> > Sure, the encapsulating "frame" may provide a length bu= t actually,
> > why not covering the debug trailer with the BFD length?
> >
> > If this is solely for debug purpose than this may work. For simpl= e
> > copying-out into e.g. a packet trace buffer it would be even simp= ler
> > to have the BFD length covering the trailer.
> > If hardware is supposed to process the trailer information (other=
> > than copying out) then it's getting ugly - having fixed posit= ion,
> > fixed length extension headers would be preferable for simple acc= ess.
>
> Fixed length would be easy to process in hardware. Problem is when we<= br> > have many have extensions in future. If we want to use only one
> extension that is at the last then I will be forced to pad all the
> other extension ahead of it? This might not be a problem if we have > fewer extensions but might become problem when there are too many exte= nsions.
>
>
> >
> > Another idea is to use the 0x80 bit of the auth type to distingui= sh
> > between a "normal" authentication header and a "se= quence +
> authentication".
> >
>
> I think this is good. In the BFD extension TLV we still have many
> reserved bits that can be used as well?
>
> Thanks
> Santosh P K
>
>
>
> >
> > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote:
> > > Hi Santosh,
> > >
> > > You could use the crypto sequence numbers carried in the
> > > meticulous cryptographic auth for detecting packet losses. > > > However, this breaks when you use non-meticulous crypto
> > > authentication since the sequence number is only incremented=
> > > occasionally there. This i believe is a deal breaker since i=
> > > really envision non meticulous mode to be the one being wide= ly
> > > deployed. In fact we were supposed to write a draft on that = and i
> > > guess it just fell through the cracks (lemme ping my co-auth= or on
> > > that !)
> > >
> > > One way to solve this problem is by attaching a debug traile= r that
> > > only carries the seq numbers at the *end* of the BFD packet.= This
> > > would not be covered in the Length field carried in the BFD = header
> > > but would be accounted for in the length carried in the IP h= eader.
> > > The concept of attaching a trailer is documented well and is= used
> > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3.= The
> > > catch however is that this debug trailer will NOT be covered= by
> > > the BFD authentication. Is this acceptable to the WG?
> > >
> > > I think the problem of diagnosing a BFD flap becomes all the= more
> > > important with BFD authentication turned on since then we ha= ve
> > > more points where a delay can be inserted.
> > >
> > > Cheers, Manav
> > >
> > >
> > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K
> > > <santoshpk@junip= er.net>
> > wrote:
> > >> Manav,
> > >>=C2=A0 =C2=A0 =C2=A0This is good question.
> > >>
> > >>> Can the authors add some text on how this debugging = mechanism
> > >>> would work if somebody employs BFD authentication? > > >>
> > >> Right now we have considered without authentication (we = are
> > >> setting A bit). We should add some text on how we can us= e both
> > >> Auth and de bug
> > TLV.
> > >> Is there any suggestion you have? I will get back to you= on this.
> > >>
> > >>
> > >> Thanks
> > >> Santosh P K
> > >>
> > >>>> -----Original Message-----
> > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
> > >>>> Mach
> > Chen
> > >>>> Sent: Thursday, November 27, 2014 2:13 PM
> > >>>> To: Marc Binderberger
> > >>>> Cc: rtg-bfd@= ietf.org
> > >>>> Subject: RE: BFD stability follow-up from IETF-9= 1
> > >>>>
> > >>>> Hi Marc,
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Marc Binderberger [mailto:marc@sniff.de]
> > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > >>>>> To: Mach Chen
> > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org
> > >>>>> Subject: RE: BFD stability follow-up from IE= TF-91
> > >>>>>
> > >>>>> Hello Mach,
> > >>>>>
> > >>>>>> This triggers me think out there should = be another solution
> > >>>>>> for getting the Tx and Rx timestamps wit= hout encoding the
> > >>>>>> timestamps
> > in
> > >>>>>> the BFD
> > >>>>> packets.
> > >>>>>> For example, the Tx and Rx systems could= just save timestamps
> > >>>>>> locally or send them to a centralized en= tity and then use the
> > >>>>>> sequence numbers to correlate them for f= urther analyzing.
> > >>>>>
> > >>>>> I remember some discussion on NVO3 about how= many bits it
> > >>>>> takes
> > >>>>> ;-
> > ) -
> > >>>>> could you send the links/draft names you are= working on to this list?
> > >>>>> May be useful for further discussions.
> > >>>>
> > >>>> Sure, here is the
> > >>>> link(http://tools.ietf.org/html/draft-ch= en-ippm-coloring-
> > >>> based-ipfpm-framework-02) for the reference.
> > >>>>
> > >>>> But here I want to say is that since we have seq= uence number,
> > >>>> we may
> > not
> > >>> need the marking based solution. Suppose that someon= e want to
> > monitor
> > >>> the delay of a BFD packet , just record and save the= timestamp
> > >>> at the Tx side, which indexed by the sequence number= . Similarly,
> > >>> do the same at the Rx side. Then based on the timest= amps from
> > >>> both Tx and Rx, and using the sequence number to cor= relate the
> > >>> timestamps, it can also provide a way
> > to
> > >>> monitor the delay of the BFD packet.
> > >>>>
> > >>>> That means, only if there is sequence number, ev= en if without
> > >>>> carrying the
> > >>> timestamp in the BFD packet, BFD packet delay can be= measured.
> > >>>>
> > >>>> Best regards,
> > >>>> Mach
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>> Thanks & Regards,
> > >>>>> Marc
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Che= n wrote:
> > >>>>>> Hi Marc and Manav,
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > Marc
> > >>>>>>> Binderberger
> > >>>>>>> Sent: Wednesday, November 26, 2014 4= :50 PM
> > >>>>>>> To: Manav Bhatia
> > >>>>>>> Cc: rtg-bfd@ietf.org
> > >>>>>>> Subject: Re: BFD stability follow-up= from IETF-91
> > >>>>>>>
> > >>>>>>> Hello Manav,
> > >>>>>>>
> > >>>>>>>> I believe the work is important = and addresses something
> > >>>>>>>> thats really required (spent too= much time debugging why
> > >>>>>>>> BFD
> > flapped!).
> > >>>>>>>
> > >>>>>>> agree :-) we should keep the discuss= ion alive.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> side Time stamping would have he= lped in debugging whether
> the
> > >>> BFD
> > >>>>>>>> packet was sent late, or whether= the packet was sent on
> > >>>>>>>> time and also arrived on time bu= t was delayed when passing
> > >>>>>>>> it up the BFD stack/processor (l= ay in the RX buffer for tad
> > >>>>>>>> too
> > >>>>>>>> long)
> > >>>>>>>
> > >>>>>>> well, I can see a point in having th= e Tx timestamps in the
> > >>>>>>> packet mainly for the purpose of kno= wing "this" packet was
> > >>>>>>> okay/not okay on the Tx side and to = correlate it with your
> > >>>>>>> local Rx
> measurement.
> > >>>>>>
> > >>>>>> Yes, this is one solution if people thin= k BFD delay is needed.
> > >>>>>> If allow to have Tx timestamps to be car= ried in the packets,
> > >>>>>> seems it should be no problem to leave a= seat for the Rx
> > >>>>>> timestamps as well :-). After all, with = both Tx and Rx
> > >>>>>> timestamp, it may simplify the
> > >>>>> implementation.
> > >>>>>>
> > >>>>>>>
> > >>>>>>> And even this point is less relevant= with sequence numbers
> > >>>>>>> as this number allows the identifica= tion of packets and thus
> > >>>>>>> the correlation of information from = the Tx and Rx system.
> > >>>>>>
> > >>>>>> Indeed, the sequence number helps a lot = for the correlation
> > between
> > >>>>>> the Tx and Rx system.
> > >>>>>>
> > >>>>>> This triggers me think out there should = be another solution
> > >>>>>> for getting the Tx and Rx timestamps wit= hout encoding the
> > >>>>>> timestamps
> > in
> > >>>>>> the BFD
> > >>>>> packets.
> > >>>>>> For example, the Tx and Rx systems could= just save timestamps
> > >>>>>> locally or send them to a centralized en= tity and then use the
> > >>>>>> sequence numbers to correlate them for f= urther analyzing.
> > >>>>>>
> > >>>>>> Best regards,
> > >>>>>> Mach
> > >>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Regards, Marc
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, = Manav Bhatia wrote:
> > >>>>>>>> Hi Jeff,
> > >>>>>>>>
> > >>>>>>>> I vividly remember the original = intent of the stability
> > >>>>>>>> draft was to help debug BFD fail= ures -- to isolate the
> > >>>>>>>> issue at the RX or the TX side T= ime stamping would have
> > >>>>>>>> helped in debugging
> > whether
> > >>>>>>>> the BFD packet was sent late, or= whether the packet was
> > >>>>>>>> sent on time and also arrived on= time but was delayed when
> > >>>>>>>> passing it up the BFD stack/proc= essor (lay in the RX buffer
> > >>>>>>>> for tad too long), etc. But then= time stamping came with
> > >>>>>>>> its own set of issues, and was h= ence dropped from the original draft.
> > >>>>>>>>
> > >>>>>>>> Can the authors send a summary o= n the list on why time
> > >>>>>>>> stamping was dropped so that we&= #39;re all clear on that one.
> > >>>>>>>>
> > >>>>>>>> The current proposal does help b= ut is not complete.
> > >>>>>>>>
> > >>>>>>>> Assume that the RX end loses a B= FD session and learns later
> > >>>>>>>> that it did eventually receive t= he missing BFD packets
> > >>>>>>>> (based on the
> > seq
> > >>> #).
> > >>>>>>>> How would it know which end was = misbehaving? Was it a delay
> > >>>>>>>> at the TX side, or was it the RX= that delayed passing the
> > >>>>>>>> packets to the BFD process(or). = This is usually what we
> > >>>>>>>> want to debug and i want to unde= rstand how this draft with
> > >>>>>>>> sequence numbers can unequivocal= ly tell me that.
> > >>>>>>>>
> > >>>>>>>> I believe the work is important = and addresses something
> > >>>>>>>> thats really required (spent too= much time debugging why
> > >>>>>>>> BFD
> > flapped!).
> > >>>>>>>> Clearly what would help is putti= ng a small section that
> > >>>>>>>> describes how we can use the seq= uence numbers to debug
> what
> > >>>>>>>> and
> > where
> > >>> things went wrong.
> > >>>>>>>>
> > >>>>>>>> Cheers, Manav
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM,= Jeffrey Haas
> > >>>>>>>> <jhaas@pfrc.org>
> > >>> wrote:
> > >>>>>>>>> draft-ashesh-bfd-stability-0= 1 was presented again during
> > >>>>>>>>> IETF-91 in Honolulu.=C2=A0 T= he slides can be viewed here:
> > >>>>>>>>>
> > >>>>>>>>> http://www.ietf= .org/proceedings/91/slides/slides-91-bfd-4.
> > >>>>>>>>> pp
> > >>>>>>>>> tx
> > >>>>>>>>>
> > >>>>>>>>> To attempt to simplify the p= resentation, the contentious
> > >>>>>>>>> portion of the timers were r= emoved from the proposal,
> > >>>>>>>>> leaving only the sequence nu= mbering for detecting loss of
> > >>>>>>>>> BFD
> async packets.
> > >>>>>>>>>
> > >>>>>>>>> When the room was polled to = see whether the draft should
> > >>>>>>>>> be adopted as a WG item, the= sense of the room was very quiet.
> > >>>>>>>>> As promised, this is to inqu= ire for support for this draft
> > >>>>>>>>> on the WG mailing list to ma= ke sure the whole group has a
> voice.
> > >>>>>>>>>
> > >>>>>>>>> It should be noted that post= -meeting discussion on the
> > >>>>>>>>> fate of this draft noted tha= t BFD authentication code
> > >>>>>>>>> points are plentiful and are= available with expert review.
> > >>>>>>>>> Should the draft authors wis= h to continue this work as
> > >>>>>>>>> Experimental, that is
> > an
> > >>> option.
> > >>>>>>>>>
> > >>>>>>>>> -- Jeff
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > >


--047d7b5d341addc91e050963252b-- From nobody Thu Dec 4 05:27:47 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D198A1A88CB for ; Wed, 3 Dec 2014 22:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 FEK9EtnVHW3R for ; Wed, 3 Dec 2014 22:23:03 -0800 (PST) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30B91A88C8 for ; Wed, 3 Dec 2014 22:23:02 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so12382575qcr.14 for ; Wed, 03 Dec 2014 22:23:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=i8Qeqe6W9QOPh8JNO9f0xPMAFJnM9KvZmcSa3hoK1tc=; b=xCMTLcCem7bPORCN6rUBe1vNQOjsoRO14Yft0yP05buQ7b6PSbUWJyVBogFZj1R5Aj 1j5vX+NW3Zl/1JctVn0WYco3czsjvaeeRlpcDhUctYu7BIPdhPznakRr0iUPSWSbIkZn 9WLJS9nUYGdZuuDyv+bnC2h3mYo/46iXoz5eLSzVRCIta/lVfg/AEEJi9YhpAd+n9kFj ET3pTwYGo+/Opezja6i4P0krXvuAcYSl7JJDpI01iU3nkWrACfQw6KncwEhvbxQ9aBPr 1ZRTS50Yw/NUmwRAFT8vDZjMX9QP0/nbCxur/szdJShxhhMT1v2FbHDG210fAWg3s+sw sV7Q== X-Received: by 10.224.4.133 with SMTP id 5mr14223659qar.37.1417674182133; Wed, 03 Dec 2014 22:23:02 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id e7sm8787626qag.49.2014.12.03.22.23.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 22:23:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AFCC8517-66EF-4AF5-8E04-9BDE8997F415" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: BFD stability follow-up from IETF-91 From: Mahesh Jethanandani In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> Date: Wed, 3 Dec 2014 22:22:57 -0800 Message-Id: <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/nmoooPqrvVkWKMIUDSJFA3kvfcU X-Mailman-Approved-At: Thu, 04 Dec 2014 05:27:20 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 06:23:07 -0000 X-List-Received-Date: Thu, 04 Dec 2014 06:23:07 -0000 --Apple-Mail=_AFCC8517-66EF-4AF5-8E04-9BDE8997F415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greg, I believe we have a disagreement here. I do not believe that issue of = debug ability are outside the scope of a standardized protocol. Look at MPLS ping and traceroute (RFC 4379) . They are ultimately debug = tools used to establish viability of a path and they are very much part = of the standardized protocol. > On Dec 3, 2014, at 3:25 PM, Gregory Mirsky = wrote: >=20 > Hi Mahesh, > I consider issues of debugability, not of just BFD but any other = standardized protocol, to be outside of Standard track, at most to be = suitable for Informational or Experimental track. If we agree on that, = then we can discuss scenarios that present problem and investigate = whether anything in the protocol requires clarification to help vendors = in building well-performing, scalable and interoperable implementations = and provide operational guidelines for operators. > =20 > Regards, > Greg > =20 > From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]=20 > Sent: Tuesday, December 02, 2014 8:46 PM > To: Gregory Mirsky > Cc: Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: Re: BFD stability follow-up from IETF-91 > =20 > Greg, > =20 > What is Peng referring to is a way to figure out why a particular BFD = session flapped, particularly if the packet(s) for that session arrive = late. I do not see how that can be performance measurement. It is basic = BFD debug ability. Running a separate DM does tell you why a particular = BFD session flapped. > =20 > Now we can debate what methods can be employed to measure that delay = and I am open to ways to doing it, including local loopback to measure = transmit delays or time stamping of packets in hardware. But in cases, = where there is no support for either of the capabilities, one of the = suggested solutions is to use the time stamps carried in the BFD = payload.=20 > =20 > Cheers. > =20 > On Dec 1, 2014, at 9:38 AM, Gregory Mirsky = > = wrote: > =20 > Hi Peng, > and still, you=E2=80=99re looking for a tool to measure BFD = performance. Then you=E2=80=99ll be looking for a tool to verify the BFD = performance measurement, and on, and on. Operators do need complete set = of FCAPS tools, including performance measurement. Note that passive = performance measurement through marking method that Mach Chen referred = to can monitor BFD flow(s) and be used to do Loss and/or Delay = Measurement. And active Synthetic Loss Measurement may simulate flow of = small packets as well as relatively large packets. And the same goes for = active measurement method of Delay Measurement. I like Swiss Army knives = but let us not turn BFD into one. > =20 > Regards, > Greg > =20 > From: Fan, Peng [mailto:fanpeng@chinamobile.com = ]=20 > Sent: Monday, December 01, 2014 4:44 AM > To: Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org = > Subject: RE: BFD stability follow-up from IETF-91 > =20 > Hi Gregory, > =20 > I was just giving an example :) Application traffic usually cannot = stand small packet loss, not to say 30% loss. > =20 > I am actually asking for a debug function that could give us some = useful hints of poor connection with small protocol change, besides the = basic connectivity information. If it measures something, it measures = packets of BFD itself. So I don=E2=80=99t expect it to be considered as = a performance measurement tool. > =20 > Best regards, > Peng > =20 > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com = ]=20 > Sent: Saturday, November 29, 2014 3:37 AM > To: Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org = > Subject: RE: BFD stability follow-up from IETF-91 > =20 > Hi Peng, > this is very interesting scenario. I think that if BFD experiences = ~30% packet loss, then highly likely so are affected other applications. = Then it is not just BFD issue but condition that should be detected by = performance measurement method, whether active or passive packet loss = measurement. > I=E2=80=99m convinced that overloading BFD with performance = measurement provisions is counter-productive and is inappropriate. > =20 > Regards, > Greg > =20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] On Behalf Of Fan, Peng > Sent: Friday, November 28, 2014 4:34 AM > To: 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org = > Subject: RE: BFD stability follow-up from IETF-91 > =20 > Hi Mallik, > =20 > Exactly. Packets may be experiencing slight loss, but the link can = hardly be regarded as connected. More importantly, the experience of = upper-level applications can be degraded severely (e.g. TCP traffic is = not able to go fast in face of even small continuous loss). But what if = one BFD frame is lost every three frames? Then the loss rate is 30% on = average, which is already a very severe value. > =20 > Best regards, > Peng > =20 > From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com = ]=20 > Sent: Friday, November 28, 2014 7:53 PM > To: Fan, Peng; rtg-bfd@ietf.org > Subject: Re: BFD stability follow-up from IETF-91 > =20 > Hi Peng, > =20 > If the BFD packets are lost, doesn=E2=80=99t the BFD session go DOWN? = Are you saying that packet loss is not big enough to make BFD session go = DOWN? > =20 > Thanks > =20 > Regards > Mallik > =20 > From: , Peng > > Date: Friday, 28 November 2014 4:20 pm > To: "rtg-bfd@ietf.org " > > Subject: RE: BFD stability follow-up from IETF-91 > =20 > Hi Jeff, all, > =20 > I have been following this stability extension from the beginning, and = as an > operator I would like to express that this draft enables the "advanced > feature" we desire for BFD to provide additional useful information = that > helps operators understand network issues. A relevant use case is = detecting > lossy or "quasi-disconnected" links or member LAG links. An example of = such > situation we experienced was a loosely connected fiber link resulting = in > continuous, small amount of packet loss. BFD could get the information = of > lost BFD frames on such unstable link, and probably report when a = target > level is reached, say a certain number of frames are lost over a = period or > among a total number of frames. > =20 > Best regards, > Peng > =20 > Mahesh Jethanandani > Co-chair, NETCONF WG > mjethanandani@gmail.com Mahesh Jethanandani Co-chair, NETCONF WG mjethanandani@gmail.com --Apple-Mail=_AFCC8517-66EF-4AF5-8E04-9BDE8997F415 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Greg,

I = believe we have a disagreement here. I do not believe that issue of = debug ability are outside the scope of a standardized = protocol.

Look = at MPLS ping and traceroute (RFC 4379) . They are ultimately debug tools = used to establish viability of a path and they are very much part of the = standardized protocol.

On = Dec 3, 2014, at 3:25 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Mahesh,
I consider issues of debugability, not of = just BFD but any other standardized protocol, to be outside of Standard = track, at most to be suitable for Informational or Experimental track. = If we agree on that, then we can discuss scenarios that present problem = and investigate whether anything in the protocol requires clarification = to help vendors in building well-performing, scalable and interoperable = implementations and provide operational guidelines for operators.
 
          &nb= sp;     Regards,
          &nb= sp;            = ;         Greg
 
From: Mahesh = Jethanandani [mailto:mjethanandani@gmail.com] 
Sent: Tuesday, December 02, 2014 = 8:46 PM
To: Gregory Mirsky
Cc: Fan, Peng; MALLIK MUDIGONDA = (mmudigon); rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up = from IETF-91
 
Greg,
 
What is Peng referring to is a way to figure out why = a particular BFD session flapped, particularly if the packet(s) for that = session arrive late. I do not see how that can be performance = measurement. It is basic BFD debug ability. Running a separate DM does = tell you why a particular BFD session flapped.
 
Now we can debate what methods can be = employed to measure that delay and I am open to ways to doing it, = including local loopback to measure transmit delays or time stamping of = packets in hardware. But in cases, where there is no support for either = of the capabilities, one of the suggested solutions is to use the time = stamps carried in the BFD payload. 
 
Cheers.
 
On Dec 1, 2014, at = 9:38 AM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:
 
Hi = Peng,
and= still, you=E2=80=99re looking for a tool to measure BFD performance. = Then you=E2=80=99ll be looking for a tool to verify the BFD performance = measurement, and on, and on. Operators do need complete set of FCAPS = tools, including performance measurement. Note that passive performance = measurement through marking method that Mach Chen referred to can = monitor BFD flow(s) and be used to do Loss and/or Delay Measurement. And = active Synthetic Loss Measurement may simulate flow of small packets as = well as relatively large packets. And the same goes for active = measurement method of Delay Measurement. I like Swiss Army knives but = let us not turn BFD into one.
 
          &nb= sp;     Regards,
          &nb= sp;            = ;         Greg
 
From: Fan, Peng [mailto:fanpeng@chinamobile.com] 
Sent: Monday, December 01, 2014 = 4:44 AM
To: Gregory Mirsky; 'MALLIK = MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up = from IETF-91
 
Hi Gregory,
 
I was just giving an = example :) Application traffic usually cannot stand small packet loss, = not to say 30% loss.
 
I am actually asking = for a debug function that could give us some useful hints of poor = connection with small protocol change, besides the basic connectivity = information. If it measures something, it measures packets of BFD = itself. So I don=E2=80=99t expect it to be considered as a performance = measurement tool.
 
Best = regards,
Peng
 
From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] 
Sent: Saturday, November 29, 2014 = 3:37 AM
To: Fan, Peng; 'MALLIK = MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up = from IETF-91
 
Hi Peng,
this is very = interesting scenario. I think that if BFD experiences ~30% packet loss, = then highly likely so are affected other applications. Then it is not = just BFD issue but condition that should be detected  by = performance measurement method, whether active or passive packet loss = measurement.
I=E2=80=99m convinced that overloading BFD with performance = measurement provisions is counter-productive and is = inappropriate.
 
          &nb= sp;     Regards,
          &nb= sp;            = ;         Greg
 
From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Fan, Peng
Sent: Friday, November 28, 2014 = 4:34 AM
To: 'MALLIK MUDIGONDA = (mmudigon)'; rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up = from IETF-91
 
Hi Mallik,
 
Exactly. Packets may be = experiencing slight loss, but the link can hardly be regarded as = connected. More importantly, the experience of upper-level applications = can be degraded severely (e.g. TCP traffic is not able to go fast in = face of even small continuous loss). But what if one BFD frame is lost = every three frames? Then the loss rate is 30% on average, which is = already a very severe value.
 
Best = regards,
Peng
 
From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] 
Sent: Friday, November 28, 2014 = 7:53 PM
To: Fan, Peng; rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up = from IETF-91
 
Hi Peng,
 
If the BFD packets are lost, = doesn=E2=80=99t the BFD session go DOWN? Are you saying that packet loss = is not big enough to make BFD session go DOWN?
 
Thanks
 
Regards
Mallik
 
From: <Fan>, Peng <fanpeng@chinamobile.com>
Date: Friday, 28 November = 2014 4:20 pm
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: BFD stability = follow-up from IETF-91
 
Hi Jeff, all,
 
I have been following this = stability extension from the beginning, and as an
operator I would like to = express that this draft enables the "advanced
feature" we desire for BFD = to provide additional useful information that
helps operators understand = network issues. A relevant use case is detecting
lossy or = "quasi-disconnected" links or member LAG links. An example of = such
situation we experienced was a loosely connected fiber link = resulting in
continuous, small amount of packet loss. BFD could get the = information of
lost BFD frames on such unstable link, and probably report = when a target
level is reached, say a certain number of frames are lost = over a period or
among a total number of frames.
 
Best regards,
Peng
 
Mahesh Jethanandani
Co-chair, NETCONF WG
mjethanandani@gmail.com

Mahesh Jethanandani
Co-chair, NETCONF WG
mjethanandani@gmail.com




= --Apple-Mail=_AFCC8517-66EF-4AF5-8E04-9BDE8997F415-- From nobody Thu Dec 4 05:27:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9901A88C8 for ; Wed, 3 Dec 2014 22:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 khuhpOmfcis0 for ; Wed, 3 Dec 2014 22:41:51 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 451311A00CF for ; Wed, 3 Dec 2014 22:41:51 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-51-547fb21e7fcf Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9B.08.03307.E12BF745; Thu, 4 Dec 2014 02:00:15 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 01:41:49 -0500 From: Gregory Mirsky To: Mahesh Jethanandani Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAjSUAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAF9PggASh4oD///wSUIACoyWAgADg8VCAAMxrgP//rMkg Date: Thu, 4 Dec 2014 06:41:48 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> In-Reply-To: <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.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_7347100B5761DC41A166AC17F22DF1121B8AAA24eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyuXRPlK78pvoQgz+72S3WN7xgtzj9Zh2b xZFXx5gtPv/ZxujA4jHvwkI2jym/N7J67Jx1l91jyZKfTAEsUVw2Kak5mWWpRfp2CVwZv0/8 ZS04NZW54uOO78wNjC3dzF2MnBwSAiYSi7ZfZoKwxSQu3FvP1sXIxSEkcIRR4uPzN+wQzjJG id+nethBqtgEjCRebISwRQQMJU4deMEEUsQs0MYo0fBmEhtIQhgosap7MVSRkcSxGXPBJokI TGOUmL5xF9g+FgEViZcnT4DdwSvgK3Hk3BKodX+ZJe6df8QIkuAUsJXYdH4RmM0IdOD3U2vA mpkFxCVuPZkPdbiAxJI956EeEpV4+fgfK4StJDHn9TVmiPp8iQ3tDUwQywQlTs58wjKBUXQW klGzkJTNQlI2i5EDKK4psX6XPkSJosSU7ofsELaGROucuezI4gsY2VcxcpQWp5blphsZbGIE xuExCTbdHYx7XloeYhTgYFTi4f0wtT5EiDWxrLgy9xCjNAeLkjjvrNp5wUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYF6Zv599e5RF0XtGrj2vVr+VmV6WcP77O3HN4x4kl001Fo09bHvKt Kr3Nt0CGQ4+paZr6i8mxhUlXeOc57ZxcsdnHO2cNw6wTPhE5Sz81ia9QymJ5ub0466uZoZq+ 7+HH/luXfHV4+O18ksYNU5PaHpuytT+O+QlYWpRfPX9yNv/sS8uPmaZvU2Ipzkg01GIuKk4E AF6KtKikAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/v0za1DPGR4IywG4Ro8hVyRw5n3Y X-Mailman-Approved-At: Thu, 04 Dec 2014 05:27:24 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 06:41:55 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AAA24eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KaW5kZWVkLCBMU1AgUGluZyBpcyBwYXJ0IG9mIE1QTFMgT0FNIHRvb2wgc2V0 IGFzIEJGRCBpdHNlbGYgdGhhdCBpbnRlbmRlZCB0byBtb25pdG9yIG9wZXJhdGlvbmFsIHN0YXRl IG9mIHRoZSBuZXR3b3JrLCBwYXRoIGNvbnRpbnVpdHkgYmV0d2VlbiB0d28gbm9kZXMuIEFuZCBM U1AgUGluZywgYXMgcHJpbWFyaWx5IG9uLWRlbWFuZCB0cm91Ymxlc2hvb3RpbmcgdG9vbCwgaGVs cHMgbG9jYWxpemUgYW5kLCB0byBjZXJ0YWluIGRlZ3JlZSwgZGlhZ25vc2UgdGhlIHByb2JsZW0u IEJ1dCB0aGUgdWx0aW1hdGUgZGVidWdnaW5nIGlzIHByb3ByaWV0YXJ5LiBUaGlzIHByb3Bvc2Fs LCBpbiBteSB2aWV3LCBoZWxwcyBub3QgbW9uaXRvciBiZWhhdmlvciBvZiB0aGUgbmV0d29yayBi dXQgQkZEIGl0c2VsZiwgcXVhbGl0eSBvZiBCRkQgaW1wbGVtZW50YXRpb24uIEnigJltIG5vdCBz YXlpbmcgdGhhdCBpdCBpcyBub3QgdXNlZnVsIGZvciBpbXBsZW1lbnRlcnMgYW5kIG9wZXJhdG9y cywgb25lIGNhbiBmaW5kIHRoYXQgdG9vIG1hbnkgQkZEIHNlc3Npb25zIG9yIGF0IHRvbyBzaG9y dCBpbnRlcnZhbHMgYmVpbmcgIHJhbi4gSSBkb27igJl0IGFncmVlIHRvIGxvYWRpbmcgdGhpcyBh cyBleHRlbnNpb24gb2YgdGhlIHdpZGVseSB1c2VkIHN0YW5kYXJkLiBQZXJoYXBzIHdlIGNhbiBs b29rIGludG8gdXNpbmcgQkZEIEVjaG8gYXMgc2VsZi1kZWJ1Z2dpbmcgaW5zdHJ1bWVudC4NCg0K ICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEdyZWcNCg0KRnJvbTogTWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAwMywgMjAxNCAxMDoyMyBQTQ0K VG86IEdyZWdvcnkgTWlyc2t5DQpDYzogRmFuLCBQZW5nOyBNQUxMSUsgTVVESUdPTkRBIChtbXVk aWdvbik7IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBCRkQgc3RhYmlsaXR5IGZvbGxv dy11cCBmcm9tIElFVEYtOTENCg0KR3JlZywNCg0KSSBiZWxpZXZlIHdlIGhhdmUgYSBkaXNhZ3Jl ZW1lbnQgaGVyZS4gSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGlzc3VlIG9mIGRlYnVnIGFiaWxpdHkg YXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIGEgc3RhbmRhcmRpemVkIHByb3RvY29sLg0KDQpMb29r IGF0IE1QTFMgcGluZyBhbmQgdHJhY2Vyb3V0ZSAoUkZDIDQzNzkpIC4gVGhleSBhcmUgdWx0aW1h dGVseSBkZWJ1ZyB0b29scyB1c2VkIHRvIGVzdGFibGlzaCB2aWFiaWxpdHkgb2YgYSBwYXRoIGFu ZCB0aGV5IGFyZSB2ZXJ5IG11Y2ggcGFydCBvZiB0aGUgc3RhbmRhcmRpemVkIHByb3RvY29sLg0K DQpPbiBEZWMgMywgMjAxNCwgYXQgMzoyNSBQTSwgR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3Jv dGU6DQoNCkhpIE1haGVzaCwNCkkgY29uc2lkZXIgaXNzdWVzIG9mIGRlYnVnYWJpbGl0eSwgbm90 IG9mIGp1c3QgQkZEIGJ1dCBhbnkgb3RoZXIgc3RhbmRhcmRpemVkIHByb3RvY29sLCB0byBiZSBv dXRzaWRlIG9mIFN0YW5kYXJkIHRyYWNrLCBhdCBtb3N0IHRvIGJlIHN1aXRhYmxlIGZvciBJbmZv cm1hdGlvbmFsIG9yIEV4cGVyaW1lbnRhbCB0cmFjay4gSWYgd2UgYWdyZWUgb24gdGhhdCwgdGhl biB3ZSBjYW4gZGlzY3VzcyBzY2VuYXJpb3MgdGhhdCBwcmVzZW50IHByb2JsZW0gYW5kIGludmVz dGlnYXRlIHdoZXRoZXIgYW55dGhpbmcgaW4gdGhlIHByb3RvY29sIHJlcXVpcmVzIGNsYXJpZmlj YXRpb24gdG8gaGVscCB2ZW5kb3JzIGluIGJ1aWxkaW5nIHdlbGwtcGVyZm9ybWluZywgc2NhbGFi bGUgYW5kIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zIGFuZCBwcm92aWRlIG9wZXJhdGlv bmFsIGd1aWRlbGluZXMgZm9yIG9wZXJhdG9ycy4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMs DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFoZXNoIEpl dGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KU2VudDogVHVlc2Rh eSwgRGVjZW1iZXIgMDIsIDIwMTQgODo0NiBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5DQpDYzogRmFu LCBQZW5nOyBNQUxMSUsgTVVESUdPTkRBIChtbXVkaWdvbik7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFp bHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ct dXAgZnJvbSBJRVRGLTkxDQoNCkdyZWcsDQoNCldoYXQgaXMgUGVuZyByZWZlcnJpbmcgdG8gaXMg YSB3YXkgdG8gZmlndXJlIG91dCB3aHkgYSBwYXJ0aWN1bGFyIEJGRCBzZXNzaW9uIGZsYXBwZWQs IHBhcnRpY3VsYXJseSBpZiB0aGUgcGFja2V0KHMpIGZvciB0aGF0IHNlc3Npb24gYXJyaXZlIGxh dGUuIEkgZG8gbm90IHNlZSBob3cgdGhhdCBjYW4gYmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQu IEl0IGlzIGJhc2ljIEJGRCBkZWJ1ZyBhYmlsaXR5LiBSdW5uaW5nIGEgc2VwYXJhdGUgRE0gZG9l cyB0ZWxsIHlvdSB3aHkgYSBwYXJ0aWN1bGFyIEJGRCBzZXNzaW9uIGZsYXBwZWQuDQoNCk5vdyB3 ZSBjYW4gZGViYXRlIHdoYXQgbWV0aG9kcyBjYW4gYmUgZW1wbG95ZWQgdG8gbWVhc3VyZSB0aGF0 IGRlbGF5IGFuZCBJIGFtIG9wZW4gdG8gd2F5cyB0byBkb2luZyBpdCwgaW5jbHVkaW5nIGxvY2Fs IGxvb3BiYWNrIHRvIG1lYXN1cmUgdHJhbnNtaXQgZGVsYXlzIG9yIHRpbWUgc3RhbXBpbmcgb2Yg cGFja2V0cyBpbiBoYXJkd2FyZS4gQnV0IGluIGNhc2VzLCB3aGVyZSB0aGVyZSBpcyBubyBzdXBw b3J0IGZvciBlaXRoZXIgb2YgdGhlIGNhcGFiaWxpdGllcywgb25lIG9mIHRoZSBzdWdnZXN0ZWQg c29sdXRpb25zIGlzIHRvIHVzZSB0aGUgdGltZSBzdGFtcHMgY2FycmllZCBpbiB0aGUgQkZEIHBh eWxvYWQuDQoNCkNoZWVycy4NCg0KT24gRGVjIDEsIDIwMTQsIGF0IDk6MzggQU0sIEdyZWdvcnkg TWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5 QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSBQZW5nLA0KYW5kIHN0aWxsLCB5b3XigJlyZSBs b29raW5nIGZvciBhIHRvb2wgdG8gbWVhc3VyZSBCRkQgcGVyZm9ybWFuY2UuIFRoZW4geW914oCZ bGwgYmUgbG9va2luZyBmb3IgYSB0b29sIHRvIHZlcmlmeSB0aGUgQkZEIHBlcmZvcm1hbmNlIG1l YXN1cmVtZW50LCBhbmQgb24sIGFuZCBvbi4gT3BlcmF0b3JzIGRvIG5lZWQgY29tcGxldGUgc2V0 IG9mIEZDQVBTIHRvb2xzLCBpbmNsdWRpbmcgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQuIE5vdGUg dGhhdCBwYXNzaXZlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IHRocm91Z2ggbWFya2luZyBtZXRo b2QgdGhhdCBNYWNoIENoZW4gcmVmZXJyZWQgdG8gY2FuIG1vbml0b3IgQkZEIGZsb3cocykgYW5k IGJlIHVzZWQgdG8gZG8gTG9zcyBhbmQvb3IgRGVsYXkgTWVhc3VyZW1lbnQuIEFuZCBhY3RpdmUg U3ludGhldGljIExvc3MgTWVhc3VyZW1lbnQgbWF5IHNpbXVsYXRlIGZsb3cgb2Ygc21hbGwgcGFj a2V0cyBhcyB3ZWxsIGFzIHJlbGF0aXZlbHkgbGFyZ2UgcGFja2V0cy4gQW5kIHRoZSBzYW1lIGdv ZXMgZm9yIGFjdGl2ZSBtZWFzdXJlbWVudCBtZXRob2Qgb2YgRGVsYXkgTWVhc3VyZW1lbnQuIEkg bGlrZSBTd2lzcyBBcm15IGtuaXZlcyBidXQgbGV0IHVzIG5vdCB0dXJuIEJGRCBpbnRvIG9uZS4N Cg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEdyZWcNCg0KRnJvbTogRmFuLCBQZW5nIFttYWlsdG86ZmFucGVuZ0BjaGluYW1vYmlsZS5j b21dDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDAxLCAyMDE0IDQ6NDQgQU0NClRvOiBHcmVnb3J5 IE1pcnNreTsgJ01BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKSc7IHJ0Zy1iZmRAaWV0Zi5vcmc8 bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogQkZEIHN0YWJpbGl0eSBmb2xs b3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIEdyZWdvcnksDQoNCkkgd2FzIGp1c3QgZ2l2aW5nIGFu IGV4YW1wbGUgOikgQXBwbGljYXRpb24gdHJhZmZpYyB1c3VhbGx5IGNhbm5vdCBzdGFuZCBzbWFs bCBwYWNrZXQgbG9zcywgbm90IHRvIHNheSAzMCUgbG9zcy4NCg0KSSBhbSBhY3R1YWxseSBhc2tp bmcgZm9yIGEgZGVidWcgZnVuY3Rpb24gdGhhdCBjb3VsZCBnaXZlIHVzIHNvbWUgdXNlZnVsIGhp bnRzIG9mIHBvb3IgY29ubmVjdGlvbiB3aXRoIHNtYWxsIHByb3RvY29sIGNoYW5nZSwgYmVzaWRl cyB0aGUgYmFzaWMgY29ubmVjdGl2aXR5IGluZm9ybWF0aW9uLiBJZiBpdCBtZWFzdXJlcyBzb21l dGhpbmcsIGl0IG1lYXN1cmVzIHBhY2tldHMgb2YgQkZEIGl0c2VsZi4gU28gSSBkb27igJl0IGV4 cGVjdCBpdCB0byBiZSBjb25zaWRlcmVkIGFzIGEgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgdG9v bC4NCg0KQmVzdCByZWdhcmRzLA0KUGVuZw0KDQpGcm9tOiBHcmVnb3J5IE1pcnNreSBbbWFpbHRv OmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAy OSwgMjAxNCAzOjM3IEFNDQpUbzogRmFuLCBQZW5nOyAnTUFMTElLIE1VRElHT05EQSAobW11ZGln b24pJzsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6 IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGkgUGVuZywNCnRo aXMgaXMgdmVyeSBpbnRlcmVzdGluZyBzY2VuYXJpby4gSSB0aGluayB0aGF0IGlmIEJGRCBleHBl cmllbmNlcyB+MzAlIHBhY2tldCBsb3NzLCB0aGVuIGhpZ2hseSBsaWtlbHkgc28gYXJlIGFmZmVj dGVkIG90aGVyIGFwcGxpY2F0aW9ucy4gVGhlbiBpdCBpcyBub3QganVzdCBCRkQgaXNzdWUgYnV0 IGNvbmRpdGlvbiB0aGF0IHNob3VsZCBiZSBkZXRlY3RlZCAgYnkgcGVyZm9ybWFuY2UgbWVhc3Vy ZW1lbnQgbWV0aG9kLCB3aGV0aGVyIGFjdGl2ZSBvciBwYXNzaXZlIHBhY2tldCBsb3NzIG1lYXN1 cmVtZW50Lg0KSeKAmW0gY29udmluY2VkIHRoYXQgb3ZlcmxvYWRpbmcgQkZEIHdpdGggcGVyZm9y bWFuY2UgbWVhc3VyZW1lbnQgcHJvdmlzaW9ucyBpcyBjb3VudGVyLXByb2R1Y3RpdmUgYW5kIGlz IGluYXBwcm9wcmlhdGUuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGYW4sIFBlbmcNClNlbnQ6IEZyaWRheSwg Tm92ZW1iZXIgMjgsIDIwMTQgNDozNCBBTQ0KVG86ICdNQUxMSUsgTVVESUdPTkRBIChtbXVkaWdv biknOyBydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPg0KU3ViamVjdDog UkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KDQpIaSBNYWxsaWssDQoN CkV4YWN0bHkuIFBhY2tldHMgbWF5IGJlIGV4cGVyaWVuY2luZyBzbGlnaHQgbG9zcywgYnV0IHRo ZSBsaW5rIGNhbiBoYXJkbHkgYmUgcmVnYXJkZWQgYXMgY29ubmVjdGVkLiBNb3JlIGltcG9ydGFu dGx5LCB0aGUgZXhwZXJpZW5jZSBvZiB1cHBlci1sZXZlbCBhcHBsaWNhdGlvbnMgY2FuIGJlIGRl Z3JhZGVkIHNldmVyZWx5IChlLmcuIFRDUCB0cmFmZmljIGlzIG5vdCBhYmxlIHRvIGdvIGZhc3Qg aW4gZmFjZSBvZiBldmVuIHNtYWxsIGNvbnRpbnVvdXMgbG9zcykuIEJ1dCB3aGF0IGlmIG9uZSBC RkQgZnJhbWUgaXMgbG9zdCBldmVyeSB0aHJlZSBmcmFtZXM/IFRoZW4gdGhlIGxvc3MgcmF0ZSBp cyAzMCUgb24gYXZlcmFnZSwgd2hpY2ggaXMgYWxyZWFkeSBhIHZlcnkgc2V2ZXJlIHZhbHVlLg0K DQpCZXN0IHJlZ2FyZHMsDQpQZW5nDQoNCkZyb206IE1BTExJSyBNVURJR09OREEgKG1tdWRpZ29u KSBbbWFpbHRvOm1tdWRpZ29uQGNpc2NvLmNvbV0NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMjgs IDIwMTQgNzo1MyBQTQ0KVG86IEZhbiwgUGVuZzsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRn LWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9t IElFVEYtOTENCg0KSGkgUGVuZywNCg0KSWYgdGhlIEJGRCBwYWNrZXRzIGFyZSBsb3N0LCBkb2Vz buKAmXQgdGhlIEJGRCBzZXNzaW9uIGdvIERPV04/IEFyZSB5b3Ugc2F5aW5nIHRoYXQgcGFja2V0 IGxvc3MgaXMgbm90IGJpZyBlbm91Z2ggdG8gbWFrZSBCRkQgc2Vzc2lvbiBnbyBET1dOPw0KDQpU aGFua3MNCg0KUmVnYXJkcw0KTWFsbGlrDQoNCkZyb206IDxGYW4+LCBQZW5nIDxmYW5wZW5nQGNo aW5hbW9iaWxlLmNvbTxtYWlsdG86ZmFucGVuZ0BjaGluYW1vYmlsZS5jb20+Pg0KRGF0ZTogRnJp ZGF5LCAyOCBOb3ZlbWJlciAyMDE0IDQ6MjAgcG0NClRvOiAicnRnLWJmZEBpZXRmLm9yZzxtYWls dG86cnRnLWJmZEBpZXRmLm9yZz4iIDxydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGll dGYub3JnPj4NClN1YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYt OTENCg0KSGkgSmVmZiwgYWxsLA0KDQpJIGhhdmUgYmVlbiBmb2xsb3dpbmcgdGhpcyBzdGFiaWxp dHkgZXh0ZW5zaW9uIGZyb20gdGhlIGJlZ2lubmluZywgYW5kIGFzIGFuDQpvcGVyYXRvciBJIHdv dWxkIGxpa2UgdG8gZXhwcmVzcyB0aGF0IHRoaXMgZHJhZnQgZW5hYmxlcyB0aGUgImFkdmFuY2Vk DQpmZWF0dXJlIiB3ZSBkZXNpcmUgZm9yIEJGRCB0byBwcm92aWRlIGFkZGl0aW9uYWwgdXNlZnVs IGluZm9ybWF0aW9uIHRoYXQNCmhlbHBzIG9wZXJhdG9ycyB1bmRlcnN0YW5kIG5ldHdvcmsgaXNz dWVzLiBBIHJlbGV2YW50IHVzZSBjYXNlIGlzIGRldGVjdGluZw0KbG9zc3kgb3IgInF1YXNpLWRp c2Nvbm5lY3RlZCIgbGlua3Mgb3IgbWVtYmVyIExBRyBsaW5rcy4gQW4gZXhhbXBsZSBvZiBzdWNo DQpzaXR1YXRpb24gd2UgZXhwZXJpZW5jZWQgd2FzIGEgbG9vc2VseSBjb25uZWN0ZWQgZmliZXIg bGluayByZXN1bHRpbmcgaW4NCmNvbnRpbnVvdXMsIHNtYWxsIGFtb3VudCBvZiBwYWNrZXQgbG9z cy4gQkZEIGNvdWxkIGdldCB0aGUgaW5mb3JtYXRpb24gb2YNCmxvc3QgQkZEIGZyYW1lcyBvbiBz dWNoIHVuc3RhYmxlIGxpbmssIGFuZCBwcm9iYWJseSByZXBvcnQgd2hlbiBhIHRhcmdldA0KbGV2 ZWwgaXMgcmVhY2hlZCwgc2F5IGEgY2VydGFpbiBudW1iZXIgb2YgZnJhbWVzIGFyZSBsb3N0IG92 ZXIgYSBwZXJpb2Qgb3INCmFtb25nIGEgdG90YWwgbnVtYmVyIG9mIGZyYW1lcy4NCg0KQmVzdCBy ZWdhcmRzLA0KUGVuZw0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQpDby1jaGFpciwgTkVUQ09ORiBX Rw0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29t Pg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQpDby1jaGFpciwgTkVUQ09ORiBXRw0KbWpldGhhbmFu ZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0K --_000_7347100B5761DC41A166AC17F22DF1121B8AAA24eusaamb103erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGkgTWFoZXNoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5pbmRlZWQsIExTUCBQaW5n IGlzIHBhcnQgb2YgTVBMUyBPQU0gdG9vbCBzZXQgYXMgQkZEIGl0c2VsZiB0aGF0IGludGVuZGVk IHRvIG1vbml0b3Igb3BlcmF0aW9uYWwgc3RhdGUgb2YgdGhlIG5ldHdvcmssIHBhdGggY29udGlu dWl0eSBiZXR3ZWVuIHR3byBub2Rlcy4gQW5kDQogTFNQIFBpbmcsIGFzIHByaW1hcmlseSBvbi1k ZW1hbmQgdHJvdWJsZXNob290aW5nIHRvb2wsIGhlbHBzIGxvY2FsaXplIGFuZCwgdG8gY2VydGFp biBkZWdyZWUsIGRpYWdub3NlIHRoZSBwcm9ibGVtLiBCdXQgdGhlIHVsdGltYXRlIGRlYnVnZ2lu ZyBpcyBwcm9wcmlldGFyeS4gVGhpcyBwcm9wb3NhbCwgaW4gbXkgdmlldywgaGVscHMgbm90IG1v bml0b3IgYmVoYXZpb3Igb2YgdGhlIG5ldHdvcmsgYnV0IEJGRCBpdHNlbGYsIHF1YWxpdHkgb2Yg QkZEDQogaW1wbGVtZW50YXRpb24uIEnigJltIG5vdCBzYXlpbmcgdGhhdCBpdCBpcyBub3QgdXNl ZnVsIGZvciBpbXBsZW1lbnRlcnMgYW5kIG9wZXJhdG9ycywgb25lIGNhbiBmaW5kIHRoYXQgdG9v IG1hbnkgQkZEIHNlc3Npb25zIG9yIGF0IHRvbyBzaG9ydCBpbnRlcnZhbHMgYmVpbmcmbmJzcDsg cmFuLiBJIGRvbuKAmXQgYWdyZWUgdG8gbG9hZGluZyB0aGlzIGFzIGV4dGVuc2lvbiBvZiB0aGUg d2lkZWx5IHVzZWQgc3RhbmRhcmQuIFBlcmhhcHMgd2UgY2FuIGxvb2sgaW50bw0KIHVzaW5nIEJG RCBFY2hvIGFzIHNlbGYtZGVidWdnaW5nIGluc3RydW1lbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYWhlc2ggSmV0 aGFuYW5kYW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBEZWNlbWJlciAwMywgMjAxNCAxMDoyMyBQTTxicj4NCjxiPlRvOjwv Yj4gR3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8L2I+IEZhbiwgUGVuZzsgTUFMTElLIE1VRElH T05EQSAobW11ZGlnb24pOyBydGctYmZkQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHdlIGhhdmUgYSBkaXNhZ3JlZW1lbnQg aGVyZS4gSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGlzc3VlIG9mIGRlYnVnIGFiaWxpdHkgYXJlIG91 dHNpZGUgdGhlIHNjb3BlIG9mIGEgc3RhbmRhcmRpemVkIHByb3RvY29sLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb29rIGF0IE1QTFMgcGlu ZyBhbmQgdHJhY2Vyb3V0ZSAoUkZDIDQzNzkpIC4gVGhleSBhcmUgdWx0aW1hdGVseSBkZWJ1ZyB0 b29scyB1c2VkIHRvIGVzdGFibGlzaCB2aWFiaWxpdHkgb2YgYSBwYXRoIGFuZCB0aGV5IGFyZSB2 ZXJ5IG11Y2ggcGFydCBvZiB0aGUgc3RhbmRhcmRpemVkIHByb3RvY29sLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRGVjIDMsIDIwMTQs IGF0IDM6MjUgUE0sIEdyZWdvcnkgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5t aXJza3lAZXJpY3Nzb24uY29tIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBNYWhlc2gsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY29uc2lkZXIgaXNzdWVzIG9m IGRlYnVnYWJpbGl0eSwgbm90IG9mIGp1c3QgQkZEIGJ1dCBhbnkgb3RoZXIgc3RhbmRhcmRpemVk IHByb3RvY29sLCB0byBiZSBvdXRzaWRlIG9mIFN0YW5kYXJkIHRyYWNrLCBhdCBtb3N0IHRvIGJl IHN1aXRhYmxlIGZvciBJbmZvcm1hdGlvbmFsDQogb3IgRXhwZXJpbWVudGFsIHRyYWNrLiBJZiB3 ZSBhZ3JlZSBvbiB0aGF0LCB0aGVuIHdlIGNhbiBkaXNjdXNzIHNjZW5hcmlvcyB0aGF0IHByZXNl bnQgcHJvYmxlbSBhbmQgaW52ZXN0aWdhdGUgd2hldGhlciBhbnl0aGluZyBpbiB0aGUgcHJvdG9j b2wgcmVxdWlyZXMgY2xhcmlmaWNhdGlvbiB0byBoZWxwIHZlbmRvcnMgaW4gYnVpbGRpbmcgd2Vs bC1wZXJmb3JtaW5nLCBzY2FsYWJsZSBhbmQgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMg YW5kDQogcHJvdmlkZSBvcGVyYXRpb25hbCBndWlkZWxpbmVzIGZvciBvcGVyYXRvcnMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1haGVzaA0K IEpldGhhbmFuZGFuaSBbPGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5t YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgRGVjZW1iZXIgMDIs IDIwMTQgODo0NiBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+R3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZhbiwgUGVuZzsgTUFM TElLIE1VRElHT05EQSAobW11ZGlnb24pOw0KPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5v cmciPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBCRkQgc3RhYmlsaXR5IGZv bGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2hhdCBpcyBQZW5nIHJlZmVycmluZyB0byBpcyBhIHdheSB0byBmaWd1cmUgb3V0 IHdoeSBhIHBhcnRpY3VsYXIgQkZEIHNlc3Npb24gZmxhcHBlZCwgcGFydGljdWxhcmx5IGlmIHRo ZSBwYWNrZXQocykgZm9yIHRoYXQgc2Vzc2lvbiBhcnJpdmUgbGF0ZS4gSSBkbyBub3Qgc2VlIGhv dyB0aGF0IGNhbiBiZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudC4gSXQgaXMgYmFzaWMgQkZEIGRl YnVnIGFiaWxpdHkuIFJ1bm5pbmcNCiBhIHNlcGFyYXRlIERNIGRvZXMgdGVsbCB5b3Ugd2h5IGEg cGFydGljdWxhciBCRkQgc2Vzc2lvbiBmbGFwcGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Ob3cgd2UgY2FuIGRlYmF0ZSB3aGF0IG1ldGhvZHMgY2FuIGJlIGVtcGxveWVkIHRvIG1lYXN1 cmUgdGhhdCBkZWxheSBhbmQgSSBhbSBvcGVuIHRvIHdheXMgdG8gZG9pbmcgaXQsIGluY2x1ZGlu ZyBsb2NhbCBsb29wYmFjayB0byBtZWFzdXJlIHRyYW5zbWl0IGRlbGF5cyBvciB0aW1lIHN0YW1w aW5nIG9mIHBhY2tldHMgaW4gaGFyZHdhcmUuIEJ1dCBpbiBjYXNlcywgd2hlcmUgdGhlcmUgaXMg bm8gc3VwcG9ydA0KIGZvciBlaXRoZXIgb2YgdGhlIGNhcGFiaWxpdGllcywgb25lIG9mIHRoZSBz dWdnZXN0ZWQgc29sdXRpb25zIGlzIHRvIHVzZSB0aGUgdGltZSBzdGFtcHMgY2FycmllZCBpbiB0 aGUgQkZEIHBheWxvYWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIERlYyAxLCAyMDE0LCBhdCA5OjM4IEFNLCBH cmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29u LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFBlbmcsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFuZCBzdGlsbCwgeW91 4oCZcmUgbG9va2luZyBmb3IgYSB0b29sIHRvIG1lYXN1cmUgQkZEIHBlcmZvcm1hbmNlLiBUaGVu IHlvdeKAmWxsIGJlIGxvb2tpbmcgZm9yIGEgdG9vbCB0byB2ZXJpZnkgdGhlIEJGRCBwZXJmb3Jt YW5jZSBtZWFzdXJlbWVudCwgYW5kIG9uLCBhbmQgb24uDQogT3BlcmF0b3JzIGRvIG5lZWQgY29t cGxldGUgc2V0IG9mIEZDQVBTIHRvb2xzLCBpbmNsdWRpbmcgcGVyZm9ybWFuY2UgbWVhc3VyZW1l bnQuIE5vdGUgdGhhdCBwYXNzaXZlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IHRocm91Z2ggbWFy a2luZyBtZXRob2QgdGhhdCBNYWNoIENoZW4gcmVmZXJyZWQgdG8gY2FuIG1vbml0b3IgQkZEIGZs b3cocykgYW5kIGJlIHVzZWQgdG8gZG8gTG9zcyBhbmQvb3IgRGVsYXkgTWVhc3VyZW1lbnQuIEFu ZCBhY3RpdmUNCiBTeW50aGV0aWMgTG9zcyBNZWFzdXJlbWVudCBtYXkgc2ltdWxhdGUgZmxvdyBv ZiBzbWFsbCBwYWNrZXRzIGFzIHdlbGwgYXMgcmVsYXRpdmVseSBsYXJnZSBwYWNrZXRzLiBBbmQg dGhlIHNhbWUgZ29lcyBmb3IgYWN0aXZlIG1lYXN1cmVtZW50IG1ldGhvZCBvZiBEZWxheSBNZWFz dXJlbWVudC4gSSBsaWtlIFN3aXNzIEFybXkga25pdmVzIGJ1dCBsZXQgdXMgbm90IHR1cm4gQkZE IGludG8gb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GYW4sDQogUGVuZyBbPGEgaHJlZj0ibWFpbHRvOmZh bnBlbmdAY2hpbmFtb2JpbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86 ZmFucGVuZ0BjaGluYW1vYmlsZS5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgRGVjZW1iZXIgMDEs IDIwMTQgNDo0NCBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+R3JlZ29yeSBNaXJza3k7ICdNQUxMSUsgTVVESUdPTkRBICht bXVkaWdvbiknOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBCRkQgc3Rh YmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SGkgR3JlZ29yeSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd2FzIGp1c3QgZ2l2aW5nIGFuIGV4 YW1wbGUgOikgQXBwbGljYXRpb24gdHJhZmZpYyB1c3VhbGx5IGNhbm5vdCBzdGFuZCBzbWFsbCBw YWNrZXQgbG9zcywgbm90IHRvIHNheSAzMCUgbG9zcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gYWN0dWFs bHkgYXNraW5nIGZvciBhIGRlYnVnIGZ1bmN0aW9uIHRoYXQgY291bGQgZ2l2ZSB1cyBzb21lIHVz ZWZ1bCBoaW50cyBvZiBwb29yIGNvbm5lY3Rpb24gd2l0aCBzbWFsbCBwcm90b2NvbCBjaGFuZ2Us IGJlc2lkZXMgdGhlIGJhc2ljIGNvbm5lY3Rpdml0eQ0KIGluZm9ybWF0aW9uLiBJZiBpdCBtZWFz dXJlcyBzb21ldGhpbmcsIGl0IG1lYXN1cmVzIHBhY2tldHMgb2YgQkZEIGl0c2VsZi4gU28gSSBk b27igJl0IGV4cGVjdCBpdCB0byBiZSBjb25zaWRlcmVkIGFzIGEgcGVyZm9ybWFuY2UgbWVhc3Vy ZW1lbnQgdG9vbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVuZzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+R3JlZ29yeQ0KIE1pcnNreSBb PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvc3Bhbj48 L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+ DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+U2F0dXJkYXksIE5vdmVtYmVyIDI5LCAyMDE0IDM6MzcgQU08YnI+DQo8Yj5Ubzo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZhbiwgUGVu ZzsgJ01BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKSc7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGctYmZkQGlldGYub3JnPC9zcGFuPjwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+UkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBQZW5nLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50aGlzIGlzIHZlcnkg aW50ZXJlc3Rpbmcgc2NlbmFyaW8uIEkgdGhpbmsgdGhhdCBpZiBCRkQgZXhwZXJpZW5jZXMgfjMw JSBwYWNrZXQgbG9zcywgdGhlbiBoaWdobHkgbGlrZWx5IHNvIGFyZSBhZmZlY3RlZCBvdGhlciBh cHBsaWNhdGlvbnMuIFRoZW4gaXQgaXMgbm90IGp1c3QNCiBCRkQgaXNzdWUgYnV0IGNvbmRpdGlv biB0aGF0IHNob3VsZCBiZSBkZXRlY3RlZCZuYnNwOyBieSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVu dCBtZXRob2QsIHdoZXRoZXIgYWN0aXZlIG9yIHBhc3NpdmUgcGFja2V0IGxvc3MgbWVhc3VyZW1l bnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPknigJltIGNvbnZpbmNlZCB0aGF0IG92ZXJsb2FkaW5nIEJGRCB3aXRoIHBlcmZvcm1h bmNlIG1lYXN1cmVtZW50IHByb3Zpc2lvbnMgaXMgY291bnRlci1wcm9kdWN0aXZlIGFuZCBpcyBp bmFwcHJvcHJpYXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SdGctYmZkDQogWzxhIGhyZWY9Im1haWx0bzpy dGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0 bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5GYW4sIFBlbmc8YnI+DQo8 Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+RnJpZGF5LCBOb3ZlbWJlciAyOCwgMjAxNCA0OjM0IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4nTUFMTElLIE1VRElH T05EQSAobW11ZGlnb24pJzs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnJ0Zy1iZmRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTog QkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbGxpayw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV4YWN0bHkuIFBhY2tldHMg bWF5IGJlIGV4cGVyaWVuY2luZyBzbGlnaHQgbG9zcywgYnV0IHRoZSBsaW5rIGNhbiBoYXJkbHkg YmUgcmVnYXJkZWQgYXMgY29ubmVjdGVkLiBNb3JlIGltcG9ydGFudGx5LCB0aGUgZXhwZXJpZW5j ZSBvZiB1cHBlci1sZXZlbCBhcHBsaWNhdGlvbnMNCiBjYW4gYmUgZGVncmFkZWQgc2V2ZXJlbHkg KGUuZy4gVENQIHRyYWZmaWMgaXMgbm90IGFibGUgdG8gZ28gZmFzdCBpbiBmYWNlIG9mIGV2ZW4g c21hbGwgY29udGludW91cyBsb3NzKS4gQnV0IHdoYXQgaWYgb25lIEJGRCBmcmFtZSBpcyBsb3N0 IGV2ZXJ5IHRocmVlIGZyYW1lcz8gVGhlbiB0aGUgbG9zcyByYXRlIGlzIDMwJSBvbiBhdmVyYWdl LCB3aGljaCBpcyBhbHJlYWR5IGEgdmVyeSBzZXZlcmUgdmFsdWUuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0 IHJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlBlbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPk1BTExJSw0KIE1VRElHT05EQSAobW11ZGlnb24pIFs8YSBocmVmPSJtYWlsdG86 bW11ZGlnb25AY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86bW11 ZGlnb25AY2lzY28uY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GcmlkYXksIE5vdmVtYmVyIDI4LCAyMDE0IDc6 NTMgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPkZhbiwgUGVuZzs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Zy1iZmRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5SZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkhpIFBlbmcsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgdGhlIEJGRCBwYWNrZXRzIGFyZSBs b3N0LCBkb2VzbuKAmXQgdGhlIEJGRCBzZXNzaW9uIGdvIERPV04/IEFyZSB5b3Ugc2F5aW5nIHRo YXQgcGFja2V0IGxvc3MgaXMgbm90IGJpZyBlbm91Z2ggdG8gbWFrZSBCRkQgc2Vzc2lvbiBnbyBE T1dOPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYWxsaWs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZsdDtGYW4mZ3Q7LCBQZW5nICZsdDs8YSBocmVmPSJtYWlsdG86ZmFucGVuZ0Bj aGluYW1vYmlsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmZhbnBlbmdAY2hpbmFt b2JpbGUuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkZyaWRheSwgMjggTm92ZW1iZXIgMjAx NCA0OjIwIHBtPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5S RTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5IaSBKZWZmLCBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBoYXZlIGJlZW4gZm9sbG93aW5nIHRo aXMgc3RhYmlsaXR5IGV4dGVuc2lvbiBmcm9tIHRoZSBiZWdpbm5pbmcsIGFuZCBhcyBhbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm9w ZXJhdG9yIEkgd291bGQgbGlrZSB0byBleHByZXNzIHRoYXQgdGhpcyBkcmFmdCBlbmFibGVzIHRo ZSAmcXVvdDthZHZhbmNlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPmZlYXR1cmUmcXVvdDsgd2UgZGVzaXJlIGZvciBCRkQgdG8gcHJv dmlkZSBhZGRpdGlvbmFsIHVzZWZ1bCBpbmZvcm1hdGlvbiB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aGVscHMgb3BlcmF0b3Jz IHVuZGVyc3RhbmQgbmV0d29yayBpc3N1ZXMuIEEgcmVsZXZhbnQgdXNlIGNhc2UgaXMgZGV0ZWN0 aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+bG9zc3kgb3IgJnF1b3Q7cXVhc2ktZGlzY29ubmVjdGVkJnF1b3Q7IGxpbmtzIG9yIG1l bWJlciBMQUcgbGlua3MuIEFuIGV4YW1wbGUgb2Ygc3VjaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnNpdHVhdGlvbiB3ZSBleHBlcmll bmNlZCB3YXMgYSBsb29zZWx5IGNvbm5lY3RlZCBmaWJlciBsaW5rIHJlc3VsdGluZyBpbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmNv bnRpbnVvdXMsIHNtYWxsIGFtb3VudCBvZiBwYWNrZXQgbG9zcy4gQkZEIGNvdWxkIGdldCB0aGUg aW5mb3JtYXRpb24gb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5sb3N0IEJGRCBmcmFtZXMgb24gc3VjaCB1bnN0YWJsZSBsaW5rLCBh bmQgcHJvYmFibHkgcmVwb3J0IHdoZW4gYSB0YXJnZXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5sZXZlbCBpcyByZWFjaGVkLCBzYXkg YSBjZXJ0YWluIG51bWJlciBvZiBmcmFtZXMgYXJlIGxvc3Qgb3ZlciBhIHBlcmlvZCBvcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmFt b25nIGEgdG90YWwgbnVtYmVyIG9mIGZyYW1lcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CZXN0IHJlZ2FyZHMsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ UGVuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFoZXNoIEpldGhhbmFuZGFuaTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q28tY2hhaXIsIE5FVENPTkYgV0c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpt amV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWpldGhh bmFuZGFuaUBnbWFpbC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ TWFoZXNoIEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q28tY2hhaXIs IE5FVENPTkYgV0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpt amV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF1121B8AAA24eusaamb103erics_-- From nobody Thu Dec 4 05:27:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C509C1A023E for ; Thu, 4 Dec 2014 03:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 wcAtRmtZ1M0X for ; Thu, 4 Dec 2014 03:45:25 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8AD1A0211 for ; Thu, 4 Dec 2014 03:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42651; q=dns/txt; s=iport; t=1417693525; x=1418903125; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=85icSZZViRjOamVrNY8dXkubiZ/ZgNRJqmgWxETwYgM=; b=I+fCbYk/bJ+7k06LyVPXxvd3M7nPSQfwsp66m+S4s94TMSGthJgftl7i ksBkp1/izWAmhC9f+tDTT8DSqqwT+/U6zMPQm6z4cYzo4ylgKYfFqMgFO /MnypV9Dvf9F9wePHp9tAiih6JQ4YoqwoCfbybUj8rhT9tLmWCg+O1hog I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFANRIgFStJV2Q/2dsb2JhbABagkNDUlgExCk8gWqGFgKBGhYBAQEBAX2EAgEBAQMBGk0EAwsFBwYBCBEDAQEBASABBiYCERQJCAIEAQ0FCRKIDgMJCQ3QQw2FXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReOMIIUEQwFBwaEPAWOBhSBdgWEEYRCgXKBIjiCdYNAhWuCNINpg3lvgUWBAAEBAQ X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208,217";a="102606035" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 04 Dec 2014 11:45:23 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB4BjNWf017503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 11:45:23 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 05:45:23 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "Vengada Prasad Govindan (venggovi)" , Gregory Mirsky , Santosh P K , "Marc Binderberger" , Manav Bhatia Subject: Re: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6sKG4KnHULdkO3SoZYWD6QxJxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYCAAFQ6AIAAZKSA Date: Thu, 4 Dec 2014 11:45:22 +0000 Message-ID: In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D347719A2@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.94] Content-Type: multipart/alternative; boundary="_000_D0A646BE28833mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5j3XoffLyOqpLS-_Y3q3uRt2yag X-Mailman-Approved-At: Thu, 04 Dec 2014 05:27:25 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 11:45:31 -0000 --_000_D0A646BE28833mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, The other point is, if echo mode is used, how do you verify that the receiv= e path is ok. Echo packets are going to be sent back in the forwarding path= . If there is a problem in the receive path we will not be able to detect t= hat with echo. Thanks Regards Mallik From: "Vengada Prasad Govindan (venggovi)" > Date: Thursday, 4 December 2014 4:45 pm To: Gregory Mirsky >, Santosh P K = >, Marc Binderberger >, Manav Bhatia > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hello Greg/ Santosh, It was my understanding that BFD Async was chosen for stability since the= re are configurations where BFD echo mode is not supported (e.g. Multi-hop,= BFD on LAGs and BFD over MPLS). Am I missing something here, please let me= know. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, December 04, 2014 11:44 AM To: Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, yes, the format and thus interpretation of payload in Echo mode is not defi= ned and that, in my view, is what we need - some open space. And Echo well = could be exactly that - no legacy, no backward compatibility (addressee tha= t doesn't support "extended Echo" will simply loop the packet back to sende= r). Perhaps that will be direction we can discuss and, hopefully, agree on. Regards, Greg -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Wednesday, December 03, 2014 9:54 PM To: Gregory Mirsky; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Greg, I don't think we have discussed about echo in this context. Echo is good= thing but payload of BFD echo packet is decided by local system. Did you m= ean to add suggestion on how echo packet should look like? Or how echo can = help in BFD loss/delay issue? Thanks Santosh P K -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, December 04, 2014 2:22 AM To: Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Dear All, had authors of the proposal or we already dismissed use of BFD Echo? I've scanned the thread and couldn't find trace of us discussing BFD Echo mode. I think that it is more suitable for experimentation and unortho= dox use. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Wednesday, December 03, 2014 5:39 AM To: Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Manav and Marc, > > One way to solve this problem is by attaching a debug trailer that > > only carries the seq numbers at the *end* of the BFD packet. This > > would not be covered in the Length field carried in the BFD header > > but would be accounted for in the length carried in the IP header. > > BFD itself is not related to IP, i.e. there is not always an IP header. > Sure, the encapsulating "frame" may provide a length but actually, > why not covering the debug trailer with the BFD length? > > If this is solely for debug purpose than this may work. For simple > copying-out into e.g. a packet trace buffer it would be even simpler > to have the BFD length covering the trailer. > If hardware is supposed to process the trailer information (other > than copying out) then it's getting ugly - having fixed position, > fixed length extension headers would be preferable for simple access. Fixed length would be easy to process in hardware. Problem is when we have many have extensions in future. If we want to use only one extension that is at the last then I will be forced to pad all the other extension ahead of it? This might not be a problem if we have fewer extensions but might become problem when there are too many extension= s. > > Another idea is to use the 0x80 bit of the auth type to distinguish > between a "normal" authentication header and a "sequence + authentication". > I think this is good. In the BFD extension TLV we still have many reserved bits that can be used as well? Thanks Santosh P K > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > Hi Santosh, > > > > You could use the crypto sequence numbers carried in the > > meticulous cryptographic auth for detecting packet losses. > > However, this breaks when you use non-meticulous crypto > > authentication since the sequence number is only incremented > > occasionally there. This i believe is a deal breaker since i > > really envision non meticulous mode to be the one being widely > > deployed. In fact we were supposed to write a draft on that and i > > guess it just fell through the cracks (lemme ping my co-author on > > that !) > > > > One way to solve this problem is by attaching a debug trailer that > > only carries the seq numbers at the *end* of the BFD packet. This > > would not be covered in the Length field carried in the BFD header > > but would be accounted for in the length carried in the IP header. > > The concept of attaching a trailer is documented well and is used > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The > > catch however is that this debug trailer will NOT be covered by > > the BFD authentication. Is this acceptable to the WG? > > > > I think the problem of diagnosing a BFD flap becomes all the more > > important with BFD authentication turned on since then we have > > more points where a delay can be inserted. > > > > Cheers, Manav > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > > > wrote: > >> Manav, > >> This is good question. > >> > >>> Can the authors add some text on how this debugging mechanism > >>> would work if somebody employs BFD authentication? > >> > >> Right now we have considered without authentication (we are > >> setting A bit). We should add some text on how we can use both > >> Auth and de bug > TLV. > >> Is there any suggestion you have? I will get back to you on this. > >> > >> > >> Thanks > >> Santosh P K > >> > >>>> -----Original Message----- > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >>>> Mach > Chen > >>>> Sent: Thursday, November 27, 2014 2:13 PM > >>>> To: Marc Binderberger > >>>> Cc: rtg-bfd@ietf.org > >>>> Subject: RE: BFD stability follow-up from IETF-91 > >>>> > >>>> Hi Marc, > >>>> > >>>>> -----Original Message----- > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > >>>>> To: Mach Chen > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > >>>>> > >>>>> Hello Mach, > >>>>> > >>>>>> This triggers me think out there should be another solution > >>>>>> for getting the Tx and Rx timestamps without encoding the > >>>>>> timestamps > in > >>>>>> the BFD > >>>>> packets. > >>>>>> For example, the Tx and Rx systems could just save timestamps > >>>>>> locally or send them to a centralized entity and then use the > >>>>>> sequence numbers to correlate them for further analyzing. > >>>>> > >>>>> I remember some discussion on NVO3 about how many bits it > >>>>> takes > >>>>> ;- > ) - > >>>>> could you send the links/draft names you are working on to this lis= t? > >>>>> May be useful for further discussions. > >>>> > >>>> Sure, here is the > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > >>> based-ipfpm-framework-02) for the reference. > >>>> > >>>> But here I want to say is that since we have sequence number, > >>>> we may > not > >>> need the marking based solution. Suppose that someone want to > monitor > >>> the delay of a BFD packet , just record and save the timestamp > >>> at the Tx side, which indexed by the sequence number. Similarly, > >>> do the same at the Rx side. Then based on the timestamps from > >>> both Tx and Rx, and using the sequence number to correlate the > >>> timestamps, it can also provide a way > to > >>> monitor the delay of the BFD packet. > >>>> > >>>> That means, only if there is sequence number, even if without > >>>> carrying the > >>> timestamp in the BFD packet, BFD packet delay can be measured. > >>>> > >>>> Best regards, > >>>> Mach > >>>> > >>>>> > >>>>> > >>>>> Thanks & Regards, > >>>>> Marc > >>>>> > >>>>> > >>>>> > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > >>>>>> Hi Marc and Manav, > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Marc > >>>>>>> Binderberger > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > >>>>>>> To: Manav Bhatia > >>>>>>> Cc: rtg-bfd@ietf.org > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > >>>>>>> > >>>>>>> Hello Manav, > >>>>>>> > >>>>>>>> I believe the work is important and addresses something > >>>>>>>> thats really required (spent too much time debugging why > >>>>>>>> BFD > flapped!). > >>>>>>> > >>>>>>> agree :-) we should keep the discussion alive. > >>>>>>> > >>>>>>> > >>>>>>>> side Time stamping would have helped in debugging whether the > >>> BFD > >>>>>>>> packet was sent late, or whether the packet was sent on > >>>>>>>> time and also arrived on time but was delayed when passing > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad > >>>>>>>> too > >>>>>>>> long) > >>>>>>> > >>>>>>> well, I can see a point in having the Tx timestamps in the > >>>>>>> packet mainly for the purpose of knowing "this" packet was > >>>>>>> okay/not okay on the Tx side and to correlate it with your > >>>>>>> local Rx measurement. > >>>>>> > >>>>>> Yes, this is one solution if people think BFD delay is needed. > >>>>>> If allow to have Tx timestamps to be carried in the packets, > >>>>>> seems it should be no problem to leave a seat for the Rx > >>>>>> timestamps as well :-). After all, with both Tx and Rx > >>>>>> timestamp, it may simplify the > >>>>> implementation. > >>>>>> > >>>>>>> > >>>>>>> And even this point is less relevant with sequence numbers > >>>>>>> as this number allows the identification of packets and thus > >>>>>>> the correlation of information from the Tx and Rx system. > >>>>>> > >>>>>> Indeed, the sequence number helps a lot for the correlation > between > >>>>>> the Tx and Rx system. > >>>>>> > >>>>>> This triggers me think out there should be another solution > >>>>>> for getting the Tx and Rx timestamps without encoding the > >>>>>> timestamps > in > >>>>>> the BFD > >>>>> packets. > >>>>>> For example, the Tx and Rx systems could just save timestamps > >>>>>> locally or send them to a centralized entity and then use the > >>>>>> sequence numbers to correlate them for further analyzing. > >>>>>> > >>>>>> Best regards, > >>>>>> Mach > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Regards, Marc > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > >>>>>>>> Hi Jeff, > >>>>>>>> > >>>>>>>> I vividly remember the original intent of the stability > >>>>>>>> draft was to help debug BFD failures -- to isolate the > >>>>>>>> issue at the RX or the TX side Time stamping would have > >>>>>>>> helped in debugging > whether > >>>>>>>> the BFD packet was sent late, or whether the packet was > >>>>>>>> sent on time and also arrived on time but was delayed when > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer > >>>>>>>> for tad too long), etc. But then time stamping came with > >>>>>>>> its own set of issues, and was hence dropped from the original d= raft. > >>>>>>>> > >>>>>>>> Can the authors send a summary on the list on why time > >>>>>>>> stamping was dropped so that we're all clear on that one. > >>>>>>>> > >>>>>>>> The current proposal does help but is not complete. > >>>>>>>> > >>>>>>>> Assume that the RX end loses a BFD session and learns later > >>>>>>>> that it did eventually receive the missing BFD packets > >>>>>>>> (based on the > seq > >>> #). > >>>>>>>> How would it know which end was misbehaving? Was it a delay > >>>>>>>> at the TX side, or was it the RX that delayed passing the > >>>>>>>> packets to the BFD process(or). This is usually what we > >>>>>>>> want to debug and i want to understand how this draft with > >>>>>>>> sequence numbers can unequivocally tell me that. > >>>>>>>> > >>>>>>>> I believe the work is important and addresses something > >>>>>>>> thats really required (spent too much time debugging why > >>>>>>>> BFD > flapped!). > >>>>>>>> Clearly what would help is putting a small section that > >>>>>>>> describes how we can use the sequence numbers to debug what > >>>>>>>> and > where > >>> things went wrong. > >>>>>>>> > >>>>>>>> Cheers, Manav > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > >>>>>>>> > > >>> wrote: > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > >>>>>>>>> > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > >>>>>>>>> pp > >>>>>>>>> tx > >>>>>>>>> > >>>>>>>>> To attempt to simplify the presentation, the contentious > >>>>>>>>> portion of the timers were removed from the proposal, > >>>>>>>>> leaving only the sequence numbering for detecting loss of > >>>>>>>>> BFD async packets. > >>>>>>>>> > >>>>>>>>> When the room was polled to see whether the draft should > >>>>>>>>> be adopted as a WG item, the sense of the room was very quiet. > >>>>>>>>> As promised, this is to inquire for support for this draft > >>>>>>>>> on the WG mailing list to make sure the whole group has a voice. > >>>>>>>>> > >>>>>>>>> It should be noted that post-meeting discussion on the > >>>>>>>>> fate of this draft noted that BFD authentication code > >>>>>>>>> points are plentiful and are available with expert review. > >>>>>>>>> Should the draft authors wish to continue this work as > >>>>>>>>> Experimental, that is > an > >>> option. > >>>>>>>>> > >>>>>>>>> -- Jeff > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> > > --_000_D0A646BE28833mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Greg,

The other point is, if echo mode is used, how do you verify that the r= eceive path is ok. Echo packets are going to be sent back in the forwarding= path. If there is a problem in the receive path we will not be able to det= ect that with echo. 

Thanks

Regards
Mallik

From: "Vengada Prasad Govindan= (venggovi)" <venggovi@cisco.= com>
Date: Thursday, 4 December 2014 4:4= 5 pm
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, San= tosh P K <santoshpk@juniper.net= >, Marc Binderberger <marc@sniff= .de>, Manav Bhatia <manavbhatia@gmai= l.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-u= p from IETF-91

Hello Greg/ Santosh,
  It was my understanding that BFD Async was chosen for stab= ility since there are configurations where BFD echo mode is not supported (= e.g. Multi-hop, BFD on LAGs and BFD over MPLS). Am I missing something here= , please let me know.
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, December 04, 2014 11:44 AM
To: Santosh P K; Marc Binderberger; Manav Bhatia
Subject: RE: BFD stability follow-up from IETF-91

Hi Santosh,
yes, the format and thus interpretation of payload in Echo mode is not= defined and that, in my view, is what we need - some open space. And Echo = well could be exactly that - no legacy, no backward compatibility (addresse= e that doesn't support "extended Echo" will simply loop the packet back to sender). Perhaps that will = be direction we can discuss and, hopefully, agree on.

Regard= s,
Greg

-----Original Message-----
From: Santosh P K [mailto:san= toshpk@juniper.net]
Sent: Wednesday, December 03, 2014 9:54 PM
To: Gregory Mirsky; Marc Binderberger; Manav Bhatia
Subject: RE: BFD stability follow-up from IETF-91

Greg,
   I don't think we have discussed about echo in this contex= t. Echo is good thing but payload of BFD echo packet is decided by local sy= stem. Did you mean to add suggestion on how echo packet should look like? O= r how echo can help in BFD loss/delay issue?

Thanks
Santosh P K
-----Original Message-----
Sent: Thursday, December 04, 2014 2:22 AM
To: Santosh P K; Marc Binderberger; Manav Bhatia
Subject: RE: BFD stability follow-up from IETF-91
Dear All,
had authors of the proposal or we already dismissed use of BFD Echo? <= /div>
I've scanned the thread and couldn't find trace of us discussing BFD <= /div>
Echo mode. I think that it is more suitable for experimentation and un= orthodox use.
Regard= s,
Greg
-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Santosh P
K
Sent: Wednesday, December 03, 2014 5:39 AM
To: Marc Binderberger; Manav Bhatia
Subject: RE: BFD stability follow-up from IETF-91
Hello Manav and Marc,
> > One way to solve this problem is by attaching a debug traile= r that
> > only carries the seq numbers at the *end* of the BFD packet.= This
> > would not be covered in the Length field carried in the BFD = header
> > but would be accounted for in the length carried in the IP h= eader.
>
> BFD itself is not related to IP, i.e. there is not always an IP h= eader.
> Sure, the encapsulating "frame" may provide a length bu= t actually,
> why not covering the debug trailer with the BFD length?
>
> If this is solely for debug purpose than this may work. For simpl= e
> copying-out into e.g. a packet trace buffer it would be even simp= ler
> to have the BFD length covering the trailer.
> If hardware is supposed to process the trailer information (other=
> than copying out) then it's getting ugly - having fixed position,=
> fixed length extension headers would be preferable for simple acc= ess.
Fixed length would be easy to process in hardware. Problem is when we =
have many have extensions in future. If we want to use only one
extension that is at the last then I will be forced to pad all the
other extension ahead of it? This might not be a problem if we have
fewer extensions but might become problem when there are too many exte= nsions.
>
> Another idea is to use the 0x80 bit of the auth type to distingui= sh
> between a "normal" authentication header and a "se= quence +
authentication".
>
I think this is good. In the BFD extension TLV we still have many
reserved bits that can be used as well?
Thanks
Santosh P K
>
> On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote:
> > Hi Santosh,
> >
> > You could use the crypto sequence numbers carried in the
> > meticulous cryptographic auth for detecting packet losses.
> > However, this breaks when you use non-meticulous crypto
> > authentication since the sequence number is only incremented=
> > occasionally there. This i believe is a deal breaker since i=
> > really envision non meticulous mode to be the one being wide= ly
> > deployed. In fact we were supposed to write a draft on that = and i
> > guess it just fell through the cracks (lemme ping my co-auth= or on
> > that !)
> >
> > One way to solve this problem is by attaching a debug traile= r that
> > only carries the seq numbers at the *end* of the BFD packet.= This
> > would not be covered in the Length field carried in the BFD = header
> > but would be accounted for in the length carried in the IP h= eader.
> > The concept of attaching a trailer is documented well and is= used
> > in the IGPs. RFC 6506 describes one such trailer for OSPFv3.= The
> > catch however is that this debug trailer will NOT be covered= by
> > the BFD authentication. Is this acceptable to the WG?
> >
> > I think the problem of diagnosing a BFD flap becomes all the= more
> > important with BFD authentication turned on since then we ha= ve
> > more points where a delay can be inserted.
> >
> > Cheers, Manav
> >
> >
> > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K
> wrote:
> >> Manav,
> >>     This is good question.
> >>
> >>> Can the authors add some text on how this debugging = mechanism
> >>> would work if somebody employs BFD authentication?
> >>
> >> Right now we have considered without authentication (we = are
> >> setting A bit). We should add some text on how we can us= e both
> >> Auth and de bug
> TLV.
> >> Is there any suggestion you have? I will get back to you= on this.
> >>
> >>
> >> Thanks
> >> Santosh P K
> >>
> >>>> -----Original Message-----
> >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
> >>>> Mach
> Chen
> >>>> Sent: Thursday, November 27, 2014 2:13 PM
> >>>> To: Marc Binderberger
> >>>> Subject: RE: BFD stability follow-up from IETF-9= 1
> >>>>
> >>>> Hi Marc,
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Marc Binderberger [mailto:marc@sniff.de]
> >>>>> Sent: Thursday, November 27, 2014 1:43 AM
> >>>>> To: Mach Chen
> >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org
> >>>>> Subject: RE: BFD stability follow-up from IE= TF-91
> >>>>>
> >>>>> Hello Mach,
> >>>>>
> >>>>>> This triggers me think out there should = be another solution
> >>>>>> for getting the Tx and Rx timestamps wit= hout encoding the
> >>>>>> timestamps
> in
> >>>>>> the BFD
> >>>>> packets.
> >>>>>> For example, the Tx and Rx systems could= just save timestamps
> >>>>>> locally or send them to a centralized en= tity and then use the
> >>>>>> sequence numbers to correlate them for f= urther analyzing.
> >>>>>
> >>>>> I remember some discussion on NVO3 about how= many bits it
> >>>>> takes
> >>>>> ;-
> ) -
> >>>>> could you send the links/draft names you are= working on to this list?
> >>>>> May be useful for further discussions.
> >>>>
> >>>> Sure, here is the
> >>> based-ipfpm-framework-02) for the reference.
> >>>>
> >>>> But here I want to say is that since we have seq= uence number,
> >>>> we may
> not
> >>> need the marking based solution. Suppose that someon= e want to
> monitor
> >>> the delay of a BFD packet , just record and save the= timestamp
> >>> at the Tx side, which indexed by the sequence number= . Similarly,
> >>> do the same at the Rx side. Then based on the timest= amps from
> >>> both Tx and Rx, and using the sequence number to cor= relate the
> >>> timestamps, it can also provide a way
> to
> >>> monitor the delay of the BFD packet.
> >>>>
> >>>> That means, only if there is sequence number, ev= en if without
> >>>> carrying the
> >>> timestamp in the BFD packet, BFD packet delay can be= measured.
> >>>>
> >>>> Best regards,
> >>>> Mach
> >>>>
> >>>>>
> >>>>>
> >>>>> Thanks & Regards,
> >>>>> Marc
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach= Chen wrote:
> >>>>>> Hi Marc and Manav,
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
> Marc
> >>>>>>> Binderberger
> >>>>>>> Sent: Wednesday, November 26, 2014 4= :50 PM
> >>>>>>> To: Manav Bhatia
> >>>>>>> Cc: rtg-bfd@ietf.org
> >>>>>>> Subject: Re: BFD stability follow-up= from IETF-91
> >>>>>>>
> >>>>>>> Hello Manav,
> >>>>>>>
> >>>>>>>> I believe the work is important = and addresses something
> >>>>>>>> thats really required (spent too= much time debugging why
> >>>>>>>> BFD
> flapped!).
> >>>>>>>
> >>>>>>> agree :-) we should keep the discuss= ion alive.
> >>>>>>>
> >>>>>>>
> >>>>>>>> side Time stamping would have he= lped in debugging whether
the
> >>> BFD
> >>>>>>>> packet was sent late, or whether= the packet was sent on
> >>>>>>>> time and also arrived on time bu= t was delayed when passing
> >>>>>>>> it up the BFD stack/processor (l= ay in the RX buffer for tad
> >>>>>>>> too
> >>>>>>>> long)
> >>>>>>>
> >>>>>>> well, I can see a point in having th= e Tx timestamps in the
> >>>>>>> packet mainly for the purpose of kno= wing "this" packet was
> >>>>>>> okay/not okay on the Tx side and to = correlate it with your
> >>>>>>> local Rx
measurement.
> >>>>>>
> >>>>>> Yes, this is one solution if people thin= k BFD delay is needed.
> >>>>>> If allow to have Tx timestamps to be car= ried in the packets,
> >>>>>> seems it should be no problem to leave a= seat for the Rx
> >>>>>> timestamps as well :-). After all, with = both Tx and Rx
> >>>>>> timestamp, it may simplify the
> >>>>> implementation.
> >>>>>>
> >>>>>>>
> >>>>>>> And even this point is less relevant= with sequence numbers
> >>>>>>> as this number allows the identifica= tion of packets and thus
> >>>>>>> the correlation of information from = the Tx and Rx system.
> >>>>>>
> >>>>>> Indeed, the sequence number helps a lot = for the correlation
> between
> >>>>>> the Tx and Rx system.
> >>>>>>
> >>>>>> This triggers me think out there should = be another solution
> >>>>>> for getting the Tx and Rx timestamps wit= hout encoding the
> >>>>>> timestamps
> in
> >>>>>> the BFD
> >>>>> packets.
> >>>>>> For example, the Tx and Rx systems could= just save timestamps
> >>>>>> locally or send them to a centralized en= tity and then use the
> >>>>>> sequence numbers to correlate them for f= urther analyzing.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Mach
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Regards, Marc
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, 26 Nov 2014 12:26:41 +05= 30, Manav Bhatia wrote:
> >>>>>>>> Hi Jeff,
> >>>>>>>>
> >>>>>>>> I vividly remember the original = intent of the stability
> >>>>>>>> draft was to help debug BFD fail= ures -- to isolate the
> >>>>>>>> issue at the RX or the TX side T= ime stamping would have
> >>>>>>>> helped in debugging
> whether
> >>>>>>>> the BFD packet was sent late, or= whether the packet was
> >>>>>>>> sent on time and also arrived on= time but was delayed when
> >>>>>>>> passing it up the BFD stack/proc= essor (lay in the RX buffer
> >>>>>>>> for tad too long), etc. But then= time stamping came with
> >>>>>>>> its own set of issues, and was h= ence dropped from the original draft.
> >>>>>>>>
> >>>>>>>> Can the authors send a summary o= n the list on why time
> >>>>>>>> stamping was dropped so that we'= re all clear on that one.
> >>>>>>>>
> >>>>>>>> The current proposal does help b= ut is not complete.
> >>>>>>>>
> >>>>>>>> Assume that the RX end loses a B= FD session and learns later
> >>>>>>>> that it did eventually receive t= he missing BFD packets
> >>>>>>>> (based on the
> seq
> >>> #).
> >>>>>>>> How would it know which end was = misbehaving? Was it a delay
> >>>>>>>> at the TX side, or was it the RX= that delayed passing the
> >>>>>>>> packets to the BFD process(or). = This is usually what we
> >>>>>>>> want to debug and i want to unde= rstand how this draft with
> >>>>>>>> sequence numbers can unequivocal= ly tell me that.
> >>>>>>>>
> >>>>>>>> I believe the work is important = and addresses something
> >>>>>>>> thats really required (spent too= much time debugging why
> >>>>>>>> BFD
> flapped!).
> >>>>>>>> Clearly what would help is putti= ng a small section that
> >>>>>>>> describes how we can use the seq= uence numbers to debug
what
> >>>>>>>> and
> where
> >>> things went wrong.
> >>>>>>>>
> >>>>>>>> Cheers, Manav
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM,= Jeffrey Haas
> >>>>>>>> <jhaas@pfrc.org>
> >>> wrote:
> >>>>>>>>> draft-ashesh-bfd-stability-0= 1 was presented again during
> >>>>>>>>> IETF-91 in Honolulu. &n= bsp;The slides can be viewed here:
> >>>>>>>>>
> >>>>>>>>> pp
> >>>>>>>>> tx
> >>>>>>>>>
> >>>>>>>>> To attempt to simplify the p= resentation, the contentious
> >>>>>>>>> portion of the timers were r= emoved from the proposal,
> >>>>>>>>> leaving only the sequence nu= mbering for detecting loss of
> >>>>>>>>> BFD
async packets.
> >>>>>>>>>
> >>>>>>>>> When the room was polled to = see whether the draft should
> >>>>>>>>> be adopted as a WG item, the= sense of the room was very quiet.
> >>>>>>>>> As promised, this is to inqu= ire for support for this draft
> >>>>>>>>> on the WG mailing list to ma= ke sure the whole group has a
voice.
> >>>>>>>>>
> >>>>>>>>> It should be noted that post= -meeting discussion on the
> >>>>>>>>> fate of this draft noted tha= t BFD authentication code
> >>>>>>>>> points are plentiful and are= available with expert review.
> >>>>>>>>> Should the draft authors wis= h to continue this work as
> >>>>>>>>> Experimental, that is
> an
> >>> option.
> >>>>>>>>>
> >>>>>>>>> -- Jeff
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> >


 --_000_D0A646BE28833mmudigonciscocom_-- From nobody Thu Dec 4 05:27:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBCA1A0211 for ; Thu, 4 Dec 2014 03:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 myxziIbQBdxt for ; Thu, 4 Dec 2014 03:49:06 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9251A0277 for ; Thu, 4 Dec 2014 03:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46200; q=dns/txt; s=iport; t=1417693745; x=1418903345; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=QJDMztcuCyVuJOFcnFg1Jk8S//KQvj2WOgijfRqtzeQ=; b=AgODQLikAR7eE3tki6V1bMzBJSGsup2V68ixmbEDYlrTSRgMeLE5rDw4 EcbKAPlgYaWgrGc3dz6JnkvmpJE4350xRd/jRkhgEmWvTuh+v7VN3fX3q mOEGsMzrL1KfsxWOUkBqteHHYXW5e6kWD81O3sLMTqKHSkh+08u3wHHCf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAP5IgFStJV2U/2dsb2JhbABagkNDUlgExCk8gWqGFgKBGhYBAQEBAX2EAgEBAQMBGgFMBAMLBQcGAQgRAwEBAQEgAQYmAhEUCQgCBAENBQkSiA4DCQkN0EMNhV4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXjjCCFBEMBQcGhDwFjgYUgXYFhBGEQoFygSI4gnWDQIVrgjSDaYN5b4FFgQABAQE X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208,217";a="102606479" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 04 Dec 2014 11:49:03 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sB4Bn3Eq006869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 11:49:03 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 05:49:03 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: Santosh P K , "Vengada Prasad Govindan (venggovi)" , Gregory Mirsky , "Marc Binderberger" , Manav Bhatia Subject: Re: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6sKG4KnHULdkO3SoZYWD6QxJxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYCAAFQ6AIAACIMAgABdKQA= Date: Thu, 4 Dec 2014 11:49:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.94] Content-Type: multipart/alternative; boundary="_000_D0A647C128843mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4eYrSVVrRmjjOpxJ1ZgS9GNV0As X-Mailman-Approved-At: Thu, 04 Dec 2014 05:27:25 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 11:49:12 -0000 --_000_D0A647C128843mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Santosh, With Echo, the receive side is not going to look into the packet. It is jus= t going to send it back and it is the responsibility of the sender to inter= pret its contents. Regards Mallik From: Santosh P K > Date: Thursday, 4 December 2014 5:15 pm To: "Vengada Prasad Govindan (venggovi)" >, Gregory Mirsky >, Marc Binderberger >, Manav Bhatia > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Prasad, That's right. We echo has limitations but for single hop we can still use= it. I was trying to understand even for single hop do we need to define an= y packet format for echo? Thanks Santosh P K -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] Sent: Thursday, December 04, 2014 4:45 PM To: Gregory Mirsky; Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Greg/ Santosh, It was my understanding that BFD Async was chosen for stability since th= ere are configurations where BFD echo mode is not supported (e.g. Multi-hop, BFD on LAGs and BFD over MPLS). Am I missing something here, please let me know. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, December 04, 2014 11:44 AM To: Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, yes, the format and thus interpretation of payload in Echo mode is not defined and that, in my view, is what we need - some open space. And Echo well could be exactly that - no legacy, no backward compatibility (addresse= e that doesn't support "extended Echo" will simply loop the packet back to sender). Perhaps that will be direction we can discuss and, hopefully, agre= e on. Regards, Greg -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Wednesday, December 03, 2014 9:54 PM To: Gregory Mirsky; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Greg, I don't think we have discussed about echo in this context. Echo is goo= d thing but payload of BFD echo packet is decided by local system. Did you mean to add suggestion on how echo packet should look like? Or how echo can help in BFD loss/delay issue? Thanks Santosh P K > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, December 04, 2014 2:22 AM > To: Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 > > Dear All, > had authors of the proposal or we already dismissed use of BFD Echo? > I've scanned the thread and couldn't find trace of us discussing BFD > Echo mode. I think that it is more suitable for experimentation and unorthodox use. > > Regards, > Greg > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P > K > Sent: Wednesday, December 03, 2014 5:39 AM > To: Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 > > Hello Manav and Marc, > > > > > One way to solve this problem is by attaching a debug trailer that > > > only carries the seq numbers at the *end* of the BFD packet. This > > > would not be covered in the Length field carried in the BFD header > > > but would be accounted for in the length carried in the IP header. > > > > BFD itself is not related to IP, i.e. there is not always an IP header. > > Sure, the encapsulating "frame" may provide a length but actually, > > why not covering the debug trailer with the BFD length? > > > > If this is solely for debug purpose than this may work. For simple > > copying-out into e.g. a packet trace buffer it would be even simpler > > to have the BFD length covering the trailer. > > If hardware is supposed to process the trailer information (other > > than copying out) then it's getting ugly - having fixed position, > > fixed length extension headers would be preferable for simple access. > > Fixed length would be easy to process in hardware. Problem is when we > have many have extensions in future. If we want to use only one > extension that is at the last then I will be forced to pad all the > other extension ahead of it? This might not be a problem if we have > fewer extensions but might become problem when there are too many extensions. > > > > > > Another idea is to use the 0x80 bit of the auth type to distinguish > > between a "normal" authentication header and a "sequence + > authentication". > > > > I think this is good. In the BFD extension TLV we still have many > reserved bits that can be used as well? > > Thanks > Santosh P K > > > > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > Hi Santosh, > > > > > > You could use the crypto sequence numbers carried in the > > > meticulous cryptographic auth for detecting packet losses. > > > However, this breaks when you use non-meticulous crypto > > > authentication since the sequence number is only incremented > > > occasionally there. This i believe is a deal breaker since i > > > really envision non meticulous mode to be the one being widely > > > deployed. In fact we were supposed to write a draft on that and i > > > guess it just fell through the cracks (lemme ping my co-author on > > > that !) > > > > > > One way to solve this problem is by attaching a debug trailer that > > > only carries the seq numbers at the *end* of the BFD packet. This > > > would not be covered in the Length field carried in the BFD header > > > but would be accounted for in the length carried in the IP header. > > > The concept of attaching a trailer is documented well and is used > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The > > > catch however is that this debug trailer will NOT be covered by > > > the BFD authentication. Is this acceptable to the WG? > > > > > > I think the problem of diagnosing a BFD flap becomes all the more > > > important with BFD authentication turned on since then we have > > > more points where a delay can be inserted. > > > > > > Cheers, Manav > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > > > > > wrote: > > >> Manav, > > >> This is good question. > > >> > > >>> Can the authors add some text on how this debugging mechanism > > >>> would work if somebody employs BFD authentication? > > >> > > >> Right now we have considered without authentication (we are > > >> setting A bit). We should add some text on how we can use both > > >> Auth and de bug > > TLV. > > >> Is there any suggestion you have? I will get back to you on this. > > >> > > >> > > >> Thanks > > >> Santosh P K > > >> > > >>>> -----Original Message----- > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > >>>> Mach > > Chen > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > >>>> To: Marc Binderberger > > >>>> Cc: rtg-bfd@ietf.org > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>> > > >>>> Hi Marc, > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > >>>>> To: Mach Chen > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>>> > > >>>>> Hello Mach, > > >>>>> > > >>>>>> This triggers me think out there should be another solution > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > >>>>>> locally or send them to a centralized entity and then use the > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>> > > >>>>> I remember some discussion on NVO3 about how many bits it > > >>>>> takes > > >>>>> ;- > > ) - > > >>>>> could you send the links/draft names you are working on to this list? > > >>>>> May be useful for further discussions. > > >>>> > > >>>> Sure, here is the > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > >>> based-ipfpm-framework-02) for the reference. > > >>>> > > >>>> But here I want to say is that since we have sequence number, > > >>>> we may > > not > > >>> need the marking based solution. Suppose that someone want to > > monitor > > >>> the delay of a BFD packet , just record and save the timestamp > > >>> at the Tx side, which indexed by the sequence number. Similarly, > > >>> do the same at the Rx side. Then based on the timestamps from > > >>> both Tx and Rx, and using the sequence number to correlate the > > >>> timestamps, it can also provide a way > > to > > >>> monitor the delay of the BFD packet. > > >>>> > > >>>> That means, only if there is sequence number, even if without > > >>>> carrying the > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > >>>> > > >>>> Best regards, > > >>>> Mach > > >>>> > > >>>>> > > >>>>> > > >>>>> Thanks & Regards, > > >>>>> Marc > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > >>>>>> Hi Marc and Manav, > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > Marc > > >>>>>>> Binderberger > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > >>>>>>> To: Manav Bhatia > > >>>>>>> Cc: rtg-bfd@ietf.org > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > >>>>>>> > > >>>>>>> Hello Manav, > > >>>>>>> > > >>>>>>>> I believe the work is important and addresses something > > >>>>>>>> thats really required (spent too much time debugging why > > >>>>>>>> BFD > > flapped!). > > >>>>>>> > > >>>>>>> agree :-) we should keep the discussion alive. > > >>>>>>> > > >>>>>>> > > >>>>>>>> side Time stamping would have helped in debugging whether > the > > >>> BFD > > >>>>>>>> packet was sent late, or whether the packet was sent on > > >>>>>>>> time and also arrived on time but was delayed when passing > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad > > >>>>>>>> too > > >>>>>>>> long) > > >>>>>>> > > >>>>>>> well, I can see a point in having the Tx timestamps in the > > >>>>>>> packet mainly for the purpose of knowing "this" packet was > > >>>>>>> okay/not okay on the Tx side and to correlate it with your > > >>>>>>> local Rx > measurement. > > >>>>>> > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > >>>>>> If allow to have Tx timestamps to be carried in the packets, > > >>>>>> seems it should be no problem to leave a seat for the Rx > > >>>>>> timestamps as well :-). After all, with both Tx and Rx > > >>>>>> timestamp, it may simplify the > > >>>>> implementation. > > >>>>>> > > >>>>>>> > > >>>>>>> And even this point is less relevant with sequence numbers > > >>>>>>> as this number allows the identification of packets and thus > > >>>>>>> the correlation of information from the Tx and Rx system. > > >>>>>> > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > between > > >>>>>> the Tx and Rx system. > > >>>>>> > > >>>>>> This triggers me think out there should be another solution > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > >>>>>> locally or send them to a centralized entity and then use the > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Mach > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Regards, Marc > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > >>>>>>>> Hi Jeff, > > >>>>>>>> > > >>>>>>>> I vividly remember the original intent of the stability > > >>>>>>>> draft was to help debug BFD failures -- to isolate the > > >>>>>>>> issue at the RX or the TX side Time stamping would have > > >>>>>>>> helped in debugging > > whether > > >>>>>>>> the BFD packet was sent late, or whether the packet was > > >>>>>>>> sent on time and also arrived on time but was delayed when > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer > > >>>>>>>> for tad too long), etc. But then time stamping came with > > >>>>>>>> its own set of issues, and was hence dropped from the original draft. > > >>>>>>>> > > >>>>>>>> Can the authors send a summary on the list on why time > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > >>>>>>>> > > >>>>>>>> The current proposal does help but is not complete. > > >>>>>>>> > > >>>>>>>> Assume that the RX end loses a BFD session and learns later > > >>>>>>>> that it did eventually receive the missing BFD packets > > >>>>>>>> (based on the > > seq > > >>> #). > > >>>>>>>> How would it know which end was misbehaving? Was it a delay > > >>>>>>>> at the TX side, or was it the RX that delayed passing the > > >>>>>>>> packets to the BFD process(or). This is usually what we > > >>>>>>>> want to debug and i want to understand how this draft with > > >>>>>>>> sequence numbers can unequivocally tell me that. > > >>>>>>>> > > >>>>>>>> I believe the work is important and addresses something > > >>>>>>>> thats really required (spent too much time debugging why > > >>>>>>>> BFD > > flapped!). > > >>>>>>>> Clearly what would help is putting a small section that > > >>>>>>>> describes how we can use the sequence numbers to debug > what > > >>>>>>>> and > > where > > >>> things went wrong. > > >>>>>>>> > > >>>>>>>> Cheers, Manav > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > > >>>>>>>> > > > >>> wrote: > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > >>>>>>>>> > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > >>>>>>>>> pp > > >>>>>>>>> tx > > >>>>>>>>> > > >>>>>>>>> To attempt to simplify the presentation, the contentious > > >>>>>>>>> portion of the timers were removed from the proposal, > > >>>>>>>>> leaving only the sequence numbering for detecting loss of > > >>>>>>>>> BFD > async packets. > > >>>>>>>>> > > >>>>>>>>> When the room was polled to see whether the draft should > > >>>>>>>>> be adopted as a WG item, the sense of the room was very quiet. > > >>>>>>>>> As promised, this is to inquire for support for this draft > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > voice. > > >>>>>>>>> > > >>>>>>>>> It should be noted that post-meeting discussion on the > > >>>>>>>>> fate of this draft noted that BFD authentication code > > >>>>>>>>> points are plentiful and are available with expert review. > > >>>>>>>>> Should the draft authors wish to continue this work as > > >>>>>>>>> Experimental, that is > > an > > >>> option. > > >>>>>>>>> > > >>>>>>>>> -- Jeff > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > --_000_D0A647C128843mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6788DE3D866EB547A00C748C3B58D3CC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Santosh,

With Echo, the receive side is not going to look into the packet. It i= s just going to send it back and it is the responsibility of the sender to = interpret its contents. 

Regards
Mallik

From: Santosh P K <santoshpk@juniper.net>
Date: Thursday, 4 December 2014 5:1= 5 pm
To: "Vengada Prasad Govindan (= venggovi)" <venggovi@cisco.co= m>, Gregory Mirsky <gregory.mirsky@ericsson.com>, Marc Binderberger <marc@sniff.de>, Manav Bhatia <manavbhatia@gmai= l.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-u= p from IETF-91

Hi Prasad,
  That's right. We echo has limitations but for single hop w= e can still use it. I was trying to understand even for single hop do we ne= ed to define any packet format for echo?

Thanks
Santosh P K

-----Original Message-----
From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]
Sent: Thursday, December 04, 2014 4:45 PM
To: Gregory Mirsky; Santosh P K; Marc Binderberger; Manav Bhatia
Subject: RE: BFD stability follow-up from IETF-91
Hello Greg/ Santosh,
   It was my understanding that BFD Async was chosen for sta= bility since there
are configurations where BFD echo mode is not supported (e.g. Multi-ho= p,
BFD on LAGs and BFD over MPLS). Am I missing something here, please le= t
me know.
Thanks
Prasad
-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Gregory
Mirsky
Sent: Thursday, December 04, 2014 11:44 AM
To: Santosh P K; Marc Binderberger; Manav Bhatia
Subject: RE: BFD stability follow-up from IETF-91
Hi Santosh,
yes, the format and thus interpretation of payload in Echo mode is not=
defined and that, in my view, is what we need - some open space. And E= cho
well could be exactly that - no legacy, no backward compatibility (add= ressee
that doesn't support "extended Echo" will simply loop the pa= cket back to
sender). Perhaps that will be direction we can discuss and, hopefully,= agree
on.
Regard= s,
Greg
-----Original Message-----
From: Santosh P K [mailto:san= toshpk@juniper.net]
Sent: Wednesday, December 03, 2014 9:54 PM
To: Gregory Mirsky; Marc Binderberger; Manav Bhatia
Subject: RE: BFD stability follow-up from IETF-91
Greg,
    I don't think we have discussed about echo in = this context. Echo is good
thing but payload of BFD echo packet is decided by local system. Did y= ou
mean to add suggestion on how echo packet should look like? Or how ech= o
can help in BFD loss/delay issue?
Thanks
Santosh P K
> -----Original Message-----
> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> Sent: Thursday, December 04, 2014 2:22 AM
> To: Santosh P K; Marc Binderberger; Manav Bhatia
> Cc: rtg-bfd@ietf.org
> Subject: RE: BFD stability follow-up from IETF-91
>
> Dear All,
> had authors of the proposal or we already dismissed use of BFD Ec= ho?
> I've scanned the thread and couldn't find trace of us discussing = BFD
> Echo mode. I think that it is more suitable for experimentation a= nd
unorthodox use.
>
> R= egards,
> <= span class=3D"Apple-tab-span" style=3D"white-space:pre">Greg
>
> -----Original Message-----
> From: Rtg-bfd [mailto= :rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P
> K
> Sent: Wednesday, December 03, 2014 5:39 AM
> To: Marc Binderberger; Manav Bhatia
> Cc: rtg-bfd@ietf.org
> Subject: RE: BFD stability follow-up from IETF-91
>
> Hello Manav and Marc,
>
>
> > > One way to solve this problem is by attaching a debug t= railer that
> > > only carries the seq numbers at the *end* of the BFD pa= cket. This
> > > would not be covered in the Length field carried in the= BFD header
> > > but would be accounted for in the length carried in the= IP header.
> >
> > BFD itself is not related to IP, i.e. there is not always an= IP header.
> > Sure, the encapsulating "frame" may provide a leng= th but actually,
> > why not covering the debug trailer with the BFD length?
> >
> > If this is solely for debug purpose than this may work. For = simple
> > copying-out into e.g. a packet trace buffer it would be even= simpler
> > to have the BFD length covering the trailer.
> > If hardware is supposed to process the trailer information (= other
> > than copying out) then it's getting ugly - having fixed posi= tion,
> > fixed length extension headers would be preferable for simpl= e access.
>
> Fixed length would be easy to process in hardware. Problem is whe= n we
> have many have extensions in future. If we want to use only one
> extension that is at the last then I will be forced to pad all th= e
> other extension ahead of it? This might not be a problem if we ha= ve
> fewer extensions but might become problem when there are too many=
extensions.
>
>
> >
> > Another idea is to use the 0x80 bit of the auth type to dist= inguish
> > between a "normal" authentication header and a &qu= ot;sequence +
> authentication".
> >
>
> I think this is good. In the BFD extension TLV we still have many=
> reserved bits that can be used as well?
>
> Thanks
> Santosh P K
>
>
>
> >
> > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote:<= /div>
> > > Hi Santosh,
> > >
> > > You could use the crypto sequence numbers carried in th= e
> > > meticulous cryptographic auth for detecting packet loss= es.
> > > However, this breaks when you use non-meticulous crypto=
> > > authentication since the sequence number is only increm= ented
> > > occasionally there. This i believe is a deal breaker si= nce i
> > > really envision non meticulous mode to be the one being= widely
> > > deployed. In fact we were supposed to write a draft on = that and i
> > > guess it just fell through the cracks (lemme ping my co= -author on
> > > that !)
> > >
> > > One way to solve this problem is by attaching a debug t= railer that
> > > only carries the seq numbers at the *end* of the BFD pa= cket. This
> > > would not be covered in the Length field carried in the= BFD header
> > > but would be accounted for in the length carried in the= IP header.
> > > The concept of attaching a trailer is documented well a= nd is used
> > > in the IGPs. RFC 6506 describes one such trailer for OS= PFv3. The
> > > catch however is that this debug trailer will NOT be co= vered by
> > > the BFD authentication. Is this acceptable to the WG?
> > >
> > > I think the problem of diagnosing a BFD flap becomes al= l the more
> > > important with BFD authentication turned on since then = we have
> > > more points where a delay can be inserted.
> > >
> > > Cheers, Manav
> > >
> > >
> > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K
> > wrote:
> > >> Manav,
> > >>     This is good question.
> > >>
> > >>> Can the authors add some text on how this debug= ging mechanism
> > >>> would work if somebody employs BFD authenticati= on?
> > >>
> > >> Right now we have considered without authentication= (we are
> > >> setting A bit). We should add some text on how we c= an use both
> > >> Auth and de bug
> > TLV.
> > >> Is there any suggestion you have? I will get back t= o you on this.
> > >>
> > >>
> > >> Thanks
> > >> Santosh P K
> > >>
> > >>>> -----Original Message-----
> > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
> > >>>> Mach
> > Chen
> > >>>> Sent: Thursday, November 27, 2014 2:13 PM
> > >>>> To: Marc Binderberger
> > >>>> Cc: rtg= -bfd@ietf.org
> > >>>> Subject: RE: BFD stability follow-up from I= ETF-91
> > >>>>
> > >>>> Hi Marc,
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Marc Binderberger [mailto:marc@sniff.de]
> > >>>>> Sent: Thursday, November 27, 2014 1:43 = AM
> > >>>>> To: Mach Chen
> > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org
> > >>>>> Subject: RE: BFD stability follow-up fr= om IETF-91
> > >>>>>
> > >>>>> Hello Mach,
> > >>>>>
> > >>>>>> This triggers me think out there sh= ould be another solution
> > >>>>>> for getting the Tx and Rx timestamp= s without encoding the
> > >>>>>> timestamps
> > in
> > >>>>>> the BFD
> > >>>>> packets.
> > >>>>>> For example, the Tx and Rx systems = could just save timestamps
> > >>>>>> locally or send them to a centraliz= ed entity and then use the
> > >>>>>> sequence numbers to correlate them = for further analyzing.
> > >>>>>
> > >>>>> I remember some discussion on NVO3 abou= t how many bits it
> > >>>>> takes
> > >>>>> ;-
> > ) -
> > >>>>> could you send the links/draft names yo= u are working on to this
list?
> > >>>>> May be useful for further discussions.<= /div>
> > >>>>
> > >>>> Sure, here is the
> > >>> based-ipfpm-framework-02) for the reference.
> > >>>>
> > >>>> But here I want to say is that since we hav= e sequence number,
> > >>>> we may
> > not
> > >>> need the marking based solution. Suppose that s= omeone want to
> > monitor
> > >>> the delay of a BFD packet , just record and sav= e the timestamp
> > >>> at the Tx side, which indexed by the sequence n= umber. Similarly,
> > >>> do the same at the Rx side. Then based on the t= imestamps from
> > >>> both Tx and Rx, and using the sequence number t= o correlate the
> > >>> timestamps, it can also provide a way
> > to
> > >>> monitor the delay of the BFD packet.
> > >>>>
> > >>>> That means, only if there is sequence numbe= r, even if without
> > >>>> carrying the
> > >>> timestamp in the BFD packet, BFD packet delay c= an be measured.
> > >>>>
> > >>>> Best regards,
> > >>>> Mach
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>> Thanks & Regards,
> > >>>>> Marc
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000,= Mach Chen wrote:
> > >>>>>> Hi Marc and Manav,
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of
> > Marc
> > >>>>>>> Binderberger
> > >>>>>>> Sent: Wednesday, November 26, 2= 014 4:50 PM
> > >>>>>>> To: Manav Bhatia
> > >>>>>>> Cc: rtg-bfd@ietf.org
> > >>>>>>> Subject: Re: BFD stability foll= ow-up from IETF-91
> > >>>>>>>
> > >>>>>>> Hello Manav,
> > >>>>>>>
> > >>>>>>>> I believe the work is impor= tant and addresses something
> > >>>>>>>> thats really required (spen= t too much time debugging why
> > >>>>>>>> BFD
> > flapped!).
> > >>>>>>>
> > >>>>>>> agree :-) we should keep the di= scussion alive.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> side Time stamping would ha= ve helped in debugging whether
> the
> > >>> BFD
> > >>>>>>>> packet was sent late, or wh= ether the packet was sent on
> > >>>>>>>> time and also arrived on ti= me but was delayed when passing
> > >>>>>>>> it up the BFD stack/process= or (lay in the RX buffer for tad
> > >>>>>>>> too
> > >>>>>>>> long)
> > >>>>>>>
> > >>>>>>> well, I can see a point in havi= ng the Tx timestamps in the
> > >>>>>>> packet mainly for the purpose o= f knowing "this" packet was
> > >>>>>>> okay/not okay on the Tx side an= d to correlate it with your
> > >>>>>>> local Rx
> measurement.
> > >>>>>>
> > >>>>>> Yes, this is one solution if people= think BFD delay is needed.
> > >>>>>> If allow to have Tx timestamps to b= e carried in the packets,
> > >>>>>> seems it should be no problem to le= ave a seat for the Rx
> > >>>>>> timestamps as well :-). After all, = with both Tx and Rx
> > >>>>>> timestamp, it may simplify the
> > >>>>> implementation.
> > >>>>>>
> > >>>>>>>
> > >>>>>>> And even this point is less rel= evant with sequence numbers
> > >>>>>>> as this number allows the ident= ification of packets and thus
> > >>>>>>> the correlation of information = from the Tx and Rx system.
> > >>>>>>
> > >>>>>> Indeed, the sequence number helps a= lot for the correlation
> > between
> > >>>>>> the Tx and Rx system.
> > >>>>>>
> > >>>>>> This triggers me think out there sh= ould be another solution
> > >>>>>> for getting the Tx and Rx timestamp= s without encoding the
> > >>>>>> timestamps
> > in
> > >>>>>> the BFD
> > >>>>> packets.
> > >>>>>> For example, the Tx and Rx systems = could just save timestamps
> > >>>>>> locally or send them to a centraliz= ed entity and then use the
> > >>>>>> sequence numbers to correlate them = for further analyzing.
> > >>>>>>
> > >>>>>> Best regards,
> > >>>>>> Mach
> > >>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Regards, Marc
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Wed, 26 Nov 2014 12:26:41 &#= 43;0530, Manav Bhatia wrote:
> > >>>>>>>> Hi Jeff,
> > >>>>>>>>
> > >>>>>>>> I vividly remember the orig= inal intent of the stability
> > >>>>>>>> draft was to help debug BFD= failures -- to isolate the
> > >>>>>>>> issue at the RX or the TX s= ide Time stamping would have
> > >>>>>>>> helped in debugging
> > whether
> > >>>>>>>> the BFD packet was sent lat= e, or whether the packet was
> > >>>>>>>> sent on time and also arriv= ed on time but was delayed when
> > >>>>>>>> passing it up the BFD stack= /processor (lay in the RX buffer
> > >>>>>>>> for tad too long), etc. But= then time stamping came with
> > >>>>>>>> its own set of issues, and = was hence dropped from the original
draft.
> > >>>>>>>>
> > >>>>>>>> Can the authors send a summ= ary on the list on why time
> > >>>>>>>> stamping was dropped so tha= t we're all clear on that one.
> > >>>>>>>>
> > >>>>>>>> The current proposal does h= elp but is not complete.
> > >>>>>>>>
> > >>>>>>>> Assume that the RX end lose= s a BFD session and learns later
> > >>>>>>>> that it did eventually rece= ive the missing BFD packets
> > >>>>>>>> (based on the
> > seq
> > >>> #).
> > >>>>>>>> How would it know which end= was misbehaving? Was it a
delay
> > >>>>>>>> at the TX side, or was it t= he RX that delayed passing the
> > >>>>>>>> packets to the BFD process(= or). This is usually what we
> > >>>>>>>> want to debug and i want to= understand how this draft with
> > >>>>>>>> sequence numbers can unequi= vocally tell me that.
> > >>>>>>>>
> > >>>>>>>> I believe the work is impor= tant and addresses something
> > >>>>>>>> thats really required (spen= t too much time debugging why
> > >>>>>>>> BFD
> > flapped!).
> > >>>>>>>> Clearly what would help is = putting a small section that
> > >>>>>>>> describes how we can use th= e sequence numbers to debug
> what
> > >>>>>>>> and
> > where
> > >>> things went wrong.
> > >>>>>>>>
> > >>>>>>>> Cheers, Manav
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Nov 26, 2014 at 5:4= 9 AM, Jeffrey Haas
> > >>>>>>>> <jhaas@pfrc.org>
> > >>> wrote:
> > >>>>>>>>> draft-ashesh-bfd-stabil= ity-01 was presented again during
> > >>>>>>>>> IETF-91 in Honolulu.&nb= sp; The slides can be viewed here:
> > >>>>>>>>>
> > >>>>>>>>> pp
> > >>>>>>>>> tx
> > >>>>>>>>>
> > >>>>>>>>> To attempt to simplify = the presentation, the contentious
> > >>>>>>>>> portion of the timers w= ere removed from the proposal,
> > >>>>>>>>> leaving only the sequen= ce numbering for detecting loss of
> > >>>>>>>>> BFD
> async packets.
> > >>>>>>>>>
> > >>>>>>>>> When the room was polle= d to see whether the draft should
> > >>>>>>>>> be adopted as a WG item= , the sense of the room was very
quiet.
> > >>>>>>>>> As promised, this is to= inquire for support for this draft
> > >>>>>>>>> on the WG mailing list = to make sure the whole group has a
> voice.
> > >>>>>>>>>
> > >>>>>>>>> It should be noted that= post-meeting discussion on the
> > >>>>>>>>> fate of this draft note= d that BFD authentication code
> > >>>>>>>>> points are plentiful an= d are available with expert review.
> > >>>>>>>>> Should the draft author= s wish to continue this work as
> > >>>>>>>>> Experimental, that is
> > an
> > >>> option.
> > >>>>>>>>>
> > >>>>>>>>> -- Jeff
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > >


 --_000_D0A647C128843mmudigonciscocom_-- From nobody Thu Dec 4 05:27:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269F41A026E for ; Thu, 4 Dec 2014 03:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 RKFjYHFd1r_O for ; Thu, 4 Dec 2014 03:52:43 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:740]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C481A0266 for ; Thu, 4 Dec 2014 03:52:42 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB824.namprd05.prod.outlook.com (10.141.244.146) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 11:52:18 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 4 Dec 2014 11:52:18 +0000 From: Santosh P K To: "MALLIK MUDIGONDA (mmudigon)" , "Vengada Prasad Govindan (venggovi)" , Gregory Mirsky , Marc Binderberger , "Manav Bhatia" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuCAAAvZAIAF49GAgANl6hCAAHr8gIAAli8QgAAGoICAAFQ5AIAACCOwgAABWQCAAABdwA== Date: Thu, 4 Dec 2014 11:52:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(57704003)(51444003)(24454002)(189002)(377454003)(199003)(51704005)(62966003)(77156002)(77096005)(107046002)(74316001)(76576001)(19300405004)(101416001)(97736003)(19625215002)(99286002)(95666004)(106356001)(4396001)(106116001)(105586002)(19617315012)(16236675004)(64706001)(50986999)(19609705001)(46102003)(54206007)(86362001)(20776003)(40100003)(54606007)(92566001)(2656002)(92726001)(99396003)(66066001)(19580405001)(122556002)(31966008)(33656002)(68736005)(87936001)(54356999)(561944003)(120916001)(21056001)(76176999)(19580395003)(15202345003)(15975445006)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB824; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CO2PR0501MB8234A1BDDFD008EE12C847AB3780CO2PR0501MB823na_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/30zQoy2xRGFJqJoz2VQV_Qjl_eU X-Mailman-Approved-At: Thu, 04 Dec 2014 05:27:22 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 11:52:52 -0000 --_000_CO2PR0501MB8234A1BDDFD008EE12C847AB3780CO2PR0501MB823na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mallaik, That's correct and that is why I asked if we really need to define any pa= cket format as Greg suggested? Thanks Santosh P K From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Thursday, December 04, 2014 5:19 PM To: Santosh P K; Vengada Prasad Govindan (venggovi); Gregory Mirsky; Marc B= inderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Santosh, With Echo, the receive side is not going to look into the packet. It is jus= t going to send it back and it is the responsibility of the sender to inter= pret its contents. Regards Mallik From: Santosh P K > Date: Thursday, 4 December 2014 5:15 pm To: "Vengada Prasad Govindan (venggovi)" >, Gregory Mirsky >, Marc Binderberger >, Manav Bhatia > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Prasad, That's right. We echo has limitations but for single hop we can still use= it. I was trying to understand even for single hop do we need to define an= y packet format for echo? Thanks Santosh P K -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] Sent: Thursday, December 04, 2014 4:45 PM To: Gregory Mirsky; Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Greg/ Santosh, It was my understanding that BFD Async was chosen for stability since th= ere are configurations where BFD echo mode is not supported (e.g. Multi-hop, BFD on LAGs and BFD over MPLS). Am I missing something here, please let me know. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, December 04, 2014 11:44 AM To: Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, yes, the format and thus interpretation of payload in Echo mode is not defined and that, in my view, is what we need - some open space. And Echo well could be exactly that - no legacy, no backward compatibility (addresse= e that doesn't support "extended Echo" will simply loop the packet back to sender). Perhaps that will be direction we can discuss and, hopefully, agre= e on. Regards, Greg -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Wednesday, December 03, 2014 9:54 PM To: Gregory Mirsky; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Greg, I don't think we have discussed about echo in this context. Echo is goo= d thing but payload of BFD echo packet is decided by local system. Did you mean to add suggestion on how echo packet should look like? Or how echo can help in BFD loss/delay issue? Thanks Santosh P K > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, December 04, 2014 2:22 AM > To: Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 > > Dear All, > had authors of the proposal or we already dismissed use of BFD Echo? > I've scanned the thread and couldn't find trace of us discussing BFD > Echo mode. I think that it is more suitable for experimentation and unorthodox use. > > Regards, > Greg > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P > K > Sent: Wednesday, December 03, 2014 5:39 AM > To: Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 > > Hello Manav and Marc, > > > > > One way to solve this problem is by attaching a debug trailer that > > > only carries the seq numbers at the *end* of the BFD packet. This > > > would not be covered in the Length field carried in the BFD header > > > but would be accounted for in the length carried in the IP header. > > > > BFD itself is not related to IP, i.e. there is not always an IP header. > > Sure, the encapsulating "frame" may provide a length but actually, > > why not covering the debug trailer with the BFD length? > > > > If this is solely for debug purpose than this may work. For simple > > copying-out into e.g. a packet trace buffer it would be even simpler > > to have the BFD length covering the trailer. > > If hardware is supposed to process the trailer information (other > > than copying out) then it's getting ugly - having fixed position, > > fixed length extension headers would be preferable for simple access. > > Fixed length would be easy to process in hardware. Problem is when we > have many have extensions in future. If we want to use only one > extension that is at the last then I will be forced to pad all the > other extension ahead of it? This might not be a problem if we have > fewer extensions but might become problem when there are too many extensions. > > > > > > Another idea is to use the 0x80 bit of the auth type to distinguish > > between a "normal" authentication header and a "sequence + > authentication". > > > > I think this is good. In the BFD extension TLV we still have many > reserved bits that can be used as well? > > Thanks > Santosh P K > > > > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > Hi Santosh, > > > > > > You could use the crypto sequence numbers carried in the > > > meticulous cryptographic auth for detecting packet losses. > > > However, this breaks when you use non-meticulous crypto > > > authentication since the sequence number is only incremented > > > occasionally there. This i believe is a deal breaker since i > > > really envision non meticulous mode to be the one being widely > > > deployed. In fact we were supposed to write a draft on that and i > > > guess it just fell through the cracks (lemme ping my co-author on > > > that !) > > > > > > One way to solve this problem is by attaching a debug trailer that > > > only carries the seq numbers at the *end* of the BFD packet. This > > > would not be covered in the Length field carried in the BFD header > > > but would be accounted for in the length carried in the IP header. > > > The concept of attaching a trailer is documented well and is used > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The > > > catch however is that this debug trailer will NOT be covered by > > > the BFD authentication. Is this acceptable to the WG? > > > > > > I think the problem of diagnosing a BFD flap becomes all the more > > > important with BFD authentication turned on since then we have > > > more points where a delay can be inserted. > > > > > > Cheers, Manav > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > > > > > wrote: > > >> Manav, > > >> This is good question. > > >> > > >>> Can the authors add some text on how this debugging mechanism > > >>> would work if somebody employs BFD authentication? > > >> > > >> Right now we have considered without authentication (we are > > >> setting A bit). We should add some text on how we can use both > > >> Auth and de bug > > TLV. > > >> Is there any suggestion you have? I will get back to you on this. > > >> > > >> > > >> Thanks > > >> Santosh P K > > >> > > >>>> -----Original Message----- > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > >>>> Mach > > Chen > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > >>>> To: Marc Binderberger > > >>>> Cc: rtg-bfd@ietf.org > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>> > > >>>> Hi Marc, > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > >>>>> To: Mach Chen > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>>> > > >>>>> Hello Mach, > > >>>>> > > >>>>>> This triggers me think out there should be another solution > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > >>>>>> locally or send them to a centralized entity and then use the > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>> > > >>>>> I remember some discussion on NVO3 about how many bits it > > >>>>> takes > > >>>>> ;- > > ) - > > >>>>> could you send the links/draft names you are working on to this list? > > >>>>> May be useful for further discussions. > > >>>> > > >>>> Sure, here is the > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > >>> based-ipfpm-framework-02) for the reference. > > >>>> > > >>>> But here I want to say is that since we have sequence number, > > >>>> we may > > not > > >>> need the marking based solution. Suppose that someone want to > > monitor > > >>> the delay of a BFD packet , just record and save the timestamp > > >>> at the Tx side, which indexed by the sequence number. Similarly, > > >>> do the same at the Rx side. Then based on the timestamps from > > >>> both Tx and Rx, and using the sequence number to correlate the > > >>> timestamps, it can also provide a way > > to > > >>> monitor the delay of the BFD packet. > > >>>> > > >>>> That means, only if there is sequence number, even if without > > >>>> carrying the > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > >>>> > > >>>> Best regards, > > >>>> Mach > > >>>> > > >>>>> > > >>>>> > > >>>>> Thanks & Regards, > > >>>>> Marc > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > >>>>>> Hi Marc and Manav, > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > Marc > > >>>>>>> Binderberger > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > >>>>>>> To: Manav Bhatia > > >>>>>>> Cc: rtg-bfd@ietf.org > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > >>>>>>> > > >>>>>>> Hello Manav, > > >>>>>>> > > >>>>>>>> I believe the work is important and addresses something > > >>>>>>>> thats really required (spent too much time debugging why > > >>>>>>>> BFD > > flapped!). > > >>>>>>> > > >>>>>>> agree :-) we should keep the discussion alive. > > >>>>>>> > > >>>>>>> > > >>>>>>>> side Time stamping would have helped in debugging whether > the > > >>> BFD > > >>>>>>>> packet was sent late, or whether the packet was sent on > > >>>>>>>> time and also arrived on time but was delayed when passing > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad > > >>>>>>>> too > > >>>>>>>> long) > > >>>>>>> > > >>>>>>> well, I can see a point in having the Tx timestamps in the > > >>>>>>> packet mainly for the purpose of knowing "this" packet was > > >>>>>>> okay/not okay on the Tx side and to correlate it with your > > >>>>>>> local Rx > measurement. > > >>>>>> > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > >>>>>> If allow to have Tx timestamps to be carried in the packets, > > >>>>>> seems it should be no problem to leave a seat for the Rx > > >>>>>> timestamps as well :-). After all, with both Tx and Rx > > >>>>>> timestamp, it may simplify the > > >>>>> implementation. > > >>>>>> > > >>>>>>> > > >>>>>>> And even this point is less relevant with sequence numbers > > >>>>>>> as this number allows the identification of packets and thus > > >>>>>>> the correlation of information from the Tx and Rx system. > > >>>>>> > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > between > > >>>>>> the Tx and Rx system. > > >>>>>> > > >>>>>> This triggers me think out there should be another solution > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > >>>>>> locally or send them to a centralized entity and then use the > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Mach > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Regards, Marc > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > >>>>>>>> Hi Jeff, > > >>>>>>>> > > >>>>>>>> I vividly remember the original intent of the stability > > >>>>>>>> draft was to help debug BFD failures -- to isolate the > > >>>>>>>> issue at the RX or the TX side Time stamping would have > > >>>>>>>> helped in debugging > > whether > > >>>>>>>> the BFD packet was sent late, or whether the packet was > > >>>>>>>> sent on time and also arrived on time but was delayed when > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer > > >>>>>>>> for tad too long), etc. But then time stamping came with > > >>>>>>>> its own set of issues, and was hence dropped from the original draft. > > >>>>>>>> > > >>>>>>>> Can the authors send a summary on the list on why time > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > >>>>>>>> > > >>>>>>>> The current proposal does help but is not complete. > > >>>>>>>> > > >>>>>>>> Assume that the RX end loses a BFD session and learns later > > >>>>>>>> that it did eventually receive the missing BFD packets > > >>>>>>>> (based on the > > seq > > >>> #). > > >>>>>>>> How would it know which end was misbehaving? Was it a delay > > >>>>>>>> at the TX side, or was it the RX that delayed passing the > > >>>>>>>> packets to the BFD process(or). This is usually what we > > >>>>>>>> want to debug and i want to understand how this draft with > > >>>>>>>> sequence numbers can unequivocally tell me that. > > >>>>>>>> > > >>>>>>>> I believe the work is important and addresses something > > >>>>>>>> thats really required (spent too much time debugging why > > >>>>>>>> BFD > > flapped!). > > >>>>>>>> Clearly what would help is putting a small section that > > >>>>>>>> describes how we can use the sequence numbers to debug > what > > >>>>>>>> and > > where > > >>> things went wrong. > > >>>>>>>> > > >>>>>>>> Cheers, Manav > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > > >>>>>>>> > > > >>> wrote: > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > >>>>>>>>> > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > >>>>>>>>> pp > > >>>>>>>>> tx > > >>>>>>>>> > > >>>>>>>>> To attempt to simplify the presentation, the contentious > > >>>>>>>>> portion of the timers were removed from the proposal, > > >>>>>>>>> leaving only the sequence numbering for detecting loss of > > >>>>>>>>> BFD > async packets. > > >>>>>>>>> > > >>>>>>>>> When the room was polled to see whether the draft should > > >>>>>>>>> be adopted as a WG item, the sense of the room was very quiet. > > >>>>>>>>> As promised, this is to inquire for support for this draft > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > voice. > > >>>>>>>>> > > >>>>>>>>> It should be noted that post-meeting discussion on the > > >>>>>>>>> fate of this draft noted that BFD authentication code > > >>>>>>>>> points are plentiful and are available with expert review. > > >>>>>>>>> Should the draft authors wish to continue this work as > > >>>>>>>>> Experimental, that is > > an > > >>> option. > > >>>>>>>>> > > >>>>>>>>> -- Jeff > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > --_000_CO2PR0501MB8234A1BDDFD008EE12C847AB3780CO2PR0501MB823na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mallaik,

  That’s correct and = that is why I asked if we really need to define any packet format as Greg s= uggested?

 

Thanks

Santosh P K

 

From: MALLIK MUDIGONDA (mmudigon) [m= ailto:mmudigon@cisco.com]
Sent: Thursday, December 04, 2014 5:19 PM
To: Santosh P K; Vengada Prasad Govindan (venggovi); Gregory Mirsky;= Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91<= /p>

 

Hi Santosh,

 

With Echo, the receive side is not going = to look into the packet. It is just going to send it back and it is the res= ponsibility of the sender to interpret its contents. 

 

Regards

Mallik

 

From: Santosh P K <santoshpk@juniper.net>
Date: Thursday, 4 December 2014 5:15 pm
To: "Vengada Prasad Govindan (venggovi)" <venggovi@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com= >, Marc Binderberger <marc@sniff.de<= /a>>, Manav Bhatia <manavbhatia@gmai= l.com>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91<= /p>

 

Hi Prasad,

  That's right. We echo has lim= itations but for single hop we can still use it. I was trying to understand= even for single hop do we need to define any packet format for echo?

 

Thanks

Santosh P K

 

-----Original Message-----

From: Vengada Prasad Govindan (venggovi) = [mailto:venggovi@cisco.com]<= /o:p>

Sent: Thursday, December 04, 2014 4:45 PM=

To: Gregory Mirsky; Santosh P K; Marc Bin= derberger; Manav Bhatia

Cc: rtg-bfd@ietf.org<= /p>

Subject: RE: BFD stability follow-up from= IETF-91

Hello Greg/ Santosh,

   It was my understanding that= BFD Async was chosen for stability since there

are configurations where BFD echo mode is= not supported (e.g. Multi-hop,

BFD on LAGs and BFD over MPLS). Am I miss= ing something here, please let

me know.

Thanks

Prasad

-----Original Message-----

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory=

Mirsky

Sent: Thursday, December 04, 2014 11:44 A= M

To: Santosh P K; Marc Binderberger; Manav= Bhatia

Cc: rtg-bfd@ietf.org<= /p>

Subject: RE: BFD stability follow-up from= IETF-91

Hi Santosh,

yes, the format and thus interpretation o= f payload in Echo mode is not

defined and that, in my view, is what we = need - some open space. And Echo

well could be exactly that - no legacy, n= o backward compatibility (addressee

that doesn't support "extended Echo&= quot; will simply loop the packet back to

sender). Perhaps that will be direction w= e can discuss and, hopefully, agree

on.

Regards,

Greg

-----Original Message-----

From: Santosh P K [mailto:santoshpk@juniper.net]

Sent: Wednesday, December 03, 2014 9:54 P= M

To: Gregory Mirsky; Marc Binderberger; Ma= nav Bhatia

Cc: rtg-bfd@ietf.org<= /p>

Subject: RE: BFD stability follow-up from= IETF-91

Greg,

    I don't think we = have discussed about echo in this context. Echo is good

thing but payload of BFD echo packet is d= ecided by local system. Did you

mean to add suggestion on how echo packet= should look like? Or how echo

can help in BFD loss/delay issue?

Thanks

Santosh P K

> -----Original Message-----

> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]

> Sent: Thursday, December 04, 2014 2:= 22 AM

> To: Santosh P K; Marc Binderberger; = Manav Bhatia

> Cc: rtg-bfd@ietf.org<= /p>

> Subject: RE: BFD stability follow-up= from IETF-91

> 

> Dear All,

> had authors of the proposal or we al= ready dismissed use of BFD Echo?

> I've scanned the thread and couldn't= find trace of us discussing BFD

> Echo mode. I think that it is more s= uitable for experimentation and

unorthodox use.

> 

> Regards,

> Greg

> 

> -----Original Message-----

> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Sa= ntosh P

> K

> Sent: Wednesday, December 03, 2014 5= :39 AM

> To: Marc Binderberger; Manav Bhatia<= o:p>

> Cc: rtg-bfd@ietf.org<= /p>

> Subject: RE: BFD stability follow-up= from IETF-91

> 

> Hello Manav and Marc,

> 

> 

> > > One way to solve this prob= lem is by attaching a debug trailer that

> > > only carries the seq numbe= rs at the *end* of the BFD packet. This

> > > would not be covered in th= e Length field carried in the BFD header

> > > but would be accounted for= in the length carried in the IP header.

> >

> > BFD itself is not related to IP= , i.e. there is not always an IP header.

> > Sure, the encapsulating "f= rame" may provide a length but actually,

> > why not covering the debug trai= ler with the BFD length?

> >

> > If this is solely for debug pur= pose than this may work. For simple

> > copying-out into e.g. a packet = trace buffer it would be even simpler

> > to have the BFD length covering= the trailer.

> > If hardware is supposed to proc= ess the trailer information (other

> > than copying out) then it's get= ting ugly - having fixed position,

> > fixed length extension headers = would be preferable for simple access.

> 

> Fixed length would be easy to proces= s in hardware. Problem is when we

> have many have extensions in future.= If we want to use only one

> extension that is at the last then I= will be forced to pad all the

> other extension ahead of it? This mi= ght not be a problem if we have

> fewer extensions but might become pr= oblem when there are too many

extensions.

> 

> 

> >

> > Another idea is to use the 0x80= bit of the auth type to distinguish

> > between a "normal" au= thentication header and a "sequence +

> authentication".

> >

> 

> I think this is good. In the BFD ext= ension TLV we still have many

> reserved bits that can be used as we= ll?

> 

> Thanks

> Santosh P K

> 

> 

> 

> >

> > On Thu, 27 Nov 2014 21:12:00 &#= 43;0530, Manav Bhatia wrote:

> > > Hi Santosh,

> > >

> > > You could use the crypto s= equence numbers carried in the

> > > meticulous cryptographic a= uth for detecting packet losses.

> > > However, this breaks when = you use non-meticulous crypto

> > > authentication since the s= equence number is only incremented

> > > occasionally there. This i= believe is a deal breaker since i

> > > really envision non meticu= lous mode to be the one being widely

> > > deployed. In fact we were = supposed to write a draft on that and i

> > > guess it just fell through= the cracks (lemme ping my co-author on

> > > that !)<= /p>

> > >

> > > One way to solve this prob= lem is by attaching a debug trailer that

> > > only carries the seq numbe= rs at the *end* of the BFD packet. This

> > > would not be covered in th= e Length field carried in the BFD header

> > > but would be accounted for= in the length carried in the IP header.

> > > The concept of attaching a= trailer is documented well and is used

> > > in the IGPs. RFC 6506 desc= ribes one such trailer for OSPFv3. The

> > > catch however is that this= debug trailer will NOT be covered by

> > > the BFD authentication. Is= this acceptable to the WG?

> > >

> > > I think the problem of dia= gnosing a BFD flap becomes all the more

> > > important with BFD authent= ication turned on since then we have

> > > more points where a delay = can be inserted.

> > >

> > > Cheers, Manav

> > >

> > >

> > > On Thu, Nov 27, 2014 at 8:= 32 PM, Santosh P K

> > wrote:

> > >> Manav,

> > >>    = ; This is good question.

> > >>

> > >>> Can the authors ad= d some text on how this debugging mechanism

> > >>> would work if some= body employs BFD authentication?

> > >>

> > >> Right now we have cons= idered without authentication (we are

> > >> setting A bit). We sho= uld add some text on how we can use both

> > >> Auth and de bug

> > TLV.

> > >> Is there any suggestio= n you have? I will get back to you on this.

> > >>

> > >>

> > >> Thanks

> > >> Santosh P K=

> > >>

> > >>>> -----Original = Message-----

> > >>>> From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of

> > >>>> Mach

> > Chen

> > >>>> Sent: Thursday= , November 27, 2014 2:13 PM

> > >>>> To: Marc Binde= rberger

> > >>>> Cc: rtg-bfd@ietf.org<= /p>

> > >>>> Subject: RE: B= FD stability follow-up from IETF-91

> > >>>>

> > >>>> Hi Marc,<= /o:p>

> > >>>>

> > >>>>> -----Origi= nal Message-----

> > >>>>> From: Marc= Binderberger [mailto:marc@sniff.de]

> > >>>>> Sent: Thur= sday, November 27, 2014 1:43 AM

> > >>>>> To: Mach C= hen

> > >>>>> Cc: Manav = Bhatia; rtg-bfd@ietf.org<= /p>

> > >>>>> Subject: R= E: BFD stability follow-up from IETF-91

> > >>>>>=

> > >>>>> Hello Mach= ,

> > >>>>>=

> > >>>>>> This t= riggers me think out there should be another solution

> > >>>>>> for ge= tting the Tx and Rx timestamps without encoding the

> > >>>>>> timest= amps

> > in

> > >>>>>> the BF= D

> > >>>>> packets.

> > >>>>>> For ex= ample, the Tx and Rx systems could just save timestamps

> > >>>>>> locall= y or send them to a centralized entity and then use the

> > >>>>>> sequen= ce numbers to correlate them for further analyzing.

> > >>>>>=

> > >>>>> I remember= some discussion on NVO3 about how many bits it

> > >>>>> takes=

> > >>>>> ;-

> > ) -

> > >>>>> could you = send the links/draft names you are working on to this

list?

> > >>>>> May be use= ful for further discussions.

> > >>>>

> > >>>> Sure, here is = the

> > >>> based-ipfpm-framew= ork-02) for the reference.

> > >>>>

> > >>>> But here I wan= t to say is that since we have sequence number,

> > >>>> we may

> > not

> > >>> need the marking b= ased solution. Suppose that someone want to

> > monitor

> > >>> the delay of a BFD= packet , just record and save the timestamp

> > >>> at the Tx side, wh= ich indexed by the sequence number. Similarly,

> > >>> do the same at the= Rx side. Then based on the timestamps from

> > >>> both Tx and Rx, an= d using the sequence number to correlate the

> > >>> timestamps, it can= also provide a way

> > to

> > >>> monitor the delay = of the BFD packet.

> > >>>>

> > >>>> That means, on= ly if there is sequence number, even if without

> > >>>> carrying the

> > >>> timestamp in the B= FD packet, BFD packet delay can be measured.

> > >>>>

> > >>>> Best regards,<= o:p>

> > >>>> Mach

> > >>>>

> > >>>>>=

> > >>>>>=

> > >>>>> Thanks &am= p; Regards,

> > >>>>> Marc<= /o:p>

> > >>>>>=

> > >>>>>=

> > >>>>>=

> > >>>>> On Wed, 26= Nov 2014 09:17:32 +0000, Mach Chen wrote:

> > >>>>>> Hi Mar= c and Manav,

> > >>>>>>

> > >>>>>>> --= ---Original Message-----

> > >>>>>>> Fr= om: Rtg-bfd [mailto:rtg-bfd-bou= nces@ietf.org] On Behalf Of

> > Marc

> > >>>>>>> Bi= nderberger

> > >>>>>>> Se= nt: Wednesday, November 26, 2014 4:50 PM

> > >>>>>>> To= : Manav Bhatia

> > >>>>>>> Cc= : rtg-bfd@ietf.org<= /p>

> > >>>>>>> Su= bject: Re: BFD stability follow-up from IETF-91

> > >>>>>>>

> > >>>>>>> He= llo Manav,

> > >>>>>>>

> > >>>>>>>>= ; I believe the work is important and addresses something=

> > >>>>>>>>= ; thats really required (spent too much time debugging why

> > >>>>>>>>= ; BFD

> > flapped!).

> > >>>>>>>

> > >>>>>>> ag= ree :-) we should keep the discussion alive.

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>>= ; side Time stamping would have helped in debugging whether

> the

> > >>> BFD

> > >>>>>>>>= ; packet was sent late, or whether the packet was sent on=

> > >>>>>>>>= ; time and also arrived on time but was delayed when passing

> > >>>>>>>>= ; it up the BFD stack/processor (lay in the RX buffer for tad

> > >>>>>>>>= ; too

> > >>>>>>>>= ; long)

> > >>>>>>>

> > >>>>>>> we= ll, I can see a point in having the Tx timestamps in the<= /p>

> > >>>>>>> pa= cket mainly for the purpose of knowing "this" packet was

> > >>>>>>> ok= ay/not okay on the Tx side and to correlate it with your<= /p>

> > >>>>>>> lo= cal Rx

> measurement.

> > >>>>>>

> > >>>>>> Yes, t= his is one solution if people think BFD delay is needed.<= /p>

> > >>>>>> If all= ow to have Tx timestamps to be carried in the packets,

> > >>>>>> seems = it should be no problem to leave a seat for the Rx

> > >>>>>> timest= amps as well :-). After all, with both Tx and Rx

> > >>>>>> timest= amp, it may simplify the

> > >>>>> implementa= tion.

> > >>>>>>

> > >>>>>>>

> > >>>>>>> An= d even this point is less relevant with sequence numbers<= /p>

> > >>>>>>> as= this number allows the identification of packets and thus

> > >>>>>>> th= e correlation of information from the Tx and Rx system.

> > >>>>>>

> > >>>>>> Indeed= , the sequence number helps a lot for the correlation

> > between

> > >>>>>> the Tx= and Rx system.

> > >>>>>>

> > >>>>>> This t= riggers me think out there should be another solution

> > >>>>>> for ge= tting the Tx and Rx timestamps without encoding the

> > >>>>>> timest= amps

> > in

> > >>>>>> the BF= D

> > >>>>> packets.

> > >>>>>> For ex= ample, the Tx and Rx systems could just save timestamps

> > >>>>>> locall= y or send them to a centralized entity and then use the

> > >>>>>> sequen= ce numbers to correlate them for further analyzing.

> > >>>>>>

> > >>>>>> Best r= egards,

> > >>>>>> Mach

> > >>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>> Re= gards, Marc

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>> On= Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote:=

> > >>>>>>>>= ; Hi Jeff,

> > >>>>>>>>= ;

> > >>>>>>>>= ; I vividly remember the original intent of the stability=

> > >>>>>>>>= ; draft was to help debug BFD failures -- to isolate the<= /p>

> > >>>>>>>>= ; issue at the RX or the TX side Time stamping would have=

> > >>>>>>>>= ; helped in debugging

> > whether

> > >>>>>>>>= ; the BFD packet was sent late, or whether the packet was=

> > >>>>>>>>= ; sent on time and also arrived on time but was delayed when

> > >>>>>>>>= ; passing it up the BFD stack/processor (lay in the RX buffer

> > >>>>>>>>= ; for tad too long), etc. But then time stamping came with

> > >>>>>>>>= ; its own set of issues, and was hence dropped from the original=

draft.

> > >>>>>>>>= ;

> > >>>>>>>>= ; Can the authors send a summary on the list on why time<= /p>

> > >>>>>>>>= ; stamping was dropped so that we're all clear on that one.

> > >>>>>>>>= ;

> > >>>>>>>>= ; The current proposal does help but is not complete.

> > >>>>>>>>= ;

> > >>>>>>>>= ; Assume that the RX end loses a BFD session and learns later

> > >>>>>>>>= ; that it did eventually receive the missing BFD packets<= /p>

> > >>>>>>>>= ; (based on the

> > seq

> > >>> #).

> > >>>>>>>>= ; How would it know which end was misbehaving? Was it a

delay

> > >>>>>>>>= ; at the TX side, or was it the RX that delayed passing the

> > >>>>>>>>= ; packets to the BFD process(or). This is usually what we=

> > >>>>>>>>= ; want to debug and i want to understand how this draft with

> > >>>>>>>>= ; sequence numbers can unequivocally tell me that.

> > >>>>>>>>= ;

> > >>>>>>>>= ; I believe the work is important and addresses something=

> > >>>>>>>>= ; thats really required (spent too much time debugging why

> > >>>>>>>>= ; BFD

> > flapped!).

> > >>>>>>>>= ; Clearly what would help is putting a small section that=

> > >>>>>>>>= ; describes how we can use the sequence numbers to debug<= /p>

> what

> > >>>>>>>>= ; and

> > where

> > >>> things went wrong.=

> > >>>>>>>>= ;

> > >>>>>>>>= ; Cheers, Manav

> > >>>>>>>>= ;

> > >>>>>>>>= ;

> > >>>>>>>>= ; On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas

> > >>>>>>>>= ; <jhaas@pfrc.org>

> > >>> wrote:<= /span>

> > >>>>>>>>= ;> draft-ashesh-bfd-stability-01 was presented again during

> > >>>>>>>>= ;> IETF-91 in Honolulu.  The slides can be viewed here:

> > >>>>>>>>= ;>

> > >>>>>>>>= ;> pp

> > >>>>>>>>= ;> tx

> > >>>>>>>>= ;>

> > >>>>>>>>= ;> To attempt to simplify the presentation, the contentious

> > >>>>>>>>= ;> portion of the timers were removed from the proposal,

> > >>>>>>>>= ;> leaving only the sequence numbering for detecting loss of<= /span>

> > >>>>>>>>= ;> BFD

> async packets.

> > >>>>>>>>= ;>

> > >>>>>>>>= ;> When the room was polled to see whether the draft should

> > >>>>>>>>= ;> be adopted as a WG item, the sense of the room was very

quiet.

> > >>>>>>>>= ;> As promised, this is to inquire for support for this draft=

> > >>>>>>>>= ;> on the WG mailing list to make sure the whole group has a<= /span>

> voice.

> > >>>>>>>>= ;>

> > >>>>>>>>= ;> It should be noted that post-meeting discussion on the

> > >>>>>>>>= ;> fate of this draft noted that BFD authentication code

> > >>>>>>>>= ;> points are plentiful and are available with expert review.=

> > >>>>>>>>= ;> Should the draft authors wish to continue this work as

> > >>>>>>>>= ;> Experimental, that is

> > an

> > >>> option.=

> > >>>>>>>>= ;>

> > >>>>>>>>= ;> -- Jeff

> > >>>>>>>>= ;>

> > >>>>>>>>= ;

> > >>>>>>

> > >>>>

> > >>

> > >

 

 

--_000_CO2PR0501MB8234A1BDDFD008EE12C847AB3780CO2PR0501MB823na_-- From nobody Thu Dec 4 06:01:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FAB1AD384 for ; Thu, 4 Dec 2014 06:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 z9uksxZne-1z for ; Thu, 4 Dec 2014 06:00:45 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4A31AD3A1 for ; Thu, 4 Dec 2014 06:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=126728; q=dns/txt; s=iport; t=1417701644; x=1418911244; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4NZbPLWq9QlH9jjA+1dmWEtw44KOvyqbxT24qAAjalw=; b=FrKPDsnS7mWHZkTDQ3EKS5RSL3SwnbBV+rnoRoQu7SJ5f6E5TAU52Fee 8Uey71dX+eBZZbeDqD5G8dpuzCSJk/2TRbi+8Vy14ObhyuZdDDeQs3AGe A/v1b7ubsyP98NAkrT8hSM+jyOt2335Kw9BCpWINYHQc6T+G4981p+LBm 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIFAHNogFStJA2E/2dsb2JhbABagkMhIlJYBMRmgWqBewGEGgKBGxYBAQEBAX2EAgEBAQMBGgESOgQDCwUHBAIBCBEDAQEBAQoWAQYHIREUCQgCBAENBQgBEogOAwkJAQzQRQ2FXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReOMIIFIAwFBgEGgx6BHgWOBhSBdoQWhEKDFDiCdYNAhWuCNINpg3lvgUWBAAEBAQ X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208,217";a="102642689" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 04 Dec 2014 14:00:41 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB4E0fdD021916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 14:00:41 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 08:00:40 -0600 From: "Nobo Akiya (nobo)" To: Santosh P K , "MALLIK MUDIGONDA (mmudigon)" , "Vengada Prasad Govindan (venggovi)" , Gregory Mirsky , "Marc Binderberger" , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6shW/jisJENECZQt8/kBXRdpxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYCAAFQ6AIAACIMAgAAA+ACAAADogP//un7w Date: Thu, 4 Dec 2014 14:00:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.136] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F5AE38Dxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/T5G4dkYq_COt1fyg58XgHV2tcO0 X-Mailman-Approved-At: Thu, 04 Dec 2014 06:01:39 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 14:00:53 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943F5AE38Dxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A quick question to understand where we are. If we had: 1. Standardization of Null Authentication (i.e., sequence numbers) 2. Implementation of local TX/RX timestamp mechanism described by Marc= below What are the core requirements which have not been satisfied? Thanks! -Nobo P.S. No, there is no need to standardize BFD echo contents. From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Thursday, December 04, 2014 6:52 AM To: MALLIK MUDIGONDA (mmudigon); Vengada Prasad Govindan (venggovi); Gregor= y Mirsky; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Mallaik, That's correct and that is why I asked if we really need to define any pa= cket format as Greg suggested? Thanks Santosh P K From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Thursday, December 04, 2014 5:19 PM To: Santosh P K; Vengada Prasad Govindan (venggovi); Gregory Mirsky; Marc B= inderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Santosh, With Echo, the receive side is not going to look into the packet. It is jus= t going to send it back and it is the responsibility of the sender to inter= pret its contents. Regards Mallik From: Santosh P K > Date: Thursday, 4 December 2014 5:15 pm To: "Vengada Prasad Govindan (venggovi)" >, Gregory Mirsky >, Marc Binderberger >, Manav Bhatia > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Prasad, That's right. We echo has limitations but for single hop we can still use= it. I was trying to understand even for single hop do we need to define an= y packet format for echo? Thanks Santosh P K -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] Sent: Thursday, December 04, 2014 4:45 PM To: Gregory Mirsky; Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Greg/ Santosh, It was my understanding that BFD Async was chosen for stability since th= ere are configurations where BFD echo mode is not supported (e.g. Multi-hop, BFD on LAGs and BFD over MPLS). Am I missing something here, please let me know. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, December 04, 2014 11:44 AM To: Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, yes, the format and thus interpretation of payload in Echo mode is not defined and that, in my view, is what we need - some open space. And Echo well could be exactly that - no legacy, no backward compatibility (addresse= e that doesn't support "extended Echo" will simply loop the packet back to sender). Perhaps that will be direction we can discuss and, hopefully, agre= e on. Regards, Greg -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Wednesday, December 03, 2014 9:54 PM To: Gregory Mirsky; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Greg, I don't think we have discussed about echo in this context. Echo is goo= d thing but payload of BFD echo packet is decided by local system. Did you mean to add suggestion on how echo packet should look like? Or how echo can help in BFD loss/delay issue? Thanks Santosh P K > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, December 04, 2014 2:22 AM > To: Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 > > Dear All, > had authors of the proposal or we already dismissed use of BFD Echo? > I've scanned the thread and couldn't find trace of us discussing BFD > Echo mode. I think that it is more suitable for experimentation and unorthodox use. > > Regards, > Greg > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P > K > Sent: Wednesday, December 03, 2014 5:39 AM > To: Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 > > Hello Manav and Marc, > > > > > One way to solve this problem is by attaching a debug trailer that > > > only carries the seq numbers at the *end* of the BFD packet. This > > > would not be covered in the Length field carried in the BFD header > > > but would be accounted for in the length carried in the IP header. > > > > BFD itself is not related to IP, i.e. there is not always an IP header. > > Sure, the encapsulating "frame" may provide a length but actually, > > why not covering the debug trailer with the BFD length? > > > > If this is solely for debug purpose than this may work. For simple > > copying-out into e.g. a packet trace buffer it would be even simpler > > to have the BFD length covering the trailer. > > If hardware is supposed to process the trailer information (other > > than copying out) then it's getting ugly - having fixed position, > > fixed length extension headers would be preferable for simple access. > > Fixed length would be easy to process in hardware. Problem is when we > have many have extensions in future. If we want to use only one > extension that is at the last then I will be forced to pad all the > other extension ahead of it? This might not be a problem if we have > fewer extensions but might become problem when there are too many extensions. > > > > > > Another idea is to use the 0x80 bit of the auth type to distinguish > > between a "normal" authentication header and a "sequence + > authentication". > > > > I think this is good. In the BFD extension TLV we still have many > reserved bits that can be used as well? > > Thanks > Santosh P K > > > > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > Hi Santosh, > > > > > > You could use the crypto sequence numbers carried in the > > > meticulous cryptographic auth for detecting packet losses. > > > However, this breaks when you use non-meticulous crypto > > > authentication since the sequence number is only incremented > > > occasionally there. This i believe is a deal breaker since i > > > really envision non meticulous mode to be the one being widely > > > deployed. In fact we were supposed to write a draft on that and i > > > guess it just fell through the cracks (lemme ping my co-author on > > > that !) > > > > > > One way to solve this problem is by attaching a debug trailer that > > > only carries the seq numbers at the *end* of the BFD packet. This > > > would not be covered in the Length field carried in the BFD header > > > but would be accounted for in the length carried in the IP header. > > > The concept of attaching a trailer is documented well and is used > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The > > > catch however is that this debug trailer will NOT be covered by > > > the BFD authentication. Is this acceptable to the WG? > > > > > > I think the problem of diagnosing a BFD flap becomes all the more > > > important with BFD authentication turned on since then we have > > > more points where a delay can be inserted. > > > > > > Cheers, Manav > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > > > > > wrote: > > >> Manav, > > >> This is good question. > > >> > > >>> Can the authors add some text on how this debugging mechanism > > >>> would work if somebody employs BFD authentication? > > >> > > >> Right now we have considered without authentication (we are > > >> setting A bit). We should add some text on how we can use both > > >> Auth and de bug > > TLV. > > >> Is there any suggestion you have? I will get back to you on this. > > >> > > >> > > >> Thanks > > >> Santosh P K > > >> > > >>>> -----Original Message----- > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > >>>> Mach > > Chen > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > >>>> To: Marc Binderberger > > >>>> Cc: rtg-bfd@ietf.org > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>> > > >>>> Hi Marc, > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > >>>>> To: Mach Chen > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>>> > > >>>>> Hello Mach, > > >>>>> > > >>>>>> This triggers me think out there should be another solution > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > >>>>>> locally or send them to a centralized entity and then use the > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>> > > >>>>> I remember some discussion on NVO3 about how many bits it > > >>>>> takes > > >>>>> ;- > > ) - > > >>>>> could you send the links/draft names you are working on to this list? > > >>>>> May be useful for further discussions. > > >>>> > > >>>> Sure, here is the > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > >>> based-ipfpm-framework-02) for the reference. > > >>>> > > >>>> But here I want to say is that since we have sequence number, > > >>>> we may > > not > > >>> need the marking based solution. Suppose that someone want to > > monitor > > >>> the delay of a BFD packet , just record and save the timestamp > > >>> at the Tx side, which indexed by the sequence number. Similarly, > > >>> do the same at the Rx side. Then based on the timestamps from > > >>> both Tx and Rx, and using the sequence number to correlate the > > >>> timestamps, it can also provide a way > > to > > >>> monitor the delay of the BFD packet. > > >>>> > > >>>> That means, only if there is sequence number, even if without > > >>>> carrying the > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > >>>> > > >>>> Best regards, > > >>>> Mach > > >>>> > > >>>>> > > >>>>> > > >>>>> Thanks & Regards, > > >>>>> Marc > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > >>>>>> Hi Marc and Manav, > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > Marc > > >>>>>>> Binderberger > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > >>>>>>> To: Manav Bhatia > > >>>>>>> Cc: rtg-bfd@ietf.org > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > >>>>>>> > > >>>>>>> Hello Manav, > > >>>>>>> > > >>>>>>>> I believe the work is important and addresses something > > >>>>>>>> thats really required (spent too much time debugging why > > >>>>>>>> BFD > > flapped!). > > >>>>>>> > > >>>>>>> agree :-) we should keep the discussion alive. > > >>>>>>> > > >>>>>>> > > >>>>>>>> side Time stamping would have helped in debugging whether > the > > >>> BFD > > >>>>>>>> packet was sent late, or whether the packet was sent on > > >>>>>>>> time and also arrived on time but was delayed when passing > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad > > >>>>>>>> too > > >>>>>>>> long) > > >>>>>>> > > >>>>>>> well, I can see a point in having the Tx timestamps in the > > >>>>>>> packet mainly for the purpose of knowing "this" packet was > > >>>>>>> okay/not okay on the Tx side and to correlate it with your > > >>>>>>> local Rx > measurement. > > >>>>>> > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > >>>>>> If allow to have Tx timestamps to be carried in the packets, > > >>>>>> seems it should be no problem to leave a seat for the Rx > > >>>>>> timestamps as well :-). After all, with both Tx and Rx > > >>>>>> timestamp, it may simplify the > > >>>>> implementation. > > >>>>>> > > >>>>>>> > > >>>>>>> And even this point is less relevant with sequence numbers > > >>>>>>> as this number allows the identification of packets and thus > > >>>>>>> the correlation of information from the Tx and Rx system. > > >>>>>> > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > between > > >>>>>> the Tx and Rx system. > > >>>>>> > > >>>>>> This triggers me think out there should be another solution > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > >>>>>> locally or send them to a centralized entity and then use the > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Mach > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Regards, Marc > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > >>>>>>>> Hi Jeff, > > >>>>>>>> > > >>>>>>>> I vividly remember the original intent of the stability > > >>>>>>>> draft was to help debug BFD failures -- to isolate the > > >>>>>>>> issue at the RX or the TX side Time stamping would have > > >>>>>>>> helped in debugging > > whether > > >>>>>>>> the BFD packet was sent late, or whether the packet was > > >>>>>>>> sent on time and also arrived on time but was delayed when > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer > > >>>>>>>> for tad too long), etc. But then time stamping came with > > >>>>>>>> its own set of issues, and was hence dropped from the original draft. > > >>>>>>>> > > >>>>>>>> Can the authors send a summary on the list on why time > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > >>>>>>>> > > >>>>>>>> The current proposal does help but is not complete. > > >>>>>>>> > > >>>>>>>> Assume that the RX end loses a BFD session and learns later > > >>>>>>>> that it did eventually receive the missing BFD packets > > >>>>>>>> (based on the > > seq > > >>> #). > > >>>>>>>> How would it know which end was misbehaving? Was it a delay > > >>>>>>>> at the TX side, or was it the RX that delayed passing the > > >>>>>>>> packets to the BFD process(or). This is usually what we > > >>>>>>>> want to debug and i want to understand how this draft with > > >>>>>>>> sequence numbers can unequivocally tell me that. > > >>>>>>>> > > >>>>>>>> I believe the work is important and addresses something > > >>>>>>>> thats really required (spent too much time debugging why > > >>>>>>>> BFD > > flapped!). > > >>>>>>>> Clearly what would help is putting a small section that > > >>>>>>>> describes how we can use the sequence numbers to debug > what > > >>>>>>>> and > > where > > >>> things went wrong. > > >>>>>>>> > > >>>>>>>> Cheers, Manav > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > > >>>>>>>> > > > >>> wrote: > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > >>>>>>>>> > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > >>>>>>>>> pp > > >>>>>>>>> tx > > >>>>>>>>> > > >>>>>>>>> To attempt to simplify the presentation, the contentious > > >>>>>>>>> portion of the timers were removed from the proposal, > > >>>>>>>>> leaving only the sequence numbering for detecting loss of > > >>>>>>>>> BFD > async packets. > > >>>>>>>>> > > >>>>>>>>> When the room was polled to see whether the draft should > > >>>>>>>>> be adopted as a WG item, the sense of the room was very quiet. > > >>>>>>>>> As promised, this is to inquire for support for this draft > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > voice. > > >>>>>>>>> > > >>>>>>>>> It should be noted that post-meeting discussion on the > > >>>>>>>>> fate of this draft noted that BFD authentication code > > >>>>>>>>> points are plentiful and are available with expert review. > > >>>>>>>>> Should the draft authors wish to continue this work as > > >>>>>>>>> Experimental, that is > > an > > >>> option. > > >>>>>>>>> > > >>>>>>>>> -- Jeff > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > --_000_CECE764681BE964CBE1DFF78F3CDD3943F5AE38Dxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A quick question to under= stand where we are.

 <= /p>

If we had:

 <= /p>

1. = ;     Standardization o= f Null Authentication (i.e., sequence numbers)

2. = ;     Implementation of= local TX/RX timestamp mechanism described by Marc below<= /p>

 <= /p>

What are the core require= ments which have not been satisfied?

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

P.S. No, there is no need= to standardize BFD echo contents.

 <= /p>

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Thursday, December 04, 2014 6:52 AM
To: MALLIK MUDIGONDA (mmudigon); Vengada Prasad Govindan (venggovi);= Gregory Mirsky; Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up from IETF-91<= /p>

 

Mallaik,

 &nbs= p;That’s correct and that is why I asked if we really need to define = any packet format as Greg suggested?

 = ;

Thanks

Santosh P = K

 = ;

From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Thursday, December 04, 2014 5:19 PM
To: Santosh P K; Vengada Prasad Govindan (venggovi); Gregory Mirsky;= Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91<= /p>

 

Hi Santosh,

 

With Echo, the= receive side is not going to look into the packet. It is just going to sen= d it back and it is the responsibility of the sender to interpret its contents. 

 

Regards

Mallik

 

From: Santosh P K <santoshpk@juniper.net>
Date: Thursday, 4 December 2014 5:15 pm
To: "Vengada Prasad Govindan (venggovi)" <venggovi@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com= >, Marc Binderberger <marc@sniff.de<= /a>>, Manav Bhatia <manavbhatia@gmai= l.com>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91<= /p>

 

Hi Prasad,

  Th= at's right. We echo has limitations but for single hop we can still use it.= I was trying to understand even for single hop do we need to define any packet format for echo?

 

Thanks

Santosh P K

 

-----Original = Message-----

From: Vengada = Prasad Govindan (venggovi) [mailto:ve= nggovi@cisco.com]

Sent: Thursday= , December 04, 2014 4:45 PM

To: Gregory Mi= rsky; Santosh P K; Marc Binderberger; Manav Bhatia

Cc: rtg-bfd@ietf.org<= /p>

Subject: RE: B= FD stability follow-up from IETF-91

Hello Greg/ Sa= ntosh,

   I= t was my understanding that BFD Async was chosen for stability since there<= o:p>

are configurat= ions where BFD echo mode is not supported (e.g. Multi-hop,

BFD on LAGs an= d BFD over MPLS). Am I missing something here, please let=

me know.<= /o:p>

Thanks

Prasad

-----Original = Message-----

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of Gregory

Mirsky

Sent: Thursday= , December 04, 2014 11:44 AM

To: Santosh P = K; Marc Binderberger; Manav Bhatia

Cc: rtg-bfd@ietf.org<= /p>

Subject: RE: B= FD stability follow-up from IETF-91

Hi Santosh,

yes, the forma= t and thus interpretation of payload in Echo mode is not<= /p>

defined and th= at, in my view, is what we need - some open space. And Echo

well could be = exactly that - no legacy, no backward compatibility (addressee

that doesn't s= upport "extended Echo" will simply loop the packet back to

sender). Perha= ps that will be direction we can discuss and, hopefully, agree

on.=

Regards,<= /o:p>

Greg

-----Original = Message-----

Sent: Wednesda= y, December 03, 2014 9:54 PM

To: Gregory Mi= rsky; Marc Binderberger; Manav Bhatia

Subject: RE: B= FD stability follow-up from IETF-91

Greg,

  &n= bsp; I don't think we have discussed about echo in this context. Echo = is good

thing but payl= oad of BFD echo packet is decided by local system. Did you

mean to add su= ggestion on how echo packet should look like? Or how echo=

can help in BF= D loss/delay issue?

Thanks

Santosh P K

> -----Orig= inal Message-----

> From: Gre= gory Mirsky [mailto:gregory.= mirsky@ericsson.com]

> Sent: Thu= rsday, December 04, 2014 2:22 AM

> To: Santo= sh P K; Marc Binderberger; Manav Bhatia

> Cc: rtg-bfd@ietf.org<= /p>

> Subject: = RE: BFD stability follow-up from IETF-91

> = ;

> Dear All,=

> had autho= rs of the proposal or we already dismissed use of BFD Echo?

> I've scan= ned the thread and couldn't find trace of us discussing BFD

> Echo mode= . I think that it is more suitable for experimentation and

unorthodox use= .

> = ;

> Regards,<= o:p>

> Greg=

> = ;

> -----Orig= inal Message-----

> From: Rtg= -bfd [mailto:rtg-bfd-bounces@ie= tf.org] On Behalf Of Santosh P

> K

> Sent: Wed= nesday, December 03, 2014 5:39 AM

> To: Marc = Binderberger; Manav Bhatia

> Cc: rtg-bfd@ietf.org<= /p>

> Subject: = RE: BFD stability follow-up from IETF-91

> = ;

> Hello Man= av and Marc,

> = ;

> = ;

> > >= One way to solve this problem is by attaching a debug trailer that

> > >= only carries the seq numbers at the *end* of the BFD packet. This

> > >= would not be covered in the Length field carried in the BFD header

> > >= but would be accounted for in the length carried in the IP header.

> >=

> > BFD = itself is not related to IP, i.e. there is not always an IP header.

> > Sure= , the encapsulating "frame" may provide a length but actually,

> > why = not covering the debug trailer with the BFD length?

> >=

> > If t= his is solely for debug purpose than this may work. For simple

> > copy= ing-out into e.g. a packet trace buffer it would be even simpler=

> > to h= ave the BFD length covering the trailer.

> > If h= ardware is supposed to process the trailer information (other

> > than= copying out) then it's getting ugly - having fixed position,

> > fixe= d length extension headers would be preferable for simple access.

> = ;

> Fixed len= gth would be easy to process in hardware. Problem is when we

> have many= have extensions in future. If we want to use only one

> extension= that is at the last then I will be forced to pad all the=

> other ext= ension ahead of it? This might not be a problem if we have

> fewer ext= ensions but might become problem when there are too many<= /p>

extensions.

> = ;

> = ;

> >=

> > Anot= her idea is to use the 0x80 bit of the auth type to distinguish<= /span>

> > betw= een a "normal" authentication header and a "sequence +

> authentic= ation".

> >=

> = ;

> I think t= his is good. In the BFD extension TLV we still have many<= /p>

> reserved = bits that can be used as well?

> = ;

> Thanks

> Santosh P= K

> = ;

> = ;

> = ;

> >=

> > On T= hu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote:

> > >= Hi Santosh,

> > >=

> > >= You could use the crypto sequence numbers carried in the=

> > >= meticulous cryptographic auth for detecting packet losses.

> > >= However, this breaks when you use non-meticulous crypto<= /p>

> > >= authentication since the sequence number is only incremented

> > >= occasionally there. This i believe is a deal breaker since i

> > >= really envision non meticulous mode to be the one being widely<= /span>

> > >= deployed. In fact we were supposed to write a draft on that and i

> > >= guess it just fell through the cracks (lemme ping my co-author on

> > >= that !)

> > >=

> > >= One way to solve this problem is by attaching a debug trailer that

> > >= only carries the seq numbers at the *end* of the BFD packet. This

> > >= would not be covered in the Length field carried in the BFD header

> > >= but would be accounted for in the length carried in the IP header.

> > >= The concept of attaching a trailer is documented well and is used

> > >= in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The

> > >= catch however is that this debug trailer will NOT be covered by=

> > >= the BFD authentication. Is this acceptable to the WG?

> > >=

> > >= I think the problem of diagnosing a BFD flap becomes all the more

> > >= important with BFD authentication turned on since then we have<= /span>

> > >= more points where a delay can be inserted.

> > >=

> > >= Cheers, Manav

> > >=

> > >=

> > >= On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K

> > wrot= e:

> > >= > Manav,

> > >= >     This is good question.

> > >= >

> > >= >> Can the authors add some text on how this debugging mechanism=

> > >= >> would work if somebody employs BFD authentication?

> > >= >

> > >= > Right now we have considered without authentication (we are=

> > >= > setting A bit). We should add some text on how we can use both

> > >= > Auth and de bug

> > TLV.=

> > >= > Is there any suggestion you have? I will get back to you on this.=

> > >= >

> > >= >

> > >= > Thanks

> > >= > Santosh P K

> > >= >

> > >= >>> -----Original Message-----

> > >= >>> From: Rtg-bfd [mai= lto:rtg-bfd-bounces@ietf.org] On Behalf Of

> > >= >>> Mach

> > Chen=

> > >= >>> Sent: Thursday, November 27, 2014 2:13 PM

> > >= >>> To: Marc Binderberger

> > >= >>> Cc: rtg-bfd@ietf.org<= /p>

> > >= >>> Subject: RE: BFD stability follow-up from IETF-91

> > >= >>>

> > >= >>> Hi Marc,

> > >= >>>

> > >= >>>> -----Original Message-----

> > >= >>>> From: Marc Binderberger [= mailto:marc@sniff.de]

> > >= >>>> Sent: Thursday, November 27, 2014 1:43 AM

> > >= >>>> To: Mach Chen

> > >= >>>> Cc: Manav Bhatia; rtg-bfd@ietf.org<= /p>

> > >= >>>> Subject: RE: BFD stability follow-up from IETF-91

> > >= >>>>

> > >= >>>> Hello Mach,

> > >= >>>>

> > >= >>>>> This triggers me think out there should be another sol= ution

> > >= >>>>> for getting the Tx and Rx timestamps without encoding = the

> > >= >>>>> timestamps

> > in

> > >= >>>>> the BFD

> > >= >>>> packets.

> > >= >>>>> For example, the Tx and Rx systems could just save tim= estamps

> > >= >>>>> locally or send them to a centralized entity and then = use the

> > >= >>>>> sequence numbers to correlate them for further analyzi= ng.

> > >= >>>>

> > >= >>>> I remember some discussion on NVO3 about how many bits it<= o:p>

> > >= >>>> takes

> > >= >>>> ;-

> > ) -<= o:p>

> > >= >>>> could you send the links/draft names you are working on to= this

list?

> > >= >>>> May be useful for further discussions.

> > >= >>>

> > >= >>> Sure, here is the

> > >= >> based-ipfpm-framework-02) for the reference.

> > >= >>>

> > >= >>> But here I want to say is that since we have sequence number,<= o:p>

> > >= >>> we may

> > not<= o:p>

> > >= >> need the marking based solution. Suppose that someone want to=

> > moni= tor

> > >= >> the delay of a BFD packet , just record and save the timestamp

> > >= >> at the Tx side, which indexed by the sequence number. Similarly,

> > >= >> do the same at the Rx side. Then based on the timestamps from=

> > >= >> both Tx and Rx, and using the sequence number to correlate the

> > >= >> timestamps, it can also provide a way

> > to

> > >= >> monitor the delay of the BFD packet.

> > >= >>>

> > >= >>> That means, only if there is sequence number, even if without<= o:p>

> > >= >>> carrying the

> > >= >> timestamp in the BFD packet, BFD packet delay can be measured.

> > >= >>>

> > >= >>> Best regards,

> > >= >>> Mach

> > >= >>>

> > >= >>>>

> > >= >>>>

> > >= >>>> Thanks & Regards,

> > >= >>>> Marc

> > >= >>>>

> > >= >>>>

> > >= >>>>

> > >= >>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote:

> > >= >>>>> Hi Marc and Manav,

> > >= >>>>>

> > >= >>>>>> -----Original Message-----

> > >= >>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of

> > Marc=

> > >= >>>>>> Binderberger

> > >= >>>>>> Sent: Wednesday, November 26, 2014 4:50 PM

> > >= >>>>>> To: Manav Bhatia

> > >= >>>>>> Cc: rtg-bfd@ietf.org<= /p>

> > >= >>>>>> Subject: Re: BFD stability follow-up from IETF-91<= o:p>

> > >= >>>>>>

> > >= >>>>>> Hello Manav,

> > >= >>>>>>

> > >= >>>>>>> I believe the work is important and addresses = something

> > >= >>>>>>> thats really required (spent too much time deb= ugging why

> > >= >>>>>>> BFD

> > flap= ped!).

> > >= >>>>>>

> > >= >>>>>> agree :-) we should keep the discussion alive.

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>> side Time stamping would have helped in debugg= ing whether

> the<= /o:p>

> > >= >> BFD

> > >= >>>>>>> packet was sent late, or whether the packet wa= s sent on

> > >= >>>>>>> time and also arrived on time but was delayed = when passing

> > >= >>>>>>> it up the BFD stack/processor (lay in the RX b= uffer for tad

> > >= >>>>>>> too

> > >= >>>>>>> long)

> > >= >>>>>>

> > >= >>>>>> well, I can see a point in having the Tx timestamp= s in the

> > >= >>>>>> packet mainly for the purpose of knowing "thi= s" packet was

> > >= >>>>>> okay/not okay on the Tx side and to correlate it w= ith your

> > >= >>>>>> local Rx

> measureme= nt.

> > >= >>>>>

> > >= >>>>> Yes, this is one solution if people think BFD delay is= needed.

> > >= >>>>> If allow to have Tx timestamps to be carried in the pa= ckets,

> > >= >>>>> seems it should be no problem to leave a seat for the = Rx

> > >= >>>>> timestamps as well :-). After all, with both Tx and Rx=

> > >= >>>>> timestamp, it may simplify the

> > >= >>>> implementation.

> > >= >>>>>

> > >= >>>>>>

> > >= >>>>>> And even this point is less relevant with sequence= numbers

> > >= >>>>>> as this number allows the identification of packet= s and thus

> > >= >>>>>> the correlation of information from the Tx and Rx = system.

> > >= >>>>>

> > >= >>>>> Indeed, the sequence number helps a lot for the correl= ation

> > betw= een

> > >= >>>>> the Tx and Rx system.

> > >= >>>>>

> > >= >>>>> This triggers me think out there should be another sol= ution

> > >= >>>>> for getting the Tx and Rx timestamps without encoding = the

> > >= >>>>> timestamps

> > in

> > >= >>>>> the BFD

> > >= >>>> packets.

> > >= >>>>> For example, the Tx and Rx systems could just save tim= estamps

> > >= >>>>> locally or send them to a centralized entity and then = use the

> > >= >>>>> sequence numbers to correlate them for further analyzi= ng.

> > >= >>>>>

> > >= >>>>> Best regards,

> > >= >>>>> Mach

> > >= >>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>> Regards, Marc

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhat= ia wrote:

> > >= >>>>>>> Hi Jeff,

> > >= >>>>>>>

> > >= >>>>>>> I vividly remember the original intent of the = stability

> > >= >>>>>>> draft was to help debug BFD failures -- to iso= late the

> > >= >>>>>>> issue at the RX or the TX side Time stamping w= ould have

> > >= >>>>>>> helped in debugging

> > whet= her

> > >= >>>>>>> the BFD packet was sent late, or whether the p= acket was

> > >= >>>>>>> sent on time and also arrived on time but was = delayed when

> > >= >>>>>>> passing it up the BFD stack/processor (lay in = the RX buffer

> > >= >>>>>>> for tad too long), etc. But then time stamping= came with

> > >= >>>>>>> its own set of issues, and was hence dropped f= rom the original

draft.

> > >= >>>>>>>

> > >= >>>>>>> Can the authors send a summary on the list on = why time

> > >= >>>>>>> stamping was dropped so that we're all clear o= n that one.

> > >= >>>>>>>

> > >= >>>>>>> The current proposal does help but is not comp= lete.

> > >= >>>>>>>

> > >= >>>>>>> Assume that the RX end loses a BFD session and= learns later

> > >= >>>>>>> that it did eventually receive the missing BFD= packets

> > >= >>>>>>> (based on the

> > seq<= o:p>

> > >= >> #).

> > >= >>>>>>> How would it know which end was misbehaving? W= as it a

delay

> > >= >>>>>>> at the TX side, or was it the RX that delayed = passing the

> > >= >>>>>>> packets to the BFD process(or). This is usuall= y what we

> > >= >>>>>>> want to debug and i want to understand how thi= s draft with

> > >= >>>>>>> sequence numbers can unequivocally tell me tha= t.

> > >= >>>>>>>

> > >= >>>>>>> I believe the work is important and addresses = something

> > >= >>>>>>> thats really required (spent too much time deb= ugging why

> > >= >>>>>>> BFD

> > flap= ped!).

> > >= >>>>>>> Clearly what would help is putting a small sec= tion that

> > >= >>>>>>> describes how we can use the sequence numbers = to debug

> what=

> > >= >>>>>>> and

> > wher= e

> > >= >> things went wrong.

> > >= >>>>>>>

> > >= >>>>>>> Cheers, Manav

> > >= >>>>>>>

> > >= >>>>>>>

> > >= >>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas<= o:p>

> > >= >>>>>>> <jhaas@pf= rc.org>

> > >= >> wrote:

> > >= >>>>>>>> draft-ashesh-bfd-stability-01 was presente= d again during

> > >= >>>>>>>> IETF-91 in Honolulu.  The slides= can be viewed here:

> > >= >>>>>>>>

> > >= >>>>>>>> pp

> > >= >>>>>>>> tx

> > >= >>>>>>>>

> > >= >>>>>>>> To attempt to simplify the presentation, t= he contentious

> > >= >>>>>>>> portion of the timers were removed from th= e proposal,

> > >= >>>>>>>> leaving only the sequence numbering for de= tecting loss of

> > >= >>>>>>>> BFD

> async pac= kets.

> > >= >>>>>>>>

> > >= >>>>>>>> When the room was polled to see whether th= e draft should

> > >= >>>>>>>> be adopted as a WG item, the sense of the = room was very

quiet.

> > >= >>>>>>>> As promised, this is to inquire for suppor= t for this draft

> > >= >>>>>>>> on the WG mailing list to make sure the wh= ole group has a

> voice.

> > >= >>>>>>>>

> > >= >>>>>>>> It should be noted that post-meeting discu= ssion on the

> > >= >>>>>>>> fate of this draft noted that BFD authenti= cation code

> > >= >>>>>>>> points are plentiful and are available wit= h expert review.

> > >= >>>>>>>> Should the draft authors wish to continue = this work as

> > >= >>>>>>>> Experimental, that is

> > an

> > >= >> option.

> > >= >>>>>>>>

> > >= >>>>>>>> -- Jeff

> > >= >>>>>>>>

> > >= >>>>>>>

> > >= >>>>>

> > >= >>>

> > >= >

> > >=

 

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943F5AE38Dxmbalnx01ciscoc_-- From nobody Thu Dec 4 06:53:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17381AD3FF for ; Thu, 4 Dec 2014 06:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 I0hEGxQ8gK06 for ; Thu, 4 Dec 2014 06:53:22 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CA91AD3BB for ; Thu, 4 Dec 2014 06:53:22 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id u20so12370490oif.41 for ; Thu, 04 Dec 2014 06:53:21 -0800 (PST) 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:content-type; bh=Aoq90yF09gmUpM+OW/bFgMtA2qc7ffw5N5uitJWyJY8=; b=PV4BAMsEdFxSvfUNRFj9xLiaAk663k0jv/5C+3+tEMe/nRGQD7xB+aLhj2Po45E6D7 PzQwNmC6eF/D75o3tP9ry6TiW2hlmS0xf4pbxb9Dkje1xnWHwqgyvsYqsi/M55TSWbQ/ 0nBkKtknbpdjDQAt7QPv/HK6HY+dN1k9EvM4gQ+T2csNycXovyVq+pzfUG62ptlcPScd +Y/BPxqk+C1VaEPtsRYvD+fV+ltZFRd1ayMlGySt+sSD6HN0Qfb6/CD8Fg77oyXkJzBW dqkaI6l+503eGiks40jh1w1svhzD+267H3m8t5akenotFvF4kKSpPQvE5tEUN7IjF86U hflg== MIME-Version: 1.0 X-Received: by 10.202.80.21 with SMTP id e21mr6750687oib.65.1417704801345; Thu, 04 Dec 2014 06:53:21 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 06:53:21 -0800 (PST) In-Reply-To: References: Date: Thu, 4 Dec 2014 20:23:21 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=001a113d840814a6450509651fb0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BsiIuPWTR_xEPVRfzRdBMa8tpZU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 14:53:25 -0000 --001a113d840814a6450509651fb0 Content-Type: text/plain; charset=UTF-8 Nobo - Locally storing TX/RX timestamps is not interoperable. Cheers, Manav On Thu, Dec 4, 2014 at 7:30 PM, Nobo Akiya (nobo) wrote: > A quick question to understand where we are. > > > > If we had: > > > > 1. Standardization of Null Authentication (i.e., sequence numbers) > > 2. Implementation of local TX/RX timestamp mechanism described by > Marc below > > > > What are the core requirements which have not been satisfied? > > > > Thanks! > > > > -Nobo > > > > P.S. No, there is no need to standardize BFD echo contents. > > > > > --001a113d840814a6450509651fb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nobo - Locally storing TX/RX timestamps is not intero= perable.

Cheers, Manav

On Thu, Dec 4, 2014 at 7:30 PM, = Nobo Akiya (nobo) <nobo@cisco.com> wrote:

A quick question to under= stand where we are.

=C2=A0

If we had:<= /span>

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Standardization of N= ull Authentication (i.e., sequence numbers)

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Implementation of lo= cal TX/RX timestamp mechanism described by Marc below<= /p>

=C2=A0

What are the core require= ments which have not been satisfied?

=C2=A0

Thanks!

=C2=A0

-Nobo

=C2=A0

P.S. No, there is no need= to standardize BFD echo contents.

=C2=A0


--001a113d840814a6450509651fb0-- From nobody Thu Dec 4 07:14:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AA71A0183 for ; Thu, 4 Dec 2014 07:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 z4mIqlOKCPK0 for ; Thu, 4 Dec 2014 07:14:52 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7124D1A8968 for ; Thu, 4 Dec 2014 07:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15416; q=dns/txt; s=iport; t=1417706092; x=1418915692; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TCkVIRaZnDxsHjmQ54oCpN1CttPtC6t2pElKBq2dJZk=; b=IWo3uyj4NZs0uDk3z16TMAj5LUQV3ACQYytpJytWkfMjAsaTNZ5+7KqW /eiQ36VIoxMcYfgKr7gCErd5NaS6p90QdLokr3/tQAXMpMiHSAVIpj/a6 4ah9lBDuasawBFVwF3Aey/OLouOR0PLtKnwDAOwFMLi4RmlqNC23nHlYK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsJAI15gFStJV2Y/2dsb2JhbABZgkMhIlJYBIMBxUoBhBoCHIEBFgEBAQEBfYQCAQEBBCMKTBACAQgRBAEBCx0DAgICHxEUCQgCBA4FCIghAxIBwByQcw2FXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReOMIIFMQYBgnEzgR4FjhqBdohYj22GHYN5b4FFgQABAQE X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208,217";a="377566840" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 04 Dec 2014 15:14:52 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB4FEpqf031015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 15:14:51 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 09:14:51 -0600 From: "Nobo Akiya (nobo)" To: Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6shW/jisJENECZQt8/kBXRdpxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYCAAFQ6AIAACIMAgAAA+ACAAADogP//un7wgAB4GYD//5u2QA== Date: Thu, 4 Dec 2014 15:14:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.136] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F5AE4AExmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OTCU74f_b44-0hoZA7J0YdVd8n0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:14:54 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943F5AE4AExmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W25vIGhhdCBvbiwgYnR3XQ0KDQpIaSBNYW5hdiwNCg0KSWYgd2hhdCB5b3Ugc2F5IGlzIHRoZSBv bmx5IHJlcXVpcmVtZW50IG5vdCBtZXQsIG9uZSBhcHByb2FjaCBtYXkgYmUgdG8gcHVyc3VlIGEg bm9uLXN0YW5kYXJkLXRyYWNrIGRvY3VtZW50IGRlc2NyaWJpbmcgc29tZSBzdWdnZXN0ZWQgaW1w bGVtZW50YXRpb24gdGVjaG5pcXVlcyB0byBsb2NhbGx5IHN0b3JlIFRYL1JYIHRpbWVzdGFtcC4N Cg0KR2l2ZW4gdGhhdCBlY2hvIGFwcHJvYWNoIHdpbGwgYmUgbGVzcyBhY2N1cmF0ZSBhbmQgZ2l2 ZW4gdGhhdCB3ZSBzZWVtIHRvIGJlIGhhdmluZyBkaWZmaWN1bHR5IGNvbnZlcmdpbmcsIEkgdGhv dWdodCBJ4oCZbGwgdGhyb3cgb3V0IGFub3RoZXIgaWRlYS4NCg0KVGhhbmtzIQ0KDQotTm9ibw0K DQpGcm9tOiBNYW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21dDQpTZW50 OiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgOTo1MyBBTQ0KVG86IE5vYm8gQWtpeWEgKG5v Ym8pDQpDYzogU2FudG9zaCBQIEs7IE1BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKTsgVmVuZ2Fk YSBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKTsgR3JlZ29yeSBNaXJza3k7IE1hcmMgQmluZGVy YmVyZ2VyOyBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQkZEIHN0YWJpbGl0eSBmb2xs b3ctdXAgZnJvbSBJRVRGLTkxDQoNCk5vYm8gLSBMb2NhbGx5IHN0b3JpbmcgVFgvUlggdGltZXN0 YW1wcyBpcyBub3QgaW50ZXJvcGVyYWJsZS4NCg0KQ2hlZXJzLCBNYW5hdg0KDQpPbiBUaHUsIERl YyA0LCAyMDE0IGF0IDc6MzAgUE0sIE5vYm8gQWtpeWEgKG5vYm8pIDxub2JvQGNpc2NvLmNvbTxt YWlsdG86bm9ib0BjaXNjby5jb20+PiB3cm90ZToNCkEgcXVpY2sgcXVlc3Rpb24gdG8gdW5kZXJz dGFuZCB3aGVyZSB3ZSBhcmUuDQoNCklmIHdlIGhhZDoNCg0KDQoxLiAgICAgIFN0YW5kYXJkaXph dGlvbiBvZiBOdWxsIEF1dGhlbnRpY2F0aW9uIChpLmUuLCBzZXF1ZW5jZSBudW1iZXJzKQ0KDQoy LiAgICAgIEltcGxlbWVudGF0aW9uIG9mIGxvY2FsIFRYL1JYIHRpbWVzdGFtcCBtZWNoYW5pc20g ZGVzY3JpYmVkIGJ5IE1hcmMgYmVsb3cNCg0KV2hhdCBhcmUgdGhlIGNvcmUgcmVxdWlyZW1lbnRz IHdoaWNoIGhhdmUgbm90IGJlZW4gc2F0aXNmaWVkPw0KDQpUaGFua3MhDQoNCi1Ob2JvDQoNClAu Uy4gTm8sIHRoZXJlIGlzIG5vIG5lZWQgdG8gc3RhbmRhcmRpemUgQkZEIGVjaG8gY29udGVudHMu DQoNCg0K --_000_CECE764681BE964CBE1DFF78F3CDD3943F5AE4AExmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W25vIGhh dCBvbiwgYnR3XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFuYXYsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB3aGF0IHlvdSBzYXkg aXMgdGhlIG9ubHkgcmVxdWlyZW1lbnQgbm90IG1ldCwgb25lIGFwcHJvYWNoIG1heSBiZSB0byBw dXJzdWUgYSBub24tc3RhbmRhcmQtdHJhY2sgZG9jdW1lbnQgZGVzY3JpYmluZyBzb21lIHN1Z2dl c3RlZCBpbXBsZW1lbnRhdGlvbiB0ZWNobmlxdWVzDQogdG8gbG9jYWxseSBzdG9yZSBUWC9SWCB0 aW1lc3RhbXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5HaXZlbiB0aGF0IGVjaG8gYXBwcm9hY2ggd2lsbCBiZSBsZXNz IGFjY3VyYXRlIGFuZCBnaXZlbiB0aGF0IHdlIHNlZW0gdG8gYmUgaGF2aW5nIGRpZmZpY3VsdHkg Y29udmVyZ2luZywgSSB0aG91Z2h0IEnigJlsbCB0aHJvdyBvdXQgYW5vdGhlciBpZGVhLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LU5vYm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW5hdiBCaGF0aWEg W21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIERlY2VtYmVyIDA0LCAyMDE0IDk6NTMgQU08YnI+DQo8Yj5Ubzo8L2I+IE5vYm8gQWtpeWEg KG5vYm8pPGJyPg0KPGI+Q2M6PC9iPiBTYW50b3NoIFAgSzsgTUFMTElLIE1VRElHT05EQSAobW11 ZGlnb24pOyBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiAodmVuZ2dvdmkpOyBHcmVnb3J5IE1pcnNr eTsgTWFyYyBCaW5kZXJiZXJnZXI7IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm9ibyAtIExv Y2FsbHkgc3RvcmluZyBUWC9SWCB0aW1lc3RhbXBzIGlzIG5vdCBpbnRlcm9wZXJhYmxlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2hlZXJzLCBNYW5hdjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgRGVjIDQsIDIwMTQgYXQgNzozMCBQTSwgTm9ibyBBa2l5YSAobm9ibykgJmx0OzxhIGhyZWY9 Im1haWx0bzpub2JvQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5vYm9AY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgcXVp Y2sgcXVlc3Rpb24gdG8gdW5kZXJzdGFuZCB3aGVyZSB3ZSBhcmUuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYg d2UgaGFkOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4xLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdGFuZGFyZGl6YXRpb24gb2YgTnVsbCBBdXRoZW50aWNh dGlvbiAoaS5lLiwgc2VxdWVuY2UgbnVtYmVycyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Mi48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SW1wbGVtZW50YXRpb24gb2YgbG9jYWwgVFgvUlggdGltZXN0YW1wIG1lY2hhbmlzbSBk ZXNjcmliZWQgYnkgTWFyYyBiZWxvdzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgYXJlIHRoZSBjb3JlIHJl cXVpcmVtZW50cyB3aGljaCBoYXZlIG5vdCBiZWVuIHNhdGlzZmllZD88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+LU5vYm88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QLlMuIE5vLCB0aGVyZSBp cyBubyBuZWVkIHRvIHN0YW5kYXJkaXplIEJGRCBlY2hvIGNvbnRlbnRzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6 My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CECE764681BE964CBE1DFF78F3CDD3943F5AE4AExmbalnx01ciscoc_-- From nobody Thu Dec 4 07:17:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB521AD3AF for ; Thu, 4 Dec 2014 07:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 mFMQsjFSh8f6 for ; Thu, 4 Dec 2014 07:17:09 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 13F6A1A0183 for ; Thu, 4 Dec 2014 07:17:09 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C6136C1E5; Thu, 4 Dec 2014 10:17:08 -0500 (EST) Date: Thu, 4 Dec 2014 10:17:08 -0500 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: BFD stability follow-up from IETF-91 Message-ID: <20141204151708.GA9458@pfrc> References: 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: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lbXCxEwPOKNXCwVmnr8Grz4TozI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:17:10 -0000 On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote: > If what you say is the only requirement not met, one approach may be to pursue a non-standard-track document describing some suggested implementation techniques to locally store TX/RX timestamp. > > Given that echo approach will be less accurate and given that we seem to be having difficulty converging, I thought I???ll throw out another idea. I think my biggest concern is that the echo approach has bidirectional packet loss possibilities. Async at least lets the receiver know about unidirectional packet loss. Of course, if your goal is to notify the sender that their packets are being lost, you need a backchannel anyway. I just don't know if we want that back channel to be bfd. - Jeff From nobody Thu Dec 4 07:20:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7F11AD40D for ; Thu, 4 Dec 2014 07:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 KQUzxRmq_R0A for ; Thu, 4 Dec 2014 07:01:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009831AD400 for ; Thu, 4 Dec 2014 07:01:55 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB824.namprd05.prod.outlook.com (10.141.244.146) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 15:01:32 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 4 Dec 2014 15:01:32 +0000 From: Santosh P K To: Gregory Mirsky , Mahesh Jethanandani Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAdgIAgARDtICAAFI2AIACTQCAgAE4tICAAHSogIAABUQAgACJ5+A= Date: Thu, 4 Dec 2014 15:01:32 +0000 Message-ID: References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(24454002)(51444003)(20776003)(2656002)(92726001)(99396003)(54606007)(40100003)(92566001)(46102003)(19609705001)(50986999)(64706001)(86362001)(54206007)(19580395003)(15202345003)(76176999)(15975445006)(19580405001)(54356999)(66066001)(93886004)(561944003)(21056001)(120916001)(122556002)(68736005)(31966008)(33656002)(87936001)(101416001)(97736003)(19625215002)(77096005)(62966003)(77156002)(19300405004)(107046002)(74316001)(76576001)(16236675004)(99286002)(95666004)(105586002)(106356001)(4396001)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB824; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CO2PR0501MB8231A4913DEB31323847CA8B3780CO2PR0501MB823na_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bPIrTmfMuWzofeCk_RsFY-LtbRs X-Mailman-Approved-At: Thu, 04 Dec 2014 07:20:28 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:02:01 -0000 --_000_CO2PR0501MB8231A4913DEB31323847CA8B3780CO2PR0501MB823na_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gR3JlZywNCiAgRGVidWdnaW5nIEJGRCBpcyBvbmUgb2YgdGhlIHVzZSBjYXNlLiBJIGFs c28gd2FudCB0byBicmluZyB1cCBvbmUgb2YgdGhlIHVzZSBjYXNlIHRoYXQgSmVmZiBzdWdnZXN0 ZWQgaW4gaGlzIGVhcmxpZXIgIG1haWwuIE9wZXJhdG9yIG1pZ2h0IE5PVCB3YW50IHRvIHJ1biBP QU0gd2hpY2ggZG9lcyBsb3NzIGFuZCBkZWxheSBtZWFzdXJlbWVudCBhbGwgdGhlIHRpbWUgZHVl IHRvIGl0cyBvdmVyaGVhZC4gV2l0aCB0aGUgZXh0ZW5zaW9uIHRvIEJGRCAoc2VxdWVuY2UgbnVt YmVyKSB3ZSBjYW4gZGV0ZWN0IGlmIHRoZXJlIGlzIGFueSBsb3NzIGJ1dCBCRkQgc3RpbGwgc3Rh eXMgdXAuIFRoaXMgbG9zcyBkZXRlY3Rpb24gY2FuIGJlIHVzZWQgYXMgYSB0cmlnZ2VyIGZvciBs b3NzIGFuZCBkZWxheSBtZWFzdXJlbWVudC4gRWNobyBjYW4gYmUgdXNlZCBvbmx5IGluIGNhc2Ug b2Ygc2luZ2xlaG9wIGFuZCBpbiBvbmUgZGlyZWN0aW9uIG9ubHkuDQoNClRoYW5rcw0KU2FudG9z aCBQIEsNCg0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEdyZWdvcnkgTWlyc2t5DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMDQs IDIwMTQgMTI6MTIgUE0NClRvOiBNYWhlc2ggSmV0aGFuYW5kYW5pDQpDYzogcnRnLWJmZEBpZXRm Lm9yZw0KU3ViamVjdDogUkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0K DQpIaSBNYWhlc2gsDQppbmRlZWQsIExTUCBQaW5nIGlzIHBhcnQgb2YgTVBMUyBPQU0gdG9vbCBz ZXQgYXMgQkZEIGl0c2VsZiB0aGF0IGludGVuZGVkIHRvIG1vbml0b3Igb3BlcmF0aW9uYWwgc3Rh dGUgb2YgdGhlIG5ldHdvcmssIHBhdGggY29udGludWl0eSBiZXR3ZWVuIHR3byBub2Rlcy4gQW5k IExTUCBQaW5nLCBhcyBwcmltYXJpbHkgb24tZGVtYW5kIHRyb3VibGVzaG9vdGluZyB0b29sLCBo ZWxwcyBsb2NhbGl6ZSBhbmQsIHRvIGNlcnRhaW4gZGVncmVlLCBkaWFnbm9zZSB0aGUgcHJvYmxl bS4gQnV0IHRoZSB1bHRpbWF0ZSBkZWJ1Z2dpbmcgaXMgcHJvcHJpZXRhcnkuIFRoaXMgcHJvcG9z YWwsIGluIG15IHZpZXcsIGhlbHBzIG5vdCBtb25pdG9yIGJlaGF2aW9yIG9mIHRoZSBuZXR3b3Jr IGJ1dCBCRkQgaXRzZWxmLCBxdWFsaXR5IG9mIEJGRCBpbXBsZW1lbnRhdGlvbi4gSeKAmW0gbm90 IHNheWluZyB0aGF0IGl0IGlzIG5vdCB1c2VmdWwgZm9yIGltcGxlbWVudGVycyBhbmQgb3BlcmF0 b3JzLCBvbmUgY2FuIGZpbmQgdGhhdCB0b28gbWFueSBCRkQgc2Vzc2lvbnMgb3IgYXQgdG9vIHNo b3J0IGludGVydmFscyBiZWluZyAgcmFuLiBJIGRvbuKAmXQgYWdyZWUgdG8gbG9hZGluZyB0aGlz IGFzIGV4dGVuc2lvbiBvZiB0aGUgd2lkZWx5IHVzZWQgc3RhbmRhcmQuIFBlcmhhcHMgd2UgY2Fu IGxvb2sgaW50byB1c2luZyBCRkQgRWNobyBhcyBzZWxmLWRlYnVnZ2luZyBpbnN0cnVtZW50Lg0K DQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgR3JlZw0KDQpGcm9tOiBNYWhlc2ggSmV0aGFuYW5kYW5pIFttYWlsdG86bWpldGhhbmFuZGFu aUBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDAzLCAyMDE0IDEwOjIzIFBN DQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBGYW4sIFBlbmc7IE1BTExJSyBNVURJR09OREEgKG1t dWRpZ29uKTsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KR3JlZywNCg0K SSBiZWxpZXZlIHdlIGhhdmUgYSBkaXNhZ3JlZW1lbnQgaGVyZS4gSSBkbyBub3QgYmVsaWV2ZSB0 aGF0IGlzc3VlIG9mIGRlYnVnIGFiaWxpdHkgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIGEgc3Rh bmRhcmRpemVkIHByb3RvY29sLg0KDQpMb29rIGF0IE1QTFMgcGluZyBhbmQgdHJhY2Vyb3V0ZSAo UkZDIDQzNzkpIC4gVGhleSBhcmUgdWx0aW1hdGVseSBkZWJ1ZyB0b29scyB1c2VkIHRvIGVzdGFi bGlzaCB2aWFiaWxpdHkgb2YgYSBwYXRoIGFuZCB0aGV5IGFyZSB2ZXJ5IG11Y2ggcGFydCBvZiB0 aGUgc3RhbmRhcmRpemVkIHByb3RvY29sLg0KDQpPbiBEZWMgMywgMjAxNCwgYXQgMzoyNSBQTSwg R3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpIE1haGVzaCwNCkkgY29uc2lkZXIg aXNzdWVzIG9mIGRlYnVnYWJpbGl0eSwgbm90IG9mIGp1c3QgQkZEIGJ1dCBhbnkgb3RoZXIgc3Rh bmRhcmRpemVkIHByb3RvY29sLCB0byBiZSBvdXRzaWRlIG9mIFN0YW5kYXJkIHRyYWNrLCBhdCBt b3N0IHRvIGJlIHN1aXRhYmxlIGZvciBJbmZvcm1hdGlvbmFsIG9yIEV4cGVyaW1lbnRhbCB0cmFj ay4gSWYgd2UgYWdyZWUgb24gdGhhdCwgdGhlbiB3ZSBjYW4gZGlzY3VzcyBzY2VuYXJpb3MgdGhh dCBwcmVzZW50IHByb2JsZW0gYW5kIGludmVzdGlnYXRlIHdoZXRoZXIgYW55dGhpbmcgaW4gdGhl IHByb3RvY29sIHJlcXVpcmVzIGNsYXJpZmljYXRpb24gdG8gaGVscCB2ZW5kb3JzIGluIGJ1aWxk aW5nIHdlbGwtcGVyZm9ybWluZywgc2NhbGFibGUgYW5kIGludGVyb3BlcmFibGUgaW1wbGVtZW50 YXRpb25zIGFuZCBwcm92aWRlIG9wZXJhdGlvbmFsIGd1aWRlbGluZXMgZm9yIG9wZXJhdG9ycy4N Cg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEdyZWcNCg0KRnJvbTogTWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDIsIDIwMTQgODo0NiBQTQ0K VG86IEdyZWdvcnkgTWlyc2t5DQpDYzogRmFuLCBQZW5nOyBNQUxMSUsgTVVESUdPTkRBIChtbXVk aWdvbik7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkdyZWcsDQoNCldo YXQgaXMgUGVuZyByZWZlcnJpbmcgdG8gaXMgYSB3YXkgdG8gZmlndXJlIG91dCB3aHkgYSBwYXJ0 aWN1bGFyIEJGRCBzZXNzaW9uIGZsYXBwZWQsIHBhcnRpY3VsYXJseSBpZiB0aGUgcGFja2V0KHMp IGZvciB0aGF0IHNlc3Npb24gYXJyaXZlIGxhdGUuIEkgZG8gbm90IHNlZSBob3cgdGhhdCBjYW4g YmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQuIEl0IGlzIGJhc2ljIEJGRCBkZWJ1ZyBhYmlsaXR5 LiBSdW5uaW5nIGEgc2VwYXJhdGUgRE0gZG9lcyB0ZWxsIHlvdSB3aHkgYSBwYXJ0aWN1bGFyIEJG RCBzZXNzaW9uIGZsYXBwZWQuDQoNCk5vdyB3ZSBjYW4gZGViYXRlIHdoYXQgbWV0aG9kcyBjYW4g YmUgZW1wbG95ZWQgdG8gbWVhc3VyZSB0aGF0IGRlbGF5IGFuZCBJIGFtIG9wZW4gdG8gd2F5cyB0 byBkb2luZyBpdCwgaW5jbHVkaW5nIGxvY2FsIGxvb3BiYWNrIHRvIG1lYXN1cmUgdHJhbnNtaXQg ZGVsYXlzIG9yIHRpbWUgc3RhbXBpbmcgb2YgcGFja2V0cyBpbiBoYXJkd2FyZS4gQnV0IGluIGNh c2VzLCB3aGVyZSB0aGVyZSBpcyBubyBzdXBwb3J0IGZvciBlaXRoZXIgb2YgdGhlIGNhcGFiaWxp dGllcywgb25lIG9mIHRoZSBzdWdnZXN0ZWQgc29sdXRpb25zIGlzIHRvIHVzZSB0aGUgdGltZSBz dGFtcHMgY2FycmllZCBpbiB0aGUgQkZEIHBheWxvYWQuDQoNCkNoZWVycy4NCg0KT24gRGVjIDEs IDIwMTQsIGF0IDk6MzggQU0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nv bi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSBQ ZW5nLA0KYW5kIHN0aWxsLCB5b3XigJlyZSBsb29raW5nIGZvciBhIHRvb2wgdG8gbWVhc3VyZSBC RkQgcGVyZm9ybWFuY2UuIFRoZW4geW914oCZbGwgYmUgbG9va2luZyBmb3IgYSB0b29sIHRvIHZl cmlmeSB0aGUgQkZEIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LCBhbmQgb24sIGFuZCBvbi4gT3Bl cmF0b3JzIGRvIG5lZWQgY29tcGxldGUgc2V0IG9mIEZDQVBTIHRvb2xzLCBpbmNsdWRpbmcgcGVy Zm9ybWFuY2UgbWVhc3VyZW1lbnQuIE5vdGUgdGhhdCBwYXNzaXZlIHBlcmZvcm1hbmNlIG1lYXN1 cmVtZW50IHRocm91Z2ggbWFya2luZyBtZXRob2QgdGhhdCBNYWNoIENoZW4gcmVmZXJyZWQgdG8g Y2FuIG1vbml0b3IgQkZEIGZsb3cocykgYW5kIGJlIHVzZWQgdG8gZG8gTG9zcyBhbmQvb3IgRGVs YXkgTWVhc3VyZW1lbnQuIEFuZCBhY3RpdmUgU3ludGhldGljIExvc3MgTWVhc3VyZW1lbnQgbWF5 IHNpbXVsYXRlIGZsb3cgb2Ygc21hbGwgcGFja2V0cyBhcyB3ZWxsIGFzIHJlbGF0aXZlbHkgbGFy Z2UgcGFja2V0cy4gQW5kIHRoZSBzYW1lIGdvZXMgZm9yIGFjdGl2ZSBtZWFzdXJlbWVudCBtZXRo b2Qgb2YgRGVsYXkgTWVhc3VyZW1lbnQuIEkgbGlrZSBTd2lzcyBBcm15IGtuaXZlcyBidXQgbGV0 IHVzIG5vdCB0dXJuIEJGRCBpbnRvIG9uZS4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogRmFuLCBQZW5nIFtt YWlsdG86ZmFucGVuZ0BjaGluYW1vYmlsZS5jb21dDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDAx LCAyMDE0IDQ6NDQgQU0NClRvOiBHcmVnb3J5IE1pcnNreTsgJ01BTExJSyBNVURJR09OREEgKG1t dWRpZ29uKSc7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIEdyZWdv cnksDQoNCkkgd2FzIGp1c3QgZ2l2aW5nIGFuIGV4YW1wbGUgOikgQXBwbGljYXRpb24gdHJhZmZp YyB1c3VhbGx5IGNhbm5vdCBzdGFuZCBzbWFsbCBwYWNrZXQgbG9zcywgbm90IHRvIHNheSAzMCUg bG9zcy4NCg0KSSBhbSBhY3R1YWxseSBhc2tpbmcgZm9yIGEgZGVidWcgZnVuY3Rpb24gdGhhdCBj b3VsZCBnaXZlIHVzIHNvbWUgdXNlZnVsIGhpbnRzIG9mIHBvb3IgY29ubmVjdGlvbiB3aXRoIHNt YWxsIHByb3RvY29sIGNoYW5nZSwgYmVzaWRlcyB0aGUgYmFzaWMgY29ubmVjdGl2aXR5IGluZm9y bWF0aW9uLiBJZiBpdCBtZWFzdXJlcyBzb21ldGhpbmcsIGl0IG1lYXN1cmVzIHBhY2tldHMgb2Yg QkZEIGl0c2VsZi4gU28gSSBkb27igJl0IGV4cGVjdCBpdCB0byBiZSBjb25zaWRlcmVkIGFzIGEg cGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgdG9vbC4NCg0KQmVzdCByZWdhcmRzLA0KUGVuZw0KDQpG cm9tOiBHcmVnb3J5IE1pcnNreSBbbWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbV0N ClNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAyOSwgMjAxNCAzOjM3IEFNDQpUbzogRmFuLCBQZW5n OyAnTUFMTElLIE1VRElHT05EQSAobW11ZGlnb24pJzsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86 cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBm cm9tIElFVEYtOTENCg0KSGkgUGVuZywNCnRoaXMgaXMgdmVyeSBpbnRlcmVzdGluZyBzY2VuYXJp by4gSSB0aGluayB0aGF0IGlmIEJGRCBleHBlcmllbmNlcyB+MzAlIHBhY2tldCBsb3NzLCB0aGVu IGhpZ2hseSBsaWtlbHkgc28gYXJlIGFmZmVjdGVkIG90aGVyIGFwcGxpY2F0aW9ucy4gVGhlbiBp dCBpcyBub3QganVzdCBCRkQgaXNzdWUgYnV0IGNvbmRpdGlvbiB0aGF0IHNob3VsZCBiZSBkZXRl Y3RlZCAgYnkgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgbWV0aG9kLCB3aGV0aGVyIGFjdGl2ZSBv ciBwYXNzaXZlIHBhY2tldCBsb3NzIG1lYXN1cmVtZW50Lg0KSeKAmW0gY29udmluY2VkIHRoYXQg b3ZlcmxvYWRpbmcgQkZEIHdpdGggcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgcHJvdmlzaW9ucyBp cyBjb3VudGVyLXByb2R1Y3RpdmUgYW5kIGlzIGluYXBwcm9wcmlhdGUuDQoNCiAgICAgICAgICAg ICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZy b206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBGYW4sIFBlbmcNClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMjgsIDIwMTQgNDozNCBBTQ0KVG86 ICdNQUxMSUsgTVVESUdPTkRBIChtbXVkaWdvbiknOyBydGctYmZkQGlldGYub3JnPG1haWx0bzpy dGctYmZkQGlldGYub3JnPg0KU3ViamVjdDogUkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZy b20gSUVURi05MQ0KDQpIaSBNYWxsaWssDQoNCkV4YWN0bHkuIFBhY2tldHMgbWF5IGJlIGV4cGVy aWVuY2luZyBzbGlnaHQgbG9zcywgYnV0IHRoZSBsaW5rIGNhbiBoYXJkbHkgYmUgcmVnYXJkZWQg YXMgY29ubmVjdGVkLiBNb3JlIGltcG9ydGFudGx5LCB0aGUgZXhwZXJpZW5jZSBvZiB1cHBlci1s ZXZlbCBhcHBsaWNhdGlvbnMgY2FuIGJlIGRlZ3JhZGVkIHNldmVyZWx5IChlLmcuIFRDUCB0cmFm ZmljIGlzIG5vdCBhYmxlIHRvIGdvIGZhc3QgaW4gZmFjZSBvZiBldmVuIHNtYWxsIGNvbnRpbnVv dXMgbG9zcykuIEJ1dCB3aGF0IGlmIG9uZSBCRkQgZnJhbWUgaXMgbG9zdCBldmVyeSB0aHJlZSBm cmFtZXM/IFRoZW4gdGhlIGxvc3MgcmF0ZSBpcyAzMCUgb24gYXZlcmFnZSwgd2hpY2ggaXMgYWxy ZWFkeSBhIHZlcnkgc2V2ZXJlIHZhbHVlLg0KDQpCZXN0IHJlZ2FyZHMsDQpQZW5nDQoNCkZyb206 IE1BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKSBbbWFpbHRvOm1tdWRpZ29uQGNpc2NvLmNvbV0N ClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMjgsIDIwMTQgNzo1MyBQTQ0KVG86IEZhbiwgUGVuZzsg cnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBC RkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGkgUGVuZywNCg0KSWYgdGhl IEJGRCBwYWNrZXRzIGFyZSBsb3N0LCBkb2VzbuKAmXQgdGhlIEJGRCBzZXNzaW9uIGdvIERPV04/ IEFyZSB5b3Ugc2F5aW5nIHRoYXQgcGFja2V0IGxvc3MgaXMgbm90IGJpZyBlbm91Z2ggdG8gbWFr ZSBCRkQgc2Vzc2lvbiBnbyBET1dOPw0KDQpUaGFua3MNCg0KUmVnYXJkcw0KTWFsbGlrDQoNCkZy b206IDxGYW4+LCBQZW5nIDxmYW5wZW5nQGNoaW5hbW9iaWxlLmNvbTxtYWlsdG86ZmFucGVuZ0Bj aGluYW1vYmlsZS5jb20+Pg0KRGF0ZTogRnJpZGF5LCAyOCBOb3ZlbWJlciAyMDE0IDQ6MjAgcG0N ClRvOiAicnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4iIDxydGctYmZk QGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBCRkQgc3Rh YmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGkgSmVmZiwgYWxsLA0KDQpJIGhhdmUg YmVlbiBmb2xsb3dpbmcgdGhpcyBzdGFiaWxpdHkgZXh0ZW5zaW9uIGZyb20gdGhlIGJlZ2lubmlu ZywgYW5kIGFzIGFuDQpvcGVyYXRvciBJIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGF0IHRoaXMg ZHJhZnQgZW5hYmxlcyB0aGUgImFkdmFuY2VkDQpmZWF0dXJlIiB3ZSBkZXNpcmUgZm9yIEJGRCB0 byBwcm92aWRlIGFkZGl0aW9uYWwgdXNlZnVsIGluZm9ybWF0aW9uIHRoYXQNCmhlbHBzIG9wZXJh dG9ycyB1bmRlcnN0YW5kIG5ldHdvcmsgaXNzdWVzLiBBIHJlbGV2YW50IHVzZSBjYXNlIGlzIGRl dGVjdGluZw0KbG9zc3kgb3IgInF1YXNpLWRpc2Nvbm5lY3RlZCIgbGlua3Mgb3IgbWVtYmVyIExB RyBsaW5rcy4gQW4gZXhhbXBsZSBvZiBzdWNoDQpzaXR1YXRpb24gd2UgZXhwZXJpZW5jZWQgd2Fz IGEgbG9vc2VseSBjb25uZWN0ZWQgZmliZXIgbGluayByZXN1bHRpbmcgaW4NCmNvbnRpbnVvdXMs IHNtYWxsIGFtb3VudCBvZiBwYWNrZXQgbG9zcy4gQkZEIGNvdWxkIGdldCB0aGUgaW5mb3JtYXRp b24gb2YNCmxvc3QgQkZEIGZyYW1lcyBvbiBzdWNoIHVuc3RhYmxlIGxpbmssIGFuZCBwcm9iYWJs eSByZXBvcnQgd2hlbiBhIHRhcmdldA0KbGV2ZWwgaXMgcmVhY2hlZCwgc2F5IGEgY2VydGFpbiBu dW1iZXIgb2YgZnJhbWVzIGFyZSBsb3N0IG92ZXIgYSBwZXJpb2Qgb3INCmFtb25nIGEgdG90YWwg bnVtYmVyIG9mIGZyYW1lcy4NCg0KQmVzdCByZWdhcmRzLA0KUGVuZw0KDQpNYWhlc2ggSmV0aGFu YW5kYW5pDQpDby1jaGFpciwgTkVUQ09ORiBXRw0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFp bHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQpDby1j aGFpciwgTkVUQ09ORiBXRw0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5h bmRhbmlAZ21haWwuY29tPg0KDQoNCg0K --_000_CO2PR0501MB8231A4913DEB31323847CA8B3780CO2PR0501MB823na_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsc2Fucy1zZXJpZjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30N CnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZl cnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IZWxsbyBHcmVnLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDsgRGVidWdnaW5nIEJGRCBpcyBvbmUgb2YgdGhlIHVzZSBjYXNlLiBJIGFs c28gd2FudCB0byBicmluZyB1cCBvbmUgb2YgdGhlIHVzZSBjYXNlIHRoYXQgSmVmZiBzdWdnZXN0 ZWQgaW4gaGlzIGVhcmxpZXIgJm5ic3A7bWFpbC4gT3BlcmF0b3IgbWlnaHQgTk9UIHdhbnQgdG8g cnVuIE9BTQ0KIHdoaWNoIGRvZXMgbG9zcyBhbmQgZGVsYXkgbWVhc3VyZW1lbnQgYWxsIHRoZSB0 aW1lIGR1ZSB0byBpdHMgb3ZlcmhlYWQuIFdpdGggdGhlIGV4dGVuc2lvbiB0byBCRkQgKHNlcXVl bmNlIG51bWJlcikgd2UgY2FuIGRldGVjdCBpZiB0aGVyZSBpcyBhbnkgbG9zcyBidXQgQkZEIHN0 aWxsIHN0YXlzIHVwLiBUaGlzIGxvc3MgZGV0ZWN0aW9uIGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dl ciBmb3IgbG9zcyBhbmQgZGVsYXkgbWVhc3VyZW1lbnQuIEVjaG8NCiBjYW4gYmUgdXNlZCBvbmx5 IGluIGNhc2Ugb2Ygc2luZ2xlaG9wIGFuZCBpbiBvbmUgZGlyZWN0aW9uIG9ubHkuICZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlNhbnRvc2ggUCBLICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJ0Zy1iZmQgW21haWx0bzpy dGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyZWdvcnkgTWly c2t5PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCAxMjoxMiBQ TTxicj4NCjxiPlRvOjwvYj4gTWFoZXNoIEpldGhhbmFuZGFuaTxicj4NCjxiPkNjOjwvYj4gcnRn LWJmZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogQkZEIHN0YWJpbGl0eSBmb2xs b3ctdXAgZnJvbSBJRVRGLTkxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIE1haGVzaCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+aW5kZWVkLCBMU1AgUGluZyBpcyBwYXJ0IG9mIE1QTFMgT0FNIHRvb2wgc2V0 IGFzIEJGRCBpdHNlbGYgdGhhdCBpbnRlbmRlZCB0byBtb25pdG9yIG9wZXJhdGlvbmFsIHN0YXRl IG9mIHRoZSBuZXR3b3JrLCBwYXRoIGNvbnRpbnVpdHkgYmV0d2VlbiB0d28gbm9kZXMuIEFuZA0K IExTUCBQaW5nLCBhcyBwcmltYXJpbHkgb24tZGVtYW5kIHRyb3VibGVzaG9vdGluZyB0b29sLCBo ZWxwcyBsb2NhbGl6ZSBhbmQsIHRvIGNlcnRhaW4gZGVncmVlLCBkaWFnbm9zZSB0aGUgcHJvYmxl bS4gQnV0IHRoZSB1bHRpbWF0ZSBkZWJ1Z2dpbmcgaXMgcHJvcHJpZXRhcnkuIFRoaXMgcHJvcG9z YWwsIGluIG15IHZpZXcsIGhlbHBzIG5vdCBtb25pdG9yIGJlaGF2aW9yIG9mIHRoZSBuZXR3b3Jr IGJ1dCBCRkQgaXRzZWxmLCBxdWFsaXR5IG9mIEJGRA0KIGltcGxlbWVudGF0aW9uLiBJ4oCZbSBu b3Qgc2F5aW5nIHRoYXQgaXQgaXMgbm90IHVzZWZ1bCBmb3IgaW1wbGVtZW50ZXJzIGFuZCBvcGVy YXRvcnMsIG9uZSBjYW4gZmluZCB0aGF0IHRvbyBtYW55IEJGRCBzZXNzaW9ucyBvciBhdCB0b28g c2hvcnQgaW50ZXJ2YWxzIGJlaW5nJm5ic3A7IHJhbi4gSSBkb27igJl0IGFncmVlIHRvIGxvYWRp bmcgdGhpcyBhcyBleHRlbnNpb24gb2YgdGhlIHdpZGVseSB1c2VkIHN0YW5kYXJkLiBQZXJoYXBz IHdlIGNhbiBsb29rIGludG8NCiB1c2luZyBCRkQgRWNobyBhcyBzZWxmLWRlYnVnZ2luZyBpbnN0 cnVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm Ij4gTWFoZXNoIEpldGhhbmFuZGFuaSBbPGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tIj5tYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgRGVjZW1iZXIgMDMsIDIwMTQgMTA6MjMgUE08YnI+DQo8Yj5Ubzo8 L2I+IEdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+Q2M6PC9iPiBGYW4sIFBlbmc7IE1BTExJSyBNVURJ R09OREEgKG1tdWRpZ29uKTsgPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPg0KcnRn LWJmZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEJGRCBzdGFiaWxpdHkg Zm9sbG93LXVwIGZyb20gSUVURi05MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkdyZWcsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGJlbGlldmUgd2UgaGF2ZSBhIGRpc2FncmVlbWVudCBoZXJlLiBJIGRvIG5vdCBi ZWxpZXZlIHRoYXQgaXNzdWUgb2YgZGVidWcgYWJpbGl0eSBhcmUgb3V0c2lkZSB0aGUgc2NvcGUg b2YgYSBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2sgYXQgTVBMUyBwaW5nIGFuZCB0cmFjZXJvdXRl IChSRkMgNDM3OSkgLiBUaGV5IGFyZSB1bHRpbWF0ZWx5IGRlYnVnIHRvb2xzIHVzZWQgdG8gZXN0 YWJsaXNoIHZpYWJpbGl0eSBvZiBhIHBhdGggYW5kIHRoZXkgYXJlIHZlcnkgbXVjaCBwYXJ0IG9m IHRoZSBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBEZWMgMywgMjAxNCwgYXQgMzoyNSBQTSwgR3Jl Z29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b20iPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkhpIE1haGVzaCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBj b25zaWRlciBpc3N1ZXMgb2YgZGVidWdhYmlsaXR5LCBub3Qgb2YganVzdCBCRkQgYnV0IGFueSBv dGhlciBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wsIHRvIGJlIG91dHNpZGUgb2YgU3RhbmRhcmQgdHJh Y2ssIGF0IG1vc3QgdG8gYmUgc3VpdGFibGUgZm9yIEluZm9ybWF0aW9uYWwNCiBvciBFeHBlcmlt ZW50YWwgdHJhY2suIElmIHdlIGFncmVlIG9uIHRoYXQsIHRoZW4gd2UgY2FuIGRpc2N1c3Mgc2Nl bmFyaW9zIHRoYXQgcHJlc2VudCBwcm9ibGVtIGFuZCBpbnZlc3RpZ2F0ZSB3aGV0aGVyIGFueXRo aW5nIGluIHRoZSBwcm90b2NvbCByZXF1aXJlcyBjbGFyaWZpY2F0aW9uIHRvIGhlbHAgdmVuZG9y cyBpbiBidWlsZGluZyB3ZWxsLXBlcmZvcm1pbmcsIHNjYWxhYmxlIGFuZCBpbnRlcm9wZXJhYmxl IGltcGxlbWVudGF0aW9ucyBhbmQNCiBwcm92aWRlIG9wZXJhdGlvbmFsIGd1aWRlbGluZXMgZm9y IG9wZXJhdG9ycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+TWFoZXNoDQogSmV0aGFuYW5k YW5pIFs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBEZWNlbWJlciAwMiwgMjAxNCA4OjQ2 IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5HcmVnb3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RmFuLCBQZW5nOyBNQUxMSUsgTVVESUdP TkRBIChtbXVkaWdvbik7DQo8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+cnRnLWJm ZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZy b20gSUVURi05MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWcsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aGF0IGlzIFBlbmcgcmVmZXJyaW5nIHRvIGlzIGEgd2F5IHRvIGZpZ3VyZSBvdXQgd2h5IGEgcGFy dGljdWxhciBCRkQgc2Vzc2lvbiBmbGFwcGVkLCBwYXJ0aWN1bGFybHkgaWYgdGhlIHBhY2tldChz KSBmb3IgdGhhdCBzZXNzaW9uIGFycml2ZSBsYXRlLiBJIGRvIG5vdCBzZWUgaG93IHRoYXQgY2Fu IGJlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LiBJdCBpcyBiYXNpYyBCRkQgZGVidWcgYWJpbGl0 eS4gUnVubmluZw0KIGEgc2VwYXJhdGUgRE0gZG9lcyB0ZWxsIHlvdSB3aHkgYSBwYXJ0aWN1bGFy IEJGRCBzZXNzaW9uIGZsYXBwZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdyB3ZSBj YW4gZGViYXRlIHdoYXQgbWV0aG9kcyBjYW4gYmUgZW1wbG95ZWQgdG8gbWVhc3VyZSB0aGF0IGRl bGF5IGFuZCBJIGFtIG9wZW4gdG8gd2F5cyB0byBkb2luZyBpdCwgaW5jbHVkaW5nIGxvY2FsIGxv b3BiYWNrIHRvIG1lYXN1cmUgdHJhbnNtaXQgZGVsYXlzIG9yIHRpbWUgc3RhbXBpbmcgb2YgcGFj a2V0cyBpbiBoYXJkd2FyZS4gQnV0IGluIGNhc2VzLCB3aGVyZSB0aGVyZSBpcyBubyBzdXBwb3J0 DQogZm9yIGVpdGhlciBvZiB0aGUgY2FwYWJpbGl0aWVzLCBvbmUgb2YgdGhlIHN1Z2dlc3RlZCBz b2x1dGlvbnMgaXMgdG8gdXNlIHRoZSB0aW1lIHN0YW1wcyBjYXJyaWVkIGluIHRoZSBCRkQgcGF5 bG9hZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gRGVjIDEsIDIwMTQsIGF0IDk6MzggQU0sIEdyZWdvcnkgTWly c2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L3NwYW4+ PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGkgUGVuZyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+YW5kIHN0aWxsLCB5b3XigJlyZSBsb29raW5nIGZvciBhIHRvb2wgdG8gbWVhc3Vy ZSBCRkQgcGVyZm9ybWFuY2UuIFRoZW4geW914oCZbGwgYmUgbG9va2luZyBmb3IgYSB0b29sIHRv IHZlcmlmeSB0aGUgQkZEIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LCBhbmQgb24sIGFuZCBvbi4N CiBPcGVyYXRvcnMgZG8gbmVlZCBjb21wbGV0ZSBzZXQgb2YgRkNBUFMgdG9vbHMsIGluY2x1ZGlu ZyBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudC4gTm90ZSB0aGF0IHBhc3NpdmUgcGVyZm9ybWFuY2Ug bWVhc3VyZW1lbnQgdGhyb3VnaCBtYXJraW5nIG1ldGhvZCB0aGF0IE1hY2ggQ2hlbiByZWZlcnJl ZCB0byBjYW4gbW9uaXRvciBCRkQgZmxvdyhzKSBhbmQgYmUgdXNlZCB0byBkbyBMb3NzIGFuZC9v ciBEZWxheSBNZWFzdXJlbWVudC4gQW5kIGFjdGl2ZQ0KIFN5bnRoZXRpYyBMb3NzIE1lYXN1cmVt ZW50IG1heSBzaW11bGF0ZSBmbG93IG9mIHNtYWxsIHBhY2tldHMgYXMgd2VsbCBhcyByZWxhdGl2 ZWx5IGxhcmdlIHBhY2tldHMuIEFuZCB0aGUgc2FtZSBnb2VzIGZvciBhY3RpdmUgbWVhc3VyZW1l bnQgbWV0aG9kIG9mIERlbGF5IE1lYXN1cmVtZW50LiBJIGxpa2UgU3dpc3MgQXJteSBrbml2ZXMg YnV0IGxldCB1cyBub3QgdHVybiBCRkQgaW50byBvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZhbiwNCiBQZW5nIFs8YSBocmVmPSJtYWlsdG86ZmFucGVu Z0BjaGluYW1vYmlsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpmYW5w ZW5nQGNoaW5hbW9iaWxlLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBEZWNlbWJlciAwMSwgMjAx NCA0OjQ0IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5HcmVnb3J5IE1pcnNreTsgJ01BTExJSyBNVURJR09OREEgKG1tdWRp Z29uKSc7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5ydGctYmZkQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IEJGRCBzdGFiaWxp dHkgZm9sbG93LXVwIGZyb20gSUVURi05MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBHcmVn b3J5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB3YXMg anVzdCBnaXZpbmcgYW4gZXhhbXBsZSA6KSBBcHBsaWNhdGlvbiB0cmFmZmljIHVzdWFsbHkgY2Fu bm90IHN0YW5kIHNtYWxsIHBhY2tldCBsb3NzLCBub3QgdG8gc2F5IDMwJSBsb3NzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbSBhY3R1YWxseSBhc2tp bmcgZm9yIGEgZGVidWcgZnVuY3Rpb24gdGhhdCBjb3VsZCBnaXZlIHVzIHNvbWUgdXNlZnVsIGhp bnRzIG9mIHBvb3IgY29ubmVjdGlvbiB3aXRoIHNtYWxsIHByb3RvY29sIGNoYW5nZSwgYmVzaWRl cyB0aGUgYmFzaWMgY29ubmVjdGl2aXR5IGluZm9ybWF0aW9uLg0KIElmIGl0IG1lYXN1cmVzIHNv bWV0aGluZywgaXQgbWVhc3VyZXMgcGFja2V0cyBvZiBCRkQgaXRzZWxmLiBTbyBJIGRvbuKAmXQg ZXhwZWN0IGl0IHRvIGJlIGNvbnNpZGVyZWQgYXMgYSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCB0 b29sLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCBy ZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Q ZW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmIj5HcmVnb3J5DQogTWlyc2t5IFs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJp Y3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86Z3JlZ29yeS5taXJz a3lAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TYXR1cmRheSwgTm92ZW1iZXIgMjksIDIwMTQg MzozNyBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+RmFuLCBQZW5nOyAnTUFMTElLIE1VRElHT05EQSAobW11ZGlnb24pJzs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Zy1i ZmRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogQkZEIHN0YWJpbGl0eSBmb2xs b3ctdXAgZnJvbSBJRVRGLTkxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFBlbmcsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoaXMgaXMgdmVyeSBp bnRlcmVzdGluZyBzY2VuYXJpby4gSSB0aGluayB0aGF0IGlmIEJGRCBleHBlcmllbmNlcyB+MzAl IHBhY2tldCBsb3NzLCB0aGVuIGhpZ2hseSBsaWtlbHkgc28gYXJlIGFmZmVjdGVkIG90aGVyIGFw cGxpY2F0aW9ucy4gVGhlbiBpdCBpcyBub3QganVzdA0KIEJGRCBpc3N1ZSBidXQgY29uZGl0aW9u IHRoYXQgc2hvdWxkIGJlIGRldGVjdGVkJm5ic3A7IGJ5IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50 IG1ldGhvZCwgd2hldGhlciBhY3RpdmUgb3IgcGFzc2l2ZSBwYWNrZXQgbG9zcyBtZWFzdXJlbWVu dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmW0g Y29udmluY2VkIHRoYXQgb3ZlcmxvYWRpbmcgQkZEIHdpdGggcGVyZm9ybWFuY2UgbWVhc3VyZW1l bnQgcHJvdmlzaW9ucyBpcyBjb3VudGVyLXByb2R1Y3RpdmUgYW5kIGlzIGluYXBwcm9wcmlhdGUu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPlJ0Zy1iZmQNCiBb PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhh bGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9i PkZhbiwgUGVuZzxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5GcmlkYXksIE5vdmVtYmVyIDI4LCAyMDE0IDQ6MzQgQU08YnI+ DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPidNQUxMSUsgTVVESUdPTkRBIChtbXVkaWdvbiknOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgTWFsbGlrLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+RXhhY3RseS4gUGFja2V0cyBtYXkgYmUgZXhwZXJpZW5jaW5n IHNsaWdodCBsb3NzLCBidXQgdGhlIGxpbmsgY2FuIGhhcmRseSBiZSByZWdhcmRlZCBhcyBjb25u ZWN0ZWQuIE1vcmUgaW1wb3J0YW50bHksIHRoZSBleHBlcmllbmNlIG9mIHVwcGVyLWxldmVsIGFw cGxpY2F0aW9ucw0KIGNhbiBiZSBkZWdyYWRlZCBzZXZlcmVseSAoZS5nLiBUQ1AgdHJhZmZpYyBp cyBub3QgYWJsZSB0byBnbyBmYXN0IGluIGZhY2Ugb2YgZXZlbiBzbWFsbCBjb250aW51b3VzIGxv c3MpLiBCdXQgd2hhdCBpZiBvbmUgQkZEIGZyYW1lIGlzIGxvc3QgZXZlcnkgdGhyZWUgZnJhbWVz PyBUaGVuIHRoZSBsb3NzIHJhdGUgaXMgMzAlIG9uIGF2ZXJhZ2UsIHdoaWNoIGlzIGFscmVhZHkg YSB2ZXJ5IHNldmVyZSB2YWx1ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+UGVuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssc2Fucy1zZXJpZiI+TUFMTElLDQogTVVESUdPTkRBIChtbXVkaWdvbikgWzxhIGhy ZWY9Im1haWx0bzptbXVkaWdvbkBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm1haWx0bzptbXVkaWdvbkBjaXNjby5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZyaWRheSwgTm92ZW1iZXIg MjgsIDIwMTQgNzo1MyBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RmFuLCBQZW5nOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlJlOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+SGkgUGVuZyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj5JZiB0aGUgQkZEIHBhY2tldHMgYXJlIGxvc3QsIGRvZXNu4oCZdCB0aGUgQkZEIHNl c3Npb24gZ28gRE9XTj8gQXJlIHlvdSBzYXlpbmcgdGhhdCBwYWNrZXQgbG9zcyBpcyBub3QgYmln IGVub3VnaCB0byBtYWtlIEJGRCBzZXNzaW9uIGdvIERPV04/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPk1hbGxpazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmx0O0ZhbiZndDssIFBlbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpmYW5wZW5nQGNoaW5hbW9i aWxlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZmFucGVuZ0BjaGluYW1vYmlsZS5j b208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RnJpZGF5LCAyOCBOb3ZlbWJlciAyMDE0IDQ6MjAg cG08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5ydGctYmZkQGlldGYub3JnPC9zcGFuPjwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5ydGctYmZkQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJFOiBCRkQg c3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEplZmYsIGFsbCw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JIGhhdmUgYmVlbiBmb2xsb3dpbmcg dGhpcyBzdGFiaWxpdHkgZXh0ZW5zaW9uIGZyb20gdGhlIGJlZ2lubmluZywgYW5kIGFzIGFuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+b3BlcmF0b3IgSSB3 b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhhdCB0aGlzIGRyYWZ0IGVuYWJsZXMgdGhlICZxdW90O2Fk dmFuY2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ZmVh dHVyZSZxdW90OyB3ZSBkZXNpcmUgZm9yIEJGRCB0byBwcm92aWRlIGFkZGl0aW9uYWwgdXNlZnVs IGluZm9ybWF0aW9uIHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj5oZWxwcyBvcGVyYXRvcnMgdW5kZXJzdGFuZCBuZXR3b3JrIGlzc3Vlcy4gQSByZWxl dmFudCB1c2UgY2FzZSBpcyBkZXRlY3Rpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5sb3NzeSBvciAmcXVvdDtxdWFzaS1kaXNjb25uZWN0ZWQmcXVvdDsg bGlua3Mgb3IgbWVtYmVyIExBRyBsaW5rcy4gQW4gZXhhbXBsZSBvZiBzdWNoPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+c2l0dWF0aW9uIHdlIGV4cGVyaWVu Y2VkIHdhcyBhIGxvb3NlbHkgY29ubmVjdGVkIGZpYmVyIGxpbmsgcmVzdWx0aW5nIGluPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Y29udGludW91cywgc21h bGwgYW1vdW50IG9mIHBhY2tldCBsb3NzLiBCRkQgY291bGQgZ2V0IHRoZSBpbmZvcm1hdGlvbiBv Zjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmxvc3QgQkZE IGZyYW1lcyBvbiBzdWNoIHVuc3RhYmxlIGxpbmssIGFuZCBwcm9iYWJseSByZXBvcnQgd2hlbiBh IHRhcmdldDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmxl dmVsIGlzIHJlYWNoZWQsIHNheSBhIGNlcnRhaW4gbnVtYmVyIG9mIGZyYW1lcyBhcmUgbG9zdCBv dmVyIGEgcGVyaW9kIG9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+YW1vbmcgYSB0b3RhbCBudW1iZXIgb2YgZnJhbWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5QZW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Dby1jaGFpciwgTkVUQ09ORiBX RzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5Dby1jaGFpciwgTkVUQ09ORiBXRzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CO2PR0501MB8231A4913DEB31323847CA8B3780CO2PR0501MB823na_-- From nobody Thu Dec 4 07:22:29 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3521AD41B for ; Thu, 4 Dec 2014 07:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 zzljETuYh640 for ; Thu, 4 Dec 2014 07:22:18 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD1A1AD419 for ; Thu, 4 Dec 2014 07:22:18 -0800 (PST) Received: by mail-oi0-f50.google.com with SMTP id a141so12548040oig.9 for ; Thu, 04 Dec 2014 07:22:17 -0800 (PST) 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:content-type; bh=j68hdx1dy+1FS22zrcBEfPeDor+1KQbYWUQMrnO1hKY=; b=lvSjhFcMInUBAo9MMNiraczs6ePrXPVgjHBDAQjay3DYuULfUei9EveWyD2vjjkCoc 0nruoj2il/eBvL3SZ9T+EPQVFcyDbVtxgN9OiUq50ui32uKzdrfNGq/uEg6Zp6BDHgtM ABsGBB+ZVVuB/ZTfybq96EC6XqrQPIbUJtUaCUx9ODZnidDnz28KlzRsZ9259msWDPz8 gLduPg0NkMC07mZ5ggwOou/hz7ZXMPCbSqC7KwGmvScwnSSHPJcgZw6tzCd4AJ9t0Jhr TDutc9Vn78iUM8jl02lfGZp+EszXYx8jPyE1RtiZspX5NSBzNu7Ibmkn2MBWd0n2b7vP QTKA== MIME-Version: 1.0 X-Received: by 10.202.69.137 with SMTP id s131mr1758434oia.103.1417706537702; Thu, 04 Dec 2014 07:22:17 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 07:22:17 -0800 (PST) In-Reply-To: References: Date: Thu, 4 Dec 2014 20:52:17 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=001a113dae32935ddc05096586f3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-aCvT0_cJtKAdwrZHY7CqjvaFbM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:22:24 -0000 --001a113dae32935ddc05096586f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nobo, The echo proposal doesnt make any sense. I thought the one with carrying some info as part of the the UDP or the IP payload made some. Having spent countless number of hours debugging a "BFD flap" i would definitely like to have a std-track mechanism that aids me in debugging the root cause. Cheers, Manav On Thu, Dec 4, 2014 at 8:44 PM, Nobo Akiya (nobo) wrote: > [no hat on, btw] > > > > Hi Manav, > > > > If what you say is the only requirement not met, one approach may be to > pursue a non-standard-track document describing some suggested > implementation techniques to locally store TX/RX timestamp. > > > > Given that echo approach will be less accurate and given that we seem to > be having difficulty converging, I thought I=E2=80=99ll throw out another= idea. > > > > Thanks! > > > > -Nobo > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Thursday, December 04, 2014 9:53 AM > *To:* Nobo Akiya (nobo) > *Cc:* Santosh P K; MALLIK MUDIGONDA (mmudigon); Vengada Prasad Govindan > (venggovi); Gregory Mirsky; Marc Binderberger; rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Nobo - Locally storing TX/RX timestamps is not interoperable. > > > > Cheers, Manav > > > > On Thu, Dec 4, 2014 at 7:30 PM, Nobo Akiya (nobo) wrote: > > A quick question to understand where we are. > > > > If we had: > > > > 1. Standardization of Null Authentication (i.e., sequence numbers) > > 2. Implementation of local TX/RX timestamp mechanism described by > Marc below > > > > What are the core requirements which have not been satisfied? > > > > Thanks! > > > > -Nobo > > > > P.S. No, there is no need to standardize BFD echo contents. > > > > > > --001a113dae32935ddc05096586f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nobo,

The echo proposal doesnt make = any sense. I thought the one with carrying some info as part of the the UDP= or the IP payload made some.

Having spent countle= ss number of hours debugging a "BFD flap" i would definitely like= to have a std-track mechanism that aids me in debugging the root cause.

Cheers, Manav
=
On Thu, Dec 4, 2014 at 8:44 PM, Nobo Akiya (= nobo) <nobo@cisco.com> wrote:

[no hat on, btw]

=C2=A0

Hi Manav,

=C2=A0

If what you say is the on= ly requirement not met, one approach may be to pursue a non-standard-track = document describing some suggested implementation techniques to locally store TX/RX timestamp.

=C2=A0

Given that echo approach = will be less accurate and given that we seem to be having difficulty conver= ging, I thought I=E2=80=99ll throw out another idea.

=C2=A0

Thanks!

=C2=A0

-Nobo

=C2=A0

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Thursday, December 04, 2014 9:53 AM
To: Nobo Akiya (nobo)
Cc: Santosh P K; MALLIK MUDIGONDA (mmudigon); Vengada Prasad Govinda= n (venggovi); Gregory Mirsky; Marc Binderberger; rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91

=C2=A0

Nobo - Locally storing TX/RX timestamps is not inter= operable.

=C2=A0

Cheers, Manav

=C2=A0

On Thu, Dec 4, 2014 at 7:30 PM, Nobo Akiya (nobo) &l= t;nobo@cisco.com>= ; wrote:

A quick question to under= stand where we are.

=C2=A0

If we had:<= u>

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Standardization of Null Authentication (i= .e., sequence numbers)

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Implementation of local TX/RX timestamp m= echanism described by Marc below

=C2=A0

What are the core require= ments which have not been satisfied?

=C2=A0

Thanks!<= /u>

=C2=A0

-Nobo

=C2=A0

P.S. No, there is no need= to standardize BFD echo contents.

=C2=A0

=C2=A0


--001a113dae32935ddc05096586f3-- From nobody Thu Dec 4 07:28:20 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1171AD435 for ; Thu, 4 Dec 2014 07:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 99CVofRRoRMp for ; Thu, 4 Dec 2014 07:28:13 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 6314B1AD434 for ; Thu, 4 Dec 2014 07:28:13 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-30-54802145fdcf Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 10.38.25146.54120845; Thu, 4 Dec 2014 09:54:29 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 10:28:06 -0500 From: Gregory Mirsky To: "Vengada Prasad Govindan (venggovi)" , Santosh P K , Marc Binderberger , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQDUqXQ6amXjPuFEmbPIOgLl4p2px+NluAgAAjMzCAAOz5gP//rP5ggACs1AD///JEgA== Date: Thu, 4 Dec 2014 15:28:05 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AABEE@eusaamb103.ericsson.se> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <20141201013841551442.5a9df5b9@sniff.de> <7347100B5761DC41A166AC17F22DF1121B8AA51B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AA9A5@eusaamb103.ericsson.se> <315041E4211CB84E86EF7C25A2AB583D347719A2@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D347719A2@xmb-rcd-x15.cisco.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonQddVsSHEYOcRFYvLk9rYLWZf+c9s 8fnPNkaLa3e3MlvM/LCJ2YHVY8rvjaweO2fdZfdYsuQnk8f1pqvsHq2ru1kCWKO4bFJSczLL Uov07RK4Mi7d389csLui4vKdWcwNjJfiuhg5OSQETCSe7LvFBGGLSVy4t56ti5GLQ0jgCKPE zq6n7BDOMkaJvfs/MIJUsQkYSbzY2AOWEBFYzyix+e9ssASzgKZE04nP7CC2sIChxKruxWC2 CFDDsRlzoewwifMT37CB2CwCKhIrj5wFinNw8Ar4SrzYGQ+xbC6HxIUjc1hBajiB4sv7NrGA 2IxA530/tYYJYpe4xK0n86HOFpBYsuc8M4QtKvHy8T9WCFtJ4uPv+ewQ9ToSC3Z/YoOwtSWW LXwNVs8rIChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtzECIyyYxJsjjsY F3yyPMQowMGoxMO7IbY+RIg1say4MvcQozQHi5I4r2b1vGAhgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjOIrBaJSpZL31sz5tq84wWXjZrlNxl3P3vgkr42cnuDvO38qy+LsByo3t+62zLky r4n9j9CxST9FF/at/G13+/1e9pyX4rNe2SRF/Y66v2jhl9DreqHLk069P80pFha4zVts2qX5 1nnvX4UcmJNk+ufKj/r0PyJnt7KWcbe+jFEy2d6489rcvFIlluKMREMt5qLiRACZAeeCkwIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/CE5a8A_pJBq1s4PLfHzge5ijA1k Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:28:17 -0000 Hi Prasad, true, though I'd say that BFD Echo is not defined in these configurations, = scenarios. Regards, Greg -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Thursday, December 04, 2014 3:15 AM To: Gregory Mirsky; Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Greg/ Santosh, It was my understanding that BFD Async was chosen for stability since the= re are configurations where BFD echo mode is not supported (e.g. Multi-hop,= BFD on LAGs and BFD over MPLS). Am I missing something here, please let me= know. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, December 04, 2014 11:44 AM To: Santosh P K; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, yes, the format and thus interpretation of payload in Echo mode is not defi= ned and that, in my view, is what we need - some open space. And Echo well = could be exactly that - no legacy, no backward compatibility (addressee tha= t doesn't support "extended Echo" will simply loop the packet back to sende= r). Perhaps that will be direction we can discuss and, hopefully, agree on. Regards, Greg -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Wednesday, December 03, 2014 9:54 PM To: Gregory Mirsky; Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Greg, I don't think we have discussed about echo in this context. Echo is good= thing but payload of BFD echo packet is decided by local system. Did you m= ean to add suggestion on how echo packet should look like? Or how echo can = help in BFD loss/delay issue?=20 Thanks Santosh P K =20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, December 04, 2014 2:22 AM > To: Santosh P K; Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Dear All, > had authors of the proposal or we already dismissed use of BFD Echo?=20 > I've scanned the thread and couldn't find trace of us discussing BFD=20 > Echo mode. I think that it is more suitable for experimentation and unort= hodox use. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P=20 > K > Sent: Wednesday, December 03, 2014 5:39 AM > To: Marc Binderberger; Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Hello Manav and Marc, >=20 >=20 > > > One way to solve this problem is by attaching a debug trailer that=20 > > > only carries the seq numbers at the *end* of the BFD packet. This=20 > > > would not be covered in the Length field carried in the BFD header=20 > > > but would be accounted for in the length carried in the IP header. > > > > BFD itself is not related to IP, i.e. there is not always an IP header. > > Sure, the encapsulating "frame" may provide a length but actually,=20 > > why not covering the debug trailer with the BFD length? > > > > If this is solely for debug purpose than this may work. For simple=20 > > copying-out into e.g. a packet trace buffer it would be even simpler=20 > > to have the BFD length covering the trailer. > > If hardware is supposed to process the trailer information (other=20 > > than copying out) then it's getting ugly - having fixed position,=20 > > fixed length extension headers would be preferable for simple access. >=20 > Fixed length would be easy to process in hardware. Problem is when we=20 > have many have extensions in future. If we want to use only one=20 > extension that is at the last then I will be forced to pad all the=20 > other extension ahead of it? This might not be a problem if we have=20 > fewer extensions but might become problem when there are too many extensi= ons. >=20 >=20 > > > > Another idea is to use the 0x80 bit of the auth type to distinguish=20 > > between a "normal" authentication header and a "sequence + > authentication". > > >=20 > I think this is good. In the BFD extension TLV we still have many=20 > reserved bits that can be used as well? >=20 > Thanks > Santosh P K >=20 >=20 >=20 > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > Hi Santosh, > > > > > > You could use the crypto sequence numbers carried in the=20 > > > meticulous cryptographic auth for detecting packet losses. > > > However, this breaks when you use non-meticulous crypto=20 > > > authentication since the sequence number is only incremented=20 > > > occasionally there. This i believe is a deal breaker since i=20 > > > really envision non meticulous mode to be the one being widely=20 > > > deployed. In fact we were supposed to write a draft on that and i=20 > > > guess it just fell through the cracks (lemme ping my co-author on=20 > > > that !) > > > > > > One way to solve this problem is by attaching a debug trailer that=20 > > > only carries the seq numbers at the *end* of the BFD packet. This=20 > > > would not be covered in the Length field carried in the BFD header=20 > > > but would be accounted for in the length carried in the IP header. > > > The concept of attaching a trailer is documented well and is used=20 > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The=20 > > > catch however is that this debug trailer will NOT be covered by=20 > > > the BFD authentication. Is this acceptable to the WG? > > > > > > I think the problem of diagnosing a BFD flap becomes all the more=20 > > > important with BFD authentication turned on since then we have=20 > > > more points where a delay can be inserted. > > > > > > Cheers, Manav > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K=20 > > > > > wrote: > > >> Manav, > > >> This is good question. > > >> > > >>> Can the authors add some text on how this debugging mechanism=20 > > >>> would work if somebody employs BFD authentication? > > >> > > >> Right now we have considered without authentication (we are=20 > > >> setting A bit). We should add some text on how we can use both=20 > > >> Auth and de bug > > TLV. > > >> Is there any suggestion you have? I will get back to you on this. > > >> > > >> > > >> Thanks > > >> Santosh P K > > >> > > >>>> -----Original Message----- > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > > >>>> Mach > > Chen > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > >>>> To: Marc Binderberger > > >>>> Cc: rtg-bfd@ietf.org > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>> > > >>>> Hi Marc, > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de] > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > >>>>> To: Mach Chen > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > >>>>> > > >>>>> Hello Mach, > > >>>>> > > >>>>>> This triggers me think out there should be another solution=20 > > >>>>>> for getting the Tx and Rx timestamps without encoding the=20 > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps=20 > > >>>>>> locally or send them to a centralized entity and then use the=20 > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>> > > >>>>> I remember some discussion on NVO3 about how many bits it=20 > > >>>>> takes > > >>>>> ;- > > ) - > > >>>>> could you send the links/draft names you are working on to this l= ist? > > >>>>> May be useful for further discussions. > > >>>> > > >>>> Sure, here is the > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > >>> based-ipfpm-framework-02) for the reference. > > >>>> > > >>>> But here I want to say is that since we have sequence number,=20 > > >>>> we may > > not > > >>> need the marking based solution. Suppose that someone want to > > monitor > > >>> the delay of a BFD packet , just record and save the timestamp=20 > > >>> at the Tx side, which indexed by the sequence number. Similarly,=20 > > >>> do the same at the Rx side. Then based on the timestamps from=20 > > >>> both Tx and Rx, and using the sequence number to correlate the=20 > > >>> timestamps, it can also provide a way > > to > > >>> monitor the delay of the BFD packet. > > >>>> > > >>>> That means, only if there is sequence number, even if without=20 > > >>>> carrying the > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > >>>> > > >>>> Best regards, > > >>>> Mach > > >>>> > > >>>>> > > >>>>> > > >>>>> Thanks & Regards, > > >>>>> Marc > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > >>>>>> Hi Marc and Manav, > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > Marc > > >>>>>>> Binderberger > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > >>>>>>> To: Manav Bhatia > > >>>>>>> Cc: rtg-bfd@ietf.org > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > >>>>>>> > > >>>>>>> Hello Manav, > > >>>>>>> > > >>>>>>>> I believe the work is important and addresses something=20 > > >>>>>>>> thats really required (spent too much time debugging why=20 > > >>>>>>>> BFD > > flapped!). > > >>>>>>> > > >>>>>>> agree :-) we should keep the discussion alive. > > >>>>>>> > > >>>>>>> > > >>>>>>>> side Time stamping would have helped in debugging whether > the > > >>> BFD > > >>>>>>>> packet was sent late, or whether the packet was sent on=20 > > >>>>>>>> time and also arrived on time but was delayed when passing=20 > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad=20 > > >>>>>>>> too > > >>>>>>>> long) > > >>>>>>> > > >>>>>>> well, I can see a point in having the Tx timestamps in the=20 > > >>>>>>> packet mainly for the purpose of knowing "this" packet was=20 > > >>>>>>> okay/not okay on the Tx side and to correlate it with your=20 > > >>>>>>> local Rx > measurement. > > >>>>>> > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > >>>>>> If allow to have Tx timestamps to be carried in the packets,=20 > > >>>>>> seems it should be no problem to leave a seat for the Rx=20 > > >>>>>> timestamps as well :-). After all, with both Tx and Rx=20 > > >>>>>> timestamp, it may simplify the > > >>>>> implementation. > > >>>>>> > > >>>>>>> > > >>>>>>> And even this point is less relevant with sequence numbers=20 > > >>>>>>> as this number allows the identification of packets and thus=20 > > >>>>>>> the correlation of information from the Tx and Rx system. > > >>>>>> > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > between > > >>>>>> the Tx and Rx system. > > >>>>>> > > >>>>>> This triggers me think out there should be another solution=20 > > >>>>>> for getting the Tx and Rx timestamps without encoding the=20 > > >>>>>> timestamps > > in > > >>>>>> the BFD > > >>>>> packets. > > >>>>>> For example, the Tx and Rx systems could just save timestamps=20 > > >>>>>> locally or send them to a centralized entity and then use the=20 > > >>>>>> sequence numbers to correlate them for further analyzing. > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Mach > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Regards, Marc > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > >>>>>>>> Hi Jeff, > > >>>>>>>> > > >>>>>>>> I vividly remember the original intent of the stability=20 > > >>>>>>>> draft was to help debug BFD failures -- to isolate the=20 > > >>>>>>>> issue at the RX or the TX side Time stamping would have=20 > > >>>>>>>> helped in debugging > > whether > > >>>>>>>> the BFD packet was sent late, or whether the packet was=20 > > >>>>>>>> sent on time and also arrived on time but was delayed when=20 > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer=20 > > >>>>>>>> for tad too long), etc. But then time stamping came with=20 > > >>>>>>>> its own set of issues, and was hence dropped from the original= draft. > > >>>>>>>> > > >>>>>>>> Can the authors send a summary on the list on why time=20 > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > >>>>>>>> > > >>>>>>>> The current proposal does help but is not complete. > > >>>>>>>> > > >>>>>>>> Assume that the RX end loses a BFD session and learns later=20 > > >>>>>>>> that it did eventually receive the missing BFD packets=20 > > >>>>>>>> (based on the > > seq > > >>> #). > > >>>>>>>> How would it know which end was misbehaving? Was it a delay=20 > > >>>>>>>> at the TX side, or was it the RX that delayed passing the=20 > > >>>>>>>> packets to the BFD process(or). This is usually what we=20 > > >>>>>>>> want to debug and i want to understand how this draft with=20 > > >>>>>>>> sequence numbers can unequivocally tell me that. > > >>>>>>>> > > >>>>>>>> I believe the work is important and addresses something=20 > > >>>>>>>> thats really required (spent too much time debugging why=20 > > >>>>>>>> BFD > > flapped!). > > >>>>>>>> Clearly what would help is putting a small section that=20 > > >>>>>>>> describes how we can use the sequence numbers to debug > what > > >>>>>>>> and > > where > > >>> things went wrong. > > >>>>>>>> > > >>>>>>>> Cheers, Manav > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas=20 > > >>>>>>>> > > >>> wrote: > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > >>>>>>>>> > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > >>>>>>>>> pp > > >>>>>>>>> tx > > >>>>>>>>> > > >>>>>>>>> To attempt to simplify the presentation, the contentious=20 > > >>>>>>>>> portion of the timers were removed from the proposal,=20 > > >>>>>>>>> leaving only the sequence numbering for detecting loss of=20 > > >>>>>>>>> BFD > async packets. > > >>>>>>>>> > > >>>>>>>>> When the room was polled to see whether the draft should=20 > > >>>>>>>>> be adopted as a WG item, the sense of the room was very quiet= . > > >>>>>>>>> As promised, this is to inquire for support for this draft=20 > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > voice. > > >>>>>>>>> > > >>>>>>>>> It should be noted that post-meeting discussion on the=20 > > >>>>>>>>> fate of this draft noted that BFD authentication code=20 > > >>>>>>>>> points are plentiful and are available with expert review. > > >>>>>>>>> Should the draft authors wish to continue this work as=20 > > >>>>>>>>> Experimental, that is > > an > > >>> option. > > >>>>>>>>> > > >>>>>>>>> -- Jeff > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > From nobody Thu Dec 4 07:42:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26FA1AD443 for ; Thu, 4 Dec 2014 07:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 lRS1JKxGf2_z for ; Thu, 4 Dec 2014 07:40:21 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 A09871AD3F9 for ; Thu, 4 Dec 2014 07:40:20 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-f1-548024213e01 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B6.19.25146.12420845; Thu, 4 Dec 2014 10:06:41 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 10:39:59 -0500 From: Gregory Mirsky To: Santosh P K , Mahesh Jethanandani Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAjSUAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAF9PggASh4oD///wSUIACoyWAgADg8VCAAMxrgP//rMkggADkGwD//7U6cA== Date: Thu, 4 Dec 2014 15:39:58 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@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_7347100B5761DC41A166AC17F22DF1121B8AAC0Deusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZXLonSldRpSHEYMIWLYvTb9axWXz+s43R 4trdrcwOzB47Z91l91iy5CeTx/Wmq+wBzFFcNimpOZllqUX6dglcGY03NzAVvLjOXHF4Uh9r A+OJ08xdjJwcEgImEk/P/mOCsMUkLtxbz9bFyMUhJHCEUeLyvltgRUICyxglvk+JALHZBIwk XmzsYe9i5OAQEYiQOHItGSTMLKAp0XTiMzuILSxgKLGqezGYLQJUfmzGXHaQmSIgYxYd7GUB SbAIqEgsXzUdzOYV8JW40j0JavE0VokD79+AJTgF4iUmr/vNBmIzAl33/dQaJoht4hK3nsyH ulpAYsme81DfiEq8fPyPFcJWkvj4ez47RH2+xO9VZ5khlglKnJz5hGUCo+gsJKNmISmbhaRs FtCfIM+t36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYwcpcWpZbnpRoabGIHRdkyCzXEH44JP locYBTgYlXh4N8TWhwixJpYVV+YeYpTmYFES59WsnhcsJJCeWJKanZpakFoUX1Sak1p8iJGJ g1OqgVH9ySbOlFMaSRteGlSXpDyqiXq9fGK/+urFKX+CNO8frD6/3s1Z1uAs69/WpIAWT8HM q+HHzCMiQ5h6JLhuH98REOp+sn7twZKD6X8ffsp5w1D24/SaXzoFt6MuroozqAm3dnr94caM e6syUvb6zosXy/roOGXdoXc1C6fckeS98OzQs/kNzY1KLMUZiYZazEXFiQA4vihMlwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5QOWTQw6IiWbc2au4Ovu_Euvy6g X-Mailman-Approved-At: Thu, 04 Dec 2014 07:42:41 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:40:26 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AAC0Deusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FudG9zaCwNCmJ1dCB0aGF0IGlzIHdoYXQgY2FuIGJlIGNhbGxlZCDigJxmZWF0dXJlIGNy ZWVw4oCdLiBCRkQgaXMgY29udGludWl0eSBjaGVjayBtZWNoYW5pc20gYW5kIGZvciBhY3RpdmUg cGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQsIGV2ZW4gb2NjYXNpb25hbCwgdGhlcmUgYXJlIFRXQU1Q IGluIElQIGFuZCBSRkMgNjM3NC82Mzc1IGluIE1QTFMvTVBMUy1UUC4gSXQgbWF5IGJlIHRlbXB0 aW5nIHRvIGV4cGFuZCBzY29wZSBvZiBCRkQgYnV0LCBJIGJlbGlldmUsIGl0IGlzIHN1Y2Nlc3Nm dWwgZXhhY3RseSBiZWNhdXNlIGl0IHdhcyBzaW1wbGUsIGxpZ2h0LXdlaWdodCBhbmQgZGVzaWdu ZWQgdG8gZG8gZXhhY3RseSBvbmUgdGhpbmcg4oCTIGNvbnRpbnVpdHkgY2hlY2suDQoNCiAgICAg ICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVn DQoNCkZyb206IFNhbnRvc2ggUCBLIFttYWlsdG86c2FudG9zaHBrQGp1bmlwZXIubmV0XQ0KU2Vu dDogVGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDc6MDIgQU0NClRvOiBHcmVnb3J5IE1pcnNr eTsgTWFoZXNoIEpldGhhbmFuZGFuaQ0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGVsbG8gR3JlZywNCiAg RGVidWdnaW5nIEJGRCBpcyBvbmUgb2YgdGhlIHVzZSBjYXNlLiBJIGFsc28gd2FudCB0byBicmlu ZyB1cCBvbmUgb2YgdGhlIHVzZSBjYXNlIHRoYXQgSmVmZiBzdWdnZXN0ZWQgaW4gaGlzIGVhcmxp ZXIgIG1haWwuIE9wZXJhdG9yIG1pZ2h0IE5PVCB3YW50IHRvIHJ1biBPQU0gd2hpY2ggZG9lcyBs b3NzIGFuZCBkZWxheSBtZWFzdXJlbWVudCBhbGwgdGhlIHRpbWUgZHVlIHRvIGl0cyBvdmVyaGVh ZC4gV2l0aCB0aGUgZXh0ZW5zaW9uIHRvIEJGRCAoc2VxdWVuY2UgbnVtYmVyKSB3ZSBjYW4gZGV0 ZWN0IGlmIHRoZXJlIGlzIGFueSBsb3NzIGJ1dCBCRkQgc3RpbGwgc3RheXMgdXAuIFRoaXMgbG9z cyBkZXRlY3Rpb24gY2FuIGJlIHVzZWQgYXMgYSB0cmlnZ2VyIGZvciBsb3NzIGFuZCBkZWxheSBt ZWFzdXJlbWVudC4gRWNobyBjYW4gYmUgdXNlZCBvbmx5IGluIGNhc2Ugb2Ygc2luZ2xlaG9wIGFu ZCBpbiBvbmUgZGlyZWN0aW9uIG9ubHkuDQoNClRoYW5rcw0KU2FudG9zaCBQIEsNCg0KRnJvbTog UnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdy ZWdvcnkgTWlyc2t5DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MTIgUE0N ClRvOiBNYWhlc2ggSmV0aGFuYW5kYW5pDQpDYzogcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRn LWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9t IElFVEYtOTENCg0KSGkgTWFoZXNoLA0KaW5kZWVkLCBMU1AgUGluZyBpcyBwYXJ0IG9mIE1QTFMg T0FNIHRvb2wgc2V0IGFzIEJGRCBpdHNlbGYgdGhhdCBpbnRlbmRlZCB0byBtb25pdG9yIG9wZXJh dGlvbmFsIHN0YXRlIG9mIHRoZSBuZXR3b3JrLCBwYXRoIGNvbnRpbnVpdHkgYmV0d2VlbiB0d28g bm9kZXMuIEFuZCBMU1AgUGluZywgYXMgcHJpbWFyaWx5IG9uLWRlbWFuZCB0cm91Ymxlc2hvb3Rp bmcgdG9vbCwgaGVscHMgbG9jYWxpemUgYW5kLCB0byBjZXJ0YWluIGRlZ3JlZSwgZGlhZ25vc2Ug dGhlIHByb2JsZW0uIEJ1dCB0aGUgdWx0aW1hdGUgZGVidWdnaW5nIGlzIHByb3ByaWV0YXJ5LiBU aGlzIHByb3Bvc2FsLCBpbiBteSB2aWV3LCBoZWxwcyBub3QgbW9uaXRvciBiZWhhdmlvciBvZiB0 aGUgbmV0d29yayBidXQgQkZEIGl0c2VsZiwgcXVhbGl0eSBvZiBCRkQgaW1wbGVtZW50YXRpb24u IEnigJltIG5vdCBzYXlpbmcgdGhhdCBpdCBpcyBub3QgdXNlZnVsIGZvciBpbXBsZW1lbnRlcnMg YW5kIG9wZXJhdG9ycywgb25lIGNhbiBmaW5kIHRoYXQgdG9vIG1hbnkgQkZEIHNlc3Npb25zIG9y IGF0IHRvbyBzaG9ydCBpbnRlcnZhbHMgYmVpbmcgIHJhbi4gSSBkb27igJl0IGFncmVlIHRvIGxv YWRpbmcgdGhpcyBhcyBleHRlbnNpb24gb2YgdGhlIHdpZGVseSB1c2VkIHN0YW5kYXJkLiBQZXJo YXBzIHdlIGNhbiBsb29rIGludG8gdXNpbmcgQkZEIEVjaG8gYXMgc2VsZi1kZWJ1Z2dpbmcgaW5z dHJ1bWVudC4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1q ZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAwMywgMjAx NCAxMDoyMyBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5DQpDYzogRmFuLCBQZW5nOyBNQUxMSUsgTVVE SUdPTkRBIChtbXVkaWdvbik7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoN CkdyZWcsDQoNCkkgYmVsaWV2ZSB3ZSBoYXZlIGEgZGlzYWdyZWVtZW50IGhlcmUuIEkgZG8gbm90 IGJlbGlldmUgdGhhdCBpc3N1ZSBvZiBkZWJ1ZyBhYmlsaXR5IGFyZSBvdXRzaWRlIHRoZSBzY29w ZSBvZiBhIHN0YW5kYXJkaXplZCBwcm90b2NvbC4NCg0KTG9vayBhdCBNUExTIHBpbmcgYW5kIHRy YWNlcm91dGUgKFJGQyA0Mzc5KSAuIFRoZXkgYXJlIHVsdGltYXRlbHkgZGVidWcgdG9vbHMgdXNl ZCB0byBlc3RhYmxpc2ggdmlhYmlsaXR5IG9mIGEgcGF0aCBhbmQgdGhleSBhcmUgdmVyeSBtdWNo IHBhcnQgb2YgdGhlIHN0YW5kYXJkaXplZCBwcm90b2NvbC4NCg0KT24gRGVjIDMsIDIwMTQsIGF0 IDM6MjUgUE0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFp bHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSBNYWhlc2gsDQpJ IGNvbnNpZGVyIGlzc3VlcyBvZiBkZWJ1Z2FiaWxpdHksIG5vdCBvZiBqdXN0IEJGRCBidXQgYW55 IG90aGVyIHN0YW5kYXJkaXplZCBwcm90b2NvbCwgdG8gYmUgb3V0c2lkZSBvZiBTdGFuZGFyZCB0 cmFjaywgYXQgbW9zdCB0byBiZSBzdWl0YWJsZSBmb3IgSW5mb3JtYXRpb25hbCBvciBFeHBlcmlt ZW50YWwgdHJhY2suIElmIHdlIGFncmVlIG9uIHRoYXQsIHRoZW4gd2UgY2FuIGRpc2N1c3Mgc2Nl bmFyaW9zIHRoYXQgcHJlc2VudCBwcm9ibGVtIGFuZCBpbnZlc3RpZ2F0ZSB3aGV0aGVyIGFueXRo aW5nIGluIHRoZSBwcm90b2NvbCByZXF1aXJlcyBjbGFyaWZpY2F0aW9uIHRvIGhlbHAgdmVuZG9y cyBpbiBidWlsZGluZyB3ZWxsLXBlcmZvcm1pbmcsIHNjYWxhYmxlIGFuZCBpbnRlcm9wZXJhYmxl IGltcGxlbWVudGF0aW9ucyBhbmQgcHJvdmlkZSBvcGVyYXRpb25hbCBndWlkZWxpbmVzIGZvciBv cGVyYXRvcnMuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IE1haGVzaCBKZXRoYW5hbmRhbmkgW21haWx0bzpt amV0aGFuYW5kYW5pQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDAyLCAyMDE0 IDg6NDYgUE0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IEZhbiwgUGVuZzsgTUFMTElLIE1VRElH T05EQSAobW11ZGlnb24pOyBydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KDQpH cmVnLA0KDQpXaGF0IGlzIFBlbmcgcmVmZXJyaW5nIHRvIGlzIGEgd2F5IHRvIGZpZ3VyZSBvdXQg d2h5IGEgcGFydGljdWxhciBCRkQgc2Vzc2lvbiBmbGFwcGVkLCBwYXJ0aWN1bGFybHkgaWYgdGhl IHBhY2tldChzKSBmb3IgdGhhdCBzZXNzaW9uIGFycml2ZSBsYXRlLiBJIGRvIG5vdCBzZWUgaG93 IHRoYXQgY2FuIGJlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LiBJdCBpcyBiYXNpYyBCRkQgZGVi dWcgYWJpbGl0eS4gUnVubmluZyBhIHNlcGFyYXRlIERNIGRvZXMgdGVsbCB5b3Ugd2h5IGEgcGFy dGljdWxhciBCRkQgc2Vzc2lvbiBmbGFwcGVkLg0KDQpOb3cgd2UgY2FuIGRlYmF0ZSB3aGF0IG1l dGhvZHMgY2FuIGJlIGVtcGxveWVkIHRvIG1lYXN1cmUgdGhhdCBkZWxheSBhbmQgSSBhbSBvcGVu IHRvIHdheXMgdG8gZG9pbmcgaXQsIGluY2x1ZGluZyBsb2NhbCBsb29wYmFjayB0byBtZWFzdXJl IHRyYW5zbWl0IGRlbGF5cyBvciB0aW1lIHN0YW1waW5nIG9mIHBhY2tldHMgaW4gaGFyZHdhcmUu IEJ1dCBpbiBjYXNlcywgd2hlcmUgdGhlcmUgaXMgbm8gc3VwcG9ydCBmb3IgZWl0aGVyIG9mIHRo ZSBjYXBhYmlsaXRpZXMsIG9uZSBvZiB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9ucyBpcyB0byB1c2Ug dGhlIHRpbWUgc3RhbXBzIGNhcnJpZWQgaW4gdGhlIEJGRCBwYXlsb2FkLg0KDQpDaGVlcnMuDQoN Ck9uIERlYyAxLCAyMDE0LCBhdCA5OjM4IEFNLCBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJz a3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PiB3cm90 ZToNCg0KSGkgUGVuZywNCmFuZCBzdGlsbCwgeW914oCZcmUgbG9va2luZyBmb3IgYSB0b29sIHRv IG1lYXN1cmUgQkZEIHBlcmZvcm1hbmNlLiBUaGVuIHlvdeKAmWxsIGJlIGxvb2tpbmcgZm9yIGEg dG9vbCB0byB2ZXJpZnkgdGhlIEJGRCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCwgYW5kIG9uLCBh bmQgb24uIE9wZXJhdG9ycyBkbyBuZWVkIGNvbXBsZXRlIHNldCBvZiBGQ0FQUyB0b29scywgaW5j bHVkaW5nIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LiBOb3RlIHRoYXQgcGFzc2l2ZSBwZXJmb3Jt YW5jZSBtZWFzdXJlbWVudCB0aHJvdWdoIG1hcmtpbmcgbWV0aG9kIHRoYXQgTWFjaCBDaGVuIHJl ZmVycmVkIHRvIGNhbiBtb25pdG9yIEJGRCBmbG93KHMpIGFuZCBiZSB1c2VkIHRvIGRvIExvc3Mg YW5kL29yIERlbGF5IE1lYXN1cmVtZW50LiBBbmQgYWN0aXZlIFN5bnRoZXRpYyBMb3NzIE1lYXN1 cmVtZW50IG1heSBzaW11bGF0ZSBmbG93IG9mIHNtYWxsIHBhY2tldHMgYXMgd2VsbCBhcyByZWxh dGl2ZWx5IGxhcmdlIHBhY2tldHMuIEFuZCB0aGUgc2FtZSBnb2VzIGZvciBhY3RpdmUgbWVhc3Vy ZW1lbnQgbWV0aG9kIG9mIERlbGF5IE1lYXN1cmVtZW50LiBJIGxpa2UgU3dpc3MgQXJteSBrbml2 ZXMgYnV0IGxldCB1cyBub3QgdHVybiBCRkQgaW50byBvbmUuDQoNCiAgICAgICAgICAgICAgICBS ZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IEZh biwgUGVuZyBbbWFpbHRvOmZhbnBlbmdAY2hpbmFtb2JpbGUuY29tXQ0KU2VudDogTW9uZGF5LCBE ZWNlbWJlciAwMSwgMjAxNCA0OjQ0IEFNDQpUbzogR3JlZ29yeSBNaXJza3k7ICdNQUxMSUsgTVVE SUdPTkRBIChtbXVkaWdvbiknOyBydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0K DQpIaSBHcmVnb3J5LA0KDQpJIHdhcyBqdXN0IGdpdmluZyBhbiBleGFtcGxlIDopIEFwcGxpY2F0 aW9uIHRyYWZmaWMgdXN1YWxseSBjYW5ub3Qgc3RhbmQgc21hbGwgcGFja2V0IGxvc3MsIG5vdCB0 byBzYXkgMzAlIGxvc3MuDQoNCkkgYW0gYWN0dWFsbHkgYXNraW5nIGZvciBhIGRlYnVnIGZ1bmN0 aW9uIHRoYXQgY291bGQgZ2l2ZSB1cyBzb21lIHVzZWZ1bCBoaW50cyBvZiBwb29yIGNvbm5lY3Rp b24gd2l0aCBzbWFsbCBwcm90b2NvbCBjaGFuZ2UsIGJlc2lkZXMgdGhlIGJhc2ljIGNvbm5lY3Rp dml0eSBpbmZvcm1hdGlvbi4gSWYgaXQgbWVhc3VyZXMgc29tZXRoaW5nLCBpdCBtZWFzdXJlcyBw YWNrZXRzIG9mIEJGRCBpdHNlbGYuIFNvIEkgZG9u4oCZdCBleHBlY3QgaXQgdG8gYmUgY29uc2lk ZXJlZCBhcyBhIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IHRvb2wuDQoNCkJlc3QgcmVnYXJkcywN ClBlbmcNCg0KRnJvbTogR3JlZ29yeSBNaXJza3kgW21haWx0bzpncmVnb3J5Lm1pcnNreUBlcmlj c3Nvbi5jb21dDQpTZW50OiBTYXR1cmRheSwgTm92ZW1iZXIgMjksIDIwMTQgMzozNyBBTQ0KVG86 IEZhbiwgUGVuZzsgJ01BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKSc7IHJ0Zy1iZmRAaWV0Zi5v cmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogQkZEIHN0YWJpbGl0eSBm b2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIFBlbmcsDQp0aGlzIGlzIHZlcnkgaW50ZXJlc3Rp bmcgc2NlbmFyaW8uIEkgdGhpbmsgdGhhdCBpZiBCRkQgZXhwZXJpZW5jZXMgfjMwJSBwYWNrZXQg bG9zcywgdGhlbiBoaWdobHkgbGlrZWx5IHNvIGFyZSBhZmZlY3RlZCBvdGhlciBhcHBsaWNhdGlv bnMuIFRoZW4gaXQgaXMgbm90IGp1c3QgQkZEIGlzc3VlIGJ1dCBjb25kaXRpb24gdGhhdCBzaG91 bGQgYmUgZGV0ZWN0ZWQgIGJ5IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IG1ldGhvZCwgd2hldGhl ciBhY3RpdmUgb3IgcGFzc2l2ZSBwYWNrZXQgbG9zcyBtZWFzdXJlbWVudC4NCknigJltIGNvbnZp bmNlZCB0aGF0IG92ZXJsb2FkaW5nIEJGRCB3aXRoIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IHBy b3Zpc2lvbnMgaXMgY291bnRlci1wcm9kdWN0aXZlIGFuZCBpcyBpbmFwcHJvcHJpYXRlLg0KDQog ICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg R3JlZw0KDQpGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRmFuLCBQZW5nDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDI4LCAyMDE0IDQ6 MzQgQU0NClRvOiAnTUFMTElLIE1VRElHT05EQSAobW11ZGlnb24pJzsgcnRnLWJmZEBpZXRmLm9y ZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5IGZv bGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGkgTWFsbGlrLA0KDQpFeGFjdGx5LiBQYWNrZXRzIG1h eSBiZSBleHBlcmllbmNpbmcgc2xpZ2h0IGxvc3MsIGJ1dCB0aGUgbGluayBjYW4gaGFyZGx5IGJl IHJlZ2FyZGVkIGFzIGNvbm5lY3RlZC4gTW9yZSBpbXBvcnRhbnRseSwgdGhlIGV4cGVyaWVuY2Ug b2YgdXBwZXItbGV2ZWwgYXBwbGljYXRpb25zIGNhbiBiZSBkZWdyYWRlZCBzZXZlcmVseSAoZS5n LiBUQ1AgdHJhZmZpYyBpcyBub3QgYWJsZSB0byBnbyBmYXN0IGluIGZhY2Ugb2YgZXZlbiBzbWFs bCBjb250aW51b3VzIGxvc3MpLiBCdXQgd2hhdCBpZiBvbmUgQkZEIGZyYW1lIGlzIGxvc3QgZXZl cnkgdGhyZWUgZnJhbWVzPyBUaGVuIHRoZSBsb3NzIHJhdGUgaXMgMzAlIG9uIGF2ZXJhZ2UsIHdo aWNoIGlzIGFscmVhZHkgYSB2ZXJ5IHNldmVyZSB2YWx1ZS4NCg0KQmVzdCByZWdhcmRzLA0KUGVu Zw0KDQpGcm9tOiBNQUxMSUsgTVVESUdPTkRBIChtbXVkaWdvbikgW21haWx0bzptbXVkaWdvbkBj aXNjby5jb21dDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDI4LCAyMDE0IDc6NTMgUE0NClRvOiBG YW4sIFBlbmc7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIFBlbmcs DQoNCklmIHRoZSBCRkQgcGFja2V0cyBhcmUgbG9zdCwgZG9lc27igJl0IHRoZSBCRkQgc2Vzc2lv biBnbyBET1dOPyBBcmUgeW91IHNheWluZyB0aGF0IHBhY2tldCBsb3NzIGlzIG5vdCBiaWcgZW5v dWdoIHRvIG1ha2UgQkZEIHNlc3Npb24gZ28gRE9XTj8NCg0KVGhhbmtzDQoNClJlZ2FyZHMNCk1h bGxpaw0KDQpGcm9tOiA8RmFuPiwgUGVuZyA8ZmFucGVuZ0BjaGluYW1vYmlsZS5jb208bWFpbHRv OmZhbnBlbmdAY2hpbmFtb2JpbGUuY29tPj4NCkRhdGU6IEZyaWRheSwgMjggTm92ZW1iZXIgMjAx NCA0OjIwIHBtDQpUbzogInJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+ IiA8cnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS RTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIEplZmYsIGFsbCwN Cg0KSSBoYXZlIGJlZW4gZm9sbG93aW5nIHRoaXMgc3RhYmlsaXR5IGV4dGVuc2lvbiBmcm9tIHRo ZSBiZWdpbm5pbmcsIGFuZCBhcyBhbg0Kb3BlcmF0b3IgSSB3b3VsZCBsaWtlIHRvIGV4cHJlc3Mg dGhhdCB0aGlzIGRyYWZ0IGVuYWJsZXMgdGhlICJhZHZhbmNlZA0KZmVhdHVyZSIgd2UgZGVzaXJl IGZvciBCRkQgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIHVzZWZ1bCBpbmZvcm1hdGlvbiB0aGF0DQpo ZWxwcyBvcGVyYXRvcnMgdW5kZXJzdGFuZCBuZXR3b3JrIGlzc3Vlcy4gQSByZWxldmFudCB1c2Ug Y2FzZSBpcyBkZXRlY3RpbmcNCmxvc3N5IG9yICJxdWFzaS1kaXNjb25uZWN0ZWQiIGxpbmtzIG9y IG1lbWJlciBMQUcgbGlua3MuIEFuIGV4YW1wbGUgb2Ygc3VjaA0Kc2l0dWF0aW9uIHdlIGV4cGVy aWVuY2VkIHdhcyBhIGxvb3NlbHkgY29ubmVjdGVkIGZpYmVyIGxpbmsgcmVzdWx0aW5nIGluDQpj b250aW51b3VzLCBzbWFsbCBhbW91bnQgb2YgcGFja2V0IGxvc3MuIEJGRCBjb3VsZCBnZXQgdGhl IGluZm9ybWF0aW9uIG9mDQpsb3N0IEJGRCBmcmFtZXMgb24gc3VjaCB1bnN0YWJsZSBsaW5rLCBh bmQgcHJvYmFibHkgcmVwb3J0IHdoZW4gYSB0YXJnZXQNCmxldmVsIGlzIHJlYWNoZWQsIHNheSBh IGNlcnRhaW4gbnVtYmVyIG9mIGZyYW1lcyBhcmUgbG9zdCBvdmVyIGEgcGVyaW9kIG9yDQphbW9u ZyBhIHRvdGFsIG51bWJlciBvZiBmcmFtZXMuDQoNCkJlc3QgcmVnYXJkcywNClBlbmcNCg0KTWFo ZXNoIEpldGhhbmFuZGFuaQ0KQ28tY2hhaXIsIE5FVENPTkYgV0cNCm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KTWFoZXNoIEpldGhhbmFu ZGFuaQ0KQ28tY2hhaXIsIE5FVENPTkYgV0cNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg== --_000_7347100B5761DC41A166AC17F22DF1121B8AAC0Deusaamb103erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQt c3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBTYW50b3NoLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5idXQgdGhhdCBpcyB3aGF0IGNhbiBiZSBjYWxsZWQg4oCcZmVh dHVyZSBjcmVlcOKAnS4gQkZEIGlzIGNvbnRpbnVpdHkgY2hlY2sgbWVjaGFuaXNtIGFuZCBmb3Ig YWN0aXZlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LCBldmVuIG9jY2FzaW9uYWwsIHRoZXJlIGFy ZSBUV0FNUCBpbg0KIElQIGFuZCBSRkMgNjM3NC82Mzc1IGluIE1QTFMvTVBMUy1UUC4gSXQgbWF5 IGJlIHRlbXB0aW5nIHRvIGV4cGFuZCBzY29wZSBvZiBCRkQgYnV0LCBJIGJlbGlldmUsIGl0IGlz IHN1Y2Nlc3NmdWwgZXhhY3RseSBiZWNhdXNlIGl0IHdhcyBzaW1wbGUsIGxpZ2h0LXdlaWdodCBh bmQgZGVzaWduZWQgdG8gZG8gZXhhY3RseSBvbmUgdGhpbmcg4oCTIGNvbnRpbnVpdHkgY2hlY2su PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBTYW50b3NoIFAgSyBbbWFpbHRvOnNhbnRvc2hwa0BqdW5pcGVyLm5ldF0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgNzowMiBBTTxicj4N CjxiPlRvOjwvYj4gR3JlZ29yeSBNaXJza3k7IE1haGVzaCBKZXRoYW5hbmRhbmk8YnI+DQo8Yj5D Yzo8L2I+IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEJGRCBzdGFi aWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IZWxsbyBHcmVnLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsgRGVi dWdnaW5nIEJGRCBpcyBvbmUgb2YgdGhlIHVzZSBjYXNlLiBJIGFsc28gd2FudCB0byBicmluZyB1 cCBvbmUgb2YgdGhlIHVzZSBjYXNlIHRoYXQgSmVmZiBzdWdnZXN0ZWQgaW4gaGlzIGVhcmxpZXIg Jm5ic3A7bWFpbC4gT3BlcmF0b3IgbWlnaHQgTk9UIHdhbnQgdG8gcnVuDQogT0FNIHdoaWNoIGRv ZXMgbG9zcyBhbmQgZGVsYXkgbWVhc3VyZW1lbnQgYWxsIHRoZSB0aW1lIGR1ZSB0byBpdHMgb3Zl cmhlYWQuIFdpdGggdGhlIGV4dGVuc2lvbiB0byBCRkQgKHNlcXVlbmNlIG51bWJlcikgd2UgY2Fu IGRldGVjdCBpZiB0aGVyZSBpcyBhbnkgbG9zcyBidXQgQkZEIHN0aWxsIHN0YXlzIHVwLiBUaGlz IGxvc3MgZGV0ZWN0aW9uIGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dlciBmb3IgbG9zcyBhbmQgZGVs YXkgbWVhc3VyZW1lbnQuDQogRWNobyBjYW4gYmUgdXNlZCBvbmx5IGluIGNhc2Ugb2Ygc2luZ2xl aG9wIGFuZCBpbiBvbmUgZGlyZWN0aW9uIG9ubHkuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNhbnRvc2ggUCBLICZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy1iZmQgWzxhIGhyZWY9Im1h aWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5HcmVnb3J5IE1pcnNreTxicj4NCjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MTIgUE08YnI+DQo8Yj5Ubzo8 L2I+IE1haGVzaCBKZXRoYW5hbmRhbmk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpy dGctYmZkQGlldGYub3JnIj5ydGctYmZkQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1haGVzaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+aW5kZWVkLCBMU1AgUGluZyBpcyBwYXJ0IG9mIE1QTFMgT0FNIHRvb2wgc2V0IGFzIEJGRCBp dHNlbGYgdGhhdCBpbnRlbmRlZCB0byBtb25pdG9yIG9wZXJhdGlvbmFsIHN0YXRlIG9mIHRoZSBu ZXR3b3JrLCBwYXRoIGNvbnRpbnVpdHkgYmV0d2VlbiB0d28gbm9kZXMuIEFuZA0KIExTUCBQaW5n LCBhcyBwcmltYXJpbHkgb24tZGVtYW5kIHRyb3VibGVzaG9vdGluZyB0b29sLCBoZWxwcyBsb2Nh bGl6ZSBhbmQsIHRvIGNlcnRhaW4gZGVncmVlLCBkaWFnbm9zZSB0aGUgcHJvYmxlbS4gQnV0IHRo ZSB1bHRpbWF0ZSBkZWJ1Z2dpbmcgaXMgcHJvcHJpZXRhcnkuIFRoaXMgcHJvcG9zYWwsIGluIG15 IHZpZXcsIGhlbHBzIG5vdCBtb25pdG9yIGJlaGF2aW9yIG9mIHRoZSBuZXR3b3JrIGJ1dCBCRkQg aXRzZWxmLCBxdWFsaXR5IG9mIEJGRA0KIGltcGxlbWVudGF0aW9uLiBJ4oCZbSBub3Qgc2F5aW5n IHRoYXQgaXQgaXMgbm90IHVzZWZ1bCBmb3IgaW1wbGVtZW50ZXJzIGFuZCBvcGVyYXRvcnMsIG9u ZSBjYW4gZmluZCB0aGF0IHRvbyBtYW55IEJGRCBzZXNzaW9ucyBvciBhdCB0b28gc2hvcnQgaW50 ZXJ2YWxzIGJlaW5nJm5ic3A7IHJhbi4gSSBkb27igJl0IGFncmVlIHRvIGxvYWRpbmcgdGhpcyBh cyBleHRlbnNpb24gb2YgdGhlIHdpZGVseSB1c2VkIHN0YW5kYXJkLiBQZXJoYXBzIHdlIGNhbiBs b29rIGludG8NCiB1c2luZyBCRkQgRWNobyBhcyBzZWxmLWRlYnVnZ2luZyBpbnN0cnVtZW50Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gTWFoZXNoIEpldGhhbmFuZGFuaSBbPGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tIj5tYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRGVjZW1iZXIgMDMsIDIwMTQgMTA6MjMgUE08YnI+DQo8 Yj5Ubzo8L2I+IEdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+Q2M6PC9iPiBGYW4sIFBlbmc7IE1BTExJ SyBNVURJR09OREEgKG1tdWRpZ29uKTsgPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmci Pg0KcnRnLWJmZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEJGRCBzdGFi aWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkdyZWcsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgd2UgaGF2ZSBhIGRpc2FncmVlbWVudCBoZXJlLiBJIGRv IG5vdCBiZWxpZXZlIHRoYXQgaXNzdWUgb2YgZGVidWcgYWJpbGl0eSBhcmUgb3V0c2lkZSB0aGUg c2NvcGUgb2YgYSBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2sgYXQgTVBMUyBwaW5nIGFuZCB0cmFj ZXJvdXRlIChSRkMgNDM3OSkgLiBUaGV5IGFyZSB1bHRpbWF0ZWx5IGRlYnVnIHRvb2xzIHVzZWQg dG8gZXN0YWJsaXNoIHZpYWJpbGl0eSBvZiBhIHBhdGggYW5kIHRoZXkgYXJlIHZlcnkgbXVjaCBw YXJ0IG9mIHRoZSBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBEZWMgMywgMjAxNCwgYXQgMzoyNSBQ TSwgR3JlZ29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmlj c3Nvbi5jb20iPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1haGVzaCw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjb25zaWRlciBpc3N1ZXMgb2YgZGVidWdhYmls aXR5LCBub3Qgb2YganVzdCBCRkQgYnV0IGFueSBvdGhlciBzdGFuZGFyZGl6ZWQgcHJvdG9jb2ws IHRvIGJlIG91dHNpZGUgb2YgU3RhbmRhcmQgdHJhY2ssIGF0IG1vc3QgdG8gYmUgc3VpdGFibGUg Zm9yIEluZm9ybWF0aW9uYWwNCiBvciBFeHBlcmltZW50YWwgdHJhY2suIElmIHdlIGFncmVlIG9u IHRoYXQsIHRoZW4gd2UgY2FuIGRpc2N1c3Mgc2NlbmFyaW9zIHRoYXQgcHJlc2VudCBwcm9ibGVt IGFuZCBpbnZlc3RpZ2F0ZSB3aGV0aGVyIGFueXRoaW5nIGluIHRoZSBwcm90b2NvbCByZXF1aXJl cyBjbGFyaWZpY2F0aW9uIHRvIGhlbHAgdmVuZG9ycyBpbiBidWlsZGluZyB3ZWxsLXBlcmZvcm1p bmcsIHNjYWxhYmxlIGFuZCBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBhbmQNCiBwcm92 aWRlIG9wZXJhdGlvbmFsIGd1aWRlbGluZXMgZm9yIG9wZXJhdG9ycy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TWFoZXNoDQogSmV0aGFuYW5k YW5pIFs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBEZWNlbWJlciAwMiwgMjAxNCA4OjQ2 IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5HcmVnb3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RmFuLCBQZW5nOyBNQUxMSUsgTVVESUdP TkRBIChtbXVkaWdvbik7DQo8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+cnRnLWJm ZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZy b20gSUVURi05MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWcsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aGF0IGlzIFBlbmcgcmVmZXJyaW5nIHRvIGlzIGEgd2F5IHRvIGZpZ3VyZSBvdXQgd2h5IGEgcGFy dGljdWxhciBCRkQgc2Vzc2lvbiBmbGFwcGVkLCBwYXJ0aWN1bGFybHkgaWYgdGhlIHBhY2tldChz KSBmb3IgdGhhdCBzZXNzaW9uIGFycml2ZSBsYXRlLiBJIGRvIG5vdCBzZWUgaG93IHRoYXQgY2Fu IGJlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LiBJdCBpcyBiYXNpYyBCRkQgZGVidWcgYWJpbGl0 eS4gUnVubmluZw0KIGEgc2VwYXJhdGUgRE0gZG9lcyB0ZWxsIHlvdSB3aHkgYSBwYXJ0aWN1bGFy IEJGRCBzZXNzaW9uIGZsYXBwZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdyB3ZSBj YW4gZGViYXRlIHdoYXQgbWV0aG9kcyBjYW4gYmUgZW1wbG95ZWQgdG8gbWVhc3VyZSB0aGF0IGRl bGF5IGFuZCBJIGFtIG9wZW4gdG8gd2F5cyB0byBkb2luZyBpdCwgaW5jbHVkaW5nIGxvY2FsIGxv b3BiYWNrIHRvIG1lYXN1cmUgdHJhbnNtaXQgZGVsYXlzIG9yIHRpbWUgc3RhbXBpbmcgb2YgcGFj a2V0cyBpbiBoYXJkd2FyZS4gQnV0IGluIGNhc2VzLCB3aGVyZSB0aGVyZSBpcyBubyBzdXBwb3J0 DQogZm9yIGVpdGhlciBvZiB0aGUgY2FwYWJpbGl0aWVzLCBvbmUgb2YgdGhlIHN1Z2dlc3RlZCBz b2x1dGlvbnMgaXMgdG8gdXNlIHRoZSB0aW1lIHN0YW1wcyBjYXJyaWVkIGluIHRoZSBCRkQgcGF5 bG9hZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gRGVjIDEsIDIwMTQsIGF0IDk6MzggQU0sIEdyZWdvcnkgTWly c2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L3NwYW4+ PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUGVuZyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YW5kIHN0aWxsLCB5b3XigJlyZSBsb29r aW5nIGZvciBhIHRvb2wgdG8gbWVhc3VyZSBCRkQgcGVyZm9ybWFuY2UuIFRoZW4geW914oCZbGwg YmUgbG9va2luZyBmb3IgYSB0b29sIHRvIHZlcmlmeSB0aGUgQkZEIHBlcmZvcm1hbmNlIG1lYXN1 cmVtZW50LCBhbmQgb24sIGFuZCBvbi4NCiBPcGVyYXRvcnMgZG8gbmVlZCBjb21wbGV0ZSBzZXQg b2YgRkNBUFMgdG9vbHMsIGluY2x1ZGluZyBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudC4gTm90ZSB0 aGF0IHBhc3NpdmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgdGhyb3VnaCBtYXJraW5nIG1ldGhv ZCB0aGF0IE1hY2ggQ2hlbiByZWZlcnJlZCB0byBjYW4gbW9uaXRvciBCRkQgZmxvdyhzKSBhbmQg YmUgdXNlZCB0byBkbyBMb3NzIGFuZC9vciBEZWxheSBNZWFzdXJlbWVudC4gQW5kIGFjdGl2ZQ0K IFN5bnRoZXRpYyBMb3NzIE1lYXN1cmVtZW50IG1heSBzaW11bGF0ZSBmbG93IG9mIHNtYWxsIHBh Y2tldHMgYXMgd2VsbCBhcyByZWxhdGl2ZWx5IGxhcmdlIHBhY2tldHMuIEFuZCB0aGUgc2FtZSBn b2VzIGZvciBhY3RpdmUgbWVhc3VyZW1lbnQgbWV0aG9kIG9mIERlbGF5IE1lYXN1cmVtZW50LiBJ IGxpa2UgU3dpc3MgQXJteSBrbml2ZXMgYnV0IGxldCB1cyBub3QgdHVybiBCRkQgaW50byBvbmUu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZhbiwNCiBQZW5nIFs8YSBocmVmPSJtYWlsdG86ZmFucGVuZ0BjaGlu YW1vYmlsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpmYW5wZW5nQGNo aW5hbW9iaWxlLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBEZWNlbWJlciAwMSwgMjAxNCA0OjQ0 IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5HcmVnb3J5IE1pcnNreTsgJ01BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKSc7 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpydGctYmZkQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGct YmZkQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IEJGRCBzdGFiaWxpdHkgZm9s bG93LXVwIGZyb20gSUVURi05MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSBHcmVnb3J5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3YXMganVzdCBnaXZpbmcgYW4gZXhhbXBsZSA6KSBB cHBsaWNhdGlvbiB0cmFmZmljIHVzdWFsbHkgY2Fubm90IHN0YW5kIHNtYWxsIHBhY2tldCBsb3Nz LCBub3QgdG8gc2F5IDMwJSBsb3NzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBhY3R1YWxseSBhc2tpbmcg Zm9yIGEgZGVidWcgZnVuY3Rpb24gdGhhdCBjb3VsZCBnaXZlIHVzIHNvbWUgdXNlZnVsIGhpbnRz IG9mIHBvb3IgY29ubmVjdGlvbiB3aXRoIHNtYWxsIHByb3RvY29sIGNoYW5nZSwgYmVzaWRlcyB0 aGUgYmFzaWMgY29ubmVjdGl2aXR5DQogaW5mb3JtYXRpb24uIElmIGl0IG1lYXN1cmVzIHNvbWV0 aGluZywgaXQgbWVhc3VyZXMgcGFja2V0cyBvZiBCRkQgaXRzZWxmLiBTbyBJIGRvbuKAmXQgZXhw ZWN0IGl0IHRvIGJlIGNvbnNpZGVyZWQgYXMgYSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCB0b29s Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5HcmVnb3J5DQogTWlyc2t5IFs8YSBocmVmPSJt YWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5tYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT5dPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TYXR1 cmRheSwgTm92ZW1iZXIgMjksIDIwMTQgMzozNyBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RmFuLCBQZW5nOyAnTUFMTElL IE1VRElHT05EQSAobW11ZGlnb24pJzs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Zy1iZmRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5SRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFBlbmcsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoaXMgaXMgdmVyeSBpbnRlcmVzdGlu ZyBzY2VuYXJpby4gSSB0aGluayB0aGF0IGlmIEJGRCBleHBlcmllbmNlcyB+MzAlIHBhY2tldCBs b3NzLCB0aGVuIGhpZ2hseSBsaWtlbHkgc28gYXJlIGFmZmVjdGVkIG90aGVyIGFwcGxpY2F0aW9u cy4gVGhlbiBpdCBpcyBub3QganVzdA0KIEJGRCBpc3N1ZSBidXQgY29uZGl0aW9uIHRoYXQgc2hv dWxkIGJlIGRldGVjdGVkJm5ic3A7IGJ5IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IG1ldGhvZCwg d2hldGhlciBhY3RpdmUgb3IgcGFzc2l2ZSBwYWNrZXQgbG9zcyBtZWFzdXJlbWVudC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKA mW0gY29udmluY2VkIHRoYXQgb3ZlcmxvYWRpbmcgQkZEIHdpdGggcGVyZm9ybWFuY2UgbWVhc3Vy ZW1lbnQgcHJvdmlzaW9ucyBpcyBjb3VudGVyLXByb2R1Y3RpdmUgYW5kIGlzIGluYXBwcm9wcmlh dGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJk cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlJ0Zy1iZmQNCiBbPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtYm91 bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnJ0Zy1iZmQt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkZhbiwgUGVuZzxicj4NCjxiPlNlbnQ6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GcmlkYXks IE5vdmVtYmVyIDI4LCAyMDE0IDQ6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPidNQUxMSUsgTVVESUdPTkRBIChtbXVk aWdvbiknOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBCRkQgc3RhYmls aXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGkgTWFsbGlrLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXhhY3RseS4gUGFja2V0cyBtYXkgYmUgZXhw ZXJpZW5jaW5nIHNsaWdodCBsb3NzLCBidXQgdGhlIGxpbmsgY2FuIGhhcmRseSBiZSByZWdhcmRl ZCBhcyBjb25uZWN0ZWQuIE1vcmUgaW1wb3J0YW50bHksIHRoZSBleHBlcmllbmNlIG9mIHVwcGVy LWxldmVsIGFwcGxpY2F0aW9ucw0KIGNhbiBiZSBkZWdyYWRlZCBzZXZlcmVseSAoZS5nLiBUQ1Ag dHJhZmZpYyBpcyBub3QgYWJsZSB0byBnbyBmYXN0IGluIGZhY2Ugb2YgZXZlbiBzbWFsbCBjb250 aW51b3VzIGxvc3MpLiBCdXQgd2hhdCBpZiBvbmUgQkZEIGZyYW1lIGlzIGxvc3QgZXZlcnkgdGhy ZWUgZnJhbWVzPyBUaGVuIHRoZSBsb3NzIHJhdGUgaXMgMzAlIG9uIGF2ZXJhZ2UsIHdoaWNoIGlz IGFscmVhZHkgYSB2ZXJ5IHNldmVyZSB2YWx1ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UGVuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ TUFMTElLDQogTVVESUdPTkRBIChtbXVkaWdvbikgWzxhIGhyZWY9Im1haWx0bzptbXVkaWdvbkBj aXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzptbXVkaWdvbkBjaXNj by5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPkZyaWRheSwgTm92ZW1iZXIgMjgsIDIwMTQgNzo1MyBQTTxicj4N CjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+RmFuLCBQZW5nOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBCRkQg c3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SGkgUGVuZyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB0aGUgQkZEIHBhY2tldHMgYXJlIGxvc3QsIGRvZXNu 4oCZdCB0aGUgQkZEIHNlc3Npb24gZ28gRE9XTj8gQXJlIHlvdSBzYXlpbmcgdGhhdCBwYWNrZXQg bG9zcyBpcyBub3QgYmlnIGVub3VnaCB0byBtYWtlIEJGRCBzZXNzaW9uIGdvIERPV04/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1hbGxpazwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jmx0O0ZhbiZndDssIFBlbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpmYW5wZW5nQGNoaW5hbW9iaWxl LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZmFucGVuZ0BjaGluYW1vYmlsZS5jb208 L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RnJpZGF5LCAyOCBOb3ZlbWJlciAyMDE0IDQ6MjAgcG08 YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5ydGctYmZkQGlldGYub3JnPC9zcGFuPjwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5ydGctYmZkQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJFOiBCRkQgc3Rh YmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhp IEplZmYsIGFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGhhdmUgYmVlbiBmb2xsb3dpbmcgdGhpcyBzdGFiaWxp dHkgZXh0ZW5zaW9uIGZyb20gdGhlIGJlZ2lubmluZywgYW5kIGFzIGFuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+b3BlcmF0b3IgSSB3 b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhhdCB0aGlzIGRyYWZ0IGVuYWJsZXMgdGhlICZxdW90O2Fk dmFuY2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+ZmVhdHVyZSZxdW90OyB3ZSBkZXNpcmUgZm9yIEJGRCB0byBwcm92aWRlIGFkZGl0 aW9uYWwgdXNlZnVsIGluZm9ybWF0aW9uIHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5oZWxwcyBvcGVyYXRvcnMgdW5kZXJzdGFu ZCBuZXR3b3JrIGlzc3Vlcy4gQSByZWxldmFudCB1c2UgY2FzZSBpcyBkZXRlY3Rpbmc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5sb3Nz eSBvciAmcXVvdDtxdWFzaS1kaXNjb25uZWN0ZWQmcXVvdDsgbGlua3Mgb3IgbWVtYmVyIExBRyBs aW5rcy4gQW4gZXhhbXBsZSBvZiBzdWNoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c2l0dWF0aW9uIHdlIGV4cGVyaWVuY2VkIHdhcyBh IGxvb3NlbHkgY29ubmVjdGVkIGZpYmVyIGxpbmsgcmVzdWx0aW5nIGluPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Y29udGludW91cywg c21hbGwgYW1vdW50IG9mIHBhY2tldCBsb3NzLiBCRkQgY291bGQgZ2V0IHRoZSBpbmZvcm1hdGlv biBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmxvc3QgQkZEIGZyYW1lcyBvbiBzdWNoIHVuc3RhYmxlIGxpbmssIGFuZCBwcm9iYWJs eSByZXBvcnQgd2hlbiBhIHRhcmdldDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmxldmVsIGlzIHJlYWNoZWQsIHNheSBhIGNlcnRhaW4g bnVtYmVyIG9mIGZyYW1lcyBhcmUgbG9zdCBvdmVyIGEgcGVyaW9kIG9yPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YW1vbmcgYSB0b3Rh bCBudW1iZXIgb2YgZnJhbWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QZW5nPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D by1jaGFpciwgTkVUQ09ORiBXRzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tamV0aGFuYW5kYW5pQGdt YWlsLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NYWhlc2ggSmV0 aGFuYW5kYW5pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Dby1jaGFpciwgTkVUQ09ORiBX RzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B8AAC0Deusaamb103erics_-- From nobody Thu Dec 4 07:49:23 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476361AD3BB for ; Thu, 4 Dec 2014 07:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 KL9pEtLGTVon for ; Thu, 4 Dec 2014 07:49:18 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 8A65A1AD418 for ; Thu, 4 Dec 2014 07:47:30 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-d8-548025cfc2b5 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 3F.79.25146.FC520845; Thu, 4 Dec 2014 10:13:51 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 10:47:28 -0500 From: Gregory Mirsky To: Jeffrey Haas , "Nobo Akiya (nobo)" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQDUqXQ6amXjPuFEmbPIOgLl4p2px+NluAgAAjMzCAAOz5gP//rP5ggACs1ACAAAiDAIAAAPgAgAAA6YCAACPdgIAADrqAgAAGAACAAAClAP//s40g Date: Thu, 4 Dec 2014 15:47:27 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> References: <20141204151708.GA9458@pfrc> In-Reply-To: <20141204151708.GA9458@pfrc> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPt+551YYQg69XFC32H3zLajG7I97i 859tjA7MHlN+b2T1WLLkJ5PH5d6trAHMUVw2Kak5mWWpRfp2CVwZ3ReuMhZc4arY+HwKUwPj eY4uRk4OCQETideTLrBB2GISF+6tB7K5OIQEjjBKrF1/iB3CWcYo8W/ba0aQKjYBI4kXG3vY QWwRAXeJBwfOgNnMApoSTSc+g9nCAoYSq7oXQ9UYSRybMRdskIhAE6PE0vZtzCAJFgEVidNn n4IV8Qr4SizefJcVYttRZon9zReYQBKcQFO7Zj8G28wIdN/3U2uYILaJS9x6Mp8J4m4BiSV7 zjND2KISLx//Y4WwlSQ+/p4PdZ2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMXKUFqeW5aYbGW5iBEbPMQk2xx2MCz5ZHmIU4GBU4uHdEFsfIsSaWFZcmXuI UZqDRUmcV7N6XrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxppjHjz7E8Jzkq02BpfUGM+1 DVxl9af6SrRX56t9PxmVE1y/F1rF3Kt4tYl/3qwCQ48CRoWCtl+rpUuqVzckhHd8bFkx1Vqs X+WNc+LhVUrMRxJuS7SfmqSzt/biki+x32PqutvVmMtL6lfdXbmsomSfzI9P54xSDnxZ2CIs HKB58a26++KNSizFGYmGWsxFxYkA2rgN3H8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/M1W3IXsmolDQMjv5ngCnm8uf1qs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:49:20 -0000 Hi Jeff, I can reference RFC 5357 here. The Appendix describes what is called TWAMP-= Light mode with Stateless Reflector. About year and a half the Errata been = accepted that describes Stateful Reflector, which supports measurement of o= ne-way latency/jitter and packet loss metrics. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Thursday, December 04, 2014 7:17 AM To: Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote: > If what you say is the only requirement not met, one approach may be to p= ursue a non-standard-track document describing some suggested implementatio= n techniques to locally store TX/RX timestamp. >=20 > Given that echo approach will be less accurate and given that we seem to = be having difficulty converging, I thought I???ll throw out another idea. I think my biggest concern is that the echo approach has bidirectional pack= et loss possibilities. Async at least lets the receiver know about unidire= ctional packet loss. Of course, if your goal is to notify the sender that their packets are bein= g lost, you need a backchannel anyway. I just don't know if we want that b= ack channel to be bfd. - Jeff From nobody Thu Dec 4 08:29:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4344F1AD4B6 for ; Thu, 4 Dec 2014 08:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 yR5yxyB0M21O for ; Thu, 4 Dec 2014 08:29:12 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815F61AD4AF for ; Thu, 4 Dec 2014 08:29:08 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so3081319obc.28 for ; Thu, 04 Dec 2014 08:29:07 -0800 (PST) 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:content-type; bh=x6EzThvWRJSsbrGY+FAzPfRyJ1cLFZVdD5VkQ0kbU9I=; b=YHgD1JolE9yVF1M9dANIN99AxfPn5tDBEm/rJf5Ukfa6Snsj7L4GIh1hY5tmjrLfHT sS9f0UCkLTOXNCPPWBgxP5KzRVpl4jRNgWWxAJoJFaKl10erNPvDeLI54Eqwr1fYkqcw kDg1uuw9lWD2yp7f3tpiyllaA/hVyhwZOhhZcsOhoR3/6hTh2smw1LQJr4FDCt81E6M7 Pt8PwlP2sXDvOyESUeaunKNBHrt0DD5IpnRrWDaEWYSmaa2qA3pK3cR3CzjNHAaEITLF XzqYIxn/fICVbFHsTYlW15AFbXggZcWVJWwjt2LZ6hIJxdlGJ4aWCq2fG7lw46tjRfLA /KuA== MIME-Version: 1.0 X-Received: by 10.60.67.165 with SMTP id o5mr7485014oet.24.1417710547753; Thu, 04 Dec 2014 08:29:07 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 08:29:07 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> Date: Thu, 4 Dec 2014 21:59:07 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a11c31dd897e1fa0509667536 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/jHWkjB72j2n_zXwmzurzBILPHZY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 16:29:17 -0000 --001a11c31dd897e1fa0509667536 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am not sure what the confusion is Greg. Assume i have a BFD session thats up. At some point in time it flaps. Now i need to know whether the issue was at the TX or the RX. Please tell me how TWAMP can help me here. Also tell me how what tool i can use if its a uBFD session that flapped. Cheers, Manav On Thu, Dec 4, 2014 at 9:09 PM, Gregory Mirsky wrote: > Hi Santosh, > > but that is what can be called =E2=80=9Cfeature creep=E2=80=9D. BFD is co= ntinuity check > mechanism and for active performance measurement, even occasional, there > are TWAMP in IP and RFC 6374/6375 in MPLS/MPLS-TP. It may be tempting to > expand scope of BFD but, I believe, it is successful exactly because it w= as > simple, light-weight and designed to do exactly one thing =E2=80=93 conti= nuity > check. > > > > Regards, > > Greg > > > --001a11c31dd897e1fa0509667536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not sure what the conf= usion is Greg.

Assume i have a BFD session thats up. At some point in time= it flaps. Now i need to know whether the issue was at the TX or the RX.

Pl= ease tell me how TWAMP can help me here. Also tell me how what tool i can u= se if its a uBFD session that flapped.
<= br>
Cheers, Manav

On Thu, Dec 4, 2014 at 9:09 PM, Gr= egory Mirsky <gregory.mirsky@ericsson.com> wrote:<= br>

Hi Santosh,=

but that is what can be c= alled =E2=80=9Cfeature creep=E2=80=9D. BFD is continuity check mechanism an= d for active performance measurement, even occasional, there are TWAMP in IP and RFC 6374/6375 in MPLS/MPLS-TP. It may be tempting to expand scope o= f BFD but, I believe, it is successful exactly because it was simple, light= -weight and designed to do exactly one thing =E2=80=93 continuity check.=

=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

<= /div>
--001a11c31dd897e1fa0509667536-- From nobody Thu Dec 4 10:11:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E132B1A1B75 for ; Thu, 4 Dec 2014 10:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 lNeSZXCBQMRD for ; Thu, 4 Dec 2014 10:11:49 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549DE1A1B47 for ; Thu, 4 Dec 2014 10:11:49 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id rd3so18563802pab.0 for ; Thu, 04 Dec 2014 10:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MhPyW5DDyVE4YxQX1KxKP94CiWfrGCu19aOQOeEer7M=; b=qhGjCoVfush+dC8016IQa/rKP4kD8mt91YLkV7AWBD5MQ0zdrlKp0zDTtYAI+pmgYN pzm36GwkPSYcT+v93OIQQtcxkONGZqbpLBF/jAC33JR26wdgL455jQ9EaaXvrbW047op 05BaU4l4i+dqzTyvLd7o4YO+4OKTybWoTydwpX2Uc6JPCY3LEhjEuDFCdEC4Bilmr+6P 5GqGRCwUrJYdQegtZeLXv4RL4PJ52caNhiRwS1FszFy7Ufw2TMffzkM3OR5Bi6dEpGLB fRAIHGQ1PqTuE3B18gM7KrJPLgD4EpUxJSkf0lJABR24PlVVJ34RS1ONpok2V2ckXiM2 av1w== X-Received: by 10.66.235.37 with SMTP id uj5mr21270463pac.72.1417716708643; Thu, 04 Dec 2014 10:11:48 -0800 (PST) Received: from [192.168.1.11] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id kp2sm26734107pdb.30.2014.12.04.10.11.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 10:11:47 -0800 (PST) Subject: Re: BFD stability follow-up from IETF-91 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Sam K. Aldrin" In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> Date: Thu, 4 Dec 2014 10:11:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> References: <20141204151708.GA9458@pfrc> <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/TvgJS0wiFrmooBRJFjIt7dS_PNg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 18:11:51 -0000 Way too many emails to catch up to discussion and to understand clearly, = every point. Here are my questions and concerns - Is this primarily to debug the debugger i.e. OAM for BFD? - Is this because the primary BFD protocol is too simple and cannot = debug its failure. And this enhancement adds some sort of extension to = base protocol? Say BFD 1.1? - Every OAM tool has issues to debug itself, but is there any reference = where there is OAM for OAM which got standardized? Concern: - With the sequence number added, one could find(?) that BFD control = packets are experiencing congestion or packet delay. So, the assertion = is that BFD flapping could be avoided. But if the packets in the = network, including BFD, are really experiencing this, shouldn't this be = the right behavior? - I see concerns regarding timestamps and sequence numbers expressed in = emails. In that case, the proposed model is still not going to identify = the problem completely. Am I reading it right? -sam On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote: > Hi Jeff, > I can reference RFC 5357 here. The Appendix describes what is called = TWAMP-Light mode with Stateless Reflector. About year and a half the = Errata been accepted that describes Stateful Reflector, which supports = measurement of one-way latency/jitter and packet loss metrics. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey = Haas > Sent: Thursday, December 04, 2014 7:17 AM > To: Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: Re: BFD stability follow-up from IETF-91 >=20 > On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote: >> If what you say is the only requirement not met, one approach may be = to pursue a non-standard-track document describing some suggested = implementation techniques to locally store TX/RX timestamp. >>=20 >> Given that echo approach will be less accurate and given that we seem = to be having difficulty converging, I thought I???ll throw out another = idea. >=20 > I think my biggest concern is that the echo approach has bidirectional = packet loss possibilities. Async at least lets the receiver know about = unidirectional packet loss. >=20 > Of course, if your goal is to notify the sender that their packets are = being lost, you need a backchannel anyway. I just don't know if we want = that back channel to be bfd. >=20 > - Jeff >=20 From nobody Thu Dec 4 10:24:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B681AD495 for ; Thu, 4 Dec 2014 08:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 lBQoXruB1Q8N for ; Thu, 4 Dec 2014 08:16:05 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424B21AD489 for ; Thu, 4 Dec 2014 08:16:05 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id a3so12577092oib.2 for ; Thu, 04 Dec 2014 08:16:04 -0800 (PST) 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:content-type; bh=xMWLyqgLccYAOFpaiNk9tAwOsZf5HqU6yjhkKZYzFBw=; b=I+wvaQtdJdNDBO8trmUvAoo9WHGjNfuGfgt8DEEPWVGPlz//xiUjBpLXpCaTK/Pg5a ykAIvdxaqjD5U7G6Dh+GMFi8Z7sYsSbRX/CRKlS7Q1URjjQTWQ8HjvkcPxx+vL9jPJ2f Q/mbAXv+LQIunygSgJ7ssYUoDDlI6nwLbVNao02TLRcc0sdtjVs6VdiWQR8okUibWj+H exn4qR05peYKxO0frxiq2DSrO80tpdQDM1O18TjL9md637k+u7C6mCnB5Abi2wBnjZJX xbf4/rF9/V3OdmogijyFrQigqRUlJhmak9DZbS+q1I3Zol1NCLa7smGNxmLdrW5VlqzR pfVw== MIME-Version: 1.0 X-Received: by 10.60.67.70 with SMTP id l6mr7292583oet.76.1417709764459; Thu, 04 Dec 2014 08:16:04 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 08:16:04 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> Date: Thu, 4 Dec 2014 21:46:04 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a11c30a22e7c1f305096646b8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/742scHnQrG-u1Woh9zm1lS0XfAQ X-Mailman-Approved-At: Thu, 04 Dec 2014 10:24:37 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 16:16:10 -0000 --001a11c30a22e7c1f305096646b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am not sure what the confusion is Greg. Assume i have a BFD session thats up. At some point in time it flaps. Now i need to know whether the issue was at the TX or the RX. Please tell me how TWAMP can help me here. Also tell me how what tool i can use if its a uBFD session that flapped. Cheers, Manav On Thu, Dec 4, 2014 at 9:09 PM, Gregory Mirsky wrote: > Hi Santosh, > > but that is what can be called =E2=80=9Cfeature creep=E2=80=9D. BFD is co= ntinuity check > mechanism and for active performance measurement, even occasional, there > are TWAMP in IP and RFC 6374/6375 in MPLS/MPLS-TP. It may be tempting to > expand scope of BFD but, I believe, it is successful exactly because it w= as > simple, light-weight and designed to do exactly one thing =E2=80=93 conti= nuity > check. > > > > Regards, > > Greg > > > > *From:* Santosh P K [mailto:santoshpk@juniper.net] > *Sent:* Thursday, December 04, 2014 7:02 AM > *To:* Gregory Mirsky; Mahesh Jethanandani > > *Cc:* rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hello Greg, > > Debugging BFD is one of the use case. I also want to bring up one of th= e > use case that Jeff suggested in his earlier mail. Operator might NOT wan= t > to run OAM which does loss and delay measurement all the time due to its > overhead. With the extension to BFD (sequence number) we can detect if > there is any loss but BFD still stays up. This loss detection can be used > as a trigger for loss and delay measurement. Echo can be used only in cas= e > of singlehop and in one direction only. > > > > Thanks > > Santosh P K > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org > ] *On Behalf Of *Gregory Mirsky > *Sent:* Thursday, December 04, 2014 12:12 PM > *To:* Mahesh Jethanandani > *Cc:* rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hi Mahesh, > > indeed, LSP Ping is part of MPLS OAM tool set as BFD itself that intended > to monitor operational state of the network, path continuity between two > nodes. And LSP Ping, as primarily on-demand troubleshooting tool, helps > localize and, to certain degree, diagnose the problem. But the ultimate > debugging is proprietary. This proposal, in my view, helps not monitor > behavior of the network but BFD itself, quality of BFD implementation. I= =E2=80=99m > not saying that it is not useful for implementers and operators, one can > find that too many BFD sessions or at too short intervals being ran. I > don=E2=80=99t agree to loading this as extension of the widely used stand= ard. > Perhaps we can look into using BFD Echo as self-debugging instrument. > > > > Regards, > > Greg > > > > *From:* Mahesh Jethanandani [mailto:mjethanandani@gmail.com > ] > *Sent:* Wednesday, December 03, 2014 10:23 PM > *To:* Gregory Mirsky > *Cc:* Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Greg, > > > > I believe we have a disagreement here. I do not believe that issue of > debug ability are outside the scope of a standardized protocol. > > > > Look at MPLS ping and traceroute (RFC 4379) . They are ultimately debug > tools used to establish viability of a path and they are very much part o= f > the standardized protocol. > > > > On Dec 3, 2014, at 3:25 PM, Gregory Mirsky > wrote: > > > > Hi Mahesh, > > I consider issues of debugability, not of just BFD but any other > standardized protocol, to be outside of Standard track, at most to be > suitable for Informational or Experimental track. If we agree on that, th= en > we can discuss scenarios that present problem and investigate whether > anything in the protocol requires clarification to help vendors in buildi= ng > well-performing, scalable and interoperable implementations and provide > operational guidelines for operators. > > > > Regards, > > Greg > > > > *From:* Mahesh Jethanandani [mailto:mjethanandani@gmail.com > ] > *Sent:* Tuesday, December 02, 2014 8:46 PM > *To:* Gregory Mirsky > *Cc:* Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Greg, > > > > What is Peng referring to is a way to figure out why a particular BFD > session flapped, particularly if the packet(s) for that session arrive > late. I do not see how that can be performance measurement. It is basic B= FD > debug ability. Running a separate DM does tell you why a particular BFD > session flapped. > > > > Now we can debate what methods can be employed to measure that delay and = I > am open to ways to doing it, including local loopback to measure transmit > delays or time stamping of packets in hardware. But in cases, where there > is no support for either of the capabilities, one of the suggested > solutions is to use the time stamps carried in the BFD payload. > > > > Cheers. > > > > On Dec 1, 2014, at 9:38 AM, Gregory Mirsky > wrote: > > > > Hi Peng, > > and still, you=E2=80=99re looking for a tool to measure BFD performance. = Then > you=E2=80=99ll be looking for a tool to verify the BFD performance measur= ement, and > on, and on. Operators do need complete set of FCAPS tools, including > performance measurement. Note that passive performance measurement throug= h > marking method that Mach Chen referred to can monitor BFD flow(s) and be > used to do Loss and/or Delay Measurement. And active Synthetic Loss > Measurement may simulate flow of small packets as well as relatively larg= e > packets. And the same goes for active measurement method of Delay > Measurement. I like Swiss Army knives but let us not turn BFD into one. > > > > Regards, > > Greg > > > > *From:* Fan, Peng [mailto:fanpeng@chinamobile.com > ] > *Sent:* Monday, December 01, 2014 4:44 AM > *To:* Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hi Gregory, > > > > I was just giving an example :) Application traffic usually cannot stand > small packet loss, not to say 30% loss. > > > > I am actually asking for a debug function that could give us some useful > hints of poor connection with small protocol change, besides the basic > connectivity information. If it measures something, it measures packets o= f > BFD itself. So I don=E2=80=99t expect it to be considered as a performanc= e > measurement tool. > > > > Best regards, > > Peng > > > > *From:* Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > ] > *Sent:* Saturday, November 29, 2014 3:37 AM > *To:* Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hi Peng, > > this is very interesting scenario. I think that if BFD experiences ~30% > packet loss, then highly likely so are affected other applications. Then = it > is not just BFD issue but condition that should be detected by performan= ce > measurement method, whether active or passive packet loss measurement. > > I=E2=80=99m convinced that overloading BFD with performance measurement p= rovisions > is counter-productive and is inappropriate. > > > > Regards, > > Greg > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org > ] *On Behalf Of *Fan, Peng > *Sent:* Friday, November 28, 2014 4:34 AM > *To:* 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hi Mallik, > > > > Exactly. Packets may be experiencing slight loss, but the link can hardly > be regarded as connected. More importantly, the experience of upper-level > applications can be degraded severely (e.g. TCP traffic is not able to go > fast in face of even small continuous loss). But what if one BFD frame is > lost every three frames? Then the loss rate is 30% on average, which is > already a very severe value. > > > > Best regards, > > Peng > > > > *From:* MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com > ] > *Sent:* Friday, November 28, 2014 7:53 PM > *To:* Fan, Peng; rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Hi Peng, > > > > If the BFD packets are lost, doesn=E2=80=99t the BFD session go DOWN? Are= you > saying that packet loss is not big enough to make BFD session go DOWN? > > > > Thanks > > > > Regards > > Mallik > > > > *From: *, Peng > *Date: *Friday, 28 November 2014 4:20 pm > *To: *"rtg-bfd@ietf.org" > *Subject: *RE: BFD stability follow-up from IETF-91 > > > > Hi Jeff, all, > > > > I have been following this stability extension from the beginning, and as > an > > operator I would like to express that this draft enables the "advanced > > feature" we desire for BFD to provide additional useful information that > > helps operators understand network issues. A relevant use case is detecti= ng > > lossy or "quasi-disconnected" links or member LAG links. An example of su= ch > > situation we experienced was a loosely connected fiber link resulting in > > continuous, small amount of packet loss. BFD could get the information of > > lost BFD frames on such unstable link, and probably report when a target > > level is reached, say a certain number of frames are lost over a period o= r > > among a total number of frames. > > > > Best regards, > > Peng > > > > Mahesh Jethanandani > > Co-chair, NETCONF WG > > mjethanandani@gmail.com > > > > Mahesh Jethanandani > > Co-chair, NETCONF WG > > mjethanandani@gmail.com > > > > > > > --001a11c30a22e7c1f305096646b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not sure what the confusion is Greg.

Assume i have a BFD session thats up. At some point in time it flaps. No= w i need to know whether the issue was at the TX or the RX.

<= /div>
Please tell me how TWAMP can help me here. Also tell me how what = tool i can use if its a uBFD session that flapped.

Cheers, Manav

On Thu, Dec 4, 2014 at 9:09 PM, Gregory Mirsky &= lt;gregory= .mirsky@ericsson.com> wrote:

Hi Santosh,=

but that is what can be c= alled =E2=80=9Cfeature creep=E2=80=9D. BFD is continuity check mechanism an= d for active performance measurement, even occasional, there are TWAMP in IP and RFC 6374/6375 in MPLS/MPLS-TP. It may be tempting to expand scope o= f BFD but, I believe, it is successful exactly because it was simple, light= -weight and designed to do exactly one thing =E2=80=93 continuity check.=

=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: Santosh = P K [mailto:sant= oshpk@juniper.net]
Sent: Thursday, December 04, 2014 7:02 AM
To: Gregory Mirsky; Mahesh Jethanandani


Cc: rtg-bfd@ie= tf.org
Subject: RE: BFD stability follow-up from IETF-91

=C2=A0

Hello Greg,=

=C2=A0 Debugging BFD is o= ne of the use case. I also want to bring up one of the use case that Jeff s= uggested in his earlier =C2=A0mail. Operator might NOT want to run OAM which does loss and delay measurement all the time due to its overhead= . With the extension to BFD (sequence number) we can detect if there is any= loss but BFD still stays up. This loss detection can be used as a trigger = for loss and delay measurement. Echo can be used only in case of singlehop and in one direction only. =C2= =A0

=C2=A0

Thanks

Santosh P K =C2=A0=

=C2=A0

From: Rtg-bf= d [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, December 04, 2014 12:12 PM
To: Mahesh Jethanandani
Cc: rtg-bfd@ie= tf.org
Subject: RE: BFD stability follow-up from IETF-91

=C2=A0

Hi Mahesh,<= /span>

indeed, LSP Ping is part = of MPLS OAM tool set as BFD itself that intended to monitor operational sta= te of the network, path continuity between two nodes. And LSP Ping, as primarily on-demand troubleshooting tool, helps localize and,= to certain degree, diagnose the problem. But the ultimate debugging is pro= prietary. This proposal, in my view, helps not monitor behavior of the netw= ork but BFD itself, quality of BFD implementation. I=E2=80=99m not saying that it is not useful for implement= ers and operators, one can find that too many BFD sessions or at too short = intervals being=C2=A0 ran. I don=E2=80=99t agree to loading this as extensi= on of the widely used standard. Perhaps we can look into using BFD Echo as self-debugging instrument.

=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: Mahesh J= ethanandani [m= ailto:mjethanandani@gmail.com]
Sent: Wednesday, December 03, 2014 10:23 PM
To: Gregory Mirsky
Cc: Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91

=C2=A0

Greg,

=C2=A0

I believe we have a disagreement here. I do not beli= eve that issue of debug ability are outside the scope of a standardized pro= tocol.

=C2=A0

Look at MPLS ping and traceroute (RFC 4379) . They a= re ultimately debug tools used to establish viability of a path and they ar= e very much part of the standardized protocol.

=C2=A0

On Dec 3, 2014, at 3:25 PM, Gregory Mirsky <gregory.mirsky@= ericsson.com> wrote:

=C2=A0

Hi Mahesh,<= u>

I consider issues of debu= gability, not of just BFD but any other standardized protocol, to be outsid= e of Standard track, at most to be suitable for Informational or Experimental track. If we agree on that, then we can discuss scenarios = that present problem and investigate whether anything in the protocol requi= res clarification to help vendors in building well-performing, scalable and= interoperable implementations and provide operational guidelines for operators.

=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:=C2= =A0Mahesh Jethanandani [mailto:mjethanandani@gmail.com]=C2=A0
Sent:=C2=A0Tuesday, December 02, 2014 8:46 PM
To:=C2=A0Gregory Mirsky
Cc:=C2=A0Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org<= br> Subject:=C2=A0Re: BFD stability follow-up from IETF-91<= /span>

=C2=A0

Greg,

=C2=A0

What is Peng referring to is a way to figure out why= a particular BFD session flapped, particularly if the packet(s) for that s= ession arrive late. I do not see how that can be performance measurement. I= t is basic BFD debug ability. Running a separate DM does tell you why a particular BFD session flapped.

=C2=A0

Now we can debate what methods can be employed to me= asure that delay and I am open to ways to doing it, including local loopbac= k to measure transmit delays or time stamping of packets in hardware. But i= n cases, where there is no support for either of the capabilities, one of the suggested solutions is to use t= he time stamps carried in the BFD payload.=C2=A0

=C2=A0

Cheers.

=C2=A0

On Dec 1, 2014, at 9:38 AM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

=C2=A0

Hi Peng,=

and still, you=E2=80=99re= looking for a tool to measure BFD performance. Then you=E2=80=99ll be look= ing for a tool to verify the BFD performance measurement, and on, and on. Operators do need complete set of FCAPS tools, including performance measu= rement. Note that passive performance measurement through marking method th= at Mach Chen referred to can monitor BFD flow(s) and be used to do Loss and= /or Delay Measurement. And active Synthetic Loss Measurement may simulate flow of small packets as well as r= elatively large packets. And the same goes for active measurement method of= Delay Measurement. I like Swiss Army knives but let us not turn BFD into o= ne.

=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:=C2= =A0Fan, Peng [mailto:fanpeng@chinamobile.com]=C2= =A0
Sent:=C2=A0Monday, December 01, 2014 4:44 AM
To:=C2=A0Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigo= n)';=C2=A0rtg-bfd@ietf.org
Subject:=C2=A0RE: BFD stability follow-up from IETF-91<= /span>

=C2=A0

Hi Gregory,=

=C2=A0

I was just giving an exam= ple :) Application traffic usually cannot stand small packet loss, not to s= ay 30% loss.

=C2=A0

I am actually asking for = a debug function that could give us some useful hints of poor connection wi= th small protocol change, besides the basic connectivity information. If it measures something, it measures packets of BFD itself. = So I don=E2=80=99t expect it to be considered as a performance measurement = tool.

=C2=A0

Best regards,

Peng=

=C2=A0

From:=C2= =A0Gregory Mirsky [<= span style=3D"color:purple">mailto:gregory.mirsky@ericsson.com]<= span>=C2=A0
Sent:=C2=A0Saturday, November 29, 2014 3:37 AM
To:=C2=A0Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)= 9;;=C2=A0rtg-bfd@ietf.org
Subject:=C2=A0RE: BFD stability follow-up from IETF-91<= /span>

=C2=A0

Hi Peng,=

this is very interesting = scenario. I think that if BFD experiences ~30% packet loss, then highly lik= ely so are affected other applications. Then it is not just BFD issue but condition that should be detected=C2=A0 by performance measu= rement method, whether active or passive packet loss measurement.=

I=E2=80=99m convinced tha= t overloading BFD with performance measurement provisions is counter-produc= tive and is inappropriate.

=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:=C2= =A0Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Fan, Peng
Sent:=C2=A0Friday, November 28, 2014 4:34 AM
To:=C2=A0'MALLIK MUDIGONDA (mmudigon)';= =C2=A0rtg-bfd@ietf.org
Subject:=C2=A0RE: BFD stability follow-up from IETF-91<= /span>

=C2=A0

Hi Mallik,<= u>

=C2=A0

Exactly. Packets may be e= xperiencing slight loss, but the link can hardly be regarded as connected. = More importantly, the experience of upper-level applications can be degraded severely (e.g. TCP traffic is not able to go fast in face = of even small continuous loss). But what if one BFD frame is lost every thr= ee frames? Then the loss rate is 30% on average, which is already a very se= vere value.

=C2=A0

Best regards,

Peng=

=C2=A0

From:=C2= =A0MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]=C2=A0
Sent:=C2=A0Friday, November 28, 2014 7:53 PM
To:=C2=A0Fan, Peng;=C2=A0rtg-bfd@i= etf.org
Subject:=C2=A0Re: BFD stability follow-up from IETF-91<= /span>

=C2=A0

Hi Peng,

=C2=A0

If the BFD packets are lost, doesn=E2=80= =99t the BFD session go DOWN? Are you saying that packet loss is not big en= ough to make BFD session go DOWN?

=C2=A0

Thanks

=C2=A0

Regards

Mallik

=C2=A0

From:=C2=A0<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif""><Fan>, Peng <fanpeng@chinamobile.com>
Date:=C2=A0Friday, 28 November 2014 4:20 pm
To:=C2=A0"rtg-bfd@ietf.org"= ; <rtg-bfd@ietf.org>
Subject:=C2=A0RE: BFD stability follow-up from IETF-91<= /span>

=C2=A0

Hi Jeff, all,

=C2=A0

I have been following this stability exte= nsion from the beginning, and as an

operator I would like to express that thi= s draft enables the "advanced

feature" we desire for BFD to provid= e additional useful information that

helps operators understand network issues= . A relevant use case is detecting

lossy or "quasi-disconnected" l= inks or member LAG links. An example of such

situation we experienced was a loosely co= nnected fiber link resulting in

continuous, small amount of packet loss. = BFD could get the information of

lost BFD frames on such unstable link, an= d probably report when a target

level is reached, say a certain number of= frames are lost over a period or

among a total number of frames.=

=C2=A0

Best regards,

Peng

=C2=A0

Mahesh Jethanandani

Co-chair, NETCONF WG

=C2=A0

Mahesh Jethanandani

Co-chair, NETCONF WG<= /u>

=C2=A0

=C2=A0<= /p>

=C2=A0


--001a11c30a22e7c1f305096646b8-- From nobody Thu Dec 4 10:24:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FC01AD4C3 for ; Thu, 4 Dec 2014 08:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 TeyKVS2UWkVU for ; Thu, 4 Dec 2014 08:34:01 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 A76CC1AD4C2 for ; Thu, 4 Dec 2014 08:34:00 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-ce-54803ce21b89 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F8.CC.03307.2EC30845; Thu, 4 Dec 2014 11:52:19 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 11:33:18 -0500 From: Gregory Mirsky To: Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAjSUAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAF9PggASh4oD///wSUIACoyWAgADg8VCAAMxrgP//rMkggADkGwD//7U6cAAL8ywAAAn4weA= Date: Thu, 4 Dec 2014 16:33:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@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_7347100B5761DC41A166AC17F22DF1121B8AACDBeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonRPexTUOIwd43nBaXJ7WxW5x+s47N 4vOfbYwW1+5uZXZg8dg56y67x5IlP5k8rjddZQ9gjuKySUnNySxLLdK3S+DK+HnzCWPBlX0s FZuO/GZvYHywnqWLkZNDQsBE4nTreUYIW0ziwr31bF2MXBxCAkcYJVa9fM8O4SxjlPj/aAUz SBWbgJHEi4097CC2iICGROv7A2BxZoF6ictTZrKC2MIChhKruhdD1RhJHJsxF2yQiMAmRon7 S7uA1nFwsAioSLzqTwWp4RXwldiyqg9q80I2iX1N98CGcgoESkyY2gZmMwKd9/3UGiaIZeIS t57MZ4I4W0BiyZ7zzBC2qMTLx/9YIWwliY+/57ND1OdLXP57mAVimaDEyZlPWCYwis5CMmoW krJZSMpmAZ3KLKApsX6XPkSJosSU7ofsEDbQ+3PmsiOLL2BkX8XIUVqcWpabbmSwiREYecck 2HR3MO55aXmIUYCDUYmH98PU+hAh1sSy4srcQ4zSHCxK4ryzaucFCwmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamCc9X33oqx/XGIB+bLWxVXSyV4XdS7M6ZL3mu3/6JJp4Jk3U95YNjVXXJcz 99BMvZfxoeWGckBnZBkzl1+48EM75bLFbTnh+y9OtX2jqdXsm7BeW0WewfCjjML1hc3/f8ap n7EpfrmLeeXEoBtP1Ff8WG/6dEv20n2tP9qnmemXWH1P/8R49qYSS3FGoqEWc1FxIgBq9/gy nQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/nmcLU-R248SyRkMRITvCRaPx2bQ X-Mailman-Approved-At: Thu, 04 Dec 2014 10:24:38 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 16:34:09 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AACDBeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQpJIGhvcGUgeW91IGRvbuKAmXQgZXhwZWN0IG1lIHRvIGdpdmUgYSBsZWN0dXJl IG9uIGhvdyB0byBkZXNpZ24gYW5kIGltcGxlbWVudCBkZWJ1Z2FibGUgaW1wbGVtZW50YXRpb24g dXNpbmcgbG9nZ2luZyBhbmQgcGFja2V0IHRyYWNpbmcuDQoNCiAgICAgICAgICAgICAgICBSZWdh cmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IE1hbmF2 IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBE ZWNlbWJlciAwNCwgMjAxNCA4OjE2IEFNDQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBTYW50b3No IFAgSzsgTWFoZXNoIEpldGhhbmFuZGFuaTsgcnRnLWJmZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KDQpJIGFtIG5vdCBzdXJlIHdo YXQgdGhlIGNvbmZ1c2lvbiBpcyBHcmVnLg0KDQpBc3N1bWUgaSBoYXZlIGEgQkZEIHNlc3Npb24g dGhhdHMgdXAuIEF0IHNvbWUgcG9pbnQgaW4gdGltZSBpdCBmbGFwcy4gTm93IGkgbmVlZCB0byBr bm93IHdoZXRoZXIgdGhlIGlzc3VlIHdhcyBhdCB0aGUgVFggb3IgdGhlIFJYLg0KDQpQbGVhc2Ug dGVsbCBtZSBob3cgVFdBTVAgY2FuIGhlbHAgbWUgaGVyZS4gQWxzbyB0ZWxsIG1lIGhvdyB3aGF0 IHRvb2wgaSBjYW4gdXNlIGlmIGl0cyBhIHVCRkQgc2Vzc2lvbiB0aGF0IGZsYXBwZWQuDQoNCkNo ZWVycywgTWFuYXYNCg0KT24gVGh1LCBEZWMgNCwgMjAxNCBhdCA5OjA5IFBNLCBHcmVnb3J5IE1p cnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb20+PiB3cm90ZToNCkhpIFNhbnRvc2gsDQpidXQgdGhhdCBpcyB3aGF0IGNhbiBi ZSBjYWxsZWQg4oCcZmVhdHVyZSBjcmVlcOKAnS4gQkZEIGlzIGNvbnRpbnVpdHkgY2hlY2sgbWVj aGFuaXNtIGFuZCBmb3IgYWN0aXZlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LCBldmVuIG9jY2Fz aW9uYWwsIHRoZXJlIGFyZSBUV0FNUCBpbiBJUCBhbmQgUkZDIDYzNzQvNjM3NSBpbiBNUExTL01Q TFMtVFAuIEl0IG1heSBiZSB0ZW1wdGluZyB0byBleHBhbmQgc2NvcGUgb2YgQkZEIGJ1dCwgSSBi ZWxpZXZlLCBpdCBpcyBzdWNjZXNzZnVsIGV4YWN0bHkgYmVjYXVzZSBpdCB3YXMgc2ltcGxlLCBs aWdodC13ZWlnaHQgYW5kIGRlc2lnbmVkIHRvIGRvIGV4YWN0bHkgb25lIHRoaW5nIOKAkyBjb250 aW51aXR5IGNoZWNrLg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBTYW50b3NoIFAgSyBbbWFpbHRvOnNhbnRv c2hwa0BqdW5pcGVyLm5ldDxtYWlsdG86c2FudG9zaHBrQGp1bmlwZXIubmV0Pl0NClNlbnQ6IFRo dXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCA3OjAyIEFNDQpUbzogR3JlZ29yeSBNaXJza3k7IE1h aGVzaCBKZXRoYW5hbmRhbmkNCg0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRG LTkxDQoNCkhlbGxvIEdyZWcsDQogIERlYnVnZ2luZyBCRkQgaXMgb25lIG9mIHRoZSB1c2UgY2Fz ZS4gSSBhbHNvIHdhbnQgdG8gYnJpbmcgdXAgb25lIG9mIHRoZSB1c2UgY2FzZSB0aGF0IEplZmYg c3VnZ2VzdGVkIGluIGhpcyBlYXJsaWVyICBtYWlsLiBPcGVyYXRvciBtaWdodCBOT1Qgd2FudCB0 byBydW4gT0FNIHdoaWNoIGRvZXMgbG9zcyBhbmQgZGVsYXkgbWVhc3VyZW1lbnQgYWxsIHRoZSB0 aW1lIGR1ZSB0byBpdHMgb3ZlcmhlYWQuIFdpdGggdGhlIGV4dGVuc2lvbiB0byBCRkQgKHNlcXVl bmNlIG51bWJlcikgd2UgY2FuIGRldGVjdCBpZiB0aGVyZSBpcyBhbnkgbG9zcyBidXQgQkZEIHN0 aWxsIHN0YXlzIHVwLiBUaGlzIGxvc3MgZGV0ZWN0aW9uIGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dl ciBmb3IgbG9zcyBhbmQgZGVsYXkgbWVhc3VyZW1lbnQuIEVjaG8gY2FuIGJlIHVzZWQgb25seSBp biBjYXNlIG9mIHNpbmdsZWhvcCBhbmQgaW4gb25lIGRpcmVjdGlvbiBvbmx5Lg0KDQpUaGFua3MN ClNhbnRvc2ggUCBLDQoNCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnb3J5IE1pcnNreQ0KU2VudDogVGh1cnNkYXksIERlY2Vt YmVyIDA0LCAyMDE0IDEyOjEyIFBNDQpUbzogTWFoZXNoIEpldGhhbmFuZGFuaQ0KQ2M6IHJ0Zy1i ZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogQkZEIHN0 YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIE1haGVzaCwNCmluZGVlZCwgTFNQ IFBpbmcgaXMgcGFydCBvZiBNUExTIE9BTSB0b29sIHNldCBhcyBCRkQgaXRzZWxmIHRoYXQgaW50 ZW5kZWQgdG8gbW9uaXRvciBvcGVyYXRpb25hbCBzdGF0ZSBvZiB0aGUgbmV0d29yaywgcGF0aCBj b250aW51aXR5IGJldHdlZW4gdHdvIG5vZGVzLiBBbmQgTFNQIFBpbmcsIGFzIHByaW1hcmlseSBv bi1kZW1hbmQgdHJvdWJsZXNob290aW5nIHRvb2wsIGhlbHBzIGxvY2FsaXplIGFuZCwgdG8gY2Vy dGFpbiBkZWdyZWUsIGRpYWdub3NlIHRoZSBwcm9ibGVtLiBCdXQgdGhlIHVsdGltYXRlIGRlYnVn Z2luZyBpcyBwcm9wcmlldGFyeS4gVGhpcyBwcm9wb3NhbCwgaW4gbXkgdmlldywgaGVscHMgbm90 IG1vbml0b3IgYmVoYXZpb3Igb2YgdGhlIG5ldHdvcmsgYnV0IEJGRCBpdHNlbGYsIHF1YWxpdHkg b2YgQkZEIGltcGxlbWVudGF0aW9uLiBJ4oCZbSBub3Qgc2F5aW5nIHRoYXQgaXQgaXMgbm90IHVz ZWZ1bCBmb3IgaW1wbGVtZW50ZXJzIGFuZCBvcGVyYXRvcnMsIG9uZSBjYW4gZmluZCB0aGF0IHRv byBtYW55IEJGRCBzZXNzaW9ucyBvciBhdCB0b28gc2hvcnQgaW50ZXJ2YWxzIGJlaW5nICByYW4u IEkgZG9u4oCZdCBhZ3JlZSB0byBsb2FkaW5nIHRoaXMgYXMgZXh0ZW5zaW9uIG9mIHRoZSB3aWRl bHkgdXNlZCBzdGFuZGFyZC4gUGVyaGFwcyB3ZSBjYW4gbG9vayBpbnRvIHVzaW5nIEJGRCBFY2hv IGFzIHNlbGYtZGVidWdnaW5nIGluc3RydW1lbnQuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRz LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IE1haGVzaCBK ZXRoYW5hbmRhbmkgW21haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5l c2RheSwgRGVjZW1iZXIgMDMsIDIwMTQgMTA6MjMgUE0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6 IEZhbiwgUGVuZzsgTUFMTElLIE1VRElHT05EQSAobW11ZGlnb24pOyBydGctYmZkQGlldGYub3Jn PG1haWx0bzpydGctYmZkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEJGRCBzdGFiaWxpdHkgZm9s bG93LXVwIGZyb20gSUVURi05MQ0KDQpHcmVnLA0KDQpJIGJlbGlldmUgd2UgaGF2ZSBhIGRpc2Fn cmVlbWVudCBoZXJlLiBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgaXNzdWUgb2YgZGVidWcgYWJpbGl0 eSBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgYSBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wuDQoNCkxv b2sgYXQgTVBMUyBwaW5nIGFuZCB0cmFjZXJvdXRlIChSRkMgNDM3OSkgLiBUaGV5IGFyZSB1bHRp bWF0ZWx5IGRlYnVnIHRvb2xzIHVzZWQgdG8gZXN0YWJsaXNoIHZpYWJpbGl0eSBvZiBhIHBhdGgg YW5kIHRoZXkgYXJlIHZlcnkgbXVjaCBwYXJ0IG9mIHRoZSBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wu DQoNCk9uIERlYyAzLCAyMDE0LCBhdCAzOjI1IFBNLCBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5t aXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PiB3 cm90ZToNCg0KSGkgTWFoZXNoLA0KSSBjb25zaWRlciBpc3N1ZXMgb2YgZGVidWdhYmlsaXR5LCBu b3Qgb2YganVzdCBCRkQgYnV0IGFueSBvdGhlciBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wsIHRvIGJl IG91dHNpZGUgb2YgU3RhbmRhcmQgdHJhY2ssIGF0IG1vc3QgdG8gYmUgc3VpdGFibGUgZm9yIElu Zm9ybWF0aW9uYWwgb3IgRXhwZXJpbWVudGFsIHRyYWNrLiBJZiB3ZSBhZ3JlZSBvbiB0aGF0LCB0 aGVuIHdlIGNhbiBkaXNjdXNzIHNjZW5hcmlvcyB0aGF0IHByZXNlbnQgcHJvYmxlbSBhbmQgaW52 ZXN0aWdhdGUgd2hldGhlciBhbnl0aGluZyBpbiB0aGUgcHJvdG9jb2wgcmVxdWlyZXMgY2xhcmlm aWNhdGlvbiB0byBoZWxwIHZlbmRvcnMgaW4gYnVpbGRpbmcgd2VsbC1wZXJmb3JtaW5nLCBzY2Fs YWJsZSBhbmQgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgYW5kIHByb3ZpZGUgb3BlcmF0 aW9uYWwgZ3VpZGVsaW5lcyBmb3Igb3BlcmF0b3JzLg0KDQogICAgICAgICAgICAgICAgUmVnYXJk cywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBNYWhlc2gg SmV0aGFuYW5kYW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb21dDQpTZW50OiBUdWVz ZGF5LCBEZWNlbWJlciAwMiwgMjAxNCA4OjQ2IFBNDQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBG YW4sIFBlbmc7IE1BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKTsgcnRnLWJmZEBpZXRmLm9yZzxt YWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBCRkQgc3RhYmlsaXR5IGZvbGxv dy11cCBmcm9tIElFVEYtOTENCg0KR3JlZywNCg0KV2hhdCBpcyBQZW5nIHJlZmVycmluZyB0byBp cyBhIHdheSB0byBmaWd1cmUgb3V0IHdoeSBhIHBhcnRpY3VsYXIgQkZEIHNlc3Npb24gZmxhcHBl ZCwgcGFydGljdWxhcmx5IGlmIHRoZSBwYWNrZXQocykgZm9yIHRoYXQgc2Vzc2lvbiBhcnJpdmUg bGF0ZS4gSSBkbyBub3Qgc2VlIGhvdyB0aGF0IGNhbiBiZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVu dC4gSXQgaXMgYmFzaWMgQkZEIGRlYnVnIGFiaWxpdHkuIFJ1bm5pbmcgYSBzZXBhcmF0ZSBETSBk b2VzIHRlbGwgeW91IHdoeSBhIHBhcnRpY3VsYXIgQkZEIHNlc3Npb24gZmxhcHBlZC4NCg0KTm93 IHdlIGNhbiBkZWJhdGUgd2hhdCBtZXRob2RzIGNhbiBiZSBlbXBsb3llZCB0byBtZWFzdXJlIHRo YXQgZGVsYXkgYW5kIEkgYW0gb3BlbiB0byB3YXlzIHRvIGRvaW5nIGl0LCBpbmNsdWRpbmcgbG9j YWwgbG9vcGJhY2sgdG8gbWVhc3VyZSB0cmFuc21pdCBkZWxheXMgb3IgdGltZSBzdGFtcGluZyBv ZiBwYWNrZXRzIGluIGhhcmR3YXJlLiBCdXQgaW4gY2FzZXMsIHdoZXJlIHRoZXJlIGlzIG5vIHN1 cHBvcnQgZm9yIGVpdGhlciBvZiB0aGUgY2FwYWJpbGl0aWVzLCBvbmUgb2YgdGhlIHN1Z2dlc3Rl ZCBzb2x1dGlvbnMgaXMgdG8gdXNlIHRoZSB0aW1lIHN0YW1wcyBjYXJyaWVkIGluIHRoZSBCRkQg cGF5bG9hZC4NCg0KQ2hlZXJzLg0KDQpPbiBEZWMgMSwgMjAxNCwgYXQgOTozOCBBTSwgR3JlZ29y eSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJz a3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpIFBlbmcsDQphbmQgc3RpbGwsIHlvdeKAmXJl IGxvb2tpbmcgZm9yIGEgdG9vbCB0byBtZWFzdXJlIEJGRCBwZXJmb3JtYW5jZS4gVGhlbiB5b3Xi gJlsbCBiZSBsb29raW5nIGZvciBhIHRvb2wgdG8gdmVyaWZ5IHRoZSBCRkQgcGVyZm9ybWFuY2Ug bWVhc3VyZW1lbnQsIGFuZCBvbiwgYW5kIG9uLiBPcGVyYXRvcnMgZG8gbmVlZCBjb21wbGV0ZSBz ZXQgb2YgRkNBUFMgdG9vbHMsIGluY2x1ZGluZyBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudC4gTm90 ZSB0aGF0IHBhc3NpdmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgdGhyb3VnaCBtYXJraW5nIG1l dGhvZCB0aGF0IE1hY2ggQ2hlbiByZWZlcnJlZCB0byBjYW4gbW9uaXRvciBCRkQgZmxvdyhzKSBh bmQgYmUgdXNlZCB0byBkbyBMb3NzIGFuZC9vciBEZWxheSBNZWFzdXJlbWVudC4gQW5kIGFjdGl2 ZSBTeW50aGV0aWMgTG9zcyBNZWFzdXJlbWVudCBtYXkgc2ltdWxhdGUgZmxvdyBvZiBzbWFsbCBw YWNrZXRzIGFzIHdlbGwgYXMgcmVsYXRpdmVseSBsYXJnZSBwYWNrZXRzLiBBbmQgdGhlIHNhbWUg Z29lcyBmb3IgYWN0aXZlIG1lYXN1cmVtZW50IG1ldGhvZCBvZiBEZWxheSBNZWFzdXJlbWVudC4g SSBsaWtlIFN3aXNzIEFybXkga25pdmVzIGJ1dCBsZXQgdXMgbm90IHR1cm4gQkZEIGludG8gb25l Lg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgR3JlZw0KDQpGcm9tOiBGYW4sIFBlbmcgW21haWx0bzpmYW5wZW5nQGNoaW5hbW9iaWxl LmNvbV0NClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDEsIDIwMTQgNDo0NCBBTQ0KVG86IEdyZWdv cnkgTWlyc2t5OyAnTUFMTElLIE1VRElHT05EQSAobW11ZGlnb24pJzsgcnRnLWJmZEBpZXRmLm9y ZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5IGZv bGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGkgR3JlZ29yeSwNCg0KSSB3YXMganVzdCBnaXZpbmcg YW4gZXhhbXBsZSA6KSBBcHBsaWNhdGlvbiB0cmFmZmljIHVzdWFsbHkgY2Fubm90IHN0YW5kIHNt YWxsIHBhY2tldCBsb3NzLCBub3QgdG8gc2F5IDMwJSBsb3NzLg0KDQpJIGFtIGFjdHVhbGx5IGFz a2luZyBmb3IgYSBkZWJ1ZyBmdW5jdGlvbiB0aGF0IGNvdWxkIGdpdmUgdXMgc29tZSB1c2VmdWwg aGludHMgb2YgcG9vciBjb25uZWN0aW9uIHdpdGggc21hbGwgcHJvdG9jb2wgY2hhbmdlLCBiZXNp ZGVzIHRoZSBiYXNpYyBjb25uZWN0aXZpdHkgaW5mb3JtYXRpb24uIElmIGl0IG1lYXN1cmVzIHNv bWV0aGluZywgaXQgbWVhc3VyZXMgcGFja2V0cyBvZiBCRkQgaXRzZWxmLiBTbyBJIGRvbuKAmXQg ZXhwZWN0IGl0IHRvIGJlIGNvbnNpZGVyZWQgYXMgYSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCB0 b29sLg0KDQpCZXN0IHJlZ2FyZHMsDQpQZW5nDQoNCkZyb206IEdyZWdvcnkgTWlyc2t5IFttYWls dG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tXQ0KU2VudDogU2F0dXJkYXksIE5vdmVtYmVy IDI5LCAyMDE0IDM6MzcgQU0NClRvOiBGYW4sIFBlbmc7ICdNQUxMSUsgTVVESUdPTkRBIChtbXVk aWdvbiknOyBydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPg0KU3ViamVj dDogUkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KDQpIaSBQZW5nLA0K dGhpcyBpcyB2ZXJ5IGludGVyZXN0aW5nIHNjZW5hcmlvLiBJIHRoaW5rIHRoYXQgaWYgQkZEIGV4 cGVyaWVuY2VzIH4zMCUgcGFja2V0IGxvc3MsIHRoZW4gaGlnaGx5IGxpa2VseSBzbyBhcmUgYWZm ZWN0ZWQgb3RoZXIgYXBwbGljYXRpb25zLiBUaGVuIGl0IGlzIG5vdCBqdXN0IEJGRCBpc3N1ZSBi dXQgY29uZGl0aW9uIHRoYXQgc2hvdWxkIGJlIGRldGVjdGVkICBieSBwZXJmb3JtYW5jZSBtZWFz dXJlbWVudCBtZXRob2QsIHdoZXRoZXIgYWN0aXZlIG9yIHBhc3NpdmUgcGFja2V0IGxvc3MgbWVh c3VyZW1lbnQuDQpJ4oCZbSBjb252aW5jZWQgdGhhdCBvdmVybG9hZGluZyBCRkQgd2l0aCBwZXJm b3JtYW5jZSBtZWFzdXJlbWVudCBwcm92aXNpb25zIGlzIGNvdW50ZXItcHJvZHVjdGl2ZSBhbmQg aXMgaW5hcHByb3ByaWF0ZS4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1i ZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZhbiwgUGVuZw0KU2VudDogRnJpZGF5 LCBOb3ZlbWJlciAyOCwgMjAxNCA0OjM0IEFNDQpUbzogJ01BTExJSyBNVURJR09OREEgKG1tdWRp Z29uKSc7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIE1hbGxpaywN Cg0KRXhhY3RseS4gUGFja2V0cyBtYXkgYmUgZXhwZXJpZW5jaW5nIHNsaWdodCBsb3NzLCBidXQg dGhlIGxpbmsgY2FuIGhhcmRseSBiZSByZWdhcmRlZCBhcyBjb25uZWN0ZWQuIE1vcmUgaW1wb3J0 YW50bHksIHRoZSBleHBlcmllbmNlIG9mIHVwcGVyLWxldmVsIGFwcGxpY2F0aW9ucyBjYW4gYmUg ZGVncmFkZWQgc2V2ZXJlbHkgKGUuZy4gVENQIHRyYWZmaWMgaXMgbm90IGFibGUgdG8gZ28gZmFz dCBpbiBmYWNlIG9mIGV2ZW4gc21hbGwgY29udGludW91cyBsb3NzKS4gQnV0IHdoYXQgaWYgb25l IEJGRCBmcmFtZSBpcyBsb3N0IGV2ZXJ5IHRocmVlIGZyYW1lcz8gVGhlbiB0aGUgbG9zcyByYXRl IGlzIDMwJSBvbiBhdmVyYWdlLCB3aGljaCBpcyBhbHJlYWR5IGEgdmVyeSBzZXZlcmUgdmFsdWUu DQoNCkJlc3QgcmVnYXJkcywNClBlbmcNCg0KRnJvbTogTUFMTElLIE1VRElHT05EQSAobW11ZGln b24pIFttYWlsdG86bW11ZGlnb25AY2lzY28uY29tXQ0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAy OCwgMjAxNCA3OjUzIFBNDQpUbzogRmFuLCBQZW5nOyBydGctYmZkQGlldGYub3JnPG1haWx0bzpy dGctYmZkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZy b20gSUVURi05MQ0KDQpIaSBQZW5nLA0KDQpJZiB0aGUgQkZEIHBhY2tldHMgYXJlIGxvc3QsIGRv ZXNu4oCZdCB0aGUgQkZEIHNlc3Npb24gZ28gRE9XTj8gQXJlIHlvdSBzYXlpbmcgdGhhdCBwYWNr ZXQgbG9zcyBpcyBub3QgYmlnIGVub3VnaCB0byBtYWtlIEJGRCBzZXNzaW9uIGdvIERPV04/DQoN ClRoYW5rcw0KDQpSZWdhcmRzDQpNYWxsaWsNCg0KRnJvbTogPEZhbj4sIFBlbmcgPGZhbnBlbmdA Y2hpbmFtb2JpbGUuY29tPG1haWx0bzpmYW5wZW5nQGNoaW5hbW9iaWxlLmNvbT4+DQpEYXRlOiBG cmlkYXksIDI4IE5vdmVtYmVyIDIwMTQgNDoyMCBwbQ0KVG86ICJydGctYmZkQGlldGYub3JnPG1h aWx0bzpydGctYmZkQGlldGYub3JnPiIgPHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVU Ri05MQ0KDQpIaSBKZWZmLCBhbGwsDQoNCkkgaGF2ZSBiZWVuIGZvbGxvd2luZyB0aGlzIHN0YWJp bGl0eSBleHRlbnNpb24gZnJvbSB0aGUgYmVnaW5uaW5nLCBhbmQgYXMgYW4NCm9wZXJhdG9yIEkg d291bGQgbGlrZSB0byBleHByZXNzIHRoYXQgdGhpcyBkcmFmdCBlbmFibGVzIHRoZSAiYWR2YW5j ZWQNCmZlYXR1cmUiIHdlIGRlc2lyZSBmb3IgQkZEIHRvIHByb3ZpZGUgYWRkaXRpb25hbCB1c2Vm dWwgaW5mb3JtYXRpb24gdGhhdA0KaGVscHMgb3BlcmF0b3JzIHVuZGVyc3RhbmQgbmV0d29yayBp c3N1ZXMuIEEgcmVsZXZhbnQgdXNlIGNhc2UgaXMgZGV0ZWN0aW5nDQpsb3NzeSBvciAicXVhc2kt ZGlzY29ubmVjdGVkIiBsaW5rcyBvciBtZW1iZXIgTEFHIGxpbmtzLiBBbiBleGFtcGxlIG9mIHN1 Y2gNCnNpdHVhdGlvbiB3ZSBleHBlcmllbmNlZCB3YXMgYSBsb29zZWx5IGNvbm5lY3RlZCBmaWJl ciBsaW5rIHJlc3VsdGluZyBpbg0KY29udGludW91cywgc21hbGwgYW1vdW50IG9mIHBhY2tldCBs b3NzLiBCRkQgY291bGQgZ2V0IHRoZSBpbmZvcm1hdGlvbiBvZg0KbG9zdCBCRkQgZnJhbWVzIG9u IHN1Y2ggdW5zdGFibGUgbGluaywgYW5kIHByb2JhYmx5IHJlcG9ydCB3aGVuIGEgdGFyZ2V0DQps ZXZlbCBpcyByZWFjaGVkLCBzYXkgYSBjZXJ0YWluIG51bWJlciBvZiBmcmFtZXMgYXJlIGxvc3Qg b3ZlciBhIHBlcmlvZCBvcg0KYW1vbmcgYSB0b3RhbCBudW1iZXIgb2YgZnJhbWVzLg0KDQpCZXN0 IHJlZ2FyZHMsDQpQZW5nDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCkNvLWNoYWlyLCBORVRDT05G IFdHDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5j b20+DQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCkNvLWNoYWlyLCBORVRDT05GIFdHDQptamV0aGFu YW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoN Cg== --_000_7347100B5761DC41A166AC17F22DF1121B8AACDBeusaamb103erics_ 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 N0QiPkkgaG9wZSB5b3UgZG9u4oCZdCBleHBlY3QgbWUgdG8gZ2l2ZSBhIGxlY3R1cmUgb24gaG93 IHRvIGRlc2lnbiBhbmQgaW1wbGVtZW50IGRlYnVnYWJsZSBpbXBsZW1lbnRhdGlvbiB1c2luZyBs b2dnaW5nIGFuZCBwYWNrZXQgdHJhY2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gTWFuYXYgQmhhdGlhIFttYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCA4OjE2IEFNPGJyPg0KPGI+VG86 PC9iPiBHcmVnb3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj4gU2FudG9zaCBQIEs7IE1haGVzaCBK ZXRoYW5hbmRhbmk7IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEJG RCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IHN1cmUgd2hhdCB0aGUgY29uZnVzaW9uIGlzIEdyZWcu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bc3N1bWUgaSBo YXZlIGEgQkZEIHNlc3Npb24gdGhhdHMgdXAuIEF0IHNvbWUgcG9pbnQgaW4gdGltZSBpdCBmbGFw cy4gTm93IGkgbmVlZCB0byBrbm93IHdoZXRoZXIgdGhlIGlzc3VlIHdhcyBhdCB0aGUgVFggb3Ig dGhlIFJYLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5QbGVhc2UgdGVsbCBtZSBob3cgVFdBTVAgY2FuIGhlbHAgbWUgaGVyZS4gQWxzbyB0ZWxs IG1lIGhvdyB3aGF0IHRvb2wgaSBjYW4gdXNlIGlmIGl0cyBhIHVCRkQgc2Vzc2lvbiB0aGF0IGZs YXBwZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNoZWVycywgTWFuYXY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVGh1LCBEZWMgNCwgMjAxNCBhdCA5OjA5IFBNLCBHcmVnb3J5IE1p cnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBTYW50b3NoLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmJ1dCB0aGF0IGlzIHdoYXQgY2FuIGJlIGNhbGxlZCDi gJxmZWF0dXJlIGNyZWVw4oCdLiBCRkQgaXMgY29udGludWl0eSBjaGVjayBtZWNoYW5pc20gYW5k IGZvciBhY3RpdmUNCiBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCwgZXZlbiBvY2Nhc2lvbmFsLCB0 aGVyZSBhcmUgVFdBTVAgaW4gSVAgYW5kIFJGQyA2Mzc0LzYzNzUgaW4gTVBMUy9NUExTLVRQLiBJ dCBtYXkgYmUgdGVtcHRpbmcgdG8gZXhwYW5kIHNjb3BlIG9mIEJGRCBidXQsIEkgYmVsaWV2ZSwg aXQgaXMgc3VjY2Vzc2Z1bCBleGFjdGx5IGJlY2F1c2UgaXQgd2FzIHNpbXBsZSwgbGlnaHQtd2Vp Z2h0IGFuZCBkZXNpZ25lZCB0byBkbyBleGFjdGx5IG9uZSB0aGluZyDigJMNCiBjb250aW51aXR5 IGNoZWNrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBS ZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBH cmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNhbnRvc2ggUCBLIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnNhbnRvc2hwa0BqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnNhbnRvc2hwa0Bq dW5pcGVyLm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDA0 LCAyMDE0IDc6MDIgQU08YnI+DQo8Yj5Ubzo8L2I+IEdyZWdvcnkgTWlyc2t5OyBNYWhlc2ggSmV0 aGFuYW5kYW5pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyBH cmVnLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyBEZWJ1Z2dpbmcgQkZE IGlzIG9uZSBvZiB0aGUgdXNlIGNhc2UuIEkgYWxzbyB3YW50IHRvIGJyaW5nIHVwIG9uZSBvZiB0 aGUgdXNlIGNhc2UgdGhhdCBKZWZmIHN1Z2dlc3RlZA0KIGluIGhpcyBlYXJsaWVyICZuYnNwO21h aWwuIE9wZXJhdG9yIG1pZ2h0IE5PVCB3YW50IHRvIHJ1biBPQU0gd2hpY2ggZG9lcyBsb3NzIGFu ZCBkZWxheSBtZWFzdXJlbWVudCBhbGwgdGhlIHRpbWUgZHVlIHRvIGl0cyBvdmVyaGVhZC4gV2l0 aCB0aGUgZXh0ZW5zaW9uIHRvIEJGRCAoc2VxdWVuY2UgbnVtYmVyKSB3ZSBjYW4gZGV0ZWN0IGlm IHRoZXJlIGlzIGFueSBsb3NzIGJ1dCBCRkQgc3RpbGwgc3RheXMgdXAuIFRoaXMgbG9zcyBkZXRl Y3Rpb24gY2FuDQogYmUgdXNlZCBhcyBhIHRyaWdnZXIgZm9yIGxvc3MgYW5kIGRlbGF5IG1lYXN1 cmVtZW50LiBFY2hvIGNhbiBiZSB1c2VkIG9ubHkgaW4gY2FzZSBvZiBzaW5nbGVob3AgYW5kIGlu IG9uZSBkaXJlY3Rpb24gb25seS4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2FudG9zaCBQIEsgJm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy1iZmQgWzxhIGhyZWY9Im1h aWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cnRn LWJmZC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+R3JlZ29yeSBN aXJza3k8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDEyOjEy IFBNPGJyPg0KPGI+VG86PC9iPiBNYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGI+Q2M6PC9iPiA8 YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1iZmRA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxv dy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhp IE1haGVzaCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5pbmRlZWQsIExTUCBQaW5n IGlzIHBhcnQgb2YgTVBMUyBPQU0gdG9vbCBzZXQgYXMgQkZEIGl0c2VsZiB0aGF0IGludGVuZGVk IHRvIG1vbml0b3Igb3BlcmF0aW9uYWwNCiBzdGF0ZSBvZiB0aGUgbmV0d29yaywgcGF0aCBjb250 aW51aXR5IGJldHdlZW4gdHdvIG5vZGVzLiBBbmQgTFNQIFBpbmcsIGFzIHByaW1hcmlseSBvbi1k ZW1hbmQgdHJvdWJsZXNob290aW5nIHRvb2wsIGhlbHBzIGxvY2FsaXplIGFuZCwgdG8gY2VydGFp biBkZWdyZWUsIGRpYWdub3NlIHRoZSBwcm9ibGVtLiBCdXQgdGhlIHVsdGltYXRlIGRlYnVnZ2lu ZyBpcyBwcm9wcmlldGFyeS4gVGhpcyBwcm9wb3NhbCwgaW4gbXkgdmlldywgaGVscHMgbm90DQog bW9uaXRvciBiZWhhdmlvciBvZiB0aGUgbmV0d29yayBidXQgQkZEIGl0c2VsZiwgcXVhbGl0eSBv ZiBCRkQgaW1wbGVtZW50YXRpb24uIEnigJltIG5vdCBzYXlpbmcgdGhhdCBpdCBpcyBub3QgdXNl ZnVsIGZvciBpbXBsZW1lbnRlcnMgYW5kIG9wZXJhdG9ycywgb25lIGNhbiBmaW5kIHRoYXQgdG9v IG1hbnkgQkZEIHNlc3Npb25zIG9yIGF0IHRvbyBzaG9ydCBpbnRlcnZhbHMgYmVpbmcmbmJzcDsg cmFuLiBJIGRvbuKAmXQgYWdyZWUgdG8gbG9hZGluZyB0aGlzDQogYXMgZXh0ZW5zaW9uIG9mIHRo ZSB3aWRlbHkgdXNlZCBzdGFuZGFyZC4gUGVyaGFwcyB3ZSBjYW4gbG9vayBpbnRvIHVzaW5nIEJG RCBFY2hvIGFzIHNlbGYtZGVidWdnaW5nIGluc3RydW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g TWFoZXNoIEpldGhhbmFuZGFuaSBbPGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIERlY2VtYmVyIDAzLCAyMDE0IDEwOjIzIFBN PGJyPg0KPGI+VG86PC9iPiBHcmVnb3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj4gRmFuLCBQZW5n OyBNQUxMSUsgTVVESUdPTkRBIChtbXVkaWdvbik7IDxhIGhyZWY9Im1haWx0bzpydGctYmZkQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGctYmZkQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkdyZWcsPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBiZWxpZXZlIHdl IGhhdmUgYSBkaXNhZ3JlZW1lbnQgaGVyZS4gSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGlzc3VlIG9m IGRlYnVnIGFiaWxpdHkgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIGEgc3RhbmRhcmRpemVkIHBy b3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+TG9vayBhdCBNUExTIHBpbmcgYW5kIHRyYWNlcm91dGUgKFJGQyA0Mzc5KSAuIFRo ZXkgYXJlIHVsdGltYXRlbHkgZGVidWcgdG9vbHMgdXNlZCB0byBlc3RhYmxpc2ggdmlhYmlsaXR5 IG9mIGEgcGF0aCBhbmQgdGhleSBhcmUgdmVyeSBtdWNoIHBhcnQgb2YgdGhlIHN0YW5kYXJkaXpl ZCBwcm90b2NvbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBEZWMgMywgMjAxNCwgYXQgMzoyNSBQTSwgR3JlZ29yeSBNaXJza3kg Jmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iIHRhcmdldD0i X2JsYW5rIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFoZXNoLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY29uc2lkZXIgaXNzdWVzIG9mIGRlYnVn YWJpbGl0eSwgbm90IG9mIGp1c3QgQkZEIGJ1dCBhbnkgb3RoZXIgc3RhbmRhcmRpemVkIHByb3Rv Y29sLCB0byBiZSBvdXRzaWRlDQogb2YgU3RhbmRhcmQgdHJhY2ssIGF0IG1vc3QgdG8gYmUgc3Vp dGFibGUgZm9yIEluZm9ybWF0aW9uYWwgb3IgRXhwZXJpbWVudGFsIHRyYWNrLiBJZiB3ZSBhZ3Jl ZSBvbiB0aGF0LCB0aGVuIHdlIGNhbiBkaXNjdXNzIHNjZW5hcmlvcyB0aGF0IHByZXNlbnQgcHJv YmxlbSBhbmQgaW52ZXN0aWdhdGUgd2hldGhlciBhbnl0aGluZyBpbiB0aGUgcHJvdG9jb2wgcmVx dWlyZXMgY2xhcmlmaWNhdGlvbiB0byBoZWxwIHZlbmRvcnMgaW4gYnVpbGRpbmcgd2VsbC1wZXJm b3JtaW5nLA0KIHNjYWxhYmxlIGFuZCBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBhbmQg cHJvdmlkZSBvcGVyYXRpb25hbCBndWlkZWxpbmVzIGZvciBvcGVyYXRvcnMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDtNYWhlc2ggSmV0aGFuYW5kYW5pIFs8YSBo cmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWls dG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+XSZuYnNwOzxicj4NCjxiPlNlbnQ6PC9iPiZu YnNwO1R1ZXNkYXksIERlY2VtYmVyIDAyLCAyMDE0IDg6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+Jm5i c3A7R3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7RmFuLCBQZW5nOyBNQUxMSUsg TVVESUdPTkRBIChtbXVkaWdvbik7IDxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+DQpydGctYmZkQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiZuYnNwO1JlOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+R3JlZyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0IGlzIFBlbmcg cmVmZXJyaW5nIHRvIGlzIGEgd2F5IHRvIGZpZ3VyZSBvdXQgd2h5IGEgcGFydGljdWxhciBCRkQg c2Vzc2lvbiBmbGFwcGVkLCBwYXJ0aWN1bGFybHkgaWYgdGhlIHBhY2tldChzKSBmb3IgdGhhdCBz ZXNzaW9uIGFycml2ZSBsYXRlLiBJIGRvIG5vdCBzZWUgaG93IHRoYXQgY2FuIGJlIHBlcmZvcm1h bmNlDQogbWVhc3VyZW1lbnQuIEl0IGlzIGJhc2ljIEJGRCBkZWJ1ZyBhYmlsaXR5LiBSdW5uaW5n IGEgc2VwYXJhdGUgRE0gZG9lcyB0ZWxsIHlvdSB3aHkgYSBwYXJ0aWN1bGFyIEJGRCBzZXNzaW9u IGZsYXBwZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ob3cgd2UgY2FuIGRlYmF0 ZSB3aGF0IG1ldGhvZHMgY2FuIGJlIGVtcGxveWVkIHRvIG1lYXN1cmUgdGhhdCBkZWxheSBhbmQg SSBhbSBvcGVuIHRvIHdheXMgdG8gZG9pbmcgaXQsIGluY2x1ZGluZyBsb2NhbCBsb29wYmFjayB0 byBtZWFzdXJlIHRyYW5zbWl0IGRlbGF5cyBvciB0aW1lIHN0YW1waW5nIG9mIHBhY2tldHMNCiBp biBoYXJkd2FyZS4gQnV0IGluIGNhc2VzLCB3aGVyZSB0aGVyZSBpcyBubyBzdXBwb3J0IGZvciBl aXRoZXIgb2YgdGhlIGNhcGFiaWxpdGllcywgb25lIG9mIHRoZSBzdWdnZXN0ZWQgc29sdXRpb25z IGlzIHRvIHVzZSB0aGUgdGltZSBzdGFtcHMgY2FycmllZCBpbiB0aGUgQkZEIHBheWxvYWQuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGVlcnMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gRGVjIDEsIDIwMTQsIGF0IDk6MzggQU0sIEdyZWdvcnkgTWly c2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Z3JlZ29yeS5taXJza3lAZXJp Y3Nzb24uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBQZW5nLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFu ZCBzdGlsbCwgeW914oCZcmUgbG9va2luZyBmb3IgYSB0b29sIHRvIG1lYXN1cmUgQkZEIHBlcmZv cm1hbmNlLiBUaGVuIHlvdeKAmWxsIGJlIGxvb2tpbmcgZm9yIGEgdG9vbA0KIHRvIHZlcmlmeSB0 aGUgQkZEIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LCBhbmQgb24sIGFuZCBvbi4gT3BlcmF0b3Jz IGRvIG5lZWQgY29tcGxldGUgc2V0IG9mIEZDQVBTIHRvb2xzLCBpbmNsdWRpbmcgcGVyZm9ybWFu Y2UgbWVhc3VyZW1lbnQuIE5vdGUgdGhhdCBwYXNzaXZlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50 IHRocm91Z2ggbWFya2luZyBtZXRob2QgdGhhdCBNYWNoIENoZW4gcmVmZXJyZWQgdG8gY2FuIG1v bml0b3IgQkZEIGZsb3cocykNCiBhbmQgYmUgdXNlZCB0byBkbyBMb3NzIGFuZC9vciBEZWxheSBN ZWFzdXJlbWVudC4gQW5kIGFjdGl2ZSBTeW50aGV0aWMgTG9zcyBNZWFzdXJlbWVudCBtYXkgc2lt dWxhdGUgZmxvdyBvZiBzbWFsbCBwYWNrZXRzIGFzIHdlbGwgYXMgcmVsYXRpdmVseSBsYXJnZSBw YWNrZXRzLiBBbmQgdGhlIHNhbWUgZ29lcyBmb3IgYWN0aXZlIG1lYXN1cmVtZW50IG1ldGhvZCBv ZiBEZWxheSBNZWFzdXJlbWVudC4gSSBsaWtlIFN3aXNzIEFybXkga25pdmVzIGJ1dA0KIGxldCB1 cyBub3QgdHVybiBCRkQgaW50byBvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDtGYW4sIFBlbmcgWzxhIGhyZWY9Im1haWx0bzpm YW5wZW5nQGNoaW5hbW9iaWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPm1haWx0bzpmYW5wZW5nQGNoaW5hbW9iaWxlLmNvbTwvc3Bhbj48L2E+XSZuYnNw Ozxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO01vbmRheSwgRGVjZW1iZXIgMDEsIDIwMTQgNDo0NCBB TTxicj4NCjxiPlRvOjwvYj4mbmJzcDtHcmVnb3J5IE1pcnNreTsgJ01BTExJSyBNVURJR09OREEg KG1tdWRpZ29uKSc7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGctYmZkQGlldGYub3JnPC9z cGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtSRTogQkZEIHN0YWJpbGl0eSBmb2xs b3ctdXAgZnJvbSBJRVRGLTkxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSBHcmVnb3J5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd2FzIGp1c3QgZ2l2aW5nIGFuIGV4YW1w bGUgOikgQXBwbGljYXRpb24gdHJhZmZpYyB1c3VhbGx5IGNhbm5vdCBzdGFuZCBzbWFsbCBwYWNr ZXQgbG9zcywgbm90IHRvDQogc2F5IDMwJSBsb3NzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gYWN0 dWFsbHkgYXNraW5nIGZvciBhIGRlYnVnIGZ1bmN0aW9uIHRoYXQgY291bGQgZ2l2ZSB1cyBzb21l IHVzZWZ1bCBoaW50cyBvZiBwb29yIGNvbm5lY3Rpb24NCiB3aXRoIHNtYWxsIHByb3RvY29sIGNo YW5nZSwgYmVzaWRlcyB0aGUgYmFzaWMgY29ubmVjdGl2aXR5IGluZm9ybWF0aW9uLiBJZiBpdCBt ZWFzdXJlcyBzb21ldGhpbmcsIGl0IG1lYXN1cmVzIHBhY2tldHMgb2YgQkZEIGl0c2VsZi4gU28g SSBkb27igJl0IGV4cGVjdCBpdCB0byBiZSBjb25zaWRlcmVkIGFzIGEgcGVyZm9ybWFuY2UgbWVh c3VyZW1lbnQgdG9vbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVuZzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO0dyZWdvcnkgTWlyc2t5IFs8YSBocmVmPSJt YWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwv c3Bhbj48L2E+XSZuYnNwOzxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO1NhdHVyZGF5LCBOb3ZlbWJl ciAyOSwgMjAxNCAzOjM3IEFNPGJyPg0KPGI+VG86PC9iPiZuYnNwO0ZhbiwgUGVuZzsgJ01BTExJ SyBNVURJR09OREEgKG1tdWRpZ29uKSc7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGctYmZk QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtSRTogQkZEIHN0 YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSBQZW5nLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoaXMgaXMgdmVyeSBpbnRlcmVzdGluZyBzY2Vu YXJpby4gSSB0aGluayB0aGF0IGlmIEJGRCBleHBlcmllbmNlcyB+MzAlIHBhY2tldCBsb3NzLCB0 aGVuIGhpZ2hseQ0KIGxpa2VseSBzbyBhcmUgYWZmZWN0ZWQgb3RoZXIgYXBwbGljYXRpb25zLiBU aGVuIGl0IGlzIG5vdCBqdXN0IEJGRCBpc3N1ZSBidXQgY29uZGl0aW9uIHRoYXQgc2hvdWxkIGJl IGRldGVjdGVkJm5ic3A7IGJ5IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IG1ldGhvZCwgd2hldGhl ciBhY3RpdmUgb3IgcGFzc2l2ZSBwYWNrZXQgbG9zcyBtZWFzdXJlbWVudC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbSBj b252aW5jZWQgdGhhdCBvdmVybG9hZGluZyBCRkQgd2l0aCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVu dCBwcm92aXNpb25zIGlzIGNvdW50ZXItcHJvZHVjdGl2ZQ0KIGFuZCBpcyBpbmFwcHJvcHJpYXRl Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdh cmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7UnRnLWJmZCBbPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0mbmJzcDs8Yj5Pbg0KIEJlaGFsZiBPZiZuYnNw OzwvYj5GYW4sIFBlbmc8YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDtGcmlkYXksIE5vdmVtYmVyIDI4 LCAyMDE0IDQ6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7J01BTExJSyBNVURJR09OREEgKG1t dWRpZ29uKSc7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGctYmZkQGlldGYub3JnPC9zcGFu PjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtSRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ct dXAgZnJvbSBJRVRGLTkxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSBNYWxsaWssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXhhY3RseS4gUGFja2V0cyBtYXkgYmUgZXhwZXJp ZW5jaW5nIHNsaWdodCBsb3NzLCBidXQgdGhlIGxpbmsgY2FuIGhhcmRseSBiZSByZWdhcmRlZCBh cyBjb25uZWN0ZWQuDQogTW9yZSBpbXBvcnRhbnRseSwgdGhlIGV4cGVyaWVuY2Ugb2YgdXBwZXIt bGV2ZWwgYXBwbGljYXRpb25zIGNhbiBiZSBkZWdyYWRlZCBzZXZlcmVseSAoZS5nLiBUQ1AgdHJh ZmZpYyBpcyBub3QgYWJsZSB0byBnbyBmYXN0IGluIGZhY2Ugb2YgZXZlbiBzbWFsbCBjb250aW51 b3VzIGxvc3MpLiBCdXQgd2hhdCBpZiBvbmUgQkZEIGZyYW1lIGlzIGxvc3QgZXZlcnkgdGhyZWUg ZnJhbWVzPyBUaGVuIHRoZSBsb3NzIHJhdGUgaXMgMzAlIG9uIGF2ZXJhZ2UsDQogd2hpY2ggaXMg YWxyZWFkeSBhIHZlcnkgc2V2ZXJlIHZhbHVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJk cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5QZW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7TUFMTElLIE1VRElH T05EQSAobW11ZGlnb24pDQogWzxhIGhyZWY9Im1haWx0bzptbXVkaWdvbkBjaXNjby5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86bW11ZGlnb25A Y2lzY28uY29tPC9zcGFuPjwvYT5dJm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7RnJpZGF5 LCBOb3ZlbWJlciAyOCwgMjAxNCA3OjUzIFBNPGJyPg0KPGI+VG86PC9iPiZuYnNwO0ZhbiwgUGVu ZzsmbmJzcDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Zy1iZmRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9t IElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIFBlbmcsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPklmIHRoZSBCRkQgcGFja2V0cyBhcmUgbG9zdCwgZG9lc27igJl0IHRoZSBCRkQgc2Vz c2lvbiBnbyBET1dOPyBBcmUgeW91IHNheWluZyB0aGF0IHBhY2tldCBsb3NzIGlzIG5vdCBiaWcg ZW5vdWdoIHRvDQogbWFrZSBCRkQgc2Vzc2lvbiBnbyBET1dOPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFu a3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TWFsbGlrPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbHQ7RmFuJmd0OywgUGVuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhbnBl bmdAY2hpbmFtb2JpbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+ZmFucGVuZ0BjaGluYW1vYmlsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRl OiZuYnNwOzwvYj5GcmlkYXksIDI4IE5vdmVtYmVyIDIwMTQgNDoyMCBwbTxicj4NCjxiPlRvOiZu YnNwOzwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Zy1iZmRAaWV0Zi5vcmc8L3NwYW4+ PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGctYmZkQGlldGYub3JnPC9zcGFu PjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDombmJzcDs8L2I+UkU6IEJGRCBzdGFiaWxpdHkgZm9s bG93LXVwIGZyb20gSUVURi05MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIEplZmYs IGFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBoYXZlIGJlZW4gZm9sbG93aW5nIHRoaXMgc3RhYmlsaXR5 IGV4dGVuc2lvbiBmcm9tIHRoZSBiZWdpbm5pbmcsIGFuZCBhcyBhbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+b3BlcmF0b3IgSSB3 b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhhdCB0aGlzIGRyYWZ0IGVuYWJsZXMgdGhlICZxdW90O2Fk dmFuY2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5mZWF0dXJlJnF1b3Q7IHdlIGRlc2lyZSBmb3IgQkZEIHRvIHByb3ZpZGUgYWRk aXRpb25hbCB1c2VmdWwgaW5mb3JtYXRpb24gdGhhdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aGVscHMgb3BlcmF0b3JzIHVuZGVy c3RhbmQgbmV0d29yayBpc3N1ZXMuIEEgcmVsZXZhbnQgdXNlIGNhc2UgaXMgZGV0ZWN0aW5nPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5sb3NzeSBvciAmcXVvdDtxdWFzaS1kaXNjb25uZWN0ZWQmcXVvdDsgbGlua3Mgb3IgbWVtYmVy IExBRyBsaW5rcy4gQW4gZXhhbXBsZSBvZiBzdWNoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zaXR1YXRpb24gd2UgZXhwZXJpZW5j ZWQgd2FzIGEgbG9vc2VseSBjb25uZWN0ZWQgZmliZXIgbGluayByZXN1bHRpbmcgaW48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmNv bnRpbnVvdXMsIHNtYWxsIGFtb3VudCBvZiBwYWNrZXQgbG9zcy4gQkZEIGNvdWxkIGdldCB0aGUg aW5mb3JtYXRpb24gb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPmxvc3QgQkZEIGZyYW1lcyBvbiBzdWNoIHVuc3RhYmxlIGxpbmss IGFuZCBwcm9iYWJseSByZXBvcnQgd2hlbiBhIHRhcmdldDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bGV2ZWwgaXMgcmVhY2hlZCwg c2F5IGEgY2VydGFpbiBudW1iZXIgb2YgZnJhbWVzIGFyZSBsb3N0IG92ZXIgYSBwZXJpb2Qgb3I8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPmFtb25nIGEgdG90YWwgbnVtYmVyIG9mIGZyYW1lcy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmVzdCBy ZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+UGVuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1haGVz aCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q28tY2hhaXIsIE5FVENPTkYgV0c8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1haGVzaCBKZXRoYW5hbmRh bmk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q28tY2hhaXIsIE5FVENPTkYgV0c8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B8AACDBeusaamb103erics_-- From nobody Thu Dec 4 17:05:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83571A8A4E for ; Thu, 4 Dec 2014 17:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 hBFOFkvOFCf7 for ; Thu, 4 Dec 2014 17:05:12 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788F81A8A4A for ; Thu, 4 Dec 2014 17:05:12 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so3798145obc.11 for ; Thu, 04 Dec 2014 17:05:11 -0800 (PST) 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:content-type; bh=ucr7kxNTKPbR98T0JzTSlVCNrUFMECCrCEfoWhhQdaI=; b=q0N2buoqavlhEFF/fh6wFQOMUhLLvsk0XpYyAMFf8Fm/m1rtI67jeJeVbxNcaqVYUq o8O5n1FnLN1ahMbjK8xBk7r6Uu5cjq+2BenD51zMsBURoeXBLJ9jw0hf1Qpr0r6p76dY F4qXRR8p3uY/AE+KC1FyZAEt/PvS1yYxdVMwyh0rrv7aoTBvlQCacqF5Ny/mi80MGyqz AwE36NNNti0dpdNcewcRf44iIEAjLVP2tiy13qMCpfHb3ak4kGhD2nj5D/wVQ1io473E 1lNZU16Qsh4gfHGTiJ//w7k4Ka8Sg5Pob1lPkLL4f+cR1Md5+KcqJaPArtAPaF1FHVmA OR/w== MIME-Version: 1.0 X-Received: by 10.202.204.208 with SMTP id c199mr8465351oig.42.1417741511781; Thu, 04 Dec 2014 17:05:11 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 17:05:11 -0800 (PST) In-Reply-To: <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> References: <20141204151708.GA9458@pfrc> <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> Date: Fri, 5 Dec 2014 06:35:11 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: "Sam K. Aldrin" Content-Type: multipart/alternative; boundary=001a1135329c3173ac05096dabab Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/F69TaKkYtxPW0l7-qH8Niuc551g Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 01:05:15 -0000 --001a1135329c3173ac05096dabab Content-Type: text/plain; charset=UTF-8 Hi Sam, > > > Concern: > - With the sequence number added, one could find(?) that BFD control > packets are experiencing congestion or packet delay. So, the assertion is > that BFD flapping could be avoided. But if the packets in the network, > including BFD, are really experiencing this, shouldn't this be the right > behavior? > I was looking at it to help debug scenarios where its not just the network but implementation issues as well that cause sporadic BFD flaps. If you have a BFD pkt lying in your buffer for too long before its gets scheduled out, then perhaps there is a case for you to look at your pkt TX scheduler. Similarly, you could look at issues on the RX side -- perhaps the queue isnt being drained fast enough, or the CIR/PIR values are aggressive and you drop certain packets when you have scaled up BFD sessions. Ideally even if there is some bit of congestion i would like the BFD packet to get through. Cheers, Manav - I see concerns regarding timestamps and sequence numbers expressed in > emails. In that case, the proposed model is still not going to identify the > problem completely. Am I reading it right? > > -sam > On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote: > > > Hi Jeff, > > I can reference RFC 5357 here. The Appendix describes what is called > TWAMP-Light mode with Stateless Reflector. About year and a half the Errata > been accepted that describes Stateful Reflector, which supports measurement > of one-way latency/jitter and packet loss metrics. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey > Haas > > Sent: Thursday, December 04, 2014 7:17 AM > > To: Nobo Akiya (nobo) > > Cc: rtg-bfd@ietf.org > > Subject: Re: BFD stability follow-up from IETF-91 > > > > On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote: > >> If what you say is the only requirement not met, one approach may be to > pursue a non-standard-track document describing some suggested > implementation techniques to locally store TX/RX timestamp. > >> > >> Given that echo approach will be less accurate and given that we seem > to be having difficulty converging, I thought I???ll throw out another idea. > > > > I think my biggest concern is that the echo approach has bidirectional > packet loss possibilities. Async at least lets the receiver know about > unidirectional packet loss. > > > > Of course, if your goal is to notify the sender that their packets are > being lost, you need a backchannel anyway. I just don't know if we want > that back channel to be bfd. > > > > - Jeff > > > > --001a1135329c3173ac05096dabab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sam,


Concern:
- With the sequence number added, one could find(?) that BFD control packet= s are experiencing congestion or packet delay. So, the assertion is that BF= D flapping could be avoided. But if the packets in the network, including B= FD, are really experiencing this, shouldn't this be the right behavior?=

I was looking at it to help debug scen= arios where its not just the network but implementation issues as well that= cause sporadic BFD flaps. If you have a BFD pkt lying in your buffer for t= oo long before its gets scheduled out, then perhaps there is a case for you= to look at your pkt TX scheduler. Similarly, you could look at issues on t= he RX side -- perhaps the queue isnt being drained fast enough, or the CIR/= PIR values are aggressive and you drop certain packets when you have scaled= up BFD sessions.

Ideally even if there is some bi= t of congestion i would like the BFD packet to get through.

<= /div>
Cheers, Manav

- I see concerns regarding timestamps and sequence numbers expressed in ema= ils. In that case, the proposed model is still not going to identify the pr= oblem completely. Am I reading it right?

-sam
On Dec 4, 2014, at 7:= 47 AM, Gregory Mirsky wrote:

> Hi Jeff,
> I can reference RFC 5357 here. The Appendix describes what is called T= WAMP-Light mode with Stateless Reflector. About year and a half the Errata = been accepted that describes Stateful Reflector, which supports measurement= of one-way latency/jitter and packet loss metrics.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Thursday, December 04, 2014 7:17 AM
> To: Nobo Akiya (nobo)
> Cc: rtg-bfd@ietf.org
> Subject: Re: BFD stability follow-up from IETF-91
>
> On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote:
>> If what you say is the only requirement not met, one approach may = be to pursue a non-standard-track document describing some suggested implem= entation techniques to locally store TX/RX timestamp.
>>
>> Given that echo approach will be less accurate and given that we s= eem to be having difficulty converging, I thought I???ll throw out another = idea.
>
> I think my biggest concern is that the echo approach has bidirectional= packet loss possibilities.=C2=A0 Async at least lets the receiver know abo= ut unidirectional packet loss.
>
> Of course, if your goal is to notify the sender that their packets are= being lost, you need a backchannel anyway.=C2=A0 I just don't know if = we want that back channel to be bfd.
>
> - Jeff
>


--001a1135329c3173ac05096dabab-- From nobody Thu Dec 4 17:41:05 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543121A1B0D for ; Thu, 4 Dec 2014 17:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 th7B93g9TNU5 for ; Thu, 4 Dec 2014 17:41:01 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60F41A8A11 for ; Thu, 4 Dec 2014 17:41:00 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lj1so19042269pab.19 for ; Thu, 04 Dec 2014 17:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=e125d9v5lFmbOkxMIpeo9eWiCVqvIOViaApp6amkDOk=; b=uqudQOeK1In5W0CJjdlD+vnp8i8qrmOqqy73kphXwprscavNOmwEWKOTtLazxGqRH3 +T+uWp3VBjisf1ZjE25qxcMWofSlm4AZHKG0QvOhxPTNy0SJR1T9P33/FrfJq6uEIu7O rQa1yRt6jBAepeJgCIMuMPew3VBIJ+Czdbq8XTggcTi7rv2TMHubgQ2qn71a74wHZxrq 7Hb9szDhs6CtuCJht3vFYf25e0Pljf54sqknZPIjJXkt8utTxuh7tA+6Je2n+r58BZ27 g4zROVi/89dFigQdFptOTKHyo5lkL7wd71zCEfFBstAxJvOl7sOIDw8gQW9Y2Y2SV05u AoPg== X-Received: by 10.68.136.137 with SMTP id qa9mr31114135pbb.8.1417743659801; Thu, 04 Dec 2014 17:40:59 -0800 (PST) Received: from [192.168.1.11] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id c3sm27124170pbu.76.2014.12.04.17.40.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 17:40:58 -0800 (PST) Subject: Re: BFD stability follow-up from IETF-91 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A6A379A1-713D-48A5-AB73-3CF3EED871FD" From: "Sam K. Aldrin" In-Reply-To: Date: Thu, 4 Dec 2014 17:40:56 -0800 Message-Id: <58D290A6-1EB1-425B-9FFA-3025A3CAE4EE@gmail.com> References: <20141204151708.GA9458@pfrc> <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> To: Manav Bhatia X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/79SMfiuI1cnR3ySYmIkuzXacBsU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 01:41:03 -0000 --Apple-Mail=_A6A379A1-713D-48A5-AB73-3CF3EED871FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Manav, On Dec 4, 2014, at 5:05 PM, Manav Bhatia wrote: > Hi Sam, >=20 >=20 > Concern: > - With the sequence number added, one could find(?) that BFD control = packets are experiencing congestion or packet delay. So, the assertion = is that BFD flapping could be avoided. But if the packets in the = network, including BFD, are really experiencing this, shouldn't this be = the right behavior? >=20 > I was looking at it to help debug scenarios where its not just the = network but implementation issues as well that cause sporadic BFD flaps. = If you have a BFD pkt lying in your buffer for too long before its gets = scheduled out, then perhaps there is a case for you to look at your pkt = TX scheduler. Similarly, you could look at issues on the RX side -- = perhaps the queue isnt being drained fast enough, or the CIR/PIR values = are aggressive and you drop certain packets when you have scaled up BFD = sessions. >=20 > Ideally even if there is some bit of congestion i would like the BFD = packet to get through. I understand the queuing problems but I am not clear how the ID is going = to solve the problem, if there is only congestion and not packet drop. = In that case just the sequence # doesn't help and timestamping is = needed. Even if timestamping is to be done, realistically it cannot = happen the same way across multi vendor i.e. where the timestamping = should/could be done. For ex: Before it is queued or after OR = LC/RP/SP/Process etc. Secondly, if the congestion happens, the CIR/PIR should apply to data = packets too. In that case BFD flap is at least a good indicator of the = problem, isn't it?=20 Lastly, these improvements is change from the existing BFD = model/protocol.=20 I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D -sam >=20 > Cheers, Manav >=20 > - I see concerns regarding timestamps and sequence numbers expressed = in emails. In that case, the proposed model is still not going to = identify the problem completely. Am I reading it right? >=20 > -sam > On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote: >=20 > > Hi Jeff, > > I can reference RFC 5357 here. The Appendix describes what is called = TWAMP-Light mode with Stateless Reflector. About year and a half the = Errata been accepted that describes Stateful Reflector, which supports = measurement of one-way latency/jitter and packet loss metrics. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey = Haas > > Sent: Thursday, December 04, 2014 7:17 AM > > To: Nobo Akiya (nobo) > > Cc: rtg-bfd@ietf.org > > Subject: Re: BFD stability follow-up from IETF-91 > > > > On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote: > >> If what you say is the only requirement not met, one approach may = be to pursue a non-standard-track document describing some suggested = implementation techniques to locally store TX/RX timestamp. > >> > >> Given that echo approach will be less accurate and given that we = seem to be having difficulty converging, I thought I???ll throw out = another idea. > > > > I think my biggest concern is that the echo approach has = bidirectional packet loss possibilities. Async at least lets the = receiver know about unidirectional packet loss. > > > > Of course, if your goal is to notify the sender that their packets = are being lost, you need a backchannel anyway. I just don't know if we = want that back channel to be bfd. > > > > - Jeff > > >=20 >=20 --Apple-Mail=_A6A379A1-713D-48A5-AB73-3CF3EED871FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Manav,

On Dec 4, 2014, at 5:05 PM, Manav = Bhatia wrote:

Hi Sam,


Concern:
- With the sequence number added, one could find(?) that BFD control = packets are experiencing congestion or packet delay. So, the assertion = is that BFD flapping could be avoided. But if the packets in the = network, including BFD, are really experiencing this, shouldn't this be = the right behavior?

I was looking at = it to help debug scenarios where its not just the network but = implementation issues as well that cause sporadic BFD flaps. If you have = a BFD pkt lying in your buffer for too long before its gets scheduled = out, then perhaps there is a case for you to look at your pkt TX = scheduler. Similarly, you could look at issues on the RX side -- perhaps = the queue isnt being drained fast enough, or the CIR/PIR values are = aggressive and you drop certain packets when you have scaled up BFD = sessions.

Ideally even if there is some bit of = congestion i would like the BFD packet to get = through.
I understand the queuing = problems but I am not clear how the ID is going to solve the problem, if = there is only congestion and not packet drop. In that case just the = sequence # doesn't help and timestamping is needed. Even if timestamping = is to be done, realistically it cannot happen the same way across multi = vendor i.e. where the timestamping should/could be done. For ex: Before = it is queued or after OR LC/RP/SP/Process = etc.

Secondly, if the congestion happens, the = CIR/PIR should apply to data packets too. In that case BFD flap is at = least a good indicator of the problem, isn't = it? 

Lastly, these improvements is change = from the existing BFD model/protocol. 
I do not see why = it shouldn't be part of BFD v2 OR lead to v2 = :D

-sam

Cheers, = Manav

- I see concerns regarding timestamps and sequence numbers expressed in = emails. In that case, the proposed model is still not going to identify = the problem completely. Am I reading it right?

-sam
On Dec 4, 2014, at = 7:47 AM, Gregory Mirsky wrote:

> Hi Jeff,
> I can reference RFC 5357 here. The Appendix describes what is = called TWAMP-Light mode with Stateless Reflector. About year and a half = the Errata been accepted that describes Stateful Reflector, which = supports measurement of one-way latency/jitter and packet loss = metrics.
>
>       Regards,
>               Greg
>
> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] = On Behalf Of Jeffrey Haas
> Sent: Thursday, December 04, 2014 7:17 AM
> To: Nobo Akiya (nobo)
> Cc: rtg-bfd@ietf.org
> Subject: Re: BFD stability follow-up from IETF-91
>
> On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) = wrote:
>> If what you say is the only requirement not met, one approach = may be to pursue a non-standard-track document describing some suggested = implementation techniques to locally store TX/RX timestamp.
>>
>> Given that echo approach will be less accurate and given that = we seem to be having difficulty converging, I thought I???ll throw out = another idea.
>
> I think my biggest concern is that the echo approach has = bidirectional packet loss possibilities.  Async at least lets the = receiver know about unidirectional packet loss.
>
> Of course, if your goal is to notify the sender that their packets = are being lost, you need a backchannel anyway.  I just don't know = if we want that back channel to be bfd.
>
> - Jeff
>



= --Apple-Mail=_A6A379A1-713D-48A5-AB73-3CF3EED871FD-- From nobody Thu Dec 4 18:51:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093B01A9095 for ; Thu, 4 Dec 2014 18:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 jEMe0iLiWTRZ for ; Thu, 4 Dec 2014 18:51:14 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A24E1A9092 for ; Thu, 4 Dec 2014 18:51:14 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so3917157obc.0 for ; Thu, 04 Dec 2014 18:51:13 -0800 (PST) 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:content-type; bh=pMSdpOpIdP9sEgZWX4NiK59p+VzmaR6YBQI2uH+vFfk=; b=f9ry/zsGDTHhtMGxI2BA15MrBDrvLCEfpAXp2BHMsQBkUCntXoZKKCpuWtCXWPlmHe ILdwHzWsdqUYaa8bfHCqSafNHVLyJObWWVZK0egZUz5KXWuzmEffZ6TV4HKcXwTB79VH 8OLVxXIO/r0TZVYYh60s9B//DAiXsT/kJRmW4N4dNySQLUzXBzG+/4iptyb1ljSFJByC XwdFs4RrNS0BN8Ge+croy5Cm61Z3LLrQvpk8O0SOrLttpIPDqwvqf7bxiYVicqo0Cmei qtesGb3u9vAQlwU6f5x+dQjZimyCJmDnRO3eRrEP/RaRIVktY1lDZOTsi71LWkwRziD7 HrmA== MIME-Version: 1.0 X-Received: by 10.202.204.208 with SMTP id c199mr8701444oig.42.1417747873431; Thu, 04 Dec 2014 18:51:13 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 18:51:13 -0800 (PST) In-Reply-To: <58D290A6-1EB1-425B-9FFA-3025A3CAE4EE@gmail.com> References: <20141204151708.GA9458@pfrc> <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> <58D290A6-1EB1-425B-9FFA-3025A3CAE4EE@gmail.com> Date: Fri, 5 Dec 2014 08:21:13 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: "Sam K. Aldrin" Content-Type: multipart/alternative; boundary=001a1135329c6089e305096f2656 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/d9cmf7InUmxZ-fVFUL-pTfMIzC0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 02:51:17 -0000 --001a1135329c6089e305096f2656 Content-Type: text/plain; charset=UTF-8 Hi Sam, > Ideally even if there is some bit of congestion i would like the BFD > packet to get through. > > I understand the queuing problems but I am not clear how the ID is going > to solve the problem, if there is only congestion and not > It would help. Assume the last sequence number you saw before the flap was s1. You timed out since you did not see s2 and s3 before the timeout. Now further assume that you know that you did receive s2 and s3, however they arrived after the BFD expiry interval then you know that there wasnt a drop, and the packet arrived late because of some queing issue. Now how you determine whether this delay was seen at the TX or RX side is open to discussion. Without a sequence number you have no idea whether the packet was dropped or whether it arrived/processed late. If by some out-of-band mechanism you can figure out that the TX was done on time and the delay was at RX end then its an implementation issue on the RX side. If the TX was delayed then its an implementation issue at the TX side. This helps isolating the node that needs to fix the issue, otherwise we're only shooting in the dark. packet drop. In that case just the sequence # doesn't help and timestamping > is needed. Even if timestamping is to be done, realistically it cannot > happen the same way across multi vendor i.e. where the timestamping > should/could be done. For ex: Before it is queued or after OR > LC/RP/SP/Process etc. > This isnt a new problem. Each vendor time stamps 1588 packets differently. However, the aggregate solution works across multiple vendors. While it may not solve all the issues because of the vagaries of how each vendor does time stamping it would certainly help debugging large number of BFD flaps. > Secondly, if the congestion happens, the CIR/PIR should apply to data > packets too. In that case BFD flap is at least a good indicator of the > problem, isn't it? > There is usually a separate CIR/PIR for different CPU bound packets. So based on some parameters you might impose a different CIR/PIR for BFD than say, ssh and radius packets. If BFD flaps and you know you missed a few sequence numbers and you see drops in that queue then all of this could be co-related and you could fix the CPU queue parameters for BFD. I understand that this is a very implementation specific issue, but then thats what i had said earlier -- such a mechanism can help in isolating implementation specific issues as well. > Lastly, these improvements is change from the existing BFD model/protocol. > I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D > Sure, that would make Marc very happy ! :-) I am not sure if we have enough momentum right now that can propel us towards BFD v2. OTOH, if the WG believes that this is an opportune time for us to start looking at BFDv2, then i would be more than willing to participate! Cheers, Manav > > -sam > > > Cheers, Manav > > - I see concerns regarding timestamps and sequence numbers expressed in >> emails. In that case, the proposed model is still not going to identify the >> problem completely. Am I reading it right? >> >> -sam >> On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote: >> >> > Hi Jeff, >> > I can reference RFC 5357 here. The Appendix describes what is called >> TWAMP-Light mode with Stateless Reflector. About year and a half the Errata >> been accepted that describes Stateful Reflector, which supports measurement >> of one-way latency/jitter and packet loss metrics. >> > >> > Regards, >> > Greg >> > >> > -----Original Message----- >> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey >> Haas >> > Sent: Thursday, December 04, 2014 7:17 AM >> > To: Nobo Akiya (nobo) >> > Cc: rtg-bfd@ietf.org >> > Subject: Re: BFD stability follow-up from IETF-91 >> > >> > On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote: >> >> If what you say is the only requirement not met, one approach may be >> to pursue a non-standard-track document describing some suggested >> implementation techniques to locally store TX/RX timestamp. >> >> >> >> Given that echo approach will be less accurate and given that we seem >> to be having difficulty converging, I thought I???ll throw out another idea. >> > >> > I think my biggest concern is that the echo approach has bidirectional >> packet loss possibilities. Async at least lets the receiver know about >> unidirectional packet loss. >> > >> > Of course, if your goal is to notify the sender that their packets are >> being lost, you need a backchannel anyway. I just don't know if we want >> that back channel to be bfd. >> > >> > - Jeff >> > >> >> > > --001a1135329c6089e305096f2656 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sam,
=
Ideally even if there is s= ome bit of congestion i would like the BFD packet to get through.
I understand the queuing problems but I a= m not clear how the ID is going to solve the problem, if there is only cong= estion and not

It would = help.

Assume the last sequence number you saw befo= re the flap was s1. You timed out since you did not see s2 and s3 before th= e timeout. Now further assume that you know that you did receive s2 and s3,= however they arrived after the BFD expiry interval then you know that ther= e wasnt a drop, and the packet arrived late because of some queing issue. N= ow how you determine whether this delay was seen at the TX or RX side is op= en to discussion.

Without a sequence number you ha= ve no idea whether the packet was dropped or whether it arrived/processed l= ate.=C2=A0

If by some out-of-band mechanism you ca= n figure out that the TX was done on time and the delay was at RX end then = its an implementation issue on the RX side. If the TX was delayed then its = an implementation issue at the TX side.

This helps= isolating the node that needs to fix the issue, otherwise we're only s= hooting in the dark.=C2=A0

packet drop. In that case = just the sequence # doesn't help and timestamping is needed. Even if ti= mestamping is to be done, realistically it cannot happen the same way acros= s multi vendor i.e. where the timestamping should/could be done. For ex: Be= fore it is queued or after OR LC/RP/SP/Process etc.

This isnt a new problem. Each vendor time stamps= 1588 packets differently. However, the aggregate solution works across mul= tiple vendors.

While it may not solve all the issu= es because of the vagaries of how each vendor does time stamping it would c= ertainly help debugging large number of BFD flaps.

=

Secondly, if the congestion happens, the CIR/PIR should ap= ply to data packets too. In that case BFD flap is at least a good indicator= of the problem, isn't it?=C2=A0
There is usually a separate CIR/PIR for different CPU bound pac= kets. So based on some parameters you might impose a different CIR/PIR for = BFD than say, ssh and radius packets. If BFD flaps and you know you missed = a few sequence numbers and you see drops in that queue then all of this cou= ld be co-related and you could fix the CPU queue parameters for BFD. I unde= rstand that this is a very implementation specific issue, but then thats wh= at i had said earlier -- such a mechanism can help in isolating implementat= ion specific issues as well.


Lastly, t= hese improvements is change from the existing BFD model/protocol.=C2=A0
I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D=

Sure, that would make Ma= rc very happy ! :-)

I am not sure if we have enoug= h momentum right now that can propel us towards BFD v2.

OTOH, if the WG believes that this is an opportune time for us to sta= rt looking at BFDv2, then i would be more than willing to participate!

Cheers, Manav=C2=A0

-sam

Cheers, Manav

- I see concerns regarding timestamps and sequence numbers expressed in ema= ils. In that case, the proposed model is still not going to identify the pr= oblem completely. Am I reading it right?

-sam
On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote:
> Hi Jeff,
> I can reference RFC 5357 here. The Appendix describes what is called T= WAMP-Light mode with Stateless Reflector. About year and a half the Errata = been accepted that describes Stateful Reflector, which supports measurement= of one-way latency/jitter and packet loss metrics.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Thursday, December 04, 2014 7:17 AM
> To: Nobo Akiya (nobo)
> Cc: rtg-bfd@ietf= .org
> Subject: Re: BFD stability follow-up from IETF-91
>
> On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote:
>> If what you say is the only requirement not met, one approach may = be to pursue a non-standard-track document describing some suggested implem= entation techniques to locally store TX/RX timestamp.
>>
>> Given that echo approach will be less accurate and given that we s= eem to be having difficulty converging, I thought I???ll throw out another = idea.
>
> I think my biggest concern is that the echo approach has bidirectional= packet loss possibilities.=C2=A0 Async at least lets the receiver know abo= ut unidirectional packet loss.
>
> Of course, if your goal is to notify the sender that their packets are= being lost, you need a backchannel anyway.=C2=A0 I just don't know if = we want that back channel to be bfd.
>
> - Jeff
>




--001a1135329c6089e305096f2656-- From nobody Thu Dec 4 19:03:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF981A90A0 for ; Thu, 4 Dec 2014 19:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 cbfC5X9NQc3i for ; Thu, 4 Dec 2014 19:02:47 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F5B1A909B for ; Thu, 4 Dec 2014 19:02:42 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so3927175obc.0 for ; Thu, 04 Dec 2014 19:02:41 -0800 (PST) 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:content-type; bh=S1YcGtujvqThbmgxgfyEDcImx7rjvTCpMDcAt/xAjQU=; b=IEujmCj8/m0nkcbyftotLkpzp2docmBR+6vYqnKhPfqt2rybZvTLLo+7R3cH6rxmlj pUESlnRt+Yu4CtJdKFFcWQqhRCdXnDNoVuBv1CC99LRqihNRc6FZpL3P/+MTz0Efxler 6nw+1V1xkx7wxJGPQ31j4LbFrdf3NzUHtlUzuiuWxnttcpZayZ1nfQwTgjenPNeKGhUs 5AQhI3M4UkpSIlhcQHdMwkh8jXHM7A4suOZzGh5u3RjBbIyaDbaItxFGuG0Qzs6+5mA4 44p/fjD9OAFR8eOTD9ERKLOahSdLtI5t/jd6odK1y0sGTiP+NTRFJTx8QqjaIdfolmhv SIyw== MIME-Version: 1.0 X-Received: by 10.202.204.208 with SMTP id c199mr8724399oig.42.1417748561780; Thu, 04 Dec 2014 19:02:41 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 19:02:41 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> Date: Fri, 5 Dec 2014 08:32:41 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a1135329c67e64705096f4f82 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ZW9JYpU9gCClJXVK9vY2r_jJRto Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 03:02:52 -0000 --001a1135329c67e64705096f4f82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, I am sure the WG would appreciate such a lecture since that would obviate the need for such an ID. Are you suggesting that i turn on logging and packet tracing for *each* incoming BFD packet for all the sessions that i have? Trying doing that for 25 BFD sessions where few are running at 50ms and 100ms TX intervals. Now trying combing through the logs when 1 BFD session flaps to understand where the issue was. Cheers, Manav On Thu, Dec 4, 2014 at 10:03 PM, Gregory Mirsky wrote: > Hi Manav, > > I hope you don=E2=80=99t expect me to give a lecture on how to design and > implement debugable implementation using logging and packet tracing. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Thursday, December 04, 2014 8:16 AM > *To:* Gregory Mirsky > *Cc:* Santosh P K; Mahesh Jethanandani; rtg-bfd@ietf.org > > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > I am not sure what the confusion is Greg. > > > > Assume i have a BFD session thats up. At some point in time it flaps. Now > i need to know whether the issue was at the TX or the RX. > > > > Please tell me how TWAMP can help me here. Also tell me how what tool i > can use if its a uBFD session that flapped. > > > > Cheers, Manav > > > > > --001a1135329c67e64705096f4f82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

I am sure the W= G would appreciate such a lecture since that would obviate the need for suc= h an ID. Are you suggesting that i turn on logging and packet tracing for *= each* incoming BFD packet for all the sessions that i have? Trying doing th= at for 25 BFD sessions where few are running at 50ms and 100ms TX intervals= . Now trying combing through the logs when 1 BFD session flaps to understan= d where the issue was.

Cheers, Manav

On Thu, Dec 4, 2014 at 10:03 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

I hope you don=E2=80=99t = expect me to give a lecture on how to design and implement debugable implem= entation using logging and packet tracing.

=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, December 04, 2014 8:16 AM
To: Gregory Mirsky
Cc: Santosh P K; Mahesh Jethanandani; rtg-bfd@ietf.org


Subject: Re: BFD stability follow-up from IETF-91

=C2=A0

I am not sure what the confusion is Greg.<= /u>

=C2=A0

Assume i have a BFD session thats up. At some point = in time it flaps. Now i need to know whether the issue was at the TX or the= RX.

=C2=A0

Please tell me how TWAMP can help me here. Also tell= me how what tool i can use if its a uBFD session that flapped.

=C2=A0

Cheers, Manav

=C2=A0


--001a1135329c67e64705096f4f82-- From nobody Thu Dec 4 19:52:31 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729091A9244 for ; Thu, 4 Dec 2014 19:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Upr0MCZ5XRY8 for ; Thu, 4 Dec 2014 19:52:26 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483B51A87AF for ; Thu, 4 Dec 2014 19:52:26 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id ft15so18969779pdb.36 for ; Thu, 04 Dec 2014 19:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=6GeUfSXJPLl32UzBUdcPh3ibayVbPAUq/zt241TVGaY=; b=jeBB8Ql14tlqGwSW4/3ZPYfpwjfIAs+RyYOG/jzCd3vsfQTvPDHTjTUJbVGdUBZ1Y/ Ghjvacwea+74TW2E9hlwzxndQ0VoWKZCFE+NVPTm0L3n9ugN4VvPx25jRurE75QEsUNa HSHoun+0hZd/Njs3XOdoN61qycHlnvTA4kcdvhhsEu4udLWRxNbPOqN7udt49x7nXQtk MwVqPv6s/hpMqxjoyTCPRvUrGJiTCxQhcWLZrOuOaWtbCLfJmqpAEa1nSRGZojzhK2Wm k4F93jbTR8r83ytH1TIxtfRX34aTOVokJNnIrZZDuN0Cok5qkawS6WyOHSL+04zBDIRG Rugg== X-Received: by 10.70.53.164 with SMTP id c4mr24595148pdp.17.1417751545530; Thu, 04 Dec 2014 19:52:25 -0800 (PST) Received: from [192.168.1.11] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id wo3sm27330072pbc.79.2014.12.04.19.52.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 19:52:24 -0800 (PST) Subject: Re: BFD stability follow-up from IETF-91 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_89D147DB-5307-4045-BD0A-9F0AEDD76694" From: "Sam K. Aldrin" In-Reply-To: Date: Thu, 4 Dec 2014 19:52:19 -0800 Message-Id: <3EA747F1-FFDD-4E36-B8A2-58E362C1F601@gmail.com> References: <20141204151708.GA9458@pfrc> <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> <58D290A6-1EB1-425B-9FFA-3025A3CAE4EE@gmail.com> To: Manav Bhatia X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2Ox5PDF9JTZuM_R2eesrkkNNerg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 03:52:29 -0000 --Apple-Mail=_89D147DB-5307-4045-BD0A-9F0AEDD76694 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Manav, On Dec 4, 2014, at 6:51 PM, Manav Bhatia wrote: > Hi Sam, >> Ideally even if there is some bit of congestion i would like the BFD = packet to get through. > I understand the queuing problems but I am not clear how the ID is = going to solve the problem, if there is only congestion and not >=20 > It would help. >=20 > Assume the last sequence number you saw before the flap was s1. You = timed out since you did not see s2 and s3 before the timeout. Now = further assume that you know that you did receive s2 and s3, however = they arrived after the BFD expiry interval then you know that there = wasnt a drop, and the packet arrived late because of some queing issue. = Now how you determine whether this delay was seen at the TX or RX side = is open to discussion. As the draft doesn't say, what exactly one would/should do, assuming = there is packet throttling happing due to various reasons, could = you/authors elaborate on this? I would like to see those tangible things = detailed first. I see the problem little differently though. BFD session flapping is an = indicator of the network behavior, be it device or network congestion or = something else. Even if the packets arrive late, as you say, one cannot = know where exactly the delay is happening. >=20 > Without a sequence number you have no idea whether the packet was = dropped or whether it arrived/processed late.=20 >=20 > If by some out-of-band mechanism you can figure out that the TX was = done on time and the delay was at RX end then its an implementation = issue on the RX side. If the TX was delayed then its an implementation = issue at the TX side. Don't think so. It could be the lot more than implementation issue. = Could be due to network congestion due to bursty traffic and nothing to = do with the implementation. >=20 > This helps isolating the node that needs to fix the issue, otherwise = we're only shooting in the dark.=20 The issue you see is what I think could be the actual network behavior = and not the device issue.=20 Debugging Packet drops, latency and mis-ordering of packets is mostly = shooting in the dark :D Nevertheless, I do not see this as BFD specific only.=20 >=20 > packet drop. In that case just the sequence # doesn't help and = timestamping is needed. Even if timestamping is to be done, = realistically it cannot happen the same way across multi vendor i.e. = where the timestamping should/could be done. For ex: Before it is queued = or after OR LC/RP/SP/Process etc. >=20 > This isnt a new problem. Each vendor time stamps 1588 packets = differently. However, the aggregate solution works across multiple = vendors. >=20 > While it may not solve all the issues because of the vagaries of how = each vendor does time stamping it would certainly help debugging large = number of BFD flaps. As timestamp is not in the ID, we could differ the discussion for later, = but I definitely believe that it is a bigger issue where TS is taken, if = granularity and accuracy are important. >=20 >=20 > Secondly, if the congestion happens, the CIR/PIR should apply to data = packets too. In that case BFD flap is at least a good indicator of the = problem, isn't it?=20 >=20 > There is usually a separate CIR/PIR for different CPU bound packets. = So based on some parameters you might impose a different CIR/PIR for BFD = than say, ssh and radius packets. If BFD flaps and you know you missed a = few sequence numbers and you see drops in that queue then all of this = could be co-related and you could fix the CPU queue parameters for BFD. = I understand that this is a very implementation specific issue, but then = thats what i had said earlier -- such a mechanism can help in isolating = implementation specific issues as well. I agree that it will be helpful. But then, when a new mechanism is = introduced, it should clearly spell out the mechanisms on interpreting = the problems and how to deal with it. The ID has none of it, as of now. >=20 >=20 > Lastly, these improvements is change from the existing BFD = model/protocol.=20 > I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D >=20 > Sure, that would make Marc very happy ! :-) >=20 > I am not sure if we have enough momentum right now that can propel us = towards BFD v2. >=20 > OTOH, if the WG believes that this is an opportune time for us to = start looking at BFDv2, then i would be more than willing to = participate! Well, if there is real issue that existing BFD falls short of the needs, = then interest automatically increases. As this ID introduces new things = to existing version, it should be pursued as part of next version, = rather than changing the existing model for the same version. -sam >=20 > Cheers, Manav=20 >=20 > -sam >>=20 >> Cheers, Manav >>=20 >> - I see concerns regarding timestamps and sequence numbers expressed = in emails. In that case, the proposed model is still not going to = identify the problem completely. Am I reading it right? >>=20 >> -sam >> On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote: >>=20 >> > Hi Jeff, >> > I can reference RFC 5357 here. The Appendix describes what is = called TWAMP-Light mode with Stateless Reflector. About year and a half = the Errata been accepted that describes Stateful Reflector, which = supports measurement of one-way latency/jitter and packet loss metrics. >> > >> > Regards, >> > Greg >> > >> > -----Original Message----- >> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of = Jeffrey Haas >> > Sent: Thursday, December 04, 2014 7:17 AM >> > To: Nobo Akiya (nobo) >> > Cc: rtg-bfd@ietf.org >> > Subject: Re: BFD stability follow-up from IETF-91 >> > >> > On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote: >> >> If what you say is the only requirement not met, one approach may = be to pursue a non-standard-track document describing some suggested = implementation techniques to locally store TX/RX timestamp. >> >> >> >> Given that echo approach will be less accurate and given that we = seem to be having difficulty converging, I thought I???ll throw out = another idea. >> > >> > I think my biggest concern is that the echo approach has = bidirectional packet loss possibilities. Async at least lets the = receiver know about unidirectional packet loss. >> > >> > Of course, if your goal is to notify the sender that their packets = are being lost, you need a backchannel anyway. I just don't know if we = want that back channel to be bfd. >> > >> > - Jeff >> > >>=20 >>=20 >=20 >=20 --Apple-Mail=_89D147DB-5307-4045-BD0A-9F0AEDD76694 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Manav,

On Dec 4, 2014, at 6:51 PM, Manav = Bhatia wrote:

Hi Sam,
Ideally even if there is some bit of = congestion i would like the BFD packet to get = through.
I understand the = queuing problems but I am not clear how the ID is going to solve the = problem, if there is only congestion and not =

It would = help.

Assume the last sequence number you saw = before the flap was s1. You timed out since you did not see s2 and s3 = before the timeout. Now further assume that you know that you did = receive s2 and s3, however they arrived after the BFD expiry interval = then you know that there wasnt a drop, and the packet arrived late = because of some queing issue. Now how you determine whether this delay = was seen at the TX or RX side is open to = discussion.

= As the draft doesn't say, what exactly one would/should do, assuming = there is packet throttling happing due to various reasons, could = you/authors elaborate on this? I would like to see those tangible things = detailed first.

I see the problem little = differently though. BFD session flapping is an indicator of the network = behavior, be it device or network congestion or something else. Even if = the packets arrive late, as you say, one cannot know where exactly the = delay is happening.


Without a sequence number you = have no idea whether the packet was dropped or whether it = arrived/processed late. 

If by some = out-of-band mechanism you can figure out that the TX was done on time = and the delay was at RX end then its an implementation issue on the RX = side. If the TX was delayed then its an implementation issue at the TX = side.
Don't think so. It could be = the lot more than implementation issue. Could be due to network = congestion due to bursty traffic and nothing to do with the = implementation.

This = helps isolating the node that needs to fix the issue, otherwise we're = only shooting in the dark. 
The = issue you see is what I think could be the actual network behavior and = not the device issue. 
Debugging Packet drops, latency = and mis-ordering of packets is mostly shooting in the dark = :D
Nevertheless, I do not see this as BFD specific = only. 


packet drop. In that case just = the sequence # doesn't help and timestamping is needed. Even if = timestamping is to be done, realistically it cannot happen the same way = across multi vendor i.e. where the timestamping should/could be done. = For ex: Before it is queued or after OR LC/RP/SP/Process = etc.

This isnt a new = problem. Each vendor time stamps 1588 packets differently. However, the = aggregate solution works across multiple = vendors.

While it may not solve all the issues = because of the vagaries of how each vendor does time stamping it would = certainly help debugging large number of BFD = flaps.
As timestamp is not in = the ID, we could differ the discussion for later, but I definitely = believe that it is a bigger issue where TS is taken, if =  granularity and accuracy are important.


Secondly, if the = congestion happens, the CIR/PIR should apply to data packets too. In = that case BFD flap is at least a good indicator of the problem, isn't = it? 

There is = usually a separate CIR/PIR for different CPU bound packets. So based on = some parameters you might impose a different CIR/PIR for BFD than say, = ssh and radius packets. If BFD flaps and you know you missed a few = sequence numbers and you see drops in that queue then all of this could = be co-related and you could fix the CPU queue parameters for BFD. I = understand that this is a very implementation specific issue, but then = thats what i had said earlier -- such a mechanism can help in isolating = implementation specific issues as = well.
I agree that it will be = helpful. But then, when a new mechanism is introduced, it should clearly = spell out the mechanisms on interpreting the problems and how to deal = with it. The ID has none of it, as of now.


Lastly, these = improvements is change from the existing BFD = model/protocol. 
I do not see why it shouldn't be part of = BFD v2 OR lead to v2 = :D

Sure, that would = make Marc very happy ! :-)

I am not sure if we = have enough momentum right now that can propel us towards BFD = v2.

OTOH, if the WG believes that this is an = opportune time for us to start looking at BFDv2, then i would be more = than willing to participate!
Well, = if there is real issue that existing BFD falls short of the needs, then = interest automatically increases. As this ID introduces new things to = existing version, it should be pursued as part of next version, rather = than changing the existing model for the same = version.

-sam


Cheers, = Manav 

-sam

Cheers, = Manav

- I see concerns regarding timestamps and sequence numbers expressed in = emails. In that case, the proposed model is still not going to identify = the problem completely. Am I reading it right?

-sam
On Dec 4, 2014, at 7:47 AM, Gregory Mirsky = wrote:

> Hi Jeff,
> I can reference RFC 5357 here. The Appendix describes what is = called TWAMP-Light mode with Stateless Reflector. About year and a half = the Errata been accepted that describes Stateful Reflector, which = supports measurement of one-way latency/jitter and packet loss = metrics.
>
>       Regards,
>               Greg
>
> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey = Haas
> Sent: Thursday, December 04, 2014 7:17 AM
> To: Nobo Akiya (nobo)
> Cc: rtg-bfd@ietf.org
> Subject: Re: BFD stability follow-up from IETF-91
>
> On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) = wrote:
>> If what you say is the only requirement not met, one approach = may be to pursue a non-standard-track document describing some suggested = implementation techniques to locally store TX/RX timestamp.
>>
>> Given that echo approach will be less accurate and given that = we seem to be having difficulty converging, I thought I???ll throw out = another idea.
>
> I think my biggest concern is that the echo approach has = bidirectional packet loss possibilities.  Async at least lets the = receiver know about unidirectional packet loss.
>
> Of course, if your goal is to notify the sender that their packets = are being lost, you need a backchannel anyway.  I just don't know = if we want that back channel to be bfd.
>
> - Jeff
>


=



= --Apple-Mail=_89D147DB-5307-4045-BD0A-9F0AEDD76694-- From nobody Thu Dec 4 21:06:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891921AC409 for ; Thu, 4 Dec 2014 21:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 JZmW6Pxm5SdL for ; Thu, 4 Dec 2014 21:06:37 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 E38FD1AC408 for ; Thu, 4 Dec 2014 21:06:36 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-05-5480ed3f9f1c Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 87.7D.03307.F3DE0845; Fri, 5 Dec 2014 00:24:48 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 00:06:34 -0500 From: Gregory Mirsky To: Manav Bhatia , "Sam K. Aldrin" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQDUqXQ6amXjPuFEmbPIOgLl4p2px+NluAgAAjMzCAAOz5gP//rP5ggACs1ACAAAiDAIAAAPgAgAAA6YCAACPdgIAADrqAgAAGAACAAAClAP//s40ggAB9OQCAAHOGgP//7Sng Date: Fri, 5 Dec 2014 05:06:33 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AC5CB@eusaamb103.ericsson.se> References: <20141204151708.GA9458@pfrc> <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> 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_7347100B5761DC41A166AC17F22DF1121B8AC5CBeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPgq7D24YQg10fRCwmtH5htLg8qY3d 4vOfbYwOzB47Z91l91iy5CdTAFMUl01Kak5mWWqRvl0CV8aO4xtYCo7UVHx+Mp2lgXFGZRcj J4eEgInE8sen2CFsMYkL99azdTFycQgJHGGU+DrtPjuEs4xRYvGjNUwgVWwCRhIvNvaAdYgI BEu0bTzKAmIzC2hKNJ34DBYXFjCUWNW9GKrGSOLYjLlQ9jRGiUWrEkFsFgEViSUbPrOC2LwC vhKvd/5ghljWzCqxbs4sRpAEp0CgxJO988FsRqDzvp+COIJZQFzi1pP5TBBnC0gs2XOeGcIW lXj5+B8rhK0k8fH3fKDFHED1+RJXv7ND7BKUODnzCcsERtFZSCbNQqiahaQKIqwpsX6XPkS1 osSU7ofsELaGROucuezI4gsY2VcxcpQWp5blphsZbGIERtcxCTbdHYx7XloeYhTgYFTi4S14 3hAixJpYVlyZe4hRmoNFSZx3Vu28YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M6Yd6809v /B+6mn+1WG7Ynx1cnyf9SCrYyTqDlXPymVcpd4uLdLU26fxc7Hds5rylL5Rj2Xo/NutH+Pez /Dbx09fUXsVs98yYI5PzpWb20heJj/IE7sW+s+kun5Ec5NzxV+3tde7QmbyBClfcDnKkO04u W2v20XXrZvXtnpl7zM+sneFjrSyrxFKckWioxVxUnAgArcstgY8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Tn6w2yWQsqBg7pon9PWNKZpKTGk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 05:06:39 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AC5CBeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsIGV0LiBhbCwNCnlvdeKAmXZlIHNhaWQ6DQpJZGVhbGx5IGV2ZW4gaWYgdGhlcmUg aXMgc29tZSBiaXQgb2YgY29uZ2VzdGlvbiBpIHdvdWxkIGxpa2UgdGhlIEJGRCBwYWNrZXQgdG8g Z2V0IHRocm91Z2guDQpBc3N1bWUgdGhhdCB0aGUgY29uZ2VzdGlvbiBpcyBpbiBlZ3Jlc3MgcXVl dWUsIHJlbGF0ZWQgdG8gdGhlIGZhc3QgZm9yd2FyZGluZyBwYXRoLiBUaGVuIHdvdWxkbuKAmXQg cHVzaGluZyBCRkQgY29udHJvbCBwYWNrZXRzIGFoZWFkIG9mIGV2ZXJ5IG90aGVyIHBhY2tldCBv ZiB0aGUgc2FtZSBEU0NQIGJlIGhpZGluZyB0aGUgcHJvYmxlbSBpbiB0aGUgbmV0d29yaywgcmF0 aGVyIHRoYW4gZGV0ZWN0aW5nIGl0LCBkb2luZyBleGFjdGx5IHdoYXQgQkZEIGludGVuZGVkIHRv IGRvPyBQZXJoYXBzIHRoYXQsIHR1bmluZyBEU0NQIG1hcmtpbmcgb2YgQkZELCBpcyBzb21ldGhp bmcgdG8gbG9vayBpbnRvIGJlZm9yZSBjaGFuZ2luZyBCRkQ/DQoNCiAgICAgICAgICAgICAgICBS ZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IE1h bmF2IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5 LCBEZWNlbWJlciAwNCwgMjAxNCA1OjA1IFBNDQpUbzogU2FtIEsuIEFsZHJpbg0KQ2M6IEdyZWdv cnkgTWlyc2t5OyBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQkZEIHN0YWJpbGl0eSBm b2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIFNhbSwNCg0KDQpDb25jZXJuOg0KLSBXaXRoIHRo ZSBzZXF1ZW5jZSBudW1iZXIgYWRkZWQsIG9uZSBjb3VsZCBmaW5kKD8pIHRoYXQgQkZEIGNvbnRy b2wgcGFja2V0cyBhcmUgZXhwZXJpZW5jaW5nIGNvbmdlc3Rpb24gb3IgcGFja2V0IGRlbGF5LiBT bywgdGhlIGFzc2VydGlvbiBpcyB0aGF0IEJGRCBmbGFwcGluZyBjb3VsZCBiZSBhdm9pZGVkLiBC dXQgaWYgdGhlIHBhY2tldHMgaW4gdGhlIG5ldHdvcmssIGluY2x1ZGluZyBCRkQsIGFyZSByZWFs bHkgZXhwZXJpZW5jaW5nIHRoaXMsIHNob3VsZG4ndCB0aGlzIGJlIHRoZSByaWdodCBiZWhhdmlv cj8NCg0KSSB3YXMgbG9va2luZyBhdCBpdCB0byBoZWxwIGRlYnVnIHNjZW5hcmlvcyB3aGVyZSBp dHMgbm90IGp1c3QgdGhlIG5ldHdvcmsgYnV0IGltcGxlbWVudGF0aW9uIGlzc3VlcyBhcyB3ZWxs IHRoYXQgY2F1c2Ugc3BvcmFkaWMgQkZEIGZsYXBzLiBJZiB5b3UgaGF2ZSBhIEJGRCBwa3QgbHlp bmcgaW4geW91ciBidWZmZXIgZm9yIHRvbyBsb25nIGJlZm9yZSBpdHMgZ2V0cyBzY2hlZHVsZWQg b3V0LCB0aGVuIHBlcmhhcHMgdGhlcmUgaXMgYSBjYXNlIGZvciB5b3UgdG8gbG9vayBhdCB5b3Vy IHBrdCBUWCBzY2hlZHVsZXIuIFNpbWlsYXJseSwgeW91IGNvdWxkIGxvb2sgYXQgaXNzdWVzIG9u IHRoZSBSWCBzaWRlIC0tIHBlcmhhcHMgdGhlIHF1ZXVlIGlzbnQgYmVpbmcgZHJhaW5lZCBmYXN0 IGVub3VnaCwgb3IgdGhlIENJUi9QSVIgdmFsdWVzIGFyZSBhZ2dyZXNzaXZlIGFuZCB5b3UgZHJv cCBjZXJ0YWluIHBhY2tldHMgd2hlbiB5b3UgaGF2ZSBzY2FsZWQgdXAgQkZEIHNlc3Npb25zLg0K DQpJZGVhbGx5IGV2ZW4gaWYgdGhlcmUgaXMgc29tZSBiaXQgb2YgY29uZ2VzdGlvbiBpIHdvdWxk IGxpa2UgdGhlIEJGRCBwYWNrZXQgdG8gZ2V0IHRocm91Z2guDQoNCkNoZWVycywgTWFuYXYNCg0K LSBJIHNlZSBjb25jZXJucyByZWdhcmRpbmcgdGltZXN0YW1wcyBhbmQgc2VxdWVuY2UgbnVtYmVy cyBleHByZXNzZWQgaW4gZW1haWxzLiBJbiB0aGF0IGNhc2UsIHRoZSBwcm9wb3NlZCBtb2RlbCBp cyBzdGlsbCBub3QgZ29pbmcgdG8gaWRlbnRpZnkgdGhlIHByb2JsZW0gY29tcGxldGVseS4gQW0g SSByZWFkaW5nIGl0IHJpZ2h0Pw0KDQotc2FtDQpPbiBEZWMgNCwgMjAxNCwgYXQgNzo0NyBBTSwg R3JlZ29yeSBNaXJza3kgd3JvdGU6DQoNCj4gSGkgSmVmZiwNCj4gSSBjYW4gcmVmZXJlbmNlIFJG QyA1MzU3IGhlcmUuIFRoZSBBcHBlbmRpeCBkZXNjcmliZXMgd2hhdCBpcyBjYWxsZWQgVFdBTVAt TGlnaHQgbW9kZSB3aXRoIFN0YXRlbGVzcyBSZWZsZWN0b3IuIEFib3V0IHllYXIgYW5kIGEgaGFs ZiB0aGUgRXJyYXRhIGJlZW4gYWNjZXB0ZWQgdGhhdCBkZXNjcmliZXMgU3RhdGVmdWwgUmVmbGVj dG9yLCB3aGljaCBzdXBwb3J0cyBtZWFzdXJlbWVudCBvZiBvbmUtd2F5IGxhdGVuY3kvaml0dGVy IGFuZCBwYWNrZXQgbG9zcyBtZXRyaWNzLg0KPg0KPiAgICAgICBSZWdhcmRzLA0KPiAgICAgICAg ICAgICAgIEdyZWcNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnRn LWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEplZmZyZXkgSGFhcw0KPiBTZW50OiBUaHVyc2Rh eSwgRGVjZW1iZXIgMDQsIDIwMTQgNzoxNyBBTQ0KPiBUbzogTm9ibyBBa2l5YSAobm9ibykNCj4g Q2M6IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6 IFJlOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4NCj4gT24gVGh1LCBE ZWMgMDQsIDIwMTQgYXQgMDM6MTQ6NTBQTSArMDAwMCwgTm9ibyBBa2l5YSAobm9ibykgd3JvdGU6 DQo+PiBJZiB3aGF0IHlvdSBzYXkgaXMgdGhlIG9ubHkgcmVxdWlyZW1lbnQgbm90IG1ldCwgb25l IGFwcHJvYWNoIG1heSBiZSB0byBwdXJzdWUgYSBub24tc3RhbmRhcmQtdHJhY2sgZG9jdW1lbnQg ZGVzY3JpYmluZyBzb21lIHN1Z2dlc3RlZCBpbXBsZW1lbnRhdGlvbiB0ZWNobmlxdWVzIHRvIGxv Y2FsbHkgc3RvcmUgVFgvUlggdGltZXN0YW1wLg0KPj4NCj4+IEdpdmVuIHRoYXQgZWNobyBhcHBy b2FjaCB3aWxsIGJlIGxlc3MgYWNjdXJhdGUgYW5kIGdpdmVuIHRoYXQgd2Ugc2VlbSB0byBiZSBo YXZpbmcgZGlmZmljdWx0eSBjb252ZXJnaW5nLCBJIHRob3VnaHQgST8/P2xsIHRocm93IG91dCBh bm90aGVyIGlkZWEuDQo+DQo+IEkgdGhpbmsgbXkgYmlnZ2VzdCBjb25jZXJuIGlzIHRoYXQgdGhl IGVjaG8gYXBwcm9hY2ggaGFzIGJpZGlyZWN0aW9uYWwgcGFja2V0IGxvc3MgcG9zc2liaWxpdGll cy4gIEFzeW5jIGF0IGxlYXN0IGxldHMgdGhlIHJlY2VpdmVyIGtub3cgYWJvdXQgdW5pZGlyZWN0 aW9uYWwgcGFja2V0IGxvc3MuDQo+DQo+IE9mIGNvdXJzZSwgaWYgeW91ciBnb2FsIGlzIHRvIG5v dGlmeSB0aGUgc2VuZGVyIHRoYXQgdGhlaXIgcGFja2V0cyBhcmUgYmVpbmcgbG9zdCwgeW91IG5l ZWQgYSBiYWNrY2hhbm5lbCBhbnl3YXkuICBJIGp1c3QgZG9uJ3Qga25vdyBpZiB3ZSB3YW50IHRo YXQgYmFjayBjaGFubmVsIHRvIGJlIGJmZC4NCj4NCj4gLSBKZWZmDQo+DQoNCg== --_000_7347100B5761DC41A166AC17F22DF1121B8AC5CBeusaamb103erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LCBldC4gYWwsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPnlvdeKAmXZlIHNhaWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SWRlYWxseSBldmVuIGlmIHRoZXJlIGlzIHNvbWUgYml0IG9mIGNv bmdlc3Rpb24gaSB3b3VsZCBsaWtlIHRoZSBCRkQgcGFja2V0IHRvIGdldCB0aHJvdWdoLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzc3VtZSB0aGF0IHRoZSBjb25nZXN0aW9uIGlzIGluIGVncmVz cyBxdWV1ZSwgcmVsYXRlZCB0byB0aGUgZmFzdCBmb3J3YXJkaW5nIHBhdGguIFRoZW4gd291bGRu 4oCZdCBwdXNoaW5nIEJGRCBjb250cm9sIHBhY2tldHMgYWhlYWQgb2YgZXZlcnkgb3RoZXIgcGFj a2V0IG9mDQogdGhlIHNhbWUgRFNDUCBiZSBoaWRpbmcgdGhlIHByb2JsZW0gaW4gdGhlIG5ldHdv cmssIHJhdGhlciB0aGFuIGRldGVjdGluZyBpdCwgZG9pbmcgZXhhY3RseSB3aGF0IEJGRCBpbnRl bmRlZCB0byBkbz8gUGVyaGFwcyB0aGF0LCB0dW5pbmcgRFNDUCBtYXJraW5nIG9mIEJGRCwgaXMg c29tZXRoaW5nIHRvIGxvb2sgaW50byBiZWZvcmUgY2hhbmdpbmcgQkZEPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFp bC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDU6 MDUgUE08YnI+DQo8Yj5Ubzo8L2I+IFNhbSBLLiBBbGRyaW48YnI+DQo8Yj5DYzo8L2I+IEdyZWdv cnkgTWlyc2t5OyBydGctYmZkQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBCRkQg c3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSBTYW0sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpDb25jZXJuOjxicj4NCi0g V2l0aCB0aGUgc2VxdWVuY2UgbnVtYmVyIGFkZGVkLCBvbmUgY291bGQgZmluZCg/KSB0aGF0IEJG RCBjb250cm9sIHBhY2tldHMgYXJlIGV4cGVyaWVuY2luZyBjb25nZXN0aW9uIG9yIHBhY2tldCBk ZWxheS4gU28sIHRoZSBhc3NlcnRpb24gaXMgdGhhdCBCRkQgZmxhcHBpbmcgY291bGQgYmUgYXZv aWRlZC4gQnV0IGlmIHRoZSBwYWNrZXRzIGluIHRoZSBuZXR3b3JrLCBpbmNsdWRpbmcgQkZELCBh cmUgcmVhbGx5IGV4cGVyaWVuY2luZyB0aGlzLA0KIHNob3VsZG4ndCB0aGlzIGJlIHRoZSByaWdo dCBiZWhhdmlvcj88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgd2FzIGxvb2tpbmcgYXQgaXQgdG8gaGVscCBkZWJ1ZyBzY2VuYXJp b3Mgd2hlcmUgaXRzIG5vdCBqdXN0IHRoZSBuZXR3b3JrIGJ1dCBpbXBsZW1lbnRhdGlvbiBpc3N1 ZXMgYXMgd2VsbCB0aGF0IGNhdXNlIHNwb3JhZGljIEJGRCBmbGFwcy4gSWYgeW91IGhhdmUgYSBC RkQgcGt0IGx5aW5nIGluIHlvdXIgYnVmZmVyIGZvciB0b28gbG9uZyBiZWZvcmUgaXRzIGdldHMg c2NoZWR1bGVkIG91dCwgdGhlbiBwZXJoYXBzDQogdGhlcmUgaXMgYSBjYXNlIGZvciB5b3UgdG8g bG9vayBhdCB5b3VyIHBrdCBUWCBzY2hlZHVsZXIuIFNpbWlsYXJseSwgeW91IGNvdWxkIGxvb2sg YXQgaXNzdWVzIG9uIHRoZSBSWCBzaWRlIC0tIHBlcmhhcHMgdGhlIHF1ZXVlIGlzbnQgYmVpbmcg ZHJhaW5lZCBmYXN0IGVub3VnaCwgb3IgdGhlIENJUi9QSVIgdmFsdWVzIGFyZSBhZ2dyZXNzaXZl IGFuZCB5b3UgZHJvcCBjZXJ0YWluIHBhY2tldHMgd2hlbiB5b3UgaGF2ZSBzY2FsZWQgdXAgQkZE DQogc2Vzc2lvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklkZWFsbHkgZXZlbiBpZiB0aGVyZSBpcyBzb21lIGJpdCBvZiBjb25nZXN0aW9u IGkgd291bGQgbGlrZSB0aGUgQkZEIHBhY2tldCB0byBnZXQgdGhyb3VnaC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLCBNYW5hdjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tIEkgc2VlIGNvbmNlcm5zIHJlZ2FyZGluZyB0aW1lc3RhbXBzIGFuZCBzZXF1ZW5jZSBudW1i ZXJzIGV4cHJlc3NlZCBpbiBlbWFpbHMuIEluIHRoYXQgY2FzZSwgdGhlIHByb3Bvc2VkIG1vZGVs IGlzIHN0aWxsIG5vdCBnb2luZyB0byBpZGVudGlmeSB0aGUgcHJvYmxlbSBjb21wbGV0ZWx5LiBB bSBJIHJlYWRpbmcgaXQgcmlnaHQ/PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxi cj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi1zYW08L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPk9uIERlYyA0LCAyMDE0LCBhdCA3OjQ3IEFNLCBHcmVnb3J5IE1pcnNreSB3cm90 ZTo8YnI+DQo8YnI+DQomZ3Q7IEhpIEplZmYsPGJyPg0KJmd0OyBJIGNhbiByZWZlcmVuY2UgUkZD IDUzNTcgaGVyZS4gVGhlIEFwcGVuZGl4IGRlc2NyaWJlcyB3aGF0IGlzIGNhbGxlZCBUV0FNUC1M aWdodCBtb2RlIHdpdGggU3RhdGVsZXNzIFJlZmxlY3Rvci4gQWJvdXQgeWVhciBhbmQgYSBoYWxm IHRoZSBFcnJhdGEgYmVlbiBhY2NlcHRlZCB0aGF0IGRlc2NyaWJlcyBTdGF0ZWZ1bCBSZWZsZWN0 b3IsIHdoaWNoIHN1cHBvcnRzIG1lYXN1cmVtZW50IG9mIG9uZS13YXkgbGF0ZW5jeS9qaXR0ZXIg YW5kIHBhY2tldA0KIGxvc3MgbWV0cmljcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1JlZ2FyZHMsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtHcmVnPGJyPg0KJmd0Ozxicj4NCiZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IFJ0Zy1iZmQgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIj5ydGctYmZkLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSmVmZnJleSBIYWFzPGJyPg0KJmd0OyBTZW50 OiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgNzoxNyBBTTxicj4NCiZndDsgVG86IE5vYm8g QWtpeWEgKG5vYm8pPGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5v cmciPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogQkZEIHN0YWJp bGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gVGh1LCBE ZWMgMDQsIDIwMTQgYXQgMDM6MTQ6NTBQTSAmIzQzOzAwMDAsIE5vYm8gQWtpeWEgKG5vYm8pIHdy b3RlOjxicj4NCiZndDsmZ3Q7IElmIHdoYXQgeW91IHNheSBpcyB0aGUgb25seSByZXF1aXJlbWVu dCBub3QgbWV0LCBvbmUgYXBwcm9hY2ggbWF5IGJlIHRvIHB1cnN1ZSBhIG5vbi1zdGFuZGFyZC10 cmFjayBkb2N1bWVudCBkZXNjcmliaW5nIHNvbWUgc3VnZ2VzdGVkIGltcGxlbWVudGF0aW9uIHRl Y2huaXF1ZXMgdG8gbG9jYWxseSBzdG9yZSBUWC9SWCB0aW1lc3RhbXAuPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBHaXZlbiB0aGF0IGVjaG8gYXBwcm9hY2ggd2lsbCBiZSBsZXNzIGFjY3Vy YXRlIGFuZCBnaXZlbiB0aGF0IHdlIHNlZW0gdG8gYmUgaGF2aW5nIGRpZmZpY3VsdHkgY29udmVy Z2luZywgSSB0aG91Z2h0IEk/Pz9sbCB0aHJvdyBvdXQgYW5vdGhlciBpZGVhLjxicj4NCiZndDs8 YnI+DQomZ3Q7IEkgdGhpbmsgbXkgYmlnZ2VzdCBjb25jZXJuIGlzIHRoYXQgdGhlIGVjaG8gYXBw cm9hY2ggaGFzIGJpZGlyZWN0aW9uYWwgcGFja2V0IGxvc3MgcG9zc2liaWxpdGllcy4mbmJzcDsg QXN5bmMgYXQgbGVhc3QgbGV0cyB0aGUgcmVjZWl2ZXIga25vdyBhYm91dCB1bmlkaXJlY3Rpb25h bCBwYWNrZXQgbG9zcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPZiBjb3Vyc2UsIGlmIHlvdXIgZ29h bCBpcyB0byBub3RpZnkgdGhlIHNlbmRlciB0aGF0IHRoZWlyIHBhY2tldHMgYXJlIGJlaW5nIGxv c3QsIHlvdSBuZWVkIGEgYmFja2NoYW5uZWwgYW55d2F5LiZuYnNwOyBJIGp1c3QgZG9uJ3Qga25v dyBpZiB3ZSB3YW50IHRoYXQgYmFjayBjaGFubmVsIHRvIGJlIGJmZC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyAtIEplZmY8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B8AC5CBeusaamb103erics_-- From nobody Thu Dec 4 21:10:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373151AC40E for ; Thu, 4 Dec 2014 21:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 pITaJrYqoROT for ; Thu, 4 Dec 2014 21:10:20 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 9604E1AC401 for ; Thu, 4 Dec 2014 21:10:20 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-ca-5480e1f11c08 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BA.BE.25146.1F1E0845; Thu, 4 Dec 2014 23:36:34 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 00:10:18 -0500 From: Gregory Mirsky To: "Sam K. Aldrin" , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQDUqXQ6amXjPuFEmbPIOgLl4p2px+NluAgAAjMzCAAOz5gP//rP5ggACs1ACAAAiDAIAAAPgAgAAA6YCAACPdgIAADrqAgAAGAACAAAClAP//s40ggAB9OQCAAHOGgIAACf0AgAATpICAABESgP//wZlg Date: Fri, 5 Dec 2014 05:10:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AC5E4@eusaamb103.ericsson.se> References: <20141204151708.GA9458@pfrc> <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> <58D290A6-1EB1-425B-9FFA-3025A3CAE4EE@gmail.com> <3EA747F1-FFDD-4E36-B8A2-58E362C1F601@gmail.com> In-Reply-To: <3EA747F1-FFDD-4E36-B8A2-58E362C1F601@gmail.com> 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_7347100B5761DC41A166AC17F22DF1121B8AC5E4eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonXPfTw4YQg5l7OC0mtH5htLg8qY3d 4vOfbYwOzB47Z91l91iy5CdTAFMUl01Kak5mWWqRvl0CV8bdjX3sBQu2MlY8u/aOsYHx4nTG LkZODgkBE4nfe7dC2WISF+6tZ+ti5OIQEjjCKDH7xk0mCGcZo8T/9klsIFVsAkYSLzb2sIPY IgLBEnu/nQXrZhbQlGg68RksLixgKLGqezFUjZHEsRlz2UEGiQisYpSYfukOK0iCRUBFYv/M /cwgNq+Ar8TyPVtYILZtYJP41LeACSTBKWArseL7UTCbEei+76fWMEFsE5e49WQ+E8TdAhJL 9pxnhrBFJV4+/scKYStJfPw9nx2iPl9i/uYmNohlghInZz5hmcAoOgvJqFlIymYhKYOI60gs 2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDcxAiPtmASb4w7GBZ8sDzEKcDAq 8fBuiK0PEWJNLCuuzD3EKM3BoiTOq1k9L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD484o /dXXJ15T26yQu9Gt/ab2lKou303xRyaJNk2f4Wp1qSxpuWvhllbfxH8d83wWpMckthw1j13s fPpzj2D97F6RlnePjgsdMqpUtAifrNU7ufSG3vmk27KReo6blQ80y0zdfm4x56JTLVJqN48t eBd/hPPBO8eidwpFJx7+OML5u2dPP9NCZSWW4oxEQy3mouJEAD5viVuVAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aWGFSfY6iihApetSjP9phqihQhY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 05:10:31 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AC5E4eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, et. al, if we're starting to compile list of requirements for what may become BFDv2= - count me in. Regards, Greg From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Thursday, December 04, 2014 7:52 PM To: Manav Bhatia Cc: Gregory Mirsky; rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Manav, On Dec 4, 2014, at 6:51 PM, Manav Bhatia wrote: Hi Sam, Ideally even if there is some bit of congestion i would like the BFD packet= to get through. I understand the queuing problems but I am not clear how the ID is going to= solve the problem, if there is only congestion and not It would help. Assume the last sequence number you saw before the flap was s1. You timed o= ut since you did not see s2 and s3 before the timeout. Now further assume t= hat you know that you did receive s2 and s3, however they arrived after the= BFD expiry interval then you know that there wasnt a drop, and the packet = arrived late because of some queing issue. Now how you determine whether th= is delay was seen at the TX or RX side is open to discussion. As the draft doesn't say, what exactly one would/should do, assuming there = is packet throttling happing due to various reasons, could you/authors elab= orate on this? I would like to see those tangible things detailed first. I see the problem little differently though. BFD session flapping is an ind= icator of the network behavior, be it device or network congestion or somet= hing else. Even if the packets arrive late, as you say, one cannot know whe= re exactly the delay is happening. Without a sequence number you have no idea whether the packet was dropped o= r whether it arrived/processed late. If by some out-of-band mechanism you can figure out that the TX was done on= time and the delay was at RX end then its an implementation issue on the R= X side. If the TX was delayed then its an implementation issue at the TX si= de. Don't think so. It could be the lot more than implementation issue. Could b= e due to network congestion due to bursty traffic and nothing to do with th= e implementation. This helps isolating the node that needs to fix the issue, otherwise we're = only shooting in the dark. The issue you see is what I think could be the actual network behavior and = not the device issue. Debugging Packet drops, latency and mis-ordering of packets is mostly shoot= ing in the dark :D Nevertheless, I do not see this as BFD specific only. packet drop. In that case just the sequence # doesn't help and timestamping= is needed. Even if timestamping is to be done, realistically it cannot hap= pen the same way across multi vendor i.e. where the timestamping should/cou= ld be done. For ex: Before it is queued or after OR LC/RP/SP/Process etc. This isnt a new problem. Each vendor time stamps 1588 packets differently. = However, the aggregate solution works across multiple vendors. While it may not solve all the issues because of the vagaries of how each v= endor does time stamping it would certainly help debugging large number of = BFD flaps. As timestamp is not in the ID, we could differ the discussion for later, bu= t I definitely believe that it is a bigger issue where TS is taken, if gra= nularity and accuracy are important. Secondly, if the congestion happens, the CIR/PIR should apply to data packe= ts too. In that case BFD flap is at least a good indicator of the problem, = isn't it? There is usually a separate CIR/PIR for different CPU bound packets. So bas= ed on some parameters you might impose a different CIR/PIR for BFD than say= , ssh and radius packets. If BFD flaps and you know you missed a few sequen= ce numbers and you see drops in that queue then all of this could be co-rel= ated and you could fix the CPU queue parameters for BFD. I understand that = this is a very implementation specific issue, but then thats what i had sai= d earlier -- such a mechanism can help in isolating implementation specific= issues as well. I agree that it will be helpful. But then, when a new mechanism is introduc= ed, it should clearly spell out the mechanisms on interpreting the problems= and how to deal with it. The ID has none of it, as of now. Lastly, these improvements is change from the existing BFD model/protocol. I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D Sure, that would make Marc very happy ! :-) I am not sure if we have enough momentum right now that can propel us towar= ds BFD v2. OTOH, if the WG believes that this is an opportune time for us to start loo= king at BFDv2, then i would be more than willing to participate! Well, if there is real issue that existing BFD falls short of the needs, th= en interest automatically increases. As this ID introduces new things to ex= isting version, it should be pursued as part of next version, rather than c= hanging the existing model for the same version. -sam Cheers, Manav -sam Cheers, Manav - I see concerns regarding timestamps and sequence numbers expressed in ema= ils. In that case, the proposed model is still not going to identify the pr= oblem completely. Am I reading it right? -sam On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote: > Hi Jeff, > I can reference RFC 5357 here. The Appendix describes what is called TWAM= P-Light mode with Stateless Reflector. About year and a half the Errata bee= n accepted that describes Stateful Reflector, which supports measurement of= one-way latency/jitter and packet loss metrics. > > Regards, > Greg > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Thursday, December 04, 2014 7:17 AM > To: Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: Re: BFD stability follow-up from IETF-91 > > On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote: >> If what you say is the only requirement not met, one approach may be to = pursue a non-standard-track document describing some suggested implementati= on techniques to locally store TX/RX timestamp. >> >> Given that echo approach will be less accurate and given that we seem to= be having difficulty converging, I thought I???ll throw out another idea. > > I think my biggest concern is that the echo approach has bidirectional pa= cket loss possibilities. Async at least lets the receiver know about unidi= rectional packet loss. > > Of course, if your goal is to notify the sender that their packets are be= ing lost, you need a backchannel anyway. I just don't know if we want that= back channel to be bfd. > > - Jeff > --_000_7347100B5761DC41A166AC17F22DF1121B8AC5E4eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sam, et. al,

if we’re starting t= o compile list of requirements for what may become BFDv2 – count me i= n.

 <= /p>

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

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

 <= /p>

From: Sam K. A= ldrin [mailto:aldrin.ietf@gmail.com]
Sent: Thursday, December 04, 2014 7:52 PM
To: Manav Bhatia
Cc: Gregory Mirsky; rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91<= /p>

 

Hi Manav,

 

On Dec 4, 2014, at 6:51 PM, Manav Bhatia wrote:=



Hi Sam,

Ideally even if there is some bit of congestion i wo= uld like the BFD packet to get through.

I understand the queuing problems but I am not clear= how the ID is going to solve the problem, if there is only congestion and = not

 

It would help.

 

Assume the last sequence number you saw before the f= lap was s1. You timed out since you did not see s2 and s3 before the timeou= t. Now further assume that you know that you did receive s2 and s3, however= they arrived after the BFD expiry interval then you know that there wasnt a drop, and the packet arrived lat= e because of some queing issue. Now how you determine whether this delay wa= s seen at the TX or RX side is open to discussion.

 

As the draft doesn't say, what exactly one would/sho= uld do, assuming there is packet throttling happing due to various reasons,= could you/authors elaborate on this? I would like to see those tangible th= ings detailed first.

 

I see the problem little differently though. BFD ses= sion flapping is an indicator of the network behavior, be it device or netw= ork congestion or something else. Even if the packets arrive late, as you s= ay, one cannot know where exactly the delay is happening.



 

Without a sequence number you have no idea whether t= he packet was dropped or whether it arrived/processed late. 

 

If by some out-of-band mechanism you can figure out = that the TX was done on time and the delay was at RX end then its an implem= entation issue on the RX side. If the TX was delayed then its an implementa= tion issue at the TX side.

Don't think so. It could be the lot more than implem= entation issue. Could be due to network congestion due to bursty traffic an= d nothing to do with the implementation.

 

This helps isolating the node that needs to fix the = issue, otherwise we're only shooting in the dark. 

The issue you see is what I think could be the actua= l network behavior and not the device issue. 

Debugging Packet drops, latency and mis-ordering of = packets is mostly shooting in the dark :D

Nevertheless, I do not see this as BFD specific only= . 



 

packet drop. In that case just the sequence # doesn'= t help and timestamping is needed. Even if timestamping is to be done, real= istically it cannot happen the same way across multi vendor i.e. where the = timestamping should/could be done. For ex: Before it is queued or after OR LC/RP/SP/Process etc.

 

This isnt a new problem. Each vendor time stamps 158= 8 packets differently. However, the aggregate solution works across multipl= e vendors.

 

While it may not solve all the issues because of the= vagaries of how each vendor does time stamping it would certainly help deb= ugging large number of BFD flaps.

As timestamp is not in the ID, we could differ the d= iscussion for later, but I definitely believe that it is a bigger issue whe= re TS is taken, if  granularity and accuracy are important.

 

 

Secondly, if the congestion happens, the CIR/PIR sho= uld apply to data packets too. In that case BFD flap is at least a good ind= icator of the problem, isn't it? 

 

There is usually a separate CIR/PIR for different CP= U bound packets. So based on some parameters you might impose a different C= IR/PIR for BFD than say, ssh and radius packets. If BFD flaps and you know = you missed a few sequence numbers and you see drops in that queue then all of this could be co-related and y= ou could fix the CPU queue parameters for BFD. I understand that this is a = very implementation specific issue, but then thats what i had said earlier = -- such a mechanism can help in isolating implementation specific issues as well.

I agree that it will be helpful. But then, when a ne= w mechanism is introduced, it should clearly spell out the mechanisms on in= terpreting the problems and how to deal with it. The ID has none of it, as = of now.

 

 

Lastly, these improvements is change from the existi= ng BFD model/protocol. 

I do not see why it shouldn't be part of BFD v2 OR l= ead to v2 :D

 

Sure, that would make Marc very happy ! :-)

 

I am not sure if we have enough momentum right now t= hat can propel us towards BFD v2.

 

OTOH, if the WG believes that this is an opportune t= ime for us to start looking at BFDv2, then i would be more than willing to = participate!

Well, if there is real issue that existing BFD falls= short of the needs, then interest automatically increases. As this ID intr= oduces new things to existing version, it should be pursued as part of next= version, rather than changing the existing model for the same version.

 

-sam



 

Cheers, Manav 

 

-sam

 

Cheers, Manav

 

- I see concerns regarding timestamps and sequence n= umbers expressed in emails. In that case, the proposed model is still not g= oing to identify the problem completely. Am I reading it right?

-sam

On Dec 4, 2014, at 7:= 47 AM, Gregory Mirsky wrote:

> Hi Jeff,
> I can reference RFC 5357 here. The Appendix describes what is called T= WAMP-Light mode with Stateless Reflector. About year and a half the Errata = been accepted that describes Stateful Reflector, which supports measurement= of one-way latency/jitter and packet loss metrics.
>
>       Regards,
>               Greg
>
> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Thursday, December 04, 2014 7:17 AM
> To: Nobo Akiya (nobo)
> Cc: rtg-bfd@ietf= .org
> Subject: Re: BFD stability follow-up from IETF-91
>
> On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote:=
>> If what you say is the only requirement not met, one approach may = be to pursue a non-standard-track document describing some suggested implem= entation techniques to locally store TX/RX timestamp.
>>
>> Given that echo approach will be less accurate and given that we s= eem to be having difficulty converging, I thought I???ll throw out another = idea.
>
> I think my biggest concern is that the echo approach has bidirectional= packet loss possibilities.  Async at least lets the receiver know abo= ut unidirectional packet loss.
>
> Of course, if your goal is to notify the sender that their packets are= being lost, you need a backchannel anyway.  I just don't know if we w= ant that back channel to be bfd.
>
> - Jeff
>

 

 

 

 

--_000_7347100B5761DC41A166AC17F22DF1121B8AC5E4eusaamb103erics_-- From nobody Thu Dec 4 21:22:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310391AC41A for ; Thu, 4 Dec 2014 21:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 6LPmnyLQ0ec4 for ; Thu, 4 Dec 2014 21:22:05 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 5A7DC1AC40F for ; Thu, 4 Dec 2014 21:22:05 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-bd-5480f0e0baae Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4D.BD.03307.0E0F0845; Fri, 5 Dec 2014 00:40:16 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 00:22:03 -0500 From: Gregory Mirsky To: Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAjSUAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAF9PggASh4oD///wSUIACoyWAgADg8VCAAMxrgP//rMkggADkGwD//7U6cAAL8ywAAAn4weAADJJRgAAF3o0g Date: Fri, 5 Dec 2014 05:22:03 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AC60A@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@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_7347100B5761DC41A166AC17F22DF1121B8AC60Aeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonQffBh4YQgw2/DSwuT2pjtzj9Zh2b xec/2xgtrt3dyuzA4rFz1l12jyVLfjJ5XG+6yh7AHMVlk5Kak1mWWqRvl8CVMentF9aCI28Y K2bfnMzcwLjiGWMXIyeHhICJxK6925khbDGJC/fWs3UxcnEICRxhlGh9f5wVwlnGKPF0y2o2 kCo2ASOJFxt72EFsEQENoKIDYN3MAvUSl6fMZAWxhQUMJVZ1L4aqMZI4NmMuO8ggEYF9jBKd NxeBrWYRUJF48nwlC4jNK+Ar0dG7nxli2xp2iT+Le8ASnAKBErs2rQPbzAh03/dTa5ggtolL 3HoynwnibgGJJXvOQ/0gKvHy8T9WCFtJ4uPv+ewQ9fkS37afgFomKHFy5hOWCYyis5CMmoWk bBaSslmMHEBxTYn1u/QhShQlpnQ/ZIewgf6fM5cdWXwBI/sqRo7S4tSy3HQjg02MwNg7JsGm u4Nxz0vLQ4wCHIxKPLwFzxtChFgTy4orcw8xSnOwKInzzqqdFywkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBsb3+0Y8at29N7j832bQx5Ha/PqTLefaxY/wTnsSG1/dV8lT6EzPtVlouKU/X 0zafsTo5jUEj8OXG8prsDMOCJW15VbsVvx91DtvU2p7wcoHXMrbgB27zf59VaEnSiu/cUy09 9SLrsxXbJ81WOcqXX65z3yz91x4NnqmOuz2+dgfN+fJN3VRIiaU4I9FQi7moOBEAqGo8Mp4C AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5eevMuvqzWjBEvwNPHiGdeNnqmo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 05:22:08 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AC60Aeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQppZiBXRyBjaGFpcnMgZmVlbCB0aGF0IEJGRCBpbXBsZW1lbnRhdGlvbiBndWlk ZSB3b3VsZCBiZSBnb29kIHRvIHdyaXRlIHdlIG1heSBmaW5kIHdpbGxpbmcgY29udHJpYnV0b3Jz Lg0KQXMgZm9yIGdyYW51bGFyaXR5IG9mIGxvZ2dpbmcsIGltcGxlbWVudGF0aW9uIEnigJltIGZh bWlsaWFyIHdpdGggYWxsb3dzIGRvIHRoYXQgcGVyIEJGRCBzZXNzaW9uIHdpdGhvdXQgY29udGV4 dCBzd2l0Y2hpbmcuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBHcmVnDQoNClBTLiBvdXIgZGlzY3Vzc2lvbiBncmV3IGJleW9uZCB0 b2xlcmFuY2UgbGV2ZWwgb2YgbWFpbC1ob3N0LCBzbyBJ4oCZdmUgc25pcHBlZCBwYXJ0Lg0KDQpG cm9tOiBNYW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21dDQpTZW50OiBU aHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgNzowMiBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5DQpD YzogU2FudG9zaCBQIEs7IE1haGVzaCBKZXRoYW5hbmRhbmk7IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGkgR3Jl ZywNCg0KSSBhbSBzdXJlIHRoZSBXRyB3b3VsZCBhcHByZWNpYXRlIHN1Y2ggYSBsZWN0dXJlIHNp bmNlIHRoYXQgd291bGQgb2J2aWF0ZSB0aGUgbmVlZCBmb3Igc3VjaCBhbiBJRC4gQXJlIHlvdSBz dWdnZXN0aW5nIHRoYXQgaSB0dXJuIG9uIGxvZ2dpbmcgYW5kIHBhY2tldCB0cmFjaW5nIGZvciAq ZWFjaCogaW5jb21pbmcgQkZEIHBhY2tldCBmb3IgYWxsIHRoZSBzZXNzaW9ucyB0aGF0IGkgaGF2 ZT8gVHJ5aW5nIGRvaW5nIHRoYXQgZm9yIDI1IEJGRCBzZXNzaW9ucyB3aGVyZSBmZXcgYXJlIHJ1 bm5pbmcgYXQgNTBtcyBhbmQgMTAwbXMgVFggaW50ZXJ2YWxzLiBOb3cgdHJ5aW5nIGNvbWJpbmcg dGhyb3VnaCB0aGUgbG9ncyB3aGVuIDEgQkZEIHNlc3Npb24gZmxhcHMgdG8gdW5kZXJzdGFuZCB3 aGVyZSB0aGUgaXNzdWUgd2FzLg0KDQpDaGVlcnMsIE1hbmF2DQoNCk9uIFRodSwgRGVjIDQsIDIw MTQgYXQgMTA6MDMgUE0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgTWFuYXYs DQpJIGhvcGUgeW91IGRvbuKAmXQgZXhwZWN0IG1lIHRvIGdpdmUgYSBsZWN0dXJlIG9uIGhvdyB0 byBkZXNpZ24gYW5kIGltcGxlbWVudCBkZWJ1Z2FibGUgaW1wbGVtZW50YXRpb24gdXNpbmcgbG9n Z2luZyBhbmQgcGFja2V0IHRyYWNpbmcuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IE1hbmF2IEJoYXRpYSBb bWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbTxtYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29t Pl0NClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCA4OjE2IEFNDQpUbzogR3JlZ29y eSBNaXJza3kNCkNjOiBTYW50b3NoIFAgSzsgTWFoZXNoIEpldGhhbmFuZGFuaTsgcnRnLWJmZEBp ZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IEJGRCBzdGFi aWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KDQpJIGFtIG5vdCBzdXJlIHdoYXQgdGhlIGNv bmZ1c2lvbiBpcyBHcmVnLg0KDQpBc3N1bWUgaSBoYXZlIGEgQkZEIHNlc3Npb24gdGhhdHMgdXAu IEF0IHNvbWUgcG9pbnQgaW4gdGltZSBpdCBmbGFwcy4gTm93IGkgbmVlZCB0byBrbm93IHdoZXRo ZXIgdGhlIGlzc3VlIHdhcyBhdCB0aGUgVFggb3IgdGhlIFJYLg0KDQpQbGVhc2UgdGVsbCBtZSBo b3cgVFdBTVAgY2FuIGhlbHAgbWUgaGVyZS4gQWxzbyB0ZWxsIG1lIGhvdyB3aGF0IHRvb2wgaSBj YW4gdXNlIGlmIGl0cyBhIHVCRkQgc2Vzc2lvbiB0aGF0IGZsYXBwZWQuDQoNCkNoZWVycywgTWFu YXYNCg0KT24gVGh1LCBEZWMgNCwgMjAxNCBhdCA5OjA5IFBNLCBHcmVnb3J5IE1pcnNreSA8Z3Jl Z29yeS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b20+PiB3cm90ZToNCkhpIFNhbnRvc2gsDQpidXQgdGhhdCBpcyB3aGF0IGNhbiBiZSBjYWxsZWQg 4oCcZmVhdHVyZSBjcmVlcOKAnS4gQkZEIGlzIGNvbnRpbnVpdHkgY2hlY2sgbWVjaGFuaXNtIGFu ZCBmb3IgYWN0aXZlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LCBldmVuIG9jY2FzaW9uYWwsIHRo ZXJlIGFyZSBUV0FNUCBpbiBJUCBhbmQgUkZDIDYzNzQvNjM3NSBpbiBNUExTL01QTFMtVFAuIEl0 IG1heSBiZSB0ZW1wdGluZyB0byBleHBhbmQgc2NvcGUgb2YgQkZEIGJ1dCwgSSBiZWxpZXZlLCBp dCBpcyBzdWNjZXNzZnVsIGV4YWN0bHkgYmVjYXVzZSBpdCB3YXMgc2ltcGxlLCBsaWdodC13ZWln aHQgYW5kIGRlc2lnbmVkIHRvIGRvIGV4YWN0bHkgb25lIHRoaW5nIOKAkyBjb250aW51aXR5IGNo ZWNrLg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgR3JlZw0KDQpGcm9tOiBTYW50b3NoIFAgSyBbbWFpbHRvOnNhbnRvc2hwa0BqdW5p cGVyLm5ldDxtYWlsdG86c2FudG9zaHBrQGp1bmlwZXIubmV0Pl0NClNlbnQ6IFRodXJzZGF5LCBE ZWNlbWJlciAwNCwgMjAxNCA3OjAyIEFNDQpUbzogR3JlZ29yeSBNaXJza3k7IE1haGVzaCBKZXRo YW5hbmRhbmkNCg0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhl bGxvIEdyZWcsDQogIERlYnVnZ2luZyBCRkQgaXMgb25lIG9mIHRoZSB1c2UgY2FzZS4gSSBhbHNv IHdhbnQgdG8gYnJpbmcgdXAgb25lIG9mIHRoZSB1c2UgY2FzZSB0aGF0IEplZmYgc3VnZ2VzdGVk IGluIGhpcyBlYXJsaWVyICBtYWlsLiBPcGVyYXRvciBtaWdodCBOT1Qgd2FudCB0byBydW4gT0FN IHdoaWNoIGRvZXMgbG9zcyBhbmQgZGVsYXkgbWVhc3VyZW1lbnQgYWxsIHRoZSB0aW1lIGR1ZSB0 byBpdHMgb3ZlcmhlYWQuIFdpdGggdGhlIGV4dGVuc2lvbiB0byBCRkQgKHNlcXVlbmNlIG51bWJl cikgd2UgY2FuIGRldGVjdCBpZiB0aGVyZSBpcyBhbnkgbG9zcyBidXQgQkZEIHN0aWxsIHN0YXlz IHVwLiBUaGlzIGxvc3MgZGV0ZWN0aW9uIGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dlciBmb3IgbG9z cyBhbmQgZGVsYXkgbWVhc3VyZW1lbnQuIEVjaG8gY2FuIGJlIHVzZWQgb25seSBpbiBjYXNlIG9m IHNpbmdsZWhvcCBhbmQgaW4gb25lIGRpcmVjdGlvbiBvbmx5Lg0KDQpUaGFua3MNClNhbnRvc2gg UCBLDQoNCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHcmVnb3J5IE1pcnNreQ0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA0LCAy MDE0IDEyOjEyIFBNDQpUbzogTWFoZXNoIEpldGhhbmFuZGFuaQ0KQ2M6IHJ0Zy1iZmRAaWV0Zi5v cmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogQkZEIHN0YWJpbGl0eSBm b2xsb3ctdXAgZnJvbSBJRVRGLTkxDQoNCkhpIE1haGVzaCwNCmluZGVlZCwgTFNQIFBpbmcgaXMg cGFydCBvZiBNUExTIE9BTSB0b29sIHNldCBhcyBCRkQgaXRzZWxmIHRoYXQgaW50ZW5kZWQgdG8g bW9uaXRvciBvcGVyYXRpb25hbCBzdGF0ZSBvZiB0aGUgbmV0d29yaywgcGF0aCBjb250aW51aXR5 IGJldHdlZW4gdHdvIG5vZGVzLiBBbmQgTFNQIFBpbmcsIGFzIHByaW1hcmlseSBvbi1kZW1hbmQg dHJvdWJsZXNob290aW5nIHRvb2wsIGhlbHBzIGxvY2FsaXplIGFuZCwgdG8gY2VydGFpbiBkZWdy ZWUsIGRpYWdub3NlIHRoZSBwcm9ibGVtLiBCdXQgdGhlIHVsdGltYXRlIGRlYnVnZ2luZyBpcyBw cm9wcmlldGFyeS4gVGhpcyBwcm9wb3NhbCwgaW4gbXkgdmlldywgaGVscHMgbm90IG1vbml0b3Ig YmVoYXZpb3Igb2YgdGhlIG5ldHdvcmsgYnV0IEJGRCBpdHNlbGYsIHF1YWxpdHkgb2YgQkZEIGlt cGxlbWVudGF0aW9uLiBJ4oCZbSBub3Qgc2F5aW5nIHRoYXQgaXQgaXMgbm90IHVzZWZ1bCBmb3Ig aW1wbGVtZW50ZXJzIGFuZCBvcGVyYXRvcnMsIG9uZSBjYW4gZmluZCB0aGF0IHRvbyBtYW55IEJG RCBzZXNzaW9ucyBvciBhdCB0b28gc2hvcnQgaW50ZXJ2YWxzIGJlaW5nICByYW4uIEkgZG9u4oCZ dCBhZ3JlZSB0byBsb2FkaW5nIHRoaXMgYXMgZXh0ZW5zaW9uIG9mIHRoZSB3aWRlbHkgdXNlZCBz dGFuZGFyZC4gUGVyaGFwcyB3ZSBjYW4gbG9vayBpbnRvIHVzaW5nIEJGRCBFY2hvIGFzIHNlbGYt ZGVidWdnaW5nIGluc3RydW1lbnQuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQo= --_000_7347100B5761DC41A166AC17F22DF1121B8AC60Aeusaamb103erics_ 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 N0QiPmlmIFdHIGNoYWlycyBmZWVsIHRoYXQgQkZEIGltcGxlbWVudGF0aW9uIGd1aWRlIHdvdWxk IGJlIGdvb2QgdG8gd3JpdGUgd2UgbWF5IGZpbmQgd2lsbGluZyBjb250cmlidXRvcnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGZvciBncmFudWxhcml0eSBvZiBsb2dnaW5nLCBp bXBsZW1lbnRhdGlvbiBJ4oCZbSBmYW1pbGlhciB3aXRoIGFsbG93cyBkbyB0aGF0IHBlciBCRkQg c2Vzc2lvbiB3aXRob3V0IGNvbnRleHQgc3dpdGNoaW5nLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBTLiBvdXIgZGlzY3Vzc2lvbiBn cmV3IGJleW9uZCB0b2xlcmFuY2UgbGV2ZWwgb2YgbWFpbC1ob3N0LCBzbyBJ4oCZdmUgc25pcHBl ZCBwYXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFuYXYg QmhhdGlhIFttYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCA3OjAyIFBNPGJyPg0KPGI+VG86PC9iPiBHcmVn b3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj4gU2FudG9zaCBQIEs7IE1haGVzaCBKZXRoYW5hbmRh bmk7IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEJGRCBzdGFiaWxp dHkgZm9sbG93LXVwIGZyb20gSUVURi05MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIEdyZWcsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGFtIHN1cmUgdGhlIFdHIHdvdWxkIGFwcHJlY2lhdGUgc3VjaCBhIGxlY3R1cmUgc2lu Y2UgdGhhdCB3b3VsZCBvYnZpYXRlIHRoZSBuZWVkIGZvciBzdWNoIGFuIElELiBBcmUgeW91IHN1 Z2dlc3RpbmcgdGhhdCBpIHR1cm4gb24gbG9nZ2luZyBhbmQgcGFja2V0IHRyYWNpbmcgZm9yICpl YWNoKiBpbmNvbWluZyBCRkQgcGFja2V0IGZvciBhbGwgdGhlIHNlc3Npb25zIHRoYXQgaSBoYXZl PyBUcnlpbmcgZG9pbmcNCiB0aGF0IGZvciAyNSBCRkQgc2Vzc2lvbnMgd2hlcmUgZmV3IGFyZSBy dW5uaW5nIGF0IDUwbXMgYW5kIDEwMG1zIFRYIGludGVydmFscy4gTm93IHRyeWluZyBjb21iaW5n IHRocm91Z2ggdGhlIGxvZ3Mgd2hlbiAxIEJGRCBzZXNzaW9uIGZsYXBzIHRvIHVuZGVyc3RhbmQg d2hlcmUgdGhlIGlzc3VlIHdhcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLCBNYW5hdjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBEZWMgNCwgMjAxNCBhdCAxMDowMyBQTSwgR3Jl Z29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b20iIHRhcmdldD0iX2JsYW5rIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFuYXYsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBob3BlIHlvdSBkb27igJl0IGV4cGVjdCBt ZSB0byBnaXZlIGEgbGVjdHVyZSBvbiBob3cgdG8gZGVzaWduIGFuZCBpbXBsZW1lbnQgZGVidWdh YmxlIGltcGxlbWVudGF0aW9uDQogdXNpbmcgbG9nZ2luZyBhbmQgcGFja2V0IHRyYWNpbmcuPC9z 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 eSwgRGVjZW1iZXIgMDQsIDIwMTQgODoxNiBBTTxicj4NCjxiPlRvOjwvYj4gR3JlZ29yeSBNaXJz a3k8YnI+DQo8Yj5DYzo8L2I+IFNhbnRvc2ggUCBLOyBNYWhlc2ggSmV0aGFuYW5kYW5pOyA8YSBo cmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRnLWJmZEBp ZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQkZEIHN0YWJpbGl0eSBmb2xs b3ctdXAgZnJvbSBJRVRGLTkxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhbSBub3Qgc3VyZSB3aGF0IHRoZSBjb25mdXNp b24gaXMgR3JlZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Bc3N1bWUgaSBoYXZlIGEgQkZEIHNlc3Npb24gdGhhdHMgdXAuIEF0IHNvbWUgcG9pbnQg aW4gdGltZSBpdCBmbGFwcy4gTm93IGkgbmVlZCB0byBrbm93IHdoZXRoZXIgdGhlIGlzc3VlIHdh cyBhdCB0aGUgVFggb3IgdGhlIFJYLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UGxlYXNlIHRlbGwgbWUgaG93IFRXQU1QIGNhbiBoZWxw IG1lIGhlcmUuIEFsc28gdGVsbCBtZSBob3cgd2hhdCB0b29sIGkgY2FuIHVzZSBpZiBpdHMgYSB1 QkZEIHNlc3Npb24gdGhhdCBmbGFwcGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzLCBNYW5hdjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBEZWMgNCwg MjAxNCBhdCA5OjA5IFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdvcnkubWlyc2t5QGVy aWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IaSBTYW50b3NoLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmJ1dCB0 aGF0IGlzIHdoYXQgY2FuIGJlIGNhbGxlZCDigJxmZWF0dXJlIGNyZWVw4oCdLiBCRkQgaXMgY29u dGludWl0eSBjaGVjayBtZWNoYW5pc20gYW5kIGZvciBhY3RpdmUNCiBwZXJmb3JtYW5jZSBtZWFz dXJlbWVudCwgZXZlbiBvY2Nhc2lvbmFsLCB0aGVyZSBhcmUgVFdBTVAgaW4gSVAgYW5kIFJGQyA2 Mzc0LzYzNzUgaW4gTVBMUy9NUExTLVRQLiBJdCBtYXkgYmUgdGVtcHRpbmcgdG8gZXhwYW5kIHNj b3BlIG9mIEJGRCBidXQsIEkgYmVsaWV2ZSwgaXQgaXMgc3VjY2Vzc2Z1bCBleGFjdGx5IGJlY2F1 c2UgaXQgd2FzIHNpbXBsZSwgbGlnaHQtd2VpZ2h0IGFuZCBkZXNpZ25lZCB0byBkbyBleGFjdGx5 IG9uZSB0aGluZyDigJMNCiBjb250aW51aXR5IGNoZWNrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNh bnRvc2ggUCBLIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNhbnRvc2hwa0BqdW5pcGVyLm5ldCIg dGFyZ2V0PSJfYmxhbmsiPnNhbnRvc2hwa0BqdW5pcGVyLm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDc6MDIgQU08YnI+DQo8Yj5Ubzo8L2I+ IEdyZWdvcnkgTWlyc2t5OyBNYWhlc2ggSmV0aGFuYW5kYW5pPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPkNjOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGctYmZk QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogQkZEIHN0YWJpbGl0eSBmb2xs b3ctdXAgZnJvbSBJRVRGLTkxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIEdyZWcsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7IERlYnVnZ2luZyBCRkQgaXMgb25lIG9mIHRoZSB1c2UgY2FzZS4gSSBh bHNvIHdhbnQgdG8gYnJpbmcgdXAgb25lIG9mIHRoZSB1c2UgY2FzZSB0aGF0IEplZmYgc3VnZ2Vz dGVkDQogaW4gaGlzIGVhcmxpZXIgJm5ic3A7bWFpbC4gT3BlcmF0b3IgbWlnaHQgTk9UIHdhbnQg dG8gcnVuIE9BTSB3aGljaCBkb2VzIGxvc3MgYW5kIGRlbGF5IG1lYXN1cmVtZW50IGFsbCB0aGUg dGltZSBkdWUgdG8gaXRzIG92ZXJoZWFkLiBXaXRoIHRoZSBleHRlbnNpb24gdG8gQkZEIChzZXF1 ZW5jZSBudW1iZXIpIHdlIGNhbiBkZXRlY3QgaWYgdGhlcmUgaXMgYW55IGxvc3MgYnV0IEJGRCBz dGlsbCBzdGF5cyB1cC4gVGhpcyBsb3NzIGRldGVjdGlvbiBjYW4NCiBiZSB1c2VkIGFzIGEgdHJp Z2dlciBmb3IgbG9zcyBhbmQgZGVsYXkgbWVhc3VyZW1lbnQuIEVjaG8gY2FuIGJlIHVzZWQgb25s eSBpbiBjYXNlIG9mIHNpbmdsZWhvcCBhbmQgaW4gb25lIGRpcmVjdGlvbiBvbmx5LiAmbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGFua3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TYW50 b3NoIFAgSyAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gUnRnLWJmZCBbPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5HcmVnb3J5IE1pcnNreTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MTIgUE08YnI+DQo8Yj5Ubzo8L2I+IE1haGVzaCBK ZXRoYW5hbmRhbmk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFoZXNoLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPmluZGVlZCwgTFNQIFBpbmcgaXMgcGFydCBvZiBNUExTIE9BTSB0b29sIHNl dCBhcyBCRkQgaXRzZWxmIHRoYXQgaW50ZW5kZWQgdG8gbW9uaXRvciBvcGVyYXRpb25hbA0KIHN0 YXRlIG9mIHRoZSBuZXR3b3JrLCBwYXRoIGNvbnRpbnVpdHkgYmV0d2VlbiB0d28gbm9kZXMuIEFu ZCBMU1AgUGluZywgYXMgcHJpbWFyaWx5IG9uLWRlbWFuZCB0cm91Ymxlc2hvb3RpbmcgdG9vbCwg aGVscHMgbG9jYWxpemUgYW5kLCB0byBjZXJ0YWluIGRlZ3JlZSwgZGlhZ25vc2UgdGhlIHByb2Js ZW0uIEJ1dCB0aGUgdWx0aW1hdGUgZGVidWdnaW5nIGlzIHByb3ByaWV0YXJ5LiBUaGlzIHByb3Bv c2FsLCBpbiBteSB2aWV3LCBoZWxwcyBub3QNCiBtb25pdG9yIGJlaGF2aW9yIG9mIHRoZSBuZXR3 b3JrIGJ1dCBCRkQgaXRzZWxmLCBxdWFsaXR5IG9mIEJGRCBpbXBsZW1lbnRhdGlvbi4gSeKAmW0g bm90IHNheWluZyB0aGF0IGl0IGlzIG5vdCB1c2VmdWwgZm9yIGltcGxlbWVudGVycyBhbmQgb3Bl cmF0b3JzLCBvbmUgY2FuIGZpbmQgdGhhdCB0b28gbWFueSBCRkQgc2Vzc2lvbnMgb3IgYXQgdG9v IHNob3J0IGludGVydmFscyBiZWluZyZuYnNwOyByYW4uIEkgZG9u4oCZdCBhZ3JlZSB0byBsb2Fk aW5nIHRoaXMNCiBhcyBleHRlbnNpb24gb2YgdGhlIHdpZGVseSB1c2VkIHN0YW5kYXJkLiBQZXJo YXBzIHdlIGNhbiBsb29rIGludG8gdXNpbmcgQkZEIEVjaG8gYXMgc2VsZi1kZWJ1Z2dpbmcgaW5z dHJ1bWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg R3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B8AC60Aeusaamb103erics_-- From nobody Fri Dec 5 05:27:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E71A88C6 for ; Thu, 4 Dec 2014 10:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 2DnMSzfSe4ty for ; Thu, 4 Dec 2014 10:39:48 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756A71A1B98 for ; Thu, 4 Dec 2014 10:39:47 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id q107so13160638qgd.35 for ; Thu, 04 Dec 2014 10:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=BsOXsy9f6A2jcw7j+yanMIq3VG3HuhIFpaEWwqoezXQ=; b=O8SYSdEOUu1Z1iGSAhKJi74wFRHCK76PeM1leHO175MV6GyoSjroeeFhWVAtDTA2Iq Zvz6qwUnslaj/F0J3KoCpbOXJlM2/U0pjMcxx0EO5zsNY0gCAtw8z1OvS0TGlnnY9+y0 zjOlLaPu6yp3oWjbE25Y/FpagarYzwgEUhAz5QNYkttYV9ax5DRhNEsdVfVXBWXXoEpg DzcjnXL9EnN+JCD+kDy6yffnWcIYlP/DZADV4Q6MT0I2r7Eosi4M/gahCVl2fcw7AqVh u+11mhAV1hgEhCHW7FVckRIWcr4L5T5i9fVJJtIh8GkbMkZ5N3KwngaN2nQ6OYnDayPY KbLQ== X-Received: by 10.224.96.194 with SMTP id i2mr18924220qan.87.1417718386473; Thu, 04 Dec 2014 10:39:46 -0800 (PST) MIME-Version: 1.0 References: From: Mahesh Jethanandani Date: Thu, 04 Dec 2014 18:39:45 +0000 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 To: "Nobo Akiya (nobo)" , Santosh P K , "MALLIK MUDIGONDA (mmudigon)" , "Vengada Prasad Govindan (venggovi)" , Gregory Mirsky , Marc Binderberger , Manav Bhatia Content-Type: multipart/alternative; boundary=001a11c2c17cd142150509684883 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4CeI2So1bXEpB8l-lOlMjvHzxdE X-Mailman-Approved-At: Fri, 05 Dec 2014 05:27:08 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 18:39:58 -0000 --001a11c2c17cd142150509684883 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu Dec 04 2014 at 6:01:47 AM Nobo Akiya (nobo) wrote: > A quick question to understand where we are. > > > > If we had: > > > > 1. Standardization of Null Authentication (i.e., sequence numbers) > > 2. Implementation of local TX/RX timestamp mechanism described by > Marc below > > > > What are the core requirements which have not been satisfied? > Nobo, if we had ways to collect loss (inline) and delay (offline or inline) information, it will go a long way to address the core requirements that we want to address with this draft. One thing that probably did not come out clearly from the draft was that adding time stamps in the BFD payload was optional. As I suggested in my other e-mail we are open to other ways of collecting time stamp information. Sending it over in the payload is one of the options and allows the receiver to compute, determine and react to delays in a more timely fashion. > > > Thanks! > > > > -Nobo > > > > P.S. No, there is no need to standardize BFD echo contents. > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Santosh > P K > *Sent:* Thursday, December 04, 2014 6:52 AM > *To:* MALLIK MUDIGONDA (mmudigon); Vengada Prasad Govindan (venggovi); > Gregory Mirsky; Marc Binderberger; Manav Bhatia > *Cc:* rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Mallaik, > > That=E2=80=99s correct and that is why I asked if we really need to def= ine any > packet format as Greg suggested? > > > > Thanks > > Santosh P K > > > > *From:* MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com > ] > *Sent:* Thursday, December 04, 2014 5:19 PM > *To:* Santosh P K; Vengada Prasad Govindan (venggovi); Gregory Mirsky; > Marc Binderberger; Manav Bhatia > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Hi Santosh, > > > > With Echo, the receive side is not going to look into the packet. It is > just going to send it back and it is the responsibility of the sender to > interpret its contents. > > > > Regards > > Mallik > > > > *From: *Santosh P K > *Date: *Thursday, 4 December 2014 5:15 pm > *To: *"Vengada Prasad Govindan (venggovi)" , Gregory > Mirsky , Marc Binderberger , > Manav Bhatia > *Cc: *"rtg-bfd@ietf.org" > *Subject: *RE: BFD stability follow-up from IETF-91 > > > > Hi Prasad, > > That's right. We echo has limitations but for single hop we can still > use it. I was trying to understand even for single hop do we need to defi= ne > any packet format for echo? > > > > Thanks > > Santosh P K > > > > -----Original Message----- > > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com > ] > > Sent: Thursday, December 04, 2014 4:45 PM > > To: Gregory Mirsky; Santosh P K; Marc Binderberger; Manav Bhatia > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD stability follow-up from IETF-91 > > Hello Greg/ Santosh, > > It was my understanding that BFD Async was chosen for stability since > there > > are configurations where BFD echo mode is not supported (e.g. Multi-hop, > > BFD on LAGs and BFD over MPLS). Am I missing something here, please let > > me know. > > Thanks > > Prasad > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] > On Behalf Of Gregory > > Mirsky > > Sent: Thursday, December 04, 2014 11:44 AM > > To: Santosh P K; Marc Binderberger; Manav Bhatia > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD stability follow-up from IETF-91 > > Hi Santosh, > > yes, the format and thus interpretation of payload in Echo mode is not > > defined and that, in my view, is what we need - some open space. And Echo > > well could be exactly that - no legacy, no backward compatibility > (addressee > > that doesn't support "extended Echo" will simply loop the packet back to > > sender). Perhaps that will be direction we can discuss and, hopefully, > agree > > on. > > Regards, > > Greg > > -----Original Message----- > > From: Santosh P K [mailto:santoshpk@juniper.net ] > > Sent: Wednesday, December 03, 2014 9:54 PM > > To: Gregory Mirsky; Marc Binderberger; Manav Bhatia > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD stability follow-up from IETF-91 > > Greg, > > I don't think we have discussed about echo in this context. Echo is > good > > thing but payload of BFD echo packet is decided by local system. Did you > > mean to add suggestion on how echo packet should look like? Or how echo > > can help in BFD loss/delay issue? > > Thanks > > Santosh P K > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > ] > > > Sent: Thursday, December 04, 2014 2:22 AM > > > To: Santosh P K; Marc Binderberger; Manav Bhatia > > > Cc: rtg-bfd@ietf.org > > > Subject: RE: BFD stability follow-up from IETF-91 > > > > > > Dear All, > > > had authors of the proposal or we already dismissed use of BFD Echo? > > > I've scanned the thread and couldn't find trace of us discussing BFD > > > Echo mode. I think that it is more suitable for experimentation and > > unorthodox use. > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org > ] On Behalf Of Santosh P > > > K > > > Sent: Wednesday, December 03, 2014 5:39 AM > > > To: Marc Binderberger; Manav Bhatia > > > Cc: rtg-bfd@ietf.org > > > Subject: RE: BFD stability follow-up from IETF-91 > > > > > > Hello Manav and Marc, > > > > > > > > > > > One way to solve this problem is by attaching a debug trailer that > > > > > only carries the seq numbers at the *end* of the BFD packet. This > > > > > would not be covered in the Length field carried in the BFD header > > > > > but would be accounted for in the length carried in the IP header. > > > > > > > > BFD itself is not related to IP, i.e. there is not always an IP heade= r. > > > > Sure, the encapsulating "frame" may provide a length but actually, > > > > why not covering the debug trailer with the BFD length? > > > > > > > > If this is solely for debug purpose than this may work. For simple > > > > copying-out into e.g. a packet trace buffer it would be even simpler > > > > to have the BFD length covering the trailer. > > > > If hardware is supposed to process the trailer information (other > > > > than copying out) then it's getting ugly - having fixed position, > > > > fixed length extension headers would be preferable for simple access. > > > > > > Fixed length would be easy to process in hardware. Problem is when we > > > have many have extensions in future. If we want to use only one > > > extension that is at the last then I will be forced to pad all the > > > other extension ahead of it? This might not be a problem if we have > > > fewer extensions but might become problem when there are too many > > extensions. > > > > > > > > > > > > > > Another idea is to use the 0x80 bit of the auth type to distinguish > > > > between a "normal" authentication header and a "sequence + > > > authentication". > > > > > > > > > > I think this is good. In the BFD extension TLV we still have many > > > reserved bits that can be used as well? > > > > > > Thanks > > > Santosh P K > > > > > > > > > > > > > > > > > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote: > > > > > Hi Santosh, > > > > > > > > > > You could use the crypto sequence numbers carried in the > > > > > meticulous cryptographic auth for detecting packet losses. > > > > > However, this breaks when you use non-meticulous crypto > > > > > authentication since the sequence number is only incremented > > > > > occasionally there. This i believe is a deal breaker since i > > > > > really envision non meticulous mode to be the one being widely > > > > > deployed. In fact we were supposed to write a draft on that and i > > > > > guess it just fell through the cracks (lemme ping my co-author on > > > > > that !) > > > > > > > > > > One way to solve this problem is by attaching a debug trailer that > > > > > only carries the seq numbers at the *end* of the BFD packet. This > > > > > would not be covered in the Length field carried in the BFD header > > > > > but would be accounted for in the length carried in the IP header. > > > > > The concept of attaching a trailer is documented well and is used > > > > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The > > > > > catch however is that this debug trailer will NOT be covered by > > > > > the BFD authentication. Is this acceptable to the WG? > > > > > > > > > > I think the problem of diagnosing a BFD flap becomes all the more > > > > > important with BFD authentication turned on since then we have > > > > > more points where a delay can be inserted. > > > > > > > > > > Cheers, Manav > > > > > > > > > > > > > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > > > > > > > > wrote: > > > > >> Manav, > > > > >> This is good question. > > > > >> > > > > >>> Can the authors add some text on how this debugging mechanism > > > > >>> would work if somebody employs BFD authentication? > > > > >> > > > > >> Right now we have considered without authentication (we are > > > > >> setting A bit). We should add some text on how we can use both > > > > >> Auth and de bug > > > > TLV. > > > > >> Is there any suggestion you have? I will get back to you on this. > > > > >> > > > > >> > > > > >> Thanks > > > > >> Santosh P K > > > > >> > > > > >>>> -----Original Message----- > > > > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org > ] On Behalf Of > > > > >>>> Mach > > > > Chen > > > > >>>> Sent: Thursday, November 27, 2014 2:13 PM > > > > >>>> To: Marc Binderberger > > > > >>>> Cc: rtg-bfd@ietf.org > > > > >>>> Subject: RE: BFD stability follow-up from IETF-91 > > > > >>>> > > > > >>>> Hi Marc, > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Marc Binderberger [mailto:marc@sniff.de ] > > > > >>>>> Sent: Thursday, November 27, 2014 1:43 AM > > > > >>>>> To: Mach Chen > > > > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org > > > > >>>>> Subject: RE: BFD stability follow-up from IETF-91 > > > > >>>>> > > > > >>>>> Hello Mach, > > > > >>>>> > > > > >>>>>> This triggers me think out there should be another solution > > > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > > > >>>>>> timestamps > > > > in > > > > >>>>>> the BFD > > > > >>>>> packets. > > > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > > > >>>>>> locally or send them to a centralized entity and then use the > > > > >>>>>> sequence numbers to correlate them for further analyzing. > > > > >>>>> > > > > >>>>> I remember some discussion on NVO3 about how many bits it > > > > >>>>> takes > > > > >>>>> ;- > > > > ) - > > > > >>>>> could you send the links/draft names you are working on to this > > list? > > > > >>>>> May be useful for further discussions. > > > > >>>> > > > > >>>> Sure, here is the > > > > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > > > >>> based-ipfpm-framework-02) for the reference. > > > > >>>> > > > > >>>> But here I want to say is that since we have sequence number, > > > > >>>> we may > > > > not > > > > >>> need the marking based solution. Suppose that someone want to > > > > monitor > > > > >>> the delay of a BFD packet , just record and save the timestamp > > > > >>> at the Tx side, which indexed by the sequence number. Similarly, > > > > >>> do the same at the Rx side. Then based on the timestamps from > > > > >>> both Tx and Rx, and using the sequence number to correlate the > > > > >>> timestamps, it can also provide a way > > > > to > > > > >>> monitor the delay of the BFD packet. > > > > >>>> > > > > >>>> That means, only if there is sequence number, even if without > > > > >>>> carrying the > > > > >>> timestamp in the BFD packet, BFD packet delay can be measured. > > > > >>>> > > > > >>>> Best regards, > > > > >>>> Mach > > > > >>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> Thanks & Regards, > > > > >>>>> Marc > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > > > >>>>>> Hi Marc and Manav, > > > > >>>>>> > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org > ] On Behalf Of > > > > Marc > > > > >>>>>>> Binderberger > > > > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM > > > > >>>>>>> To: Manav Bhatia > > > > >>>>>>> Cc: rtg-bfd@ietf.org > > > > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 > > > > >>>>>>> > > > > >>>>>>> Hello Manav, > > > > >>>>>>> > > > > >>>>>>>> I believe the work is important and addresses something > > > > >>>>>>>> thats really required (spent too much time debugging why > > > > >>>>>>>> BFD > > > > flapped!). > > > > >>>>>>> > > > > >>>>>>> agree :-) we should keep the discussion alive. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>> side Time stamping would have helped in debugging whether > > > the > > > > >>> BFD > > > > >>>>>>>> packet was sent late, or whether the packet was sent on > > > > >>>>>>>> time and also arrived on time but was delayed when passing > > > > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad > > > > >>>>>>>> too > > > > >>>>>>>> long) > > > > >>>>>>> > > > > >>>>>>> well, I can see a point in having the Tx timestamps in the > > > > >>>>>>> packet mainly for the purpose of knowing "this" packet was > > > > >>>>>>> okay/not okay on the Tx side and to correlate it with your > > > > >>>>>>> local Rx > > > measurement. > > > > >>>>>> > > > > >>>>>> Yes, this is one solution if people think BFD delay is needed. > > > > >>>>>> If allow to have Tx timestamps to be carried in the packets, > > > > >>>>>> seems it should be no problem to leave a seat for the Rx > > > > >>>>>> timestamps as well :-). After all, with both Tx and Rx > > > > >>>>>> timestamp, it may simplify the > > > > >>>>> implementation. > > > > >>>>>> > > > > >>>>>>> > > > > >>>>>>> And even this point is less relevant with sequence numbers > > > > >>>>>>> as this number allows the identification of packets and thus > > > > >>>>>>> the correlation of information from the Tx and Rx system. > > > > >>>>>> > > > > >>>>>> Indeed, the sequence number helps a lot for the correlation > > > > between > > > > >>>>>> the Tx and Rx system. > > > > >>>>>> > > > > >>>>>> This triggers me think out there should be another solution > > > > >>>>>> for getting the Tx and Rx timestamps without encoding the > > > > >>>>>> timestamps > > > > in > > > > >>>>>> the BFD > > > > >>>>> packets. > > > > >>>>>> For example, the Tx and Rx systems could just save timestamps > > > > >>>>>> locally or send them to a centralized entity and then use the > > > > >>>>>> sequence numbers to correlate them for further analyzing. > > > > >>>>>> > > > > >>>>>> Best regards, > > > > >>>>>> Mach > > > > >>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> Regards, Marc > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > > > >>>>>>>> Hi Jeff, > > > > >>>>>>>> > > > > >>>>>>>> I vividly remember the original intent of the stability > > > > >>>>>>>> draft was to help debug BFD failures -- to isolate the > > > > >>>>>>>> issue at the RX or the TX side Time stamping would have > > > > >>>>>>>> helped in debugging > > > > whether > > > > >>>>>>>> the BFD packet was sent late, or whether the packet was > > > > >>>>>>>> sent on time and also arrived on time but was delayed when > > > > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer > > > > >>>>>>>> for tad too long), etc. But then time stamping came with > > > > >>>>>>>> its own set of issues, and was hence dropped from the origin= al > > draft. > > > > >>>>>>>> > > > > >>>>>>>> Can the authors send a summary on the list on why time > > > > >>>>>>>> stamping was dropped so that we're all clear on that one. > > > > >>>>>>>> > > > > >>>>>>>> The current proposal does help but is not complete. > > > > >>>>>>>> > > > > >>>>>>>> Assume that the RX end loses a BFD session and learns later > > > > >>>>>>>> that it did eventually receive the missing BFD packets > > > > >>>>>>>> (based on the > > > > seq > > > > >>> #). > > > > >>>>>>>> How would it know which end was misbehaving? Was it a > > delay > > > > >>>>>>>> at the TX side, or was it the RX that delayed passing the > > > > >>>>>>>> packets to the BFD process(or). This is usually what we > > > > >>>>>>>> want to debug and i want to understand how this draft with > > > > >>>>>>>> sequence numbers can unequivocally tell me that. > > > > >>>>>>>> > > > > >>>>>>>> I believe the work is important and addresses something > > > > >>>>>>>> thats really required (spent too much time debugging why > > > > >>>>>>>> BFD > > > > flapped!). > > > > >>>>>>>> Clearly what would help is putting a small section that > > > > >>>>>>>> describes how we can use the sequence numbers to debug > > > what > > > > >>>>>>>> and > > > > where > > > > >>> things went wrong. > > > > >>>>>>>> > > > > >>>>>>>> Cheers, Manav > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > > > > >>>>>>>> > > > > >>> wrote: > > > > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during > > > > >>>>>>>>> IETF-91 in Honolulu. The slides can be viewed here: > > > > >>>>>>>>> > > > > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. > > > > >>>>>>>>> pp > > > > >>>>>>>>> tx > > > > >>>>>>>>> > > > > >>>>>>>>> To attempt to simplify the presentation, the contentious > > > > >>>>>>>>> portion of the timers were removed from the proposal, > > > > >>>>>>>>> leaving only the sequence numbering for detecting loss of > > > > >>>>>>>>> BFD > > > async packets. > > > > >>>>>>>>> > > > > >>>>>>>>> When the room was polled to see whether the draft should > > > > >>>>>>>>> be adopted as a WG item, the sense of the room was very > > quiet. > > > > >>>>>>>>> As promised, this is to inquire for support for this draft > > > > >>>>>>>>> on the WG mailing list to make sure the whole group has a > > > voice. > > > > >>>>>>>>> > > > > >>>>>>>>> It should be noted that post-meeting discussion on the > > > > >>>>>>>>> fate of this draft noted that BFD authentication code > > > > >>>>>>>>> points are plentiful and are available with expert review. > > > > >>>>>>>>> Should the draft authors wish to continue this work as > > > > >>>>>>>>> Experimental, that is > > > > an > > > > >>> option. > > > > >>>>>>>>> > > > > >>>>>>>>> -- Jeff > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > > > > > --001a11c2c17cd142150509684883 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu Dec 04 2014 at 6:01:47 AM Nobo Ak= iya (nobo) <nobo@cisco.com> wro= te:

A quick question to under= stand where we are.

=C2=A0

If we had:<= /span>

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Standardization of N= ull Authentication (i.e., sequence numbers)

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Implementation of lo= cal TX/RX timestamp mechanism described by Marc below<= /p>

=C2=A0

What are the core require= ments which have not been satisfied?


Nobo, if we had ways to collect loss (inline) and delay (o= ffline or inline) information, it will go a long way to address the core re= quirements that we want to address with this draft.=C2=A0

One thing that probably did not come out clearly from the draft was= that adding time stamps in the BFD payload was optional. As I suggested in= my other e-mail we are open to other ways of collecting time stamp informa= tion. Sending it over in the payload is one of the options and allows the r= eceiver to compute, determine and react to delays in a more timely fashion.=

=

=C2=A0

Thanks!

=C2=A0

-Nobo

=C2=A0

P.S. No, there is no need= to standardize BFD echo contents.

=C2=A0

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Thursday, December 04, 2014 6:52 AM
To: MALLIK MUDIGONDA (mmudigon); Vengada Prasad Govindan (venggovi);= Gregory Mirsky; Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ie= tf.org
Subject: RE: BFD stability follow-up from IETF-91

=C2=A0

Mallaik,

=C2=A0=C2= =A0That=E2=80=99s correct and that is why I asked if we really need to defi= ne any packet format as Greg suggested?

=C2= =A0

Thanks<= /u>

Santosh P = K

=C2= =A0

From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Thursday, December 04, 2014 5:19 PM
To: Santosh P K; Vengada Prasad Govindan (venggovi); Gregory Mirsky;= Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ie= tf.org
Subject: Re: BFD stability follow-up from IETF-91

=C2=A0

Hi Santosh,=

=C2=A0<= u>

With Echo, the= receive side is not going to look into the packet. It is just going to sen= d it back and it is the responsibility of the sender to interpret its contents.=C2=A0

=C2=A0<= u>

Regards=

Mallik<= u>

=C2=A0<= u>

=C2=A0<= u>

Hi Prasad,<= /u>

=C2=A0=C2=A0Th= at's right. We echo has limitations but for single hop we can still use= it. I was trying to understand even for single hop do we need to define any packet format for echo?

=C2=A0<= u>

Thanks<= u>

Santosh P K

=C2=A0<= u>

-----Original = Message-----

From: Vengada = Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]

Sent: Thursday= , December 04, 2014 4:45 PM

To: Gregory Mi= rsky; Santosh P K; Marc Binderberger; Manav Bhatia

Cc: rtg-bfd@ietf.org<= u>

Subject: RE: B= FD stability follow-up from IETF-91

Hello Greg/ Sa= ntosh,

=C2=A0=C2=A0 I= t was my understanding that BFD Async was chosen for stability since there<= u>

are configurat= ions where BFD echo mode is not supported (e.g. Multi-hop,

BFD on LAGs an= d BFD over MPLS). Am I missing something here, please let

me know.

Thanks<= u>

Prasad<= u>

-----Original = Message-----

From: Rtg-bfd = [mailto:rtg-b= fd-bounces@ietf.org] On Behalf Of Gregory

Mirsky<= u>

Sent: Thursday= , December 04, 2014 11:44 AM

To: Santosh P = K; Marc Binderberger; Manav Bhatia

Cc: rtg-bfd@ietf.org<= u>

Subject: RE: B= FD stability follow-up from IETF-91

Hi Santosh,=

yes, the forma= t and thus interpretation of payload in Echo mode is not

defined and th= at, in my view, is what we need - some open space. And Echo

well could be = exactly that - no legacy, no backward compatibility (addressee

that doesn'= ;t support "extended Echo" will simply loop the packet back to=

sender). Perha= ps that will be direction we can discuss and, hopefully, agree

on.<= /u>

Regards,

Greg=

-----Original = Message-----

From: Santosh = P K [mailto:sant= oshpk@juniper.net]

Sent: Wednesda= y, December 03, 2014 9:54 PM

To: Gregory Mi= rsky; Marc Binderberger; Manav Bhatia

Cc: rtg-bfd@ietf.org<= u>

Subject: RE: B= FD stability follow-up from IETF-91

Greg,

=C2=A0=C2=A0= =C2=A0=C2=A0I don't think we have discussed about echo in this context.= Echo is good

thing but payl= oad of BFD echo packet is decided by local system. Did you

mean to add su= ggestion on how echo packet should look like? Or how echo

can help in BF= D loss/delay issue?

Thanks<= u>

Santosh P K=

> -----Orig= inal Message-----

> From: Gre= gory Mirsky [mailto:gregory.mirsky@ericsson.com]

> Sent: Thu= rsday, December 04, 2014 2:22 AM

> To: Santo= sh P K; Marc Binderberger; Manav Bhatia

> Cc: rtg-bfd@ietf.org<= u>

> Subject: = RE: BFD stability follow-up from IETF-91

>=C2= =A0

> Dear All,=

> had autho= rs of the proposal or we already dismissed use of BFD Echo?

> I've = scanned the thread and couldn't find trace of us discussing BFD<= u>

> Echo mode= . I think that it is more suitable for experimentation and

unorthodox use= .

>=C2= =A0

> Regards,<= u>

> Greg

>=C2= =A0

> -----Orig= inal Message-----

> From: Rtg= -bfd [mailto:= rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P

> K<= u>

> Sent: Wed= nesday, December 03, 2014 5:39 AM

> To: Marc = Binderberger; Manav Bhatia

> Cc: rtg-bfd@ietf.org<= u>

> Subject: = RE: BFD stability follow-up from IETF-91

>=C2= =A0

> Hello Man= av and Marc,

>=C2= =A0

>=C2= =A0

> > >= One way to solve this problem is by attaching a debug trailer that<= u>

> > >= only carries the seq numbers at the *end* of the BFD packet. This

> > >= would not be covered in the Length field carried in the BFD header<= u>

> > >= but would be accounted for in the length carried in the IP header.<= u>

> >

> > BFD = itself is not related to IP, i.e. there is not always an IP header.<= u>

> > Sure= , the encapsulating "frame" may provide a length but actually,=

> > why = not covering the debug trailer with the BFD length?

> >

> > If t= his is solely for debug purpose than this may work. For simple

> > copy= ing-out into e.g. a packet trace buffer it would be even simpler<= /u>

> > to h= ave the BFD length covering the trailer.

> > If h= ardware is supposed to process the trailer information (other=

> > than= copying out) then it's getting ugly - having fixed position,=

> > fixe= d length extension headers would be preferable for simple access.=

>=C2= =A0

> Fixed len= gth would be easy to process in hardware. Problem is when we<= /span>

> have many= have extensions in future. If we want to use only one=

> extension= that is at the last then I will be forced to pad all the

> other ext= ension ahead of it? This might not be a problem if we have

> fewer ext= ensions but might become problem when there are too many

extensions.=

>=C2= =A0

>=C2= =A0

> >

> > Anot= her idea is to use the 0x80 bit of the auth type to distinguish

> > betw= een a "normal" authentication header and a "sequence +

> authentic= ation".

> >

>=C2= =A0

> I think t= his is good. In the BFD extension TLV we still have many

> reserved = bits that can be used as well?

>=C2= =A0

> Thanks=

> Santosh P= K

>=C2= =A0

>=C2= =A0

>=C2= =A0

> >

> > On T= hu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote:

> > >= Hi Santosh,

> > >=

> > >= You could use the crypto sequence numbers carried in the

> > >= meticulous cryptographic auth for detecting packet losses.

> > >= However, this breaks when you use non-meticulous crypto

> > >= authentication since the sequence number is only incremented=

> > >= occasionally there. This i believe is a deal breaker since i=

> > >= really envision non meticulous mode to be the one being widely

> > >= deployed. In fact we were supposed to write a draft on that and i

> > >= guess it just fell through the cracks (lemme ping my co-author on

> > >= that !)

> > >=

> > >= One way to solve this problem is by attaching a debug trailer that<= u>

> > >= only carries the seq numbers at the *end* of the BFD packet. This

> > >= would not be covered in the Length field carried in the BFD header<= u>

> > >= but would be accounted for in the length carried in the IP header.<= u>

> > >= The concept of attaching a trailer is documented well and is used

> > >= in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The=

> > >= catch however is that this debug trailer will NOT be covered by<= /u>

> > >= the BFD authentication. Is this acceptable to the WG?=

> > >=

> > >= I think the problem of diagnosing a BFD flap becomes all the more

> > >= important with BFD authentication turned on since then we have

> > >= more points where a delay can be inserted.

> > >=

> > >= Cheers, Manav

> > >=

> > >=

> > >= On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K

> > wrot= e:

> > >= > Manav,

> > >= >=C2=A0=C2=A0=C2=A0=C2=A0 This is good question.

> > >= >

> > >= >> Can the authors add some text on how this debugging mechanism

> > >= >> would work if somebody employs BFD authentication?

> > >= >

> > >= > Right now we have considered without authentication (we are<= /u>

> > >= > setting A bit). We should add some text on how we can use both<= u>

> > >= > Auth and de bug

> > TLV.=

> > >= > Is there any suggestion you have? I will get back to you on this.

> > >= >

> > >= >

> > >= > Thanks

> > >= > Santosh P K

> > >= >

> > >= >>> -----Original Message-----

> > >= >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of<= /u>

> > >= >>> Mach

> > Chen=

> > >= >>> Sent: Thursday, November 27, 2014 2:13 PM=

> > >= >>> To: Marc Binderberger

> > >= >>> Cc: rtg-bfd@ietf.org<= u>

> > >= >>> Subject: RE: BFD stability follow-up from IETF-91

> > >= >>>

> > >= >>> Hi Marc,

> > >= >>>

> > >= >>>> -----Original Message-----

> > >= >>>> From: Marc Binderberger [mailto:marc@sniff.de]

> > >= >>>> Sent: Thursday, November 27, 2014 1:43 AM

> > >= >>>> To: Mach Chen

> > >= >>>> Cc: Manav Bhatia; rtg-bfd@ietf.org<= u>

> > >= >>>> Subject: RE: BFD stability follow-up from IETF-91

> > >= >>>>

> > >= >>>> Hello Mach,

> > >= >>>>

> > >= >>>>> This triggers me think out there should be another sol= ution

> > >= >>>>> for getting the Tx and Rx timestamps without encoding = the

> > >= >>>>> timestamps

> > in

> > >= >>>>> the BFD

> > >= >>>> packets.

> > >= >>>>> For example, the Tx and Rx systems could just save tim= estamps

> > >= >>>>> locally or send them to a centralized entity and then = use the

> > >= >>>>> sequence numbers to correlate them for further analyzi= ng.

> > >= >>>>

> > >= >>>> I remember some discussion on NVO3 about how many bits it<= u>

> > >= >>>> takes

> > >= >>>> ;-

> > ) -<= u>

> > >= >>>> could you send the links/draft names you are working on to= this

list?

> > >= >>>> May be useful for further discussions.

> > >= >>>

> > >= >>> Sure, here is the

> > >= >> based-ipfpm-framework-02) for the reference.<= /p>

> > >= >>>

> > >= >>> But here I want to say is that since we have sequence number,<= u>

> > >= >>> we may

> > not<= u>

> > >= >> need the marking based solution. Suppose that someone want to

> > moni= tor

> > >= >> the delay of a BFD packet , just record and save the timestamp<= /u>

> > >= >> at the Tx side, which indexed by the sequence number. Similarly,

> > >= >> do the same at the Rx side. Then based on the timestamps from

> > >= >> both Tx and Rx, and using the sequence number to correlate the<= /u>

> > >= >> timestamps, it can also provide a way

> > to

> > >= >> monitor the delay of the BFD packet.

> > >= >>>

> > >= >>> That means, only if there is sequence number, even if without<= u>

> > >= >>> carrying the

> > >= >> timestamp in the BFD packet, BFD packet delay can be measured.<= /u>

> > >= >>>

> > >= >>> Best regards,

> > >= >>> Mach

> > >= >>>

> > >= >>>>

> > >= >>>>

> > >= >>>> Thanks & Regards,

> > >= >>>> Marc

> > >= >>>>

> > >= >>>>

> > >= >>>>

> > >= >>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote:

> > >= >>>>> Hi Marc and Manav,

> > >= >>>>>

> > >= >>>>>> -----Original Message-----

> > >= >>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f

> > Marc=

> > >= >>>>>> Binderberger

> > >= >>>>>> Sent: Wednesday, November 26, 2014 4:50 PM<= u>

> > >= >>>>>> To: Manav Bhatia

> > >= >>>>>> Cc: rtg-bfd@ietf.org<= u>

> > >= >>>>>> Subject: Re: BFD stability follow-up from IETF-91<= u>

> > >= >>>>>>

> > >= >>>>>> Hello Manav,

> > >= >>>>>>

> > >= >>>>>>> I believe the work is important and addresses = something

> > >= >>>>>>> thats really required (spent too much time deb= ugging why

> > >= >>>>>>> BFD

> > flap= ped!).

> > >= >>>>>>

> > >= >>>>>> agree :-) we should keep the discussion alive.<= /u>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>> side Time stamping would have helped in debugg= ing whether

> the

> > >= >> BFD

> > >= >>>>>>> packet was sent late, or whether the packet wa= s sent on

> > >= >>>>>>> time and also arrived on time but was delayed = when passing

> > >= >>>>>>> it up the BFD stack/processor (lay in the RX b= uffer for tad

> > >= >>>>>>> too

> > >= >>>>>>> long)

> > >= >>>>>>

> > >= >>>>>> well, I can see a point in having the Tx timestamp= s in the

> > >= >>>>>> packet mainly for the purpose of knowing "thi= s" packet was

> > >= >>>>>> okay/not okay on the Tx side and to correlate it w= ith your

> > >= >>>>>> local Rx

> measureme= nt.

> > >= >>>>>

> > >= >>>>> Yes, this is one solution if people think BFD delay is= needed.

> > >= >>>>> If allow to have Tx timestamps to be carried in the pa= ckets,

> > >= >>>>> seems it should be no problem to leave a seat for the = Rx

> > >= >>>>> timestamps as well :-). After all, with both Tx and Rx=

> > >= >>>>> timestamp, it may simplify the

> > >= >>>> implementation.

> > >= >>>>>

> > >= >>>>>>

> > >= >>>>>> And even this point is less relevant with sequence= numbers

> > >= >>>>>> as this number allows the identification of packet= s and thus

> > >= >>>>>> the correlation of information from the Tx and Rx = system.

> > >= >>>>>

> > >= >>>>> Indeed, the sequence number helps a lot for the correl= ation

> > betw= een

> > >= >>>>> the Tx and Rx system.

> > >= >>>>>

> > >= >>>>> This triggers me think out there should be another sol= ution

> > >= >>>>> for getting the Tx and Rx timestamps without encoding = the

> > >= >>>>> timestamps

> > in

> > >= >>>>> the BFD

> > >= >>>> packets.

> > >= >>>>> For example, the Tx and Rx systems could just save tim= estamps

> > >= >>>>> locally or send them to a centralized entity and then = use the

> > >= >>>>> sequence numbers to correlate them for further analyzi= ng.

> > >= >>>>>

> > >= >>>>> Best regards,

> > >= >>>>> Mach

> > >= >>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>> Regards, Marc

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>>

> > >= >>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia w= rote:

> > >= >>>>>>> Hi Jeff,

> > >= >>>>>>>

> > >= >>>>>>> I vividly remember the original intent of the = stability

> > >= >>>>>>> draft was to help debug BFD failures -- to iso= late the

> > >= >>>>>>> issue at the RX or the TX side Time stamping w= ould have

> > >= >>>>>>> helped in debugging

> > whet= her

> > >= >>>>>>> the BFD packet was sent late, or whether the p= acket was

> > >= >>>>>>> sent on time and also arrived on time but was = delayed when

> > >= >>>>>>> passing it up the BFD stack/processor (lay in = the RX buffer

> > >= >>>>>>> for tad too long), etc. But then time stamping= came with

> > >= >>>>>>> its own set of issues, and was hence dropped f= rom the original

draft.<= u>

> > >= >>>>>>>

> > >= >>>>>>> Can the authors send a summary on the list on = why time

> > >= >>>>>>> stamping was dropped so that we're all cle= ar on that one.

> > >= >>>>>>>

> > >= >>>>>>> The current proposal does help but is not comp= lete.

> > >= >>>>>>>

> > >= >>>>>>> Assume that the RX end loses a BFD session and= learns later

> > >= >>>>>>> that it did eventually receive the missing BFD= packets

> > >= >>>>>>> (based on the

> > seq<= u>

> > >= >> #).

> > >= >>>>>>> How would it know which end was misbehaving? W= as it a

delay

> > >= >>>>>>> at the TX side, or was it the RX that delayed = passing the

> > >= >>>>>>> packets to the BFD process(or). This is usuall= y what we

> > >= >>>>>>> want to debug and i want to understand how thi= s draft with

> > >= >>>>>>> sequence numbers can unequivocally tell me tha= t.

> > >= >>>>>>>

> > >= >>>>>>> I believe the work is important and addresses = something

> > >= >>>>>>> thats really required (spent too much time deb= ugging why

> > >= >>>>>>> BFD

> > flap= ped!).

> > >= >>>>>>> Clearly what would help is putting a small sec= tion that

> > >= >>>>>>> describes how we can use the sequence numbers = to debug

> what

> > >= >>>>>>> and

> > wher= e

> > >= >> things went wrong.

> > >= >>>>>>>

> > >= >>>>>>> Cheers, Manav

> > >= >>>>>>>

> > >= >>>>>>>

> > >= >>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas<= u>

> > >= >>>>>>> <jhaas@pfrc.org>

> > >= >> wrote:

> > >= >>>>>>>> draft-ashesh-bfd-stability-01 was presente= d again during

> > >= >>>>>>>> IETF-91 in Honolulu.=C2=A0=C2=A0The slides= can be viewed here:

> > >= >>>>>>>>

> > >= >>>>>>>> pp

> > >= >>>>>>>> tx

> > >= >>>>>>>>

> > >= >>>>>>>> To attempt to simplify the presentation, t= he contentious

> > >= >>>>>>>> portion of the timers were removed from th= e proposal,

> > >= >>>>>>>> leaving only the sequence numbering for de= tecting loss of

> > >= >>>>>>>> BFD

> async pac= kets.

> > >= >>>>>>>>

> > >= >>>>>>>> When the room was polled to see whether th= e draft should

> > >= >>>>>>>> be adopted as a WG item, the sense of the = room was very

quiet.<= u>

> > >= >>>>>>>> As promised, this is to inquire for suppor= t for this draft

> > >= >>>>>>>> on the WG mailing list to make sure the wh= ole group has a

> voice.=

> > >= >>>>>>>>

> > >= >>>>>>>> It should be noted that post-meeting discu= ssion on the

> > >= >>>>>>>> fate of this draft noted that BFD authenti= cation code

> > >= >>>>>>>> points are plentiful and are available wit= h expert review.

> > >= >>>>>>>> Should the draft authors wish to continue = this work as

> > >= >>>>>>>> Experimental, that is=

> > an

> > >= >> option.

> > >= >>>>>>>>

> > >= >>>>>>>> -- Jeff

> > >= >>>>>>>>

> > >= >>>>>>>

> > >= >>>>>

> > >= >>>

> > >= >

> > >=

=C2=A0<= u>

=C2=A0<= u>

--001a11c2c17cd142150509684883-- From nobody Fri Dec 5 05:27:12 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F891A8824 for ; Thu, 4 Dec 2014 19:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 fYNylXx6kggK for ; Thu, 4 Dec 2014 19:01:34 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFC11A6F8C for ; Thu, 4 Dec 2014 19:01:34 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id wo20so7149418obc.27 for ; Thu, 04 Dec 2014 19:01:33 -0800 (PST) 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:content-type; bh=xFpyXgDFbXhicJqsimJmLEcQHIa5H7EzZmF6VXTSokc=; b=vlOefp2x7i93J3nsmwc8f2RgIOHEpVAuzh+u4Mnz0W0E7YKDLtPtCi0FqHduTJtO4p 7PbDjuDc0CGGCQtK7FCe2l25pHtVoyZwnCjuNqtEvKItoeC3Py3ECZTHCFh09+mBmiO8 IjxegIJdV12dxd6bQUX/lYTuZYFBwQU7xpnhZf1PEdyMysIvSJWVgqjxeendeVc3EFmX mMn55eZjBYwJ5jtzO9i5eeO3NHUV3N5KDoebv1nGouHISTuCNzQ5ZUwqEKx8C8KV91Oc UIBQELSzmURpDrumVDKLM+SbY5QQCDw5rO2hKR9DKfJFD/TzZDkTgi3tzoRiRax+Kyb3 6tDQ== MIME-Version: 1.0 X-Received: by 10.60.133.141 with SMTP id pc13mr9222733oeb.68.1417748493355; Thu, 04 Dec 2014 19:01:33 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 4 Dec 2014 19:01:33 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> Date: Fri, 5 Dec 2014 08:31:33 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=047d7b47291253cfbd05096f4b13 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gV60amOYjdD8S0ZWFYGSHurkA0Y X-Mailman-Approved-At: Fri, 05 Dec 2014 05:27:08 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 03:01:38 -0000 --047d7b47291253cfbd05096f4b13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, I am sure the WG would appreciate such a lecture since that would obviate the need for such an ID. Are you suggesting that i turn on logging and packet tracing for *each* incoming BFD packet for all the sessions that i have? Trying doing that for 25 BFD sessions where few are running at 50ms and 100ms TX intervals. Now trying combing through the logs when 1 BFD session flaps to understand where the issue was. Cheers, Manav On Thu, Dec 4, 2014 at 10:03 PM, Gregory Mirsky wrote: > Hi Manav, > > I hope you don=E2=80=99t expect me to give a lecture on how to design and > implement debugable implementation using logging and packet tracing. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Thursday, December 04, 2014 8:16 AM > *To:* Gregory Mirsky > *Cc:* Santosh P K; Mahesh Jethanandani; rtg-bfd@ietf.org > > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > I am not sure what the confusion is Greg. > > > > Assume i have a BFD session thats up. At some point in time it flaps. Now > i need to know whether the issue was at the TX or the RX. > > > > Please tell me how TWAMP can help me here. Also tell me how what tool i > can use if its a uBFD session that flapped. > > > > Cheers, Manav > > > > On Thu, Dec 4, 2014 at 9:09 PM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > > Hi Santosh, > > but that is what can be called =E2=80=9Cfeature creep=E2=80=9D. BFD is co= ntinuity check > mechanism and for active performance measurement, even occasional, there > are TWAMP in IP and RFC 6374/6375 in MPLS/MPLS-TP. It may be tempting to > expand scope of BFD but, I believe, it is successful exactly because it w= as > simple, light-weight and designed to do exactly one thing =E2=80=93 conti= nuity > check. > > > > Regards, > > Greg > > > > *From:* Santosh P K [mailto:santoshpk@juniper.net] > *Sent:* Thursday, December 04, 2014 7:02 AM > *To:* Gregory Mirsky; Mahesh Jethanandani > > > *Cc:* rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hello Greg, > > Debugging BFD is one of the use case. I also want to bring up one of th= e > use case that Jeff suggested in his earlier mail. Operator might NOT wan= t > to run OAM which does loss and delay measurement all the time due to its > overhead. With the extension to BFD (sequence number) we can detect if > there is any loss but BFD still stays up. This loss detection can be used > as a trigger for loss and delay measurement. Echo can be used only in cas= e > of singlehop and in one direction only. > > > > Thanks > > Santosh P K > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org > ] *On Behalf Of *Gregory Mirsky > *Sent:* Thursday, December 04, 2014 12:12 PM > *To:* Mahesh Jethanandani > *Cc:* rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hi Mahesh, > > indeed, LSP Ping is part of MPLS OAM tool set as BFD itself that intended > to monitor operational state of the network, path continuity between two > nodes. And LSP Ping, as primarily on-demand troubleshooting tool, helps > localize and, to certain degree, diagnose the problem. But the ultimate > debugging is proprietary. This proposal, in my view, helps not monitor > behavior of the network but BFD itself, quality of BFD implementation. I= =E2=80=99m > not saying that it is not useful for implementers and operators, one can > find that too many BFD sessions or at too short intervals being ran. I > don=E2=80=99t agree to loading this as extension of the widely used stand= ard. > Perhaps we can look into using BFD Echo as self-debugging instrument. > > > > Regards, > > Greg > > > > *From:* Mahesh Jethanandani [mailto:mjethanandani@gmail.com > ] > *Sent:* Wednesday, December 03, 2014 10:23 PM > *To:* Gregory Mirsky > *Cc:* Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Greg, > > > > I believe we have a disagreement here. I do not believe that issue of > debug ability are outside the scope of a standardized protocol. > > > > Look at MPLS ping and traceroute (RFC 4379) . They are ultimately debug > tools used to establish viability of a path and they are very much part o= f > the standardized protocol. > > > > On Dec 3, 2014, at 3:25 PM, Gregory Mirsky > wrote: > > > > Hi Mahesh, > > I consider issues of debugability, not of just BFD but any other > standardized protocol, to be outside of Standard track, at most to be > suitable for Informational or Experimental track. If we agree on that, th= en > we can discuss scenarios that present problem and investigate whether > anything in the protocol requires clarification to help vendors in buildi= ng > well-performing, scalable and interoperable implementations and provide > operational guidelines for operators. > > > > Regards, > > Greg > > > > *From:* Mahesh Jethanandani [mailto:mjethanandani@gmail.com > ] > *Sent:* Tuesday, December 02, 2014 8:46 PM > *To:* Gregory Mirsky > *Cc:* Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Greg, > > > > What is Peng referring to is a way to figure out why a particular BFD > session flapped, particularly if the packet(s) for that session arrive > late. I do not see how that can be performance measurement. It is basic B= FD > debug ability. Running a separate DM does tell you why a particular BFD > session flapped. > > > > Now we can debate what methods can be employed to measure that delay and = I > am open to ways to doing it, including local loopback to measure transmit > delays or time stamping of packets in hardware. But in cases, where there > is no support for either of the capabilities, one of the suggested > solutions is to use the time stamps carried in the BFD payload. > > > > Cheers. > > > > On Dec 1, 2014, at 9:38 AM, Gregory Mirsky > wrote: > > > > Hi Peng, > > and still, you=E2=80=99re looking for a tool to measure BFD performance. = Then > you=E2=80=99ll be looking for a tool to verify the BFD performance measur= ement, and > on, and on. Operators do need complete set of FCAPS tools, including > performance measurement. Note that passive performance measurement throug= h > marking method that Mach Chen referred to can monitor BFD flow(s) and be > used to do Loss and/or Delay Measurement. And active Synthetic Loss > Measurement may simulate flow of small packets as well as relatively larg= e > packets. And the same goes for active measurement method of Delay > Measurement. I like Swiss Army knives but let us not turn BFD into one. > > > > Regards, > > Greg > > > > *From:* Fan, Peng [mailto:fanpeng@chinamobile.com > ] > *Sent:* Monday, December 01, 2014 4:44 AM > *To:* Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hi Gregory, > > > > I was just giving an example :) Application traffic usually cannot stand > small packet loss, not to say 30% loss. > > > > I am actually asking for a debug function that could give us some useful > hints of poor connection with small protocol change, besides the basic > connectivity information. If it measures something, it measures packets o= f > BFD itself. So I don=E2=80=99t expect it to be considered as a performanc= e > measurement tool. > > > > Best regards, > > Peng > > > > *From:* Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > ] > *Sent:* Saturday, November 29, 2014 3:37 AM > *To:* Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hi Peng, > > this is very interesting scenario. I think that if BFD experiences ~30% > packet loss, then highly likely so are affected other applications. Then = it > is not just BFD issue but condition that should be detected by performan= ce > measurement method, whether active or passive packet loss measurement. > > I=E2=80=99m convinced that overloading BFD with performance measurement p= rovisions > is counter-productive and is inappropriate. > > > > Regards, > > Greg > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org > ] *On Behalf Of *Fan, Peng > *Sent:* Friday, November 28, 2014 4:34 AM > *To:* 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hi Mallik, > > > > Exactly. Packets may be experiencing slight loss, but the link can hardly > be regarded as connected. More importantly, the experience of upper-level > applications can be degraded severely (e.g. TCP traffic is not able to go > fast in face of even small continuous loss). But what if one BFD frame is > lost every three frames? Then the loss rate is 30% on average, which is > already a very severe value. > > > > Best regards, > > Peng > > > > *From:* MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com > ] > *Sent:* Friday, November 28, 2014 7:53 PM > *To:* Fan, Peng; rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Hi Peng, > > > > If the BFD packets are lost, doesn=E2=80=99t the BFD session go DOWN? Are= you > saying that packet loss is not big enough to make BFD session go DOWN? > > > > Thanks > > > > Regards > > Mallik > > > > *From: *, Peng > *Date: *Friday, 28 November 2014 4:20 pm > *To: *"rtg-bfd@ietf.org" > *Subject: *RE: BFD stability follow-up from IETF-91 > > > > Hi Jeff, all, > > > > I have been following this stability extension from the beginning, and as > an > > operator I would like to express that this draft enables the "advanced > > feature" we desire for BFD to provide additional useful information that > > helps operators understand network issues. A relevant use case is detecti= ng > > lossy or "quasi-disconnected" links or member LAG links. An example of su= ch > > situation we experienced was a loosely connected fiber link resulting in > > continuous, small amount of packet loss. BFD could get the information of > > lost BFD frames on such unstable link, and probably report when a target > > level is reached, say a certain number of frames are lost over a period o= r > > among a total number of frames. > > > > Best regards, > > Peng > > > > Mahesh Jethanandani > > Co-chair, NETCONF WG > > mjethanandani@gmail.com > > > > Mahesh Jethanandani > > Co-chair, NETCONF WG > > mjethanandani@gmail.com > > > > > > > > > --047d7b47291253cfbd05096f4b13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

I am sure the WG would appreci= ate such a lecture since that would obviate the need for such an ID. Are yo= u suggesting that i turn on logging and packet tracing for *each* incoming = BFD packet for all the sessions that i have? Trying doing that for 25 BFD s= essions where few are running at 50ms and 100ms TX intervals. Now trying co= mbing through the logs when 1 BFD session flaps to understand where the iss= ue was.

Cheers, Manav

On Thu, Dec 4, 2014 at 10:03 PM, Gregory= Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

I hope you don=E2=80=99t = expect me to give a lecture on how to design and implement debugable implem= entation using logging and packet tracing.

=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, December 04, 2014 8:16 AM
To: Gregory Mirsky
Cc: Santosh P K; Mahesh Jethanandani; rtg-bfd@ietf.org


Subject: Re: BFD stability follow-up from IETF-91

=C2=A0

I am not sure what the confusion is Greg.<= /u>

=C2=A0

Assume i have a BFD session thats up. At some point = in time it flaps. Now i need to know whether the issue was at the TX or the= RX.

=C2=A0

Please tell me how TWAMP can help me here. Also tell= me how what tool i can use if its a uBFD session that flapped.

=C2=A0

Cheers, Manav

=C2=A0

On Thu, Dec 4, 2014 at 9:09 PM, Gregory Mirsky <<= a href=3D"mailto:gregory.mirsky@ericsson.com" target=3D"_blank">gregory.mir= sky@ericsson.com> wrote:

Hi Santosh,=

but that is what can be c= alled =E2=80=9Cfeature creep=E2=80=9D. BFD is continuity check mechanism an= d for active performance measurement, even occasional, there are TWAMP in IP and RFC 63= 74/6375 in MPLS/MPLS-TP. It may be tempting to expand scope of BFD but, I b= elieve, it is successful exactly because it was simple, light-weight and de= signed to do exactly one thing =E2=80=93 continuity check.

=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: Santosh = P K [mailto:sant= oshpk@juniper.net]
Sent: Thursday, December 04, 2014 7:02 AM
To: Gregory Mirsky; Mahesh Jethanandani


Cc: rtg-bfd@ie= tf.org
Subject: RE: BFD stability follow-up from IETF-91

=C2=A0

Hello Greg,=

=C2=A0 Debugging BFD is o= ne of the use case. I also want to bring up one of the use case that Jeff s= uggested in his earlier =C2=A0mail. Operator might NOT want to run OAM which does l= oss and delay measurement all the time due to its overhead. With the extens= ion to BFD (sequence number) we can detect if there is any loss but BFD sti= ll stays up. This loss detection can be used as a trigger for loss and delay measurement. Echo can be used only= in case of singlehop and in one direction only. =C2=A0

=C2=A0

Thanks

Santosh P K =C2=A0=

=C2=A0

From: Rtg-bf= d [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, December 04, 2014 12:12 PM
To: Mahesh Jethanandani
Cc: rtg-bfd@ie= tf.org
Subject: RE: BFD stability follow-up from IETF-91

=C2=A0

Hi Mahesh,<= u>

indeed, LSP Ping is part = of MPLS OAM tool set as BFD itself that intended to monitor operational state of the network, path continuity between two nodes. And LSP Ping, as = primarily on-demand troubleshooting tool, helps localize and, to certain de= gree, diagnose the problem. But the ultimate debugging is proprietary. This= proposal, in my view, helps not monitor behavior of the network but BFD itself, quality of BFD implementat= ion. I=E2=80=99m not saying that it is not useful for implementers and oper= ators, one can find that too many BFD sessions or at too short intervals be= ing=C2=A0 ran. I don=E2=80=99t agree to loading this as extension of the widely used standard. Perhaps we can look into using B= FD Echo as self-debugging instrument.

=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: Mahesh J= ethanandani [m= ailto:mjethanandani@gmail.com]
Sent: Wednesday, December 03, 2014 10:23 PM
To: Gregory Mirsky
Cc: Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91

=C2=A0

Greg,

=C2=A0

I believe we have a disagreement here. I do not beli= eve that issue of debug ability are outside the scope of a standardized pro= tocol.

=C2=A0

Look at MPLS ping and traceroute (RFC 4379) . They a= re ultimately debug tools used to establish viability of a path and they ar= e very much part of the standardized protocol.

=C2=A0

On Dec 3, 2014, at 3:25 PM, Gregory Mirsky <gregory.mirsky@= ericsson.com> wrote:

=C2=A0

Hi Mahesh,<= u>

I consider issues of debu= gability, not of just BFD but any other standardized protocol, to be outsid= e of Standard track, at most to be suitable for Informational or Experimenta= l track. If we agree on that, then we can discuss scenarios that present pr= oblem and investigate whether anything in the protocol requires clarificati= on to help vendors in building well-performing, scalable and interoperable implementations and provide operational guideli= nes for operators.

=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:=C2=A0Mah= esh Jethanandani [mailto:mjethanandani@gmail.com]=C2=A0
Sent:=C2=A0Tuesday, December 02, 2014 8:46 PM
To:=C2=A0Gregory Mirsky
Cc:=C2=A0Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org
Subject:=C2=A0Re: BFD stability follow-up from IETF-91=

=C2=A0

Greg,

=C2=A0

What is Peng referring to is a way to figure out why= a particular BFD session flapped, particularly if the packet(s) for that s= ession arrive late. I do not see how that can be performance measurement. It is basic BFD debug ability. Running a separate DM does tel= l you why a particular BFD session flapped.

=C2=A0

Now we can debate what methods can be employed to me= asure that delay and I am open to ways to doing it, including local loopbac= k to measure transmit delays or time stamping of packets in hardware. But in cases, where there is no support for either of the cap= abilities, one of the suggested solutions is to use the time stamps carried= in the BFD payload.=C2=A0

=C2=A0

Cheers.

=C2=A0

On Dec 1, 2014, at 9:38 AM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

=C2=A0

Hi Peng,=

and still, you=E2=80=99re= looking for a tool to measure BFD performance. Then you=E2=80=99ll be look= ing for a tool to verify the BFD performance measurement, and on, and on. Operators do ne= ed complete set of FCAPS tools, including performance measurement. Note tha= t passive performance measurement through marking method that Mach Chen ref= erred to can monitor BFD flow(s) and be used to do Loss and/or Delay Measurement. And active Synthetic Loss= Measurement may simulate flow of small packets as well as relatively large= packets. And the same goes for active measurement method of Delay Measurem= ent. I like Swiss Army knives but let us not turn BFD into one.

=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:=C2=A0Fan= , Peng [mailto:fanpeng@chinamobile.com]=C2=A0
Sent:=C2=A0Monday, December 01, 2014 4:44 AM
To:=C2=A0Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigon)';=C2= =A0rtg-bfd@ietf.org
Subject:=C2=A0RE: BFD stability follow-up from IETF-91=

=C2=A0

Hi Gregory,=

=C2=A0

I was just giving an exam= ple :) Application traffic usually cannot stand small packet loss, not to say 30% loss.

=C2=A0

I am actually asking for = a debug function that could give us some useful hints of poor connection with small protocol change, besides the basic connectivity information. If= it measures something, it measures packets of BFD itself. So I don=E2=80= =99t expect it to be considered as a performance measurement tool.

=C2=A0

Best regards,

Peng=

=C2=A0

=C2=A0

Hi Peng,=

this is very interesting = scenario. I think that if BFD experiences ~30% packet loss, then highly likely so are affected other applications. Then it is not just BFD issue b= ut condition that should be detected=C2=A0 by performance measurement metho= d, whether active or passive packet loss measurement.<= /p>

I=E2=80=99m convinced tha= t overloading BFD with performance measurement provisions is counter-produc= tive and is inappropriate.

=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:=C2=A0Rtg= -bfd [mailto:rtg-bfd-bounces@ietf.org]=C2=A0O= n Behalf Of=C2=A0Fan, Peng
Sent:=C2=A0Friday, November 28, 2014 4:34 AM
To:=C2=A0'MALLIK MUDIGONDA (mmudigon)';=C2=A0rtg-bfd= @ietf.org
Subject:=C2=A0RE: BFD stability follow-up from IETF-91=

=C2=A0

Hi Mallik,<= u>

=C2=A0

Exactly. Packets may be e= xperiencing slight loss, but the link can hardly be regarded as connected. More importantly, the experience of upper-level applications can be degrad= ed severely (e.g. TCP traffic is not able to go fast in face of even small = continuous loss). But what if one BFD frame is lost every three frames? The= n the loss rate is 30% on average, which is already a very severe value.

=C2=A0

Best regards,

Peng=

=C2=A0

From:=C2=A0MAL= LIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]=C2=A0
Sent:=C2=A0Friday, November 28, 2014 7:53 PM
To:=C2=A0Fan, Peng;=C2=A0rtg-bfd@ietf.org
Subject:=C2=A0Re: BFD stability follow-up from IETF-91=

=C2=A0

Hi Peng,

=C2=A0

If the BFD packets are lost, doesn=E2=80= =99t the BFD session go DOWN? Are you saying that packet loss is not big en= ough to make BFD session go DOWN?

=C2=A0

Thanks

=C2=A0

Regards

Mallik

=C2=A0

From:=C2=A0&= lt;Fan>, Peng <fanpeng@chinamobile.com><= br> Date:=C2=A0Friday, 28 November 2014 4:20 pm
To:=C2=A0"rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject:=C2=A0RE: BFD stability follow-up from IETF-91=

=C2=A0

Hi Jeff, all,

=C2=A0

I have been following this stability exte= nsion from the beginning, and as an

operator I would like to express that thi= s draft enables the "advanced

feature" we desire for BFD to provid= e additional useful information that

helps operators understand network issues= . A relevant use case is detecting

lossy or "quasi-disconnected" l= inks or member LAG links. An example of such

situation we experienced was a loosely co= nnected fiber link resulting in

continuous, small amount of packet loss. = BFD could get the information of

lost BFD frames on such unstable link, an= d probably report when a target

level is reached, say a certain number of= frames are lost over a period or

among a total number of frames.=

=C2=A0

Best regards,

Peng

=C2=A0

Mahesh Jethanandani

Co-chair, NETCONF WG

=C2=A0

Mahesh Jethanandani

Co-chair, NETCONF WG

=C2=A0<= /u>

=C2=A0<= /p>

=C2=A0

=C2=A0


--047d7b47291253cfbd05096f4b13-- From nobody Sun Dec 7 18:46:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135D11A1B48 for ; Sun, 7 Dec 2014 18:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.939 X-Spam-Level: X-Spam-Status: No, score=0.939 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_54=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 FDkIDWHoEmyk for ; Sun, 7 Dec 2014 18:46:28 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 036841A1A7D for ; Sun, 7 Dec 2014 18:46:28 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4B31B2AA0F; Mon, 8 Dec 2014 02:46:24 +0000 (GMT) Date: Sun, 7 Dec 2014 18:50:09 -0800 From: Marc Binderberger To: Vengada Prasad Govindan (venggovi) Message-ID: <20141207185009007978.f25ecf44@sniff.de> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D3476ED27@xmb-rcd-x15.cisco.com> References: <20141126005002.GL20330@pfrc> <20141125234256188865.aafe8a3f@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1A4@xmb-rcd-x15.cisco.com> <20141201001120931824.3c66eb2f@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476ED27@xmb-rcd-x15.cisco.com> Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PX2nojJUEJl5MQjPKapk8PpaGsQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 02:46:31 -0000 Hello Prasad, sorry for my late reply. > Sorry for pressing the send button early, please find a few replies > inline with GVP1> :-) > Anyway, the procedure you describe in section 2.1 seems okay to me, > although you create a new question: > > [...] Since the BFD local discriminator of > either ends cannot change as long as the session is in the UP > state, a new discriminator received in the LSP ping unambiguously > conveys the intent of the LSR ingress to bootstrap a new BFD > session for the FEC specified in the LSP ping. > > so how do I interpret a new discriminator when one of the other, already > existing sessions, is in Down state? My assumption is you want _always_ > the interpretation above? > GVP1> Agreed, the behavior need not be influenced by the state of the > existing BFD session(s). Ok. > The text in this section has scope for > improvement. The egress node needs some freedom in accepting new session > requests. It could apply policy to limit resources (e.g. pps budget, memory > etc) being allocated to new session request. While the notion of applying > the policy could be a local matter, the behavior of the egress LSR needs to > defined for cases where the new discriminator request is not accepted. > Could it simply drop the LSP Echo request until it is ready to create the > BFD session? (I assume that the ingress LSR will continue re-transmission > of the LSP ping for the new session until it becomes successful or give-up > creating the BFD session after a given number of retries). Comments are > welcome about this aspect. I would be explicit and say that LSP ping must be send periodically when the state is not Up. Section 6.1 of 5884 seems to indicate this but if there is an agreement among implementors I would say so clearly. In that case section 6 On receipt of the LSP Ping Echo request message, the egress LSR MUST send a BFD Control packet to the ingress LSR, if the validation of the FEC in the LSP Ping Echo request message succeeds. can be updated to allow for the behaviour you describe. i.e. not sending a BFD packet if resources running low; I assume that is what implementations do anyway today? > GVP1> I do not know if this draft is required to establish the need for > multiple sessions per since the base RFC5884 already saw the > need for multiple sessions for the . But, I will try and find > references as you suggest. As I said I disagree with the interpretation that 5884 talks about multiple sessions per . But that's not my point here: you shortly mention SR and ECMP but without a bit more details or references I found this not very helpful, actually. And while no draft is required to establish a reason for it's existence it's usually done ;-) > GVP> The intent here is to conserve resources by maintaining the optimal > number of BFD sessions. Sessions that have transitioned from UP->DOWN and > remained in DOWN are candidates for removal. Sessions that have always > remained DOWN for a long enough time are also candidates for removal. > However the latter is currently an open item (please see Sec 2.3, Ed Note). okay, can you shed some light on the Ed Note? What is the problem with sessions that haven't been Up? As you say yourself, if they are long enough Down they are also candidates for removal. > The BFD session on the egress LSR MAY be gracefully removed by the > ingress LSR by using the BFD diagnostic code AdminDown(7) > specified in [RFC5880]. When the ingress LSR wants to gracefully > remove a session, it MAY transmit BFD packets containing the > diagnostic code AdminDown(7) detectMultiplier number of times. > Upon receiving such a packet, the egress LSR MAY remove the BFD > session gracefully, without triggering a change of state. > > Do you mean sending packets with state AdminDown and diagnostic code 7 or > do you mean literally that the diagnostic code controls the removal alone, > e.g. > send detectMultiplier Up packets with diagnostic code 7 and the egress LSR > still removes the session? > GVP1> We do not intend to redefine states or diagnostic codes specified in > RFC 5880. Good ;-) > The draft proposes a method of gracefully removing the BFD > sessions at the egress (from the LSR ingress) by sending packets with diag > code 7, State=Down. Wasn't obvious to me you talk about state=Down. Actually, I would have expected a state of AdminDown for a graceful shutdown (RFC5882, section 3.2) > If you think this text needs clarification or do not > agree with the proposal, please let me know. I would expect more details, like the state you expect to be sent. And I would have thought of AdminDown, not Down. A nitpick but as we discuss this: "the egress LSR MAY remove the BFD session gracefully" I guess you want the say the LSR MAY remove the BFD session and that such a removal should be done gracefully? The "may" is about the removal, not the gracefullness? Thanks & Regards, Marc > On Thu, 27 Nov 2014 12:54:53 +0000, Vengada Prasad Govindan (venggovi) > wrote: >> Hello Marc, >> Thank you for the note, please see replies inline marked with GVP1>. I >> would be happy to discuss further comments you may have regarding the >> draft. >> Thanks >> Prasad >> >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >> Binderberger >> Sent: Wednesday, November 26, 2014 1:13 PM >> To: Jeffrey Haas >> Cc: rtg-bfd@ietf.org >> Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications >> (ends >> December 12, 2014) >> >> Hello Jeff et al., >> >> hmm. I'm not against the adoption of this draft as a workgroup draft but - >> and I hope I don't step on anybodies toes - the draft seems to be in an >> early stage. Nor can I see much of a discussion on this list about the >> topic. >> >> There are for sure some interesting aspects. If enough people consider the >> BFD session removal as relevant for RFC5884 then we have a good reason as >> a >> workgroup to move on. >> GVP1> The issue of BFD session removal at the egress is one of the issues >> that the draft attempts to clarify. But more importantly clarifying the >> mechanisms for establishing and maintaining multiple sessions per > LSP> is the main motivation. Please see next point as well. >> >> I have my doubts about the multiple session per as I don't see >> how you tackle ECMP without multiple . In other words while section >> 2.1 may be a correct procedure for multiple BFD sessions I wonder what >> problem you try to solve? Maybe this needs more discussion. >> GVP1> There are no new problems that this draft attempts to solve. In >> particular, no claim is made to solve the problem of connectivity/ fault >> monitoring for ECMP paths. However, the draft provides clarifies the >> mechanisms to establish multiple sessions for the already >> specified in RFC5884. Some implementations assumed the presence of only >> one >> session per partly due to the notion that discriminators cannot >> be changed after a session was established. This draft was an attempt at >> clarifying these (mis)understandings. Please note that the concept of >> establishing multiple sessions to (possibly) track non-congruent paths was >> outlined in RFC5884 itself. >> ---snip from RFC5884--- >> If there are multiple alternate paths from an ingress LSR to an >> egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to >> determine each of these alternate paths. A BFD session SHOULD be >> established for each alternate path that is discovered. >> ---snip from RFC5884--- >> >> Long story short: while I can see this draft becoming a workgroup draft I >> find the poll - well - premature. >> >> >> Regards, Marc >> >> >> >> >> On Tue, 25 Nov 2014 19:50:02 -0500, Jeffrey Haas wrote: >>> Working Group, >>> >>> Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was >>> presented at IETF-91 in Honolulu and was positively received. We'd like >>> to >>> ask the Working Group whether we should formally adopt this draft as a >>> Working Group item. >>> >>> Please indicate your support or lack thereof to the mail list by >>> December 12, 2014. >>> >>> Also, please supply feedback to the authors. I believe the perception of >>> this document is that it's very nearly complete and thus should have a >>> short >>> lifetime prior to publication as an RFC. >>> >>> -- Jeff & Nobo. >>> >> > From nobody Sun Dec 7 19:32:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AFA1A1BA9 for ; Sun, 7 Dec 2014 19:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Ofrz9IVO0kkg for ; Sun, 7 Dec 2014 19:32:31 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 356AD1A1BA5 for ; Sun, 7 Dec 2014 19:32:31 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 0ABFD2AA0F; Mon, 8 Dec 2014 03:32:26 +0000 (GMT) Date: Sun, 7 Dec 2014 19:36:10 -0800 From: Marc Binderberger To: Manav Bhatia , Nobo Akiya (nobo) Message-ID: <20141207193610211284.1f098741@sniff.de> In-Reply-To: References: Subject: Re: BFD stability follow-up from IETF-91 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5ZWUPmZzezTq-HjDZTAFJcH_rnI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 03:32:32 -0000 SGVsbG8gTWFuYXYsDQoNCm1hbnkgZW1haWxzIG9uIHRoaXMgdGhyZWFkIC0gaGFyZCB0byBm b2xsb3cgdXAgOi0pDQoNCkFueXdheSwgc2V2ZXJhbCBjb21tZW50czoNCg0KKiBpZiBzdWNo IGEgZGVidWcgc3VwcG9ydHMgYmVjb21lcyBpbmZvcm1hbCwgZXhwZXJpbWVudGFsIG9yIHN0 YW5kYXJkIGlzIElNSE8gDQppcnJlbGV2YW50IGZvciBpdCBiZWluZyBhY3R1YWxseSBpbXBs ZW1lbnRlZC4gQXMgaXQgbG9va3MgbGlrZSB3ZSB0YWxrIGFib3V0IA0KYXNwZWN0cyB0aGF0 IGFyZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYywgZS5nLiB3aGVuIGV4YWN0bHkgYSBwYWNr ZXQgaXMgDQp0aW1lc3RhbXBlZCwgYnkgaGFyZC0gb3Igc29mdHdhcmUgYW5kIHNvIG9uLCBJ IGhhdmUgbXkgZG91YnQgYWJvdXQgYSBzdGFuZGFyZCANCmRvY3VtZW50IHRob3VnaC4NCg0K KiBHcmVnJ3MgZWNobyBpZGVhIGlzIG9mIGNvdXJzZSBkby1hYmxlIC0gd2hlbiB5b3UgdGhp bmsgdGltZXN0YW1waW5nIGluIA0KaGFyZHdhcmUgY2FuIGJlIGRvbmUgdGhlbiBpdCBjYW4g YmUgZG9uZSBpbiB0aGUgZm9yd2FyZGluZyBwYXRoIGZvciBlY2hvcyBhcyANCndlbGwuIERl cGVuZHMgb24geW91ciBoYXJkd2FyZSA6LSkgYW5kIG9uIGFuIGFncmVlZCAobWluaW1hbCkg Zm9ybWF0IGZvciANCmVjaG8uIEFzIG1lbnRpb25lZCBCRkQgZWNobyBpcyBub3QgZGVmaW5l ZC91c2VkIGZvciBtdWx0aXBsZSBCRkQgZmVhdHVyZXMsIA0Kd2hpY2ggbGltaXRzIGl0J3Mg dXNlIHRob3VnaC4NCg0KKiB0aGUgbG9jYWwgdGltZXN0YW1wcyBjYW5ub3QgY3JlYXRlIGFu IGludGVyb3AgcHJvYmxlbSBhcyB0aGV5IGFyZSBfbG9jYWxfIA0KYW5kIG5vdCBleGNoYW5n ZWQgOi0pIEEgc3RhYmlsaXR5IGRyYWZ0IGNvdWxkIGRlZmluZSB0aGUgbWluaW11bSByZXF1 aXJlbWVudHMgDQp3ZSBoYXZlIGZvciB3aGF0IHRpbWVzdGFtcHMgc2hvdWxkIGJlIChsb2Nh bGx5KSBjb2xsZWN0ZWQuIEZvciBpbnRlcm9wIGFsbCANCnRoYXQgaXMgbmVlZGVkIGlzIGFu IGFncmVlbWVudCBvbiB0aGUgIklEIiwgaS5lLiB0aGUgc2VxdWVuY2UgbnVtYmVyLCANCmVu Y29kaW5nIGluIHRoZSBwYWNrZXQuDQoNCg0KUmVnYXJkcywgTWFyYw0KDQoNCg0KDQoNCg0K DQpPbiBUaHUsIDQgRGVjIDIwMTQgMjA6NTI6MTcgKzA1MzAsIE1hbmF2IEJoYXRpYSB3cm90 ZToNCj4gSGkgTm9ibywNCj4gDQo+IFRoZSBlY2hvIHByb3Bvc2FsIGRvZXNudCBtYWtlIGFu eSBzZW5zZS4gSSB0aG91Z2h0IHRoZSBvbmUgd2l0aCBjYXJyeWluZyANCj4gc29tZSBpbmZv IGFzIHBhcnQgb2YgdGhlIHRoZSBVRFAgb3IgdGhlIElQIHBheWxvYWQgbWFkZSBzb21lLg0K PiANCj4gSGF2aW5nIHNwZW50IGNvdW50bGVzcyBudW1iZXIgb2YgaG91cnMgZGVidWdnaW5n IGEgIkJGRCBmbGFwIiBpIHdvdWxkIA0KPiBkZWZpbml0ZWx5IGxpa2UgdG8gaGF2ZSBhIHN0 ZC10cmFjayBtZWNoYW5pc20gdGhhdCBhaWRzIG1lIGluIGRlYnVnZ2luZyB0aGUgDQo+IHJv b3QgY2F1c2UuDQo+IA0KPiBDaGVlcnMsIE1hbmF2DQo+IA0KPiBPbiBUaHUsIERlYyA0LCAy MDE0IGF0IDg6NDQgUE0sIE5vYm8gQWtpeWEgKG5vYm8pIDxub2JvQGNpc2NvLmNvbT4gd3Jv dGU6DQo+PiBbbm8gaGF0IG9uLCBidHddDQo+PiAgDQo+PiBIaSBNYW5hdiwNCj4+ICANCj4+ IElmIHdoYXQgeW91IHNheSBpcyB0aGUgb25seSByZXF1aXJlbWVudCBub3QgbWV0LCBvbmUg YXBwcm9hY2ggbWF5IGJlIHRvIA0KPj4gcHVyc3VlIGEgbm9uLXN0YW5kYXJkLXRyYWNrIGRv Y3VtZW50IGRlc2NyaWJpbmcgc29tZSBzdWdnZXN0ZWQgDQo+PiBpbXBsZW1lbnRhdGlvbiB0 ZWNobmlxdWVzIHRvIGxvY2FsbHkgc3RvcmUgVFgvUlggdGltZXN0YW1wLg0KPj4gIA0KPj4g R2l2ZW4gdGhhdCBlY2hvIGFwcHJvYWNoIHdpbGwgYmUgbGVzcyBhY2N1cmF0ZSBhbmQgZ2l2 ZW4gdGhhdCB3ZSBzZWVtIHRvIA0KPj4gYmUgaGF2aW5nIGRpZmZpY3VsdHkgY29udmVyZ2lu ZywgSSB0aG91Z2h0IEmibGwgdGhyb3cgb3V0IGFub3RoZXIgaWRlYS4NCj4+ICANCj4+IFRo YW5rcyENCj4+ICANCj4+IC1Ob2JvDQo+PiAgDQo+PiBGcm9tOiBNYW5hdiBCaGF0aWEgW21h aWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21dIA0KPj4gU2VudDogVGh1cnNkYXksIERlY2Vt YmVyIDA0LCAyMDE0IDk6NTMgQU0NCj4+IFRvOiBOb2JvIEFraXlhIChub2JvKQ0KPj4gQ2M6 IFNhbnRvc2ggUCBLOyBNQUxMSUsgTVVESUdPTkRBIChtbXVkaWdvbik7IFZlbmdhZGEgUHJh c2FkIEdvdmluZGFuIA0KPj4gKHZlbmdnb3ZpKTsgR3JlZ29yeSBNaXJza3k7IE1hcmMgQmlu ZGVyYmVyZ2VyOyBydGctYmZkQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogQkZEIHN0YWJp bGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQo+PiAgDQo+PiBOb2JvIC0gTG9jYWxseSBz dG9yaW5nIFRYL1JYIHRpbWVzdGFtcHMgaXMgbm90IGludGVyb3BlcmFibGUuDQo+PiAgDQo+ PiBDaGVlcnMsIE1hbmF2DQo+PiAgDQo+PiBPbiBUaHUsIERlYyA0LCAyMDE0IGF0IDc6MzAg UE0sIE5vYm8gQWtpeWEgKG5vYm8pIDxub2JvQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBBIHF1 aWNrIHF1ZXN0aW9uIHRvIHVuZGVyc3RhbmQgd2hlcmUgd2UgYXJlLg0KPj4gIA0KPj4gSWYg d2UgaGFkOg0KPj4gIA0KPj4gMS4gICAgICBTdGFuZGFyZGl6YXRpb24gb2YgTnVsbCBBdXRo ZW50aWNhdGlvbiAoaS5lLiwgc2VxdWVuY2UgbnVtYmVycykNCj4+IDIuICAgICAgSW1wbGVt ZW50YXRpb24gb2YgbG9jYWwgVFgvUlggdGltZXN0YW1wIG1lY2hhbmlzbSBkZXNjcmliZWQg YnkgDQo+PiBNYXJjIGJlbG93DQo+PiAgDQo+PiBXaGF0IGFyZSB0aGUgY29yZSByZXF1aXJl bWVudHMgd2hpY2ggaGF2ZSBub3QgYmVlbiBzYXRpc2ZpZWQ/DQo+PiAgDQo+PiBUaGFua3Mh DQo+PiAgDQo+PiAtTm9ibw0KPj4gIA0KPj4gUC5TLiBObywgdGhlcmUgaXMgbm8gbmVlZCB0 byBzdGFuZGFyZGl6ZSBCRkQgZWNobyBjb250ZW50cy4NCj4+ICANCj4+PiAgDQo+PiANCj4g From nobody Sun Dec 7 20:03:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0309B1A1BF6 for ; Sun, 7 Dec 2014 20:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GBqAUM71r90a for ; Sun, 7 Dec 2014 20:03:12 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181A11A1BF4 for ; Sun, 7 Dec 2014 20:03:12 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id uz6so3083912obc.30 for ; Sun, 07 Dec 2014 20:03:11 -0800 (PST) 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:content-type; bh=eEvu/ls1AtputEs02+PnHDj9e8E4EgVIGhVKetfInoE=; b=bZzC6ipNbqwqFGjHo0BGzsnwywJqkibk4rHW1O9pVuPEQAAzV8oWBuyS84YBOxCifp ED0tDMdXNlq6+f5+vdMCEJEa7tPNcFPBCdwdQdfC/WnRuxhqVmjH8fehzrh+l/woqTwA OfnFYNMndRAvAz7pwv8W/exmwwlgaXw+FvXKp+FDq8f561GvL5W9rzG1x/8ZO+m9jiGw GY7C5wXbSkX2G4YPhaxje/RXHu7ldHkVMrH3+Py4Xa2CTF9isiUlgJgJhFg7EXejRX9v pJDK2nunGANw+MOWXrgbVz6EWDQecwmJHU4Y/hlmLwKKT3StyzK5E9qjraZFgBSCDvnn l3Tg== MIME-Version: 1.0 X-Received: by 10.202.69.137 with SMTP id s131mr5541411oia.103.1418011385465; Sun, 07 Dec 2014 20:03:05 -0800 (PST) Received: by 10.76.178.199 with HTTP; Sun, 7 Dec 2014 20:03:05 -0800 (PST) In-Reply-To: <20141207193610211284.1f098741@sniff.de> References: <20141207193610211284.1f098741@sniff.de> Date: Mon, 8 Dec 2014 09:33:05 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Marc Binderberger Content-Type: multipart/alternative; boundary=001a113dae32eb15280509ac801e Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ocK8lp6G71PVRYnTOmnGej_P_n8 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 04:03:14 -0000 --001a113dae32eb15280509ac801e Content-Type: text/plain; charset=UTF-8 Hi Marc, > > * Greg's echo idea is of course do-able - when you think timestamping in > hardware can be done then it can be done in the forwarding path for echos > as > well. Depends on your hardware :-) and on an agreed (minimal) format for > echo. As mentioned BFD echo is not defined/used for multiple BFD features, > which limits it's use though. > > For the echo mechanism to work, do you agree that you would have to continuously send Echos so that you can detect the issue? Or are you suggesting that once BFD flaps we will start sending Echoes overloaded with debug information to detect the issue? I'd like to understand this before the mailing list sees a barrage of emails. Alternatively, we can also take it offline and only report the summary of our discussion to the list. Cheers, Manav --001a113dae32eb15280509ac801e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marc,



* Greg's echo idea is of course do-able - when you think timestamping i= n
hardware can be done then it can be done in the forwarding path for echos a= s
well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features,<= br> which limits it's use though.


For the echo mechanism to work, do you= agree that you would have to continuously send Echos so that you can detec= t the issue?

Or are you suggesting that once BFD f= laps we will start sending Echoes overloaded with debug information to dete= ct the issue?

I'd like to understand this befo= re the mailing list sees a barrage of emails. Alternatively, we can also ta= ke it offline and only report the summary of our discussion to the list.

Cheers, Manav
--001a113dae32eb15280509ac801e-- From nobody Sun Dec 7 20:03:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3361F1A1BF6 for ; Sun, 7 Dec 2014 20:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 uJ4ktlwFa6EP for ; Sun, 7 Dec 2014 20:03:36 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6B61A1BFA for ; Sun, 7 Dec 2014 20:03:35 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id A76552AA0F; Mon, 8 Dec 2014 04:03:32 +0000 (GMT) Date: Sun, 7 Dec 2014 20:07:16 -0800 From: Marc Binderberger To: Manav Bhatia Message-ID: <20141207200716673593.1de52229@sniff.de> In-Reply-To: References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> Subject: Re: BFD stability follow-up from IETF-91 MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NpBTsmXls96Ly8Cax6mKac4FxJ4 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 04:03:38 -0000 SGVsbG8gTWFuYXYsDQoNCj4gSSBhbSBzdXJlIHRoZSBXRyB3b3VsZCBhcHByZWNpYXRlIHN1 Y2ggYSBsZWN0dXJlIHNpbmNlIHRoYXQgd291bGQgb2J2aWF0ZSANCj4gdGhlIG5lZWQgZm9y IHN1Y2ggYW4gSUQuIEFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IGkgdHVybiBvbiBsb2dnaW5n IGFuZCANCj4gcGFja2V0IHRyYWNpbmcgZm9yICplYWNoKiBpbmNvbWluZyBCRkQgcGFja2V0 IGZvciBhbGwgdGhlIHNlc3Npb25zIHRoYXQgaSANCj4gaGF2ZT8gVHJ5aW5nIGRvaW5nIHRo YXQgZm9yIDI1IEJGRCBzZXNzaW9ucyB3aGVyZSBmZXcgYXJlIHJ1bm5pbmcgYXQgNTBtcyAN Cj4gYW5kIDEwMG1zIFRYIGludGVydmFscy4gTm93IHRyeWluZyBjb21iaW5nIHRocm91Z2gg dGhlIGxvZ3Mgd2hlbiAxIEJGRCANCj4gc2Vzc2lvbiBmbGFwcyB0byB1bmRlcnN0YW5kIHdo ZXJlIHRoZSBpc3N1ZSB3YXMuDQoNCnRoZSBwcm9ibGVtIEkgaGF2ZSBoZXJlIGlzIHdlIG1v dmUgZGVlcCBpbnRvIHRoZSBpbXBsZW1lbnRhdGlvbiBhcmVhLiANCiJQcm9ibGVtIiBmb3Ig MiByZWFzb25zOg0KDQoqIGl0J3MgdGVsbGluZyBteSBjb21wZXRpdG9ycyB3aGF0IHRyaWNr cyBteSBjb21wYW55IGhhcyBkZXZlbG9wZWQgZm9yIGJldHRlciANCmRlYnVnZ2luZy4gV2Fp dCAuLi4gSSB3YW50IHRvIHNlbGwgdGhpcyBhZHZhbnRhZ2UhIDotKQ0KDQoqIGlmIHdlIHRy eSB0byAic3RhbmRhcmRpemUiIHRoaXMgdG9vIGZhciB3ZSBjaG9rZSBpbXBsZW1lbnRvcidz IHBoYW50YXN5LiBBdCANCmxlYXN0IEkgZmVhciBzby4NCg0KDQpNYW5hdiwgaWYgeW91IHRo aW5rIGFib3V0IHNvbWUga2luZCBvZiBsaWdodCwgaW50ZWdyYXRlZCBsb2cvdHJhY2luZywg dGhlbiANCnllcywgeW91IGNvdWxkIGRvIHRoaXMgZm9yIHRob3VzYW5kcyBvZiBzZXNzaW9u cyB3aXRoIGV2ZW4gZmFzdGVyIHRpbWVycy4gSSdtIA0Kb2YgY291cnNlIHNwZWFraW5nIHB1 cmVseSBoeXBvdGhldGljYWwgaGVyZSAqY291Z2gqIDotKQ0KDQpUaGlzIGlzIHdoeSBJJ20g YSBmYW4gb2Ygc29tZSBtaW5pbWFsIGFncmVlbWVudCBwbHVzIHJvb20gZm9yIGxvY2FsIChp LmUuIA0KcGVyLXZlbmRvcikgZGF0YSB0byBiZSBjb2xsZWN0ZWQuIEZvciBkZWJ1Z2dpbmcg eW91IHdhbnQgYm90aCBzaWRlcy92ZW5kb3JzIA0KYmVpbmcgaW52b2x2ZWQgYW55d2F5IGFz IGRhdGEgbmVlZHMgdG8gYmUgaW50ZXJwcmV0ZWQuDQoNCg0KUmVnYXJkcywgTWFyYw0KDQoN Cg0KT24gRnJpLCA1IERlYyAyMDE0IDA4OjMxOjMzICswNTMwLCBNYW5hdiBCaGF0aWEgd3Jv dGU6DQo+IEhpIEdyZWcsDQo+IA0KPiBJIGFtIHN1cmUgdGhlIFdHIHdvdWxkIGFwcHJlY2lh dGUgc3VjaCBhIGxlY3R1cmUgc2luY2UgdGhhdCB3b3VsZCBvYnZpYXRlIA0KPiB0aGUgbmVl ZCBmb3Igc3VjaCBhbiBJRC4gQXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgaSB0dXJuIG9uIGxv Z2dpbmcgYW5kIA0KPiBwYWNrZXQgdHJhY2luZyBmb3IgKmVhY2gqIGluY29taW5nIEJGRCBw YWNrZXQgZm9yIGFsbCB0aGUgc2Vzc2lvbnMgdGhhdCBpIA0KPiBoYXZlPyBUcnlpbmcgZG9p bmcgdGhhdCBmb3IgMjUgQkZEIHNlc3Npb25zIHdoZXJlIGZldyBhcmUgcnVubmluZyBhdCA1 MG1zIA0KPiBhbmQgMTAwbXMgVFggaW50ZXJ2YWxzLiBOb3cgdHJ5aW5nIGNvbWJpbmcgdGhy b3VnaCB0aGUgbG9ncyB3aGVuIDEgQkZEIA0KPiBzZXNzaW9uIGZsYXBzIHRvIHVuZGVyc3Rh bmQgd2hlcmUgdGhlIGlzc3VlIHdhcy4NCj4gDQo+IENoZWVycywgTWFuYXYNCj4gDQo+IE9u IFRodSwgRGVjIDQsIDIwMTQgYXQgMTA6MDMgUE0sIEdyZWdvcnkgTWlyc2t5IA0KPiA8Z3Jl Z29yeS5taXJza3lAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+IEhpIE1hbmF2LA0KPj4gSSBo b3BlIHlvdSBkb26hpnQgZXhwZWN0IG1lIHRvIGdpdmUgYSBsZWN0dXJlIG9uIGhvdyB0byBk ZXNpZ24gYW5kIA0KPj4gaW1wbGVtZW50IGRlYnVnYWJsZSBpbXBsZW1lbnRhdGlvbiB1c2lu ZyBsb2dnaW5nIGFuZCBwYWNrZXQgdHJhY2luZy4NCj4+ICANCj4+ICAgICAgICAgICAgICAg ICBSZWdhcmRzLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQo+ PiAgDQo+PiBGcm9tOiBNYW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5j b21dIA0KPj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDg6MTYgQU0NCj4+ IFRvOiBHcmVnb3J5IE1pcnNreQ0KPj4gQ2M6IFNhbnRvc2ggUCBLOyBNYWhlc2ggSmV0aGFu YW5kYW5pOyBydGctYmZkQGlldGYub3JnDQo+PiANCj4+IFN1YmplY3Q6IFJlOiBCRkQgc3Rh YmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4+IA0KPj4gIA0KPj4gSSBhbSBub3Qg c3VyZSB3aGF0IHRoZSBjb25mdXNpb24gaXMgR3JlZy4NCj4+ICANCj4+IEFzc3VtZSBpIGhh dmUgYSBCRkQgc2Vzc2lvbiB0aGF0cyB1cC4gQXQgc29tZSBwb2ludCBpbiB0aW1lIGl0IGZs YXBzLiBOb3cgDQo+PiBpIG5lZWQgdG8ga25vdyB3aGV0aGVyIHRoZSBpc3N1ZSB3YXMgYXQg dGhlIFRYIG9yIHRoZSBSWC4NCj4+ICANCj4+IFBsZWFzZSB0ZWxsIG1lIGhvdyBUV0FNUCBj YW4gaGVscCBtZSBoZXJlLiBBbHNvIHRlbGwgbWUgaG93IHdoYXQgdG9vbCBpIA0KPj4gY2Fu IHVzZSBpZiBpdHMgYSB1QkZEIHNlc3Npb24gdGhhdCBmbGFwcGVkLg0KPj4gIA0KPj4gQ2hl ZXJzLCBNYW5hdg0KPj4gIA0KPj4gT24gVGh1LCBEZWMgNCwgMjAxNCBhdCA5OjA5IFBNLCBH cmVnb3J5IE1pcnNreSANCj4+IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+IHdyb3Rl Og0KPj4gSGkgU2FudG9zaCwNCj4+IGJ1dCB0aGF0IGlzIHdoYXQgY2FuIGJlIGNhbGxlZCCh p2ZlYXR1cmUgY3JlZXChqC4gQkZEIGlzIGNvbnRpbnVpdHkgY2hlY2sgDQo+PiBtZWNoYW5p c20gYW5kIGZvciBhY3RpdmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQsIGV2ZW4gb2NjYXNp b25hbCwgdGhlcmUgDQo+PiBhcmUgVFdBTVAgaW4gSVAgYW5kIFJGQyA2Mzc0LzYzNzUgaW4g TVBMUy9NUExTLVRQLiBJdCBtYXkgYmUgdGVtcHRpbmcgdG8gDQo+PiBleHBhbmQgc2NvcGUg b2YgQkZEIGJ1dCwgSSBiZWxpZXZlLCBpdCBpcyBzdWNjZXNzZnVsIGV4YWN0bHkgYmVjYXVz ZSBpdCANCj4+IHdhcyBzaW1wbGUsIGxpZ2h0LXdlaWdodCBhbmQgZGVzaWduZWQgdG8gZG8g ZXhhY3RseSBvbmUgdGhpbmcgoVYgDQo+PiBjb250aW51aXR5IGNoZWNrLg0KPj4gIA0KPj4g ICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEdyZWcNCj4+ICANCj4+IEZyb206IFNhbnRvc2ggUCBLIFttYWlsdG86c2FudG9z aHBrQGp1bmlwZXIubmV0XSANCj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAx NCA3OjAyIEFNDQo+PiBUbzogR3JlZ29yeSBNaXJza3k7IE1haGVzaCBKZXRoYW5hbmRhbmkN Cj4+IA0KPj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBCRkQgc3Rh YmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4+ICANCj4+IEhlbGxvIEdyZWcsDQo+ PiAgIERlYnVnZ2luZyBCRkQgaXMgb25lIG9mIHRoZSB1c2UgY2FzZS4gSSBhbHNvIHdhbnQg dG8gYnJpbmcgdXAgb25lIG9mIHRoZSANCj4+IHVzZSBjYXNlIHRoYXQgSmVmZiBzdWdnZXN0 ZWQgaW4gaGlzIGVhcmxpZXIgIG1haWwuIE9wZXJhdG9yIG1pZ2h0IE5PVCB3YW50IA0KPj4g dG8gcnVuIE9BTSB3aGljaCBkb2VzIGxvc3MgYW5kIGRlbGF5IG1lYXN1cmVtZW50IGFsbCB0 aGUgdGltZSBkdWUgdG8gaXRzIA0KPj4gb3ZlcmhlYWQuIFdpdGggdGhlIGV4dGVuc2lvbiB0 byBCRkQgKHNlcXVlbmNlIG51bWJlcikgd2UgY2FuIGRldGVjdCBpZiANCj4+IHRoZXJlIGlz IGFueSBsb3NzIGJ1dCBCRkQgc3RpbGwgc3RheXMgdXAuIFRoaXMgbG9zcyBkZXRlY3Rpb24g Y2FuIGJlIHVzZWQgDQo+PiBhcyBhIHRyaWdnZXIgZm9yIGxvc3MgYW5kIGRlbGF5IG1lYXN1 cmVtZW50LiBFY2hvIGNhbiBiZSB1c2VkIG9ubHkgaW4gY2FzZSANCj4+IG9mIHNpbmdsZWhv cCBhbmQgaW4gb25lIGRpcmVjdGlvbiBvbmx5LiAgDQo+PiAgDQo+PiBUaGFua3MNCj4+IFNh bnRvc2ggUCBLICANCj4+ICANCj4+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnb3J5IE1pcnNreQ0KPj4gU2VudDog VGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDEyOjEyIFBNDQo+PiBUbzogTWFoZXNoIEpl dGhhbmFuZGFuaQ0KPj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBC RkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4+ICANCj4+IEhpIE1haGVz aCwNCj4+IGluZGVlZCwgTFNQIFBpbmcgaXMgcGFydCBvZiBNUExTIE9BTSB0b29sIHNldCBh cyBCRkQgaXRzZWxmIHRoYXQgaW50ZW5kZWQgDQo+PiB0byBtb25pdG9yIG9wZXJhdGlvbmFs IHN0YXRlIG9mIHRoZSBuZXR3b3JrLCBwYXRoIGNvbnRpbnVpdHkgYmV0d2VlbiB0d28gDQo+ PiBub2Rlcy4gQW5kIExTUCBQaW5nLCBhcyBwcmltYXJpbHkgb24tZGVtYW5kIHRyb3VibGVz aG9vdGluZyB0b29sLCBoZWxwcyANCj4+IGxvY2FsaXplIGFuZCwgdG8gY2VydGFpbiBkZWdy ZWUsIGRpYWdub3NlIHRoZSBwcm9ibGVtLiBCdXQgdGhlIHVsdGltYXRlIA0KPj4gZGVidWdn aW5nIGlzIHByb3ByaWV0YXJ5LiBUaGlzIHByb3Bvc2FsLCBpbiBteSB2aWV3LCBoZWxwcyBu b3QgbW9uaXRvciANCj4+IGJlaGF2aW9yIG9mIHRoZSBuZXR3b3JrIGJ1dCBCRkQgaXRzZWxm LCBxdWFsaXR5IG9mIEJGRCBpbXBsZW1lbnRhdGlvbi4gSaGmDQo+PiBtIG5vdCBzYXlpbmcg dGhhdCBpdCBpcyBub3QgdXNlZnVsIGZvciBpbXBsZW1lbnRlcnMgYW5kIG9wZXJhdG9ycywg b25lIGNhbiANCj4+IGZpbmQgdGhhdCB0b28gbWFueSBCRkQgc2Vzc2lvbnMgb3IgYXQgdG9v IHNob3J0IGludGVydmFscyBiZWluZyAgcmFuLiBJIGRvbg0KPj4goaZ0IGFncmVlIHRvIGxv YWRpbmcgdGhpcyBhcyBleHRlbnNpb24gb2YgdGhlIHdpZGVseSB1c2VkIHN0YW5kYXJkLiAN Cj4+IFBlcmhhcHMgd2UgY2FuIGxvb2sgaW50byB1c2luZyBCRkQgRWNobyBhcyBzZWxmLWRl YnVnZ2luZyBpbnN0cnVtZW50Lg0KPj4gIA0KPj4gICAgICAgICAgICAgICAgIFJlZ2FyZHMs DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCj4+ICANCj4+IEZy b206IE1haGVzaCBKZXRoYW5hbmRhbmkgW21haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNv bV0gDQo+PiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDAzLCAyMDE0IDEwOjIzIFBNDQo+ PiBUbzogR3JlZ29yeSBNaXJza3kNCj4+IENjOiBGYW4sIFBlbmc7IE1BTExJSyBNVURJR09O REEgKG1tdWRpZ29uKTsgcnRnLWJmZEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IEJGRCBz dGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KPj4gIA0KPj4gR3JlZywNCj4+ICAN Cj4+IEkgYmVsaWV2ZSB3ZSBoYXZlIGEgZGlzYWdyZWVtZW50IGhlcmUuIEkgZG8gbm90IGJl bGlldmUgdGhhdCBpc3N1ZSBvZiANCj4+IGRlYnVnIGFiaWxpdHkgYXJlIG91dHNpZGUgdGhl IHNjb3BlIG9mIGEgc3RhbmRhcmRpemVkIHByb3RvY29sLg0KPj4gIA0KPj4gTG9vayBhdCBN UExTIHBpbmcgYW5kIHRyYWNlcm91dGUgKFJGQyA0Mzc5KSAuIFRoZXkgYXJlIHVsdGltYXRl bHkgZGVidWcgDQo+PiB0b29scyB1c2VkIHRvIGVzdGFibGlzaCB2aWFiaWxpdHkgb2YgYSBw YXRoIGFuZCB0aGV5IGFyZSB2ZXJ5IG11Y2ggcGFydCBvZiANCj4+IHRoZSBzdGFuZGFyZGl6 ZWQgcHJvdG9jb2wuDQo+PiAgDQo+Pj4gT24gRGVjIDMsIDIwMTQsIGF0IDM6MjUgUE0sIEdy ZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+IA0KPj4+IHdyb3Rl Og0KPj4+ICANCj4+PiBIaSBNYWhlc2gsDQo+Pj4gSSBjb25zaWRlciBpc3N1ZXMgb2YgZGVi dWdhYmlsaXR5LCBub3Qgb2YganVzdCBCRkQgYnV0IGFueSBvdGhlciANCj4+PiBzdGFuZGFy ZGl6ZWQgcHJvdG9jb2wsIHRvIGJlIG91dHNpZGUgb2YgU3RhbmRhcmQgdHJhY2ssIGF0IG1v c3QgdG8gYmUgDQo+Pj4gc3VpdGFibGUgZm9yIEluZm9ybWF0aW9uYWwgb3IgRXhwZXJpbWVu dGFsIHRyYWNrLiBJZiB3ZSBhZ3JlZSBvbiB0aGF0LCANCj4+PiB0aGVuIHdlIGNhbiBkaXNj dXNzIHNjZW5hcmlvcyB0aGF0IHByZXNlbnQgcHJvYmxlbSBhbmQgaW52ZXN0aWdhdGUgDQo+ Pj4gd2hldGhlciBhbnl0aGluZyBpbiB0aGUgcHJvdG9jb2wgcmVxdWlyZXMgY2xhcmlmaWNh dGlvbiB0byBoZWxwIHZlbmRvcnMgDQo+Pj4gaW4gYnVpbGRpbmcgd2VsbC1wZXJmb3JtaW5n LCBzY2FsYWJsZSBhbmQgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgDQo+Pj4gYW5k IHByb3ZpZGUgb3BlcmF0aW9uYWwgZ3VpZGVsaW5lcyBmb3Igb3BlcmF0b3JzLg0KPj4+ICAN Cj4+PiAgICAgICAgICAgICAgICAgUmVnYXJkcywNCj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEdyZWcNCj4+PiAgDQo+Pj4gRnJvbTogTWFoZXNoIEpldGhhbmFuZGFu aSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXSANCj4+PiBTZW50OiBUdWVzZGF5 LCBEZWNlbWJlciAwMiwgMjAxNCA4OjQ2IFBNDQo+Pj4gVG86IEdyZWdvcnkgTWlyc2t5DQo+ Pj4gQ2M6IEZhbiwgUGVuZzsgTUFMTElLIE1VRElHT05EQSAobW11ZGlnb24pOyBydGctYmZk QGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZy b20gSUVURi05MQ0KPj4+ICANCj4+PiBHcmVnLA0KPj4+ICANCj4+PiBXaGF0IGlzIFBlbmcg cmVmZXJyaW5nIHRvIGlzIGEgd2F5IHRvIGZpZ3VyZSBvdXQgd2h5IGEgcGFydGljdWxhciBC RkQgDQo+Pj4gc2Vzc2lvbiBmbGFwcGVkLCBwYXJ0aWN1bGFybHkgaWYgdGhlIHBhY2tldChz KSBmb3IgdGhhdCBzZXNzaW9uIGFycml2ZSANCj4+PiBsYXRlLiBJIGRvIG5vdCBzZWUgaG93 IHRoYXQgY2FuIGJlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LiBJdCBpcyBiYXNpYyANCj4+ PiBCRkQgZGVidWcgYWJpbGl0eS4gUnVubmluZyBhIHNlcGFyYXRlIERNIGRvZXMgdGVsbCB5 b3Ugd2h5IGEgcGFydGljdWxhciANCj4+PiBCRkQgc2Vzc2lvbiBmbGFwcGVkLg0KPj4+ICAN Cj4+PiBOb3cgd2UgY2FuIGRlYmF0ZSB3aGF0IG1ldGhvZHMgY2FuIGJlIGVtcGxveWVkIHRv IG1lYXN1cmUgdGhhdCBkZWxheSBhbmQgDQo+Pj4gSSBhbSBvcGVuIHRvIHdheXMgdG8gZG9p bmcgaXQsIGluY2x1ZGluZyBsb2NhbCBsb29wYmFjayB0byBtZWFzdXJlIA0KPj4+IHRyYW5z bWl0IGRlbGF5cyBvciB0aW1lIHN0YW1waW5nIG9mIHBhY2tldHMgaW4gaGFyZHdhcmUuIEJ1 dCBpbiBjYXNlcywgDQo+Pj4gd2hlcmUgdGhlcmUgaXMgbm8gc3VwcG9ydCBmb3IgZWl0aGVy IG9mIHRoZSBjYXBhYmlsaXRpZXMsIG9uZSBvZiB0aGUgDQo+Pj4gc3VnZ2VzdGVkIHNvbHV0 aW9ucyBpcyB0byB1c2UgdGhlIHRpbWUgc3RhbXBzIGNhcnJpZWQgaW4gdGhlIEJGRCBwYXls b2FkLiANCj4+PiAgDQo+Pj4gQ2hlZXJzLg0KPj4+ICANCj4+Pj4gT24gRGVjIDEsIDIwMTQs IGF0IDk6MzggQU0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b20+IA0KPj4+PiB3cm90ZToNCj4+Pj4gIA0KPj4+PiBIaSBQZW5nLA0KPj4+PiBhbmQgc3Rp bGwsIHlvdaGmcmUgbG9va2luZyBmb3IgYSB0b29sIHRvIG1lYXN1cmUgQkZEIHBlcmZvcm1h bmNlLiBUaGVuIA0KPj4+PiB5b3WhpmxsIGJlIGxvb2tpbmcgZm9yIGEgdG9vbCB0byB2ZXJp ZnkgdGhlIEJGRCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCwgDQo+Pj4+IGFuZCBvbiwgYW5k IG9uLiBPcGVyYXRvcnMgZG8gbmVlZCBjb21wbGV0ZSBzZXQgb2YgRkNBUFMgdG9vbHMsIGlu Y2x1ZGluZyANCj4+Pj4gcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQuIE5vdGUgdGhhdCBwYXNz aXZlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IA0KPj4+PiB0aHJvdWdoIG1hcmtpbmcgbWV0 aG9kIHRoYXQgTWFjaCBDaGVuIHJlZmVycmVkIHRvIGNhbiBtb25pdG9yIEJGRCANCj4+Pj4g ZmxvdyhzKSBhbmQgYmUgdXNlZCB0byBkbyBMb3NzIGFuZC9vciBEZWxheSBNZWFzdXJlbWVu dC4gQW5kIGFjdGl2ZSANCj4+Pj4gU3ludGhldGljIExvc3MgTWVhc3VyZW1lbnQgbWF5IHNp bXVsYXRlIGZsb3cgb2Ygc21hbGwgcGFja2V0cyBhcyB3ZWxsIGFzIA0KPj4+PiByZWxhdGl2 ZWx5IGxhcmdlIHBhY2tldHMuIEFuZCB0aGUgc2FtZSBnb2VzIGZvciBhY3RpdmUgbWVhc3Vy ZW1lbnQgDQo+Pj4+IG1ldGhvZCBvZiBEZWxheSBNZWFzdXJlbWVudC4gSSBsaWtlIFN3aXNz IEFybXkga25pdmVzIGJ1dCBsZXQgdXMgbm90IA0KPj4+PiB0dXJuIEJGRCBpbnRvIG9uZS4N Cj4+Pj4gIA0KPj4+PiAgICAgICAgICAgICAgICAgUmVnYXJkcywNCj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQo+Pj4+ICANCj4+Pj4gRnJvbTogRmFuLCBQ ZW5nIFttYWlsdG86ZmFucGVuZ0BjaGluYW1vYmlsZS5jb21dIA0KPj4+PiBTZW50OiBNb25k YXksIERlY2VtYmVyIDAxLCAyMDE0IDQ6NDQgQU0NCj4+Pj4gVG86IEdyZWdvcnkgTWlyc2t5 OyAnTUFMTElLIE1VRElHT05EQSAobW11ZGlnb24pJzsgcnRnLWJmZEBpZXRmLm9yZw0KPj4+ PiBTdWJqZWN0OiBSRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQo+ Pj4+ICANCj4+Pj4gSGkgR3JlZ29yeSwNCj4+Pj4gIA0KPj4+PiBJIHdhcyBqdXN0IGdpdmlu ZyBhbiBleGFtcGxlIDopIEFwcGxpY2F0aW9uIHRyYWZmaWMgdXN1YWxseSBjYW5ub3Qgc3Rh bmQgDQo+Pj4+IHNtYWxsIHBhY2tldCBsb3NzLCBub3QgdG8gc2F5IDMwJSBsb3NzLg0KPj4+ PiAgDQo+Pj4+IEkgYW0gYWN0dWFsbHkgYXNraW5nIGZvciBhIGRlYnVnIGZ1bmN0aW9uIHRo YXQgY291bGQgZ2l2ZSB1cyBzb21lIHVzZWZ1bCANCj4+Pj4gaGludHMgb2YgcG9vciBjb25u ZWN0aW9uIHdpdGggc21hbGwgcHJvdG9jb2wgY2hhbmdlLCBiZXNpZGVzIHRoZSBiYXNpYyAN Cj4+Pj4gY29ubmVjdGl2aXR5IGluZm9ybWF0aW9uLiBJZiBpdCBtZWFzdXJlcyBzb21ldGhp bmcsIGl0IG1lYXN1cmVzIHBhY2tldHMgDQo+Pj4+IG9mIEJGRCBpdHNlbGYuIFNvIEkgZG9u oaZ0IGV4cGVjdCBpdCB0byBiZSBjb25zaWRlcmVkIGFzIGEgcGVyZm9ybWFuY2UgDQo+Pj4+ IG1lYXN1cmVtZW50IHRvb2wuDQo+Pj4+ICANCj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4+PiBQ ZW5nDQo+Pj4+ICANCj4+Pj4gRnJvbTogR3JlZ29yeSBNaXJza3kgW21haWx0bzpncmVnb3J5 Lm1pcnNreUBlcmljc3Nvbi5jb21dIA0KPj4+PiBTZW50OiBTYXR1cmRheSwgTm92ZW1iZXIg MjksIDIwMTQgMzozNyBBTQ0KPj4+PiBUbzogRmFuLCBQZW5nOyAnTUFMTElLIE1VRElHT05E QSAobW11ZGlnb24pJzsgcnRnLWJmZEBpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSRTogQkZE IHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQo+Pj4+ICANCj4+Pj4gSGkgUGVu ZywNCj4+Pj4gdGhpcyBpcyB2ZXJ5IGludGVyZXN0aW5nIHNjZW5hcmlvLiBJIHRoaW5rIHRo YXQgaWYgQkZEIGV4cGVyaWVuY2VzIH4zMCUgDQo+Pj4+IHBhY2tldCBsb3NzLCB0aGVuIGhp Z2hseSBsaWtlbHkgc28gYXJlIGFmZmVjdGVkIG90aGVyIGFwcGxpY2F0aW9ucy4gVGhlbiAN Cj4+Pj4gaXQgaXMgbm90IGp1c3QgQkZEIGlzc3VlIGJ1dCBjb25kaXRpb24gdGhhdCBzaG91 bGQgYmUgZGV0ZWN0ZWQgIGJ5IA0KPj4+PiBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBtZXRo b2QsIHdoZXRoZXIgYWN0aXZlIG9yIHBhc3NpdmUgcGFja2V0IGxvc3MgDQo+Pj4+IG1lYXN1 cmVtZW50Lg0KPj4+PiBJoaZtIGNvbnZpbmNlZCB0aGF0IG92ZXJsb2FkaW5nIEJGRCB3aXRo IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IA0KPj4+PiBwcm92aXNpb25zIGlzIGNvdW50ZXIt cHJvZHVjdGl2ZSBhbmQgaXMgaW5hcHByb3ByaWF0ZS4NCj4+Pj4gIA0KPj4+PiAgICAgICAg ICAgICAgICAgUmVnYXJkcywNCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBHcmVnDQo+Pj4+ICANCj4+Pj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZhbiwgUGVuZw0KPj4+PiBTZW50OiBGcmlk YXksIE5vdmVtYmVyIDI4LCAyMDE0IDQ6MzQgQU0NCj4+Pj4gVG86ICdNQUxMSUsgTVVESUdP TkRBIChtbXVkaWdvbiknOyBydGctYmZkQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6IFJFOiBC RkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4+Pj4gIA0KPj4+PiBIaSBN YWxsaWssDQo+Pj4+ICANCj4+Pj4gRXhhY3RseS4gUGFja2V0cyBtYXkgYmUgZXhwZXJpZW5j aW5nIHNsaWdodCBsb3NzLCBidXQgdGhlIGxpbmsgY2FuIA0KPj4+PiBoYXJkbHkgYmUgcmVn YXJkZWQgYXMgY29ubmVjdGVkLiBNb3JlIGltcG9ydGFudGx5LCB0aGUgZXhwZXJpZW5jZSBv ZiANCj4+Pj4gdXBwZXItbGV2ZWwgYXBwbGljYXRpb25zIGNhbiBiZSBkZWdyYWRlZCBzZXZl cmVseSAoZS5nLiBUQ1AgdHJhZmZpYyBpcyANCj4+Pj4gbm90IGFibGUgdG8gZ28gZmFzdCBp biBmYWNlIG9mIGV2ZW4gc21hbGwgY29udGludW91cyBsb3NzKS4gQnV0IHdoYXQgaWYgDQo+ Pj4+IG9uZSBCRkQgZnJhbWUgaXMgbG9zdCBldmVyeSB0aHJlZSBmcmFtZXM/IFRoZW4gdGhl IGxvc3MgcmF0ZSBpcyAzMCUgb24gDQo+Pj4+IGF2ZXJhZ2UsIHdoaWNoIGlzIGFscmVhZHkg YSB2ZXJ5IHNldmVyZSB2YWx1ZS4NCj4+Pj4gIA0KPj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+ IFBlbmcNCj4+Pj4gIA0KPj4+PiBGcm9tOiBNQUxMSUsgTVVESUdPTkRBIChtbXVkaWdvbikg W21haWx0bzptbXVkaWdvbkBjaXNjby5jb21dIA0KPj4+PiBTZW50OiBGcmlkYXksIE5vdmVt YmVyIDI4LCAyMDE0IDc6NTMgUE0NCj4+Pj4gVG86IEZhbiwgUGVuZzsgcnRnLWJmZEBpZXRm Lm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJ RVRGLTkxDQo+Pj4+ICANCj4+Pj4gSGkgUGVuZywNCj4+Pj4gIA0KPj4+PiBJZiB0aGUgQkZE IHBhY2tldHMgYXJlIGxvc3QsIGRvZXNuoaZ0IHRoZSBCRkQgc2Vzc2lvbiBnbyBET1dOPyBB cmUgeW91IA0KPj4+PiBzYXlpbmcgdGhhdCBwYWNrZXQgbG9zcyBpcyBub3QgYmlnIGVub3Vn aCB0byBtYWtlIEJGRCBzZXNzaW9uIGdvIERPV04/DQo+Pj4+ICANCj4+Pj4gVGhhbmtzDQo+ Pj4+ICANCj4+Pj4gUmVnYXJkcw0KPj4+PiBNYWxsaWsNCj4+Pj4gIA0KPj4+PiBGcm9tOiA8 RmFuPiwgUGVuZyA8ZmFucGVuZ0BjaGluYW1vYmlsZS5jb20+DQo+Pj4+IERhdGU6IEZyaWRh eSwgMjggTm92ZW1iZXIgMjAxNCA0OjIwIHBtDQo+Pj4+IFRvOiAicnRnLWJmZEBpZXRmLm9y ZyIgPHJ0Zy1iZmRAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5 IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4+Pj4gIA0KPj4+PiBIaSBKZWZmLCBhbGwsDQo+ Pj4+ICANCj4+Pj4gSSBoYXZlIGJlZW4gZm9sbG93aW5nIHRoaXMgc3RhYmlsaXR5IGV4dGVu c2lvbiBmcm9tIHRoZSBiZWdpbm5pbmcsIGFuZCANCj4+Pj4gYXMgYW4NCj4+Pj4gb3BlcmF0 b3IgSSB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhhdCB0aGlzIGRyYWZ0IGVuYWJsZXMgdGhl ICJhZHZhbmNlZA0KPj4+PiBmZWF0dXJlIiB3ZSBkZXNpcmUgZm9yIEJGRCB0byBwcm92aWRl IGFkZGl0aW9uYWwgdXNlZnVsIGluZm9ybWF0aW9uIHRoYXQNCj4+Pj4gaGVscHMgb3BlcmF0 b3JzIHVuZGVyc3RhbmQgbmV0d29yayBpc3N1ZXMuIEEgcmVsZXZhbnQgdXNlIGNhc2UgaXMg DQo+Pj4+IGRldGVjdGluZw0KPj4+PiBsb3NzeSBvciAicXVhc2ktZGlzY29ubmVjdGVkIiBs aW5rcyBvciBtZW1iZXIgTEFHIGxpbmtzLiBBbiBleGFtcGxlIG9mIA0KPj4+PiBzdWNoDQo+ Pj4+IHNpdHVhdGlvbiB3ZSBleHBlcmllbmNlZCB3YXMgYSBsb29zZWx5IGNvbm5lY3RlZCBm aWJlciBsaW5rIHJlc3VsdGluZyBpbg0KPj4+PiBjb250aW51b3VzLCBzbWFsbCBhbW91bnQg b2YgcGFja2V0IGxvc3MuIEJGRCBjb3VsZCBnZXQgdGhlIGluZm9ybWF0aW9uIG9mDQo+Pj4+ IGxvc3QgQkZEIGZyYW1lcyBvbiBzdWNoIHVuc3RhYmxlIGxpbmssIGFuZCBwcm9iYWJseSBy ZXBvcnQgd2hlbiBhIHRhcmdldA0KPj4+PiBsZXZlbCBpcyByZWFjaGVkLCBzYXkgYSBjZXJ0 YWluIG51bWJlciBvZiBmcmFtZXMgYXJlIGxvc3Qgb3ZlciBhIHBlcmlvZCANCj4+Pj4gb3IN Cj4+Pj4gYW1vbmcgYSB0b3RhbCBudW1iZXIgb2YgZnJhbWVzLg0KPj4+PiAgDQo+Pj4+IEJl c3QgcmVnYXJkcywNCj4+Pj4gUGVuZw0KPj4+IA0KPj4+ICANCj4+PiBNYWhlc2ggSmV0aGFu YW5kYW5pDQo+Pj4gQ28tY2hhaXIsIE5FVENPTkYgV0cNCj4+PiBtamV0aGFuYW5kYW5pQGdt YWlsLmNvbQ0KPj4gDQo+PiAgDQo+PiBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+PiBDby1jaGFp ciwgTkVUQ09ORiBXRw0KPj4gbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCj4+ICANCj4+ICAN Cj4+ICANCj4+ICANCj4g From nobody Sun Dec 7 20:57:02 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E43E1A3BA4 for ; Sun, 7 Dec 2014 20:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 KWn8hcvkqAQD for ; Sun, 7 Dec 2014 20:56:57 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1869D1A1B68 for ; Sun, 7 Dec 2014 20:56:57 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id CBBD32AA0F; Mon, 8 Dec 2014 04:56:54 +0000 (GMT) Date: Sun, 7 Dec 2014 21:00:38 -0800 From: Marc Binderberger To: "Sam K. Aldrin" , Manav Bhatia Message-ID: <20141207210038569945.f0a11d44@sniff.de> In-Reply-To: <3EA747F1-FFDD-4E36-B8A2-58E362C1F601@gmail.com> References: <20141204151708.GA9458@pfrc> <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> <58D290A6-1EB1-425B-9FFA-3025A3CAE4EE@gmail.com> <3EA747F1-FFDD-4E36-B8A2-58E362C1F601@gmail.com> Subject: Re: BFD stability follow-up from IETF-91 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/jjMt8sUN_GImT7tMDwu3CYiF1Lg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 04:56:59 -0000 Hello Sam, Manav et al., really a long thread ... :-) Reading the emails I had a few time the question: what are we trying to achieve here? There is debugging. Obviously, having more (relevant) data helps to find the cause, likely by eliminating the not-causes. I don't expect anything perfect, as Sam stated > Debugging Packet drops, latency and mis-ordering of packets is mostly > shooting in the dark :D But then there may be another motivation. Manav wrote > Ideally even if there is some bit of congestion i would like the BFD > packet to get through. and I wonder what do you mean? You mean BFD should not flap if it was congestion? The "stability" and some comments in the emails makes me wonder if we talk about "do not timeout when ...". And that would be a very different topic. It would mean we talk about a different trigger than the timeout defined in 5880. In this case we would need to talk about the new trigger condition first before we discuss what data needs to be exchanged. >>> I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D >> Sure, that would make Marc very happy ! :-) Count me in! :-) Seriously: if the discussion is to improve debugging of v1 then v2 maybe a long shot. If we talk about different triggers then a v2 header may make sense. Regards, Marc On Thu, 4 Dec 2014 19:52:19 -0800, Sam K. Aldrin wrote: > Hi Manav, > > On Dec 4, 2014, at 6:51 PM, Manav Bhatia wrote: >> Hi Sam, >>>> Ideally even if there is some bit of congestion i would like the BFD >>>> packet to get through. >>> I understand the queuing problems but I am not clear how the ID is going >>> to solve the problem, if there is only congestion and not >> >> It would help. >> >> Assume the last sequence number you saw before the flap was s1. You timed >> out since you did not see s2 and s3 before the timeout. Now further assume >> that you know that you did receive s2 and s3, however they arrived after >> the BFD expiry interval then you know that there wasnt a drop, and the >> packet arrived late because of some queing issue. Now how you determine >> whether this delay was seen at the TX or RX side is open to discussion. > > As the draft doesn't say, what exactly one would/should do, assuming there > is packet throttling happing due to various reasons, could you/authors > elaborate on this? I would like to see those tangible things detailed first. > > I see the problem little differently though. BFD session flapping is an > indicator of the network behavior, be it device or network congestion or > something else. Even if the packets arrive late, as you say, one cannot > know where exactly the delay is happening. > >> >> Without a sequence number you have no idea whether the packet was dropped >> or whether it arrived/processed late. >> >> If by some out-of-band mechanism you can figure out that the TX was done >> on time and the delay was at RX end then its an implementation issue on >> the RX side. If the TX was delayed then its an implementation issue at the >> TX side. > Don't think so. It could be the lot more than implementation issue. Could > be due to network congestion due to bursty traffic and nothing to do with > the implementation. >> >> This helps isolating the node that needs to fix the issue, otherwise we're >> only shooting in the dark. > The issue you see is what I think could be the actual network behavior and > not the device issue. > Debugging Packet drops, latency and mis-ordering of packets is mostly > shooting in the dark :D > Nevertheless, I do not see this as BFD specific only. > >> >>> packet drop. In that case just the sequence # doesn't help and >>> timestamping is needed. Even if timestamping is to be done, realistically >>> it cannot happen the same way across multi vendor i.e. where the >>> timestamping should/could be done. For ex: Before it is queued or after >>> OR LC/RP/SP/Process etc. >> >> This isnt a new problem. Each vendor time stamps 1588 packets differently. >> However, the aggregate solution works across multiple vendors. >> >> While it may not solve all the issues because of the vagaries of how each >> vendor does time stamping it would certainly help debugging large number >> of BFD flaps. > As timestamp is not in the ID, we could differ the discussion for later, > but I definitely believe that it is a bigger issue where TS is taken, if > granularity and accuracy are important. >> >>> >>> Secondly, if the congestion happens, the CIR/PIR should apply to data >>> packets too. In that case BFD flap is at least a good indicator of the >>> problem, isn't it? >> >> There is usually a separate CIR/PIR for different CPU bound packets. So >> based on some parameters you might impose a different CIR/PIR for BFD than >> say, ssh and radius packets. If BFD flaps and you know you missed a few >> sequence numbers and you see drops in that queue then all of this could be >> co-related and you could fix the CPU queue parameters for BFD. I >> understand that this is a very implementation specific issue, but then >> thats what i had said earlier -- such a mechanism can help in isolating >> implementation specific issues as well. > I agree that it will be helpful. But then, when a new mechanism is > introduced, it should clearly spell out the mechanisms on interpreting the > problems and how to deal with it. The ID has none of it, as of now. >> >>> >>> Lastly, these improvements is change from the existing BFD >>> model/protocol. >>> I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D >> >> Sure, that would make Marc very happy ! :-) >> >> I am not sure if we have enough momentum right now that can propel us >> towards BFD v2. >> >> OTOH, if the WG believes that this is an opportune time for us to start >> looking at BFDv2, then i would be more than willing to participate! > Well, if there is real issue that existing BFD falls short of the needs, > then interest automatically increases. As this ID introduces new things to > existing version, it should be pursued as part of next version, rather than > changing the existing model for the same version. > > -sam > >> >> Cheers, Manav >>> >>> -sam >>>> >>>> Cheers, Manav >>>> >>>>> - I see concerns regarding timestamps and sequence numbers expressed in >>>>> emails. In that case, the proposed model is still not going to identify >>>>> the problem completely. Am I reading it right? >>>>> >>>>> -sam >>>>> On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote: >>>>> >>>>>> Hi Jeff, >>>>>> I can reference RFC 5357 here. The Appendix describes what is called >>>>> TWAMP-Light mode with Stateless Reflector. About year and a half the >>>>> Errata been accepted that describes Stateful Reflector, which supports >>>>> measurement of one-way latency/jitter and packet loss metrics. >>>>>> >>>>>> Regards, >>>>>> Greg >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey >>>>> Haas >>>>>> Sent: Thursday, December 04, 2014 7:17 AM >>>>>> To: Nobo Akiya (nobo) >>>>>> Cc: rtg-bfd@ietf.org >>>>>> Subject: Re: BFD stability follow-up from IETF-91 >>>>>> >>>>>> On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote: >>>>>>> If what you say is the only requirement not met, one approach may be >>>>> to pursue a non-standard-track document describing some suggested >>>>> implementation techniques to locally store TX/RX timestamp. >>>>>>> >>>>>>> Given that echo approach will be less accurate and given that we >>>>> seem to be having difficulty converging, I thought I???ll throw out >>>>> another idea. >>>>>> >>>>>> I think my biggest concern is that the echo approach has >>>>> bidirectional packet loss possibilities. Async at least lets the >>>>> receiver know about unidirectional packet loss. >>>>>> >>>>>> Of course, if your goal is to notify the sender that their packets >>>>> are being lost, you need a backchannel anyway. I just don't know if we >>>>> want that back channel to be bfd. >>>>>> >>>>>> - Jeff >>>>>> >>>>> >>>> >>> >> > From nobody Sun Dec 7 21:17:23 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412B81A6EE0 for ; Sun, 7 Dec 2014 21:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 7m_WZbN85V7m for ; Sun, 7 Dec 2014 21:17:20 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C7E1A6EDE for ; Sun, 7 Dec 2014 21:17:20 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id B03E22AA0F; Mon, 8 Dec 2014 05:17:18 +0000 (GMT) Date: Sun, 7 Dec 2014 21:21:02 -0800 From: Marc Binderberger To: Manav Bhatia Message-ID: <20141207212102448099.e2e4012a@sniff.de> In-Reply-To: References: <20141207193610211284.1f098741@sniff.de> Subject: Re: BFD stability follow-up from IETF-91 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Y9nHhmFMqsiCoCazBRhQLc_oJaQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 05:17:21 -0000 Hello Manav, > For the echo mechanism to work, do you agree that you would have to > continuously send Echos so that you can detect the issue? that's what I had in mind, yes > Or are you suggesting that once BFD flaps we will start sending Echoes > overloaded with debug information to detect the issue? interesting idea - that would be an alternative use, collecting forensic data. Maybe we should support that too! My biggest problem with the echo idea is so far BFD-over-LAG. But maybe it is not a real problem, any echo stamping/updating in the forwarding path would require an hardware update (or reprogramming, if your hardware allows) and in this case one could boldly state that the echo packet must leave via the ingress port :-) Regards, Marc On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote: > Hi Marc, > >> >> >> * Greg's echo idea is of course do-able - when you think timestamping in >> hardware can be done then it can be done in the forwarding path for echos >> as >> well. Depends on your hardware :-) and on an agreed (minimal) format for >> echo. As mentioned BFD echo is not defined/used for multiple BFD features, >> which limits it's use though. >> > > For the echo mechanism to work, do you agree that you would have to > continuously send Echos so that you can detect the issue? > > Or are you suggesting that once BFD flaps we will start sending Echoes > overloaded with debug information to detect the issue? > > I'd like to understand this before the mailing list sees a barrage of > emails. Alternatively, we can also take it offline and only report the > summary of our discussion to the list. > > Cheers, Manav From nobody Sun Dec 7 21:41:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC461A6F0B for ; Sun, 7 Dec 2014 21:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 t5WWcRMtjpgT for ; Sun, 7 Dec 2014 21:41:29 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 78F311A6EFB for ; Sun, 7 Dec 2014 21:41:29 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-50-5484dd97673e Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A6.0B.25146.79DD4845; Mon, 8 Dec 2014 00:07:03 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 00:41:27 -0500 From: Gregory Mirsky To: Marc Binderberger , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAVyAD//64rAA== Date: Mon, 8 Dec 2014 05:41:27 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE6CF@eusaamb103.ericsson.se> References: <20141207193610211284.1f098741@sniff.de> <20141207212102448099.e2e4012a@sniff.de> In-Reply-To: <20141207212102448099.e2e4012a@sniff.de> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPuO70uy0hBuuPSVhcntTGbjH7yn9m i89/tjE6MHvsnHWX3WPJkp9MHq2ru1kCmKO4bFJSczLLUov07RK4Mna+WMNecFS4Yt2sDWwN jIf4uxg5OSQETCQu9d1ihbDFJC7cW8/WxcjFISRwhFGi4+1SZghnGaPE/kUzGUGq2ASMJF5s 7GEHsUUEvCWmvnzLAmIzC2hKNJ34DBYXFjCUWNW9GKrGSOLYjLlQtpPEjjXP2EBsFgEViTfr Z4P18gr4Svw6+J8JYlkXq8TWT9PAGjgFTCUenfwJZjMCnff91BomiGXiEreezGeCOFtAYsme 88wQtqjEy8f/oN5Rkvj4ez47RL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMXKUFqeW5aYbGW5iBEbPMQk2xx2MCz5ZHmIU4GBU4uHdsLglRIg1say4MvcQ ozQHi5I4r2b1vGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjB69gXcrHE9Vn5gkuTHsk5xk zY/Kfx4bZ8dmdR28qfR82TWT8o2Vt9yKXj3bu1T81YSd+qY7mP9aO1ksLi0JitKb8ba0JuBF 4XSuOQWlVcF8si9Pr7jFYRRwzOiy9NwyCzb7Z6YTZ7huufCvXYvR20Nv9ZTZl9kqpC+WBiyI OaHJbDpN44B/qxJLcUaioRZzUXEiAIiO+u9/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Nlrc9MpSmj0em_dkZB2-5bRdw14 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 05:41:31 -0000 Hi Marc, regarding your concern on ensuring that BFD Echo reply traverses the same c= onstituent link as crossed by corresponding BFD Echo request , if it is ind= eed the requirement, I'll refer to revision of IEEE-802.1AX-REV in its part= related to conversation-sensitive frame collection and distribution. Alter= natively, we may realize the RFC 7130 needs an update that introduces or ex= plains behavior of micro-BFD Echo over LAG. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderber= ger Sent: Monday, December 08, 2014 1:21 PM To: Manav Bhatia Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hello Manav, > For the echo mechanism to work, do you agree that you would have to=20 > continuously send Echos so that you can detect the issue? that's what I had in mind, yes > Or are you suggesting that once BFD flaps we will start sending Echoes=20 > overloaded with debug information to detect the issue? interesting idea - that would be an alternative use, collecting forensic da= ta. Maybe we should support that too! My biggest problem with the echo idea is so far BFD-over-LAG. But maybe it = is=20 not a real problem, any echo stamping/updating in the forwarding path would= =20 require an hardware update (or reprogramming, if your hardware allows) and = in=20 this case one could boldly state that the echo packet must leave via the=20 ingress port :-) Regards, Marc On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote: > Hi Marc, >=20 >>=20 >>=20 >> * Greg's echo idea is of course do-able - when you think timestamping in >> hardware can be done then it can be done in the forwarding path for echo= s=20 >> as >> well. Depends on your hardware :-) and on an agreed (minimal) format for >> echo. As mentioned BFD echo is not defined/used for multiple BFD feature= s, >> which limits it's use though. >>=20 >=20 > For the echo mechanism to work, do you agree that you would have to=20 > continuously send Echos so that you can detect the issue? >=20 > Or are you suggesting that once BFD flaps we will start sending Echoes=20 > overloaded with debug information to detect the issue? >=20 > I'd like to understand this before the mailing list sees a barrage of=20 > emails. Alternatively, we can also take it offline and only report the=20 > summary of our discussion to the list. >=20 > Cheers, Manav From nobody Sun Dec 7 21:43:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3B71A6F13 for ; Sun, 7 Dec 2014 21:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 hFw42U4Hqquz for ; Sun, 7 Dec 2014 21:42:48 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141D31A6EFB for ; Sun, 7 Dec 2014 21:42:48 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id va2so3023441obc.8 for ; Sun, 07 Dec 2014 21:42:47 -0800 (PST) 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:content-type; bh=tHkeQekcwSqew3uqTWuEBwKPSyqrrNC7IBHIkvR6DxA=; b=pjWkx58pcUq9SCQHrHsuQUL01Ec+P/PWqJFMXkaPYfBRLXeNLKdNgp2oUU66T8e6t8 J3TAtsYr9ploMrv8WGhmtR4zedDpU8xKm1xU+wqR7TBV1kJgxbgkG7BaRr+Un/MYyR/j MttJywKNDKH7t+lKGn8LYXfarwJTNz0nN6K09N2UdMXgRAD4H3W0tyXcJurV3qOuORBd UMKKjSTkffQ4ykky1+GvPfDVmz5ytyNtzE+T6idHO9FSm33bdWYpucuiUFyNA/3yBzNX DYMN3BrPMitb1hlQnaPmhKzr8DFbW3qkVVRGvBe/qlHcIBcN1Wna7HWK7oyGTuOsA4Lj pHLA== MIME-Version: 1.0 X-Received: by 10.202.80.21 with SMTP id e21mr5835235oib.65.1418017367399; Sun, 07 Dec 2014 21:42:47 -0800 (PST) Received: by 10.76.178.199 with HTTP; Sun, 7 Dec 2014 21:42:47 -0800 (PST) In-Reply-To: <20141207212102448099.e2e4012a@sniff.de> References: <20141207193610211284.1f098741@sniff.de> <20141207212102448099.e2e4012a@sniff.de> Date: Mon, 8 Dec 2014 11:12:47 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Marc Binderberger Content-Type: multipart/alternative; boundary=001a113d8408782bc90509ade508 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Bp33i79Z30UbQwU_fYwGFAZLKvs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 05:42:56 -0000 --001a113d8408782bc90509ade508 Content-Type: text/plain; charset=UTF-8 > > Hi Marc, > > > For the echo mechanism to work, do you agree that you would have to > > continuously send Echos so that you can detect the issue? > > that's what I had in mind, yes > .. and i dont like this. Are you saying that for each BFD session now you will run a parallel BFD echo session that would carry the debug data? Your scaling just went for a toss !! > > > Or are you suggesting that once BFD flaps we will start sending Echoes > > overloaded with debug information to detect the issue? > > interesting idea - that would be an alternative use, collecting forensic > data. Maybe we should support that too! > This would help if the flap is deterministic-ally reproducible. If its not, then how long do you run the Echo BFD? And what happens to the original BFD session? You run the two parallel-ly? Cheers, Manav > > My biggest problem with the echo idea is so far BFD-over-LAG. But maybe it > is > not a real problem, any echo stamping/updating in the forwarding path would > require an hardware update (or reprogramming, if your hardware allows) and > in > this case one could boldly state that the echo packet must leave via the > ingress port :-) > > > Regards, Marc > > > > > > On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote: > > Hi Marc, > > > >> > >> > >> * Greg's echo idea is of course do-able - when you think timestamping in > >> hardware can be done then it can be done in the forwarding path for > echos > >> as > >> well. Depends on your hardware :-) and on an agreed (minimal) format for > >> echo. As mentioned BFD echo is not defined/used for multiple BFD > features, > >> which limits it's use though. > >> > > > > For the echo mechanism to work, do you agree that you would have to > > continuously send Echos so that you can detect the issue? > > > > Or are you suggesting that once BFD flaps we will start sending Echoes > > overloaded with debug information to detect the issue? > > > > I'd like to understand this before the mailing list sees a barrage of > > emails. Alternatively, we can also take it offline and only report the > > summary of our discussion to the list. > > > > Cheers, Manav > --001a113d8408782bc90509ade508 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marc,
=C2=A0
> For the echo mechanism to work, do you agree that you would have to > continuously send Echos so that you can detect the issue?

that's what I had in mind, yes

.. and i dont like this. Are you saying that for each BFD session now yo= u will run a parallel BFD echo session that would carry the debug data? You= r scaling just went for a toss !!



> Or are you suggesting that once BFD flaps we will start sending Echoes=
> overloaded with debug information to detect the issue?

interesting idea - that would be an alternative use, collecting fore= nsic
data. Maybe we should support that too!

This would help if the flap is deterministic-ally reproducible. If its not= , then how long do you run the Echo BFD? And what happens to the original B= FD session? You run the two parallel-ly?

Cheers, M= anav



My biggest problem with the echo idea is so far BFD-over-LAG. But maybe it = is
not a real problem, any echo stamping/updating in the forwarding path would=
require an hardware update (or reprogramming, if your hardware allows) and = in
this case one could boldly state that the echo packet must leave via the ingress port :-)


Regards, Marc





On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote:
> Hi Marc,
>
>>
>>
>> * Greg's echo idea is of course do-able - when you think times= tamping in
>> hardware can be done then it can be done in the forwarding path fo= r echos
>> as
>> well. Depends on your hardware :-) and on an agreed (minimal) form= at for
>> echo. As mentioned BFD echo is not defined/used for multiple BFD f= eatures,
>> which limits it's use though.
>>
>
> For the echo mechanism to work, do you agree that you would have to > continuously send Echos so that you can detect the issue?
>
> Or are you suggesting that once BFD flaps we will start sending Echoes=
> overloaded with debug information to detect the issue?
>
> I'd like to understand this before the mailing list sees a barrage= of
> emails. Alternatively, we can also take it offline and only report the=
> summary of our discussion to the list.
>
> Cheers, Manav

--001a113d8408782bc90509ade508-- From nobody Sun Dec 7 21:46:12 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F281A6F17 for ; Sun, 7 Dec 2014 21:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 qEHo8d0rSB8L for ; Sun, 7 Dec 2014 21:46:09 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 428161A6EFB for ; Sun, 7 Dec 2014 21:46:09 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-7a-5484deae2925 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 42.1B.25146.EAED4845; Mon, 8 Dec 2014 00:11:43 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 00:46:07 -0500 From: Gregory Mirsky To: Marc Binderberger Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAVyAD//7KYYA== Date: Mon, 8 Dec 2014 05:46:07 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE6E8@eusaamb103.ericsson.se> References: <20141207193610211284.1f098741@sniff.de> <20141207212102448099.e2e4012a@sniff.de> In-Reply-To: <20141207212102448099.e2e4012a@sniff.de> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXSPt+76ey0hBsen8lrMvvKf2eLzn22M DkweS5b8ZPJoXd3NEsAUxWWTkpqTWZZapG+XwJVx+uJKpoK3ghXPpr5kaWDs5Oti5OSQEDCR 2Ll8PhuELSZx4d56IJuLQ0jgCKNE55pXjBDOMkaJ1bsXsoNUsQkYSbzY2ANmiwioStx9fYgR xGYW0JRoOvEZLC4sYCixqnsxVI2RxLEZc6FsJ4ndc/aB1bMIqEjs2NHDAmLzCvhKTNw+nxli WRerxNZP08AaOAVMJR6d/AlmMwKd9/3UGiaIZeISt57MZ4I4W0BiyZ7zzBC2qMTLx/9YIWwl iY+/57ND1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUVI0dp cWpZbrqR4SZGYKQck2Bz3MG44JPlIUYBDkYlHt4Ni1tChFgTy4orcw8xSnOwKInzalbPCxYS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaH5I8MdCznxm8/WfPT+Ke974YmI9+excr9+7l+05 K7pMYXp0GmPK6xSxP31buDtXik9OetFSl/+oXCKVa1mHLf+Oc02uO5wWf1nf/5a1/YNHxDKe fbNTVTe3vCzbsUI+qlVm7WOR4qqkC7PM2DaYGgT2aB+s3PGVSeJ1BpdgZpLhUQemdKFrSizF GYmGWsxFxYkAFvtoGnUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2RlRs_WCRrnzNZfk1guxYYKBCt8 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 05:46:10 -0000 Hi Marc, missed to add note on my intention of use of BFD Echo. I think of it as on-demand mechanism only, not proactive. Thus it would mos= t likely be invoked to investigate BFD sessions that already failed or unst= able. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderber= ger Sent: Monday, December 08, 2014 1:21 PM To: Manav Bhatia Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hello Manav, > For the echo mechanism to work, do you agree that you would have to=20 > continuously send Echos so that you can detect the issue? that's what I had in mind, yes > Or are you suggesting that once BFD flaps we will start sending Echoes=20 > overloaded with debug information to detect the issue? interesting idea - that would be an alternative use, collecting forensic da= ta. Maybe we should support that too! My biggest problem with the echo idea is so far BFD-over-LAG. But maybe it = is=20 not a real problem, any echo stamping/updating in the forwarding path would= =20 require an hardware update (or reprogramming, if your hardware allows) and = in=20 this case one could boldly state that the echo packet must leave via the=20 ingress port :-) Regards, Marc On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote: > Hi Marc, >=20 >>=20 >>=20 >> * Greg's echo idea is of course do-able - when you think timestamping in >> hardware can be done then it can be done in the forwarding path for echo= s=20 >> as >> well. Depends on your hardware :-) and on an agreed (minimal) format for >> echo. As mentioned BFD echo is not defined/used for multiple BFD feature= s, >> which limits it's use though. >>=20 >=20 > For the echo mechanism to work, do you agree that you would have to=20 > continuously send Echos so that you can detect the issue? >=20 > Or are you suggesting that once BFD flaps we will start sending Echoes=20 > overloaded with debug information to detect the issue? >=20 > I'd like to understand this before the mailing list sees a barrage of=20 > emails. Alternatively, we can also take it offline and only report the=20 > summary of our discussion to the list. >=20 > Cheers, Manav From nobody Sun Dec 7 22:07:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237D71A6F3A for ; Sun, 7 Dec 2014 22:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 X2Y_yy1s1dto for ; Sun, 7 Dec 2014 22:07:20 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD571A6F17 for ; Sun, 7 Dec 2014 22:07:20 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) with Microsoft SMTP Server (TLS) id 15.1.31.17; Mon, 8 Dec 2014 06:07:19 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0031.000; Mon, 8 Dec 2014 06:07:19 +0000 From: Santosh P K To: Manav Bhatia , Marc Binderberger Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuCAAAvZAIAF49GAgANl6hCAAHr8gIAAli8QgAAGoICAAFQ5AIAACCOwgAABWQCAAABdwIAAJGiAgAAOuoCAAAYAAIAAAhWAgAWECgCAAAeFgIAAIe5A Date: Mon, 8 Dec 2014 06:07:18 +0000 Message-ID: References: <20141207193610211284.1f098741@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-forefront-prvs: 041963B986 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(106116001)(68736005)(105586002)(4396001)(77096005)(122556002)(92566001)(102836002)(15975445007)(19625215002)(86362001)(76576001)(99286002)(16236675004)(87936001)(46102003)(40100003)(54356999)(33656002)(31966008)(19580405001)(76176999)(50986999)(99396003)(2656002)(66066001)(74316001)(64706001)(54206007)(54606007)(21056001)(101416001)(106356001)(20776003)(19580395003)(77156002)(107046002)(120916001)(19300405004)(97736003)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB823; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CO2PR0501MB823962B235ACA590C076236B3640CO2PR0501MB823na_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uENQHU77fp0duCkDKodmMchr9Os Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:07:24 -0000 --_000_CO2PR0501MB823962B235ACA590C076236B3640CO2PR0501MB823na_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTWFjIGFuZCBNYW5hdiwNCiAgICAgQXJlIHdlIGp1c3QgdGFsa2luZyBhYm91dCBzaW5n bGVob3A/IEhvdyBhYm91dCBNUExTIEJGRCBhbmQgbXVsdGlob3Agd2hlcmUgZWNobyBkb2VzIG5v dCB3b3JrPw0KDQpUaGFua3MNClNhbnRvc2ggUCBLDQoNCkZyb206IFJ0Zy1iZmQgW21haWx0bzpy dGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5hdiBCaGF0aWENClNlbnQ6 IE1vbmRheSwgRGVjZW1iZXIgMDgsIDIwMTQgOTozMyBBTQ0KVG86IE1hcmMgQmluZGVyYmVyZ2Vy DQpDYzogcnRnLWJmZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IEJGRCBzdGFiaWxpdHkgZm9sbG93 LXVwIGZyb20gSUVURi05MQ0KDQpIaSBNYXJjLA0KDQoNCg0KKiBHcmVnJ3MgZWNobyBpZGVhIGlz IG9mIGNvdXJzZSBkby1hYmxlIC0gd2hlbiB5b3UgdGhpbmsgdGltZXN0YW1waW5nIGluDQpoYXJk d2FyZSBjYW4gYmUgZG9uZSB0aGVuIGl0IGNhbiBiZSBkb25lIGluIHRoZSBmb3J3YXJkaW5nIHBh dGggZm9yIGVjaG9zIGFzDQp3ZWxsLiBEZXBlbmRzIG9uIHlvdXIgaGFyZHdhcmUgOi0pIGFuZCBv biBhbiBhZ3JlZWQgKG1pbmltYWwpIGZvcm1hdCBmb3INCmVjaG8uIEFzIG1lbnRpb25lZCBCRkQg ZWNobyBpcyBub3QgZGVmaW5lZC91c2VkIGZvciBtdWx0aXBsZSBCRkQgZmVhdHVyZXMsDQp3aGlj aCBsaW1pdHMgaXQncyB1c2UgdGhvdWdoLg0KDQpGb3IgdGhlIGVjaG8gbWVjaGFuaXNtIHRvIHdv cmssIGRvIHlvdSBhZ3JlZSB0aGF0IHlvdSB3b3VsZCBoYXZlIHRvIGNvbnRpbnVvdXNseSBzZW5k IEVjaG9zIHNvIHRoYXQgeW91IGNhbiBkZXRlY3QgdGhlIGlzc3VlPw0KDQpPciBhcmUgeW91IHN1 Z2dlc3RpbmcgdGhhdCBvbmNlIEJGRCBmbGFwcyB3ZSB3aWxsIHN0YXJ0IHNlbmRpbmcgRWNob2Vz IG92ZXJsb2FkZWQgd2l0aCBkZWJ1ZyBpbmZvcm1hdGlvbiB0byBkZXRlY3QgdGhlIGlzc3VlPw0K DQpJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIHRoaXMgYmVmb3JlIHRoZSBtYWlsaW5nIGxpc3Qgc2Vl cyBhIGJhcnJhZ2Ugb2YgZW1haWxzLiBBbHRlcm5hdGl2ZWx5LCB3ZSBjYW4gYWxzbyB0YWtlIGl0 IG9mZmxpbmUgYW5kIG9ubHkgcmVwb3J0IHRoZSBzdW1tYXJ5IG9mIG91ciBkaXNjdXNzaW9uIHRv IHRoZSBsaXN0Lg0KDQpDaGVlcnMsIE1hbmF2DQo= --_000_CO2PR0501MB823962B235ACA590C076236B3640CO2PR0501MB823na_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGVsbG8gTWFjIGFuZCBNYW5h diw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFyZSB3ZSBqdXN0 IHRhbGtpbmcgYWJvdXQgc2luZ2xlaG9wPyBIb3cgYWJvdXQgTVBMUyBCRkQgYW5kIG11bHRpaG9w IHdoZXJlIGVjaG8gZG9lcyBub3Qgd29yaz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TYW50b3NoIFAgSw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+TWFuYXYgQmhhdGlhPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRGVjZW1i ZXIgMDgsIDIwMTQgOTozMyBBTTxicj4NCjxiPlRvOjwvYj4gTWFyYyBCaW5kZXJiZXJnZXI8YnI+ DQo8Yj5DYzo8L2I+IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEJG RCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNYXJjLDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCiogR3JlZydzIGVjaG8gaWRlYSBpcyBv ZiBjb3Vyc2UgZG8tYWJsZSAtIHdoZW4geW91IHRoaW5rIHRpbWVzdGFtcGluZyBpbjxicj4NCmhh cmR3YXJlIGNhbiBiZSBkb25lIHRoZW4gaXQgY2FuIGJlIGRvbmUgaW4gdGhlIGZvcndhcmRpbmcg cGF0aCBmb3IgZWNob3MgYXM8YnI+DQp3ZWxsLiBEZXBlbmRzIG9uIHlvdXIgaGFyZHdhcmUgOi0p IGFuZCBvbiBhbiBhZ3JlZWQgKG1pbmltYWwpIGZvcm1hdCBmb3I8YnI+DQplY2hvLiBBcyBtZW50 aW9uZWQgQkZEIGVjaG8gaXMgbm90IGRlZmluZWQvdXNlZCBmb3IgbXVsdGlwbGUgQkZEIGZlYXR1 cmVzLDxicj4NCndoaWNoIGxpbWl0cyBpdCdzIHVzZSB0aG91Z2guPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhlIGVjaG8g bWVjaGFuaXNtIHRvIHdvcmssIGRvIHlvdSBhZ3JlZSB0aGF0IHlvdSB3b3VsZCBoYXZlIHRvIGNv bnRpbnVvdXNseSBzZW5kIEVjaG9zIHNvIHRoYXQgeW91IGNhbiBkZXRlY3QgdGhlIGlzc3VlPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PciBh cmUgeW91IHN1Z2dlc3RpbmcgdGhhdCBvbmNlIEJGRCBmbGFwcyB3ZSB3aWxsIHN0YXJ0IHNlbmRp bmcgRWNob2VzIG92ZXJsb2FkZWQgd2l0aCBkZWJ1ZyBpbmZvcm1hdGlvbiB0byBkZXRlY3QgdGhl IGlzc3VlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JJ2QgbGlrZSB0byB1bmRlcnN0YW5kIHRoaXMgYmVmb3JlIHRoZSBtYWlsaW5nIGxpc3Qg c2VlcyBhIGJhcnJhZ2Ugb2YgZW1haWxzLiBBbHRlcm5hdGl2ZWx5LCB3ZSBjYW4gYWxzbyB0YWtl IGl0IG9mZmxpbmUgYW5kIG9ubHkgcmVwb3J0IHRoZSBzdW1tYXJ5IG9mIG91ciBkaXNjdXNzaW9u IHRvIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DaGVlcnMsIE1hbmF2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CO2PR0501MB823962B235ACA590C076236B3640CO2PR0501MB823na_-- From nobody Sun Dec 7 22:13:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A11F1A1B68 for ; Sun, 7 Dec 2014 22:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 QUzLexIcRlD8 for ; Sun, 7 Dec 2014 22:13:09 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AAF31A6F22 for ; Sun, 7 Dec 2014 22:13:09 -0800 (PST) Received: by mail-oi0-f50.google.com with SMTP id a141so2911210oig.37 for ; Sun, 07 Dec 2014 22:13:08 -0800 (PST) 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:content-type; bh=a4TyomLxEN98J01natgjM9YNCpXvfY4AI0zLmLoogIc=; b=ExIR5KseO9P2WFAG6qZ1AW7yQf6jaI8MQkDw45y4uyu2tfYU0xXLo7pf9OlxrkGla2 Il/C78K1XH1V2llfqfsS99/Pa3olI62Dq8n9xthiUL2OtL+MAZPs7+Uy+R2uvnL/jYxo JPZFmX5c9VQ9WNuUkunYGMVMuy/IWprrRZTxvB7fuIQZHfWhPP5tCmW2oOIi2H+XSqZD yyhaySoB0MhMJshsRRD2IQxklEqSrNvADCC370tCiClB2oAf0heuUz+jv+2gWAwyf5IY 9kr0waveL/Yrb/KnqOAENkwSvrDWQDei7pa4cGhfZPkK/qB9FKCnslB/ZGRuEZ6opG6x UjqQ== MIME-Version: 1.0 X-Received: by 10.60.65.99 with SMTP id w3mr6546722oes.6.1418019188710; Sun, 07 Dec 2014 22:13:08 -0800 (PST) Received: by 10.76.178.199 with HTTP; Sun, 7 Dec 2014 22:13:08 -0800 (PST) In-Reply-To: References: <20141207193610211284.1f098741@sniff.de> Date: Mon, 8 Dec 2014 11:43:08 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Santosh P K Content-Type: multipart/alternative; boundary=001a11c24a320723730509ae5258 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Seb2Ys6obgB3IfwY_fHcxgeAnwg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:13:11 -0000 --001a11c24a320723730509ae5258 Content-Type: text/plain; charset=UTF-8 Cool. I had multihop in my mind. Cheers, Manav On Mon, Dec 8, 2014 at 11:37 AM, Santosh P K wrote: > Hello Mac and Manav, > > Are we just talking about singlehop? How about MPLS BFD and multihop > where echo does not work? > > > > Thanks > > Santosh P K > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Manav > Bhatia > *Sent:* Monday, December 08, 2014 9:33 AM > *To:* Marc Binderberger > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Hi Marc, > > > > > > * Greg's echo idea is of course do-able - when you think timestamping in > hardware can be done then it can be done in the forwarding path for echos > as > well. Depends on your hardware :-) and on an agreed (minimal) format for > echo. As mentioned BFD echo is not defined/used for multiple BFD features, > which limits it's use though. > > > > For the echo mechanism to work, do you agree that you would have to > continuously send Echos so that you can detect the issue? > > > > Or are you suggesting that once BFD flaps we will start sending Echoes > overloaded with debug information to detect the issue? > > > > I'd like to understand this before the mailing list sees a barrage of > emails. Alternatively, we can also take it offline and only report the > summary of our discussion to the list. > > > > Cheers, Manav > --001a11c24a320723730509ae5258 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cool. I had multihop in my mind.

Cheers= , Manav

On Mon, Dec 8, 2014 at 11:37 AM, Santosh P K <santoshpk@juniper.net<= /a>> wrote:

Hello Mac and Manav,

=C2=A0=C2=A0=C2=A0=C2=A0 Are we just = talking about singlehop? How about MPLS BFD and multihop where echo does no= t work?

=C2=A0

Thanks

Santosh P K

=C2=A0

=C2=A0

Hi Marc,

=C2=A0



* Greg's echo idea is of course do-able - when you think timestamping i= n
hardware can be done then it can be done in the forwarding path for echos a= s
well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features,<= br> which limits it's use though.

=C2=A0

For the echo mechanism to work, do you agree that yo= u would have to continuously send Echos so that you can detect the issue?

=C2=A0

Or are you suggesting that once BFD flaps we will st= art sending Echoes overloaded with debug information to detect the issue?

=C2=A0

I'd like to understand this before the mailing l= ist sees a barrage of emails. Alternatively, we can also take it offline an= d only report the summary of our discussion to the list.

=C2=A0

Cheers, Manav


--001a11c24a320723730509ae5258-- From nobody Sun Dec 7 22:22:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3C71A6F13 for ; Sun, 7 Dec 2014 22:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 LBktMTs5EwMr for ; Sun, 7 Dec 2014 22:22:39 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 BC8CB1A6F3A for ; Sun, 7 Dec 2014 22:22:38 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-08-5484f369d583 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E6.4B.03307.963F4845; Mon, 8 Dec 2014 01:40:10 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 01:22:37 -0500 From: Gregory Mirsky To: Santosh P K , Manav Bhatia , Marc Binderberger Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAitQD//66CwA== Date: Mon, 8 Dec 2014 06:22:36 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE751@eusaamb103.ericsson.se> References: <20141207193610211284.1f098741@sniff.de> 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_7347100B5761DC41A166AC17F22DF1121B8AE751eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZXLonRDfrc0uIwTo9i8uT2tgtZl/5z2zx +c82Rotrd7cyO7B47Jx1l91jyZKfTB7Xm66ye7Su7mYJYInisklJzcksSy3St0vgynjX8Jqt YE1Oxe+e98wNjFsyuxg5OCQETCRWn0vrYuQEMsUkLtxbz9bFyMUhJHCEUaLj5HwmCGcZo8Sy s+3MIFVsAkYSLzb2sIM0iwgUSVzbFQISZhbQlGg68ZkdxBYWMJRY1b0YzBYBKj82Yy6U7SRx +dtBsDEsAioSXa0f2UBsXgFfidf/3rCA2EICW1glNhzjA7E5BeIlLj14DVbPCHTc91NrmCB2 iUvcejKfCeJoAYkle84zQ9iiEi8f/2OFsJUkPv6ezw5Rny/xZvYLRohdghInZz5hmcAoOgvJ qFlIymYhKZsF9CXIa+t36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0VI0dpcWpZbrqRwSZGYNwd k2DT3cG456XlIUYBDkYlHt4Ni1tChFgTy4orcw8xSnOwKInzzqqdFywkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qBMftVhtxU9gMvu6cvlM4IY4581cTAaS2XvXLGlPclekHXN3jM+BNXvfNA xJF/S9r0L87hPBynt/9gXOn14n05+Zt+MtUcFPvzx8xG8lN73IIGL/4X7014dm8UVNlxWHqa hc6jva7tz205isQWBm47sTzBqCt11/HzKRKK5j9n7jwS8fDG4h8/tiixFGckGmoxFxUnAgA0 vuz/nAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Gv6DmzE5hTM0cxZg2miXgmE9bSk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:22:41 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AE751eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FudG9zaCwNCmRvIHlvdSBlbnZpc2lvbiBzY2VuYXJpbyB3aGVuIEJGRCBtdWx0aS1ob3Ag YW5kIHNpbmdsZS1ob3Agc2Vzc2lvbnMgdGhhdCBzaGFyZSB0aGUgc2FtZSBzZW5kZXIgYmVoYXZl IGRpZmZlcmVudGx5PyBJbiBteSBvcGluaW9uLCBpZiBtdWx0aS1ob3Agc2Vzc2lvbiBpcyB1bnN0 YWJsZSBhbmQgc2luZ2xlLWhvcCBpcyBzdGFibGUsIHRoZW4gdGhlIHByb2JsZW0gaXMgbGlrZWx5 IGluIHRoZSBuZXR3b3JrIGFuZCB0aHVzIGlzIHJlYWwsIHJhdGhlciB0aGFuIGluIHRoZSBCRkQg c2VuZGVyIGFuZCBtb3JlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiBUaHVzIHJ1bm5pbmcgQkZE IEVjaG8gZXZlbiB3aXRob3V0IGNvb3BlcmF0aW9uIG9mIHRoZSBuZXh0IGhvcCBub2RlIChubyB0 aW1lc3RhbXBzIHRoZXJlKSB3b3VsZCBnaXZlIHNlbmRlciBpbmZvcm1hdGlvbiBhYm91dCBsYXRl bmNpZXMgQkZEIGlzIHN1YmplY3RlZCB0byBpbiB0aGlzIG5vZGUuDQoNCiAgICAgICAgICAgICAg ICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206 IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBT YW50b3NoIFAgSw0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAwOCwgMjAxNCAyOjA3IFBNDQpUbzog TWFuYXYgQmhhdGlhOyBNYXJjIEJpbmRlcmJlcmdlcg0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1 YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGVsbG8g TWFjIGFuZCBNYW5hdiwNCiAgICAgQXJlIHdlIGp1c3QgdGFsa2luZyBhYm91dCBzaW5nbGVob3A/ IEhvdyBhYm91dCBNUExTIEJGRCBhbmQgbXVsdGlob3Agd2hlcmUgZWNobyBkb2VzIG5vdCB3b3Jr Pw0KDQpUaGFua3MNClNhbnRvc2ggUCBLDQoNCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5hdiBCaGF0aWENClNlbnQ6IE1vbmRh eSwgRGVjZW1iZXIgMDgsIDIwMTQgOTozMyBBTQ0KVG86IE1hcmMgQmluZGVyYmVyZ2VyDQpDYzog cnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBC RkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGkgTWFyYywNCg0KDQoNCiog R3JlZydzIGVjaG8gaWRlYSBpcyBvZiBjb3Vyc2UgZG8tYWJsZSAtIHdoZW4geW91IHRoaW5rIHRp bWVzdGFtcGluZyBpbg0KaGFyZHdhcmUgY2FuIGJlIGRvbmUgdGhlbiBpdCBjYW4gYmUgZG9uZSBp biB0aGUgZm9yd2FyZGluZyBwYXRoIGZvciBlY2hvcyBhcw0Kd2VsbC4gRGVwZW5kcyBvbiB5b3Vy IGhhcmR3YXJlIDotKSBhbmQgb24gYW4gYWdyZWVkIChtaW5pbWFsKSBmb3JtYXQgZm9yDQplY2hv LiBBcyBtZW50aW9uZWQgQkZEIGVjaG8gaXMgbm90IGRlZmluZWQvdXNlZCBmb3IgbXVsdGlwbGUg QkZEIGZlYXR1cmVzLA0Kd2hpY2ggbGltaXRzIGl0J3MgdXNlIHRob3VnaC4NCg0KRm9yIHRoZSBl Y2hvIG1lY2hhbmlzbSB0byB3b3JrLCBkbyB5b3UgYWdyZWUgdGhhdCB5b3Ugd291bGQgaGF2ZSB0 byBjb250aW51b3VzbHkgc2VuZCBFY2hvcyBzbyB0aGF0IHlvdSBjYW4gZGV0ZWN0IHRoZSBpc3N1 ZT8NCg0KT3IgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgb25jZSBCRkQgZmxhcHMgd2Ugd2lsbCBz dGFydCBzZW5kaW5nIEVjaG9lcyBvdmVybG9hZGVkIHdpdGggZGVidWcgaW5mb3JtYXRpb24gdG8g ZGV0ZWN0IHRoZSBpc3N1ZT8NCg0KSSdkIGxpa2UgdG8gdW5kZXJzdGFuZCB0aGlzIGJlZm9yZSB0 aGUgbWFpbGluZyBsaXN0IHNlZXMgYSBiYXJyYWdlIG9mIGVtYWlscy4gQWx0ZXJuYXRpdmVseSwg d2UgY2FuIGFsc28gdGFrZSBpdCBvZmZsaW5lIGFuZCBvbmx5IHJlcG9ydCB0aGUgc3VtbWFyeSBv ZiBvdXIgZGlzY3Vzc2lvbiB0byB0aGUgbGlzdC4NCg0KQ2hlZXJzLCBNYW5hdg0K --_000_7347100B5761DC41A166AC17F22DF1121B8AE751eusaamb103erics_ 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 IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1 NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG NzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBTYW50b3NoLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5kbyB5b3UgZW52aXNpb24gc2NlbmFyaW8gd2hlbiBC RkQgbXVsdGktaG9wIGFuZCBzaW5nbGUtaG9wIHNlc3Npb25zIHRoYXQgc2hhcmUgdGhlIHNhbWUg c2VuZGVyIGJlaGF2ZSBkaWZmZXJlbnRseT8gSW4gbXkgb3BpbmlvbiwgaWYgbXVsdGktaG9wIHNl c3Npb24gaXMgdW5zdGFibGUNCiBhbmQgc2luZ2xlLWhvcCBpcyBzdGFibGUsIHRoZW4gdGhlIHBy b2JsZW0gaXMgbGlrZWx5IGluIHRoZSBuZXR3b3JrIGFuZCB0aHVzIGlzIHJlYWwsIHJhdGhlciB0 aGFuIGluIHRoZSBCRkQgc2VuZGVyIGFuZCBtb3JlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiBU aHVzIHJ1bm5pbmcgQkZEIEVjaG8gZXZlbiB3aXRob3V0IGNvb3BlcmF0aW9uIG9mIHRoZSBuZXh0 IGhvcCBub2RlIChubyB0aW1lc3RhbXBzIHRoZXJlKSB3b3VsZCBnaXZlIHNlbmRlcg0KIGluZm9y bWF0aW9uIGFib3V0IGxhdGVuY2llcyBCRkQgaXMgc3ViamVjdGVkIHRvIGluIHRoaXMgbm9kZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPlNhbnRvc2ggUCBLPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRGVj ZW1iZXIgMDgsIDIwMTQgMjowNyBQTTxicj4NCjxiPlRvOjwvYj4gTWFuYXYgQmhhdGlhOyBNYXJj IEJpbmRlcmJlcmdlcjxicj4NCjxiPkNjOjwvYj4gcnRnLWJmZEBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSRTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIE1hYyBhbmQgTWFuYXYsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBcmUgd2UganVz dCB0YWxraW5nIGFib3V0IHNpbmdsZWhvcD8gSG93IGFib3V0IE1QTFMgQkZEIGFuZCBtdWx0aWhv cCB3aGVyZSBlY2hvIGRvZXMgbm90IHdvcms/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+U2FudG9zaCBQIEsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy1iZmQgWzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5NYW5hdiBCaGF0aWE8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBE ZWNlbWJlciAwOCwgMjAxNCA5OjMzIEFNPGJyPg0KPGI+VG86PC9iPiBNYXJjIEJpbmRlcmJlcmdl cjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPnJ0Zy1i ZmRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBCRkQgc3RhYmlsaXR5IGZv bGxvdy11cCBmcm9tIElFVEYtOTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGkgTWFyYyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0K KiBHcmVnJ3MgZWNobyBpZGVhIGlzIG9mIGNvdXJzZSBkby1hYmxlIC0gd2hlbiB5b3UgdGhpbmsg dGltZXN0YW1waW5nIGluPGJyPg0KaGFyZHdhcmUgY2FuIGJlIGRvbmUgdGhlbiBpdCBjYW4gYmUg ZG9uZSBpbiB0aGUgZm9yd2FyZGluZyBwYXRoIGZvciBlY2hvcyBhczxicj4NCndlbGwuIERlcGVu ZHMgb24geW91ciBoYXJkd2FyZSA6LSkgYW5kIG9uIGFuIGFncmVlZCAobWluaW1hbCkgZm9ybWF0 IGZvcjxicj4NCmVjaG8uIEFzIG1lbnRpb25lZCBCRkQgZWNobyBpcyBub3QgZGVmaW5lZC91c2Vk IGZvciBtdWx0aXBsZSBCRkQgZmVhdHVyZXMsPGJyPg0Kd2hpY2ggbGltaXRzIGl0J3MgdXNlIHRo b3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkZvciB0aGUgZWNobyBtZWNoYW5pc20gdG8gd29yaywgZG8geW91IGFncmVlIHRo YXQgeW91IHdvdWxkIGhhdmUgdG8gY29udGludW91c2x5IHNlbmQgRWNob3Mgc28gdGhhdCB5b3Ug Y2FuIGRldGVjdCB0aGUgaXNzdWU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9yIGFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IG9uY2UgQkZEIGZs YXBzIHdlIHdpbGwgc3RhcnQgc2VuZGluZyBFY2hvZXMgb3ZlcmxvYWRlZCB3aXRoIGRlYnVnIGlu Zm9ybWF0aW9uIHRvIGRldGVjdCB0aGUgaXNzdWU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhpcyBi ZWZvcmUgdGhlIG1haWxpbmcgbGlzdCBzZWVzIGEgYmFycmFnZSBvZiBlbWFpbHMuIEFsdGVybmF0 aXZlbHksIHdlIGNhbiBhbHNvIHRha2UgaXQgb2ZmbGluZSBhbmQgb25seSByZXBvcnQgdGhlIHN1 bW1hcnkgb2Ygb3VyIGRpc2N1c3Npb24gdG8gdGhlIGxpc3QuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycywgTWFuYXY8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B8AE751eusaamb103erics_-- From nobody Sun Dec 7 22:26:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C121A6F56 for ; Sun, 7 Dec 2014 22:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 nyJtXJm904m6 for ; Sun, 7 Dec 2014 22:26:45 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5C01A6F51 for ; Sun, 7 Dec 2014 22:26:45 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id wn1so3205317obc.31 for ; Sun, 07 Dec 2014 22:26:44 -0800 (PST) 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:content-type; bh=kuWAeVWuYkkjt73K9lAtZULJLop70m6C+/KbEpYvVlM=; b=FBoOefSR4WTbSLtabZjloE6ccDmHRAq57aBxkTgrKo2HvvvLjiwj4MyQ014M0rPu5A 8q0+iMkE0U/t6ku8tu8kybXMlBkDJOxrDFegp940504+4IxeWMI4z/Z/N51PmlRgusgE ulvwd55HBh9Ig8ZlhguNaiTXQmZzNl2gwhc6Q73f2H+HGYBl+EnoIZ8XvpJiLdl0bQn5 uRA0YOAVvTM+QOKz3i1AK0Cn/y27GhytgFmH/vnpDZETjF9wZ8LysYVdNZCdOFskIy2I zcz3VxDNZepwaNydlyWAHgOEHsS4xl1KzDKzZ5HhLB023QLoqMv8ImCMnETDA36bYMFf oovA== MIME-Version: 1.0 X-Received: by 10.60.146.231 with SMTP id tf7mr6572004oeb.48.1418020004380; Sun, 07 Dec 2014 22:26:44 -0800 (PST) Received: by 10.76.178.199 with HTTP; Sun, 7 Dec 2014 22:26:44 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AE751@eusaamb103.ericsson.se> References: <20141207193610211284.1f098741@sniff.de> <7347100B5761DC41A166AC17F22DF1121B8AE751@eusaamb103.ericsson.se> Date: Mon, 8 Dec 2014 11:56:44 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=047d7b5d341aa5456b0509ae82a6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hAI0OP7hghC9ehA0p5lARzFJovM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:26:47 -0000 --047d7b5d341aa5456b0509ae82a6 Content-Type: text/plain; charset=UTF-8 Hi Greg, What if i dont have a single-hop session? Do you want the operator to set up one between the sender and its immediate next-hop and another between the receiver and its immediate next-hop? Cheers, Manav On Mon, Dec 8, 2014 at 11:52 AM, Gregory Mirsky wrote: > Hi Santosh, > > do you envision scenario when BFD multi-hop and single-hop sessions that > share the same sender behave differently? In my opinion, if multi-hop > session is unstable and single-hop is stable, then the problem is likely in > the network and thus is real, rather than in the BFD sender and more > implementation specific. Thus running BFD Echo even without cooperation of > the next hop node (no timestamps there) would give sender information about > latencies BFD is subjected to in this node. > > > > Regards, > > Greg > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Santosh > P K > *Sent:* Monday, December 08, 2014 2:07 PM > *To:* Manav Bhatia; Marc Binderberger > *Cc:* rtg-bfd@ietf.org > *Subject:* RE: BFD stability follow-up from IETF-91 > > > > Hello Mac and Manav, > > Are we just talking about singlehop? How about MPLS BFD and multihop > where echo does not work? > > > > Thanks > > Santosh P K > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org > ] *On Behalf Of *Manav Bhatia > *Sent:* Monday, December 08, 2014 9:33 AM > *To:* Marc Binderberger > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: BFD stability follow-up from IETF-91 > > > > Hi Marc, > > > > > > * Greg's echo idea is of course do-able - when you think timestamping in > hardware can be done then it can be done in the forwarding path for echos > as > well. Depends on your hardware :-) and on an agreed (minimal) format for > echo. As mentioned BFD echo is not defined/used for multiple BFD features, > which limits it's use though. > > > > For the echo mechanism to work, do you agree that you would have to > continuously send Echos so that you can detect the issue? > > > > Or are you suggesting that once BFD flaps we will start sending Echoes > overloaded with debug information to detect the issue? > > > > I'd like to understand this before the mailing list sees a barrage of > emails. Alternatively, we can also take it offline and only report the > summary of our discussion to the list. > > > > Cheers, Manav > --047d7b5d341aa5456b0509ae82a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

What if i dont have a single-h= op session? Do you want the operator to set up one between the sender and i= ts immediate next-hop and another between the receiver and its immediate ne= xt-hop?

Cheers, Manav

On Mon, Dec 8, 2014 at 11:52 AM, G= regory Mirsky <gregory.mirsky@ericsson.com> wrote:=

Hi Santosh,=

do you envision scenario = when BFD multi-hop and single-hop sessions that share the same sender behav= e differently? In my opinion, if multi-hop session is unstable and single-hop is stable, then the problem is likely in the network and th= us is real, rather than in the BFD sender and more implementation specific.= Thus running BFD Echo even without cooperation of the next hop node (no ti= mestamps there) would give sender information about latencies BFD is subjected to in this node.

=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: Rtg-bfd = [mailto:rtg-b= fd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Monday, December 08, 2014 2:07 PM
To: Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ie= tf.org
Subject: RE: BFD stability follow-up from IETF-91

=C2=A0

Hello Mac and Manav,

=C2=A0=C2=A0=C2=A0=C2=A0 = Are we just talking about singlehop? How about MPLS BFD and multihop where = echo does not work?

=C2=A0

Thanks

Santosh P K

=C2=A0

From: Rtg-bf= d [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Monday, December 08, 2014 9:33 AM
To: Marc Binderberger
Cc: rtg-bfd@ie= tf.org
Subject: Re: BFD stability follow-up from IETF-91

=C2=A0

Hi Marc,

=C2=A0



* Greg's echo idea is of course do-able - when you think timestamping i= n
hardware can be done then it can be done in the forwarding path for echos a= s
well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features,<= br> which limits it's use though.

=C2=A0

For the echo mechanism to work, do you agree that yo= u would have to continuously send Echos so that you can detect the issue?

=C2=A0

Or are you suggesting that once BFD flaps we will st= art sending Echoes overloaded with debug information to detect the issue?

=C2=A0

I'd like to understand this before the mailing l= ist sees a barrage of emails. Alternatively, we can also take it offline an= d only report the summary of our discussion to the list.

=C2=A0

Cheers, Manav


--047d7b5d341aa5456b0509ae82a6-- From nobody Sun Dec 7 22:28:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303B51A6F59 for ; Sun, 7 Dec 2014 22:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 85d0j3XHJB_7 for ; Sun, 7 Dec 2014 22:28:01 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1159E1A6F56 for ; Sun, 7 Dec 2014 22:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13232; q=dns/txt; s=iport; t=1418020081; x=1419229681; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=bBzBFtuuf0satcN7egeFBBydZHY60HEJ0GbIu9Xbwx8=; b=gFKxfoKgSu8SGVyqxxCVpInzUuFr8GPgsfjBsbx3dyz3+Roc7Lmpnj+5 KfUNjM2MdFB9QXiTUOt/C5BUpoN1jtunHDOnQ5WtFuiUKxVeNnxiSOYB/ 40SE4jaQYVXuyOVwE883XL2XbUM6fazzlnueYzwmx89J3808xVOls1Etn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAIlEhVStJV2b/2dsb2JhbABQCoJDQ1JYBMNsiDkCgRwWAQEBAQF9hAIBAQEELUELEgEIEQMBAQEoJgIRFAkIAgQBDQWIJgMSzlwNhXUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjiKBUUsRBgGENgWGGIkuBYgrgWmBIowMgi+DYoNvb4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,536,1413244800"; d="scan'208,217";a="375240095" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 08 Dec 2014 06:28:00 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB86S0W6022819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 06:28:00 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 00:28:00 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: Gregory Mirsky , Santosh P K , Manav Bhatia , "Marc Binderberger" Subject: Re: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6sKG4KnHULdkO3SoZYWD6QxJxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYCAAFQ6AIAACIMAgABdKQD//6S3gIAAI96AgAAOuYCAAAYBAIAAAhWAgAWECQCAAAeGgIAAIrQAgAAERwCAAF25gA== Date: Mon, 8 Dec 2014 06:27:59 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AE751@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.106] Content-Type: multipart/alternative; boundary="_000_D0AB424E28B01mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/LTJE_Mrn7YI_WETJzyGOS5B9XBs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:28:03 -0000 --_000_D0AB424E28B01mmudigonciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Greg, Are we assuming that there is a single node in-between the sender and recei= ver for the multi hop case? The actual problem of packet loss may be happen= ing after the next hop node. Since we don=92t have a way to run echo for mu= lti hop sessions, how do we identify packet losses in such a case if we use= echo? Thanks Regards Mallik From: Gregory Mirsky > Date: Monday, 8 December 2014 11:52 am To: Santosh P K >, Mana= v Bhatia >, Marc Binder= berger > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, do you envision scenario when BFD multi-hop and single-hop sessions that sh= are the same sender behave differently? In my opinion, if multi-hop session= is unstable and single-hop is stable, then the problem is likely in the ne= twork and thus is real, rather than in the BFD sender and more implementati= on specific. Thus running BFD Echo even without cooperation of the next hop= node (no timestamps there) would give sender information about latencies B= FD is subjected to in this node. Regards, Greg From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, December 08, 2014 2:07 PM To: Manav Bhatia; Marc Binderberger Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Mac and Manav, Are we just talking about singlehop? How about MPLS BFD and multihop w= here echo does not work? Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia Sent: Monday, December 08, 2014 9:33 AM To: Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Marc, * Greg's echo idea is of course do-able - when you think timestamping in hardware can be done then it can be done in the forwarding path for echos a= s well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features, which limits it's use though. For the echo mechanism to work, do you agree that you would have to continu= ously send Echos so that you can detect the issue? Or are you suggesting that once BFD flaps we will start sending Echoes over= loaded with debug information to detect the issue? I'd like to understand this before the mailing list sees a barrage of email= s. Alternatively, we can also take it offline and only report the summary o= f our discussion to the list. Cheers, Manav --_000_D0AB424E28B01mmudigonciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5460B5768A41CB4DAB2F9EC48617642D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Greg,

Are we assuming that there is a single node in-between the sender and = receiver for the multi hop case? The actual problem of packet loss may be h= appening after the next hop node. Since we don=92t have a way to run echo f= or multi hop sessions, how do we identify packet losses in such a case if we use echo?

Thanks

Regards
Mallik

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Monday, 8 December 2014 11:52= am
To: Santosh P K <santoshpk@juniper.net>, Manav Bhatia <<= a href=3D"mailto:manavbhatia@gmail.com">manavbhatia@gmail.com>, Marc= Binderberger <marc@sniff.de> Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-u= p from IETF-91

Hi Santosh,

do you envision scenario when BFD m= ulti-hop and single-hop sessions that share the same sender behave differen= tly? In my opinion, if multi-hop session is unstable and single-hop is stable, then the problem is likely in the ne= twork and thus is real, rather than in the BFD sender and more implementati= on specific. Thus running BFD Echo even without cooperation of the next hop= node (no timestamps there) would give sender information about latencies BFD is subjected to in this node.<= o:p>

 

      = ;          Regards,=

      = ;            &n= bsp;            = ; Greg

 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Monday, December 08, 2014 2:07 PM
To: Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up from IETF-91<= /p>

 

Hello Mac and Manav,

     Are we jus= t talking about singlehop? How about MPLS BFD and multihop where echo does = not work?

 

Thanks

Santosh P K

 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Monday, December 08, 2014 9:33 AM
To: Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91<= /p>

 

Hi Marc,

 



* Greg's echo idea is of course do-able - when you think timestamping in hardware can be done then it can be done in the forwarding path for echos a= s
well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features,<= br> which limits it's use though.

 

For the echo mechanism to work, do you agree that yo= u would have to continuously send Echos so that you can detect the issue?

 

Or are you suggesting that once BFD flaps we will st= art sending Echoes overloaded with debug information to detect the issue?

 

I'd like to understand this before the mailing list = sees a barrage of emails. Alternatively, we can also take it offline and on= ly report the summary of our discussion to the list.

 

Cheers, Manav

 --_000_D0AB424E28B01mmudigonciscocom_-- From nobody Sun Dec 7 22:34:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD6F1A6F62 for ; Sun, 7 Dec 2014 22:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 RrADWTYXgK6M for ; Sun, 7 Dec 2014 22:34:11 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 401761A6F61 for ; Sun, 7 Dec 2014 22:34:11 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-52-5484f61e10c1 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 49.5B.03307.E16F4845; Mon, 8 Dec 2014 01:51:42 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 01:34:09 -0500 From: Gregory Mirsky To: "MALLIK MUDIGONDA (mmudigon)" , Santosh P K , Manav Bhatia , "Marc Binderberger" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAitQD//66CwIAAV0WA//+sX/A= Date: Mon, 8 Dec 2014 06:34:09 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE76E@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B8AE751@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_7347100B5761DC41A166AC17F22DF1121B8AE76Eeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXSPn67ct5YQg28H5SwuT2pjt5h95T+z xZFXx5gtPv/Zxmhx7e5WZgdWjym/N7J67Jx1l91jyZKfTB7Xm66ye7Su7mYJYI3isklJzcks Sy3St0vgytj1czdzQc9kxoqnn/tZGxinNDF2MXJySAiYSMx/v4AZwhaTuHBvPVsXIxeHkMAR RokZ52+zgiSEBJYxSjztVwex2QSMJF5s7GEHKRIRWMUosWD/VyaQBLOApkTTic/sILawgKHE qu7FYLYIUMOxGXOBbA4g20+iYzVYOYuAisTs9l1gR/AK+Er8mzuFBWJXscSNI3fBWjkFDCR2 7lsKdgMj0HHfT62BWiUucevJfCaIowUkluw5D/WAqMTLx/9YIWwliY+/57ND1OdLbFp7gxli l6DEyZlPWCYwis5CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkaO0uLU stx0I4NNjMCoPCbBpruDcc9Ly0OMAhyMSjy8Gxa3hAixJpYVV+YeYpTmYFES551VOy9YSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2NYSIPO/zd+jR0Vu+8E83zc+V3wMR+/wqPnucFrAq9P rGlp5366YnI2z91GvyXzwzZrvg7c55BhEOfS8/v0sllTvkqeVRP8X+TsvSQnx0e+ub8uOZNH TNJA7uLDO6Gn+j11lStPTg/a8X/x3Hzvd73fZLOkpnLtPM8bnFDsnfQh7M9Wllim20osxRmJ hlrMRcWJAO/4JHyrAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6eSZGhKVRWWl3WdH_uNfl8fCrjk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:34:14 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AE76Eeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mallik, the packet loss in the network, in my opinion, is the demonstration of the = real network problem that BFD is intended to detect. The BFD Echo may, I as= sume, help to rule out potential issues with the particular BFD implementat= ion. Troubleshooting the real network problem, e.g. packet loss, is not in = scope of BFD, in my opinion, and can be done with help of other OAM instrum= ents. Regards, Greg From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Monday, December 08, 2014 2:28 PM To: Gregory Mirsky; Santosh P K; Manav Bhatia; Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Greg, Are we assuming that there is a single node in-between the sender and recei= ver for the multi hop case? The actual problem of packet loss may be happen= ing after the next hop node. Since we don't have a way to run echo for mult= i hop sessions, how do we identify packet losses in such a case if we use e= cho? Thanks Regards Mallik From: Gregory Mirsky > Date: Monday, 8 December 2014 11:52 am To: Santosh P K >, Mana= v Bhatia >, Marc Binder= berger > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, do you envision scenario when BFD multi-hop and single-hop sessions that sh= are the same sender behave differently? In my opinion, if multi-hop session= is unstable and single-hop is stable, then the problem is likely in the ne= twork and thus is real, rather than in the BFD sender and more implementati= on specific. Thus running BFD Echo even without cooperation of the next hop= node (no timestamps there) would give sender information about latencies B= FD is subjected to in this node. Regards, Greg From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, December 08, 2014 2:07 PM To: Manav Bhatia; Marc Binderberger Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Mac and Manav, Are we just talking about singlehop? How about MPLS BFD and multihop w= here echo does not work? Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia Sent: Monday, December 08, 2014 9:33 AM To: Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Marc, * Greg's echo idea is of course do-able - when you think timestamping in hardware can be done then it can be done in the forwarding path for echos a= s well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features, which limits it's use though. For the echo mechanism to work, do you agree that you would have to continu= ously send Echos so that you can detect the issue? Or are you suggesting that once BFD flaps we will start sending Echoes over= loaded with debug information to detect the issue? I'd like to understand this before the mailing list sees a barrage of email= s. Alternatively, we can also take it offline and only report the summary o= f our discussion to the list. Cheers, Manav --_000_7347100B5761DC41A166AC17F22DF1121B8AE76Eeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mallik,

the packet loss in the ne= twork, in my opinion, is the demonstration of the real network problem that= BFD is intended to detect. The BFD Echo may, I assume, help to rule out potential issues with the particular BFD implementation. = Troubleshooting the real network problem, e.g. packet loss, is not in scope= of BFD, in my opinion, and can be done with help of other OAM instruments.=

 <= /p>

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

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

 <= /p>

From: MALLIK M= UDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Monday, December 08, 2014 2:28 PM
To: Gregory Mirsky; Santosh P K; Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91<= /p>

 

Hi Greg,

 

Are we assuming that there is= a single node in-between the sender and receiver for the multi hop case? T= he actual problem of packet loss may be happening after the next hop node. Since we don’t have a way to run echo for multi h= op sessions, how do we identify packet losses in such a case if we use echo= ?

 

Thanks

 

Regards

Mallik

 

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Monday, 8 December 2014 11:52 am
To: Santosh P K <santosh= pk@juniper.net>, Manav Bhatia <manavbhatia@gmail.com>, Marc Binderberger <marc@sniff.de>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91<= /p>

 

Hi Santosh,

do you envision scenario = when BFD multi-hop and single-hop sessions that share the same sender behav= e differently? In my opinion, if multi-hop session is unstable and single-hop is stable, then the problem is likely in the network and th= us is real, rather than in the BFD sender and more implementation specific.= Thus running BFD Echo even without cooperation of the next hop node (no ti= mestamps there) would give sender information about latencies BFD is subjected to in this node.

 

    &= nbsp;           Regards,<= /span>

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

 

From: Rtg-bfd [mailto= :rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Monday, December 08, 2014 2:07 PM
To: Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up from IETF-91

 =

Hello Mac and Manav,

     = Are we just talking about singlehop? How about MPLS BFD and multihop where = echo does not work?

 

Thanks

Santosh P K

 

From: Rtg-bfd [mail= to:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Monday, December 08, 2014 9:33 AM
To: Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91

 =

Hi Marc,

 =



* Greg's echo idea is of course do-able - when you think timestamping in hardware can be done then it can be done in the forwarding path for echos a= s
well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features,<= br> which limits it's use though.

 =

For the echo mechanism t= o work, do you agree that you would have to continuously send Echos so that= you can detect the issue?

 =

Or are you suggesting th= at once BFD flaps we will start sending Echoes overloaded with debug inform= ation to detect the issue?

 =

I'd like to understand t= his before the mailing list sees a barrage of emails. Alternatively, we can= also take it offline and only report the summary of our discussion to the = list.

 =

Cheers, Manav=

--_000_7347100B5761DC41A166AC17F22DF1121B8AE76Eeusaamb103erics_-- From nobody Sun Dec 7 22:35:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06211A6F67 for ; Sun, 7 Dec 2014 22:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 1ATD7s9eO-Mp for ; Sun, 7 Dec 2014 22:35:37 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 3DAA61A6F64 for ; Sun, 7 Dec 2014 22:35:37 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-5e-5484f674689a Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9B.5B.03307.476F4845; Mon, 8 Dec 2014 01:53:08 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 01:35:35 -0500 From: Gregory Mirsky To: Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAitQD//66CwIAAVuwA//+setA= Date: Mon, 8 Dec 2014 06:35:35 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE77E@eusaamb103.ericsson.se> References: <20141207193610211284.1f098741@sniff.de> <7347100B5761DC41A166AC17F22DF1121B8AE751@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_7347100B5761DC41A166AC17F22DF1121B8AE77Eeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLrHW7fkW0uIwaUbihaXJ7WxW8y+8p/Z 4vOfbYwW1+5uZXZg8dg56y67x5IlP5k8rjddZfdoXd3NEsASxWWTkpqTWZZapG+XwJWxf+oM poJPixkrPh7ey97AeGQ+YxcjJ4eEgInEo7+tTBC2mMSFe+vZuhi5OIQEjjBKXL/5jhHCWcYo ce/PJVaQKjYBI4kXG3vYQWwRAQ2J1vcHmLsYOTiYBYolXm1RBwkLCxhKrOpeDFViJHFsxlwo 209iy9LXYMtYBFQkHh25zArSyivgK/F+vQDEqv1sEqd2HAE7jlMgUOLqyd1gNiPQcd9PrQHr ZRYQl7j1ZD7U0QISS/acZ4awRSVePv7HCmErSXz8PZ8doj5fYsP0l2D1vAKCEidnPmGZwCg6 C8moWUjKZiEpmwX2mabE+l36ECWKElO6H7JD2EDPz5nLjiy+gJF9FSNHaXFqWW66kcEmRmD8 HZNg093BuOel5SFGAQ5GJR7eDYtbQoRYE8uKK3MPMUpzsCiJ886qnRcsJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgTFy6p4/9r8PO8nIBEmcsmzZ6+gsn/SNoezcr63mAT1VgcJ7n/nHlJ52 cj/qkLL4cOnmRKbpczfsnf+GOS/XIKC/4fS2zua791cm17YXLJ750yHu/fP2G16Pr1y9zxzW vdvk4MJn0yx+fJ67t8K8LVz6r7qedubL/wYuG4slqpivGH5iD+H5w6/EUpyRaKjFXFScCACf 1+DooAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aih7h9lxLgW_ZFdhDu8KNYKsTTc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:35:40 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AE77Eeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQpJ4oCZZCBwcm9wb3NlIHRvIHRha2UgdGhpcyBkaXNjdXNzaW9uIG9mZi1saW5l LiBBbnlvbmUgd2hv4oCZcyBpbnRlcmVzdGVkIGluIGRldmVsb3Bpbmcgc29sdXRpb24gYmFzZWQg b24gQkZEIEVjaG8gcGxlYXNlIGZlZWwgZnJlZSB0byBjb250YWN0IG1lIGRpcmVjdGx5Lg0KDQog ICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg R3JlZw0KDQpGcm9tOiBNYW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21d DQpTZW50OiBNb25kYXksIERlY2VtYmVyIDA4LCAyMDE0IDI6MjcgUE0NClRvOiBHcmVnb3J5IE1p cnNreQ0KQ2M6IFNhbnRvc2ggUCBLOyBNYXJjIEJpbmRlcmJlcmdlcjsgcnRnLWJmZEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IEJGRCBzdGFiaWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KDQpI aSBHcmVnLA0KDQpXaGF0IGlmIGkgZG9udCBoYXZlIGEgc2luZ2xlLWhvcCBzZXNzaW9uPyBEbyB5 b3Ugd2FudCB0aGUgb3BlcmF0b3IgdG8gc2V0IHVwIG9uZSBiZXR3ZWVuIHRoZSBzZW5kZXIgYW5k IGl0cyBpbW1lZGlhdGUgbmV4dC1ob3AgYW5kIGFub3RoZXIgYmV0d2VlbiB0aGUgcmVjZWl2ZXIg YW5kIGl0cyBpbW1lZGlhdGUgbmV4dC1ob3A/DQoNCkNoZWVycywgTWFuYXYNCg0KT24gTW9uLCBE ZWMgOCwgMjAxNCBhdCAxMTo1MiBBTSwgR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVy aWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpI aSBTYW50b3NoLA0KZG8geW91IGVudmlzaW9uIHNjZW5hcmlvIHdoZW4gQkZEIG11bHRpLWhvcCBh bmQgc2luZ2xlLWhvcCBzZXNzaW9ucyB0aGF0IHNoYXJlIHRoZSBzYW1lIHNlbmRlciBiZWhhdmUg ZGlmZmVyZW50bHk/IEluIG15IG9waW5pb24sIGlmIG11bHRpLWhvcCBzZXNzaW9uIGlzIHVuc3Rh YmxlIGFuZCBzaW5nbGUtaG9wIGlzIHN0YWJsZSwgdGhlbiB0aGUgcHJvYmxlbSBpcyBsaWtlbHkg aW4gdGhlIG5ldHdvcmsgYW5kIHRodXMgaXMgcmVhbCwgcmF0aGVyIHRoYW4gaW4gdGhlIEJGRCBz ZW5kZXIgYW5kIG1vcmUgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuIFRodXMgcnVubmluZyBCRkQg RWNobyBldmVuIHdpdGhvdXQgY29vcGVyYXRpb24gb2YgdGhlIG5leHQgaG9wIG5vZGUgKG5vIHRp bWVzdGFtcHMgdGhlcmUpIHdvdWxkIGdpdmUgc2VuZGVyIGluZm9ybWF0aW9uIGFib3V0IGxhdGVu Y2llcyBCRkQgaXMgc3ViamVjdGVkIHRvIGluIHRoaXMgbm9kZS4NCg0KICAgICAgICAgICAgICAg IFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTog UnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFNhbnRvc2ggUCBLDQpTZW50OiBNb25kYXks IERlY2VtYmVyIDA4LCAyMDE0IDI6MDcgUE0NClRvOiBNYW5hdiBCaGF0aWE7IE1hcmMgQmluZGVy YmVyZ2VyDQpDYzogcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGVsbG8g TWFjIGFuZCBNYW5hdiwNCiAgICAgQXJlIHdlIGp1c3QgdGFsa2luZyBhYm91dCBzaW5nbGVob3A/ IEhvdyBhYm91dCBNUExTIEJGRCBhbmQgbXVsdGlob3Agd2hlcmUgZWNobyBkb2VzIG5vdCB3b3Jr Pw0KDQpUaGFua3MNClNhbnRvc2ggUCBLDQoNCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5hdiBCaGF0aWENClNlbnQ6IE1vbmRh eSwgRGVjZW1iZXIgMDgsIDIwMTQgOTozMyBBTQ0KVG86IE1hcmMgQmluZGVyYmVyZ2VyDQpDYzog cnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBC RkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCg0KSGkgTWFyYywNCg0KDQoNCiog R3JlZydzIGVjaG8gaWRlYSBpcyBvZiBjb3Vyc2UgZG8tYWJsZSAtIHdoZW4geW91IHRoaW5rIHRp bWVzdGFtcGluZyBpbg0KaGFyZHdhcmUgY2FuIGJlIGRvbmUgdGhlbiBpdCBjYW4gYmUgZG9uZSBp biB0aGUgZm9yd2FyZGluZyBwYXRoIGZvciBlY2hvcyBhcw0Kd2VsbC4gRGVwZW5kcyBvbiB5b3Vy IGhhcmR3YXJlIDotKSBhbmQgb24gYW4gYWdyZWVkIChtaW5pbWFsKSBmb3JtYXQgZm9yDQplY2hv LiBBcyBtZW50aW9uZWQgQkZEIGVjaG8gaXMgbm90IGRlZmluZWQvdXNlZCBmb3IgbXVsdGlwbGUg QkZEIGZlYXR1cmVzLA0Kd2hpY2ggbGltaXRzIGl0J3MgdXNlIHRob3VnaC4NCg0KRm9yIHRoZSBl Y2hvIG1lY2hhbmlzbSB0byB3b3JrLCBkbyB5b3UgYWdyZWUgdGhhdCB5b3Ugd291bGQgaGF2ZSB0 byBjb250aW51b3VzbHkgc2VuZCBFY2hvcyBzbyB0aGF0IHlvdSBjYW4gZGV0ZWN0IHRoZSBpc3N1 ZT8NCg0KT3IgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgb25jZSBCRkQgZmxhcHMgd2Ugd2lsbCBz dGFydCBzZW5kaW5nIEVjaG9lcyBvdmVybG9hZGVkIHdpdGggZGVidWcgaW5mb3JtYXRpb24gdG8g ZGV0ZWN0IHRoZSBpc3N1ZT8NCg0KSSdkIGxpa2UgdG8gdW5kZXJzdGFuZCB0aGlzIGJlZm9yZSB0 aGUgbWFpbGluZyBsaXN0IHNlZXMgYSBiYXJyYWdlIG9mIGVtYWlscy4gQWx0ZXJuYXRpdmVseSwg d2UgY2FuIGFsc28gdGFrZSBpdCBvZmZsaW5lIGFuZCBvbmx5IHJlcG9ydCB0aGUgc3VtbWFyeSBv ZiBvdXIgZGlzY3Vzc2lvbiB0byB0aGUgbGlzdC4NCg0KQ2hlZXJzLCBNYW5hdg0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B8AE77Eeusaamb103erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBNYW5hdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWQgcHJvcG9z ZSB0byB0YWtlIHRoaXMgZGlzY3Vzc2lvbiBvZmYtbGluZS4gQW55b25lIHdob+KAmXMgaW50ZXJl c3RlZCBpbiBkZXZlbG9waW5nIHNvbHV0aW9uIGJhc2VkIG9uIEJGRCBFY2hvIHBsZWFzZSBmZWVs IGZyZWUgdG8gY29udGFjdCBtZSBkaXJlY3RseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gTWFuYXYgQmhhdGlhIFttYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgRGVjZW1iZXIgMDgsIDIwMTQgMjoyNyBQTTxicj4NCjxiPlRv OjwvYj4gR3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8L2I+IFNhbnRvc2ggUCBLOyBNYXJjIEJp bmRlcmJlcmdlcjsgcnRnLWJmZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQkZE IHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGkgR3JlZyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldoYXQgaWYgaSBkb250IGhhdmUgYSBzaW5nbGUtaG9wIHNlc3Npb24/IERv IHlvdSB3YW50IHRoZSBvcGVyYXRvciB0byBzZXQgdXAgb25lIGJldHdlZW4gdGhlIHNlbmRlciBh bmQgaXRzIGltbWVkaWF0ZSBuZXh0LWhvcCBhbmQgYW5vdGhlciBiZXR3ZWVuIHRoZSByZWNlaXZl ciBhbmQgaXRzIGltbWVkaWF0ZSBuZXh0LWhvcD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLCBNYW5hdjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIERlYyA4LCAyMDE0 IGF0IDExOjUyIEFNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnku bWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNz c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBTYW50b3NoLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmRvIHlvdSBl bnZpc2lvbiBzY2VuYXJpbyB3aGVuIEJGRCBtdWx0aS1ob3AgYW5kIHNpbmdsZS1ob3Agc2Vzc2lv bnMgdGhhdCBzaGFyZSB0aGUgc2FtZSBzZW5kZXIgYmVoYXZlDQogZGlmZmVyZW50bHk/IEluIG15 IG9waW5pb24sIGlmIG11bHRpLWhvcCBzZXNzaW9uIGlzIHVuc3RhYmxlIGFuZCBzaW5nbGUtaG9w IGlzIHN0YWJsZSwgdGhlbiB0aGUgcHJvYmxlbSBpcyBsaWtlbHkgaW4gdGhlIG5ldHdvcmsgYW5k IHRodXMgaXMgcmVhbCwgcmF0aGVyIHRoYW4gaW4gdGhlIEJGRCBzZW5kZXIgYW5kIG1vcmUgaW1w bGVtZW50YXRpb24gc3BlY2lmaWMuIFRodXMgcnVubmluZyBCRkQgRWNobyBldmVuIHdpdGhvdXQg Y29vcGVyYXRpb24NCiBvZiB0aGUgbmV4dCBob3Agbm9kZSAobm8gdGltZXN0YW1wcyB0aGVyZSkg d291bGQgZ2l2ZSBzZW5kZXIgaW5mb3JtYXRpb24gYWJvdXQgbGF0ZW5jaWVzIEJGRCBpcyBzdWJq ZWN0ZWQgdG8gaW4gdGhpcyBub2RlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy1iZmQgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2Fu dG9zaCBQIEs8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNlbWJlciAwOCwgMjAxNCAyOjA3 IFBNPGJyPg0KPGI+VG86PC9iPiBNYW5hdiBCaGF0aWE7IE1hcmMgQmluZGVyYmVyZ2VyPGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBCRkQgc3Rh YmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8gTWFjIGFuZCBNYW5hdiw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJlIHdlIGp1c3Qg dGFsa2luZyBhYm91dCBzaW5nbGVob3A/IEhvdyBhYm91dCBNUExTIEJGRCBhbmQgbXVsdGlob3Ag d2hlcmUgZWNobyBkb2VzIG5vdCB3b3JrPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNhbnRvc2ggUCBLDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnRnLWJmZCBbPGEgaHJlZj0ibWFpbHRvOnJ0 Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpydGctYmZkLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYW5hdiBCaGF0aWE8YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNlbWJlciAwOCwgMjAxNCA5OjMzIEFNPGJyPg0KPGI+ VG86PC9iPiBNYXJjIEJpbmRlcmJlcmdlcjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRv OnJ0Zy1iZmRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGctYmZkQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRG LTkxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5IaSBNYXJjLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCjxicj4NCiogR3JlZydzIGVjaG8gaWRlYSBpcyBvZiBjb3Vyc2UgZG8tYWJsZSAtIHdo ZW4geW91IHRoaW5rIHRpbWVzdGFtcGluZyBpbjxicj4NCmhhcmR3YXJlIGNhbiBiZSBkb25lIHRo ZW4gaXQgY2FuIGJlIGRvbmUgaW4gdGhlIGZvcndhcmRpbmcgcGF0aCBmb3IgZWNob3MgYXM8YnI+ DQp3ZWxsLiBEZXBlbmRzIG9uIHlvdXIgaGFyZHdhcmUgOi0pIGFuZCBvbiBhbiBhZ3JlZWQgKG1p bmltYWwpIGZvcm1hdCBmb3I8YnI+DQplY2hvLiBBcyBtZW50aW9uZWQgQkZEIGVjaG8gaXMgbm90 IGRlZmluZWQvdXNlZCBmb3IgbXVsdGlwbGUgQkZEIGZlYXR1cmVzLDxicj4NCndoaWNoIGxpbWl0 cyBpdCdzIHVzZSB0aG91Z2guPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIHRoZSBlY2hvIG1lY2hhbmlzbSB0byB3b3Jr LCBkbyB5b3UgYWdyZWUgdGhhdCB5b3Ugd291bGQgaGF2ZSB0byBjb250aW51b3VzbHkgc2VuZCBF Y2hvcyBzbyB0aGF0IHlvdSBjYW4gZGV0ZWN0IHRoZSBpc3N1ZT88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9yIGFyZSB5b3Ugc3VnZ2Vz dGluZyB0aGF0IG9uY2UgQkZEIGZsYXBzIHdlIHdpbGwgc3RhcnQgc2VuZGluZyBFY2hvZXMgb3Zl cmxvYWRlZCB3aXRoIGRlYnVnIGluZm9ybWF0aW9uIHRvIGRldGVjdCB0aGUgaXNzdWU/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ2Qg bGlrZSB0byB1bmRlcnN0YW5kIHRoaXMgYmVmb3JlIHRoZSBtYWlsaW5nIGxpc3Qgc2VlcyBhIGJh cnJhZ2Ugb2YgZW1haWxzLiBBbHRlcm5hdGl2ZWx5LCB3ZSBjYW4gYWxzbyB0YWtlIGl0IG9mZmxp bmUgYW5kIG9ubHkgcmVwb3J0IHRoZSBzdW1tYXJ5IG9mIG91ciBkaXNjdXNzaW9uIHRvIHRoZSBs aXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Q2hlZXJzLCBNYW5hdjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B8AE77Eeusaamb103erics_-- From nobody Sun Dec 7 22:38:54 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC03E1A6F7F for ; Sun, 7 Dec 2014 22:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 9vPiLAVF_jJM for ; Sun, 7 Dec 2014 22:38:43 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEA11A6F6B for ; Sun, 7 Dec 2014 22:38:42 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id ft15so4544598pdb.36 for ; Sun, 07 Dec 2014 22:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=13mdKOQEJVNO6A6sxfzXugBNFT9CnovImAKXL9VrI1A=; b=OqMsJVAsDZisMXjSoyiTJ7H1aYgJpG2sBkN8q/56JB9/njgc+78xCXdO4pLlHqV+u3 yVJUVn0mqLTD++2MVYpbtInvYFl2WakXfyeD1YN4P0TgPytKEj6JcjNt+EP8KTeLh8b6 PBfo79eTCkneQW92AOqsOGd09gt4SFHYMes6tC//E9JXBd1c4E5ukTLDDUHSsvpSO9/D 3IgBcpweXNyqpkwclzxMeKgOTnBJnnIGliU3iC0PCA3exuNNwV51FwQODTOkj3KTHibD 2wrnEs1S1P331Q9aMszU9lO7gzvVUtYgVhSSKKvIXmZqYyFHTwlLKcyskM6GJnTFfrtR 7XTQ== X-Received: by 10.68.211.7 with SMTP id my7mr58745653pbc.115.1418020722078; Sun, 07 Dec 2014 22:38:42 -0800 (PST) Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id tm3sm35620589pac.12.2014.12.07.22.38.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Dec 2014 22:38:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: BFD stability follow-up from IETF-91 From: Sam Aldrin In-Reply-To: <20141207210038569945.f0a11d44@sniff.de> Date: Sun, 7 Dec 2014 22:38:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141204151708.GA9458@pfrc> <7347100B5761DC41A166AC17F22DF1121B8AAC29@eusaamb103.ericsson.se> <059338DA-6758-46C1-AD23-D2039C875D09@gmail.com> <58D290A6-1EB1-425B-9FFA-3025A3CAE4EE@gmail.com> <3EA747F1-FFDD-4E36-B8A2-58E362C1F601@gmail.com> <20141207210038569945.f0a11d44@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5d3_PvQpvYYio13kgojReloRARg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:38:47 -0000 Hi Marc, Thanks for the response. Inline for my comments. > On Dec 7, 2014, at 9:00 PM, Marc Binderberger wrote: >=20 > Hello Sam, Manav et al., >=20 > really a long thread ... :-) >=20 > Reading the emails I had a few time the question: what are we trying = to=20 > achieve here? I have asked the same and haven=E2=80=99t received the response yet. The = ID doesn=E2=80=99t provide clear or convincing answer. But the email flood is discussing the solution already. >=20 > There is debugging. Obviously, having more (relevant) data helps to = find the=20 > cause, likely by eliminating the not-causes. I don't expect anything = perfect,=20 > as Sam stated >=20 >> Debugging Packet drops, latency and mis-ordering of packets is mostly=20= >> shooting in the dark :D >=20 >=20 > But then there may be another motivation. Manav wrote >=20 >> Ideally even if there is some bit of congestion i would like the BFD=20= >> packet to get through. >=20 > and I wonder what do you mean? You mean BFD should not flap if it was=20= > congestion? > The "stability" and some comments in the emails makes me wonder if we = talk=20 > about "do not timeout when ...". And that would be a very different = topic. It=20 > would mean we talk about a different trigger than the timeout defined = in 5880. >=20 > In this case we would need to talk about the new trigger condition = first=20 > before we discuss what data needs to be exchanged. I am not sure if the email thread has reached point of no return, but, = it is not effective when the problem to solve is not discussed enough, = but the solution is. >=20 >=20 >>>> I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D=20 >>> Sure, that would make Marc very happy ! :-) >=20 > Count me in! :-) >=20 > Seriously: if the discussion is to improve debugging of v1 then v2 = maybe a=20 > long shot. If we talk about different triggers then a v2 header may = make=20 > sense. I would add another caveat or put it differently, if the goal of = debugging the debugger (v1) with changes to protocol to v1, then take = it as v2. May be OAM for OAM WG is an idea :D -sam >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Thu, 4 Dec 2014 19:52:19 -0800, Sam K. Aldrin wrote: >> Hi Manav, >>=20 >> On Dec 4, 2014, at 6:51 PM, Manav Bhatia wrote: >>> Hi Sam, >>>>> Ideally even if there is some bit of congestion i would like the = BFD=20 >>>>> packet to get through. >>>> I understand the queuing problems but I am not clear how the ID is = going=20 >>>> to solve the problem, if there is only congestion and not >>>=20 >>> It would help. >>>=20 >>> Assume the last sequence number you saw before the flap was s1. You = timed=20 >>> out since you did not see s2 and s3 before the timeout. Now further = assume=20 >>> that you know that you did receive s2 and s3, however they arrived = after=20 >>> the BFD expiry interval then you know that there wasnt a drop, and = the=20 >>> packet arrived late because of some queing issue. Now how you = determine=20 >>> whether this delay was seen at the TX or RX side is open to = discussion. >>=20 >> As the draft doesn't say, what exactly one would/should do, assuming = there=20 >> is packet throttling happing due to various reasons, could = you/authors=20 >> elaborate on this? I would like to see those tangible things detailed = first. >>=20 >> I see the problem little differently though. BFD session flapping is = an=20 >> indicator of the network behavior, be it device or network congestion = or=20 >> something else. Even if the packets arrive late, as you say, one = cannot=20 >> know where exactly the delay is happening. >>=20 >>>=20 >>> Without a sequence number you have no idea whether the packet was = dropped=20 >>> or whether it arrived/processed late.=20 >>>=20 >>> If by some out-of-band mechanism you can figure out that the TX was = done=20 >>> on time and the delay was at RX end then its an implementation issue = on=20 >>> the RX side. If the TX was delayed then its an implementation issue = at the=20 >>> TX side. >> Don't think so. It could be the lot more than implementation issue. = Could=20 >> be due to network congestion due to bursty traffic and nothing to do = with=20 >> the implementation. >>>=20 >>> This helps isolating the node that needs to fix the issue, otherwise = we're=20 >>> only shooting in the dark.=20 >> The issue you see is what I think could be the actual network = behavior and=20 >> not the device issue.=20 >> Debugging Packet drops, latency and mis-ordering of packets is mostly=20= >> shooting in the dark :D >> Nevertheless, I do not see this as BFD specific only.=20 >>=20 >>>=20 >>>> packet drop. In that case just the sequence # doesn't help and=20 >>>> timestamping is needed. Even if timestamping is to be done, = realistically=20 >>>> it cannot happen the same way across multi vendor i.e. where the=20 >>>> timestamping should/could be done. For ex: Before it is queued or = after=20 >>>> OR LC/RP/SP/Process etc. >>>=20 >>> This isnt a new problem. Each vendor time stamps 1588 packets = differently.=20 >>> However, the aggregate solution works across multiple vendors. >>>=20 >>> While it may not solve all the issues because of the vagaries of how = each=20 >>> vendor does time stamping it would certainly help debugging large = number=20 >>> of BFD flaps. >> As timestamp is not in the ID, we could differ the discussion for = later,=20 >> but I definitely believe that it is a bigger issue where TS is taken, = if =20 >> granularity and accuracy are important. >>>=20 >>>>=20 >>>> Secondly, if the congestion happens, the CIR/PIR should apply to = data=20 >>>> packets too. In that case BFD flap is at least a good indicator of = the=20 >>>> problem, isn't it?=20 >>>=20 >>> There is usually a separate CIR/PIR for different CPU bound packets. = So=20 >>> based on some parameters you might impose a different CIR/PIR for = BFD than=20 >>> say, ssh and radius packets. If BFD flaps and you know you missed a = few=20 >>> sequence numbers and you see drops in that queue then all of this = could be=20 >>> co-related and you could fix the CPU queue parameters for BFD. I=20 >>> understand that this is a very implementation specific issue, but = then=20 >>> thats what i had said earlier -- such a mechanism can help in = isolating=20 >>> implementation specific issues as well. >> I agree that it will be helpful. But then, when a new mechanism is=20 >> introduced, it should clearly spell out the mechanisms on = interpreting the=20 >> problems and how to deal with it. The ID has none of it, as of now. >>>=20 >>>>=20 >>>> Lastly, these improvements is change from the existing BFD=20 >>>> model/protocol.=20 >>>> I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D >>>=20 >>> Sure, that would make Marc very happy ! :-) >>>=20 >>> I am not sure if we have enough momentum right now that can propel = us=20 >>> towards BFD v2. >>>=20 >>> OTOH, if the WG believes that this is an opportune time for us to = start=20 >>> looking at BFDv2, then i would be more than willing to participate! >> Well, if there is real issue that existing BFD falls short of the = needs,=20 >> then interest automatically increases. As this ID introduces new = things to=20 >> existing version, it should be pursued as part of next version, = rather than=20 >> changing the existing model for the same version. >>=20 >> -sam >>=20 >>>=20 >>> Cheers, Manav=20 >>>>=20 >>>> -sam >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> - I see concerns regarding timestamps and sequence numbers = expressed in=20 >>>>>> emails. In that case, the proposed model is still not going to = identify=20 >>>>>> the problem completely. Am I reading it right? >>>>>>=20 >>>>>> -sam >>>>>> On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote: >>>>>>=20 >>>>>>> Hi Jeff, >>>>>>> I can reference RFC 5357 here. The Appendix describes what is = called=20 >>>>>> TWAMP-Light mode with Stateless Reflector. About year and a half = the=20 >>>>>> Errata been accepted that describes Stateful Reflector, which = supports=20 >>>>>> measurement of one-way latency/jitter and packet loss metrics. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Greg >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of = Jeffrey=20 >>>>>> Haas >>>>>>> Sent: Thursday, December 04, 2014 7:17 AM >>>>>>> To: Nobo Akiya (nobo) >>>>>>> Cc: rtg-bfd@ietf.org >>>>>>> Subject: Re: BFD stability follow-up from IETF-91 >>>>>>>=20 >>>>>>> On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) = wrote: >>>>>>>> If what you say is the only requirement not met, one approach = may be=20 >>>>>> to pursue a non-standard-track document describing some suggested=20= >>>>>> implementation techniques to locally store TX/RX timestamp. >>>>>>>>=20 >>>>>>>> Given that echo approach will be less accurate and given that = we=20 >>>>>> seem to be having difficulty converging, I thought I???ll throw = out=20 >>>>>> another idea. >>>>>>>=20 >>>>>>> I think my biggest concern is that the echo approach has=20 >>>>>> bidirectional packet loss possibilities. Async at least lets the=20= >>>>>> receiver know about unidirectional packet loss. >>>>>>>=20 >>>>>>> Of course, if your goal is to notify the sender that their = packets=20 >>>>>> are being lost, you need a backchannel anyway. I just don't know = if we=20 >>>>>> want that back channel to be bfd. >>>>>>>=20 >>>>>>> - Jeff >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 From nobody Sun Dec 7 22:39:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C411A6F7F for ; Sun, 7 Dec 2014 22:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vUQzZUtA7m0m for ; Sun, 7 Dec 2014 22:39:31 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310D61A6F6B for ; Sun, 7 Dec 2014 22:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21827; q=dns/txt; s=iport; t=1418020771; x=1419230371; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=GgsAq2AEoHambWJ5BxRO2KofDABBCpy1/oRW/paM8HI=; b=jjEqpLJSSHN/bswKpfHHE3fOpeivU/AsJAewXxneV5OdeIzAMDY1a/Hv 7+H4U7HlAxxYhrW6ejMoGFUYFFbw0K6M+qoNKdMad9GeEZu44aAoYVHEM ykzFA9hV3oSVHKionFy1NOCYsa24yDAyIq5ferygN65NerQjxtQ53Zzz9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAGhGhVStJV2Z/2dsb2JhbABQCoJDQ1JYBMNviDkCgRwWAQEBAQF9hAIBAQEELUELEgEIEQMBAQEhByYCERQJCAIEAQ0FiCYDEs49DYV1AQEBAQEBAQEBAQEBAQEBAQEBAQEBF44igVFLEQYBhDYFhhiJLgWIK4FpgSKMDIIvg2KDb2+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,536,1413244800"; d="scan'208,217";a="103563882" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 08 Dec 2014 06:39:31 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sB86dTW6020872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 06:39:29 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 00:39:29 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: Gregory Mirsky , Santosh P K , Manav Bhatia , "Marc Binderberger" Subject: Re: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6sKG4KnHULdkO3SoZYWD6QxJxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYCAAFQ6AIAACIMAgABdKQD//6S3gIAAI96AgAAOuYCAAAYBAIAAAhWAgAWECQCAAAeGgIAAIrQAgAAERwCAAF25gP//pYGAgABds4A= Date: Mon, 8 Dec 2014 06:39:29 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AE76E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.106] Content-Type: multipart/alternative; boundary="_000_D0AB44A328B0Ammudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/j0_j8pcmQwthrs2lX6IC_Ewbkhk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:39:35 -0000 --_000_D0AB44A328B0Ammudigonciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Greg, I understand your point. I am not suggesting that we use a particular mecha= nism for this purpose. The original issue that was raised to support the s= equence numbers in BFD packets was that there may be loss of packets but no= t large enough to cause BFD session flap. So though the session stays up, t= here may be some packets lost. Adding sequence numbers to BFD is one of the= suggestion on this thread. You suggested using echo for this purpose. My q= uestion was echo is not supported over multi hop sessions and so is there a= generic way to take this forward? Thanks Regards Mallik From: Gregory Mirsky > Date: Monday, 8 December 2014 12:04 pm To: Cisco Employee >, Santosh= P K >, Manav Bhatia >, Marc Binderberger > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Mallik, the packet loss in the network, in my opinion, is the demonstration of the = real network problem that BFD is intended to detect. The BFD Echo may, I as= sume, help to rule out potential issues with the particular BFD implementat= ion. Troubleshooting the real network problem, e.g. packet loss, is not in = scope of BFD, in my opinion, and can be done with help of other OAM instrum= ents. Regards, Greg From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Monday, December 08, 2014 2:28 PM To: Gregory Mirsky; Santosh P K; Manav Bhatia; Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Greg, Are we assuming that there is a single node in-between the sender and recei= ver for the multi hop case? The actual problem of packet loss may be happen= ing after the next hop node. Since we don=92t have a way to run echo for mu= lti hop sessions, how do we identify packet losses in such a case if we use= echo? Thanks Regards Mallik From: Gregory Mirsky > Date: Monday, 8 December 2014 11:52 am To: Santosh P K >, Mana= v Bhatia >, Marc Binder= berger > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, do you envision scenario when BFD multi-hop and single-hop sessions that sh= are the same sender behave differently? In my opinion, if multi-hop session= is unstable and single-hop is stable, then the problem is likely in the ne= twork and thus is real, rather than in the BFD sender and more implementati= on specific. Thus running BFD Echo even without cooperation of the next hop= node (no timestamps there) would give sender information about latencies B= FD is subjected to in this node. Regards, Greg From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, December 08, 2014 2:07 PM To: Manav Bhatia; Marc Binderberger Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Mac and Manav, Are we just talking about singlehop? How about MPLS BFD and multihop w= here echo does not work? Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia Sent: Monday, December 08, 2014 9:33 AM To: Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Marc, * Greg's echo idea is of course do-able - when you think timestamping in hardware can be done then it can be done in the forwarding path for echos a= s well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features, which limits it's use though. For the echo mechanism to work, do you agree that you would have to continu= ously send Echos so that you can detect the issue? Or are you suggesting that once BFD flaps we will start sending Echoes over= loaded with debug information to detect the issue? I'd like to understand this before the mailing list sees a barrage of email= s. Alternatively, we can also take it offline and only report the summary o= f our discussion to the list. Cheers, Manav --_000_D0AB44A328B0Ammudigonciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Greg,

I understand your point. I am not suggesting that we use a particular = mechanism for this purpose.  The original issue that was raised to sup= port the sequence numbers in BFD packets was that there may be loss of pack= ets but not large enough to cause BFD session flap. So though the session stays up, there may be some packets lo= st. Adding sequence numbers to BFD is one of the suggestion on this thread.= You suggested using echo for this purpose. My question was echo is not sup= ported over multi hop sessions and so is there a generic way to take this forward?

Thanks

Regards
Mallik

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Monday, 8 December 2014 12:04= pm
To: Cisco Employee <mmudigon@cisco.com>, Santosh P K <santoshpk@juniper.net>, Manav Bh= atia <manavbhatia@gmail.com= >, Marc Binderberger <marc@sniff.de&g= t;
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-u= p from IETF-91

Hi Mallik,

the packet loss in the network, in = my opinion, is the demonstration of the real network problem that BFD is in= tended to detect. The BFD Echo may, I assume, help to rule out potential issues with the particular BFD implem= entation. Troubleshooting the real network problem, e.g. packet loss, is no= t in scope of BFD, in my opinion, and can be done with help of other OAM in= struments.

 

      = ;          Regards,=

      = ;            &n= bsp;            = ; Greg

 

From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Monday, December 08, 2014 2:28 PM
To: Gregory Mirsky; Santosh P K; Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91<= /p>

 

Hi Greg,

 

Are we assuming that there is a single node in= -between the sender and receiver for the multi hop case? The actual problem= of packet loss may be happening after the next hop node. Since we don=92t have a way to run echo for multi hop s= essions, how do we identify packet losses in such a case if we use echo?

 

Thanks

 

Regards

Mallik

 

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Monday, 8 December 2014 11:52 am
To: Santosh P K <santosh= pk@juniper.net>, Manav Bhatia <manavbhatia@gmail.com>, Marc Binderberger <marc@sniff.de>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91<= /p>

 

Hi Santosh,

do you envision scenario when BFD m= ulti-hop and single-hop sessions that share the same sender behave differen= tly? In my opinion, if multi-hop session is unstable and single-hop is stable, then the problem is likely in the ne= twork and thus is real, rather than in the BFD sender and more implementati= on specific. Thus running BFD Echo even without cooperation of the next hop= node (no timestamps there) would give sender information about latencies BFD is subjected to in this node.<= /span>

 

      = ;          Regards,

      = ;            &n= bsp;            = ; Greg

 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Monday, December 08, 2014 2:07 PM
To: Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up from IETF-91

 =

Hello Mac and Manav,

     Are we jus= t talking about singlehop? How about MPLS BFD and multihop where echo does = not work?

 

Thanks

Santosh P K

 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Monday, December 08, 2014 9:33 AM
To: Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91

 =

Hi Marc,

 =



* Greg's echo idea is of course do-able - when you think timestamping in hardware can be done then it can be done in the forwarding path for echos a= s
well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features,<= br> which limits it's use though.

 =

For the echo mechanism t= o work, do you agree that you would have to continuously send Echos so that= you can detect the issue?

 =

Or are you suggesting th= at once BFD flaps we will start sending Echoes overloaded with debug inform= ation to detect the issue?

 =

I'd like to understand t= his before the mailing list sees a barrage of emails. Alternatively, we can= also take it offline and only report the summary of our discussion to the = list.

 =

Cheers, Manav=

--_000_D0AB44A328B0Ammudigonciscocom_-- From nobody Sun Dec 7 22:47:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3501F1A6F81 for ; Sun, 7 Dec 2014 22:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 n1Lb6zi6JobA for ; Sun, 7 Dec 2014 22:47:18 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 459B81A6F6E for ; Sun, 7 Dec 2014 22:47:18 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-c6-5484f931abba Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 71.8B.03307.139F4845; Mon, 8 Dec 2014 02:04:49 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 01:47:16 -0500 From: Gregory Mirsky To: "MALLIK MUDIGONDA (mmudigon)" , Santosh P K , Manav Bhatia , "Marc Binderberger" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAitQD//66CwIAAV0WA//+sX/CAAFbYgP//rHTw Date: Mon, 8 Dec 2014 06:47:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE7C4@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B8AE76E@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_7347100B5761DC41A166AC17F22DF1121B8AE7C4eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyuXRPuK7hz5YQg7mzRSwuT2pjt5h95T+z xZFXx5gtPv/Zxmhx7e5WZgdWjym/N7J67Jx1l91jyZKfTB7Xm66ye7Su7mYJYI3isklJzcks Sy3St0vgyvjUu5Sp4PVdxorHb2sbGHceYexi5OSQEDCR6Dr9hAnCFpO4cG89WxcjF4eQwBFG iTerDzJCOMsYJWa/WckGUsUmYCTxYmMPO0hCRGAVo8SC/V/B2pkFNCWaTnxmB7GFBQwlVnUv BrNFgBqOzZgLZUdJXNk7jxXEZhFQkdhyazqYzSvgK7Hx4G0WEFtIoFji+br5zCA2p4CBxNLb S8B6GYHO+35qDdQucYlbT+ZDnS0gsWTPeWYIW1Ti5eN/rBC2ksTH3/PZIerzJc5tvMECsUtQ 4uTMJywTGEVnIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxallu upHBJkZgXB6TYNPdwbjnpeUhRgEORiUe3g2LW0KEWBPLiitzDzFKc7AoifPOqp0XLCSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoFRZJVDi2J0ZXZPk1ycdG3JloPPndnDDtRp7qrPXv3ylup1 Xb26TbVJh8V3C0TwzDSaKvFx4smpQhJx/+Ljes/OS/911+NHiUzSrvuWqmtjM3SDWF+zxS47 dHCBk0/QYqGmqDtf9sxKNWqIjbNJsz7SbL1HeI7fYZX0U9t/rm7U3FcbwJhkslWJpTgj0VCL uag4EQBJIt91rAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6CJpSzu0eEw315l5R0OXZlmorUc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 06:47:23 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8AE7C4eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mallik, I think I was not clear in explaining the possible use of BFD Echo. It is n= ot to measure packet loss in the network. That, I'm certain, is real networ= k problem that can e properly quantified only with use of performance measu= rement methods, active or passive. The subject of the proposal being discussed, as I understand, detecting sup= erficial outages of BFD caused by scaling and/or implementation issues, not= by the network environment. I agree with Mark that ensuring consistent and= thus informative timestamping is the challenge by itself and better be lef= t internal. But if there's some interest in developing something that may b= e used for this purpose and, at the same time, would not affect the most us= ed BFD Async mode, then BFD Echo may be, may be the right vechicle. Regards, Greg From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Monday, December 08, 2014 2:39 PM To: Gregory Mirsky; Santosh P K; Manav Bhatia; Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Greg, I understand your point. I am not suggesting that we use a particular mecha= nism for this purpose. The original issue that was raised to support the s= equence numbers in BFD packets was that there may be loss of packets but no= t large enough to cause BFD session flap. So though the session stays up, t= here may be some packets lost. Adding sequence numbers to BFD is one of the= suggestion on this thread. You suggested using echo for this purpose. My q= uestion was echo is not supported over multi hop sessions and so is there a= generic way to take this forward? Thanks Regards Mallik From: Gregory Mirsky > Date: Monday, 8 December 2014 12:04 pm To: Cisco Employee >, Santosh= P K >, Manav Bhatia >, Marc Binderberger > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Mallik, the packet loss in the network, in my opinion, is the demonstration of the = real network problem that BFD is intended to detect. The BFD Echo may, I as= sume, help to rule out potential issues with the particular BFD implementat= ion. Troubleshooting the real network problem, e.g. packet loss, is not in = scope of BFD, in my opinion, and can be done with help of other OAM instrum= ents. Regards, Greg From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Monday, December 08, 2014 2:28 PM To: Gregory Mirsky; Santosh P K; Manav Bhatia; Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Greg, Are we assuming that there is a single node in-between the sender and recei= ver for the multi hop case? The actual problem of packet loss may be happen= ing after the next hop node. Since we don't have a way to run echo for mult= i hop sessions, how do we identify packet losses in such a case if we use e= cho? Thanks Regards Mallik From: Gregory Mirsky > Date: Monday, 8 December 2014 11:52 am To: Santosh P K >, Mana= v Bhatia >, Marc Binder= berger > Cc: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Santosh, do you envision scenario when BFD multi-hop and single-hop sessions that sh= are the same sender behave differently? In my opinion, if multi-hop session= is unstable and single-hop is stable, then the problem is likely in the ne= twork and thus is real, rather than in the BFD sender and more implementati= on specific. Thus running BFD Echo even without cooperation of the next hop= node (no timestamps there) would give sender information about latencies B= FD is subjected to in this node. Regards, Greg From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, December 08, 2014 2:07 PM To: Manav Bhatia; Marc Binderberger Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hello Mac and Manav, Are we just talking about singlehop? How about MPLS BFD and multihop w= here echo does not work? Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia Sent: Monday, December 08, 2014 9:33 AM To: Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Marc, * Greg's echo idea is of course do-able - when you think timestamping in hardware can be done then it can be done in the forwarding path for echos a= s well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features, which limits it's use though. For the echo mechanism to work, do you agree that you would have to continu= ously send Echos so that you can detect the issue? Or are you suggesting that once BFD flaps we will start sending Echoes over= loaded with debug information to detect the issue? I'd like to understand this before the mailing list sees a barrage of email= s. Alternatively, we can also take it offline and only report the summary o= f our discussion to the list. Cheers, Manav --_000_7347100B5761DC41A166AC17F22DF1121B8AE7C4eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mallik,

I think I was not clear i= n explaining the possible use of BFD Echo. It is not to measure packet loss= in the network. That, I’m certain, is real network problem that can e properly quantified only with use of performance measurement me= thods, active or passive.

The subject of the propos= al being discussed, as I understand, detecting superficial outages of BFD c= aused by scaling and/or implementation issues, not by the network environment. I agree with Mark that ensuring consistent and thus i= nformative timestamping is the challenge by itself and better be left inter= nal. But if there’s some interest in developing something that may be= used for this purpose and, at the same time, would not affect the most used BFD Async mode, then BFD Echo may be,= may be the right vechicle.

 <= /p>

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

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

 <= /p>

From: MALLIK M= UDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Monday, December 08, 2014 2:39 PM
To: Gregory Mirsky; Santosh P K; Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91<= /p>

 

Hi Greg,

 

I understand your point. I am= not suggesting that we use a particular mechanism for this purpose.  = The original issue that was raised to support the sequence numbers in BFD packets was that there may be loss of packets but not large enough = to cause BFD session flap. So though the session stays up, there may be som= e packets lost. Adding sequence numbers to BFD is one of the suggestion on = this thread. You suggested using echo for this purpose. My question was echo is not supported over multi ho= p sessions and so is there a generic way to take this forward?

 

Thanks

 

Regards

Mallik

 

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Monday, 8 December 2014 12:04 pm
To: Cisco Employee <mmudigo= n@cisco.com>, Santosh P K <santoshpk@juniper.net>, Manav Bhatia <manavbhatia@gmail.com>, Marc Binderberger <marc@sniff.de>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91<= /p>

 

Hi Mallik,

the packet loss in the ne= twork, in my opinion, is the demonstration of the real network problem that= BFD is intended to detect. The BFD Echo may, I assume, help to rule out potential issues with the particular BFD implementation. = Troubleshooting the real network problem, e.g. packet loss, is not in scope= of BFD, in my opinion, and can be done with help of other OAM instruments.=

 

    &= nbsp;           Regards,<= /span>

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

 

From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Monday, December 08, 2014 2:28 PM
To: Gregory Mirsky; Santosh P K; Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91

 =

Hi Greg,

 

Are we assuming that there is= a single node in-between the sender and receiver for the multi hop case? T= he actual problem of packet loss may be happening after the next hop node. Since we don’t have a way to run echo for multi h= op sessions, how do we identify packet losses in such a case if we use echo= ?

 

Thanks

 

Regards

Mallik

 

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Monday, 8 December 2014 11:52 am
To: Santosh P K <santosh= pk@juniper.net>, Manav Bhatia <manavbhatia@gmail.com>, Marc Binderberger <marc@sniff.de>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91

 

Hi Santosh,

do you envision scenario = when BFD multi-hop and single-hop sessions that share the same sender behav= e differently? In my opinion, if multi-hop session is unstable and single-hop is stable, then the problem is likely in the network and th= us is real, rather than in the BFD sender and more implementation specific.= Thus running BFD Echo even without cooperation of the next hop node (no ti= mestamps there) would give sender information about latencies BFD is subjected to in this node.

 

    &= nbsp;           Regards,<= /span>

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

 

From: Rtg-bfd [mailto= :rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Monday, December 08, 2014 2:07 PM
To: Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up from IETF-91

 =

Hello Mac and Manav,

     = Are we just talking about singlehop? How about MPLS BFD and multihop where = echo does not work?

 

Thanks

Santosh P K

 

From: Rtg-bfd [mail= to:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Monday, December 08, 2014 9:33 AM
To: Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91

 =

Hi Marc,

 =



* Greg's echo idea is of course do-able - when you think timestamping in hardware can be done then it can be done in the forwarding path for echos a= s
well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features,<= br> which limits it's use though.

 =

For the echo mechanism t= o work, do you agree that you would have to continuously send Echos so that= you can detect the issue?

 =

Or are you suggesting th= at once BFD flaps we will start sending Echoes overloaded with debug inform= ation to detect the issue?

 =

I'd like to understand t= his before the mailing list sees a barrage of emails. Alternatively, we can= also take it offline and only report the summary of our discussion to the = list.

 =

Cheers, Manav=

--_000_7347100B5761DC41A166AC17F22DF1121B8AE7C4eusaamb103erics_-- From nobody Sun Dec 7 23:33:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15AD1A6FDF for ; Sun, 7 Dec 2014 23:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 tyFuBFnaMrud for ; Sun, 7 Dec 2014 23:33:20 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B691A6FD8 for ; Sun, 7 Dec 2014 23:33:20 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id bm13so2999341qab.16 for ; Sun, 07 Dec 2014 23:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NAS89/GYZReQSbzkAOGzb/UeeKvH5RgF+oHAV3TMfcw=; b=J2jk3yPurz3bxv7tV+zTVyJ00pXLewODQTef6D2TaYaqKrplnzu4xGiPdIScwpjFZf CnC5eA2tBBX6Jxosq4+ewzF5tweaKHZbYD6T7yv1F2d00Ixb7nxEcvROOm6ztxf1OGIW BKY96w+F03yrun7PYf728NslPnkFl9XEu5hLSjAJ4yFD/OwZfqUGWdz74shH9pFZhxPe W/jxI/8MnSFKuvAXgnZrQMfnI1dOJLVOGQ6X1nbs3utyrUt9x/R1fy0mzoggB/YwxloZ DKVIqY6t4Upk2MMBXj3COzUD4NB0YK3HaTEF9R0UAFaQe9HcZYXeOeq0xRicdZ9qV6Od Zj6Q== X-Received: by 10.140.88.177 with SMTP id t46mr48557536qgd.36.1418023999415; Sun, 07 Dec 2014 23:33:19 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id l3sm32944800qav.16.2014.12.07.23.33.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Dec 2014 23:33:18 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB7ED1CE-7C6A-47F6-893F-9C8578D8C170" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: BFD stability follow-up from IETF-91 From: Mahesh Jethanandani In-Reply-To: Date: Sun, 7 Dec 2014 23:33:16 -0800 Message-Id: <3BF271DB-C70D-47FB-A702-B9A6157B123B@gmail.com> References: To: "MALLIK MUDIGONDA (mmudigon)" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/HzqqOoz1iU1LRXxj5rYS8b78_CM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 07:33:22 -0000 --Apple-Mail=_DB7ED1CE-7C6A-47F6-893F-9C8578D8C170 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Let me try to see if I can bring the focus back on at least what the = draft is trying to achieve. And I will do this by way of a customer = scenario.=20 Customer configures MPLS-TP with working and protect tunnels. Customer = then configures BFD on both the working and protect tunnels. BFD flaps = and triggers a failover to the protect tunnel. After the fact the = customer wants to know why did the failover happen.=20 We do not have the option of saying that they needed to change their = hardware (to perform echo or hardware based time stamping) or to run = other protocols continuously without impacting their network. I am = outlining these parameters not because I want the solution to be limited = to this situation but because most of the explanations or solutions = seemed to have missed the fact that one is dealing with an existing = network with existing hardware. So while the solution can extend itself = to more configurations/situations it cannot ignore the existing setup. How do we determine why a BFD session flapped? There are really two = explanations to a BFD session flapping. Either the BFD packets were lost = or packets were delayed. So the first determination is to do just that. That essentially is germane to why the draft is written. Cheers. p.s. And to tell the customer that we had no way to explain why one of = the features used to detect problems in the network cannot explain *why* = a particular problem happens also does not help. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_DB7ED1CE-7C6A-47F6-893F-9C8578D8C170 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Let me try to see if I can bring the focus back on at least = what the draft is trying to achieve. And I will do this by way of a = customer scenario. 

Customer configures MPLS-TP with working and protect tunnels. = Customer then configures BFD on both the working and protect tunnels. = BFD flaps and triggers a failover to the protect tunnel. After the fact = the customer wants to know why did the failover happen. 

We do not have the = option of saying that they needed to change their hardware (to perform = echo or hardware based time stamping) or to run other protocols = continuously without impacting their network. I am outlining these = parameters not because I want the solution to be limited to this = situation but because most of the explanations or solutions seemed to = have missed the fact that one is dealing with an existing network with = existing hardware. So while the solution can extend itself to more = configurations/situations it cannot ignore the existing setup.

How do we determine = why a BFD session flapped? There are really two explanations to a BFD = session flapping. Either the BFD packets were lost or packets were = delayed. So the first determination is to do just that.

That essentially is germane to why the draft is = written.

Cheers.

p.s. And to tell the customer that we had no way = to explain why one of the features used to detect problems in the = network cannot explain *why* a particular problem happens also does not = help.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_DB7ED1CE-7C6A-47F6-893F-9C8578D8C170-- From nobody Sun Dec 7 23:46:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5EC1A6FF9 for ; Sun, 7 Dec 2014 23:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 WmFMJ3FHxtVd for ; Sun, 7 Dec 2014 23:46:19 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8961A6FFB for ; Sun, 7 Dec 2014 23:46:18 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 686542AA0F; Mon, 8 Dec 2014 07:46:14 +0000 (GMT) Date: Sun, 7 Dec 2014 23:49:58 -0800 From: Marc Binderberger To: Manav Bhatia Message-ID: <20141207234958554921.33ce21f7@sniff.de> In-Reply-To: References: <20141207193610211284.1f098741@sniff.de> <20141207212102448099.e2e4012a@sniff.de> Subject: Re: BFD stability follow-up from IETF-91 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Xl_cyY5-V42cWJeY45sDulHictY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 07:46:20 -0000 Hello Manav, >>> For the echo mechanism to work, do you agree that you would have to >>> continuously send Echos so that you can detect the issue? >> >> that's what I had in mind, yes > > .. and i dont like this. Are you saying that for each BFD session now you > will run a parallel BFD echo session that would carry the debug data? Your > scaling just went for a toss !! Just by a factor of 2 ;-) But seriously: if you run echo at hight speed you would usually avoid running the control packets at high speed too. Just what RFC5880 describes. > This would help if the flap is deterministic-ally reproducible. If its not, Correct. Good for some problems, not good for others. As I said, interesting option but not what I had in mind in first place. > then how long do you run the Echo BFD? And what happens to the original BFD > session? You run the two parallel-ly? The "original" session? I'm talking here about an echo session that is controlled by the corresponding control packet exchange. As described in RFC5880. Echo not defined for 5884 or 7130? Ah well, one probably could. Echo seems at least an option to me, in the context of debugging, that can be discussed. The freedom of defining the packet is interesting, some parameters like RTT are measured easily. Other aspects, like Multihop, are a problem, no doubt. I was simply surprised how quickly this idea was dismissed ... . Regards, Marc > >> >> >>> Or are you suggesting that once BFD flaps we will start sending Echoes >>> overloaded with debug information to detect the issue? >> >> interesting idea - that would be an alternative use, collecting forensic >> data. Maybe we should support that too! > > This would help if the flap is deterministic-ally reproducible. If its not, > then how long do you run the Echo BFD? And what happens to the original BFD > session? You run the two parallel-ly? > > Cheers, Manav > >> >> >> My biggest problem with the echo idea is so far BFD-over-LAG. But maybe it >> is >> not a real problem, any echo stamping/updating in the forwarding path would >> require an hardware update (or reprogramming, if your hardware allows) and >> in >> this case one could boldly state that the echo packet must leave via the >> ingress port :-) >> >> >> Regards, Marc >> >> >> >> >> >> On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote: >>> Hi Marc, >>> >>>> >>>> >>>> * Greg's echo idea is of course do-able - when you think timestamping in >>>> hardware can be done then it can be done in the forwarding path for >> echos >>>> as >>>> well. Depends on your hardware :-) and on an agreed (minimal) format for >>>> echo. As mentioned BFD echo is not defined/used for multiple BFD >> features, >>>> which limits it's use though. >>>> >>> >>> For the echo mechanism to work, do you agree that you would have to >>> continuously send Echos so that you can detect the issue? >>> >>> Or are you suggesting that once BFD flaps we will start sending Echoes >>> overloaded with debug information to detect the issue? >>> >>> I'd like to understand this before the mailing list sees a barrage of >>> emails. Alternatively, we can also take it offline and only report the >>> summary of our discussion to the list. >>> >>> Cheers, Manav > From nobody Mon Dec 8 00:27:31 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B391A700D for ; Mon, 8 Dec 2014 00:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 3SgT3ZXhTWme for ; Mon, 8 Dec 2014 00:27:25 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B3C1A6FC9 for ; Mon, 8 Dec 2014 00:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12240; q=dns/txt; s=iport; t=1418027245; x=1419236845; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=g/wPQwI5TcZ5+AjFwzx+EjVgel5wfJLisO5t2FKE3a8=; b=SSBfUzL7fm/jpoCTsZmhfc5DRkRf+VrqPkGTYYxuW3s1dyAWbTEo9C6m vXl10pOti+4XVR6OFxxqteEmy3OYfxicAxsPaZuDrySJ5Af5PLJ/qiD1O 1j0X8VXe/D5sGVPo68LLZ9iwvf2L6nt/2lHqujqaISeSlVICOWLDzM8uS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFACxghVStJA2I/2dsb2JhbABagkNDgSoEw2+IOQKBIxYBAQEBAX2EAgECBG4LEgEIEQMBAigmAhEUCQgCBA4FiCYDEs5eDYV1AQEBAQEBAQEBAQEBAQEBAQEBAQEBF44ighwRB4Q2BYYYiS4FiCuBaYEii1A8gi+DYoNvb4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208,217";a="103582094" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 08 Dec 2014 08:27:24 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB88ROTj031825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 08:27:24 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 02:27:24 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: Marc Binderberger Subject: Re: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6sKG4KnHULdkO3SoZYWD6QxJxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYCAAFQ6AIAACIMAgABdKQD//6S3gIAAI96AgAAOuYCAAAYBAIAAAhWAgAWECQCAAAeGgIAAFccAgAAGFICAACOJAIAAZqQA Date: Mon, 8 Dec 2014 08:27:24 +0000 Message-ID: In-Reply-To: <20141207234958554921.33ce21f7@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.106] Content-Type: multipart/alternative; boundary="_000_D0AB5E8228B3Bmmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/MDi-UTbPMhEYZMB8m7dAcEAgdaM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 08:27:27 -0000 --_000_D0AB5E8228B3Bmmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, Nothing has been dismissed yet :-). Trying to see what can be done. Thanks Regards Mallik From: Marc Binderberger > Date: Monday, 8 December 2014 1:19 pm To: Manav Bhatia > Cc: "rtg-bfd@ietf.org" > Subject: Re: BFD stability follow-up from IETF-91 Hello Manav, For the echo mechanism to work, do you agree that you would have to continuously send Echos so that you can detect the issue? that's what I had in mind, yes .. and i dont like this. Are you saying that for each BFD session now you will run a parallel BFD echo session that would carry the debug data? Your scaling just went for a toss !! Just by a factor of 2 ;-) But seriously: if you run echo at hight speed you would usually avoid runni= ng the control packets at high speed too. Just what RFC5880 describes. This would help if the flap is deterministic-ally reproducible. If its not, Correct. Good for some problems, not good for others. As I said, interestin= g option but not what I had in mind in first place. then how long do you run the Echo BFD? And what happens to the original BFD session? You run the two parallel-ly? The "original" session? I'm talking here about an echo session that is controlled by the corresponding control packet exchange. As described in RFC5880. Echo not defined for 5884 or 7130? Ah well, one probably could. Echo seems at least an option to me, in the context of debugging, that can = be discussed. The freedom of defining the packet is interesting, some paramete= rs like RTT are measured easily. Other aspects, like Multihop, are a problem, = no doubt. I was simply surprised how quickly this idea was dismissed ... . Regards, Marc Or are you suggesting that once BFD flaps we will start sending Echoes overloaded with debug information to detect the issue? interesting idea - that would be an alternative use, collecting forensic data. Maybe we should support that too! This would help if the flap is deterministic-ally reproducible. If its not, then how long do you run the Echo BFD? And what happens to the original BFD session? You run the two parallel-ly? Cheers, Manav My biggest problem with the echo idea is so far BFD-over-LAG. But maybe it is not a real problem, any echo stamping/updating in the forwarding path would require an hardware update (or reprogramming, if your hardware allows) and in this case one could boldly state that the echo packet must leave via the ingress port :-) Regards, Marc On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote: Hi Marc, * Greg's echo idea is of course do-able - when you think timestamping in hardware can be done then it can be done in the forwarding path for echos as well. Depends on your hardware :-) and on an agreed (minimal) format for echo. As mentioned BFD echo is not defined/used for multiple BFD features, which limits it's use though. For the echo mechanism to work, do you agree that you would have to continuously send Echos so that you can detect the issue? Or are you suggesting that once BFD flaps we will start sending Echoes overloaded with debug information to detect the issue? I'd like to understand this before the mailing list sees a barrage of emails. Alternatively, we can also take it offline and only report the summary of our discussion to the list. Cheers, Manav --_000_D0AB5E8228B3Bmmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Marc,

Nothing has been dismissed yet :-). Trying to see what can be done.

Thanks

Regards
Mallik

From: Marc Binderberger <marc@sniff.de>
Date: Monday, 8 December 2014 1:19 = pm
To: Manav Bhatia <manavbhatia@gmail.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: BFD stability follow-u= p from IETF-91

Hello Manav,

For the echo mechanism to work, do you agree that you would have to
continuously send Echos so that you can detect the issue?
that's what I had in mind, yes
.. and i dont like this. Are you saying that for each BFD session now = you
will run a parallel BFD echo session that would carry the debug data? = Your
scaling just went for a toss !!

Just by a factor of 2 ;-)

But seriously: if you run echo at hight speed you would usually avoid = running
the control packets at high speed too. Just what RFC5880 describes.

This would help if the flap is deterministic-ally reproducible. If its= not,

Correct. Good for some problems, not good for others. As I said, inter= esting
option but not what I had in mind in first place.

then how long do you run the Echo BFD? And what happens to the origina= l BFD
session? You run the two parallel-ly?

The "original" session?  I'm talking here about an= echo session that is
controlled by the corresponding control packet exchange. As described = in
RFC5880. Echo not defined for 5884 or 7130? Ah well, one probably coul= d.

Echo seems at least an option to me, in the context of debugging, that= can be
discussed. The freedom of defining the packet is interesting, some par= ameters
like RTT are measured easily. Other aspects, like Multihop, are a prob= lem, no
doubt. I was simply surprised how quickly this idea was dismissed ... = .


Regards, Marc





Or are you suggesting that once BFD flaps we will start sending Echoes=
overloaded with debug information to detect the issue?
interesting idea - that would be an alternative use, collecting forens= ic
data. Maybe we should support that too!
This would help if the flap is deterministic-ally reproducible. If its= not,
then how long do you run the Echo BFD? And what happens to the origina= l BFD
session? You run the two parallel-ly?
Cheers, Manav
My biggest problem with the echo idea is so far BFD-over-LAG. But mayb= e it
is
not a real problem, any echo stamping/updating in the forwarding path = would
require an hardware update (or reprogramming, if your hardware allows)= and
in
this case one could boldly state that the echo packet must leave via t= he
ingress port :-)
Regards, Marc
On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote:
Hi Marc,



* Greg's echo idea is of course do-able - when you think timestamping = in
hardware can be done then it can be done in the forwarding path for
echos
as
well. Depends on your hardware :-) and on an agreed (minimal) format f= or
echo. As mentioned BFD echo is not defined/used for multiple BFD
features,
which limits it's use though.


For the echo mechanism to work, do you agree that you would have to
continuously send Echos so that you can detect the issue?

Or are you suggesting that once BFD flaps we will start sending Echoes=
overloaded with debug information to detect the issue?

I'd like to understand this before the mailing list sees a barrage of<= /div>
emails. Alternatively, we can also take it offline and only report the=
summary of our discussion to the list.

Cheers, Manav


--_000_D0AB5E8228B3Bmmudigonciscocom_-- From nobody Mon Dec 8 04:43:29 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBB61A8546 for ; Mon, 8 Dec 2014 04:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ul1N9hFY5cvk for ; Mon, 8 Dec 2014 04:43:25 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4C31A86DD for ; Mon, 8 Dec 2014 04:43:19 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id e131so3301817oig.24 for ; Mon, 08 Dec 2014 04:43:18 -0800 (PST) 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:content-type; bh=hpXrDChqI9bS21wo6F1P/ZwRsIMLQ8meQ0dkmKq+C8k=; b=TK1RwcY02TIp5acKzVmzJo/z0F0MbTJWE1N66cRBfiL2zVxHeh8FEhGtU25eAIAw3B MlPm26uW9VzsTlUb5ATH6oLKXWB8yfcVy4/beq19Do27f/yUf2AlquCwIM+KYAntsHkK HHuSCUzwssVFw8Z5JBBDnZb8U7WyLMlbGWjr5S7g9cnDdy9sERUhjyx7m75XX71j+eOW pJU3TW4OtYADco3ombwK3NGgr/mRS8MaWKYqJcCPsk0f90ptkjb0QY4ZdAmnQSOCNcaE KSqS7tj5scCrD45VbTid8yU+eBbgYyrXaaCfey+YmzicTuPy4fi/+9IUej35Wq7cAbeq adgQ== MIME-Version: 1.0 X-Received: by 10.60.146.231 with SMTP id tf7mr7499811oeb.48.1418042598430; Mon, 08 Dec 2014 04:43:18 -0800 (PST) Received: by 10.76.178.199 with HTTP; Mon, 8 Dec 2014 04:43:18 -0800 (PST) In-Reply-To: <20141207234958554921.33ce21f7@sniff.de> References: <20141207193610211284.1f098741@sniff.de> <20141207212102448099.e2e4012a@sniff.de> <20141207234958554921.33ce21f7@sniff.de> Date: Mon, 8 Dec 2014 18:13:18 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Marc Binderberger Content-Type: multipart/alternative; boundary=047d7b5d341a5b1bd10509b3c524 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fvLvYeWS6ZXTK5m6Bl2edCAomiE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 12:43:27 -0000 --047d7b5d341a5b1bd10509b3c524 Content-Type: text/plain; charset=UTF-8 Hi Marc, > .. and i dont like this. Are you saying that for each BFD session now you > > will run a parallel BFD echo session that would carry the debug data? > Your > > scaling just went for a toss !! > > Just by a factor of 2 ;-) > .. and thats quite bad. > But seriously: if you run echo at hight speed you would usually avoid > running > the control packets at high speed too. Just what RFC5880 describes. > You never send control plane packets at a high rate - but now you send and receive twice as many BFD packets as you were processing earlier. I would wager that this would be a show stopper. Cheers, Manav > > > This would help if the flap is deterministic-ally reproducible. If its > not, > > Correct. Good for some problems, not good for others. As I said, > interesting > option but not what I had in mind in first place. > > > then how long do you run the Echo BFD? And what happens to the original > BFD > > session? You run the two parallel-ly? > > The "original" session? I'm talking here about an echo session that is > controlled by the corresponding control packet exchange. As described in > RFC5880. Echo not defined for 5884 or 7130? Ah well, one probably could. > > Echo seems at least an option to me, in the context of debugging, that can > be > discussed. The freedom of defining the packet is interesting, some > parameters > like RTT are measured easily. Other aspects, like Multihop, are a problem, > no > doubt. I was simply surprised how quickly this idea was dismissed ... . > > > Regards, Marc > > > > > > > > >> > >> > >>> Or are you suggesting that once BFD flaps we will start sending Echoes > >>> overloaded with debug information to detect the issue? > >> > >> interesting idea - that would be an alternative use, collecting forensic > >> data. Maybe we should support that too! > > > > This would help if the flap is deterministic-ally reproducible. If its > not, > > then how long do you run the Echo BFD? And what happens to the original > BFD > > session? You run the two parallel-ly? > > > > Cheers, Manav > > > >> > >> > >> My biggest problem with the echo idea is so far BFD-over-LAG. But maybe > it > >> is > >> not a real problem, any echo stamping/updating in the forwarding path > would > >> require an hardware update (or reprogramming, if your hardware allows) > and > >> in > >> this case one could boldly state that the echo packet must leave via the > >> ingress port :-) > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >> > >> On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote: > >>> Hi Marc, > >>> > >>>> > >>>> > >>>> * Greg's echo idea is of course do-able - when you think timestamping > in > >>>> hardware can be done then it can be done in the forwarding path for > >> echos > >>>> as > >>>> well. Depends on your hardware :-) and on an agreed (minimal) format > for > >>>> echo. As mentioned BFD echo is not defined/used for multiple BFD > >> features, > >>>> which limits it's use though. > >>>> > >>> > >>> For the echo mechanism to work, do you agree that you would have to > >>> continuously send Echos so that you can detect the issue? > >>> > >>> Or are you suggesting that once BFD flaps we will start sending Echoes > >>> overloaded with debug information to detect the issue? > >>> > >>> I'd like to understand this before the mailing list sees a barrage of > >>> emails. Alternatively, we can also take it offline and only report the > >>> summary of our discussion to the list. > >>> > >>> Cheers, Manav > > > --047d7b5d341a5b1bd10509b3c524 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marc,

>= ; .. and i dont like this. Are you saying that for each BFD session now you=
> will run a parallel BFD echo session that would carry the debug data? = Your
> scaling just went for a toss !!

Just by a factor of 2 ;-)

.. and= thats quite bad.=C2=A0


But seriously: if you run echo at hight speed you would usually avoid runni= ng
the control packets at high speed too. Just what RFC5880 describes.

You never send control plane packets at a high= rate - but now you send and receive twice as many BFD packets as you were = processing earlier. I would wager that this would be a show stopper.=C2=A0<= /div>

Cheers, Manav
=C2=A0

> This would help if the flap is deterministic-ally reproducible. If its= not,

Correct. Good for some problems, not good for others. As I said, int= eresting
option but not what I had in mind in first place.

> then how long do you run the Echo BFD? And what happens to the origina= l BFD
> session? You run the two parallel-ly?

The "original" session?=C2=A0 I'm talking here about a= n echo session that is
controlled by the corresponding control packet exchange. As described in RFC5880. Echo not defined for 5884 or 7130? Ah well, one probably could.
Echo seems at least an option to me, in the context of debugging, that can = be
discussed. The freedom of defining the packet is interesting, some paramete= rs
like RTT are measured easily. Other aspects, like Multihop, are a problem, = no
doubt. I was simply surprised how quickly this idea was dismissed ... .


Regards, Marc





>
>>
>>
>>> Or are you suggesting that once BFD flaps we will start sendin= g Echoes
>>> overloaded with debug information to detect the issue?
>>
>> interesting idea - that would be an alternative use, collecting fo= rensic
>> data. Maybe we should support that too!
>
> This would help if the flap is deterministic-ally reproducible. If its= not,
> then how long do you run the Echo BFD? And what happens to the origina= l BFD
> session? You run the two parallel-ly?
>
> Cheers, Manav
>
>>
>>
>> My biggest problem with the echo idea is so far BFD-over-LAG. But = maybe it
>> is
>> not a real problem, any echo stamping/updating in the forwarding p= ath would
>> require an hardware update (or reprogramming, if your hardware all= ows) and
>> in
>> this case one could boldly state that the echo packet must leave v= ia the
>> ingress port :-)
>>
>>
>> Regards, Marc
>>
>>
>>
>>
>>
>> On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote:
>>> Hi Marc,
>>>
>>>>
>>>>
>>>> * Greg's echo idea is of course do-able - when you thi= nk timestamping in
>>>> hardware can be done then it can be done in the forwarding= path for
>> echos
>>>> as
>>>> well. Depends on your hardware :-) and on an agreed (minim= al) format for
>>>> echo. As mentioned BFD echo is not defined/used for multip= le BFD
>> features,
>>>> which limits it's use though.
>>>>
>>>
>>> For the echo mechanism to work, do you agree that you would ha= ve to
>>> continuously send Echos so that you can detect the issue?
>>>
>>> Or are you suggesting that once BFD flaps we will start sendin= g Echoes
>>> overloaded with debug information to detect the issue?
>>>
>>> I'd like to understand this before the mailing list sees a= barrage of
>>> emails. Alternatively, we can also take it offline and only re= port the
>>> summary of our discussion to the list.
>>>
>>> Cheers, Manav
>

--047d7b5d341a5b1bd10509b3c524-- From nobody Mon Dec 8 10:15:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7561A87B2 for ; Mon, 8 Dec 2014 10:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4U75xPngvx9q for ; Mon, 8 Dec 2014 10:14:57 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1872D1ACD74 for ; Mon, 8 Dec 2014 10:14:57 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id D6FEB2AA0F; Mon, 8 Dec 2014 18:14:54 +0000 (GMT) Date: Mon, 8 Dec 2014 10:18:40 -0800 From: Marc Binderberger To: Manav Bhatia Message-ID: <20141208101840770153.4d0c983f@sniff.de> In-Reply-To: References: <20141207193610211284.1f098741@sniff.de> <20141207212102448099.e2e4012a@sniff.de> <20141207234958554921.33ce21f7@sniff.de> Subject: Re: BFD stability follow-up from IETF-91 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/79RqiBUQSOvoJIzBz60eEOxzFLk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 18:15:00 -0000 Hello Manav, > You never send control plane packets at a high rate - but now you send and > receive twice as many BFD packets as you were processing earlier. I would > wager that this would be a show stopper. that depends on implementation details how much impact this has. BFD itself is still sending/receiving largely the same number of packets. The echo U-turn processing would happen in the data/forwarding plane and should (well, must) be simple, even with some stamping. Regards, Marc On Mon, 8 Dec 2014 18:13:18 +0530, Manav Bhatia wrote: > Hi Marc, > >>> .. and i dont like this. Are you saying that for each BFD session now you >>> will run a parallel BFD echo session that would carry the debug data? >> Your >>> scaling just went for a toss !! >> >> Just by a factor of 2 ;-) > > .. and thats quite bad. > >> >> But seriously: if you run echo at hight speed you would usually avoid >> running >> the control packets at high speed too. Just what RFC5880 describes. > > You never send control plane packets at a high rate - but now you send and > receive twice as many BFD packets as you were processing earlier. I would > wager that this would be a show stopper. > > Cheers, Manav > >> >>> This would help if the flap is deterministic-ally reproducible. If its >> not, >> >> Correct. Good for some problems, not good for others. As I said, >> interesting >> option but not what I had in mind in first place. >> >>> then how long do you run the Echo BFD? And what happens to the original >> BFD >>> session? You run the two parallel-ly? >> >> The "original" session? I'm talking here about an echo session that is >> controlled by the corresponding control packet exchange. As described in >> RFC5880. Echo not defined for 5884 or 7130? Ah well, one probably could. >> >> Echo seems at least an option to me, in the context of debugging, that can >> be >> discussed. The freedom of defining the packet is interesting, some >> parameters >> like RTT are measured easily. Other aspects, like Multihop, are a problem, >> no >> doubt. I was simply surprised how quickly this idea was dismissed ... . >> >> >> Regards, Marc >> >> >> >> >> >>> >>>> >>>> >>>>> Or are you suggesting that once BFD flaps we will start sending Echoes >>>>> overloaded with debug information to detect the issue? >>>> >>>> interesting idea - that would be an alternative use, collecting forensic >>>> data. Maybe we should support that too! >>> >>> This would help if the flap is deterministic-ally reproducible. If its >> not, >>> then how long do you run the Echo BFD? And what happens to the original >> BFD >>> session? You run the two parallel-ly? >>> >>> Cheers, Manav >>> >>>> >>>> >>>> My biggest problem with the echo idea is so far BFD-over-LAG. But maybe >> it >>>> is >>>> not a real problem, any echo stamping/updating in the forwarding path >> would >>>> require an hardware update (or reprogramming, if your hardware allows) >> and >>>> in >>>> this case one could boldly state that the echo packet must leave via the >>>> ingress port :-) >>>> >>>> >>>> Regards, Marc >>>> >>>> >>>> >>>> >>>> >>>> On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote: >>>>> Hi Marc, >>>>> >>>>>> >>>>>> >>>>>> * Greg's echo idea is of course do-able - when you think timestamping >> in >>>>>> hardware can be done then it can be done in the forwarding path for >>>> echos >>>>>> as >>>>>> well. Depends on your hardware :-) and on an agreed (minimal) format >> for >>>>>> echo. As mentioned BFD echo is not defined/used for multiple BFD >>>> features, >>>>>> which limits it's use though. >>>>>> >>>>> >>>>> For the echo mechanism to work, do you agree that you would have to >>>>> continuously send Echos so that you can detect the issue? >>>>> >>>>> Or are you suggesting that once BFD flaps we will start sending Echoes >>>>> overloaded with debug information to detect the issue? >>>>> >>>>> I'd like to understand this before the mailing list sees a barrage of >>>>> emails. Alternatively, we can also take it offline and only report the >>>>> summary of our discussion to the list. >>>>> >>>>> Cheers, Manav >>> > From nobody Tue Dec 9 08:19:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801651A8794 for ; Tue, 9 Dec 2014 08:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mS4SOd3EmdWv for ; Tue, 9 Dec 2014 08:19:14 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2421A00BD for ; Tue, 9 Dec 2014 08:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=937; q=dns/txt; s=iport; t=1418141954; x=1419351554; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hl/qP+2kUBO+duDn8qUvvF0x9Cz07Ue7UCVkOyxgUbA=; b=IPc6uMTsejbNBhroLsig7r8mAg0oiaxjsbp8NHDJSC477GNX0IV+JxzY GU/MvPqkb2Wt4HFHHExyfNHAO9RQe4tfysG/D5pVVYcluG/MxaoSzYszG hJFF5GUfEBmLtziLOUGSHA0lvaqj6+oM1X1Sulz6Gckrzgu68rQlNDrax 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAIQgh1StJA2D/2dsb2JhbABZgwaBKgTDeIgvAoEmFgEBAQEBfYQCAQEBBDpLBAIBCA4DBAEBCxQJBzIUCQgCBAESCIgw1ycBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjQOCaAEBHjgGgxuBFQEEjg2KIoJfhWcuhAuDXoIwgT5vgQw5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="104080023" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 09 Dec 2014 16:19:13 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB9GJD7K022484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 16:19:13 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 10:19:13 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Topic: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Index: AQHQCRLwLqZvDFdkwECOCg+XQQBjhZyHhVIw Date: Tue, 9 Dec 2014 16:19:13 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3477779F@xmb-rcd-x15.cisco.com> References: <20141126005002.GL20330@pfrc> In-Reply-To: <20141126005002.GL20330@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.68.219.218] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FzOSIkHL-eO9zd7hXI72014Eb48 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 16:19:16 -0000 Hello Jeff/ WG, Support the adoption of this document as co-author. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, November 26, 2014 6:20 AM To: rtg-bfd@ietf.org Subject: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends Dec= ember 12, 2014) Working Group, Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was pre= sented at IETF-91 in Honolulu and was positively received. We'd like to as= k the Working Group whether we should formally adopt this draft as a Workin= g Group item. Please indicate your support or lack thereof to the mail list by December 1= 2, 2014. =20 Also, please supply feedback to the authors. I believe the perception of t= his document is that it's very nearly complete and thus should have a short= lifetime prior to publication as an RFC. -- Jeff & Nobo. From nobody Wed Dec 10 08:16:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5B71A1A10 for ; Wed, 10 Dec 2014 08:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 gFSniBXYJtLn for ; Wed, 10 Dec 2014 08:16:18 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDAD41A026A for ; Wed, 10 Dec 2014 08:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1252; q=dns/txt; s=iport; t=1418228178; x=1419437778; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tyG7X4Pd4d1NIxiWUvSxfnN5ZxtfUCLVprOo2D5mPlw=; b=hI/uy9/mkDklkGw9kvZefG6T/22SYpMU5rzVrmTLgQsINyudBHvjPdsG TetjoC5EAzFbn5LqOlsN7inm+dXV6pVPbQSy5h9PQVvDFtU+iRm63w0ax lK9WhieQXOX07hPe2QTvKIa2vFanQ9jazvICxYRDzz6WYuMAO4G7zGtE8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssFAJ9wiFStJA2G/2dsb2JhbABZgwaBKgTDURiIEwKBGBYBAQEBAX2EDAEBAQQ6SwQCAQgOAwQBAQEKFAUEBzIUCQgCBAESCIgw2DsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjE+CYwEBHjgGgxuBFQEEjgKJfYJchWMthAODX4IwgT5ugQw5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="379137938" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 10 Dec 2014 16:16:17 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sBAGGHNe031313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Dec 2014 16:16:17 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 10:16:16 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)) Thread-Topic: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)) Thread-Index: AQHQC0Orfpq0NkQzqk+rnJxbw6ZJCJyHgT1A Date: Wed, 10 Dec 2014 16:16:16 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D34778BF3@xmb-rcd-x15.cisco.com> References: <20141126005002.GL20330@pfrc> <20141128194337.GE1274@pfrc> In-Reply-To: <20141128194337.GE1274@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.68.220.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/d2v44g213Z4f8ys8C8lJqXSnIj0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 16:16:19 -0000 Hello Jeff, I am not aware of any IPR related to this draft. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Saturday, November 29, 2014 1:14 AM To: rtg-bfd@ietf.org Subject: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-cl= arifications (ends December 12, 2014)) The chairs would like to take this opportunity to remind everyone that if y= ou have IPR on this Internet-draft - or any other draft - to disclose it as= soon as possible. -- Jeff & Nobo On Tue, Nov 25, 2014 at 07:50:02PM -0500, Jeffrey Haas wrote: > Working Group, >=20 > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications,=20 > was presented at IETF-91 in Honolulu and was positively received. =20 > We'd like to ask the Working Group whether we should formally adopt=20 > this draft as a Working Group item. >=20 > Please indicate your support or lack thereof to the mail list by=20 > December 12, 2014. >=20 > Also, please supply feedback to the authors. I believe the perception=20 > of this document is that it's very nearly complete and thus should=20 > have a short lifetime prior to publication as an RFC. >=20 > -- Jeff & Nobo. From nobody Wed Dec 10 08:48:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205151A0369 for ; Wed, 10 Dec 2014 08:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 xED588RQ-W9H for ; Wed, 10 Dec 2014 08:48:05 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A73F1A0363 for ; Wed, 10 Dec 2014 08:48:05 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id ft15so3079813pdb.22 for ; Wed, 10 Dec 2014 08:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=++NmVGVyImJBS721lByTWowLVITc/EnvOF5jnl3kz94=; b=StXAQtNu+WGO0I1aDr0f7B4mfoVcaXrhekAH2O6NbbI0XI2VH6F/BF3gGi++OlPA5j 2By1qTk6qRCCeorygwhmFSt6PBEfMkUyUjv/XtwUo3vVLN6Sa9tHazJWinRw1YvUhf1z sKFOR/zEcqkBQ4LRImNLpgiA35MsgbWHsL9Y1z3gfscRYBRPY/UWowViFU4Z9eeAqHyl 5lESaDS7mSfKS3Amx1/wW5q7+YJRsYXBqYe4pPVyX1wwfzsXDrboHaA7gKQWqnPp2gEm kb1zswDaUh+xpbwpUx2yv7UwKJaVQ/TpEmDVJMpd1EnQ/IU0JyDuiq7yqOQGGiuk9bfn AerA== X-Received: by 10.68.202.1 with SMTP id ke1mr8615523pbc.139.1418230084794; Wed, 10 Dec 2014 08:48:04 -0800 (PST) Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id qg2sm4740899pdb.5.2014.12.10.08.48.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 08:48:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)) From: Sam Aldrin In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D34778BF3@xmb-rcd-x15.cisco.com> Date: Wed, 10 Dec 2014 08:48:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <171282AF-633A-4CEC-B4FB-3F2BA3914AF3@gmail.com> References: <20141126005002.GL20330@pfrc> <20141128194337.GE1274@pfrc> <315041E4211CB84E86EF7C25A2AB583D34778BF3@xmb-rcd-x15.cisco.com> To: "Vengada Prasad Govindan (venggovi)" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/__-MmYauNfwLMpsPSyKUbO7qHhU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 16:48:08 -0000 Not aware of any IPR related to this draft. -sam > On Dec 10, 2014, at 8:16 AM, Vengada Prasad Govindan (venggovi) = wrote: >=20 > Hello Jeff, > I am not aware of any IPR related to this draft. > Thanks > Prasad >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey = Haas > Sent: Saturday, November 29, 2014 1:14 AM > To: rtg-bfd@ietf.org > Subject: IPR Reminder (was Re: Adoption poll for = draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)) >=20 > The chairs would like to take this opportunity to remind everyone that = if you have IPR on this Internet-draft - or any other draft - to = disclose it as soon as possible. >=20 > -- Jeff & Nobo >=20 > On Tue, Nov 25, 2014 at 07:50:02PM -0500, Jeffrey Haas wrote: >> Working Group, >>=20 >> Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications,=20= >> was presented at IETF-91 in Honolulu and was positively received. =20 >> We'd like to ask the Working Group whether we should formally adopt=20= >> this draft as a Working Group item. >>=20 >> Please indicate your support or lack thereof to the mail list by=20 >> December 12, 2014. >>=20 >> Also, please supply feedback to the authors. I believe the = perception=20 >> of this document is that it's very nearly complete and thus should=20 >> have a short lifetime prior to publication as an RFC. >>=20 >> -- Jeff & Nobo. >=20 From nobody Wed Dec 10 17:58:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15211A0377; Wed, 10 Dec 2014 17:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 KjA4W9OXPWRJ; Wed, 10 Dec 2014 17:58:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C811A1AAA; Wed, 10 Dec 2014 17:58:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-seamless-use-case-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141211015835.3515.21327.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 17:58:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/mGqP0dXQOpLA4_Z1p8SkKBhEppk Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 01:58:37 -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 Working Group of the IETF. Title : Seamless Bidirectional Forwarding Detection (BFD) Use Case Authors : Sam Aldrin Manav Bhatia Greg Mirsky Nagendra Kumar Satoru Matsushima Filename : draft-ietf-bfd-seamless-use-case-01.txt Pages : 10 Date : 2014-12-10 Abstract: This document provides various use cases for Bidirectional Forwarding Detection (BFD) such that simplified solution and extensions could be developed for detecting forwarding failures. 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: http://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-use-case-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 10 18:33:38 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC951A1B5D for ; Wed, 10 Dec 2014 18:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 q_-fKVfCbj4Q for ; Wed, 10 Dec 2014 18:33:36 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 29E121A0162 for ; Wed, 10 Dec 2014 18:33:36 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-37-5488a5e7fea7 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D0.68.25146.7E5A8845; Wed, 10 Dec 2014 20:58:31 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 21:33:33 -0500 From: Gregory Mirsky To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)) Thread-Topic: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)) Thread-Index: AQHQC0OfoXDaGKFXtE6S058TJUgu0JyJvtMw Date: Thu, 11 Dec 2014 02:33:33 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8B1CC2@eusaamb103.ericsson.se> References: <20141126005002.GL20330@pfrc> <20141128194337.GE1274@pfrc> In-Reply-To: <20141128194337.GE1274@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyuXSPn+7zpR0hBrueyFnsP/iW1eLzn22M DkweS5b8ZPK43LuVNYApissmJTUnsyy1SN8ugStj3y2zgsecFZ/OnmJvYHzL3sXIwSEhYCKx eW10FyMnkCkmceHeerYuRi4OIYEjjBJbP8xjhnCWM0pMm7+OEaSKTcBI4sXGHnYQW0TAQ6L7 2HOwuLBAuUTPx0OMIENFBCok9t0RgCgxkmi5+YkJxGYRUJW49HolC4jNK+Ar8e7HF2YQW0jA TWLJhWdMIK2cApoSO87Ug4QZge75fmoNWCuzgLjErSfzmSDuFJBYsuc8M4QtKvHy8T9WCFtR Yl//dHaIeh2JBbs/sUHY2hLLFr5mhlgrKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxi5Cgt Ti3LTTcy3MQIjINjEmyOOxgXfLI8xCjAwajEw/uhrj1EiDWxrLgy9xCjNAeLkjivZvW8YCGB 9MSS1OzU1ILUovii0pzU4kOMTBycUg2MSrpzrULTvzCGve1dp7DTZnvQqfUFsvlOWlLCBYs3 rtycXsDXL1/ZoJIuqvH2gbbe+it5yez/q84ctvY+fj/iRubyR49+GbEtXzW1tPLE3CaDkrq7 q/o6NxttL+FXvaTL3L+ktmerdySfO9sd0eZUU6ttS9lO38npdBGc8vf5iYCTq5VfpXoosRRn JBpqMRcVJwIAOG8BM2QCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KxGqClEJofmRcHHnAHIdUc2sLBk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 02:33:37 -0000 I am not aware of any IPR that is related to this draft. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Saturday, November 29, 2014 3:44 AM To: rtg-bfd@ietf.org Subject: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-cl= arifications (ends December 12, 2014)) The chairs would like to take this opportunity to remind everyone that if y= ou have IPR on this Internet-draft - or any other draft - to disclose it as= soon as possible. -- Jeff & Nobo On Tue, Nov 25, 2014 at 07:50:02PM -0500, Jeffrey Haas wrote: > Working Group, >=20 > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications,=20 > was presented at IETF-91 in Honolulu and was positively received. =20 > We'd like to ask the Working Group whether we should formally adopt=20 > this draft as a Working Group item. >=20 > Please indicate your support or lack thereof to the mail list by=20 > December 12, 2014. >=20 > Also, please supply feedback to the authors. I believe the perception=20 > of this document is that it's very nearly complete and thus should=20 > have a short lifetime prior to publication as an RFC. >=20 > -- Jeff & Nobo. From nobody Wed Dec 10 18:42:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E001A1B63 for ; Wed, 10 Dec 2014 18:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 9qgT9FG4Wcyz for ; Wed, 10 Dec 2014 18:42:19 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0951A1B2F for ; Wed, 10 Dec 2014 18:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1277; q=dns/txt; s=iport; t=1418265740; x=1419475340; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HS2sYUEoTQnFvL1WS0nZd6TwzXZ3DIvfrQTBOqcrmsU=; b=la0grFsi4VQHEUn9qW2jh8VoT5R++O+sYlQfUJjkHz/f72GvP3jhveY1 RvAqZWcX1XhjL3pj00X5E2+DWr7W06ARoBkb7e2+FDP3IDTvercWKrpju lSCFukjK56VucnnDy4PWzUQFqa/Nn4NsedR7YzWiuLlKrAbtEg5ZeNPeI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssFAEMEiVStJV2R/2dsb2JhbABZgmQigSoEw0SIKwKBGRYBAQEBAX2EDAEBAQQ6SwQCAQgOAwQBAQEKFAUEBzIUCQgCBAESCIgwAdgjAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4xPgmMBAR44BoMbgRUBBIwsgVaJfYJchWMthAODX4IwgT5ugQw5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,555,1413244800"; d="scan'208";a="379374875" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 11 Dec 2014 02:41:58 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBB2fvAS008628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 02:41:57 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 20:41:57 -0600 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)) Thread-Topic: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)) Thread-Index: AQHQC0Ora+hlEvysSUGh/NnA1sKM25yJwUmw Date: Thu, 11 Dec 2014 02:41:56 +0000 Message-ID: References: <20141126005002.GL20330@pfrc> <20141128194337.GE1274@pfrc> In-Reply-To: <20141128194337.GE1274@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.134.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/WXfpJd4IIBjAn6taxBUE2ehaWxw X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 02:42:20 -0000 I am not aware of any IPR that applies to this document. Thanks! -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Friday, November 28, 2014 2:44 PM > To: rtg-bfd@ietf.org > Subject: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884- > clarifications (ends December 12, 2014)) >=20 > The chairs would like to take this opportunity to remind everyone that if > you have IPR on this Internet-draft - or any other draft - to disclose it= as soon > as possible. >=20 > -- Jeff & Nobo >=20 > On Tue, Nov 25, 2014 at 07:50:02PM -0500, Jeffrey Haas wrote: > > Working Group, > > > > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, > > was presented at IETF-91 in Honolulu and was positively received. > > We'd like to ask the Working Group whether we should formally adopt > > this draft as a Working Group item. > > > > Please indicate your support or lack thereof to the mail list by > > December 12, 2014. > > > > Also, please supply feedback to the authors. I believe the perception > > of this document is that it's very nearly complete and thus should > > have a short lifetime prior to publication as an RFC. > > > > -- Jeff & Nobo. From nobody Fri Dec 12 10:09:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFF31A0141 for ; Fri, 12 Dec 2014 10:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 HLFC_MbqKflk for ; Fri, 12 Dec 2014 10:09:28 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19661A00B7 for ; Fri, 12 Dec 2014 10:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1086; q=dns/txt; s=iport; t=1418407767; x=1419617367; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Fk6SON8jtrdaueqsrJ4AVVWuNcyOfl+5w22fPKvq6Qc=; b=knqj/zmCe6j5DCyBOhIFLLNyXIE0Z/4Uo9dZN4GEAZSvwA0nWRJghRiX rwDSHW/bjqOLwyeHzA13/3sVBNkuS/aEbMf6v4qZNwQFgi9OtR4htHtM/ cEkeRfcwdW0HOoleH0vEu2azlOcEvyPbyzAwyX2IEX/viTYwRK1xTwAad 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANQui1StJA2K/2dsb2JhbABZgmQigS7LaQKBFhYBAQEBAX2EDgEDAToxIAEqFEImAQQbE4gJCAGyQKYCAQEBAQYBAQEBAR2PBTyDToETBYwqgVWJeoJeh0OCU4M4IoNsgjN+AQEB X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="105244056" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 12 Dec 2014 18:09:27 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBCI9RvY012114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 12 Dec 2014 18:09:27 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 12:09:26 -0600 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: S-BFD port allocation Thread-Topic: S-BFD port allocation Thread-Index: AdAWNnPRsInEU61oRKiIebSET7H+hg== Date: Fri, 12 Dec 2014 18:09:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/q57uKl73cRLNLXCY78_aiPJKtIQ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 18:09:30 -0000 BFD WG, Here's an update of the allocation of S-BFD ports, and we need your input &= consensus to decide how to proceed forward. >> s-bfd (request #7784) >> s-bfd-echo (request #7785) Comments from expert review is that the BFD WG should not continue to alloc= ate new ports for every BFD feature. It looks like this point was brought u= p when we progressed BFD on LAG back in 2012. However, this may not be easi= ly achievable by BFD unless the BFD header had some sort of a Type field. G= iven where we are with the BFD, and the S-BFD progress, experts have offere= d a compromising solution for the S-BFD port allocation. 1. Continue with s-bfd (request #7784) port allocation. 2. Cancel s-bfd-echo (request #7785) and let standards/implementations figu= re out a way to reuse port 3785. 3. For any further port allocations for BFD features, consider feature demu= x logic within the BFD layer. This may require us to define v2 BFD. Please chime in and provide comments, especially if you have objections to = this direction. Thanks! -Nobo & Jeff From nobody Mon Dec 15 05:25:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AA21A1BEE for ; Mon, 15 Dec 2014 05:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 KgAo0VeK1gQB for ; Mon, 15 Dec 2014 05:25:46 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60CB1A1BE7 for ; Mon, 15 Dec 2014 05:25:46 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB824.namprd05.prod.outlook.com (10.141.244.146) with Microsoft SMTP Server (TLS) id 15.1.31.17; Mon, 15 Dec 2014 13:25:44 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0031.000; Mon, 15 Dec 2014 13:25:45 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: RE: S-BFD port allocation Thread-Topic: S-BFD port allocation Thread-Index: AdAWNnPRsInEU61oRKiIebSET7H+hgCMuADA Date: Mon, 15 Dec 2014 13:25:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-forefront-prvs: 04267075BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(189002)(41574002)(64706001)(99286002)(20776003)(54606007)(2656002)(74316001)(92566001)(105586002)(46102003)(86362001)(99396003)(122556002)(120916001)(40100003)(107886001)(54356999)(76176999)(66066001)(87936001)(33656002)(21056001)(4396001)(106356001)(54206007)(50986999)(77096005)(107046002)(31966008)(97736003)(101416001)(77156002)(102836002)(68736005)(76576001)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB824; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SfRhP2qkyE-ZdLsOAlezGF_k-kI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 13:25:48 -0000 Nobo, > 2. Cancel s-bfd-echo (request #7785) and let standards/implementations > figure out a way to reuse port 3785. If we are not using separate port number then we might need to dig in to pa= yload of BFD. Not all hardware can do this right? Will this become a bottle= neck for S-BFD which are hardware based? I am assuming that few hardware im= plementation might not do any parsing of S-BFD packets but will simply do a= blind compare of received packet with template from software? To do this i= t might want to check if this is S-BFD echo or legacy BFD echo so that it c= an take right path.=20 > 3. For any further port allocations for BFD features, consider feature de= mux > logic within the BFD layer. This may require us to define v2 BFD. I agree :).=20 Thanks Santosh P K=20 =20 > 3. For any further port allocations for BFD features, consider feature de= mux > logic within the BFD layer. This may require us to define v2 BFD. >=20 > Please chime in and provide comments, especially if you have objections t= o > this direction. >=20 > Thanks! >=20 > -Nobo & Jeff From nobody Mon Dec 15 15:02:01 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBE81A6F62 for ; Mon, 15 Dec 2014 15:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 GibYMRP5gbyd for ; Mon, 15 Dec 2014 15:01:59 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549FA1A6F32 for ; Mon, 15 Dec 2014 15:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1995; q=dns/txt; s=iport; t=1418684520; x=1419894120; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3XFaKaDCdbwuZVksC5oPq3P5XYTvlo4cRVIwhpoAwCE=; b=FtgqCoov794B+B2PNvBkW4qajNjXbf0W0ff6PyfiONR3Gp4ZZZ2XQULt OmRCtdky0keTjVaHQXFIGIw0y0sGeCU+dUUMbm+KFt5RbMbb5mTGdItGY K9WWHXoCtw4rUlPZ98/3VNvKGtm0Y/3a/gg3rmt/RaCoJ5fp9PiE8O453 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAABoj1StJA2H/2dsb2JhbABagmQigS7LTgKBIRYBAQEBAX2EDQEBAwE6TwIBCCIUEDIlAQEEARqIHAgB1HkBAQEBAQEBAQEBAQEBAQEBAQEBGY9BOIMWgRMFjCyBVol6gl6KFoM4IoNsgjN+AQEB X-IronPort-AV: E=Sophos;i="5.07,582,1413244800"; d="scan'208";a="377406388" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 15 Dec 2014 23:01:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBFN1wkU007828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 23:01:58 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 17:01:58 -0600 From: "Nobo Akiya (nobo)" To: Santosh P K , "rtg-bfd@ietf.org" Subject: RE: S-BFD port allocation Thread-Topic: S-BFD port allocation Thread-Index: AdAWNnPRsInEU61oRKiIebSET7H+hgCMuADAABMxvgA= Date: Mon, 15 Dec 2014 23:01:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dUMROXpmq_I0cVsX1CCo8ghfsQM X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 23:02:00 -0000 Hi Santosh, et al, Thanks for providing your opinion. I also received a private comment from a= nother person saying "let's push for S-BFD echo port allocation". Let me, however, play devil's advocate on (2), as I don't think we have eno= ugh good arguments against the port allocation push back for S-BFD echo. > > 2. Cancel s-bfd-echo (request #7785) and let standards/implementations > > figure out a way to reuse port 3785. >=20 > If we are not using separate port number then we might need to dig in to > payload of BFD. Not all hardware can do this right? Will this become a > bottleneck for S-BFD which are hardware based? I am assuming that few > hardware implementation might not do any parsing of S-BFD packets but > will simply do a blind compare of received packet with template from > software? To do this it might want to check if this is S-BFD echo or lega= cy > BFD echo so that it can take right path. 1) I do agree that BFD feature demux is easier off of lower layer informati= on (i.e., dest port). 2) New lower layer information to demux new BFD feature will allow clean in= troduction of new BFD features. However, if we were to go down the path of demux logic within the BFD layer= in the future, what you described above as "difficult" is exactly what imp= lementations will have to do. So, doing this with BFD/S-BFD echo on 3785 is= a good starting point. What do you think? Thanks! -Nobo >=20 >=20 > > 3. For any further port allocations for BFD features, consider feature > > demux logic within the BFD layer. This may require us to define v2 BFD. >=20 > I agree :). >=20 >=20 > Thanks > Santosh P K >=20 >=20 > > 3. For any further port allocations for BFD features, consider feature > > demux logic within the BFD layer. This may require us to define v2 BFD. > > > > Please chime in and provide comments, especially if you have > > objections to this direction. > > > > Thanks! > > > > -Nobo & Jeff From nobody Tue Dec 16 21:44:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A1D1A1BFC for ; Tue, 16 Dec 2014 21:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 aikphpVsQbJG for ; Tue, 16 Dec 2014 21:44:47 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FF71A1BFA for ; Tue, 16 Dec 2014 21:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2848; q=dns/txt; s=iport; t=1418795087; x=1420004687; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2qBtu+jaCVZCTYQFBSbOyL1802R2J5q2BcA2QRf8zDg=; b=FMWNWjj5VQLuNGyTzbD718T1gbHdv0byTGG/lp9urIIzK6jKHCws72ni Xfhq5pNWJEMA6+Oh0HxAMXU1/SAT2jBYjx1JXod5wv9mDclDy40E2w2cp H2kDZsUR4ncaW0BtJP2j6iLdt9BWYgqLRjOa2pHFRxgWL3tatIzGQE7fJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFADoXkVStJV2Q/2dsb2JhbABagwaBKgTDXIgXAoEbFgEBAQEBfYQMAQEBAwE6OhEEAgEIEQQBAQsUCQcyFAkIAQEEARIIiBwI1EMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjw8yOAaDEIETBYwxgVaJe4JeihiDOCKDbG6BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,591,1413244800"; d="scan'208";a="106211141" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP; 17 Dec 2014 05:44:46 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sBH5ijg1000724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 05:44:46 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.86]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 23:44:45 -0600 From: "Vengada Prasad Govindan (venggovi)" To: "Nobo Akiya (nobo)" , Santosh P K , "rtg-bfd@ietf.org" Subject: RE: S-BFD port allocation Thread-Topic: S-BFD port allocation Thread-Index: AdAWNnPRsInEU61oRKiIebSET7H+hgCMuADAABMxvgAAQNLiwA== Date: Wed, 17 Dec 2014 05:44:45 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D347AEF66@xmb-rcd-x15.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Kb9qBWFQXNlGtTtOxLuhEtNzGUI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 05:44:49 -0000 Hello Nobo, I agree with your thoughts on absorbing the complexity of de-multiplexing= S-BFD v/s classical BFD based on the contents of the echo packet and not r= ely on the destination port. However, the destination port for S-BFD Async = packets will have to be different to help current implementation efforts. W= ithout it, it becomes difficult for implementations to go back to the drawi= ng board at this stage. A related question in this context would be: Would = the (future) de-mupltiplex header affect current S-BFD Async or echo packe= t formats ? =20 Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Tuesday, December 16, 2014 4:32 AM To: Santosh P K; rtg-bfd@ietf.org Subject: RE: S-BFD port allocation Hi Santosh, et al, Thanks for providing your opinion. I also received a private comment from a= nother person saying "let's push for S-BFD echo port allocation". Let me, however, play devil's advocate on (2), as I don't think we have eno= ugh good arguments against the port allocation push back for S-BFD echo. > > 2. Cancel s-bfd-echo (request #7785) and let=20 > > standards/implementations figure out a way to reuse port 3785. >=20 > If we are not using separate port number then we might need to dig in=20 > to payload of BFD. Not all hardware can do this right? Will this=20 > become a bottleneck for S-BFD which are hardware based? I am assuming=20 > that few hardware implementation might not do any parsing of S-BFD=20 > packets but will simply do a blind compare of received packet with=20 > template from software? To do this it might want to check if this is=20 > S-BFD echo or legacy BFD echo so that it can take right path. 1) I do agree that BFD feature demux is easier off of lower layer informati= on (i.e., dest port). 2) New lower layer information to demux new BFD feature will allow clean in= troduction of new BFD features. However, if we were to go down the path of demux logic within the BFD layer= in the future, what you described above as "difficult" is exactly what imp= lementations will have to do. So, doing this with BFD/S-BFD echo on 3785 is= a good starting point. What do you think? Thanks! -Nobo >=20 >=20 > > 3. For any further port allocations for BFD features, consider=20 > > feature demux logic within the BFD layer. This may require us to define= v2 BFD. >=20 > I agree :). >=20 >=20 > Thanks > Santosh P K >=20 >=20 > > 3. For any further port allocations for BFD features, consider=20 > > feature demux logic within the BFD layer. This may require us to define= v2 BFD. > > > > Please chime in and provide comments, especially if you have=20 > > objections to this direction. > > > > Thanks! > > > > -Nobo & Jeff From nobody Tue Dec 16 21:57:38 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8C21A1DBD for ; Tue, 16 Dec 2014 21:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 89IOgeqG3k4Q for ; Tue, 16 Dec 2014 21:57:26 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7C71A1DBC for ; Tue, 16 Dec 2014 21:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8823; q=dns/txt; s=iport; t=1418795846; x=1420005446; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ORGq2aqTCmcz6e8PLILeknm37pBhjMobGYg6DcrTuwo=; b=aAdHrqNnxtDicAELT24UelsB13JoNp2WfllKQRcLdERIgNZAsdZnwzh/ 7bNmVA93+H8YeRbnHZMqdH82yoYIO8dS4rX4hSwqn4J9pE35ueiuFbiS8 oZ+pkcnErZboIa0UVZNakSuQxA7867c7kLU/lsokPPq9LIvj80fdqR8wa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFAAUakVStJA2G/2dsb2JhbABagkNDgSoEw16IFwKBGxYBAQEBAX2EDAEBAQMBDHINAQgRAwECKCYTFAkIAQEEARKIJAjULAEBAQEBAQQBAQEBAQEBARqPYRiEKQWMMYFWBIhsgQuCXooYgzgig2xugUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,591,1413244800"; d="scan'208,217";a="380720685" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 17 Dec 2014 05:57:26 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sBH5vPfq014323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 05:57:25 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.176]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 23:57:25 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "Nobo Akiya (nobo)" , Santosh P K , "rtg-bfd@ietf.org" Subject: Re: S-BFD port allocation Thread-Topic: S-BFD port allocation Thread-Index: AdAWNnPRsInEU61oRKiIebSET7H+hgCMuADAABMxvgAAWicfAA== Date: Wed, 17 Dec 2014 05:57:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.106] Content-Type: multipart/alternative; boundary="_000_D0B717A528E95mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SE6nDOlmxcAt6ER98zKU-Y-3Y1c X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 05:57:35 -0000 --_000_D0B717A528E95mmudigonciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Nobo et al, Please find my responses inline Regards Mallik From: "Nobo Akiya (nobo)" > Date: Tuesday, 16 December 2014 4:31 am To: Santosh P K >, "rtg= -bfd@ietf.org" > Subject: RE: S-BFD port allocation Hi Santosh, et al, Thanks for providing your opinion. I also received a private comment from a= nother person saying "let's push for S-BFD echo port allocation". Mallik>> I agree with this suggestion. When classic BFD can have two ports = for Async and Echo, why is this an issue for SBFD? Let me, however, play devil's advocate on (2), as I don't think we have eno= ugh good arguments against the port allocation push back for S-BFD echo. > 2. Cancel s-bfd-echo (request #7785) and let standards/implementations > figure out a way to reuse port 3785. If we are not using separate port number then we might need to dig in to payload of BFD. Not all hardware can do this right? Will this become a bottleneck for S-BFD which are hardware based? I am assuming that few hardware implementation might not do any parsing of S-BFD packets but will simply do a blind compare of received packet with template from software? To do this it might want to check if this is S-BFD echo or legacy BFD echo so that it can take right path. 1) I do agree that BFD feature demux is easier off of lower layer informati= on (i.e., dest port). Mallik>> Yes. There are implementations today which does it based on Destin= ation port. 2) New lower layer information to demux new BFD feature will allow clean in= troduction of new BFD features. However, if we were to go down the path of demux logic within the BFD layer= in the future, what you described above as "difficult" is exactly what imp= lementations will have to do. So, doing this with BFD/S-BFD echo on 3785 is= a good starting point. Mallik>> It is easier to demux classic echo verses SBFD echo if we use 3785= because we have the =93D=94 bit that is set by the initiator. But then imp= lementation will have to look deeper inside BFD/SBFD packets which may be o= ne of the reasons for asking for a separate port. What do you think? Mallik>> If we plan to implement additional headers in BFD packets for demu= x purpose then it is time we start discussing the same. Thanks! -Nobo > 3. For any further port allocations for BFD features, consider feature > demux logic within the BFD layer. This may require us to define v2 BFD. I agree :). Thanks Santosh P K > 3. For any further port allocations for BFD features, consider feature > demux logic within the BFD layer. This may require us to define v2 BFD. > > Please chime in and provide comments, especially if you have > objections to this direction. > > Thanks! > > -Nobo & Jeff --_000_D0B717A528E95mmudigonciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0D97F81D2A50934AB2FB10717842A53C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Nobo et al,

Please find my responses inline

Regards
Mallik

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Tuesday, 16 December 2014 4:3= 1 am
To: Santosh P K <santoshpk@juniper.net>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: S-BFD port allocation<= br>

Hi Santosh, et al,

Thanks for providing your opinion. I also received a private comment f= rom another person saying "let's push for S-BFD echo port allocation&q= uot;.

Mallik>> I agree with this suggestion. When classic BFD can have= two ports for Async and Echo, why is this an issue for SBFD?

Let me, however, play devil's advocate on (2), as I don't think we hav= e enough good arguments against the port allocation push back for S-BFD ech= o.

> 2. Cancel s-bfd-echo (request #7785) and let standards/implementa= tions
> figure out a way to reuse port 3785.
If we are not using separate port number then we might need to dig in = to
payload of BFD. Not all hardware can do this right? Will this become a=
bottleneck for S-BFD which are hardware based? I am assuming that few<= /div>
hardware implementation might not do any parsing of S-BFD packets but<= /div>
will simply do a blind compare of received packet with template from
software? To do this it might want to check if this is S-BFD echo or l= egacy
BFD echo so that it can take right path.

1) I do agree that BFD feature demux is easier off of lower layer info= rmation (i.e., dest port).

Mallik>> Yes. There are implementations today which does it base= d on Destination port.

2) New lower layer information to demux new BFD feature will allow cle= an introduction of new BFD features.

However, if we were to go down the path of demux logic within the BFD = layer in the future, what you described above as "difficult" is e= xactly what implementations will have to do. So, doing this with BFD/S-BFD = echo on 3785 is a good starting point.

Mallik>> It is easier to demux classic echo verses SBFD echo if = we use 3785 because we have the =93D=94 bit that is set by the initiator. B= ut then implementation will have to look deeper inside BFD/SBFD packets whi= ch may be one of the reasons for asking for a separate port.

What do you think?

Mallik>> If we plan to implement additional headers in BFD packe= ts for demux purpose then it is time we start discussing the same.

Thanks!

-Nobo

> 3. For any further port allocations for BFD features, consider fe= ature
> demux logic within the BFD layer. This may require us to define v= 2 BFD.
I agree :).
Thanks
Santosh P K
> 3. For any further port allocations for BFD features, consider fe= ature
> demux logic within the BFD layer. This may require us to define v= 2 BFD.
>
> Please chime in and provide comments, especially if you have
> objections to this direction.
>
> Thanks!
>
> -Nobo & Jeff


 --_000_D0B717A528E95mmudigonciscocom_-- From nobody Wed Dec 17 06:09:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1495A1A1AF1 for ; Wed, 17 Dec 2014 06:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 1AoW1l_l2LEK for ; Wed, 17 Dec 2014 06:08:57 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B271A1BDC for ; Wed, 17 Dec 2014 06:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4220; q=dns/txt; s=iport; t=1418825337; x=1420034937; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+KnKJJ/IS52YtBQHwdzz/zV2dIFncL9ddSg1k4IASuo=; b=E3abePE3lTuPpjVXps96GxwPGHeSRjaXTsUWjoTB+xm+vL1EE3CsWz2s mw1IoXPz9N6MBbqCfSVv5/0xpKefKNQxzR7YF3qJENbTpY3ZrtXKpZEK1 zHFd36X4LN5LACmUmPMBXxiZibXYDzDuvwq7sfZks0HgnboQb9zxJhIS8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAA6OkVStJA2F/2dsb2JhbABagmQigSoEy2QCgR8WAQEBAQF9hAwBAQEDATo6CgcEAgEIEQQBAQsUCQcyFAkIAQEEARIIiBwIAdRgAQEBAQEBAQEBAQEBAQEBAQEBAQEBF48PMjgGgxCBEwWMMoFWiXuCYYocgzgig2xvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="380890233" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP; 17 Dec 2014 14:08:57 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sBHE8uoU031326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 14:08:56 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 08:08:56 -0600 From: "Nobo Akiya (nobo)" To: "Vengada Prasad Govindan (venggovi)" , Santosh P K , "rtg-bfd@ietf.org" Subject: RE: S-BFD port allocation Thread-Topic: S-BFD port allocation Thread-Index: AdAWNnPRsInEU61oRKiIebSET7H+hgCMuADAABMxvgAAQNLiwAASPItA Date: Wed, 17 Dec 2014 14:08:55 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D347AEF66@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D347AEF66@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/IDOrTSNwhtM32r_NYJo9e3fHo74 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 14:09:00 -0000 Hi Prasad, > I agree with your thoughts on absorbing the complexity of de-multiplexi= ng > S-BFD v/s classical BFD based on the contents of the echo packet and not > rely on the destination port. It is good to know that one vendor thinks S-BFD echo reusing 3785 is a poss= ibility. > However, the destination port for S-BFD Async > packets will have to be different to help current implementation efforts. > Without it, it becomes difficult for implementations to go back to the > drawing board at this stage. I agree. We definitely need a new port for S-BFD async. > A related question in this context would be: > Would the (future) de-mupltiplex header affect current S-BFD Async or > echo packet formats ? I would guess that BFD layer demux will require an additional field to do s= o, and we all know that BFD v1 has difficulty finding a space for any addit= ional fields. This is up for discussion, and it is up to the "new approach"= to ensure that changes are backwards compatible. Thanks! -Nobo > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) > Sent: Wednesday, December 17, 2014 12:45 AM > To: Nobo Akiya (nobo); Santosh P K; rtg-bfd@ietf.org > Subject: RE: S-BFD port allocation >=20 > Hello Nobo, > I agree with your thoughts on absorbing the complexity of de-multiplexi= ng > S-BFD v/s classical BFD based on the contents of the echo packet and not > rely on the destination port. However, the destination port for S-BFD Asy= nc > packets will have to be different to help current implementation efforts. > Without it, it becomes difficult for implementations to go back to the > drawing board at this stage. A related question in this context would be: > Would the (future) de-mupltiplex header affect current S-BFD Async or > echo packet formats ? > Thanks > Prasad >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Tuesday, December 16, 2014 4:32 AM > To: Santosh P K; rtg-bfd@ietf.org > Subject: RE: S-BFD port allocation >=20 > Hi Santosh, et al, >=20 > Thanks for providing your opinion. I also received a private comment from > another person saying "let's push for S-BFD echo port allocation". >=20 > Let me, however, play devil's advocate on (2), as I don't think we have > enough good arguments against the port allocation push back for S-BFD > echo. >=20 > > > 2. Cancel s-bfd-echo (request #7785) and let > > > standards/implementations figure out a way to reuse port 3785. > > > > If we are not using separate port number then we might need to dig in > > to payload of BFD. Not all hardware can do this right? Will this > > become a bottleneck for S-BFD which are hardware based? I am assuming > > that few hardware implementation might not do any parsing of S-BFD > > packets but will simply do a blind compare of received packet with > > template from software? To do this it might want to check if this is > > S-BFD echo or legacy BFD echo so that it can take right path. >=20 > 1) I do agree that BFD feature demux is easier off of lower layer informa= tion > (i.e., dest port). > 2) New lower layer information to demux new BFD feature will allow clean > introduction of new BFD features. >=20 > However, if we were to go down the path of demux logic within the BFD > layer in the future, what you described above as "difficult" is exactly w= hat > implementations will have to do. So, doing this with BFD/S-BFD echo on > 3785 is a good starting point. >=20 > What do you think? >=20 > Thanks! >=20 > -Nobo >=20 > > > > > > > 3. For any further port allocations for BFD features, consider > > > feature demux logic within the BFD layer. This may require us to defi= ne > v2 BFD. > > > > I agree :). > > > > > > Thanks > > Santosh P K > > > > > > > 3. For any further port allocations for BFD features, consider > > > feature demux logic within the BFD layer. This may require us to defi= ne > v2 BFD. > > > > > > Please chime in and provide comments, especially if you have > > > objections to this direction. > > > > > > Thanks! > > > > > > -Nobo & Jeff From nobody Wed Dec 17 06:16:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E521A1AA4 for ; Wed, 17 Dec 2014 06:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 EhaboOfMGiPv for ; Wed, 17 Dec 2014 06:16:45 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DF41A1AF1 for ; Wed, 17 Dec 2014 06:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25464; q=dns/txt; s=iport; t=1418825805; x=1420035405; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ilxGtNgwm8egPsdZxKxvsrnAJKcHRvez/OkimjCRb+M=; b=P7No908G0wYgiDi9yE8kZEGH8Ygw5hEG5gw90Mj7kxfPorzhhHZNe0Y1 mzM0xyKZE/klncZZXOiC2Tzyjsi+vhgmDrEVHH7T7U5u65RtTCCCRqJvG nyDxUtNj9YKT4QYHoMiZTDZuc462G1kMLGYjUIAneGJgjIqnaacH2FngQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAGmPkVStJA2L/2dsb2JhbABagkMhIlJYBMtkAoEfFgEBAQEBfYQMAQEBAwEMIVELAgEIEQMBAQELFgcHMhQJCAEBBAESCIgcCAHUYgEBAQEBAQEBAQEBAQEBAQEBAQEBARePQSAXAYMWgRMFjDKBVol7gmGKHIM4IoNsb4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208,217";a="380779637" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 17 Dec 2014 14:16:43 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sBHEGhE8015100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 14:16:43 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 08:16:43 -0600 From: "Nobo Akiya (nobo)" To: "MALLIK MUDIGONDA (mmudigon)" , Santosh P K , "rtg-bfd@ietf.org" Subject: RE: S-BFD port allocation Thread-Topic: S-BFD port allocation Thread-Index: AdAWNnPRsInEU61oRKiIebSET7H+hgCMuADAABMxvgAAWicfAAAG622g Date: Wed, 17 Dec 2014 14:16:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.106] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F64AAEBxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/oYsA2yre0xxHKzuVrB8SxSnWGSw X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 14:16:51 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943F64AAEBxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mallik, Please see in-line with [NOBO]. From: MALLIK MUDIGONDA (mmudigon) Sent: Wednesday, December 17, 2014 12:57 AM To: Nobo Akiya (nobo); Santosh P K; rtg-bfd@ietf.org Subject: Re: S-BFD port allocation Hi Nobo et al, Please find my responses inline Regards Mallik From: "Nobo Akiya (nobo)" > Date: Tuesday, 16 December 2014 4:31 am To: Santosh P K >, "rtg= -bfd@ietf.org" > Subject: RE: S-BFD port allocation Hi Santosh, et al, Thanks for providing your opinion. I also received a private comment from a= nother person saying "let's push for S-BFD echo port allocation". Mallik>> I agree with this suggestion. When classic BFD can have two ports = for Async and Echo, why is this an issue for SBFD? [NOBO] IANA believe that the BFD protocol is abusing the port space. They a= re strongly suggesting that feature demux be done on the feature layer. And= it appears that this isn't the first time this topic was brought up. Thu t= he pushback from IANA. Let me, however, play devil's advocate on (2), as I don't think we have eno= ugh good arguments against the port allocation push back for S-BFD echo. > 2. Cancel s-bfd-echo (request #7785) and let standards/implementations > figure out a way to reuse port 3785. If we are not using separate port number then we might need to dig in to payload of BFD. Not all hardware can do this right? Will this become a bottleneck for S-BFD which are hardware based? I am assuming that few hardware implementation might not do any parsing of S-BFD packets but will simply do a blind compare of received packet with template from software? To do this it might want to check if this is S-BFD echo or legacy BFD echo so that it can take right path. 1) I do agree that BFD feature demux is easier off of lower layer informati= on (i.e., dest port). Mallik>> Yes. There are implementations today which does it based on Destin= ation port. [NOBO] And we will need to revisit this, if we are to do feature demux in t= he BFD layer. 2) New lower layer information to demux new BFD feature will allow clean in= troduction of new BFD features. However, if we were to go down the path of demux logic within the BFD layer= in the future, what you described above as "difficult" is exactly what imp= lementations will have to do. So, doing this with BFD/S-BFD echo on 3785 is= a good starting point. Mallik>> It is easier to demux classic echo verses SBFD echo if we use 3785= because we have the "D" bit that is set by the initiator. But then impleme= ntation will have to look deeper inside BFD/SBFD packets which may be one o= f the reasons for asking for a separate port. [NOBO] I don't disagree. It is easier to be able to demux in the lower laye= r, and I wish this model can be preserved going forward. However, we (BFD W= G) have been flagged by the "police", and we need to look into how this can= be addressed in the BFD layer, going forward. [NOBO] Good thing is that IANA is willing to allow the port for S-BFD async= . And considering echo packet contents is something implementations can def= ine (i.e. having version, type, etc), we _should be_ able to reuse 3785 for= S-BFD echo. Do you think this is true? What do you think? Mallik>> If we plan to implement additional headers in BFD packets for demu= x purpose then it is time we start discussing the same. [NOBO] This can start up now, or this has to start up when there is another= BFD feature requiring a new port. Thanks! -Nobo Thanks! -Nobo > 3. For any further port allocations for BFD features, consider feature > demux logic within the BFD layer. This may require us to define v2 BFD. I agree :). Thanks Santosh P K > 3. For any further port allocations for BFD features, consider feature > demux logic within the BFD layer. This may require us to define v2 BFD. > > Please chime in and provide comments, especially if you have > objections to this direction. > > Thanks! > > -Nobo & Jeff --_000_CECE764681BE964CBE1DFF78F3CDD3943F64AAEBxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mallik,

 <= /p>

Please see in-line with [= NOBO].

 <= /p>

From: MALLIK MUDIGONDA (mmudigon)
Sent: Wednesday, December 17, 2014 12:57 AM
To: Nobo Akiya (nobo); Santosh P K; rtg-bfd@ietf.org
Subject: Re: S-BFD port allocation

 

Hi Nobo et al,

 

Please find my responses inli= ne

 

Regards

Mallik

 

From: "Nobo Akiya (nobo)" <nobo@cisco.com>
Date: Tuesday, 16 December 2014 4:31 am
To: Santosh P K <santosh= pk@juniper.net>, "rtg-bfd@i= etf.org" <rtg-bfd@ietf.org<= /a>>
Subject: RE: S-BFD port allocation

 

Hi Santosh, et al,=

 

Thanks for providing your opi= nion. I also received a private comment from another person saying "le= t's push for S-BFD echo port allocation".

 

Mallik>> I agree with t= his suggestion. When classic BFD can have two ports for Async and Echo, why= is this an issue for SBFD?

 

[NOBO] IANA believe that = the BFD protocol is abusing the port space. They are strongly suggesting th= at feature demux be done on the feature layer. And it appears that this isn’t the first time this topic was brought up. Thu the pu= shback from IANA.

 <= /p>

Let me, however, play devil's= advocate on (2), as I don't think we have enough good arguments against th= e port allocation push back for S-BFD echo.

 

> 2. Cancel s-bfd-echo (re= quest #7785) and let standards/implementations

> figure out a way to reus= e port 3785.

If we are not using separate = port number then we might need to dig in to

payload of BFD. Not all hardw= are can do this right? Will this become a

bottleneck for S-BFD which ar= e hardware based? I am assuming that few

hardware implementation might= not do any parsing of S-BFD packets but

will simply do a blind compar= e of received packet with template from

software? To do this it might= want to check if this is S-BFD echo or legacy

BFD echo so that it can take = right path.

 

1) I do agree that BFD featur= e demux is easier off of lower layer information (i.e., dest port).

 

Mallik>> Yes. There are= implementations today which does it based on Destination port.<= /span>

 <= /p>

[NOBO] And we will need t= o revisit this, if we are to do feature demux in the BFD layer.<= /span>

 

2) New lower layer informatio= n to demux new BFD feature will allow clean introduction of new BFD feature= s.

 

However, if we were to go dow= n the path of demux logic within the BFD layer in the future, what you desc= ribed above as "difficult" is exactly what implementations will have to do. So, doing this with BFD/S-BFD echo on 3785 is a good star= ting point.

 

Mallik>> It is easier t= o demux classic echo verses SBFD echo if we use 3785 because we have the &#= 8220;D” bit that is set by the initiator. But then implementation wil= l have to look deeper inside BFD/SBFD packets which may be one of the reason= s for asking for a separate port.

 

[NOBO] I don’t disa= gree. It is easier to be able to demux in the lower layer, and I wish this = model can be preserved going forward. However, we (BFD WG) have been flagged by the “police”, and we need to look into how thi= s can be addressed in the BFD layer, going forward.

 <= /p>

[NOBO] Good thing is that= IANA is willing to allow the port for S-BFD async. And considering echo pa= cket contents is something implementations can define (i.e. having version, type, etc), we _should be_ able to reuse 3785 for S= -BFD echo. Do you think this is true?

 <= /p>

What do you think?=

 

Mallik>> If we plan to = implement additional headers in BFD packets for demux purpose then it is ti= me we start discussing the same.

 

[NOBO] This can start up = now, or this has to start up when there is another BFD feature requiring a = new port.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

Thanks!

 

-Nobo

 

> 3. For any further port = allocations for BFD features, consider feature

> demux logic within the B= FD layer. This may require us to define v2 BFD.

I agree :).=

Thanks

Santosh P K=

> 3. For any further port = allocations for BFD features, consider feature

> demux logic within the B= FD layer. This may require us to define v2 BFD.

> <= /p>

> Please chime in and prov= ide comments, especially if you have

> objections to this direc= tion.

> <= /p>

> Thanks!

> <= /p>

> -Nobo & Jeff

 

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943F64AAEBxmbalnx01ciscoc_-- From nobody Wed Dec 17 12:38:38 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF7E1A7001 for ; Wed, 17 Dec 2014 12:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 w0bNwiItqwAW for ; Wed, 17 Dec 2014 12:38:36 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1373E1A8F34 for ; Wed, 17 Dec 2014 12:38:32 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 846C4C132; Wed, 17 Dec 2014 15:38:31 -0500 (EST) Date: Wed, 17 Dec 2014 15:38:31 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Message-ID: <20141217203831.GD16279@pfrc> References: <20141126005002.GL20330@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141126005002.GL20330@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/XfjDuRdNkGt3McasgdlE9sO02WA X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 20:38:37 -0000 On Tue, Nov 25, 2014 at 07:50:02PM -0500, Jeffrey Haas wrote: > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was > presented at IETF-91 in Honolulu and was positively received. We'd like to > ask the Working Group whether we should formally adopt this draft as a > Working Group item. > > Please indicate your support or lack thereof to the mail list by > December 12, 2014. [This chair is rather behind in his IETF email. Sorry.] We had good response along with the feedback in the room during the IETF session. This document is adopted as a WG item. Authors, please re-submit as draft-ietf-bfd-rfc5884-clarifications. Also, please consider what a reasonable milestone would be for completing the work in this draft. -- Jeff From nobody Wed Dec 17 14:08:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8D21A877D for ; Wed, 17 Dec 2014 14:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 q5_LouEpUpum for ; Wed, 17 Dec 2014 14:08:39 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EE6D71A87DB for ; Wed, 17 Dec 2014 14:08:38 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id B072EC132; Wed, 17 Dec 2014 17:08:38 -0500 (EST) Date: Wed, 17 Dec 2014 17:08:38 -0500 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: S-BFD port allocation Message-ID: <20141217220838.GG16279@pfrc> References: 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: http://mailarchive.ietf.org/arch/msg/rtg-bfd/k6IZyLs6NUWwCHpTPEiIS6hTQ3U Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 22:08:40 -0000 On Wed, Dec 17, 2014 at 02:16:42PM +0000, Nobo Akiya (nobo) wrote: > [NOBO] Good thing is that IANA is willing to allow the port for S-BFD async. And considering echo packet contents is something implementations can define (i.e. having version, type, etc), we _should be_ able to reuse 3785 for S-BFD echo. Do you think this is true? > > What do you think? > > Mallik>> If we plan to implement additional headers in BFD packets for demux purpose then it is time we start discussing the same. > > [NOBO] This can start up now, or this has to start up when there is another BFD feature requiring a new port. I think we have enough breathing room for S-BFD to proceed with a single port for async and letting the remote demux on echo contents with existing BFD echo port from 5880. At least that's how I read the above. I've added the BFDv2 item to my internal TODO list as I mentioned to Nobo. There's already been some thoughts on what we might want out of such a thing in terms of "well known payloads", but I think additional demux is probably the killer app for it. The modeling exercise I'll be recommending when the conversation starts moving is how we would rewrite our existing features to all fit into BFDv2 with a single port assigned. -- Jeff From nobody Thu Dec 18 05:54:31 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852511A89A7 for ; Thu, 18 Dec 2014 05:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 j3EUJFevZgNb for ; Thu, 18 Dec 2014 05:54:28 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9D21A89A3 for ; Thu, 18 Dec 2014 05:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1301; q=dns/txt; s=iport; t=1418910868; x=1420120468; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FRA+22rz4SrO4OuoX2KAQK1OWvtBNzRzPf/F8EGNaWs=; b=dCmPuMjhqaFLPaPcXFXwlQy2nlbHG5mO3xHUsxIjb1/RBKxf05dCzsgZ mElzHfuIzV+7/31LvVVnaahBQ7hmZhorAOIK9RcrXkrI+Encs2YnDaNPo 7C/S06p8mPKmdAMeOzNXg8PB8Gh+Fx/YlWUt3OrAhHZjOk2AmaCaMlKu/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAFrbklStJV2R/2dsb2JhbABagmQigS7MDgKBGxYBAQEBAX2EDAEBAQMBOj8FCwIBCA4KChQQMiUCBA4NiBwIAdUGAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49BMQeDFoETAQSMM4FXiX2FEodrgzgig2yCNH4BAQE X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="381104010" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 18 Dec 2014 13:54:27 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBIDsR6u017440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 13:54:27 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 07:54:27 -0600 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: S-BFD port allocation Thread-Topic: S-BFD port allocation Thread-Index: AdAWNnPRsInEU61oRKiIebSET7H+hgCMuADAABMxvgAAWicfAAAG622gAA958gAAFErZkA== Date: Thu, 18 Dec 2014 13:54:26 +0000 Message-ID: References: <20141217220838.GG16279@pfrc> In-Reply-To: <20141217220838.GG16279@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KYemjj3OYxhSblMB1yn231xEWvw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 13:54:29 -0000 [snipping in only the s-bfd port discussion portion ... to attempt to close= this off] > On Wed, Dec 17, 2014 at 02:16:42PM +0000, Nobo Akiya (nobo) wrote: > > [NOBO] Good thing is that IANA is willing to allow the port for S-BFD a= sync. > And considering echo packet contents is something implementations can > define (i.e. having version, type, etc), we _should be_ able to reuse 378= 5 for > S-BFD echo. Do you think this is true? > > > > What do you think? > > > > Mallik>> If we plan to implement additional headers in BFD packets for > demux purpose then it is time we start discussing the same. > > > > [NOBO] This can start up now, or this has to start up when there is ano= ther > BFD feature requiring a new port. >=20 > I think we have enough breathing room for S-BFD to proceed with a single > port for async and letting the remote demux on echo contents with existin= g > BFD echo port from 5880. At least that's how I read the above. Since there hasn't been any major objection to going with one port for S-BF= D, I'm starting to conclude that this is something which we can live with. = If anyone object, do chime in within few days and provide your reasons. Oth= erwise, we'll provide "let's go ahead with one S-BFD port" to IANA. Thanks! -Nobo From nobody Fri Dec 19 13:02:26 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F28B1A7023 for ; Fri, 19 Dec 2014 13:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 yrQynUtv2L_y for ; Fri, 19 Dec 2014 13:02:22 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B854A1A7011 for ; Fri, 19 Dec 2014 13:02:22 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7043DC19C; Fri, 19 Dec 2014 16:02:22 -0500 (EST) Date: Fri, 19 Dec 2014 16:02:22 -0500 From: Jeffrey Haas To: Gregory Mirsky Subject: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91) Message-ID: <20141219210222.GJ16279@pfrc> References: <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/LwBCEXuJG9RztoG0XFmVOXLpwZM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 21:02:23 -0000 [I'm running behind in discussions as usual] On Thu, Dec 04, 2014 at 04:33:17PM +0000, Gregory Mirsky wrote: > Hi Manav, > I hope you don???t expect me to give a lecture on how to design and implement debugable implementation using logging and packet tracing. For what it's worth, I always find such "drive-by" comments about "well, there already exists something that does , it's here - go do your homework!" to be a bit frustrating myself. :-) Not being personally familiar with TWAMP, I spend a few minutes digging through the spec for TWAMP and OWAMP for some details about the control and test traffic. It has some properties that are problematic for the pieces of the ecosystem covered by various portions of BFD deployment: TCP control channel. The implication is not only bidirectional reachability, but a control IP stack that may not involve the nodes being tested. (Nodes in this case potentially being anything from host systems all the way down to line card components.) The data channel is UDP, which is good. The problem though is there's no guarantee it'll cover the layers of the hardware stack covered by the BFD sessions. As one example, BFD on LAG, we not only may not have a full IP stack running at the point it's coming up, there's a chance that the receiver isn't really much of an IP speaker. It may be effectively using the IP+UDP framing as dumb framing rather than protocol in order to bootstrap the session. IP may not come up until constituent LAG elements have been put into service. There's also the matter that to get TWAMP running at the appropriate layer, it would be similarly necessary to embed it in the same general paths that BFD covers. Thus, at first very coarse analysis, TWAMP neither seems to share enough of the forwarding fate on a guaranteed basis as we'd want to supplement BFD debugging. The control channel also seems a bit heavy-weight, but it's potentially no worse than architecture of some LACP implementations I'm aware of. Is there something missing or incorrect in the above thinking? -- Jeff From nobody Fri Dec 19 13:22:09 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3561F1A710C for ; Fri, 19 Dec 2014 13:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 dWJnUepms8b1 for ; Fri, 19 Dec 2014 13:22:07 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 234CD1A7025 for ; Fri, 19 Dec 2014 13:22:07 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id AEE24C19C; Fri, 19 Dec 2014 16:22:06 -0500 (EST) Date: Fri, 19 Dec 2014 16:22:06 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: WGLC for Seamless BFD Use Case; IPR attestation Message-ID: <20141219212206.GK16279@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Ru3VHuKt4ykZWUpjbEzPtm1n_38 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 21:22:08 -0000 Working Group, The authors of draft-ietf-bfd-seamless-use-case have requested last call for this document. Given the end of year holidays for many IETF attendees, this will lead to a somewhat extended polling period. The WGLC polling period will end on January 9, 2015. Please send your comments to the list as to whether you believe this document is ready for publication. Simultaneously, authors please state whether you have any IPR on this draft. If you do, I expect it to be acknowledged prior to the end of the last call period. Any missing declarations for acknowledged IPR will be cause to extend the polling period. -- Jeff From nobody Fri Dec 19 13:40:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBBC1A1BD2 for ; Fri, 19 Dec 2014 13:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 DD6HE-85pezc for ; Fri, 19 Dec 2014 13:40:11 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8637B1A1B7A for ; Fri, 19 Dec 2014 13:40:11 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3EA7EC19C; Fri, 19 Dec 2014 16:40:11 -0500 (EST) Date: Fri, 19 Dec 2014 16:40:11 -0500 From: Jeffrey Haas To: Santosh P K Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt Message-ID: <20141219214011.GL16279@pfrc> References: <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.namprd05.prod.outlook.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-s-h5-4OYrvr0hDbCJWJ0tJlQxE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 21:40:12 -0000 On Thu, Nov 27, 2014 at 03:55:48PM +0000, Santosh P K wrote: > I would like to thank all for valuable comments. I think we have made enough progress now. Below are the points on which we have rough consensus . I have taken this summary and posted it to the wiki for tracking purposes. Please update consensus there. http://wiki.tools.ietf.org/wg/bfd/trac/wiki/BfdMultipointIssues (Some working groups use trac. Some keep a text file in svn. Let's do this a bit more light weight. :-) -- Jeff From nobody Fri Dec 19 13:55:12 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73011AC3D2 for ; Fri, 19 Dec 2014 13:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 CalNTL10gsp1 for ; Fri, 19 Dec 2014 13:55:09 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 1687D1AC3D3 for ; Fri, 19 Dec 2014 13:55:09 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-10-54944dde1d16 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BE.FA.03307.EDD44945; Fri, 19 Dec 2014 17:10:07 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 16:55:07 -0500 From: Gregory Mirsky To: "Jeffrey Haas (jhaas@pfrc.org)" , "rtg-bfd@ietf.org" Subject: RE: WGLC for Seamless BFD Use Case; IPR attestation Thread-Topic: WGLC for Seamless BFD Use Case; IPR attestation Thread-Index: AQHQG9YpxO30qMnd606XjtwS7UzmHZyXdNLw Date: Fri, 19 Dec 2014 21:55:07 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8C5E38@eusaamb103.ericsson.se> References: <20141219212206.GK16279@pfrc> 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.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8C5E38eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPoO593ykhBq+f81rsP/iW1eLzn22M DkweS5b8ZPK43LuVNYApissmJTUnsyy1SN8ugSvj4td/rAUPrCoaZhxia2Dssexi5OSQEDCR OPH2NCuELSZx4d56ti5GLg4hgSOMEndbWlkhnOWMEtM2zmMDqWITMJJ4sbGHHcQWEYiVmHlh MiOILSxgI7FmyWM2iLitxMpP+4FqOIBsI4kPc/NBwiwCqhJNS1rBSngFfCXWvzzOAmILCRRI 3JrQDWZzCgRKHGw6BzaSEeig76fWMIHYzALiEreezGeCOFRAYsme88wQtqjEy8f/oB5QlNjX P50doj5fYtmeP0wQuwQlTs58wjKBUWQWklGzkJTNQlI2C+hqZgFNifW79CFKFCWmdD9kh7A1 JFrnzGVHFl/AyL6KkaO0OLUsN93IYBMjMHaOSbDp7mDc89LyEKMAB6MSD6+ByuQQIdbEsuLK 3EOM0hwsSuK8s2rnBQsJpCeWpGanphakFsUXleakFh9iZOLglGpg7N2So5N0XWWmdU5jFeMc PSY198wjj2TXXXzx8pThJIW4En2d89XeB2atNnubvkCox61r0qsvfv67ZI7zcuTP5f+2ave9 fJM41aYk5eZYwS6fd9rqctdndcv2iS1bv8xDclJaSM3/OV+VY6/Wp96KWLPL6m+1x+9jaSz5 He6Xd2mIdfJFLixUYinOSDTUYi4qTgQAZEY8lX4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/9b6uVSRLDM6Fbukc3DCEOuhdCRY X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 21:55:11 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8C5E38eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmVmZiwgZXQuIGFsLA0KSeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0 aGlzIGRyYWZ0Lg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcyBhbmQgaGFwcHkgaG9saWRheXMs DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogSmVmZnJleSBI YWFzIDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+Pg0KRGF0ZTogU2F0LCBE ZWMgMjAsIDIwMTQgYXQgNToyMiBBTQ0KU3ViamVjdDogV0dMQyBmb3IgU2VhbWxlc3MgQkZEIFVz ZSBDYXNlOyBJUFIgYXR0ZXN0YXRpb24NClRvOiBydGctYmZkQGlldGYub3JnPG1haWx0bzpydGct YmZkQGlldGYub3JnPg0KDQoNCldvcmtpbmcgR3JvdXAsDQoNClRoZSBhdXRob3JzIG9mIGRyYWZ0 LWlldGYtYmZkLXNlYW1sZXNzLXVzZS1jYXNlIGhhdmUgcmVxdWVzdGVkIGxhc3QgY2FsbCBmb3IN CnRoaXMgZG9jdW1lbnQuICBHaXZlbiB0aGUgZW5kIG9mIHllYXIgaG9saWRheXMgZm9yIG1hbnkg SUVURiBhdHRlbmRlZXMsIHRoaXMNCndpbGwgbGVhZCB0byBhIHNvbWV3aGF0IGV4dGVuZGVkIHBv bGxpbmcgcGVyaW9kLg0KDQpUaGUgV0dMQyBwb2xsaW5nIHBlcmlvZCB3aWxsIGVuZCBvbiBKYW51 YXJ5IDksIDIwMTUuICBQbGVhc2Ugc2VuZCB5b3VyDQpjb21tZW50cyB0byB0aGUgbGlzdCBhcyB0 byB3aGV0aGVyIHlvdSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yDQpwdWJsaWNh dGlvbi4NCg0KU2ltdWx0YW5lb3VzbHksIGF1dGhvcnMgcGxlYXNlIHN0YXRlIHdoZXRoZXIgeW91 IGhhdmUgYW55IElQUiBvbiB0aGlzIGRyYWZ0Lg0KSWYgeW91IGRvLCBJIGV4cGVjdCBpdCB0byBi ZSBhY2tub3dsZWRnZWQgcHJpb3IgdG8gdGhlIGVuZCBvZiB0aGUgbGFzdCBjYWxsDQpwZXJpb2Qu ICBBbnkgbWlzc2luZyBkZWNsYXJhdGlvbnMgZm9yIGFja25vd2xlZGdlZCBJUFIgd2lsbCBiZSBj YXVzZSB0bw0KZXh0ZW5kIHRoZSBwb2xsaW5nIHBlcmlvZC4NCg0KLS0gSmVmZg0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B8C5E38eusaamb103erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBKZWZmLCBldC4gYWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlt IG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzIGFuZCBoYXBweSBob2xpZGF5 cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KRnJvbTogPGI+SmVmZnJleSBIYWFzPC9i PiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoYWFzQHBmcmMub3JnIj5qaGFhc0BwZnJjLm9yZzwvYT4m Z3Q7PGJyPg0KRGF0ZTogU2F0LCBEZWMgMjAsIDIwMTQgYXQgNToyMiBBTTxicj4NClN1YmplY3Q6 IFdHTEMgZm9yIFNlYW1sZXNzIEJGRCBVc2UgQ2FzZTsgSVBSIGF0dGVzdGF0aW9uPGJyPg0KVG86 IDxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIj5ydGctYmZkQGlldGYub3JnPC9hPjxi cj4NCjxicj4NCjxicj4NCldvcmtpbmcgR3JvdXAsPGJyPg0KPGJyPg0KVGhlIGF1dGhvcnMgb2Yg ZHJhZnQtaWV0Zi1iZmQtc2VhbWxlc3MtdXNlLWNhc2UgaGF2ZSByZXF1ZXN0ZWQgbGFzdCBjYWxs IGZvcjxicj4NCnRoaXMgZG9jdW1lbnQuJm5ic3A7IEdpdmVuIHRoZSBlbmQgb2YgeWVhciBob2xp ZGF5cyBmb3IgbWFueSBJRVRGIGF0dGVuZGVlcywgdGhpczxicj4NCndpbGwgbGVhZCB0byBhIHNv bWV3aGF0IGV4dGVuZGVkIHBvbGxpbmcgcGVyaW9kLjxicj4NCjxicj4NClRoZSBXR0xDIHBvbGxp bmcgcGVyaW9kIHdpbGwgZW5kIG9uIEphbnVhcnkgOSwgMjAxNS4mbmJzcDsgUGxlYXNlIHNlbmQg eW91cjxicj4NCmNvbW1lbnRzIHRvIHRoZSBsaXN0IGFzIHRvIHdoZXRoZXIgeW91IGJlbGlldmUg dGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3I8YnI+DQpwdWJsaWNhdGlvbi48YnI+DQo8YnI+DQpT aW11bHRhbmVvdXNseSwgYXV0aG9ycyBwbGVhc2Ugc3RhdGUgd2hldGhlciB5b3UgaGF2ZSBhbnkg SVBSIG9uIHRoaXMgZHJhZnQuPGJyPg0KSWYgeW91IGRvLCBJIGV4cGVjdCBpdCB0byBiZSBhY2tu b3dsZWRnZWQgcHJpb3IgdG8gdGhlIGVuZCBvZiB0aGUgbGFzdCBjYWxsPGJyPg0KcGVyaW9kLiZu YnNwOyBBbnkgbWlzc2luZyBkZWNsYXJhdGlvbnMgZm9yIGFja25vd2xlZGdlZCBJUFIgd2lsbCBi ZSBjYXVzZSB0bzxicj4NCmV4dGVuZCB0aGUgcG9sbGluZyBwZXJpb2QuPGJyPg0KPGJyPg0KLS0g SmVmZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B8C5E38eusaamb103erics_-- From nobody Fri Dec 19 14:07:02 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7AA1AC3ED for ; Fri, 19 Dec 2014 14:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 hXjSSznQqQbr for ; Fri, 19 Dec 2014 14:06:58 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A829F1AC3E8 for ; Fri, 19 Dec 2014 14:06:56 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 73839C19C; Fri, 19 Dec 2014 17:06:55 -0500 (EST) Date: Fri, 19 Dec 2014 17:06:55 -0500 From: Jeffrey Haas To: venkatesan mahalingam Subject: Re: Fwd: BFD statistics for BFD-MPLS sessions (fate of MIB) Message-ID: <20141219220655.GM16279@pfrc> References: <20141124194751.GD28464@pfrc> <1693791C-89AF-4023-9FCE-013F2532927E@gmail.com> 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: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lQjdFgqi8VWhYQI_wYUzSKKuZdg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 22:06:59 -0000 On Wed, Dec 03, 2014 at 04:34:29PM -0800, venkatesan mahalingam wrote: > Hi Jeff, > > Thanks for questions. Sorry for the delayed response. > > Does your implementation provide statistics for connectivity issues in your > UI for BFD over MPLS sessions? > > Yes. Our implementation provides statistics for connectivity issues. > > >> Let's use these data points to discuss whether the WG will continue to > spend > > >> effort on the MIB. > > Sure. We are pretty much done the MIB work for BFD over MPLS sessions, > please take this MIB to the next level. Venkat, if you're saying you have implemented the MIB as-is, then that at least provides existence proof that it is structured well enough for implementation. That's one of the major hurdles for shipping a MIB document. The biggest hurdles are clearing MIB doctor review. :-) Given that there's an implementation, let's keep the WG document and we'll target trying to get review cycles in by February. Meanwhile, if you have any edits to the document, please post them to the working group. -- Jeff From nobody Fri Dec 19 14:52:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B501A9088 for ; Fri, 19 Dec 2014 14:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 eeXUua7ZONlk for ; Fri, 19 Dec 2014 14:52:13 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.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 621061A9084 for ; Fri, 19 Dec 2014 14:52:13 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-b4-54944f11f9ad Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 66.BB.25146.11F44945; Fri, 19 Dec 2014 17:15:13 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 17:52:11 -0500 From: Gregory Mirsky To: Jeffrey Haas Subject: RE: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91) Thread-Topic: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91) Thread-Index: AQHQG88XebvdVz4lWEyU7mFsO07GX5yXbPxA Date: Fri, 19 Dec 2014 22:52:10 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8C5EA0@eusaamb103.ericsson.se> References: <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> <20141219210222.GJ16279@pfrc> In-Reply-To: <20141219210222.GJ16279@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXSPt66g/5QQgxMrdC32H3zLanF5Uhu7 xec/2xgdmD12zrrL7rFkyU8mj8u9W1kDmKO4bFJSczLLUov07RK4Mo7feMpS8F2u4sXqJqYG xtcSXYycHBICJhKnN/9khrDFJC7cW8/WxcjFISRwhFGit3MflLOcUeLBnCvsIFVsAkYSLzb2 gNkiAooS8/93soHYzAKBEqs//mQFsYUF0iVmvDzBBlGTIbGn4zxQnAPINpJ4vkENJMwioCqx bOsEsDG8Ar4Sn/7/ADtCSGAzq8TEu+kgNqeAlsS06TPBahiBjvt+ag0TxCpxiVtP5jNBHC0g sWTPeagHRCVePv7HCmErSuzrn84OUa8jsWD3J6gztSWWLXzNDLFXUOLkzCcsExjFZiEZOwtJ yywkLbOQtCxgZFnFyFFanFqWm25kuIkRGDnHJNgcdzAu+GR5iFGAg1GJh9dAZXKIEGtiWXFl 7iFGaQ4WJXFezep5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYDQ23B/3bVufaxvv0397f F5akm+fuyJsmWKeS+DPRKap06qcqhYI5TUILdGdl8itv0Rfb07D1l8A9NaPPGlvKfuaef7mv 1u/MRqOmfDaF60aRwgnV6csSDlk5NwaZqLS3JDFWhH85eFC+6plMgczFjPUVH+peGdvE/57w U2nxooPR1+xv2wUosRRnJBpqMRcVJwIAdK5AfH0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2HJ07NKgE64sKV984sg_Nmf57t0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 22:52:15 -0000 Hi Jeff, thank you for your interest in this discussion. If you agree, we can add IP= PM WG to it. I agree with your analysis of TWAMP and I would not suggest that TWAMP-Test= is well suited to debug BFD specific issues. But TWAMP-Test, as other acti= ve performance measurement mechanisms, i.e. Y.1731 and MPLS PM based on RFC= 6374, may be used to measure latency and jitter of a network or its segmen= t. And even more than active, passive measurement methods may provide helpf= ul information to troubleshoot network or BFD. That may be done using IPFIX= on certain nodes in the network with the data analysis by a data collector= . Would like to note that IPPM WG is in discussion of IP flow measurement m= ethod that uses marking method that I consider operationally more useful co= mparing to straight IPFIX. I agree that debugging and troubleshooting is often an art and operators an= d vendors need to have and use all tools that are available. We probably c= an do better job of instrumenting BFD debug tools but, I believe, not by ch= anging, not by overloading its main functions of monitoring continuity and = fast detection of the Loss of Continuity defect. Whether Down state is indi= cation of the real defect or false negative, that is the question to be ans= wered through analysis of available information and follow-up with debuggin= g and troubleshooting the BFD itself rather than the network if there are c= oncerns that it was not a real defect. Regards, Greg -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Friday, December 19, 2014 1:02 PM To: Gregory Mirsky Cc: Manav Bhatia; rtg-bfd@ietf.org Subject: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability f= ollow-up from IETF-91) [I'm running behind in discussions as usual] On Thu, Dec 04, 2014 at 04:33:17PM +0000, Gregory Mirsky wrote: > Hi Manav, > I hope you don???t expect me to give a lecture on how to design and imple= ment debugable implementation using logging and packet tracing. For what it's worth, I always find such "drive-by" comments about "well, th= ere already exists something that does , it's here - go do your homewo= rk!" to be a bit frustrating myself. :-) =20 Not being personally familiar with TWAMP, I spend a few minutes digging thr= ough the spec for TWAMP and OWAMP for some details about the control and te= st traffic. It has some properties that are problematic for the pieces of = the ecosystem covered by various portions of BFD deployment: TCP control channel. The implication is not only bidirectional reachabilit= y, but a control IP stack that may not involve the nodes being tested. (No= des in this case potentially being anything from host systems all the way d= own to line card components.) The data channel is UDP, which is good. The problem though is there's no g= uarantee it'll cover the layers of the hardware stack covered by the BFD se= ssions. As one example, BFD on LAG, we not only may not have a full IP sta= ck running at the point it's coming up, there's a chance that the receiver = isn't really much of an IP speaker. It may be effectively using the IP+UDP= framing as dumb framing rather than protocol in order to bootstrap the ses= sion. IP may not come up until constituent LAG elements have been put into= service. There's also the matter that to get TWAMP running at the appropriate layer,= it would be similarly necessary to embed it in the same general paths that= BFD covers. Thus, at first very coarse analysis, TWAMP neither seems to share enough of= the forwarding fate on a guaranteed basis as we'd want to supplement BFD d= ebugging. The control channel also seems a bit heavy-weight, but it's pote= ntially no worse than architecture of some LACP implementations I'm aware o= f. Is there something missing or incorrect in the above thinking? -- Jeff From nobody Fri Dec 19 17:05:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F601A1B0D for ; Fri, 19 Dec 2014 17:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 aGBZ9UAdopWo for ; Fri, 19 Dec 2014 17:05:02 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC0B1A802F for ; Fri, 19 Dec 2014 17:05:01 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id h136so3907486oig.5 for ; Fri, 19 Dec 2014 17:05:01 -0800 (PST) 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:content-type; bh=6uB8wBIHDeE0qNboDvGvPvw5EEA9TEMA19kVi3c3UfQ=; b=WbS5uUurcckFtiIXff05WnkzlCcQjnVwRosATXy/7Hj9bLzX0U1DdtIIzDuxzTKGJ/ h+Ombjgzlzm7jqJW0XaRw+M5wENiknWRTKWUOlf4heTRv3sJpropxzKvpR9XRvLm+39L nmrAZpcZImxuWCFGJTw05+xnKthGzAd4dCUIUYMcMtzyqcewvGREzHh1dgxbAdaKyYSZ DUZ4RHX0+mHhgJe6q8VmRBc2I4q9/LoMR7OsHDD9683FpW4H3JKlVim02E3mhrfF/q/g JKDjg+42YA11rzEPvU218n7+zRglxK88y0zHz3aSNxPgBJZOd32WF3tqEq5x+hLEWIrI fzSw== MIME-Version: 1.0 X-Received: by 10.182.231.230 with SMTP id tj6mr6639149obc.58.1419037501154; Fri, 19 Dec 2014 17:05:01 -0800 (PST) Received: by 10.76.178.199 with HTTP; Fri, 19 Dec 2014 17:05:01 -0800 (PST) In-Reply-To: <20141219212206.GK16279@pfrc> References: <20141219212206.GK16279@pfrc> Date: Sat, 20 Dec 2014 06:35:01 +0530 Message-ID: Subject: Re: WGLC for Seamless BFD Use Case; IPR attestation From: Manav Bhatia To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c30a062deccc050a9b6a53 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KdZBqGlCDj2-Leegpo68Of-VHew Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Dec 2014 01:05:04 -0000 --001a11c30a062deccc050a9b6a53 Content-Type: text/plain; charset=UTF-8 No IPR from my side. Cheers, Manav On Sat, Dec 20, 2014 at 2:52 AM, Jeffrey Haas wrote: > Working Group, > > The authors of draft-ietf-bfd-seamless-use-case have requested last call > for > this document. Given the end of year holidays for many IETF attendees, > this > will lead to a somewhat extended polling period. > > The WGLC polling period will end on January 9, 2015. Please send your > comments to the list as to whether you believe this document is ready for > publication. > > Simultaneously, authors please state whether you have any IPR on this > draft. > If you do, I expect it to be acknowledged prior to the end of the last call > period. Any missing declarations for acknowledged IPR will be cause to > extend the polling period. > > -- Jeff > > --001a11c30a062deccc050a9b6a53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No IPR from my side.

Cheers, Manav

On Sat, De= c 20, 2014 at 2:52 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
=
Working Group,

The authors of draft-ietf-bfd-seamless-use-case have requested last call fo= r
this document.=C2=A0 Given the end of year holidays for many IETF attendees= , this
will lead to a somewhat extended polling period.

The WGLC polling period will end on January 9, 2015.=C2=A0 Please send your=
comments to the list as to whether you believe this document is ready for publication.

Simultaneously, authors please state whether you have any IPR on this draft= .
If you do, I expect it to be acknowledged prior to the end of the last call=
period.=C2=A0 Any missing declarations for acknowledged IPR will be cause t= o
extend the polling period.

-- Jeff


--001a11c30a062deccc050a9b6a53-- From nobody Fri Dec 19 17:14:25 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EA61A888F for ; Fri, 19 Dec 2014 17:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 CpiHzZ2LHt0K for ; Fri, 19 Dec 2014 17:14:21 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC841A802F for ; Fri, 19 Dec 2014 17:14:21 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id et14so2238158pad.29 for ; Fri, 19 Dec 2014 17:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OrEfE+8WhuhU8Y85qeLBsnJI0NKPvdtSO0M26MaO0Fk=; b=Pbu9rk77lx4fxDrOTfq3RrqnVD6dG/2ilmJ4rTJVJ+pWYGtP4FwJdVniMx36uYpxdh EEiphL4OU0OzxYASO7y4HTuwaptm7Ui4myz9PyHyLU/xe/ywxkJQ/BF3/b2+POjD6zeR vQS7K+dkA70b/xL6rA1U9cHhgkcIbzgNmFXUeFMNoxPxAEwmCzDX8GpDmgCDTO8Ej1lk 0ly2NY2ATsbVQrZHnv5gdr9ZsW9LymsMmZt9sk3Ff5L3VbtOO73Gqq4hsnFZnSrl8YNg Qr/lQabcFZbaxbMU1OXMC77BWOu5VEiQIruxKmwnwrHFWYRjvlx115L4bHs8F4ZW/97O kagA== X-Received: by 10.70.37.104 with SMTP id x8mr16459346pdj.119.1419038060712; Fri, 19 Dec 2014 17:14:20 -0800 (PST) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id pr3sm10331155pbb.37.2014.12.19.17.14.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 17:14:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: WGLC for Seamless BFD Use Case; IPR attestation From: Sam Aldrin In-Reply-To: <20141219212206.GK16279@pfrc> Date: Fri, 19 Dec 2014 17:14:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141219212206.GK16279@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/3Q_CQhwI_G2l1N4LBqMfhwrHi_0 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Dec 2014 01:14:23 -0000 No IPR that I am aware off, related to this document. cheers -sam > On Dec 19, 2014, at 1:22 PM, Jeffrey Haas wrote: >=20 > Working Group, >=20 > The authors of draft-ietf-bfd-seamless-use-case have requested last = call for > this document. Given the end of year holidays for many IETF = attendees, this > will lead to a somewhat extended polling period. >=20 > The WGLC polling period will end on January 9, 2015. Please send your > comments to the list as to whether you believe this document is ready = for > publication. >=20 > Simultaneously, authors please state whether you have any IPR on this = draft. > If you do, I expect it to be acknowledged prior to the end of the last = call > period. Any missing declarations for acknowledged IPR will be cause = to > extend the polling period. >=20 > -- Jeff >=20 From nobody Sat Dec 20 09:31:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9061AC3DF for ; Sat, 20 Dec 2014 09:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 eeDqwUngJRLs for ; Sat, 20 Dec 2014 09:31:31 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6A51A8775 for ; Sat, 20 Dec 2014 09:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=830; q=dns/txt; s=iport; t=1419096691; x=1420306291; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=tpAD5l2gLIEb21+KNeCq85d+G5kC0asX03Og0Eb6Jlw=; b=giNZ1uqHlwuctLCr8UcdntzMe7UDc96jfa7+z0tfALJvOHWLZGenduHR 2miantC6FAW1TkM06yjMdBQJBwqA5jnoWwFrZUBwsIb+cT6HUTh8hEvxL aGA/bqSNrbmhqL/kfhVwbidLgEZOxdywqKhBi02xhhPfIWYVxSkFf/96N o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFABqylVStJA2B/2dsb2JhbABbgwaBKgTEBogVAoERFgEBAQEBfYQNAgQ6UQEIDihCJQIEARKILM97AQEBAQEBBAEBAQEBARyPeYQpAQSOD4hygQ2CY4ohgzkig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,613,1413244800"; d="scan'208";a="107221821" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP; 20 Dec 2014 17:31:28 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBKHVRSw006404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Dec 2014 17:31:27 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.194]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Sat, 20 Dec 2014 11:31:27 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: WGLC for Seamless BFD Use Case; IPR attestation Thread-Topic: WGLC for Seamless BFD Use Case; IPR attestation Thread-Index: AQHQG9HcjDf0dtxW1EaFdHbH0lewEJyYzq6A Date: Sat, 20 Dec 2014 17:31:27 +0000 Message-ID: In-Reply-To: <20141219212206.GK16279@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.78.89] Content-Type: text/plain; charset="us-ascii" Content-ID: <4FA12E72115DD74ABCAE76104CCBE4B9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Tk7KIc5w09PLExu3zMN9tjYQAjs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Dec 2014 17:31:32 -0000 Hi, I am not aware of any IPR related to this document. Thanks, Nagendra On 12/19/14, 4:22 PM, "Jeffrey Haas" wrote: >Working Group, > >The authors of draft-ietf-bfd-seamless-use-case have requested last call >for >this document. Given the end of year holidays for many IETF attendees, >this >will lead to a somewhat extended polling period. > >The WGLC polling period will end on January 9, 2015. Please send your >comments to the list as to whether you believe this document is ready for >publication. > >Simultaneously, authors please state whether you have any IPR on this >draft. >If you do, I expect it to be acknowledged prior to the end of the last >call >period. Any missing declarations for acknowledged IPR will be cause to >extend the polling period. > >-- Jeff > From nobody Sat Dec 20 19:38:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3F1A0117 for ; Sat, 20 Dec 2014 19:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Ktgaim6m-Lyb for ; Sat, 20 Dec 2014 19:38:30 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D37EF1A010A for ; Sat, 20 Dec 2014 19:38:29 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 46D2A2AA0F; Sun, 21 Dec 2014 03:38:25 +0000 (GMT) Date: Sat, 20 Dec 2014 19:42:58 -0800 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20141220194258469026.44ef65d8@sniff.de> In-Reply-To: References: <20141217220838.GG16279@pfrc> Subject: RE: S-BFD port allocation MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/R1j5KLpfY4Z_kvZIsObF-a6XKvY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 03:38:32 -0000 SGVsbG8gTm9ibyBldCBhbC4sDQoNCj4gU2luY2UgdGhlcmUgaGFzbid0IGJlZW4gYW55IG1h am9yIG9iamVjdGlvbiB0byBnb2luZyB3aXRoIG9uZSBwb3J0IGZvciANCj4gUy1CRkQsIEkn bSBzdGFydGluZyB0byBjb25jbHVkZSB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIHdoaWNoIHdl IGNhbiBsaXZlIA0KPiB3aXRoLiBJZiBhbnlvbmUgb2JqZWN0LCBkbyBjaGltZSBpbiB3aXRo aW4gZmV3IGRheXMgYW5kIHByb3ZpZGUgeW91ciANCj4gcmVhc29ucy4gT3RoZXJ3aXNlLCB3 ZSdsbCBwcm92aWRlICJsZXQncyBnbyBhaGVhZCB3aXRoIG9uZSBTLUJGRCBwb3J0IiB0byAN Cj4gSUFOQS4NCg0Kd2hpY2ggcHJvdmVzIHRoZSBwdXNoYmFjayBmcm9tIElBTkEgd2FzIGFj dHVhbGx5IGEgZ29vZCB0aGluZy4gImRvIHlvdSByZWFsbHkgDQpuZWVkIHRoaXM/IiBpcyBh IHJlYXNvbmFibGUgcXVlc3Rpb24uIE92ZXJhbGwgdGhlIG1lY2hhbmlzbXMgc2VlbSB0byB3 b3JrLg0KDQoNCkluIGFub3RoZXIgZW1haWwgeW91IHNhaWQ6DQoNCltOT0JPXSBJQU5BIGJl bGlldmUgdGhhdCB0aGUgQkZEIHByb3RvY29sIGlzIGFidXNpbmcgdGhlIHBvcnQgc3BhY2Uu IFRoZXkgYXJlIA0Kc3Ryb25nbHkgc3VnZ2VzdGluZyB0aGF0IGZlYXR1cmUgZGVtdXggYmUg ZG9uZSBvbiB0aGUgZmVhdHVyZSBsYXllci4gQW5kIGl0IA0KYXBwZWFycyB0aGF0IHRoaXMg aXNuonQgdGhlIGZpcnN0IHRpbWUgdGhpcyB0b3BpYyB3YXMgYnJvdWdodCB1cC4gVGh1IHRo ZSANCnB1c2hiYWNrIGZyb20gSUFOQS4NCg0KDQpBY3R1YWxseSBJIGRvIG5vdCByZW1lbWJl ciB0aGF0IHRoaXMgd2FzIGEgcmVhbCBwcm9ibGVtIGluIHRoZSBwYXN0IC0gSSB0aGluayAN Cml0IGlzIGp1c3Qgbm9ybWFsIGJ1c2luZXNzIHRoYXQgeW91IGhhdmUgdG8gZXhwbGFpbiB3 aHkgeW91IG5lZWQgdG8gdGFrZSBhIA0KcG9ydC4NCk9yIG1heWJlIGl0J3MgYW5vdGhlciAo c2V0IG9mKSBwZXJzb24gdGhpcyB0aW1lIGJ1dCBhZ2FpbiwgdGhleSBzZWUgdGhlIHBvaW50 IA0KZm9yIFMtQkZEIGFuZCBhcmUgd2lsbGluZyB0byBwcm92aWRlIGEgcG9ydCwgc28gaXQn cyBub3QgdGhlIGVuZCBvZiB0aGUgd29ybGQuDQoNCk5vdCB0aGF0IHlvdSB3aWxsIHNlZSBt ZSBhcmd1ZSBhZ2FpbnN0ICJ2MiIgOy0pIGJ1dCBpdCBkb2Vzbid0IHNlZW0gdG8gYmUgDQpu ZWNlc3NhcnkgZm9yIFMtQkZELg0KDQoNCkZvciB0aGUgZWNobywgYXMgYXNrZWQgaW4gYW5v dGhlciBlbWFpbDogd2hhdCBpcyBkaWZmZXJlbnQgZm9yIFMtQkZEIGVjaG8/ICANCklzIHRo ZXJlIGFueSBzcGVjaWFsL2RpZmZlcmVudCBiZWhhdmlvdXIgZXhwZWN0ZWQgb24gdGhlIHJl bW90ZSBzaWRlLCANCmNvbXBhcmVkIHRvIDM3ODUvdWRwIGVjaG8gPw0KDQoNClJlZ2FyZHMs IE1hcmMNCg0KDQoNCg0KDQoNCg0KT24gVGh1LCAxOCBEZWMgMjAxNCAxMzo1NDoyNiArMDAw MCwgTm9ibyBBa2l5YSAobm9ibykgd3JvdGU6DQo+IFtzbmlwcGluZyBpbiBvbmx5IHRoZSBz LWJmZCBwb3J0IGRpc2N1c3Npb24gcG9ydGlvbiAuLi4gdG8gYXR0ZW1wdCB0byBjbG9zZSAN Cj4gdGhpcyBvZmZdDQo+IA0KPj4gT24gV2VkLCBEZWMgMTcsIDIwMTQgYXQgMDI6MTY6NDJQ TSArMDAwMCwgTm9ibyBBa2l5YSAobm9ibykgd3JvdGU6DQo+Pj4gW05PQk9dIEdvb2QgdGhp bmcgaXMgdGhhdCBJQU5BIGlzIHdpbGxpbmcgdG8gYWxsb3cgdGhlIHBvcnQgZm9yIFMtQkZE IA0KPj4+IGFzeW5jLg0KPj4gQW5kIGNvbnNpZGVyaW5nIGVjaG8gcGFja2V0IGNvbnRlbnRz IGlzIHNvbWV0aGluZyBpbXBsZW1lbnRhdGlvbnMgY2FuDQo+PiBkZWZpbmUgKGkuZS4gaGF2 aW5nIHZlcnNpb24sIHR5cGUsIGV0YyksIHdlIF9zaG91bGQgYmVfIGFibGUgdG8gcmV1c2Ug Mzc4NSANCj4+IGZvcg0KPj4gUy1CRkQgZWNoby4gRG8geW91IHRoaW5rIHRoaXMgaXMgdHJ1 ZT8NCj4+PiANCj4+PiBXaGF0IGRvIHlvdSB0aGluaz8NCj4+PiANCj4+PiBNYWxsaWs+PiBJ ZiB3ZSBwbGFuIHRvIGltcGxlbWVudCBhZGRpdGlvbmFsIGhlYWRlcnMgaW4gQkZEIHBhY2tl dHMgZm9yDQo+PiBkZW11eCBwdXJwb3NlIHRoZW4gaXQgaXMgdGltZSB3ZSBzdGFydCBkaXNj dXNzaW5nIHRoZSBzYW1lLg0KPj4+IA0KPj4+IFtOT0JPXSBUaGlzIGNhbiBzdGFydCB1cCBu b3csIG9yIHRoaXMgaGFzIHRvIHN0YXJ0IHVwIHdoZW4gdGhlcmUgaXMgDQo+Pj4gYW5vdGhl cg0KPj4gQkZEIGZlYXR1cmUgcmVxdWlyaW5nIGEgbmV3IHBvcnQuDQo+PiANCj4+IEkgdGhp bmsgd2UgaGF2ZSBlbm91Z2ggYnJlYXRoaW5nIHJvb20gZm9yIFMtQkZEIHRvIHByb2NlZWQg d2l0aCBhIHNpbmdsZQ0KPj4gcG9ydCBmb3IgYXN5bmMgYW5kIGxldHRpbmcgdGhlIHJlbW90 ZSBkZW11eCBvbiBlY2hvIGNvbnRlbnRzIHdpdGggZXhpc3RpbmcNCj4+IEJGRCBlY2hvIHBv cnQgZnJvbSA1ODgwLiAgQXQgbGVhc3QgdGhhdCdzIGhvdyBJIHJlYWQgdGhlIGFib3ZlLg0K PiANCj4gU2luY2UgdGhlcmUgaGFzbid0IGJlZW4gYW55IG1ham9yIG9iamVjdGlvbiB0byBn b2luZyB3aXRoIG9uZSBwb3J0IGZvciANCj4gUy1CRkQsIEknbSBzdGFydGluZyB0byBjb25j bHVkZSB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIHdoaWNoIHdlIGNhbiBsaXZlIA0KPiB3aXRo LiBJZiBhbnlvbmUgb2JqZWN0LCBkbyBjaGltZSBpbiB3aXRoaW4gZmV3IGRheXMgYW5kIHBy b3ZpZGUgeW91ciANCj4gcmVhc29ucy4gT3RoZXJ3aXNlLCB3ZSdsbCBwcm92aWRlICJsZXQn cyBnbyBhaGVhZCB3aXRoIG9uZSBTLUJGRCBwb3J0IiB0byANCj4gSUFOQS4NCj4gDQo+IFRo YW5rcyENCj4gDQo+IC1Ob2JvDQo+IA0KPiA= From nobody Sat Dec 20 22:17:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C241A0164 for ; Sat, 20 Dec 2014 22:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 RcV7CJ2FIS6o for ; Sat, 20 Dec 2014 22:17:24 -0800 (PST) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4EAB1A0162 for ; Sat, 20 Dec 2014 22:17:23 -0800 (PST) Received: by mail-yh0-f47.google.com with SMTP id f73so1516449yha.20 for ; Sat, 20 Dec 2014 22:17:23 -0800 (PST) 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:content-type; bh=AJFCcT6fEHOXHSoE3oq+eVOFtSV2v4G4r2+pU/RNqrs=; b=SBbQF1mXAsbbOdHkz/f5smb8yephBMtnMPk+XwA3zQKT4QM8bNloe5iaV0xMPWxJwz E7bEeFwg4bIie/Ef2l8sq6tmPiqqZZkS1AQ9jA38eHmSkgAkpbEvucf5it8GU0e5uG61 2NNNkKz6PG3TP8pJYGJ8DOGzYwXCoQdrC5cKOAjV52sjOfbiA13PEDNvgYpdG5wUhe9e w9wRTwxZAyt+62VQdtkv1uvs55VmKoaFDUpSJlenWHMlpM5zXx0OLZJBNRBwPNHqtKLM SBU+CLj2NTlmpvDYDiNfnGgtdUSWEsnCH/j3HyitOAidldZYYsMTrRdMY3dQoCMBt/lu c9tw== MIME-Version: 1.0 X-Received: by 10.236.109.7 with SMTP id r7mr13180108yhg.107.1419142643196; Sat, 20 Dec 2014 22:17:23 -0800 (PST) Received: by 10.170.136.132 with HTTP; Sat, 20 Dec 2014 22:17:23 -0800 (PST) In-Reply-To: <20141220194258469026.44ef65d8@sniff.de> References: <20141217220838.GG16279@pfrc> <20141220194258469026.44ef65d8@sniff.de> Date: Sun, 21 Dec 2014 01:17:23 -0500 Message-ID: Subject: Re: S-BFD port allocation From: Alia Atlas To: Marc Binderberger Content-Type: multipart/alternative; boundary=001a11c2c596222c09050ab3e5d8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dXu6fNdJXUen_fGRVUWAzQ2thvo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 06:17:26 -0000 --001a11c2c596222c09050ab3e5d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 20, 2014 at 10:42 PM, Marc Binderberger wrote: > Hello Nobo et al., > > > Since there hasn't been any major objection to going with one port for > > S-BFD, I'm starting to conclude that this is something which we can liv= e > > with. If anyone object, do chime in within few days and provide your > > reasons. Otherwise, we'll provide "let's go ahead with one S-BFD port" = to > > IANA. > > which proves the pushback from IANA was actually a good thing. "do you > really > need this?" is a reasonable question. Overall the mechanisms seem to work= . > > > In another email you said: > > [NOBO] IANA believe that the BFD protocol is abusing the port space. They > are > strongly suggesting that feature demux be done on the feature layer. And = it > appears that this isn=E2=80=99t the first time this topic was brought up.= Thu the > pushback from IANA. > Just to clarify - this is not IANA. This is the designated expert, whom is assigned by the IESG. IANA, of course, doesn't do policy related to the protocol parameters. I am very glad to see the conversation resolving well. Regards, Alia > Actually I do not remember that this was a real problem in the past - I > think > it is just normal business that you have to explain why you need to take = a > port. > Or maybe it's another (set of) person this time but again, they see the > point > for S-BFD and are willing to provide a port, so it's not the end of the > world. > > Not that you will see me argue against "v2" ;-) but it doesn't seem to be > necessary for S-BFD. > > > For the echo, as asked in another email: what is different for S-BFD echo= ? > Is there any special/different behaviour expected on the remote side, > compared to 3785/udp echo ? > > > Regards, Marc > > > > > > > > On Thu, 18 Dec 2014 13:54:26 +0000, Nobo Akiya (nobo) wrote: > > [snipping in only the s-bfd port discussion portion ... to attempt to > close > > this off] > > > >> On Wed, Dec 17, 2014 at 02:16:42PM +0000, Nobo Akiya (nobo) wrote: > >>> [NOBO] Good thing is that IANA is willing to allow the port for S-BFD > >>> async. > >> And considering echo packet contents is something implementations can > >> define (i.e. having version, type, etc), we _should be_ able to reuse > 3785 > >> for > >> S-BFD echo. Do you think this is true? > >>> > >>> What do you think? > >>> > >>> Mallik>> If we plan to implement additional headers in BFD packets fo= r > >> demux purpose then it is time we start discussing the same. > >>> > >>> [NOBO] This can start up now, or this has to start up when there is > >>> another > >> BFD feature requiring a new port. > >> > >> I think we have enough breathing room for S-BFD to proceed with a sing= le > >> port for async and letting the remote demux on echo contents with > existing > >> BFD echo port from 5880. At least that's how I read the above. > > > > Since there hasn't been any major objection to going with one port for > > S-BFD, I'm starting to conclude that this is something which we can liv= e > > with. If anyone object, do chime in within few days and provide your > > reasons. Otherwise, we'll provide "let's go ahead with one S-BFD port" = to > > IANA. > > > > Thanks! > > > > -Nobo > > > > > --001a11c2c596222c09050ab3e5d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 20, 2014 at 10:42 PM, Marc Binderberger &= lt;marc@sniff.de>= wrote:
Hello Nobo et al.,

> Since there hasn't been any major objection to going with one port= for
> S-BFD, I'm starting to conclude that this is something which we ca= n live
> with. If anyone object, do chime in within few days and provide your > reasons. Otherwise, we'll provide "let's go ahead with on= e S-BFD port" to
> IANA.

which proves the pushback from IANA was actually a good thing. "= ;do you really
need this?" is a reasonable question. Overall the mechanisms seem to w= ork.


In another email you said:

[NOBO] IANA believe that the BFD protocol is abusing the port space. They a= re
strongly suggesting that feature demux be done on the feature layer. And it=
appears that this isn=E2=80=99t the first time this topic was brought up. T= hu the
pushback from IANA.

Just to clar= ify - this is not IANA.=C2=A0 This is the designated expert, whom is assign= ed
by the IESG.=C2=A0 IANA, of course, doesn't do policy rela= ted to the protocol parameters.

I am very glad to = see the conversation resolving well.

Regards,
Alia=C2=A0
=C2=A0
Actually I do not remember that this was a real problem in the past = - I think
it is just normal business that you have to explain why you need to take a<= br> port.
Or maybe it's another (set of) person this time but again, they see the= point
for S-BFD and are willing to provide a port, so it's not the end of the= world.

Not that you will see me argue against "v2" ;-) but it doesn'= t seem to be
necessary for S-BFD.


For the echo, as asked in another email: what is different for S-BFD echo?<= br> Is there any special/different behaviour expected on the remote side,
compared to 3785/udp echo ?


Regards, Marc







On Thu, 18 Dec 2014 13:54:26 +0000, Nobo Akiya (nobo) wrote:
> [snipping in only the s-bfd port discussion portion ... to attempt to = close
> this off]
>
>> On Wed, Dec 17, 2014 at 02:16:42PM +0000, Nobo Akiya (nobo) wrote:=
>>> [NOBO] Good thing is that IANA is willing to allow the port fo= r S-BFD
>>> async.
>> And considering echo packet contents is something implementations = can
>> define (i.e. having version, type, etc), we _should be_ able to re= use 3785
>> for
>> S-BFD echo. Do you think this is true?
>>>
>>> What do you think?
>>>
>>> Mallik>> If we plan to implement additional headers in B= FD packets for
>> demux purpose then it is time we start discussing the same.
>>>
>>> [NOBO] This can start up now, or this has to start up when the= re is
>>> another
>> BFD feature requiring a new port.
>>
>> I think we have enough breathing room for S-BFD to proceed with a = single
>> port for async and letting the remote demux on echo contents with = existing
>> BFD echo port from 5880.=C2=A0 At least that's how I read the = above.
>
> Since there hasn't been any major objection to going with one port= for
> S-BFD, I'm starting to conclude that this is something which we ca= n live
> with. If anyone object, do chime in within few days and provide your > reasons. Otherwise, we'll provide "let's go ahead with on= e S-BFD port" to
> IANA.
>
> Thanks!
>
> -Nobo
>
>

--001a11c2c596222c09050ab3e5d8-- From nobody Sun Dec 21 07:27:54 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5746D1A1A63 for ; Sun, 21 Dec 2014 07:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 yFSbyZ7oY-yc for ; Sun, 21 Dec 2014 07:27:51 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A821A1A54 for ; Sun, 21 Dec 2014 07:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6532; q=dns/txt; s=iport; t=1419175672; x=1420385272; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6w9G1MX4+Adp0SbEn6fy0iIGXzT0nGaRvDROPvRPngw=; b=blTFO54Mbb9aiU1nGw6nnwJNc1pDa6KH5SDbP2OwjNbhJ/nZX+27/dZZ vUTU+XZOtd4lhlsNkDwV2P37RXxCmHf8vA6wNPCZ1MH31gmuIsjiaD1xl ni0Npfi9lX1BeWnPwrTBWuFk10vG0w+rfphE63oOJPSSqRb204cItRRe0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYGABfmllStJA2B/2dsb2JhbABbgmQigSoEgwDJIwIcdRYBAQEBAX2EDAEBAQMBIxE3DgUHBAIBCA4DBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIiBADCQgBuHyPYQ2FPwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYwpgUYRAR8WGwcGgmIugRMFjDqBV4cuglGFF4VSghyDOSKDbm+BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,617,1413244800"; d="scan'208";a="381733332" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 21 Dec 2014 15:27:51 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBLFRopn031301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Dec 2014 15:27:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Sun, 21 Dec 2014 09:27:50 -0600 From: "Nobo Akiya (nobo)" To: Alia Atlas , Marc Binderberger Subject: RE: S-BFD port allocation Thread-Topic: S-BFD port allocation Thread-Index: AdAWNnPRsInEU61oRKiIebSET7H+hgCMuADAABMxvgAAWicfAAAG622gAA958gAAFErZkACOQiMAAAVkl4AABlM2cA== Date: Sun, 21 Dec 2014 15:27:49 +0000 Message-ID: References: <20141217220838.GG16279@pfrc> <20141220194258469026.44ef65d8@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.77.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/M9q3uivy47gVbDIWy9Ddr3UvlvU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 15:27:53 -0000 SGkgQWxpYSwNCg0KQWggeWVzLCB0aGFua3MgZm9yIGNsYXJpZnlpbmcgdGhhdCB0aGUgY29tbWVu dHMgYXJlIGZyb20gZGVzaWduYXRlZCBleHBlcnRzIGFuZCBub3QgSUFOQS4NCg0KSGkgTWFyYywN Cg0KTWFueSB0aGFua3MgZm9yIHByb3ZpZGluZyBjb21tZW50cy4NCg0KPiBGb3IgdGhlIGVjaG8s IGFzIGFza2VkIGluIGFub3RoZXIgZW1haWw6IHdoYXQgaXMgZGlmZmVyZW50IGZvciBTLUJGRCBl Y2hvPw0KPiBJcyB0aGVyZSBhbnkgc3BlY2lhbC9kaWZmZXJlbnQgYmVoYXZpb3VyIGV4cGVjdGVk IG9uIHRoZSByZW1vdGUgc2lkZSwNCj4gY29tcGFyZWQgdG8gMzc4NS91ZHAgZWNobyA/DQoNClRo ZSBjb250ZW50cyBvZiB0aGUgZWNobyBjYW4gYmUgZWFzaWx5IHVwZGF0ZWQgdG8gYmUgYWJsZSB0 byBkZW11eCBiZXR3ZWVuIEJGRC9TLUJGRC4gQnV0IHRoZSBjb25jZXJucyB3ZXJlOg0KLSBDYW4g U1cvSFcgaW1wbGVtZW50YXRpb25zIGVhc2lseSBkZW11eCB0aGUgQkZEL1MtQkZEIGVjaG8gb24g dGhlIEJGRCBsYXllcj8NCi0gQXJlIHRoZXJlIGFueSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBoYXMg c3BlY2lhbCBjb2RlIHBhdGggZm9yIHBvcnQgMzc4NSB0aGF0IGNhbiByZXN1bHQgaW4gYSBjb25m bGljdCBieSBTLUJGRCBlY2hvIGFsc28gdXNpbmcgdGhhdCBwb3J0Pw0KDQpbY2hhaXIgaGF0IG9u XQ0KDQpXRywNCg0KQmFzZWQgb24gdGhlIGNvbW1lbnRzIG9uIHRoaXMgdGhyZWFkIChhbmQgbGFj ayBvZiBvcHBvc2luZyBjb21tZW50cyksIEkgaGF2ZSBjb25jbHVkZWQgdGhhdCB3ZSBjYW4gbW92 ZSBmb3J3YXJkIHdpdGggdGhlIGZvbGxvd2luZ3MgZm9yIFMtQkZEIHBvcnQgYWxsb2NhdGlvbnMu DQotIE1vdmUgZm9yd2FyZCB3aXRoIFMtQkZEIGNvbnRyb2wgcG9ydCBhbGxvY2F0aW9uICg3Nzg0 KQ0KLSBDYW5jZWwgUy1CRkQgZWNobyBwb3J0IGFsbG9jYXRpb24gKDc3ODUpDQoNCkFkZGl0aW9u YWxseSwgZG8gY29udGludWUgdG8gdGhpbmsgYW5kIGRpc2N1c3MgdGhlIGFzcGVjdCBvZiBCRkQg ZmVhdHVyZSBkZW11eCBvbiB0aGUgQkZEIGxheWVyLCBiZWNhdXNlIHRoaXMgd2lsbCBiZSBhIHRv cGljIHRoYXQgd2Ugd2lsbCBoYXZlIHRvIHJlc29sdmUgaWYvd2hlbiB0aGUgQkZEIFdHIG5lZWQg dG8gcmVxdWVzdCBhbm90aGVyIHBvcnQuDQoNCltjaGFpciBoYXQgb2ZmXQ0KDQpUaGFua3MhDQoN Ci1Ob2JvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxpYSBBdGxh cyBbbWFpbHRvOmFrYXRsYXNAZ21haWwuY29tXQ0KPiBTZW50OiBTdW5kYXksIERlY2VtYmVyIDIx LCAyMDE0IDE6MTcgQU0NCj4gVG86IE1hcmMgQmluZGVyYmVyZ2VyDQo+IENjOiBOb2JvIEFraXlh IChub2JvKTsgcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogUy1CRkQgcG9ydCBhbGxv Y2F0aW9uDQo+IA0KPiANCj4gDQo+IE9uIFNhdCwgRGVjIDIwLCAyMDE0IGF0IDEwOjQyIFBNLCBN YXJjIEJpbmRlcmJlcmdlciA8bWFyY0BzbmlmZi5kZT4gd3JvdGU6DQo+IEhlbGxvIE5vYm8gZXQg YWwuLA0KPiANCj4gPiBTaW5jZSB0aGVyZSBoYXNuJ3QgYmVlbiBhbnkgbWFqb3Igb2JqZWN0aW9u IHRvIGdvaW5nIHdpdGggb25lIHBvcnQgZm9yDQo+ID4gUy1CRkQsIEknbSBzdGFydGluZyB0byBj b25jbHVkZSB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIHdoaWNoIHdlIGNhbiBsaXZlDQo+ID4gd2l0 aC4gSWYgYW55b25lIG9iamVjdCwgZG8gY2hpbWUgaW4gd2l0aGluIGZldyBkYXlzIGFuZCBwcm92 aWRlIHlvdXINCj4gPiByZWFzb25zLiBPdGhlcndpc2UsIHdlJ2xsIHByb3ZpZGUgImxldCdzIGdv IGFoZWFkIHdpdGggb25lIFMtQkZEIHBvcnQiIHRvDQo+ID4gSUFOQS4NCj4gDQo+IHdoaWNoIHBy b3ZlcyB0aGUgcHVzaGJhY2sgZnJvbSBJQU5BIHdhcyBhY3R1YWxseSBhIGdvb2QgdGhpbmcuICJk byB5b3UNCj4gcmVhbGx5DQo+IG5lZWQgdGhpcz8iIGlzIGEgcmVhc29uYWJsZSBxdWVzdGlvbi4g T3ZlcmFsbCB0aGUgbWVjaGFuaXNtcyBzZWVtIHRvIHdvcmsuDQo+IA0KPiANCj4gSW4gYW5vdGhl ciBlbWFpbCB5b3Ugc2FpZDoNCj4gDQo+IFtOT0JPXSBJQU5BIGJlbGlldmUgdGhhdCB0aGUgQkZE IHByb3RvY29sIGlzIGFidXNpbmcgdGhlIHBvcnQgc3BhY2UuIFRoZXkNCj4gYXJlDQo+IHN0cm9u Z2x5IHN1Z2dlc3RpbmcgdGhhdCBmZWF0dXJlIGRlbXV4IGJlIGRvbmUgb24gdGhlIGZlYXR1cmUg bGF5ZXIuIEFuZCBpdA0KPiBhcHBlYXJzIHRoYXQgdGhpcyBpc27igJl0IHRoZSBmaXJzdCB0aW1l IHRoaXMgdG9waWMgd2FzIGJyb3VnaHQgdXAuIFRodSB0aGUNCj4gcHVzaGJhY2sgZnJvbSBJQU5B Lg0KPiANCj4gSnVzdCB0byBjbGFyaWZ5IC0gdGhpcyBpcyBub3QgSUFOQS7CoCBUaGlzIGlzIHRo ZSBkZXNpZ25hdGVkIGV4cGVydCwgd2hvbSBpcw0KPiBhc3NpZ25lZA0KPiBieSB0aGUgSUVTRy7C oCBJQU5BLCBvZiBjb3Vyc2UsIGRvZXNuJ3QgZG8gcG9saWN5IHJlbGF0ZWQgdG8gdGhlIHByb3Rv Y29sDQo+IHBhcmFtZXRlcnMuDQo+IA0KPiBJIGFtIHZlcnkgZ2xhZCB0byBzZWUgdGhlIGNvbnZl cnNhdGlvbiByZXNvbHZpbmcgd2VsbC4NCj4gDQo+IFJlZ2FyZHMsDQo+IEFsaWENCj4gDQo+IEFj dHVhbGx5IEkgZG8gbm90IHJlbWVtYmVyIHRoYXQgdGhpcyB3YXMgYSByZWFsIHByb2JsZW0gaW4g dGhlIHBhc3QgLSBJIHRoaW5rDQo+IGl0IGlzIGp1c3Qgbm9ybWFsIGJ1c2luZXNzIHRoYXQgeW91 IGhhdmUgdG8gZXhwbGFpbiB3aHkgeW91IG5lZWQgdG8gdGFrZSBhDQo+IHBvcnQuDQo+IE9yIG1h eWJlIGl0J3MgYW5vdGhlciAoc2V0IG9mKSBwZXJzb24gdGhpcyB0aW1lIGJ1dCBhZ2FpbiwgdGhl eSBzZWUgdGhlIHBvaW50DQo+IGZvciBTLUJGRCBhbmQgYXJlIHdpbGxpbmcgdG8gcHJvdmlkZSBh IHBvcnQsIHNvIGl0J3Mgbm90IHRoZSBlbmQgb2YgdGhlIHdvcmxkLg0KPiANCj4gTm90IHRoYXQg eW91IHdpbGwgc2VlIG1lIGFyZ3VlIGFnYWluc3QgInYyIiA7LSkgYnV0IGl0IGRvZXNuJ3Qgc2Vl bSB0byBiZQ0KPiBuZWNlc3NhcnkgZm9yIFMtQkZELg0KPiANCj4gDQo+IEZvciB0aGUgZWNobywg YXMgYXNrZWQgaW4gYW5vdGhlciBlbWFpbDogd2hhdCBpcyBkaWZmZXJlbnQgZm9yIFMtQkZEIGVj aG8/DQo+IElzIHRoZXJlIGFueSBzcGVjaWFsL2RpZmZlcmVudCBiZWhhdmlvdXIgZXhwZWN0ZWQg b24gdGhlIHJlbW90ZSBzaWRlLA0KPiBjb21wYXJlZCB0byAzNzg1L3VkcCBlY2hvID8NCj4gDQo+ IA0KPiBSZWdhcmRzLCBNYXJjDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBPbiBUaHUs IDE4IERlYyAyMDE0IDEzOjU0OjI2ICswMDAwLCBOb2JvIEFraXlhIChub2JvKSB3cm90ZToNCj4g PiBbc25pcHBpbmcgaW4gb25seSB0aGUgcy1iZmQgcG9ydCBkaXNjdXNzaW9uIHBvcnRpb24gLi4u IHRvIGF0dGVtcHQgdG8gY2xvc2UNCj4gPiB0aGlzIG9mZl0NCj4gPg0KPiA+PiBPbiBXZWQsIERl YyAxNywgMjAxNCBhdCAwMjoxNjo0MlBNICswMDAwLCBOb2JvIEFraXlhIChub2JvKSB3cm90ZToN Cj4gPj4+IFtOT0JPXSBHb29kIHRoaW5nIGlzIHRoYXQgSUFOQSBpcyB3aWxsaW5nIHRvIGFsbG93 IHRoZSBwb3J0IGZvciBTLUJGRA0KPiA+Pj4gYXN5bmMuDQo+ID4+IEFuZCBjb25zaWRlcmluZyBl Y2hvIHBhY2tldCBjb250ZW50cyBpcyBzb21ldGhpbmcgaW1wbGVtZW50YXRpb25zIGNhbg0KPiA+ PiBkZWZpbmUgKGkuZS4gaGF2aW5nIHZlcnNpb24sIHR5cGUsIGV0YyksIHdlIF9zaG91bGQgYmVf IGFibGUgdG8gcmV1c2UgMzc4NQ0KPiA+PiBmb3INCj4gPj4gUy1CRkQgZWNoby4gRG8geW91IHRo aW5rIHRoaXMgaXMgdHJ1ZT8NCj4gPj4+DQo+ID4+PiBXaGF0IGRvIHlvdSB0aGluaz8NCj4gPj4+ DQo+ID4+PiBNYWxsaWs+PiBJZiB3ZSBwbGFuIHRvIGltcGxlbWVudCBhZGRpdGlvbmFsIGhlYWRl cnMgaW4gQkZEIHBhY2tldHMgZm9yDQo+ID4+IGRlbXV4IHB1cnBvc2UgdGhlbiBpdCBpcyB0aW1l IHdlIHN0YXJ0IGRpc2N1c3NpbmcgdGhlIHNhbWUuDQo+ID4+Pg0KPiA+Pj4gW05PQk9dIFRoaXMg Y2FuIHN0YXJ0IHVwIG5vdywgb3IgdGhpcyBoYXMgdG8gc3RhcnQgdXAgd2hlbiB0aGVyZSBpcw0K PiA+Pj4gYW5vdGhlcg0KPiA+PiBCRkQgZmVhdHVyZSByZXF1aXJpbmcgYSBuZXcgcG9ydC4NCj4g Pj4NCj4gPj4gSSB0aGluayB3ZSBoYXZlIGVub3VnaCBicmVhdGhpbmcgcm9vbSBmb3IgUy1CRkQg dG8gcHJvY2VlZCB3aXRoIGENCj4gc2luZ2xlDQo+ID4+IHBvcnQgZm9yIGFzeW5jIGFuZCBsZXR0 aW5nIHRoZSByZW1vdGUgZGVtdXggb24gZWNobyBjb250ZW50cyB3aXRoDQo+IGV4aXN0aW5nDQo+ ID4+IEJGRCBlY2hvIHBvcnQgZnJvbSA1ODgwLsKgIEF0IGxlYXN0IHRoYXQncyBob3cgSSByZWFk IHRoZSBhYm92ZS4NCj4gPg0KPiA+IFNpbmNlIHRoZXJlIGhhc24ndCBiZWVuIGFueSBtYWpvciBv YmplY3Rpb24gdG8gZ29pbmcgd2l0aCBvbmUgcG9ydCBmb3INCj4gPiBTLUJGRCwgSSdtIHN0YXJ0 aW5nIHRvIGNvbmNsdWRlIHRoYXQgdGhpcyBpcyBzb21ldGhpbmcgd2hpY2ggd2UgY2FuIGxpdmUN Cj4gPiB3aXRoLiBJZiBhbnlvbmUgb2JqZWN0LCBkbyBjaGltZSBpbiB3aXRoaW4gZmV3IGRheXMg YW5kIHByb3ZpZGUgeW91cg0KPiA+IHJlYXNvbnMuIE90aGVyd2lzZSwgd2UnbGwgcHJvdmlkZSAi bGV0J3MgZ28gYWhlYWQgd2l0aCBvbmUgUy1CRkQgcG9ydCIgdG8NCj4gPiBJQU5BLg0KPiA+DQo+ ID4gVGhhbmtzIQ0KPiA+DQo+ID4gLU5vYm8NCj4gPg0KPiA+DQoNCg== From nobody Sun Dec 21 22:29:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAAC1A8886 for ; Sun, 21 Dec 2014 22:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham 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 XJfEURlw2X9U for ; Sun, 21 Dec 2014 22:29:54 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155A51A89AA for ; Sun, 21 Dec 2014 22:29:54 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so3849194ier.0 for ; Sun, 21 Dec 2014 22:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:subject:references:from :mime-version:in-reply-to:message-id:date:cc:to; bh=4hgkeAisbvODxF4c+MokLBvdrh+93Z4pmwLWUmsp+ic=; b=eFI2b9W1ubFs+h2xTqxDrfKfrWjJmq2r+ajquW034zUXujKhD7SoAth2F89QR2LNfu 82YPKuclBRCxjEmT0R7arpre9D8gML6Z1Vp5NKSupd9pxbm83fPWt0uppZKIBaliLv76 3jfoC1tH651TmFC8y8BcPiG3ZBSBJ+mFXPccuIvo9u1UMQUFAaajqDOIBswWPs/L+m2q MR3uiD1PDrl82a3v2fJXLqInQgXs98JPXZD+9hksyQSBA6FQecPdXGi+iAThuU/KvGoV iUvX3XDcPTgb+BPuo9PhQ3xkAdqoEDMYgQOLHSNf91tn/XhLUYf8q67YPupswME7BJ/Z 5j7g== X-Received: by 10.107.129.80 with SMTP id c77mr18409457iod.92.1419229792873; Sun, 21 Dec 2014 22:29:52 -0800 (PST) Received: from [10.71.0.219] (96-35-158-10.static.stls.mo.charter.com. [96.35.158.10]) by mx.google.com with ESMTPSA id 5sm8114819iom.7.2014.12.21.22.29.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Dec 2014 22:29:51 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-0481D64C-4740-426A-8D0C-F86FA3C2D83F Content-Transfer-Encoding: 7bit Subject: Re: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91) References: <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> <20141219210222.GJ16279@pfrc> <7347100B5761DC41A166AC17F22DF1121B8C5EA0@eusaamb103.ericsson.se> From: Mahesh Jethanandani Mime-Version: 1.0 (1.0) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8C5EA0@eusaamb103.ericsson.se> Message-Id: Date: Sun, 21 Dec 2014 20:17:05 -0800 To: Gregory Mirsky X-Mailer: iPad Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2fJs5MuCfA2ySbNiUI8n1WP4EC4 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 06:29:55 -0000 --Apple-Mail-0481D64C-4740-426A-8D0C-F86FA3C2D83F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Greg, I do not think the issue we are trying to debug is of whether a BFD flap is a= real defect or a false negative, but rather why did BFD flap. And that is t= he information that is not available by running other PM tools. If you go back to my email from a few weeks ago, when I gave a customer scen= ario, you would remember I was talking about a BFD flap causing tunnel to sw= itch over. This draft is attempting to explain to the customer why the tunne= l switched over when it did. How would you explain to the customer the reaso= n for a failover? Mahesh Jethanandani mjethanandani@gmail.com > On Dec 19, 2014, at 2:52 PM, Gregory Mirsky w= rote: >=20 > Whether Down state is indication of the real defect or false negative, tha= t is the question to be answered through analysis of available information a= nd follow-up with debugging and troubleshooting the BFD itself rather than t= he network if there are concerns that it was not a real defect. --Apple-Mail-0481D64C-4740-426A-8D0C-F86FA3C2D83F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Greg,

I do no= t think the issue we are trying to debug is of whether a BFD flap is a real d= efect or a false negative, but rather why did BFD flap. And that is the info= rmation that is not available by running other PM tools.

If you go back to my email from a few weeks ago, when I gave a custome= r scenario, you would remember I was talking about a BFD flap causing tunnel= to switch over. This draft is attempting to explain to the customer why the= tunnel switched over when it did. How would you explain to the customer the= reason for a failover?

M= ahesh Jethanandani
mjethanandani@gmail.com<= /div>

On Dec 19, 2014, at 2:52 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wro= te:

Whether Down state is indication o= f the real defect or false negative, that is the question to be answered thr= ough analysis of available information and follow-up with debugging and trou= bleshooting the BFD itself rather than the network if there are concerns tha= t it was not a real defect.
= --Apple-Mail-0481D64C-4740-426A-8D0C-F86FA3C2D83F-- From nobody Sun Dec 21 22:46:38 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC211A89BB for ; Sun, 21 Dec 2014 22:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 MZg1WGx12H-0 for ; Sun, 21 Dec 2014 22:46:34 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.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 3C3FC1A89B8 for ; Sun, 21 Dec 2014 22:46:34 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-ee-54976d4792db Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1F.D1.03307.74D67945; Mon, 22 Dec 2014 02:00:55 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 01:46:27 -0500 From: Gregory Mirsky To: Mahesh Jethanandani Subject: RE: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91) Thread-Topic: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91) Thread-Index: AQHQG88XebvdVz4lWEyU7mFsO07GX5yXbPxAgAPrgID//9G68A== Date: Mon, 22 Dec 2014 06:46:26 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8C6959@eusaamb103.ericsson.se> References: <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> <20141219210222.GJ16279@pfrc> <7347100B5761DC41A166AC17F22DF1121B8C5EA0@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_7347100B5761DC41A166AC17F22DF1121B8C6959eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonRNc9d3qIwd8FWhb7D75ltTj9Zh2b xec/2xgdmD12zrrL7rFkyU8mj8u9W1kDmKO4bFJSczLLUov07RK4Mqbfes9W0BZRcar5A1sD 44XQLkYODgkBE4mvH+y6GDmBTDGJC/fWs3UxcnEICRxhlJh4fB8jhLOcUWL2/HtMIFVsAkYS Lzb2sIPYIgKGEqcOvACLMwt4SPRt3c0GYgsLpEvMeHmCDaImQ2JPx3lWCNtJYvrq14wgNouA qsSJWRfBangFfCWureplgVi2ik3iybcbYAlOAVuJa/Ongy1gBDrv+6k1UMvEJW49mc8EcbaA xJI955khbFGJl4//sULYShJzXl9jhqjPlzg/C6KeV0BQ4uTMJywTGEVnIRk1C0nZLCRls4CB xCygKbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMXKUFqeW5aYbGWxiBEbaMQk23R2Me15a HmIU4GBU4uHdIDE9RIg1say4MvcQozQHi5I476zaecFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGDNC39+Q+Kj0MElGLe37p4ii44efqH/vOrvfLVZdNbZi9pxmrmDZfcaS/dsOmP5KWdla ea+pw2/Ozw9rvi/8prHqol7dtB1KbOuLf6r37zshkPuU51+8yLG2o0KSDhGchlevBCkcK9Pc vHBlwdbi8qcJcT/3icUkBXdu2cpzwn3F8nSpjffla5RYijMSDbWYi4oTAYaz+lKVAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OeRQEs9I0J9lREpB75siiAj2IP8 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 06:46:36 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8C6959eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KaWYgeW91IGFzc3VtZSB0aGF0IEJGRCBmbGFwIGlzIG1vcmUgbGlrZWx5IGJl Y2F1c2Ugb2YgaW1wbGVtZW50YXRpb24gb3Igb3ZlcmxvYWRpbmcgc3lzdGVtIHJhdGhlciB0aGFu IGJlY2F1c2Ugb2YgbmV0d29yayBjb25kaXRpb24sIHRoZW4gSeKAmWQgbGlrZSB0byB1bmRlcnN0 YW5kIGhvdyBpbnRlcm1pdHRlbnQgY29uZ2VzdGlvbiBpbiBhIHNvdXJjZSBlbmQtbm9kZSBjYW4g YmUgZGlmZmVyZW50aWF0ZWQgZnJvbSBpbnRlcm1pdHRlbnQgY29uZ2VzdGlvbiBpbiB0aGUgbmV0 d29yayB3aXRob3V0IFBNLiBJ4oCZbSBub3QgcXVlc3Rpb25pbmcgdmFsdWUgb2YgaW1wcm92ZWQg ZGVidWdhYmlsaXR5IG9mIGFuIGltcGxlbWVudGF0aW9uLCBCRkQgaW4gdGhpcyBjYXNlLCBidXQg SeKAmWQgcHJlZmVyIGl0IG5vdCB0byBoYXZlIGFkdmVyc2UgaW1wYWN0IG9uIHRoZSBwcm90b2Nv bCwgb24gaXRzIGFiaWxpdHkgdG8gcGVyZm9ybSBpdHMgbWFpbiB0YXNrIG1vc3QgZWZmaWNpZW50 bHkuIERlYnVnZ2luZywgSSBiZWxpZXZlLCBiZWVuIGFuZCBzdGlsbCBpcywgcHJvcHJpZXRhcnks IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiBQcm9ibGVtcyB5b3XigJl2ZSBkZXNjcmliZWQsIEkg YmVsaWV2ZSwgdW5saWtlbHkgdG8gYmUgZXhwZXJpZW5jZWQgaW4gSFcgYmFzZWQgQkZEIGltcGxl bWVudGF0aW9uLiBUaHVzLCB3aGF0IGJlbmVmaXQsIGNoYW5nZXMgeW91IHByb3Bvc2UsIHdvdWxk IGJyaW5nIGZvciBzdWNoIGltcGxlbWVudGF0aW9ucz8NCg0KICAgICAgICAgICAgICAgIFJlZ2Fy ZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFoZXNo IEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KU2VudDogU3Vu ZGF5LCBEZWNlbWJlciAyMSwgMjAxNCA4OjE3IFBNDQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBK ZWZmcmV5IEhhYXM7IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBUV0FNUCBhbmFseXNp cyBmb3IgYXNzaXN0aW5nIEJGRCBkZWJ1Z2dpbiAod2FzIFJlOiBCRkQgc3RhYmlsaXR5IGZvbGxv dy11cCBmcm9tIElFVEYtOTEpDQoNCkdyZWcsDQoNCkkgZG8gbm90IHRoaW5rIHRoZSBpc3N1ZSB3 ZSBhcmUgdHJ5aW5nIHRvIGRlYnVnIGlzIG9mIHdoZXRoZXIgYSBCRkQgZmxhcCBpcyBhIHJlYWwg ZGVmZWN0IG9yIGEgZmFsc2UgbmVnYXRpdmUsIGJ1dCByYXRoZXIgd2h5IGRpZCBCRkQgZmxhcC4g QW5kIHRoYXQgaXMgdGhlIGluZm9ybWF0aW9uIHRoYXQgaXMgbm90IGF2YWlsYWJsZSBieSBydW5u aW5nIG90aGVyIFBNIHRvb2xzLg0KDQpJZiB5b3UgZ28gYmFjayB0byBteSBlbWFpbCBmcm9tIGEg ZmV3IHdlZWtzIGFnbywgd2hlbiBJIGdhdmUgYSBjdXN0b21lciBzY2VuYXJpbywgeW91IHdvdWxk IHJlbWVtYmVyIEkgd2FzIHRhbGtpbmcgYWJvdXQgYSBCRkQgZmxhcCBjYXVzaW5nIHR1bm5lbCB0 byBzd2l0Y2ggb3Zlci4gVGhpcyBkcmFmdCBpcyBhdHRlbXB0aW5nIHRvIGV4cGxhaW4gdG8gdGhl IGN1c3RvbWVyIHdoeSB0aGUgdHVubmVsIHN3aXRjaGVkIG92ZXIgd2hlbiBpdCBkaWQuIEhvdyB3 b3VsZCB5b3UgZXhwbGFpbiB0byB0aGUgY3VzdG9tZXIgdGhlIHJlYXNvbiBmb3IgYSBmYWlsb3Zl cj8NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQpPbiBEZWMgMTksIDIwMTQsIGF0IDI6NTIgUE0s IEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KV2hldGhlciBEb3duIHN0YXRlIGlzIGlu ZGljYXRpb24gb2YgdGhlIHJlYWwgZGVmZWN0IG9yIGZhbHNlIG5lZ2F0aXZlLCB0aGF0IGlzIHRo ZSBxdWVzdGlvbiB0byBiZSBhbnN3ZXJlZCB0aHJvdWdoIGFuYWx5c2lzIG9mIGF2YWlsYWJsZSBp bmZvcm1hdGlvbiBhbmQgZm9sbG93LXVwIHdpdGggZGVidWdnaW5nIGFuZCB0cm91Ymxlc2hvb3Rp bmcgdGhlIEJGRCBpdHNlbGYgcmF0aGVyIHRoYW4gdGhlIG5ldHdvcmsgaWYgdGhlcmUgYXJlIGNv bmNlcm5zIHRoYXQgaXQgd2FzIG5vdCBhIHJlYWwgZGVmZWN0Lg0K --_000_7347100B5761DC41A166AC17F22DF1121B8C6959eusaamb103erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFoZXNoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5pZiB5b3UgYXNzdW1lIHRoYXQgQkZEIGZsYXAgaXMgbW9yZSBsaWtlbHkgYmVjYXVz ZSBvZiBpbXBsZW1lbnRhdGlvbiBvciBvdmVybG9hZGluZyBzeXN0ZW0gcmF0aGVyIHRoYW4gYmVj YXVzZSBvZiBuZXR3b3JrIGNvbmRpdGlvbiwgdGhlbiBJ4oCZZCBsaWtlIHRvIHVuZGVyc3RhbmQN CiBob3cgaW50ZXJtaXR0ZW50IGNvbmdlc3Rpb24gaW4gYSBzb3VyY2UgZW5kLW5vZGUgY2FuIGJl IGRpZmZlcmVudGlhdGVkIGZyb20gaW50ZXJtaXR0ZW50IGNvbmdlc3Rpb24gaW4gdGhlIG5ldHdv cmsgd2l0aG91dCBQTS4gSeKAmW0gbm90IHF1ZXN0aW9uaW5nIHZhbHVlIG9mIGltcHJvdmVkIGRl YnVnYWJpbGl0eSBvZiBhbiBpbXBsZW1lbnRhdGlvbiwgQkZEIGluIHRoaXMgY2FzZSwgYnV0IEni gJlkIHByZWZlciBpdCBub3QgdG8gaGF2ZSBhZHZlcnNlDQogaW1wYWN0IG9uIHRoZSBwcm90b2Nv bCwgb24gaXRzIGFiaWxpdHkgdG8gcGVyZm9ybSBpdHMgbWFpbiB0YXNrIG1vc3QgZWZmaWNpZW50 bHkuIERlYnVnZ2luZywgSSBiZWxpZXZlLCBiZWVuIGFuZCBzdGlsbCBpcywgcHJvcHJpZXRhcnks IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiBQcm9ibGVtcyB5b3XigJl2ZSBkZXNjcmliZWQsIEkg YmVsaWV2ZSwgdW5saWtlbHkgdG8gYmUgZXhwZXJpZW5jZWQgaW4gSFcgYmFzZWQgQkZEIGltcGxl bWVudGF0aW9uLg0KIFRodXMsIHdoYXQgYmVuZWZpdCwgY2hhbmdlcyB5b3UgcHJvcG9zZSwgd291 bGQgYnJpbmcgZm9yIHN1Y2ggaW1wbGVtZW50YXRpb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFoZXNoIEpldGhh bmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFN1bmRheSwgRGVjZW1iZXIgMjEsIDIwMTQgODoxNyBQTTxicj4NCjxiPlRvOjwvYj4gR3Jl Z29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8L2I+IEplZmZyZXkgSGFhczsgcnRnLWJmZEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVFdBTVAgYW5hbHlzaXMgZm9yIGFzc2lzdGluZyBC RkQgZGVidWdnaW4gKHdhcyBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkx KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5H cmVnLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGRvIG5vdCB0aGluayB0aGUgaXNzdWUgd2UgYXJlIHRyeWluZyB0byBkZWJ1ZyBpcyBvZiB3 aGV0aGVyIGEgQkZEIGZsYXAgaXMgYSByZWFsIGRlZmVjdCBvciBhIGZhbHNlIG5lZ2F0aXZlLCBi dXQgcmF0aGVyIHdoeSBkaWQgQkZEIGZsYXAuIEFuZCB0aGF0IGlzIHRoZSBpbmZvcm1hdGlvbiB0 aGF0IGlzIG5vdCBhdmFpbGFibGUgYnkgcnVubmluZyBvdGhlciBQTSB0b29scy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGdvIGJh Y2sgdG8gbXkgZW1haWwgZnJvbSBhIGZldyB3ZWVrcyBhZ28sIHdoZW4gSSBnYXZlIGEgY3VzdG9t ZXIgc2NlbmFyaW8sIHlvdSB3b3VsZCByZW1lbWJlciBJIHdhcyB0YWxraW5nIGFib3V0IGEgQkZE IGZsYXAgY2F1c2luZyB0dW5uZWwgdG8gc3dpdGNoIG92ZXIuIFRoaXMgZHJhZnQgaXMgYXR0ZW1w dGluZyB0byBleHBsYWluIHRvIHRoZSBjdXN0b21lciB3aHkgdGhlIHR1bm5lbCBzd2l0Y2hlZA0K IG92ZXIgd2hlbiBpdCBkaWQuIEhvdyB3b3VsZCB5b3UgZXhwbGFpbiB0byB0aGUgY3VzdG9tZXIg dGhlIHJlYXNvbiBmb3IgYSBmYWlsb3Zlcj88YnI+DQo8YnI+DQo8Yj5NYWhlc2ggSmV0aGFuYW5k YW5pPC9iPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5j b208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gRGVjIDE5LCAy MDE0LCBhdCAyOjUyIFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbSI+Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hldGhlciBEb3duIHN0YXRlIGlzIGluZGljYXRpb24gb2YgdGhlIHJlYWwgZGVmZWN0IG9yIGZh bHNlIG5lZ2F0aXZlLCB0aGF0IGlzIHRoZSBxdWVzdGlvbiB0byBiZSBhbnN3ZXJlZCB0aHJvdWdo IGFuYWx5c2lzIG9mIGF2YWlsYWJsZSBpbmZvcm1hdGlvbiBhbmQgZm9sbG93LXVwIHdpdGggZGVi dWdnaW5nIGFuZCB0cm91Ymxlc2hvb3RpbmcgdGhlIEJGRCBpdHNlbGYgcmF0aGVyIHRoYW4gdGhl IG5ldHdvcmsNCiBpZiB0aGVyZSBhcmUgY29uY2VybnMgdGhhdCBpdCB3YXMgbm90IGEgcmVhbCBk ZWZlY3QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B8C6959eusaamb103erics_-- From nobody Mon Dec 22 07:15:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FAB1A19EC for ; Mon, 22 Dec 2014 07:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 PZLVIAwGbqng for ; Mon, 22 Dec 2014 07:15:26 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 323231A1A04 for ; Mon, 22 Dec 2014 07:15:25 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id A8F26C265; Mon, 22 Dec 2014 10:15:24 -0500 (EST) Date: Mon, 22 Dec 2014 10:15:24 -0500 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91) Message-ID: <20141222151524.GP16279@pfrc> References: <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> <20141219210222.GJ16279@pfrc> <7347100B5761DC41A166AC17F22DF1121B8C5EA0@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8C6959@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8C6959@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OB6H5D38QOHB6vJqgDdDd2sb85Y Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 15:15:27 -0000 Greg, On Mon, Dec 22, 2014 at 06:46:26AM +0000, Gregory Mirsky wrote: > if you assume that BFD flap is more likely because of implementation or > overloading system rather than because of network condition, then I???d > like to understand how intermittent congestion in a source end-node can be > differentiated from intermittent congestion in the network without PM. Congestion is one of the scenarios covered by tracking things at the BFD level. Another is simply whether packets are being generated or not or even the simple timings within protocol packet generation. While very lightweight, BFD still has implementation scaling choices that can lead to unusual behaviors. Packets are inherently jittered within the context of the protocol, but to some extent it's simply a practical consideration that maintaining tight timings is difficult. Similarly, if a packet simply is not sent because an internal timer ran late and it decided to send the next packet instead, that's a consideration. Being able to tie BFD issues to either issues within implementation vs. issues happening on the wire is useful, but the tool sets will overlap in some cases. > I???m not questioning value of improved debugability of an implementation, > BFD in this case, but I???d prefer it not to have adverse impact on the > protocol, on its ability to perform its main task most efficiently. > Debugging, I believe, been and still is, proprietary, implementation > specific. Problems you???ve described, I believe, unlikely to be > experienced in HW based BFD implementation. Unlikely to be experienced in HW? I suspect you'll get a much different set of feedback off-list where people think they can speak a bit more bluntly than on-list. > Thus, what benefit, changes > you propose, would bring for such implementations? Even in a situation where a given implementation was perfect, we care about any pair of implementations. When services flap due to BFD, you now have two devices to troubleshoot and blame. -- Jeff From nobody Mon Dec 22 07:28:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B2F1A9100 for ; Mon, 22 Dec 2014 07:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 QU2RjaLDjW2S for ; Mon, 22 Dec 2014 07:27:55 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAE21A9104 for ; Mon, 22 Dec 2014 07:27:55 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 819B9C26E; Mon, 22 Dec 2014 10:27:52 -0500 (EST) Date: Mon, 22 Dec 2014 10:27:52 -0500 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91) Message-ID: <20141222152752.GQ16279@pfrc> References: <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> <20141219210222.GJ16279@pfrc> <7347100B5761DC41A166AC17F22DF1121B8C5EA0@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8C5EA0@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Zvj9pGaoQXb2Tv13PFC5tEw2nWI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 15:27:57 -0000 On Fri, Dec 19, 2014 at 10:52:10PM +0000, Gregory Mirsky wrote: > thank you for your interest in this discussion. If you agree, we can add IPPM WG to it. I think that would be excessively overloading the conversation at this time. My primary point was that a performance measuring tech wasn't a fully appropriate tool for this situation. At some point if IPPM would like to have BFD devs visit their session and provide feedback about where implementation layering issues bias measurement, I suspect we can find volunteers. > I agree with your analysis of TWAMP and I would not suggest that > TWAMP-Test is well suited to debug BFD specific issues. But TWAMP-Test, as > other active performance measurement mechanisms, i.e. Y.1731 and MPLS PM > based on RFC 6374, may be used to measure latency and jitter of a network > or its segment. But such measurements will depend on where in the implementation the injectiosn and measurement are done. The closer you get to IEEE work, the more the measurements are likely to be implemented in HW as part of L2. The closer to IETF, the more likely it will be a layer just above HW L2. Each kind of measurement is valuable, and the results are ideally congruent. > And even more than active, passive measurement methods may > provide helpful information to troubleshoot network or BFD. That may be > done using IPFIX on certain nodes in the network with the data analysis by > a data collector. IPFIX typically will give you biased statistics either due to binning effects or the fact that it's statistically sampled. (Admittedly, I don't follow current work, only work I've done in the last 5 years with flow.) To some extent, that observation highlights a difference in what is being observed. When you are concerned about flow-level impacts in your network, the aggregates are the item of concern. For BFD, and to a lesser extent things like the other control plane protocols, a small number of lost packets at inopportune times has significantly negative impacts. The granularities become much tighter. > I agree that debugging and troubleshooting is often an art and operators > and vendors need to have and use all tools that are available. We > probably can do better job of instrumenting BFD debug tools but, I > believe, not by changing, not by overloading its main functions of > monitoring continuity and fast detection of the Loss of Continuity defect. > Whether Down state is indication of the real defect or false negative, > that is the question to be answered through analysis of available > information and follow-up with debugging and troubleshooting the BFD > itself rather than the network if there are concerns that it was not a > real defect. That is the fundamental point: What tools do we need in BFD to troubleshoot BFD especially given the layering issues that are somewhat distinct for its implementations? Sequencing information, minimally. I am becoming more convinced that the timing information is helpful - if tricky to implement in a cross-vendor fashion. I don't believe that BFD with such extensions should replace mechanisms such as CFM. -- Jeff From nobody Tue Dec 23 05:14:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB211A8A87 for ; Tue, 23 Dec 2014 05:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GUN2JjipPUr3 for ; Tue, 23 Dec 2014 05:14:18 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C931ACDA9 for ; Tue, 23 Dec 2014 05:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1072; q=dns/txt; s=iport; t=1419340254; x=1420549854; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=b+qpEt2ZqyAuyOuuuFuSfAOgZNUuxtYvouEdKisXW3k=; b=laAyWvd2kUwz0AbWuFak33vAr+XcmeDxrfp2gzA6c9BoWYAQWudSOVrH A3AhTdu2FjWAkc+L9xB1hnfdAo1RPTNy/0THXIHw4ST7iqf1Af/dmNDp7 I6Nu35PUFCpAlJTPn0pK5qR6gNhT6M2iNcUxIcEgiVa2qOvBxq1SbbviJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFADppmVStJA2B/2dsb2JhbABbgmQigSoExBeIFQKBGBYBAQEBAX2EDAEBAQMBHR06BQULAgEIDgoeEDIlAgQOBYgkCAHPEgEBAQEBAQEBAQEBAQEBAQEBAQEBARePPzMHgxaBEwEEjD2BV4hzgQ2CZYojgzkig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="382126422" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 23 Dec 2014 13:10:53 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBNDArre010763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Dec 2014 13:10:53 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 07:10:52 -0600 From: "Carlos Pignataro (cpignata)" To: Jeff Haas Subject: Re: WGLC for Seamless BFD Use Case; IPR attestation Thread-Topic: WGLC for Seamless BFD Use Case; IPR attestation Thread-Index: AQHQG9HcdD2ocC73SEKClqK+BsqnN5ydkLIA Date: Tue, 23 Dec 2014 13:10:52 +0000 Message-ID: References: <20141219212206.GK16279@pfrc> In-Reply-To: <20141219212206.GK16279@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/408O3JDeG0VG6gNjDFLQf4OSdJA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 23 Dec 2014 13:14:19 -0000 Jeff, draft-ietf-bfd-seamless-use-case is an important document, setting the stag= e for s-bfd protocol documents. It is in pretty good shape and contains use= ful use cases. As such, I support this WGLC and moving this document forwar= d towards pub. Thanks, Carlos. > On Dec 19, 2014, at 4:22 PM, Jeffrey Haas wrote: >=20 > Working Group, >=20 > The authors of draft-ietf-bfd-seamless-use-case have requested last call = for > this document. Given the end of year holidays for many IETF attendees, t= his > will lead to a somewhat extended polling period. >=20 > The WGLC polling period will end on January 9, 2015. Please send your > comments to the list as to whether you believe this document is ready for > publication. >=20 > Simultaneously, authors please state whether you have any IPR on this dra= ft. > If you do, I expect it to be acknowledged prior to the end of the last ca= ll > period. Any missing declarations for acknowledged IPR will be cause to > extend the polling period. >=20 > -- Jeff >=20 From nobody Tue Dec 23 05:38:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B66D1ACDEF for ; Tue, 23 Dec 2014 05:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7yBCo0uLrwMM for ; Tue, 23 Dec 2014 05:38:10 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0541ACDEB for ; Tue, 23 Dec 2014 05:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1011; q=dns/txt; s=iport; t=1419341890; x=1420551490; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=MIcbD0JZ/jiXE02djEE66YKsOZAnDWaV5PtKpfzOzD4=; b=ACgADhpPFpGkVUhuzUC8idMtl9BwrLgo7+QTSLSin1AM8m20KfjK5Gyq Ey7U0XRGnfMWoNTnnmJ1w/HMiDeGn3s3AePjvfYjGtnPBQgRBncmv5adT kdU/NLw3xpsw3AhUJGJ1edWSk3Y3OEDZTW8GPkTHIMDX0UVDmvK2+qqv9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAJNvmVStJV2a/2dsb2JhbABbgwaBIAoExBeIFQKBFxYBAQEBAX2EDQEBBDpRAQgYHkIlAgQBEogszwwBAQEBAQEEAQEBAQEBHI95hCkBBI4UiHOBDYJliiODOSKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="379052448" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 23 Dec 2014 13:38:09 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBNDc8bt030061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Dec 2014 13:38:09 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.50]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 07:38:08 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: "Nagendra Kumar Nainar (naikumar)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: WGLC for Seamless BFD Use Case; IPR attestation Thread-Topic: WGLC for Seamless BFD Use Case; IPR attestation Thread-Index: AQHQG9HcjDf0dtxW1EaFdHbH0lewEJyYzq6AgAR10QA= Date: Tue, 23 Dec 2014 13:38:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.203.88] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xq5NwbjHfx2JrSqLownl3U4YZuM X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 23 Dec 2014 13:38:11 -0000 Hi, I support as a co-author. Regards, Nagendra On 12/20/14, 12:31 PM, "Nagendra Kumar Nainar (naikumar)" wrote: >Hi, > >I am not aware of any IPR related to this document. > >Thanks, >Nagendra > >On 12/19/14, 4:22 PM, "Jeffrey Haas" wrote: > >>Working Group, >> >>The authors of draft-ietf-bfd-seamless-use-case have requested last call >>for >>this document. Given the end of year holidays for many IETF attendees, >>this >>will lead to a somewhat extended polling period. >> >>The WGLC polling period will end on January 9, 2015. Please send your >>comments to the list as to whether you believe this document is ready for >>publication. >> >>Simultaneously, authors please state whether you have any IPR on this >>draft. >>If you do, I expect it to be acknowledged prior to the end of the last >>call >>period. Any missing declarations for acknowledged IPR will be cause to >>extend the polling period. >> >>-- Jeff >> > From nobody Wed Dec 24 15:00:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CF71A1B8E for ; Wed, 24 Dec 2014 15:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 nfmTQguh0bbD for ; Wed, 24 Dec 2014 15:00:43 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436821A1B64 for ; Wed, 24 Dec 2014 15:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=686; q=dns/txt; s=iport; t=1419462043; x=1420671643; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9AESaadRfw9FSBl7+ixy3eYdKcbvkEOFBZq+O8GxZJ4=; b=WNNoKmIWhjKLjL/7bxPNKSmeZ4D4lkEJL7nTz1wA0V2Zf35NBWSSkLMA FdD9ZPXDC2dAz/xnfcs4eAkAz6RlXjIpHGGopUQtXsTGivHZnYu4ERwn+ KR2gMdGNkJdOzfflEdFwLaAPc3T99cIJCeAjkPymAPr+kSKqfO/MXvkUG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIJAMpEm1StJA2J/2dsb2JhbABcgmQiUlgBA4MAw1iFbQIcdBYBAQEBAX2EDgEDASMRNxMNASICBiACBDAVEQEEGwGIGwgBDKRdj0SVSgEBAQEGAQEBAR6BIY4ggyAugRMFjhWKAI0Kgzkig25vAYFEfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,639,1413244800"; d="scan'208";a="108246629" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 24 Dec 2014 23:00:42 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBON0go6024016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Dec 2014 23:00:42 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 24 Dec 2014 17:00:42 -0600 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: s-bfd port (7784) assignment complete Thread-Topic: s-bfd port (7784) assignment complete Thread-Index: AdAfzHkC6jlXbeoAQZWXA2vVWuj+/g== Date: Wed, 24 Dec 2014 23:00:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.231.160] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/040IXb63LmmSP4i9FPF-KMpOKv8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 24 Dec 2014 23:00:44 -0000 RGVhciBCRkQgV0csDQoNCkRlc2lnbmF0ZWQgZXhwZXJ0cyBoYXZlIGNvbXBsZXRlZCB0aGUgcmV2 aWV3IGFuZCB0aGUgcy1iZmQgcG9ydCwgNzc4NCwgaGFzIGJlZW4gYWxsb2NhdGVkLg0KDQo+IHMt YmZkCTc3ODQJdWRwCVNlYW1sZXNzIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24g KFMtQkZEKQ0KDQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3NlcnZpY2UtbmFtZXMt cG9ydC1udW1iZXJzL3NlcnZpY2UtbmFtZXMtcG9ydC1udW1iZXJzLnhodG1sP3NlYXJjaD03Nzg0 DQoNCkl0IGlzIG9mZmljaWFsIDopDQoNCkFuZCB0aGlzIGlzIGEgZ29vZCB0aW1pbmcgdG8gc2F5 IC4uLg0KDQpUaGFuayB5b3UgZm9yIGFsbCBvZiB5b3VyIGhhcmQgd29yayBpbiAyMDE0Lg0KDQpI YXBweSBob2xpZGF5cyAmIGxvb2sgZm9yd2FyZCB0byBwdXNoaW5nIHRoZSBCRkQgdGVjaG5vbG9n eSBldmVuIGZ1cnRoZXIgaW4gMjAxNSENCg0KLU5vYm8gYW5kIEplZmYNCg0K From nobody Thu Dec 25 05:29:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311AD1A87BE for ; Thu, 25 Dec 2014 05:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 rd3_nofePVgQ for ; Thu, 25 Dec 2014 05:29:48 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152E21A87B9 for ; Thu, 25 Dec 2014 05:29:48 -0800 (PST) Received: from CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) by CO2PR0501MB1015.namprd05.prod.outlook.com (25.160.10.152) with Microsoft SMTP Server (TLS) id 15.1.49.12; Thu, 25 Dec 2014 13:29:46 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.49.12; Thu, 25 Dec 2014 13:29:45 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0049.002; Thu, 25 Dec 2014 13:29:44 +0000 From: Santosh P K To: Jeffrey Haas Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThCAAAlCsIAE3GeAgAA3/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAXdhgIAAcEwAgAAVyUCABPle4IAi+X2AgAjkx3A= Date: Thu, 25 Dec 2014 13:29:44 +0000 Message-ID: References: <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.namprd05.prod.outlook.com> <20141219214011.GL16279@pfrc> In-Reply-To: <20141219214011.GL16279@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.15] authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(24454002)(51704005)(377454003)(189002)(93886004)(66066001)(68736005)(15975445007)(102836002)(20776003)(21056001)(106356001)(101416001)(2900100001)(230783001)(97736003)(92566001)(77156002)(46102003)(74316001)(106116001)(64706001)(62966003)(1720100001)(54356999)(86362001)(2950100001)(77096005)(31966008)(122556002)(87936001)(2656002)(99286002)(105586002)(76176999)(54606007)(107046002)(99396003)(50986999)(76576001)(4396001)(19621155008)(54206007)(120916001)(110136001)(19580405001)(33656002)(19580395003)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Dec 2014 13:29:44.4341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB821 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB1015; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/p6x6c7i4Jnk3xq14jAmLYOYgyEw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 25 Dec 2014 13:29:51 -0000 Jeff, Thanks a lot for updating this in wiki :). Thanks Santosh P K =20 > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Saturday, December 20, 2014 3:10 AM > To: Santosh P K > Cc: Vengada Prasad Govindan (venggovi); Mingui Zhang; Gregory Mirsky; > Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > On Thu, Nov 27, 2014 at 03:55:48PM +0000, Santosh P K wrote: > > I would like to thank all for valuable comments. I think we have made > enough progress now. Below are the points on which we have rough > consensus . >=20 > I have taken this summary and posted it to the wiki for tracking purposes= . > Please update consensus there. >=20 > http://wiki.tools.ietf.org/wg/bfd/trac/wiki/BfdMultipointIssues >=20 > (Some working groups use trac. Some keep a text file in svn. Let's do th= is a > bit more light weight. :-) >=20 >=20 > -- Jeff From nobody Sun Dec 28 17:04:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A89F1AC3F7; Sun, 28 Dec 2014 17:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 u5O9q95AnlzH; Sun, 28 Dec 2014 17:03:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 338FE1AC3DC; Sun, 28 Dec 2014 17:03:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mpls-mib-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229010359.8722.42613.idtracker@ietfa.amsl.com> Date: Sun, 28 Dec 2014 17:03:59 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/n0iEQ1-bPyO4kU4mtWPh4NCbWm8 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 01:04:00 -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 Working Group of the IETF. Title : BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks Authors : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-bfd-mpls-mib-05.txt Pages : 23 Date : 2014-12-28 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mpls-mib-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 Tue Dec 30 09:25:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857B41A0399 for ; Tue, 30 Dec 2014 09:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 R-G-iJQaDW1e for ; Tue, 30 Dec 2014 09:25:41 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 262871A039D for ; Tue, 30 Dec 2014 09:25:40 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7D781C20F; Tue, 30 Dec 2014 12:25:39 -0500 (EST) Date: Tue, 30 Dec 2014 12:25:39 -0500 From: Jeffrey Haas To: draft-ietf-bfd-mpls-mib@tools.ietf.org Subject: Comments on draft-ietf-bfd-mpls-mib-05 Message-ID: <20141230172539.GA25357@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FS2yy4z2hfuSU5R4iDHr2lGRHxw Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 30 Dec 2014 17:25:42 -0000 Note that I have neither audited the conformances nor the security section in detail. : This document adopts the definitions, acronyms and mechanisms : described in [BFD], [BFD-1HOP], [BFD-MH], [RFC5884], [RFC6428]. : Unless otherwise stated, the mechanisms described therein will not be : re-described here. I'd suggest making the links BFD and BFD-1HOP pointer to the relevant RFC numbers. Otherwise continue the naming practice with 5884 and 6428. : 5.1. Extensions to the BFD session table (bfdSessionTable) Auditing this entry lead to the discovery of errata in RFC 7331. The underlying table is bfdSessTable and should be listed that way in this MIB. This document contains two textual conventions. The SessionMapTypeTC in particular has properties that suggest it may be best to craft a separate MIB module to permit IANA maintenance. This will permit the TCs to be maintained separately without requiring an update to the RFC. It is unclear whether the DefectActionTC would similarly benefit from being an IANA maintained MIB module. If the SessionMapTypeTC is placed in a separate module, section 5.1 will require updating. : Similarly BFD session would be configured on the tail-end of "Similarly, the BFD session"... The same correction applies in section 5.2. Section 5.3 refers to bfdSessionPerfTable. As noted from the errata mentioned above, bfdSessPerfTable is the actual table name. Section 6: : RowPointer,TruthValue,TEXTUAL-CONVENTION Please apply consistent spacing after commas. : -- RFC Ed.: RFC-editor pls fill in xxxx s/xxxx/XXX/ (Although I suspect the RFC editor would still catch this. :-) : DESCRIPTION : "A row in this table extends a row in bfdSessTable." While I believe this comment is clear, it may be worth noting explicitly that not all bfdSessEntry instances will utilize these extensions. This will make it clearer for MIB doctor review why you have chosen to use a foreign index rather than augment the underlying bfdSessTable. : bfdMplsSessRole OBJECT-TYPE : SYNTAX INTEGER { : active(1), : passive(2) : } While obviously required for the BFD MPLS MIB, I'm wondering if the active/passive state is more generally useful for the underlying BFD MIB. While I don't believe that we should force this to go into an update for the BFD MIB, the BFD Yang editors should probably make note of this configuration state for their efforts. : REFERENCE : "1.RFC6428, Proactive Connectivity Verification, The 1 here is extraneous and should be removed. : bfdMplsSessMapPointer OBJECT-TYPE : SYNTAX RowPointer : MAX-ACCESS read-create : STATUS current : DESCRIPTION : "If bfdMplsSessMapType is nonTeIpv4(1) or nonTeIpv6(2), : then this object MUST contain zeroDotZero or point to : an instance of the mplsXCEntry indicating the LDP-based : LSP associated with this BFD session. [...] As noted above, I suspect that the underlying bfdMplsSessMapType TC should be an IANA maintained TC. That would impact the text in this section. I'm somewhat unclear on how the underlying dependencies of the DESCRIPTION text for this object which belongs in this MIB vs. the bfdMplsSessMapType TC in a separate module should be handled. Probably a question for the MIB doctors. [next two comments out of order from the MIB text] : If this object contains zeroDotZero then no valid path is : associated with this BFD session entry till it is : populated with a valid pointer consistent with : the value of bfdMplsSessMapType as explained above." My reading of this is that if a BfdMplsSessEntry row is instantiated but bfdSessRowStatus is otherwise set to a state that would be "running" (e.g. active, createAndGo), that action should fail. Similarly: : If this object points to a conceptual row instance : in a table consistent with bfdMplsSessMapType but this : instance does not currently exist then no valid : path is associated with this session entry. In the case where the entry does not currently exist, I would similarly expect the bfdSessRowStatus would fail for running states. I would spell this out. It is probably also necessary to spell out what happens when an underlying reference is invalidated. My expectation is that the bfdSessRowStatus would need to transition to notInService or notReady. The bfdMplsSessPerfTable consists only of Counter32 objects. Practice appears to use paired Counter64 "High Capacity" counters. Are these being left out for any specific reason? One final comment is that no NOTIFICATIONs are defined for this MIB. While not strictly required, an operator has no indication that a given NOTIFICATION in the underlying RFC 7331 MIB is for sessions that may change state for reasons having to do with underlying MPLS session association. One possibility that comes to mind to address this is to add a recommendation that the bfdSessUp/bfdSessDown NOTIFICATIONS receive an additional OBJECTS entry of bfdMplsSessMapPointer. The one obvious counter to such a practice is this may disrupt the low/high range optimization in the base NOTIFICATION. -- Jeff From nobody Wed Dec 31 18:41:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C751A1B22; Wed, 31 Dec 2014 18:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-Bl1h5_ITcu; Wed, 31 Dec 2014 18:41:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 442CE1A1B21; Wed, 31 Dec 2014 18:41:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3390A180448; Wed, 31 Dec 2014 18:41:26 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7419 on Common Interval Support in Bidirectional Forwarding Detection X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150101024126.3390A180448@rfc-editor.org> Date: Wed, 31 Dec 2014 18:41:26 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/nCChk3-pk9afAVuCrg7JboFwr0w Cc: rtg-bfd@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 02:41:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7419 Title: Common Interval Support in Bidirectional Forwarding Detection Author: N. Akiya, M. Binderberger, G. Mirsky Status: Informational Stream: IETF Date: December 2014 Mailbox: nobo@cisco.com, mbinderb@cisco.com, gregory.mirsky@ericsson.com Pages: 8 Characters: 16944 Updates: RFC 5880 I-D Tag: draft-ietf-bfd-intervals-05.txt URL: https://www.rfc-editor.org/rfc/rfc7419.txt Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions. This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals. This document is a product of the Bidirectional Forwarding Detection Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Dec 31 19:56:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17D71A1B35 for ; Wed, 31 Dec 2014 19:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 nz803WZelSvr for ; Wed, 31 Dec 2014 19:56:06 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E858C1A00D8 for ; Wed, 31 Dec 2014 19:56:05 -0800 (PST) Received: from [10.151.188.151] (unknown [166.170.21.63]) by slice.pfrc.org (Postfix) with ESMTPSA id 37068C178 for ; Wed, 31 Dec 2014 22:56:05 -0500 (EST) From: Jeff Haas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: RFC 7419 on Common Interval Support in Bidirectional Forwarding Detection Message-Id: Date: Wed, 31 Dec 2014 22:56:04 -0500 References: <20150101024126.3390A180448@rfc-editor.org> In-Reply-To: <20150101024126.3390A180448@rfc-editor.org> To: rtg-bfd@ietf.org X-Mailer: iPhone Mail (12B440) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/itHXlsyOHThr2UrT0Z-6mmxQNbs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 03:56:08 -0000 Happy new year and congratulations to the Working Group for another RFC! Jeff > On Dec 31, 2014, at 21:41, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7419 >=20 > Title: Common Interval Support in Bidirectional=20 > Forwarding Detection=20 > Author: N. Akiya, M. Binderberger, G. Mirsky > Status: Informational > Stream: IETF > Date: December 2014 > Mailbox: nobo@cisco.com,=20 > mbinderb@cisco.com,=20 > gregory.mirsky@ericsson.com > Pages: 8 > Characters: 16944 > Updates: RFC 5880 >=20 > I-D Tag: draft-ietf-bfd-intervals-05.txt >=20 > URL: https://www.rfc-editor.org/rfc/rfc7419.txt >=20 > Bidirectional Forwarding Detection (BFD) requires that messages be > transmitted at regular intervals and provides a way to negotiate the > interval used by BFD peers. Some BFD implementations may be > restricted to only support several interval values. When such BFD > implementations speak to each other, there is a possibility of two > sides not being able to find a common value for the interval to run > BFD sessions. >=20 > This document updates RFC 5880 by defining a small set of interval > values for BFD that we call "Common Intervals" and recommends > implementations to support the defined intervals. This solves the > problem of finding an interval value that both BFD speakers can > support while allowing a simplified implementation as seen for > hardware-based BFD. It does not restrict an implementation from > supporting more intervals in addition to the Common Intervals. >=20 > This document is a product of the Bidirectional Forwarding Detection Worki= ng Group of the IETF. >=20 >=20 > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 From nobody Wed Dec 31 21:06:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AF61A1B40 for ; Wed, 31 Dec 2014 21:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 TabNyJRdzVjQ for ; Wed, 31 Dec 2014 21:06:11 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A9F1A1B36 for ; Wed, 31 Dec 2014 21:06:11 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rd18so15467109iec.22 for ; Wed, 31 Dec 2014 21:06:10 -0800 (PST) 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:content-type; bh=gyO86fXUX+QGhQaoe5qXWZUKPGK8XXqVxSshUIztgvw=; b=PiZunvDI6PJVE7Jhi1FqR0rWfDsmI3WvYWPrxCnSCpBcjbWrph4v0qLnG0g7pHvf2m XogBwNJdrGLzutCq4sNtS4lH0F2atRD7Qs1LriTqs/qXibEuF3I0j6lZp4KlHt40mEho YZr8ZKX6aeO3wTZT/ljh3cNHwQ4iZg5Q1l3ur7vFDS1oB+AbLo1B1GMqR0P8tw2puBu+ PoUaDtuWS0wLABysSkwy4+0r2RiLnoMHoJv+LJ9zFSjezBgfSVETALNrSxcowPNae0K4 4Zej3Bwg5N3AKXYTh2cUlKAod1EYcMbjAEpypLehgmtatXPKlLkX1sa7BAvAcsexTmRy TPBQ== MIME-Version: 1.0 X-Received: by 10.50.29.107 with SMTP id j11mr57542178igh.32.1420088770431; Wed, 31 Dec 2014 21:06:10 -0800 (PST) Received: by 10.107.174.168 with HTTP; Wed, 31 Dec 2014 21:06:10 -0800 (PST) In-Reply-To: References: <20150101024126.3390A180448@rfc-editor.org> Date: Wed, 31 Dec 2014 21:06:10 -0800 Message-ID: Subject: Re: RFC 7419 on Common Interval Support in Bidirectional Forwarding Detection From: Greg Mirsky To: Jeff Haas Content-Type: multipart/alternative; boundary=047d7bd760c4b61135050b902e68 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/HEQwtn9_QBT49lhjZwJXKRVeTUw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 05:06:14 -0000 --047d7bd760c4b61135050b902e68 Content-Type: text/plain; charset=UTF-8 Happy New Year and the best wishes to All! On Wed, Dec 31, 2014 at 7:56 PM, Jeff Haas wrote: > Happy new year and congratulations to the Working Group for another RFC! > > Jeff > > > On Dec 31, 2014, at 21:41, rfc-editor@rfc-editor.org wrote: > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 7419 > > > > Title: Common Interval Support in Bidirectional > > Forwarding Detection > > Author: N. Akiya, M. Binderberger, G. Mirsky > > Status: Informational > > Stream: IETF > > Date: December 2014 > > Mailbox: nobo@cisco.com, > > mbinderb@cisco.com, > > gregory.mirsky@ericsson.com > > Pages: 8 > > Characters: 16944 > > Updates: RFC 5880 > > > > I-D Tag: draft-ietf-bfd-intervals-05.txt > > > > URL: https://www.rfc-editor.org/rfc/rfc7419.txt > > > > Bidirectional Forwarding Detection (BFD) requires that messages be > > transmitted at regular intervals and provides a way to negotiate the > > interval used by BFD peers. Some BFD implementations may be > > restricted to only support several interval values. When such BFD > > implementations speak to each other, there is a possibility of two > > sides not being able to find a common value for the interval to run > > BFD sessions. > > > > This document updates RFC 5880 by defining a small set of interval > > values for BFD that we call "Common Intervals" and recommends > > implementations to support the defined intervals. This solves the > > problem of finding an interval value that both BFD speakers can > > support while allowing a simplified implementation as seen for > > hardware-based BFD. It does not restrict an implementation from > > supporting more intervals in addition to the Common Intervals. > > > > This document is a product of the Bidirectional Forwarding Detection > Working Group of the IETF. > > > > > > INFORMATIONAL: This memo provides information for the Internet community. > > It does not specify an Internet standard of any kind. Distribution of > > this memo is unlimited. > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > To subscribe or unsubscribe, see > > https://www.ietf.org/mailman/listinfo/ietf-announce > > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > For searching the RFC series, see https://www.rfc-editor.org/search > > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > > specifically noted otherwise on the RFC itself, all RFCs are for > > unlimited distribution. > > > > > > The RFC Editor Team > > Association Management Solutions, LLC > > > > --047d7bd760c4b61135050b902e68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Happy New Year and the best wishes to All!

On Wed, Dec 31, 2014 at 7:5= 6 PM, Jeff Haas <jhaas@pfrc.org> wrote:
Happy new year and congratulations to the Working Group for anot= her RFC!

Jeff

> On Dec 31, 2014, at 21:41, rfc-editor@rfc-editor.org wrote:
>
> A new Request for Comments is now available in online RFC libraries. >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 7419
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 Common Interval = Support in Bidirectional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F= orwarding Detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0N. Akiya, M. Bin= derberger, G. Mirsky
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Informational >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0December 20= 14
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 nobo@cisco.com,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= a href=3D"mailto:mbinderb@cisco.com">mbinderb@cisco.com,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= a href=3D"mailto:gregory.mirsky@ericsson.com">gregory.mirsky@ericsson.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 16944
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates:=C2=A0 =C2=A0 RFC 5880
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-bfd-interv= als-05.txt
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.r= fc-editor.org/rfc/rfc7419.txt
>
> Bidirectional Forwarding Detection (BFD) requires that messages be
> transmitted at regular intervals and provides a way to negotiate the > interval used by BFD peers.=C2=A0 Some BFD implementations may be
> restricted to only support several interval values.=C2=A0 When such BF= D
> implementations speak to each other, there is a possibility of two
> sides not being able to find a common value for the interval to run > BFD sessions.
>
> This document updates RFC 5880 by defining a small set of interval
> values for BFD that we call "Common Intervals" and recommend= s
> implementations to support the defined intervals.=C2=A0 This solves th= e
> problem of finding an interval value that both BFD speakers can
> support while allowing a simplified implementation as seen for
> hardware-based BFD.=C2=A0 It does not restrict an implementation from<= br> > supporting more intervals in addition to the Common Intervals.
>
> This document is a product of the Bidirectional Forwarding Detection W= orking Group of the IETF.
>
>
> INFORMATIONAL: This memo provides information for the Internet communi= ty.
> It does not specify an Internet standard of any kind. Distribution of<= br> > this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>=C2=A0 https://www.ietf.org/mailman/listinfo/ietf-announce >=C2=A0 https://mailman.rfc-editor.org/mailman/listinfo/rfc-= dist
>
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/rfc.html
>
> Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>


--047d7bd760c4b61135050b902e68--