From jhaas@slice.pfrc.org Thu Aug 1 07:26:52 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4600721E81D0 for ; Thu, 1 Aug 2013 07:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-ez7qs-xJIO for ; Thu, 1 Aug 2013 07:26:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2B46521E81E4 for ; Thu, 1 Aug 2013 07:26:25 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9AA1AC27A; Thu, 1 Aug 2013 10:26:19 -0400 (EDT) Date: Thu, 1 Aug 2013 10:26:19 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: KARP presentation on impact of SHA-2 Message-ID: <20130801142619.GB23273@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2013 14:26:53 -0000 Here's how a software based SHA-2 256 implementation behaved. http://tools.ietf.org/agenda/87/slides/slides-87-karp-4.pdf KARP WG slides http://www.ietf.org/mail-archive/web/karp/current/msg01112.html Start of WG discussion thread. -- Jeff From lokeshnb1@gmail.com Tue Aug 20 23:40:20 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3D11E81BE for ; Tue, 20 Aug 2013 23:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPqLNKteE7AR for ; Tue, 20 Aug 2013 23:40:20 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id E3FF511E819A for ; Tue, 20 Aug 2013 23:40:19 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so46615oag.12 for ; Tue, 20 Aug 2013 23:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2lFK3J+g6MH3Cm0SrMdBdJ03BuZ+l5iBRdSaGlrxmvs=; b=r32527PxqgXIM4vOz6h8cxgfet4CIDLaisFpfVNoFgeYLFDM4NGshOTbSRUcCesXUY hDL95cn+4kWlQ2dBNsVVdF9ZGVe8shLmhIPZw4lRy3IO1DMsnE3xUP7etxrYvcUD6mco tb6bh+2YbvUY7uoNx5vEfwGOWWlFDGRLmURFfAYhffzFhdNR4xFNNBawU2bEtM1ZomG/ HkQtrLfXxDNLndKgHwFQf+GuzueMmmf9kwcvevn322koH3JF5oWs0v48cdIV5FT0BT/h yZZAlDBITCFACqA343MjpDLp8NWIwQIYqex4JJnwgND96TtwH0uvxT12VTGwEFG28r3w p8sQ== MIME-Version: 1.0 X-Received: by 10.182.46.232 with SMTP id y8mr6103842obm.13.1377067219411; Tue, 20 Aug 2013 23:40:19 -0700 (PDT) Received: by 10.76.168.39 with HTTP; Tue, 20 Aug 2013 23:40:19 -0700 (PDT) In-Reply-To: <4201D9DD-6751-4466-9A62-D9131B10C936@sniff.de> References: <4201D9DD-6751-4466-9A62-D9131B10C936@sniff.de> Date: Wed, 21 Aug 2013 12:10:19 +0530 Message-ID: Subject: Re: few queries regarding BFD From: Lokesh B To: Marc Binderberger Content-Type: multipart/alternative; boundary=047d7bfe97e071ec1c04e46f72fd Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 06:40:20 -0000 --047d7bfe97e071ec1c04e46f72fd Content-Type: text/plain; charset=ISO-8859-1 Thanks Marc, I'm just picking this old thread because my question is in this context, could you please let me know names of vendors and products of these "8k-16k BFD sessions per linecard" systems? I'm interested in software/hardware specifications of such high end systems. Is it cisco? I googled but could not find any. Regards -Lokesh On Fri, May 17, 2013 at 1:11 PM, Marc Binderberger wrote: > Hello Lokesh, > > I know about systems that support 8k - 16k BFD sessions per linecard and > "no limit" per system. For software-based I/O we talk about intervals of > several hundreds of milliseconds then, hardware-based I/O can deliver much > faster though. > > I use quotation marks as it mainly means no hard limits in the code; in > reality one may find certain code/data structures like SNMP work fine for a > few thousands but not for hundreds of thousands of sessions - and need > optimization. > > > Regards, Marc > > > > > On 2013-05-17, at 6:30 , Lokesh NB wrote: > > Thanks Marc for the answers, > > >> 2. what is the currently supported maximum number of BFD sessions in > high end routers? is it in the orders of hundreds of thousands? > > >Thousands. Details may depend on the timer values when the implementation > is software based, still >system-wide I stick to "thousands". > > do you have any information about what is the highest number of BFD > sessions supported by high end routers? I mean how many thousands of > sessions do they support? I searched online but could not find the info. > > Regards > -Lokesh > > > > > On Fri, May 3, 2013 at 3:30 PM, Marc Binderberger wrote: > >> Hello Lokesh, >> >> some questions are quite generic but nevertheless ... >> >> >> > 1. How to arrive at maximum number of BFD sessions to be supported in a >> high end router.? >> >> distributed architecture and/or using ASIC/FPGA/NP to offload the packet >> Tx/Rx >> >> >> > 2. what is the currently supported maximum number of BFD sessions in >> high end routers? is it in the orders of hundreds of thousands? >> >> Thousands. Details may depend on the timer values when the implementation >> is software based, still system-wide I stick to "thousands". >> >> >> > 3. What is the minimum Tx time to be supported for layer 3 UDP encap >> peers? I know cisco supports minimum 50 msec but can we expect requirement >> for IP peers to be monitored below that 50 msecs? like 10,20 msec? >> >> Actually this particular vendor you mention supports 15msec for high-end >> equipment today. With a multiplier of 2 that makes a detection time of >> 30msec maximum, so depending on the fiber length in a network that could >> make the 50-60msec time for detection & restoration. >> >> Obviously: the faster the timer the better :-) , for MPLS-TP OAM the >> usual number you hear is 3.3msec (so 10msec detection time with a >> multiplier of 3). >> >> >> > 4. What is average Tx time usually IP peers settle for in general? is >> it like 100-300 msec? In other words what is usually configured Tx time for >> IP peers? >> >> there is no single number, too many network designs out there in real >> life. In the core customers typically go fast, to the endpoints some >> customers go slower, just to stay below 1sec detection time so VoIP >> controller don't freak out. >> >> >> Regards, Marc >> >> >> >> > 5. What is the expected percentage of BFD traffic of the total >> bandwidth of the device? I know it depends on how many sessions are active >> in parallel and Tx/Rx timers but in general is it correct to estimate that >> BFD traffic generally should not exceed 2 to 5 % of the total bandwidth >> available for user data? >> > >> > 6. How frequently Auth is used in general deployments? is it only used >> for multi hop peers usually? >> > >> > Regards >> > -Lokesh >> > >> > >> > >> > >> > >> > >> >> >> > > > --047d7bfe97e071ec1c04e46f72fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Marc,
I'm just picking = this old thread because my question is in this context,
could you please= let me know names of vendors and products of these "8k-16k BFD sessio= ns per linecard" systems? I'm interested in software/hardware spec= ifications of such high end systems.
Is it cisco? I googled but could not find any.

