RE: BFD stability follow-up from IETF-91
Santosh P K <santoshpk@juniper.net> Fri, 28 November 2014 13:12 UTC
Return-Path: <santoshpk@juniper.net>
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 58F1E1A1AFB for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Nov 2014 05:12:06 -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 gFUOGprdloRM for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Nov 2014 05:12:02 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1691A1AD3 for <rtg-bfd@ietf.org>; Fri, 28 Nov 2014 05:12:01 -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; Fri, 28 Nov 2014 13:11:38 +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; Fri, 28 Nov 2014 13:11:38 +0000
From: Santosh P K <santoshpk@juniper.net>
To: Manav Bhatia <manavbhatia@gmail.com>
Subject: RE: BFD stability follow-up from IETF-91
Thread-Topic: BFD stability follow-up from IETF-91
Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuCAAAvZAIAAAu3AgAAG7QCAAV2GoA==
Date: Fri, 28 Nov 2014 13:11:36 +0000
Message-ID: <284b2137c42a402d8e712bb4c7f6c9d6@CO2PR0501MB823.namprd05.prod.outlook.com>
References: <20141126001931.GJ20330@pfrc> <CAG1kdoghcA=xSaXmkr68qduH2t8oC=-ZazoQztj8JK12SazKsw@mail.gmail.com> <20141126005023981392.0c488535@sniff.de> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B2D9A97@SZXEMA510-MBX.china.huawei.com> <20141126094242449051.c8abfe39@sniff.de> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B2DB0BD@SZXEMA510-MBX.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <CAG1kdojcmMj38t3wj24zy=6vn4Pa04khuJT4tN5tJF56g0kDPA@mail.gmail.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <CAG1kdoi6skeQTmn0zW9ML7hfseXgVRh3=6ifF2kD+R8UK8BS8A@mail.gmail.com> <7595889a8ea9451f8043f7587b6d9631@CO2PR0501MB823.namprd05.prod.outlook.com> <CAG1kdoiurzUvNvhe1f4uxX47U3zp-SEj+Zg=-pHMGNS030bMKg@mail.gmail.com>
In-Reply-To: <CAG1kdoiurzUvNvhe1f4uxX47U3zp-SEj+Zg=-pHMGNS030bMKg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.15]
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: 04097B7F7F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(13464003)(377454003)(51704005)(199003)(76176999)(54356999)(31966008)(64706001)(46102003)(15975445006)(101416001)(2656002)(122556002)(15202345003)(40100003)(1720100001)(87936001)(19580395003)(21056001)(19580405001)(561944003)(120916001)(110136001)(33646002)(107046002)(74316001)(106356001)(106116001)(20776003)(108616004)(93886004)(86362001)(99286002)(95666004)(105586002)(92566001)(76576001)(77156002)(50986999)(66066001)(62966003)(1411001)(4396001)(24736002); 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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/I1W6AWqwiP1zA1m33fYuvCABYsc
Cc: "rtg-bfd@ietf.org" <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" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 13:12:06 -0000
Hi Manav, Thanks. Please see inline. > >> 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 > > > > You are suggesting to add the debug trailer with or without authentication > right? > > without. If we can go with trailer method then it can be applicable to both with and without Auth right? I was thinking having two solution might complicate things :)? Thanks Santosh P K > > > >> On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K <santoshpk@juniper.net> > >> 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 > >> >> >> >>> <jhaas@pfrc.org> > >> >> 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. > >> >> >> >>>> ppt > >> >> >> >>>> x > >> >> >> >>>> > >> >> >> >>>> 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 > >> >> >> >>>> > >> >> >> >>> > >> >> >> > > >> >> > > >> >
- BFD stability follow-up from IETF-91 Jeffrey Haas
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Mach Chen
- RE: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Mach Chen
- RE: BFD stability follow-up from IETF-91 Vengada Prasad Govindan (venggovi)
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Abhishek Verma
- RE: BFD stability follow-up from IETF-91 Fan, Peng
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- RE: BFD stability follow-up from IETF-91 Fan, Peng
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Jeffrey Haas
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Fan, Peng
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Mahesh Jethanandani
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Vengada Prasad Govindan (venggovi)
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Mahesh Jethanandani
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Nobo Akiya (nobo)
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Nobo Akiya (nobo)
- Re: BFD stability follow-up from IETF-91 Jeffrey Haas
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Sam K. Aldrin
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Sam K. Aldrin
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Sam K. Aldrin
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Mahesh Jethanandani
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Sam Aldrin
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Mahesh Jethanandani
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- TWAMP analysis for assisting BFD debuggin (was Re… Jeffrey Haas
- RE: TWAMP analysis for assisting BFD debuggin (wa… Gregory Mirsky
- Re: TWAMP analysis for assisting BFD debuggin (wa… Mahesh Jethanandani
- RE: TWAMP analysis for assisting BFD debuggin (wa… Gregory Mirsky
- Re: TWAMP analysis for assisting BFD debuggin (wa… Jeffrey Haas
- Re: TWAMP analysis for assisting BFD debuggin (wa… Jeffrey Haas