Regards
-Lokesh


On Fri, May 17, 2013 at 1:11 PM, Marc Binde= rberger <marc@sniff.de> wrote:
Hello Lo= kesh,

I know about systems that support 8k - 16k BFD ses= sions per linecard and "no limit" per system. For software-based = I/O we talk about intervals of several hundreds of milliseconds then, hardw= are-based I/O can deliver much faster though.

I use quotation marks as it mainly means no hard limits= in the code; in reality one may find certain code/data structures like SNM= P work fine for a few thousands but not for hundreds of thousands of sessio= ns - and need optimization.


Regards, Marc

<= br>


On 2013-05-17, at 6:30 , Lokesh = NB wrote:

Thanks Marc for the answers,

>> 2. what is the currently suppo= rted maximum number of BFD sessions=20 in high end routers? is it in the orders of hundreds of thousands?

>Thousands. Details may depend on the timer values when the=20 implementation is software based, still >system-wide I stick to=20 "thousands".

do you have any information about what = is the highest number of BFD sessions supported by high end routers? I mean= how many thousands of sessions do they support? I searched online but coul= d not find the info.

Regards
-Lokesh




On Fri, May 3, 2013 at 3:30 PM, Marc Binderberger <marc@sniff.de&g= t; wrote:
Hello Lokesh,

some questions are quite generic but nevertheless ...


> 1. How to arrive at maximum number of BFD sessions to be supported in = a high end router.?

distributed architecture and/or using ASIC/FPGA/NP to offload the packet Tx= /Rx


> 2. what is the currently supported maximum number of BFD sessions in h= igh end routers? is it in the orders of hundreds of thousands?

Thousands. Details may depend on the timer values when the implementation i= s software based, still system-wide I stick to "thousands".


> 3. What is the minimum Tx time to be supported for layer 3 UDP encap p= eers? I know cisco supports minimum 50 msec but can we expect requirement f= or IP peers to be monitored below that 50 msecs? like 10,20 msec?

Actually this particular vendor you mention supports 15msec for high-end eq= uipment today. With a multiplier of 2 that makes a detection time of 30msec= maximum, so depending on the fiber length in a network that could make the= 50-60msec time for detection & restoration.

Obviously: the faster the timer the better :-) , for MPLS-TP OAM the usual = number you hear is 3.3msec (so 10msec detection time with a multiplier of 3= ).


> 4. What is average Tx time usually IP peers settle for in general? is = it like 100-300 msec? In other words what is usually configured Tx time for= IP peers?

there is no single number, too many network designs out there in real life.= In the core customers typically go fast, to the endpoints some customers g= o slower, just to stay below 1sec detection time so VoIP controller don'= ;t freak out.


Regards, Marc



> 5. What is the expected percentage of BFD traffic of the total bandwid= th of the device? I know it depends on how many sessions are active in para= llel and Tx/Rx timers but in general is it correct to estimate that BFD tra= ffic generally should not exceed 2 to 5 % of the total bandwidth available = for user data?
>
> 6. How frequently Auth is used in general deployments? is it only used= for multi hop peers usually?
>
> Regards
> -Lokesh
>
>
>
>
>
>






--047d7bfe97e071ec1c04e46f72fd-- From lokeshnb1@gmail.com Wed Aug 21 00:21:47 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78C511E836D for ; Wed, 21 Aug 2013 00:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eftVQ1WcLXBO for ; Wed, 21 Aug 2013 00:21:47 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5027711E81C0 for ; Wed, 21 Aug 2013 00:21:47 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m6so108367oag.4 for ; Wed, 21 Aug 2013 00:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bIviK4MD8FDOIX7Nw6hca+rHNxLUQMtUCofTvqjeADM=; b=1E4yux8GQH52LcaKLckZERoD7KUw1BKDFTiVl3zfh9ZK+FDQF0cjSj4WSKQX2beaUL M1HEKfi1VEAhagf0Yku/rRf7PKEvUPyNiLYpNyWRGqNVxvZ/0wRAyEn/cyHtvLlsVUCS UauilXOoBb8OaGaj9ykEZqyUj5apouz1n51iEcLwcF+ANimeiEo/UNtRDIv+I/6watYd PxmU9P3ZPfLrqxfygJLWgkswSUXgXEbFs4VA5wY67KIRRP5s843C+xCSqi7iEu6xDYfz p4bPNlpHgPcOuF9zIVq0K5cIUsWfn0tIDKYUqvpLwuW8Bpq8lR0ShDZnCpRm+XXKcM7Q s54A== MIME-Version: 1.0 X-Received: by 10.60.44.9 with SMTP id a9mr6288364oem.67.1377069705810; Wed, 21 Aug 2013 00:21:45 -0700 (PDT) Received: by 10.76.168.39 with HTTP; Wed, 21 Aug 2013 00:21:45 -0700 (PDT) Date: Wed, 21 Aug 2013 12:51:45 +0530 Message-ID: Subject: understanding Echo mode From: Lokesh B To: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2e73ea5593304e470060f X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 07:21:48 -0000 --001a11c2e73ea5593304e470060f Content-Type: text/plain; charset=ISO-8859-1 Hi, Following is my understanding on why echo mode is required. Because RFC 5880 does not mandate route lookup for control packets in asynchronous mode, there can be implementations that just build BFD packet and transmit directly on connected network interfaces without doing route lookup for peer device. Hence echo mode is provided to test real routing by mandating that control packet should be transmitted to peer by looping it via forwarding plane that tests existence of route to peer machine. Is it correct? or is there any other requirement that is kept in mind while proposing echo mode. Regards -Lokesh --001a11c2e73ea5593304e470060f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Following is my under= standing on why echo mode is required.

Because RFC 5880 does = not mandate route lookup for control packets in asynchronous mode, there ca= n be implementations that just build BFD packet and transmit directly on co= nnected network interfaces without doing route lookup for peer device. Henc= e echo mode is provided to test real routing by mandating that control pack= et should be transmitted to peer by looping it via forwarding plane that te= sts existence of route to peer machine.

Is it correct? or is there any other requirement that is kept in = mind while proposing echo mode.


Regards
-Lokesh
--001a11c2e73ea5593304e470060f-- From marc@sniff.de Wed Aug 21 00:51:30 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC1611E837E for ; Wed, 21 Aug 2013 00:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dof7PNYHVtSO for ; Wed, 21 Aug 2013 00:51:30 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8358E11E81E9 for ; Wed, 21 Aug 2013 00:51:29 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4B6602AA0F; Wed, 21 Aug 2013 07:51:25 +0000 (GMT) Date: Wed, 21 Aug 2013 09:50:47 +0200 From: Marc Binderberger To: Lokesh B Message-ID: <20130821095047187695.66a4e721@sniff.de> In-Reply-To: References: Subject: Re: understanding Echo mode MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 07:51:30 -0000 Hello Lokesh, > by mandating that control packet should be > transmitted to peer by looping it via forwarding plane that tests > existence of route to peer machine. No, echo is not about control packets (in the sense of BFD control packets). And there is, similar to control packets, no requirement how router A originates the echo packet to router B (the peer). This can be again a transmission directly on the wire. There are many motivations for echo. The echo packet traverses the "full" hardware path on the peer, it does a "routing lookup" on the peer - the exact meaning is implementation specific - and it allows to put the burden of fast detection on the router that requires it (and not the peer), in case of asymmetric detection times. And a few more things. Regards, Marc On Wed, 21 Aug 2013 12:51:45 +0530, Lokesh B wrote: > Hi, > > Following is my understanding on why echo mode is required. > > Because RFC 5880 does not mandate route lookup for control packets in > asynchronous mode, there can be implementations that just build BFD > packet and transmit directly on connected network interfaces without > doing route lookup for peer device. Hence echo mode is provided to > test real routing by mandating that control packet should be > transmitted to peer by looping it via forwarding plane that tests > existence of route to peer machine. > > Is it correct? or is there any other requirement that is kept in mind > while proposing echo mode. > > > Regards > -Lokesh From jeff.tantsura@ericsson.com Wed Aug 21 07:26:57 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B603F11E80F1 for ; Wed, 21 Aug 2013 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f7l0WV3VOq8 for ; Wed, 21 Aug 2013 07:26:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2671E11E83A6 for ; Wed, 21 Aug 2013 07:26:47 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-28-5214ce20c87c Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 96.85.03458.02EC4125; Wed, 21 Aug 2013 16:26:41 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Wed, 21 Aug 2013 10:26:40 -0400 From: Jeff Tantsura To: Lokesh B , Marc Binderberger Subject: Re: few queries regarding BFD Thread-Topic: few queries regarding BFD Thread-Index: AQHOR9QLGDv/vY1K00KhfdxzQ2urD5jzfX+AgBWkYwCAADVXAICWzseAgAAM7wA= Date: Wed, 21 Aug 2013 14:26:39 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748398F80BE@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C748398F80BEeusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXSPn67iOZEgg4t3eCxWLZvDZjH7yn9m i89/tjE6MHvsnHWX3WPJkp9MHq2ru1kCmKO4bFJSczLLUov07RK4Ms6eWMNasCy2Yu4s/gbG Zz5djJwcEgImEvM2tbBB2GISF+6tB7K5OIQEjjJKTO6fDZYQEljOKPH4kDyIzSZgIPH/23EW EFtEwFVi+tKNTCA2s4CmRNOJz+xdjBwcwgJqEncv+YOYIgLqElvXmEFU+0n8OLCIGcRmEVCV mNn4D2wKr4C3xN1lF8BsToFAibevzoBNZAQ65/upNVDTxSVuPZnPBHGmgMSSPeeZIWxRiZeP /7GC2KICehJtx86wQ8SVJb7PecQC0Zsv8afvMyPELkGJkzOfsExgFJ2FZOwsJGWzkJRBxHUk Fuz+xAZha0ssW/iaGcY+c+AxVK+1xJW7ExiR1Sxg5FjFyFFanFqWm25kuIkRGHvHJNgcdzAu +GR5iFGag0VJnHeD3plAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwpO1bdXrfVMGfG7neh cbyXhetKPseLFM/KWPt56gWDoxw7VveonedYKNls1qd39Ut0KpPdpK5T9dv27j5dnl+59+M9 QVEn9nkCftw1QXwhHrkbjqzQPHv/BtNMs9ezHpyJzPu8pamhZL9o+/TVfG1r+5YH1Z+Z8085 +OujHf7sd1b2X9sUOOu4EktxRqKhFnNRcSIAU+wYj4sCAAA= Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 14:26:57 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C748398F80BEeusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lokesh, Any modern high end NP, depending on timers used could do 2-4K BFD sessions= . Cheers, Jeff From: Lokesh B > Date: Tuesday, August 20, 2013 11:40 PM To: Marc Binderberger > Cc: "rtg-bfd@ietf.org" > Subject: Re: few queries regarding BFD Thanks Marc, I'm just picking this old thread because my question is in this context, could you please let me know names of vendors and products of these "8k-16k= BFD sessions per linecard" systems? I'm interested in software/hardware sp= ecifications of such high end systems. Is it cisco? I googled but could not find any. Regards -Lokesh On Fri, May 17, 2013 at 1:11 PM, Marc Binderberger > wrote: Hello Lokesh, I know about systems that support 8k - 16k BFD sessions per linecard and "n= o limit" per system. For software-based I/O we talk about intervals of seve= ral hundreds of milliseconds then, hardware-based I/O can deliver much fast= er though. I use quotation marks as it mainly means no hard limits in the code; in rea= lity one may find certain code/data structures like SNMP work fine for a fe= w thousands but not for hundreds of thousands of sessions - and need optimi= zation. Regards, Marc On 2013-05-17, at 6:30 , Lokesh NB wrote: Thanks Marc for the answers, >> 2. what is the currently supported maximum number of BFD sessions in hig= h end routers? is it in the orders of hundreds of thousands? >Thousands. Details may depend on the timer values when the implementation = is software based, still >system-wide I stick to "thousands". do you have any information about what is the highest number of BFD session= s supported by high end routers? I mean how many thousands of sessions do t= hey support? I searched online but could not find the info. Regards -Lokesh On Fri, May 3, 2013 at 3:30 PM, Marc Binderberger > wrote: Hello Lokesh, some questions are quite generic but nevertheless ... > 1. How to arrive at maximum number of BFD sessions to be supported in a h= igh end router.? distributed architecture and/or using ASIC/FPGA/NP to offload the packet Tx= /Rx > 2. what is the currently supported maximum number of BFD sessions in high= end routers? is it in the orders of hundreds of thousands? Thousands. Details may depend on the timer values when the implementation i= s software based, still system-wide I stick to "thousands". > 3. What is the minimum Tx time to be supported for layer 3 UDP encap peer= s? I know cisco supports minimum 50 msec but can we expect requirement for = IP peers to be monitored below that 50 msecs? like 10,20 msec? Actually this particular vendor you mention supports 15msec for high-end eq= uipment today. With a multiplier of 2 that makes a detection time of 30msec= maximum, so depending on the fiber length in a network that could make the= 50-60msec time for detection & restoration. Obviously: the faster the timer the better :-) , for MPLS-TP OAM the usual = number you hear is 3.3msec (so 10msec detection time with a multiplier of 3= ). > 4. What is average Tx time usually IP peers settle for in general? is it = like 100-300 msec? In other words what is usually configured Tx time for IP= peers? there is no single number, too many network designs out there in real life.= In the core customers typically go fast, to the endpoints some customers g= o slower, just to stay below 1sec detection time so VoIP controller don't f= reak out. Regards, Marc > 5. What is the expected percentage of BFD traffic of the total bandwidth = of the device? I know it depends on how many sessions are active in paralle= l and Tx/Rx timers but in general is it correct to estimate that BFD traffi= c generally should not exceed 2 to 5 % of the total bandwidth available for= user data? > > 6. How frequently Auth is used in general deployments? is it only used fo= r multi hop peers usually? > > Regards > -Lokesh > > > > > > --_000_60DEDD93F5E54B4AB55647B8B6C748398F80BEeusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Lokesh,

Any modern high end NP, depending on timers used could do 2-4K BFD ses= sions.


Cheers,
Jeff

From: Lokesh B <lokeshnb1@gmail.com>
Date: Tuesday, August 20, 2013 11:4= 0 PM
To: Marc Binderberger <marc@sniff.de>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: few queries regarding = BFD

Thanks Marc,
I'm just picking this old thread because my question is in this context, could you please let me know names of vendors and products of these "8= k-16k BFD sessions per linecard" systems? I'm interested in software/h= ardware specifications of such high end systems.
Is it cisco? I googled but could not find any.

Regards
-Lokesh



On Fri, May 17, 2013 at 1:11 PM, Marc Binderberg= er <marc@sniff.de>= ; wrote:
Hello Lokesh,

I know about systems that support 8k - 16k BFD sessions per linecard a= nd "no limit" per system. For software-based I/O we talk about in= tervals of several hundreds of milliseconds then, hardware-based I/O can de= liver much faster though.

I use quotation marks as it mainly means no hard limits in the code; i= n reality one may find certain code/data structures like SNMP work fine for= a few thousands but not for hundreds of thousands of sessions - and need o= ptimization.


Regards, Marc




On 2013-05-17, at 6:30 , Lokesh NB wrote:

Thanks Marc for the answers,

>> 2. what is the currently supported maximum number of BFD sessions = in high end routers? is it in the orders of hundreds of thousands?

>Thousands. Details may depend on the timer values when the implementati= on is software based, still >system-wide I stick to "thousands"= ;.

do you have any information about what is the highest number of BFD session= s supported by high end routers? I mean how many thousands of sessions do t= hey support? I searched online but could not find the info.

Regards
-Lokesh




On Fri, May 3, 2013 at 3:30 PM, Marc Binderberge= r <marc@sniff.de>= ; wrote:
Hello Lokesh,

some questions are quite generic but nevertheless ...


> 1. How to arrive at maximum number of BFD sessions to be supported in = a high end router.?

distributed architecture and/or using ASIC/FPGA/NP to offload the packet Tx= /Rx


> 2. what is the currently supported maximum number of BFD sessions in h= igh end routers? is it in the orders of hundreds of thousands?

Thousands. Details may depend on the timer values when the implementation i= s software based, still system-wide I stick to "thousands".


> 3. What is the minimum Tx time to be supported for layer 3 UDP encap p= eers? I know cisco supports minimum 50 msec but can we expect requirement f= or IP peers to be monitored below that 50 msecs? like 10,20 msec?

Actually this particular vendor you mention supports 15msec for high-end eq= uipment today. With a multiplier of 2 that makes a detection time of 30msec= maximum, so depending on the fiber length in a network that could make the= 50-60msec time for detection & restoration.

Obviously: the faster the timer the better :-) , for MPLS-TP OAM the usual = number you hear is 3.3msec (so 10msec detection time with a multiplier of 3= ).


> 4. What is average Tx time usually IP peers settle for in general? is = it like 100-300 msec? In other words what is usually configured Tx time for= IP peers?

there is no single number, too many network designs out there in real life.= In the core customers typically go fast, to the endpoints some customers g= o slower, just to stay below 1sec detection time so VoIP controller don't f= reak out.


Regards, Marc



> 5. What is the expected percentage of BFD traffic of the total bandwid= th of the device? I know it depends on how many sessions are active in para= llel and Tx/Rx timers but in general is it correct to estimate that BFD tra= ffic generally should not exceed 2 to 5 % of the total bandwidth available for user data?
>
> 6. How frequently Auth is used in general deployments? is it only used= for multi hop peers usually?
>
> Regards
> -Lokesh
>
>
>
>
>
>






 --_000_60DEDD93F5E54B4AB55647B8B6C748398F80BEeusaamb109ericsso_-- From nobo@cisco.com Wed Aug 21 08:21:32 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A2A21F9C00 for ; Wed, 21 Aug 2013 08:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrGue77omOpD for ; Wed, 21 Aug 2013 08:21:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16611E8112 for ; Wed, 21 Aug 2013 08:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3626; q=dns/txt; s=iport; t=1377098485; x=1378308085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ktvtAXhSTaMqn6/8tUQgNnLPbSkbU0BGF3WMY+3cYKU=; b=H8FMJLcI/FRrgQKAUw6bf8PPqLBiqTtggfr0UhxTZbW79yVcDZ1fWRzL sxLO7I73q2tS8bUAUYdA4Qh7erD3EF6ZoJIRYncl7JPhMv4nhcRnHPXNW Gozp6jU9bO8uxAiku79rM3oBc4pb1xTDzWWN2suezES1X4eMUBFpKdz4G o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisGALvZFFKtJV2Z/2dsb2JhbABagmQhNUsGgxq8QReBCBZtB4IkAQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQOBQgBiAcBBgWibYpsgSmOexYbBwaCYjN5A5kSkCmDHIIq X-IronPort-AV: E=Sophos;i="4.89,928,1367971200"; d="scan'208";a="250033545" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 21 Aug 2013 15:21:20 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7LFLKvM011582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Aug 2013 15:21:20 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 10:21:20 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Topic: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Index: AQHOnn5l/+pr3RmCiUeQmy2G0jO595mfwJTg Date: Wed, 21 Aug 2013 15:21:19 +0000 Message-ID: References: <20130821145447.28106.64314.idtracker@ietfa.amsl.com> In-Reply-To: <20130821145447.28106.64314.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "David Ward \(wardd\)" , "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 15:21:33 -0000 DQpIZWxsbyBCRkQgV0cgTWVtYmVycywNCg0KV2UgaGF2ZSBwdWJsaXNoZWQgUy1CRkQgQmFzZSAt MDEuDQoNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDEudHh0DQpTdGF0dXM6ICAgICAgICAg IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNz LWJhc2UNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDENCg0K V2UgaGF2ZSByZXdvcmRlZCBzZXZlcmFsIHNlY3Rpb25zIHRvIGltcHJvdmUgdGhlIHJlYWRhYmls aXR5IGFzcGVjdC4NClRoZXJlIGFyZSBmZXcgdGVjaG5pY2FsIGNoYW5nZXMgYXMgd2VsbC4gSWYg eW91IGhhdmUgcmVhZCAtMDEsIHBsZWFzZSB2aXNpdCB0aGUgZGlmZiBsaW5rIHRvIHNlZSB3aGF0 IGhhcyBjaGFuZ2VkLg0KDQpBdXRob3JzIGFyZSBsb29raW5nIGludG8gdmFyaW91cyBhc3BlY3Rz IG9mIFMtQkZEIG5leHQuIENhcmxvcyBhbmQgbXlzZWxmIHdpbGwgYmUgbG9va2luZyBpbnRvIGZ1 cnRoZXIgZGVmaW5pbmcgU2VnbWVudCBSb3V0aW5nIHNjZW5hcmlvcyAoUy1CRkQgU1IgZHJhZnQp IGFuZCB3aWxsIGJlIHNlZWtpbmcgc29tZSBoZWxwIHRvIG9uIHRoYXQgZnJvbnQuIEFuZCBwcm9n cmVzcyBvZiB0aGF0IHJlcXVpcmVzIHRoZSAiYmFzZSIgdG8gYmUgc29saWRpZmllZCwgYW5kIHdl IGFyZSBuZWVkIHlvdXIgaGVscC4gUGxlYXNlIHBvaW50IG91dCBhbnl0aGluZyB0aGF0IGlzIHVu Y2xlYXIsIGNvbmZ1c2luZyBhbmQvb3IgcXVlc3Rpb25hYmxlLg0KDQpSZWdhcmRzLA0KQXV0aG9y cw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMjEsIDIwMTMgMTA6NTUgQU0NCj4gVG86IERhdmlkIFdhcmQgKHdhcmRk KTsgTWFuYXYgQmhhdGlhOyBEYXZpZCBXYXJkICh3YXJkZCk7IENhcmxvcw0KPiBQaWduYXRhcm8g KGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibykNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFzZS0wMS50eHQNCj4gDQo+ IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2Ut MDEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTm9ibyBBa2l5YSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJIGRy YWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlDQo+IFJldmlzaW9uOgkgMDENCj4gVGl0bGU6CQkg U2VhbWxlc3MgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSB3aXRoDQo+ IE1QTFMgTGFiZWwgVmVyaWZpY2F0aW9uIEV4dGVuc2lvbg0KPiBDcmVhdGlvbiBkYXRlOgkgMjAx My0wOC0yMQ0KPiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBh Z2VzOiAyMA0KPiBVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy0NCj4gYmFzZS0wMS50eHQNCj4gU3RhdHVz OiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLWJm ZC1zZWFtbGVzcy1iYXNlDQo+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDENCj4gRGlmZjogICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ha2l5YS1iZmQtc2VhbWxl c3MtYmFzZS0NCj4gMDENCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgYSBzaW1wbGlmaWVkIG1lY2hhbmlzbSB0byB1c2UgQmlkaXJlY3Rpb25hbA0KPiAgICBGb3J3 YXJkaW5nIERldGVjdGlvbiAoQkZEKSB3aXRoIGxhcmdlIHBvcnRpb25zIG9mIG5lZ290aWF0aW9u IGFzcGVjdHMNCj4gICAgZWxpbWluYXRlZCwgdGhhdCBhbGxvd3MgZnVsbCBhbmQgcGFydGlhbCBy ZWFjaGFiaWxpdHkgdmVyaWZpY2F0aW9uLg0KPiAgICBGb3IgTVBMUyBiYXNlZCBCRkQsIGV4dGVu c2lvbnMgdG8gdGhlIGdlbmVyaWMgbWVjaGFuaXNtIGFyZSBkZWZpbmVkDQo+ICAgIHRoYXQgYWxs b3dzIEJGRCB0byBwZXJmb3JtIGEgbGV2ZWwgb2YgbGFiZWwgdmVyaWZpY2F0aW9uLg0KPiANCj4g DQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobo@cisco.com Wed Aug 21 08:32:48 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7590E11E80E3 for ; Wed, 21 Aug 2013 08:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th+bQ2PGzdDf for ; Wed, 21 Aug 2013 08:32:43 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDE121F8C72 for ; Wed, 21 Aug 2013 08:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4394; q=dns/txt; s=iport; t=1377099163; x=1378308763; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ewzC93qzKJG0eF4UUU/M4qgl4DES3HdMpe4cK8Z0+9g=; b=ErSfAM5eoDrDw0APUhb1CPsm/YNNU95fOZkVMb9o3dteA2CMopkne9QR xWIsyZw7/arAhxjpvMwF7UAtTXcw1xACdIbQR7RPCYGK2/6XEHGwDWD6C hc+edTva1YsD7j4DK+sB0kNcfIiFMqghOiibAvBdSQIGdZJyeWOrLGrPp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisGAF7cFFKtJXHB/2dsb2JhbABagmQhNUsGgxq8QReBCBZtB4IkAQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQOBQgBiAcBBgWiZYprgSmNY4EYFhsHBoJiM3kDmRKQKYMcgXE5 X-IronPort-AV: E=Sophos;i="4.89,928,1367971200"; d="scan'208";a="250008613" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 21 Aug 2013 15:32:42 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7LFWfNP027066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Aug 2013 15:32:41 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.02.0318.004; Wed, 21 Aug 2013 10:32:41 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Topic: New Version Notification for draft-akiya-bfd-seamless-base-01.txt Thread-Index: AQHOnn5l/+pr3RmCiUeQmy2G0jO595mfwJTggAAJNLA= Date: Wed, 21 Aug 2013 15:32:41 +0000 Message-ID: References: <20130821145447.28106.64314.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "David Ward \(wardd\)" , "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 15:32:48 -0000 KyBNYW5hdiwgc29tZW9uZSBtYWlsZXIgc3RyaXBwZWQgb2ZmIE1hbmF2J3MgZW1haWwgZnJvbSBw cmlvciBlbWFpbC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGct YmZkLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9u DQo+IEJlaGFsZiBPZiBOb2JvIEFraXlhIChub2JvKQ0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3Vz dCAyMSwgMjAxMyAxMToyMSBBTQ0KPiBUbzogcnRnLWJmZEBpZXRmLm9yZw0KPiBDYzogRGF2aWQg V2FyZCAod2FyZGQpOyBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCj4gU3ViamVjdDogUkU6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJh c2UtDQo+IDAxLnR4dA0KPiANCj4gDQo+IEhlbGxvIEJGRCBXRyBNZW1iZXJzLA0KPiANCj4gV2Ug aGF2ZSBwdWJsaXNoZWQgUy1CRkQgQmFzZSAtMDEuDQo+IA0KPiBVUkw6ICAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVz cy0NCj4gYmFzZS0wMS50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlDQo+IEh0bWxpemVkOiAg ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNz LWJhc2UtMDENCj4gRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFzZS0NCj4gMDENCj4gDQo+IFdlIGhhdmUg cmV3b3JkZWQgc2V2ZXJhbCBzZWN0aW9ucyB0byBpbXByb3ZlIHRoZSByZWFkYWJpbGl0eSBhc3Bl Y3QuDQo+IFRoZXJlIGFyZSBmZXcgdGVjaG5pY2FsIGNoYW5nZXMgYXMgd2VsbC4gSWYgeW91IGhh dmUgcmVhZCAtMDEsIHBsZWFzZSB2aXNpdA0KPiB0aGUgZGlmZiBsaW5rIHRvIHNlZSB3aGF0IGhh cyBjaGFuZ2VkLg0KPiANCj4gQXV0aG9ycyBhcmUgbG9va2luZyBpbnRvIHZhcmlvdXMgYXNwZWN0 cyBvZiBTLUJGRCBuZXh0LiBDYXJsb3MgYW5kIG15c2VsZg0KPiB3aWxsIGJlIGxvb2tpbmcgaW50 byBmdXJ0aGVyIGRlZmluaW5nIFNlZ21lbnQgUm91dGluZyBzY2VuYXJpb3MgKFMtQkZEIFNSDQo+ IGRyYWZ0KSBhbmQgd2lsbCBiZSBzZWVraW5nIHNvbWUgaGVscCB0byBvbiB0aGF0IGZyb250LiBB bmQgcHJvZ3Jlc3Mgb2YgdGhhdA0KPiByZXF1aXJlcyB0aGUgImJhc2UiIHRvIGJlIHNvbGlkaWZp ZWQsIGFuZCB3ZSBhcmUgbmVlZCB5b3VyIGhlbHAuIFBsZWFzZQ0KPiBwb2ludCBvdXQgYW55dGhp bmcgdGhhdCBpcyB1bmNsZWFyLCBjb25mdXNpbmcgYW5kL29yIHF1ZXN0aW9uYWJsZS4NCj4gDQo+ IFJlZ2FyZHMsDQo+IEF1dGhvcnMNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddDQo+ID4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjEsIDIwMTMgMTA6NTUg QU0NCj4gPiBUbzogRGF2aWQgV2FyZCAod2FyZGQpOyBNYW5hdiBCaGF0aWE7IERhdmlkIFdhcmQg KHdhcmRkKTsgQ2FybG9zDQo+ID4gUGlnbmF0YXJvIChjcGlnbmF0YSk7IE5vYm8gQWtpeWEgKG5v Ym8pDQo+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0 LWFraXlhLWJmZC1zZWFtbGVzcy1iYXNlLTAxLnR4dA0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDEudHh0DQo+ID4gaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOb2JvIEFraXlhIGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYNCj4gPiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gRmlsZW5hbWU6CSBkcmFmdC1ha2l5 YS1iZmQtc2VhbWxlc3MtYmFzZQ0KPiA+IFJldmlzaW9uOgkgMDENCj4gPiBUaXRsZToJCSBTZWFt bGVzcyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIHdpdGgNCj4gPiBN UExTIExhYmVsIFZlcmlmaWNhdGlvbiBFeHRlbnNpb24NCj4gPiBDcmVhdGlvbiBkYXRlOgkgMjAx My0wOC0yMQ0KPiA+IEdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IE51bWJlciBv ZiBwYWdlczogMjANCj4gPiBVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy0NCj4gPiBiYXNlLTAxLnR4dA0K PiA+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFzZQ0KPiA+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UtMDENCj4gPiBE aWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFr aXlhLWJmZC1zZWFtbGVzcy0NCj4gYmFzZS0NCj4gPiAwMQ0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ ID4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2ltcGxpZmllZCBtZWNoYW5pc20gdG8gdXNl IEJpZGlyZWN0aW9uYWwNCj4gPiAgICBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSB3aXRoIGxh cmdlIHBvcnRpb25zIG9mIG5lZ290aWF0aW9uIGFzcGVjdHMNCj4gPiAgICBlbGltaW5hdGVkLCB0 aGF0IGFsbG93cyBmdWxsIGFuZCBwYXJ0aWFsIHJlYWNoYWJpbGl0eSB2ZXJpZmljYXRpb24uDQo+ ID4gICAgRm9yIE1QTFMgYmFzZWQgQkZELCBleHRlbnNpb25zIHRvIHRoZSBnZW5lcmljIG1lY2hh bmlzbSBhcmUgZGVmaW5lZA0KPiA+ICAgIHRoYXQgYWxsb3dzIEJGRCB0byBwZXJmb3JtIGEgbGV2 ZWwgb2YgbGFiZWwgdmVyaWZpY2F0aW9uLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+IFRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg== From dkatz@juniper.net Wed Aug 21 11:59:51 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398D021F9EF0 for ; Wed, 21 Aug 2013 11:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+KIokj+P5lF for ; Wed, 21 Aug 2013 11:59:45 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0C66D21F9EED for ; Wed, 21 Aug 2013 11:59:43 -0700 (PDT) Received: from mail184-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Aug 2013 18:59:39 +0000 Received: from mail184-va3 (localhost [127.0.0.1]) by mail184-va3-R.bigfish.com (Postfix) with ESMTP id AA91DE0171; Wed, 21 Aug 2013 18:59:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h1155h) Received-SPF: pass (mail184-va3: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=dkatz@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail184-va3 (localhost.localdomain [127.0.0.1]) by mail184-va3 (MessageSwitch) id 1377111578291471_7226; Wed, 21 Aug 2013 18:59:38 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.238]) by mail184-va3.bigfish.com (Postfix) with ESMTP id 41D6A60047; Wed, 21 Aug 2013 18:59:38 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.52) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 21 Aug 2013 18:59:38 +0000 Received: from sa-nc-it-180.static.jnpr.net (172.23.3.180) by smtp.juniper.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 21 Aug 2013 11:59:37 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: understanding Echo mode From: Dave Katz In-Reply-To: <20130821095047187695.66a4e721@sniff.de> Date: Wed, 21 Aug 2013 11:59:36 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <348B462A-1991-49B3-B0F0-0E422E3CE3E6@juniper.net> References: <20130821095047187695.66a4e721@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1508) X-Originating-IP: [172.23.3.180] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2013 18:59:51 -0000 Yep. And among the "more things" are the ability to do proprietary = things in the echo protocol (since it is a private matter to the = originating machine) and less work for the receiving end (perhaps handy = when the receiving machine has a large fan-in). --Dave On Aug 21, 2013, at 12:50 AM, Marc Binderberger wrote: > Hello Lokesh, >=20 >> by mandating that control packet should be=20 >> transmitted to peer by looping it via forwarding plane that tests=20 >> existence of route to peer machine. >=20 > No, echo is not about control packets (in the sense of BFD control=20 > packets). And there is, similar to control packets, no requirement how=20= > router A originates the echo packet to router B (the peer). This can = be=20 > again a transmission directly on the wire. >=20 >=20 > There are many motivations for echo. The echo packet traverses the=20 > "full" hardware path on the peer, it does a "routing lookup" on the=20 > peer - the exact meaning is implementation specific - and it allows to=20= > put the burden of fast detection on the router that requires it (and=20= > not the peer), in case of asymmetric detection times. And a few more=20= > things. >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 >=20 >=20 > On Wed, 21 Aug 2013 12:51:45 +0530, Lokesh B wrote: >> Hi, >>=20 >> Following is my understanding on why echo mode is required.=20 >>=20 >> Because RFC 5880 does not mandate route lookup for control packets in=20= >> asynchronous mode, there can be implementations that just build BFD=20= >> packet and transmit directly on connected network interfaces without=20= >> doing route lookup for peer device. Hence echo mode is provided to=20 >> test real routing by mandating that control packet should be=20 >> transmitted to peer by looping it via forwarding plane that tests=20 >> existence of route to peer machine. >>=20 >> Is it correct? or is there any other requirement that is kept in mind=20= >> while proposing echo mode. >>=20 >>=20 >> Regards >> -Lokesh >=20 >=20 From sekraj@gmail.com Wed Aug 28 03:25:33 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08C11E817B for ; Wed, 28 Aug 2013 03:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAbrFMChddVP for ; Wed, 28 Aug 2013 03:25:31 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A695611E816F for ; Wed, 28 Aug 2013 03:25:31 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id x14so7968086ief.25 for ; Wed, 28 Aug 2013 03:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lNMAxULb+BnUSwTAjhM36yBlQmVBHkqYRMb9uEzarI4=; b=sf6ecyCeCLViS9+LQexUk3k24JiW4XsZIfsce/DJ7h33Tz4SSPh4mk5JW6jxw2ErhV Er2oWvmqXKmUwAL9wcg2zACIC574olDdXRZAsIU6D58OTy6HdZNckMN/NK7rYkppKmE5 oAYciBaE5/B/tGDA3YIcA4jcB2AQ8iLWDidj7rQwRKU7a/ETykHu2jVcUePgcy5LtzzV jgaPs3Fk6u1w9G1EKcisr/h6T5OR9cIz0TUXMr9js9/B4farOYyojq/1iiKa1YlFoepK u9oECDWeOw4i3i31EoGK9o4E0NcY594cdUzFo+3u+R/r2y5Xfbm2K2SS5riOQBPnBSU1 La6Q== MIME-Version: 1.0 X-Received: by 10.42.223.10 with SMTP id ii10mr992044icb.17.1377685531272; Wed, 28 Aug 2013 03:25:31 -0700 (PDT) Received: by 10.50.82.4 with HTTP; Wed, 28 Aug 2013 03:25:31 -0700 (PDT) Date: Wed, 28 Aug 2013 15:55:31 +0530 Message-ID: Subject: BFD MIB minimizing notifications From: Rajasekar Kumar To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a113348d0b4300f04e4ff6853 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2013 10:25:36 -0000 --001a113348d0b4300f04e4ff6853 Content-Type: text/plain; charset=ISO-8859-1 Hi I am looking at bfdSessUp & bfdSessDown notifications. Draft mentions the below. "For the cases where a contiguous range of sessions have transitioned into the up(4) state at roughly the same time, the device SHOULD issue a single notification for each range of contiguous indexes in an effort to minimize the emission of a large number of notifications." What is considered as roughly the same time? How long should the implementation wait in order to combine the status changes of multiple sessions, before generating a notification? If I assume that the implementation should wait for some amount of time, the following problem exists. Suppose there are sessions with indexes 1, 2, 3. All of them move to UP state within the waiting time. Before expiry of waiting time, if session index 2 quickly moves to DOWN, then again to UP, bfdSessUp trap will be generated first for session indexes 1,2,3. After this, bfdSessDown will be generated for session index 2. The result is: the order of traps was reversed (With optimization, the order is UP, then DOWN trap. But without optimization, the order would be UP, DOWN, UP) Please let me know if I am missing something. Thanks Rajasekar --001a113348d0b4300f04e4ff6853 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi

I am lookin= g at bfdSessUp & bfdSessDown notifications. Draft mentions the below.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "For the
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 cases where a contiguous range of sessions
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 have transitioned into the up(4) state= at roughly
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the same time, the devi= ce SHOULD issue a single
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 notificati= on for each range of contiguous indexes in
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 an effort to minimize the emission of a large number
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of notifications."

W= hat is considered as roughly the same time? How long should the implementat= ion wait in order to combine the status changes of multiple sessions, befor= e generating a notification?

If I assume that the implementation should wait for some amount o= f time, the following problem exists.=A0 Suppose there are sessions with in= dexes 1, 2, 3. All of them move to UP state within the waiting time.=A0 Bef= ore expiry of waiting time, if session index 2 quickly moves to DOWN, then = again to UP,=A0 bfdSessUp trap will be generated first for session indexes = 1,2,3. After this, bfdSessDown will be generated for session index 2.=A0 Th= e result is: the order of traps was reversed (With optimization, the order = is UP, then DOWN trap.=A0 But without optimization, the order would be UP, = DOWN, UP)

Please let me know if I am missing something.

Thanks=
Rajasekar
--001a113348d0b4300f04e4ff6853-- From nobo@cisco.com Wed Aug 28 06:33:46 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1794821F9EEE for ; Wed, 28 Aug 2013 06:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpfhhoVHyXBs for ; Wed, 28 Aug 2013 06:33:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 514A521F9CB5 for ; Wed, 28 Aug 2013 06:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2553; q=dns/txt; s=iport; t=1377696813; x=1378906413; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xJDfPhBIgUpuG9+5CEZyhBVqlOgHRMjbBWB6M+lb+pc=; b=g2fqqz7LvE2IVeN766jn2Ab3e5lgjsQjV3+xkL4pVWxL+CQQaqQmN9kg jgDus7RB/Nerfhhoi91RgM/l5Wt2kUQW1PVuWRo6d/kLxyDwOrsdwF4tM esmEsihZs/jpJTFGbP2XgfG2erE5iDhTiCWbVWgA7wdywFLNTVBqAs5Ay E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAO36HVKtJV2Y/2dsb2JhbABbgmYhgQbAKoEgFnSCJAEBAQMBdwcHBAIBCA4DBAEBCx0HMhQJCAIEARIIh3MGAbkojzM4BoMWfQOIe4sclTuDIIIq X-IronPort-AV: E=Sophos;i="4.89,976,1367971200"; d="scan'208";a="252640279" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 28 Aug 2013 13:33:33 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7SDXWdM021894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Aug 2013 13:33:32 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 28 Aug 2013 08:33:32 -0500 From: "Nobo Akiya (nobo)" To: Rajasekar Kumar , "rtg-bfd@ietf.org" Subject: RE: BFD MIB minimizing notifications Thread-Topic: BFD MIB minimizing notifications Thread-Index: AQHOo9j2nVStK3vLd0ObMXRyT9Uo0pmqmjjQ Date: Wed, 28 Aug 2013 13:33:32 +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.213.104] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2013 13:33:46 -0000 Hi Rajesekar, Unless implementation wants to intentionally suppress rapid state change(s)= and back to original state, it would be incorrect to "fuse" same state for= same index, meaning there'll be two "up" traps for index 2 whether you opt= imize or not. Without optimization: - There will be 5 traps. - 1-up, 2-up, 3-up, 2-down, 2-up With optimization: - There will be 3 traps. - 1-2-3-up, 2-down, 2-up > What is considered as roughly the same time? How long should the > implementation wait in order to combine the status changes of multiple > sessions, before generating a notification? In general, I would guess that operators do not want the "wait" to be more = than a second, two at the most. - Nobo > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Rajasekar Kumar > Sent: Wednesday, August 28, 2013 6:26 AM > To: rtg-bfd@ietf.org > Subject: BFD MIB minimizing notifications >=20 > Hi > I am looking at bfdSessUp & bfdSessDown notifications. Draft mentions the > below. > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "For the > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cases where a contiguous range of se= ssions > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 have transitioned into the up(4) sta= te at roughly > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the same time, the device SHOULD iss= ue a single > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 notification for each range of conti= guous indexes in > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 an effort to minimize the emission o= f a large number > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of notifications." > What is considered as roughly the same time? How long should the > implementation wait in order to combine the status changes of multiple > sessions, before generating a notification? > If I assume that the implementation should wait for some amount of time, > the following problem exists.=A0 Suppose there are sessions with indexes = 1, 2, > 3. All of them move to UP state within the waiting time.=A0 Before expiry= of > waiting time, if session index 2 quickly moves to DOWN, then again to > UP,=A0 bfdSessUp trap will be generated first for session indexes 1,2,3. = After > this, bfdSessDown will be generated for session index 2.=A0 The result is= : the > order of traps was reversed (With optimization, the order is UP, then DOW= N > trap.=A0 But without optimization, the order would be UP, DOWN, UP) > Please let me know if I am missing something. > Thanks > Rajasekar