From lokeshnb1@gmail.com Thu Apr 4 04:36:42 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 71D0D21F9656 for ; Thu, 4 Apr 2013 04:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 xmgIBDD-bKRj for ; Thu, 4 Apr 2013 04:36:40 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 20C7021F9643 for ; Thu, 4 Apr 2013 04:36:40 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n12so2578212oag.41 for ; Thu, 04 Apr 2013 04:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=p6rMadX6a8FlITTWbhL1/wsgJDuweo0NCpPL1UHqCSc=; b=snHRMxNxjX9oMn1sjEJsxVcgXGdUoSqkIDSYEv1hDxF2g1LA3RpDXdEq90v0CelcDv lDzEKOOuyOM6/NrrNJ2nFUti4ZkWzAmLdqg94bfjM23aEkbRMdPPJ3HMQMOKjQ5awG7e rS6XDgJhCGVE1cUtPi8TgL75XNu7n1B3Q7Qhhd/t3FQU7QjaFJBeNAE+weNKM0uaDVJd 6F2ABzneaWltb20bkSjSZrBAbE9auoMo9GiNQHHZkV3dmMa9a2ItVL9Y/Nohs/OlwJKD 41auvD4X/8A4tnNKdhAiH4cbjWfLz0z2Fm37ex3D/7fJl2w2Jxu7NMUjVL7y1F0uB6dz n/Kg== MIME-Version: 1.0 X-Received: by 10.60.173.199 with SMTP id bm7mr3625189oec.108.1365075399664; Thu, 04 Apr 2013 04:36:39 -0700 (PDT) Received: by 10.76.28.101 with HTTP; Thu, 4 Apr 2013 04:36:39 -0700 (PDT) Date: Thu, 4 Apr 2013 17:06:39 +0530 Message-ID: Subject: Should BFD respond even if there is no session? From: Lokesh NB To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=089e01184bcc49e9ea04d9876228 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, 04 Apr 2013 11:37:55 -0000 --089e01184bcc49e9ea04d9876228 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a general question. If BFD receives a first session establishment packet from a peer but no session matches what is the normal course of action in that case?. RFC 5880 says that you can either ignore the packet or create a new session. What is the general handling of such a situation in the industry? do most of the vendors respond to such a packet and create a BFD session? even though no application in the system want to monitor peer that is requesting a session?. Appreciate your help. Thanks -Lokesh. --089e01184bcc49e9ea04d9876228 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
I'm trying to implemen= t BFD tor monitor IPV4/IPv6 peers. I have a general question.

If BFD= receives a first session establishment packet from a peer but no session m= atches what is the normal course of action in that case?. RFC 5880 says tha= t you can either ignore the packet or create a new session. What is the gen= eral handling of such a situation in the industry? do most of the vendors r= espond to such a packet and create a BFD session? even though no applicatio= n in the system want to monitor peer that is requesting a session?. Appreci= ate your help.

Thanks
-Lokesh.

--089e01184bcc49e9ea04d9876228-- From lokeshnb1@gmail.com Thu Apr 4 04:51:26 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 8717A21F9607 for ; Thu, 4 Apr 2013 04:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 waLu9j+9R2Ko for ; Thu, 4 Apr 2013 04:51:22 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8493521F9615 for ; Thu, 4 Apr 2013 04:51:19 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id l10so2615072oag.2 for ; Thu, 04 Apr 2013 04:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=nlsYUDoWsQPr3ypr4lAl23DCj7ye7rqeTdAhodzewak=; b=A62/jCfoHl0BZHN7y44HghdBKuS1rR/BQbuqUIPA0GcV61+7aCpJfza8CInFbH1Sn9 /I+GViaMw2GzJ5U+0yBEpYzVldzB/94pgJ4BCZp7dE3JgSrLOMNe8ODOPW9C9eB6I9YU Of0e0r+y60/JVocbU7O7n6+a1z09QNLZ39lb2yh2kOC6suH0/CS0V5grmkADBm15borq JKjSjYqQ1dyQdn7vQnEK9eMFGrPGqNsVQ3BT83d9Kv3dliPms7lbVmEmd+VAuJnrXpH1 eqjP8uUfYhPpbyk5wGaVOZmMJsmnJPiFC4e8iTndJjmOP9PnJWj4elHYiLxS65HbsYch NlqA== MIME-Version: 1.0 X-Received: by 10.60.20.225 with SMTP id q1mr3757107oee.31.1365076279187; Thu, 04 Apr 2013 04:51:19 -0700 (PDT) Received: by 10.76.28.101 with HTTP; Thu, 4 Apr 2013 04:51:19 -0700 (PDT) Date: Thu, 4 Apr 2013 17:21:19 +0530 Message-ID: Subject: BFD open source From: Lokesh NB To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1c1fcb660c704d987960e 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, 04 Apr 2013 11:51:26 -0000 --e89a8ff1c1fcb660c704d987960e Content-Type: text/plain; charset=ISO-8859-1 Hi All, Is there any open source implementation of BFD for routing protocols other than BFD patch for quagga-0.99.9 and kbfd? I want the one with echo support which quagga patch and kbfd dont provide. Any help greatly appreciated. Regards -Lokesh --e89a8ff1c1fcb660c704d987960e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
Is there any open source i= mplementation of BFD for routing protocols other than BFD patch for quagga-= 0.99.9 and kbfd?=A0 I want the one with echo support which quagga patch and= kbfd dont provide. Any help greatly appreciated.

Regards
-Lokesh
--e89a8ff1c1fcb660c704d987960e-- From binnyjeshan@gmail.com Thu Apr 4 04:56: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 CBD1A21F9633 for ; Thu, 4 Apr 2013 04:56: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 FfDsyKvdO9r2 for ; Thu, 4 Apr 2013 04:56:32 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F27B321F962E for ; Thu, 4 Apr 2013 04:56:31 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id fe20so2411803lab.1 for ; Thu, 04 Apr 2013 04:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bkx8eYLFoLCGjBUT6RTl+mr3bKrkPNCLsfuJqLMyUYI=; b=IQby1tO37CAsM2SmGnXIl/nig/yhzSzFWg1Yekr8jjsxr0RnSUcZyLYfJTPAWtP3Hr xq0nmwdBxJn5K6Ofxw/Cx+FNTAMrPA5b33PQ1gdzO9W/lJNpy5UcZGLxsLK29ueiskmm p433+FZPoUWaSNUb+JuT88s8oqL5aSblmsddPoQAVia/uG82cEzq9TeauNRqa5JALHlL Xs8YfhGLBH8rw+y3Gcz1lGipEbEc0wHEWTCArh0zfaYMGFIL+E26caH3FCZ2A4gzolkq Ch0D9jbBimbR/1jFWq4syHwUV0pVBkorJj198LDEi+4gjdlRn72vAeDWPHlxvpvY0J87 Ofew== MIME-Version: 1.0 X-Received: by 10.112.138.198 with SMTP id qs6mr3222561lbb.68.1365076241722; Thu, 04 Apr 2013 04:50:41 -0700 (PDT) Received: by 10.114.24.233 with HTTP; Thu, 4 Apr 2013 04:50:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Apr 2013 17:20:41 +0530 Message-ID: Subject: Re: Should BFD respond even if there is no session? From: Binny Jeshan To: Lokesh NB Content-Type: multipart/alternative; boundary=089e011825887ab58c04d987940e 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: Thu, 04 Apr 2013 11:56:32 -0000 --089e011825887ab58c04d987940e Content-Type: text/plain; charset=ISO-8859-1 Hello Lokesh, I don't think i have come across such an implementation. In my experience, such packets are ignored. In MPLS, there is a mechanism known as Bootstrapping, through which BFD Session establishes based on a Bootstrap ping request sent by the peer. For more details refer http://tools.ietf.org/html/rfc5884 Thanks, Binny On 4 April 2013 17:06, Lokesh NB wrote: > Hi All, > I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a general > question. > > If BFD receives a first session establishment packet from a peer but no > session matches what is the normal course of action in that case?. RFC 5880 > says that you can either ignore the packet or create a new session. What is > the general handling of such a situation in the industry? do most of the > vendors respond to such a packet and create a BFD session? even though no > application in the system want to monitor peer that is requesting a > session?. Appreciate your help. > > Thanks > -Lokesh. > > --089e011825887ab58c04d987940e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Lokesh,

I don't think i= have come across such an implementation. In my experience, such packets ar= e ignored.=A0

In MPLS, there is a mech= anism known as Bootstrapping, through which BFD Session establishes based o= n a Bootstrap ping request sent by the peer. For more details refer

Thanks,
Binny


On 4 April 2013 17:06, Lokesh NB <lokeshnb1@gmail.com> wro= te:
Hi All,
I'm trying to implemen= t BFD tor monitor IPV4/IPv6 peers. I have a general question.

If BFD= receives a first session establishment packet from a peer but no session m= atches what is the normal course of action in that case?. RFC 5880 says tha= t you can either ignore the packet or create a new session. What is the gen= eral handling of such a situation in the industry? do most of the vendors r= espond to such a packet and create a BFD session? even though no applicatio= n in the system want to monitor peer that is requesting a session?. Appreci= ate your help.

Thanks
<= /span>
-Lokesh.


--089e011825887ab58c04d987940e-- From nobo@cisco.com Thu Apr 4 06:57: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 1229E21F8D03 for ; Thu, 4 Apr 2013 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Y7-9G9GaBwQ5 for ; Thu, 4 Apr 2013 06:57:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 28DF921F8970 for ; Thu, 4 Apr 2013 06:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10211; q=dns/txt; s=iport; t=1365083866; x=1366293466; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oPn+88W4TQbmz+IpgBP/gcfoRSYsj7LrEb0l3EswgnI=; b=JIdP8KmEHd9oq4zjeS9x8KCNJPk6ySunZNsivrGwVB6Ye0I40H6QMJeM y02iohOfEk2hxxHcrvWWSc2OPUsA46yFIoXleWdtiJXbuAyPPa0HrCtqT 9qGm6fXWbTnAbl4xGEwCkDIfh/0g510cBLp4ZRoqloWs0gPPyLjTtIkc8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkFAPaFXVGtJV2a/2dsb2JhbABDgkIjITa4VAGIMoEAFnSCHwEBAQQtTBACAQgRBAEBCx0HIREUCQgCBAENBQiHegMPAQu3Bg2JW4kHg0KCISYLBgGCX2EDlQ6DAIpShRuDC4FsJBg X-IronPort-AV: E=Sophos;i="4.87,408,1363132800"; d="scan'208,217";a="192017480" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 04 Apr 2013 13:57:45 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r34DvjjN031231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Apr 2013 13:57:45 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 08:57:44 -0500 From: "Nobo Akiya (nobo)" To: Binny Jeshan , Lokesh NB Subject: RE: Should BFD respond even if there is no session? Thread-Topic: Should BFD respond even if there is no session? Thread-Index: AQHOMSjjo3nTD4HPI0iaDew4VJPqn5jGRsOA///KDbA= Date: Thu, 4 Apr 2013 13:56: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.81] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941B5B82D5xmbalnx01ciscoc_" MIME-Version: 1.0 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: Thu, 04 Apr 2013 13:57:48 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941B5B82D5xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Lokesh, I agree with Binny. Best course of action is to ignore such packets at earl= iest ingress path, to avoid unnecessary resources taken up on the local nod= e. Technically you could dynamically create a corresponding session based o= n incoming BFD packets, but it could become a vulnerability unless allowanc= e is scoped and good amount of validations are performed. Even so, without = any "action" attached to dynamically created BFD session on local node, it'= s basically doing a "favor" to requesting node. These complexity additions = are avoided if both sides are required to be configured, thus drop such pac= kets. 5884 creates session based on LSP echo request, so this one is a bit differ= ent. Regards, Nobo From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Binny Jeshan Sent: Thursday, April 04, 2013 7:51 AM To: Lokesh NB Cc: rtg-bfd@ietf.org Subject: Re: Should BFD respond even if there is no session? Hello Lokesh, I don't think i have come across such an implementation. In my experience, = such packets are ignored. In MPLS, there is a mechanism known as Bootstrapping, through which BFD Ses= sion establishes based on a Bootstrap ping request sent by the peer. For mo= re details refer http://tools.ietf.org/html/rfc5884 Thanks, Binny On 4 April 2013 17:06, Lokesh NB > wrote: Hi All, I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a general q= uestion. If BFD receives a first session establishment packet from a peer but no ses= sion matches what is the normal course of action in that case?. RFC 5880 sa= ys that you can either ignore the packet or create a new session. What is t= he general handling of such a situation in the industry? do most of the ven= dors respond to such a packet and create a BFD session? even though no appl= ication in the system want to monitor peer that is requesting a session?. A= ppreciate your help. Thanks -Lokesh. --_000_CECE764681BE964CBE1DFF78F3CDD3941B5B82D5xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Lokesh= ,

 <= /o:p>

I agree with= Binny. Best course of action is to ignore such packets at earliest ingress= path, to avoid unnecessary resources taken up on the local node. Technically you could dynamically create a corresponding session bas= ed on incoming BFD packets, but it could become a vulnerability unless allo= wance is scoped and good amount of validations are performed. Even so, with= out any “action” attached to dynamically created BFD session on local node, it’s basically doing a “fav= or” to requesting node. These complexity additions are avoided if bot= h sides are required to be configured, thus drop such packets.

 <= /o:p>

5884 creates= session based on LSP echo request, so this one is a bit different.

 <= /o:p>

Regards,

Nobo

 <= /o:p>

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf= .org] On Behalf Of Binny Jeshan
Sent: Thursday, April 04, 2013 7:51 AM
To: Lokesh NB
Cc: rtg-bfd@ietf.org
Subject: Re: Should BFD respond even if there is no session?

 

Hello Lokesh,=

 

I don't think i have come acros= s such an implementation. In my experience, such packets are ignored. =

 

In MPLS, there is a mechanism k= nown as Bootstrapping, through which BFD Session establishes based on a Boo= tstrap ping request sent by the peer. For more details refer

 

Thanks,

Binny

=  

On 4 April 2013 17:06, Lokesh N= B <lokeshnb1@gm= ail.com> wrote:

Hi All,

= I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a general q= uestion.

If BFD receives a first session establishment packet from a peer but no ses= sion matches what is the normal course of action in that case?. RFC 5880 sa= ys that you can either ignore the packet or create a new session. What is t= he general handling of such a situation in the industry? do most of the vendors respond to such a packet and creat= e a BFD session? even though no application in the system want to monitor p= eer that is requesting a session?. Appreciate your help.

Thanks

-Lokesh.

 

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941B5B82D5xmbalnx01ciscoc_-- From lokeshnb1@gmail.com Thu Apr 4 21:43:00 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 399E721F96AC for ; Thu, 4 Apr 2013 21:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Wwj16nsXUNBH for ; Thu, 4 Apr 2013 21:42:56 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5B0321F96AD for ; Thu, 4 Apr 2013 21:42:55 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id h1so3641596oag.17 for ; Thu, 04 Apr 2013 21:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1f42JpwCzeZKM4b/QHZ/jmeOXvQINyPbtLRccMUvb4c=; b=JwV9oLzyzJe2z23EjsfG3NWVk5On9poDRrIdX3HoHaTEPYdzLzyxcwA04iRLO6A792 hYQGzChOdMOw3F/eCKgE2kDXY1usNYA4l4j0t/YRlIYeFa7eRU/xvQd0XiJuPWObh6Nk a5IYzTmd4gJeZ2bSgZEh0CRTYoVxByiqRtFGVO2nUEu8gJ8CR445aCCPszS95YlbkfpC oh76ezcvFvGcf+6aLE1ZAcZK+EmTFyJHXO9OfZ6FDSkU4EahXDZxuwhwrJ9RKuIaEO9K KBLm7YWaXEFIm0I7sn4DNCvvALbDuwrRgKCpGrxfDpMERTblnp87SHCdqaSaZ+UX+Hd5 FGBg== MIME-Version: 1.0 X-Received: by 10.182.164.73 with SMTP id yo9mr6885272obb.28.1365136972526; Thu, 04 Apr 2013 21:42:52 -0700 (PDT) Received: by 10.76.28.101 with HTTP; Thu, 4 Apr 2013 21:42:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Apr 2013 10:12:52 +0530 Message-ID: Subject: Re: Should BFD respond even if there is no session? From: Lokesh NB To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=e89a8f6477c7513bcd04d995b8e6 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: Fri, 05 Apr 2013 04:43:00 -0000 --e89a8f6477c7513bcd04d995b8e6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Nobo, >From your response, it looks like generally BFD products do not honour such packets and there is no interoperability problem if I do the same. Am I right? Is there any rare situation/application where you have do this favour to requesting node? Regards -Lokesh. On Thu, Apr 4, 2013 at 7:26 PM, Nobo Akiya (nobo) wrote: > Hello Lokesh,**** > > ** ** > > I agree with Binny. Best course of action is to ignore such packets at > earliest ingress path, to avoid unnecessary resources taken up on the loc= al > node. Technically you could dynamically create a corresponding session > based on incoming BFD packets, but it could become a vulnerability unless > allowance is scoped and good amount of validations are performed. Even so= , > without any =93action=94 attached to dynamically created BFD session on l= ocal > node, it=92s basically doing a =93favor=94 to requesting node. These comp= lexity > additions are avoided if both sides are required to be configured, thus > drop such packets.**** > > ** ** > > 5884 creates session based on LSP echo request, so this one is a bit > different.**** > > ** ** > > Regards,**** > > Nobo**** > > ** ** > > *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On > Behalf Of *Binny Jeshan > *Sent:* Thursday, April 04, 2013 7:51 AM > *To:* Lokesh NB > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: Should BFD respond even if there is no session?**** > > ** ** > > Hello Lokesh,**** > > ** ** > > I don't think i have come across such an implementation. In my experience= , > such packets are ignored. **** > > ** ** > > In MPLS, there is a mechanism known as Bootstrapping, through which BFD > Session establishes based on a Bootstrap ping request sent by the peer. F= or > more details refer**** > > http://tools.ietf.org/html/rfc5884**** > > ** ** > > Thanks,**** > > Binny**** > > ** ** > > On 4 April 2013 17:06, Lokesh NB wrote:**** > > Hi All,**** > > I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a general > question. > > If BFD receives a first session establishment packet from a peer but no > session matches what is the normal course of action in that case?. RFC 58= 80 > says that you can either ignore the packet or create a new session. What = is > the general handling of such a situation in the industry? do most of the > vendors respond to such a packet and create a BFD session? even though no > application in the system want to monitor peer that is requesting a > session?. Appreciate your help. **** > > Thanks**** > > -Lokesh.**** > > ** ** > > ** ** > --e89a8f6477c7513bcd04d995b8e6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks Nobo,
From your respon= se, it looks like generally BFD products do not honour such packets and the= re is no interoperability problem if I do the same. Am I right?
Is= there any rare situation/application where you have do this favour to requ= esting node?

Regards
-Lokesh.

On Thu, Apr 4, 2013 at 7:26 PM, Nobo Akiya = (nobo) <nobo@cisco.com> wrote:

Hello Lokesh= ,

=A0

I agree with= Binny. Best course of action is to ignore such packets at earliest ingress= path, to avoid unnecessary resources taken up on the local node. Technically you could dynamically create a corresponding session bas= ed on incoming BFD packets, but it could become a vulnerability unless allo= wance is scoped and good amount of validations are performed. Even so, with= out any =93action=94 attached to dynamically created BFD session on local node, it=92s basically doing a =93favor=94 to= requesting node. These complexity additions are avoided if both sides are = required to be configured, thus drop such packets.

=A0

5884 creates= session based on LSP echo request, so this one is a bit different.<= u>

=A0

Regards,<= /u>

Nobo<= u>

=A0

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Binny Jeshan
Sent: Thursday, April 04, 2013 7:51 AM
To: Lokesh NB
Cc: rtg-bfd@ie= tf.org
Subject: Re: Should BFD respond even if there is no session?<= u>

=A0

Hello Lokesh,

=A0

I don't think i have come a= cross such an implementation. In my experience, such packets are ignored.= =A0

=A0

In MPLS, there is a mechanism k= nown as Bootstrapping, through which BFD Session establishes based on a Boo= tstrap ping request sent by the peer. For more details refer<= /span>

=A0

Thanks,

Binny

= =A0

On 4 April 2013 17:06, Lokesh N= B <lokeshnb1@gm= ail.com> wrote:

Hi All,

= I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a gener= al question.

If BFD receives a first session establishment packet from a peer but no ses= sion matches what is the normal course of action in that case?. RFC 5880 sa= ys that you can either ignore the packet or create a new session. What is t= he general handling of such a situation in the industry? do most of the vendors respond to such a packet and creat= e a BFD session? even though no application in the system want to monitor p= eer that is requesting a session?. Appreciate your help.

Thanks

-= Lokesh.

=A0

=A0


--e89a8f6477c7513bcd04d995b8e6-- From lokeshnb1@gmail.com Thu Apr 4 21:51: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 91A2121F96BB for ; Thu, 4 Apr 2013 21:51: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 3d-oKMO3e2Dw for ; Thu, 4 Apr 2013 21:51:46 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id B143321F96B9 for ; Thu, 4 Apr 2013 21:51:46 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uz6so3377477obc.36 for ; Thu, 04 Apr 2013 21:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=qD6PXGgSJdmyQAQB6rv5Xy5sghCd4aAwKXW2ATWMQYc=; b=MYEQlyd1hp4nRUfbulsJkBoV4RuG0i2/6h3tYKjZ2Smg2mIbB/lKAGi1tAqh8xqwIb 3F13lbRm8swb4lwFx0gwJr3l3wTz1qiNR47xRjye7isiL7qZl/SKlArHt3A22e3bNV+g Pwci0VaQsKYKQynvWIU5BjLj3srBR/0c/DmN4UDi3rl8o1424sRkefCLX782/tYO/3gf 18NNLG6QHktgYgO0zus2mVxAkBWmFj/NdkDHQ3v9LtWJrKXcMW33EtZhqckdsCaMTpiE omTs9iyoqOTD8SoXDjlWK/kmEiNcy4RBeCDHBrjkqjIvDm4V/GuNCWiG6byrkqPxxTQs e/tw== MIME-Version: 1.0 X-Received: by 10.182.176.37 with SMTP id cf5mr2654889obc.101.1365137505782; Thu, 04 Apr 2013 21:51:45 -0700 (PDT) Received: by 10.76.28.101 with HTTP; Thu, 4 Apr 2013 21:51:45 -0700 (PDT) Date: Fri, 5 Apr 2013 10:21:45 +0530 Message-ID: Subject: How commonly Echo and Demand mode is used? From: Lokesh NB To: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ff1cd541a10bb04d995d811 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: Fri, 05 Apr 2013 04:51:48 -0000 --e89a8ff1cd541a10bb04d995d811 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I would like know if there are routing applications that use demand mode and echo mode usually. I understand that asynchronous mode is used by most of the applications. I'm newbie to BFD, sorry if these questions sound too naive. Appreciate answers. Regards -Lokesh. --e89a8ff1cd541a10bb04d995d811 Content-Type: text/html; charset=ISO-8859-1
Hi All,
I would like know if there are routing applications that use demand mode and echo mode usually.
I understand that asynchronous mode is used by most of the applications.
I'm newbie to BFD, sorry if these questions sound too naive. Appreciate answers.

Regards
-Lokesh.
--e89a8ff1cd541a10bb04d995d811-- From binnyjeshan@gmail.com Thu Apr 4 22:56:38 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 A86AC21F96E9 for ; Thu, 4 Apr 2013 22:56:38 -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 LiTNxPGOyz-2 for ; Thu, 4 Apr 2013 22:56:37 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2665E21F96C4 for ; Thu, 4 Apr 2013 22:56:36 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so3106151lab.22 for ; Thu, 04 Apr 2013 22:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=i4pF5MWIYNxq3O1kNcR8IfY1uph0DKXfcyVdLI6HmEo=; b=LOKNQ13NfmrfV9ea6vgSP43dv8TgmZKGLoNthoh8V/G75juxGZaOk+Gt7AuHjDNjLv iKoWLAxrWed/o91eDMsJNc3ZEeyoJNgKWfkUnR+AnbycuqfQzgxZAI/k+V0dTzR8JgGa IarhmNUziIfgCNMpJiaKFuc6kBkyKEZrwmrv1vGZMxHUcbB21i7AJW5W0f1meyR8ntWm o3Nzxy9ykFqhQOYGF0ZGpoT1yiYSd1LBkFOKLmY1Pc8vjY+Xq+Q7htAYRkl4E5Q5bXfv l+t65XAsgLTJlw/+gKsu9EHLZbl7bDFTMohZQi1wV/kDgJZ/+CRHHc8iumRniIFOxom4 ffvA== MIME-Version: 1.0 X-Received: by 10.152.144.105 with SMTP id sl9mr5157521lab.4.1365141395915; Thu, 04 Apr 2013 22:56:35 -0700 (PDT) Received: by 10.114.24.233 with HTTP; Thu, 4 Apr 2013 22:56:35 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Apr 2013 11:26:35 +0530 Message-ID: Subject: Re: Should BFD respond even if there is no session? From: Binny Jeshan To: Lokesh NB Content-Type: multipart/alternative; boundary=e89a8f22c5bdf8c84a04d996bf87 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: Fri, 05 Apr 2013 05:56:38 -0000 --e89a8f22c5bdf8c84a04d996bf87 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Lokesh, I think that should more depend on how your system is specified to work. In case in the network you would need to do it that way as per what the Operator wants AND if your device OEM agrees to do it, only then its needed. But if your equipment system engineering needs BFD session to start only when your operator manually configures it, then you can stop honoring such BFD packets whose session entry does not exist with you. Regards, Binny, *Aricent Group.* On 5 April 2013 10:12, Lokesh NB wrote: > Thanks Nobo, > From your response, it looks like generally BFD products do not honour > such packets and there is no interoperability problem if I do the same. A= m > I right? > Is there any rare situation/application where you have do this favour to > requesting node? > > Regards > -Lokesh. > > > On Thu, Apr 4, 2013 at 7:26 PM, Nobo Akiya (nobo) wrote: > >> Hello Lokesh,**** >> >> ** ** >> >> I agree with Binny. Best course of action is to ignore such packets at >> earliest ingress path, to avoid unnecessary resources taken up on the lo= cal >> node. Technically you could dynamically create a corresponding session >> based on incoming BFD packets, but it could become a vulnerability unles= s >> allowance is scoped and good amount of validations are performed. Even s= o, >> without any =93action=94 attached to dynamically created BFD session on = local >> node, it=92s basically doing a =93favor=94 to requesting node. These com= plexity >> additions are avoided if both sides are required to be configured, thus >> drop such packets.**** >> >> ** ** >> >> 5884 creates session based on LSP echo request, so this one is a bit >> different.**** >> >> ** ** >> >> Regards,**** >> >> Nobo**** >> >> ** ** >> >> *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On >> Behalf Of *Binny Jeshan >> *Sent:* Thursday, April 04, 2013 7:51 AM >> *To:* Lokesh NB >> *Cc:* rtg-bfd@ietf.org >> *Subject:* Re: Should BFD respond even if there is no session?**** >> >> ** ** >> >> Hello Lokesh,**** >> >> ** ** >> >> I don't think i have come across such an implementation. In my >> experience, such packets are ignored. **** >> >> ** ** >> >> In MPLS, there is a mechanism known as Bootstrapping, through which BFD >> Session establishes based on a Bootstrap ping request sent by the peer. = For >> more details refer**** >> >> http://tools.ietf.org/html/rfc5884**** >> >> ** ** >> >> Thanks,**** >> >> Binny**** >> >> ** ** >> >> On 4 April 2013 17:06, Lokesh NB wrote:**** >> >> Hi All,**** >> >> I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a genera= l >> question. >> >> If BFD receives a first session establishment packet from a peer but no >> session matches what is the normal course of action in that case?. RFC 5= 880 >> says that you can either ignore the packet or create a new session. What= is >> the general handling of such a situation in the industry? do most of the >> vendors respond to such a packet and create a BFD session? even though n= o >> application in the system want to monitor peer that is requesting a >> session?. Appreciate your help. **** >> >> Thanks**** >> >> -Lokesh.**** >> >> ** ** >> >> ** ** >> > > --e89a8f22c5bdf8c84a04d996bf87 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Lokesh,

I think that should mo= re depend on how your system is specified to work. In case in the network y= ou would need to do it that way as per what the Operator wants AND if your = device OEM agrees to do it, only then its needed.=A0

But if your equipment system engineering ne= eds BFD session to start only when your operator manually configures it, th= en you can stop honoring such BFD packets whose session entry does not exis= t with you.

Regards,
Binny,
Aricent Group.


On 5 April 2013 10:= 12, Lokesh NB <lokeshnb1@gmail.com> wrote:
Thanks Nobo,=
From your response, it looks like generally BFD products do = not honour such packets and there is no interoperability problem if I do th= e same. Am I right?
Is there any rare situation/application where you have do this favour= to requesting node?

Regards
=
-Lokesh.


On Thu, Apr 4, 2013 at 7:26 PM, Nobo Aki= ya (nobo) <nobo@cisco.com> wrote:

Hello Lokesh= ,

=A0

I agree with= Binny. Best course of action is to ignore such packets at earliest ingress= path, to avoid unnecessary resources taken up on the local node. Technically you could dynamically create a corresponding session bas= ed on incoming BFD packets, but it could become a vulnerability unless allo= wance is scoped and good amount of validations are performed. Even so, with= out any =93action=94 attached to dynamically created BFD session on local node, it=92s basically doing a =93favor=94 to= requesting node. These complexity additions are avoided if both sides are = required to be configured, thus drop such packets.

=A0

5884 creates= session based on LSP echo request, so this one is a bit different.<= u>

=A0

Regards,<= /u>

Nobo<= u>

=A0

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Binny Jeshan
Sent: Thursday, April 04, 2013 7:51 AM
To: Lokesh NB
Cc: rtg-bfd@ie= tf.org
Subject: Re: Should BFD respond even if there is no session?<= u>

=A0

Hello Lokesh,

=A0

I don't think i have come a= cross such an implementation. In my experience, such packets are ignored.= =A0

=A0

In MPLS, there is a mechanism k= nown as Bootstrapping, through which BFD Session establishes based on a Boo= tstrap ping request sent by the peer. For more details refer<= /span>

=A0

Thanks,

Binny

= =A0

On 4 April 2013 17:06, Lokesh N= B <lokeshnb1@gm= ail.com> wrote:

Hi All,

= I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a gener= al question.

If BFD receives a first session establishment packet from a peer but no ses= sion matches what is the normal course of action in that case?. RFC 5880 sa= ys that you can either ignore the packet or create a new session. What is t= he general handling of such a situation in the industry? do most of the vendors respond to such a packet and creat= e a BFD session? even though no application in the system want to monitor p= eer that is requesting a session?. Appreciate your help.

Thanks

-= Lokesh.

=A0

=A0



--e89a8f22c5bdf8c84a04d996bf87-- From swallow@cisco.com Fri Apr 5 07:54:21 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 15D0421F97DE for ; Fri, 5 Apr 2013 07:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 RRaFuEWB04xM for ; Fri, 5 Apr 2013 07:54:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0306321F97C9 for ; Fri, 5 Apr 2013 07:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12469; q=dns/txt; s=iport; t=1365173660; x=1366383260; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=vg03U5CUVDZkk/okQI5aSFKzypiOrc+BP9G/XWtyllM=; b=WGBcLembSqXqMojlfwtztu/bIffkcg0r2A9P2I1UiwVbSFUMjbjc3V8H WftiIp8Oh9fJAA4967Kr3AD6Im+GAgH7KPQHOl/9JtnMPnE0923skTp5G 4O9N40LudBTFkchxLD33qcwkLgaWWTSDamgfehhaUPRbEWfiW4SH6aZFa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAN7kXlGtJV2d/2dsb2JhbABLgkJENrhdiDOBCxZ0gh8BAQEEeRIBCBEDAQEBCx0oERQJCAIEAQ0FCId6Aw8Mt1QNiV2MSYIhIAYLBgGCX2EDlQ6DAIpShRuDC4FsJBg X-IronPort-AV: E=Sophos;i="4.87,415,1363132800"; d="scan'208,217";a="195414941" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 05 Apr 2013 14:54:19 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r35EsJLr016360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Apr 2013 14:54:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 09:54:18 -0500 From: "George Swallow (swallow)" To: Lokesh NB , "Nobo Akiya (nobo)" Subject: Re: Should BFD respond even if there is no session? Thread-Topic: Should BFD respond even if there is no session? Thread-Index: AQHOMSjj6Gn+P8NbgEibgkZ5ewDvOZjGRsOAgAAjMYCAAPecAIAAZ8QA Date: Fri, 5 Apr 2013 14:54:17 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0F7EC003@xmb-rcd-x10.cisco.com> 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: [10.98.56.166] Content-Type: multipart/alternative; boundary="_000_2FE467D3673DCE409A84D67EC2F607BB0F7EC003xmbrcdx10ciscoc_" MIME-Version: 1.0 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: Fri, 05 Apr 2013 14:54:21 -0000 --_000_2FE467D3673DCE409A84D67EC2F607BB0F7EC003xmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It would most likely happen due to a misconfiguration where the operator ha= s only configured one end of a desired (nor not deleted the other end of a = no longer desired) BFD session. The configured end will keep sending BFD p= ackets to init but this should be 1 per second or less, and perhaps exponen= tial back off is implemented, though this is not required (and barely menti= oned) in the spec. George From: Lokesh NB > Date: Friday, April 5, 2013 12:42 AM To: "Nobo Akiya (nobo)" > Cc: "rtg-bfd@ietf.org" > Subject: Re: Should BFD respond even if there is no session? Thanks Nobo, >From your response, it looks like generally BFD products do not honour such= packets and there is no interoperability problem if I do the same. Am I ri= ght? Is there any rare situation/application where you have do this favour to re= questing node? Regards -Lokesh. On Thu, Apr 4, 2013 at 7:26 PM, Nobo Akiya (nobo) > wrote: Hello Lokesh, I agree with Binny. Best course of action is to ignore such packets at earl= iest ingress path, to avoid unnecessary resources taken up on the local nod= e. Technically you could dynamically create a corresponding session based o= n incoming BFD packets, but it could become a vulnerability unless allowanc= e is scoped and good amount of validations are performed. Even so, without = any =93action=94 attached to dynamically created BFD session on local node,= it=92s basically doing a =93favor=94 to requesting node. These complexity = additions are avoided if both sides are required to be configured, thus dro= p such packets. 5884 creates session based on LSP echo request, so this one is a bit differ= ent. Regards, Nobo From:rtg-bfd-bounces@ietf.org [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Binny J= eshan Sent: Thursday, April 04, 2013 7:51 AM To: Lokesh NB Cc: rtg-bfd@ietf.org Subject: Re: Should BFD respond even if there is no session? Hello Lokesh, I don't think i have come across such an implementation. In my experience, = such packets are ignored. In MPLS, there is a mechanism known as Bootstrapping, through which BFD Ses= sion establishes based on a Bootstrap ping request sent by the peer. For mo= re details refer http://tools.ietf.org/html/rfc5884 Thanks, Binny On 4 April 2013 17:06, Lokesh NB > wrote: Hi All, I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a general q= uestion. If BFD receives a first session establishment packet from a peer but no ses= sion matches what is the normal course of action in that case?. RFC 5880 sa= ys that you can either ignore the packet or create a new session. What is t= he general handling of such a situation in the industry? do most of the ven= dors respond to such a packet and create a BFD session? even though no appl= ication in the system want to monitor peer that is requesting a session?. A= ppreciate your help. Thanks -Lokesh. --_000_2FE467D3673DCE409A84D67EC2F607BB0F7EC003xmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
It would most likely happen due to a misconfiguration where the operat= or has only configured one end of a desired (nor not deleted the other end = of a no longer desired) BFD session.  The configured end will keep sen= ding BFD packets to init but this should be 1 per second or less, and perhaps exponential back off is implemented, = though this is not required (and barely mentioned) in the spec.

George

From: Lokesh NB <lokeshnb1@gmail.com>
Date: Friday, April 5, 2013 12:42 A= M
To: "Nobo Akiya (nobo)" &= lt;nobo@cisco.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Should BFD respond eve= n if there is no session?

Thanks Nobo,
From your response, it looks like generally BFD products do not honour= such packets and there is no interoperability problem if I do the same. Am= I right?
Is there any rare situation/application where you have do this favour to re= questing node?

Regards
-Lokesh.


On Thu, Apr 4, 2013 at 7:26 PM, Nobo Akiya (nobo= ) <nobo@cisco.com&= gt; wrote:

Hello Lokesh,<= u>

 <= /span>

I agree with Binny. B= est course of action is to ignore such packets at earliest ingress path, to= avoid unnecessary resources taken up on the local node. Technically you could dynamically create a correspondin= g session based on incoming BFD packets, but it could become a vulnerabilit= y unless allowance is scoped and good amount of validations are performed. = Even so, without any =93action=94 attached to dynamically created BFD session on local node, it=92s basically doing a= =93favor=94 to requesting node. These complexity additions are avoided if = both sides are required to be configured, thus drop such packets.=

 <= /span>

5884 creates session = based on LSP echo request, so this one is a bit different.

 <= /span>

Regards,

Nobo

 <= /span>

From:rtg-bfd-bounces@ietf.org [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Binny Jeshan
Sent: Thursday, April 04, 2013 7:51 AM
To: Lokesh NB
Cc: rtg-bfd@ie= tf.org
Subject: Re: Should BFD respond even if there is no session?<= u>

 

Hello Lokesh,

 

I don't think i have come acros= s such an implementation. In my experience, such packets are ignored. =

 

In MPLS, there is a mechanism k= nown as Bootstrapping, through which BFD Session establishes based on a Boo= tstrap ping request sent by the peer. For more details refer<= /span>

 

Thanks,

Binny

=  

On 4 April 2013 17:06, Lokesh N= B <lokeshnb1@gm= ail.com> wrote:

Hi All,

= I'm trying to implement BFD tor monitor IPV4/IPv6 peers. I have a general q= uestion.

If BFD receives a first session establishment packet from a peer but no ses= sion matches what is the normal course of action in that case?. RFC 5880 sa= ys that you can either ignore the packet or create a new session. What is t= he general handling of such a situation in the industry? do most of the vendors respond to such a packet and creat= e a BFD session? even though no application in the system want to monitor p= eer that is requesting a session?. Appreciate your help.

Thanks

-= Lokesh.

 

 


 --_000_2FE467D3673DCE409A84D67EC2F607BB0F7EC003xmbrcdx10ciscoc_-- From Palanivelan.Appanasamy@emc.com Tue Apr 9 23:47:22 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 DBB8921F8D14 for ; Tue, 9 Apr 2013 23:47:22 -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 IZGEqIhHDxla for ; Tue, 9 Apr 2013 23:47:22 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3671721F8CF0 for ; Tue, 9 Apr 2013 23:47:21 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3A6lBdT022259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Apr 2013 02:47:17 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 10 Apr 2013 02:46:56 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3A6ktp2002641; Wed, 10 Apr 2013 02:46:56 -0400 Received: from MXHUB101.corp.emc.com (10.253.50.15) by mxhub23.corp.emc.com (128.222.70.135) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 10 Apr 2013 02:46:55 -0400 Received: from MX101CL02.corp.emc.com ([169.254.2.117]) by MXHUB101.corp.emc.com ([::1]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 02:46:55 -0400 From: "Appanasamy, Palanivelan" To: "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-palanivelan-bfd-gr-rec-00.txt Thread-Topic: New Version Notification for draft-palanivelan-bfd-gr-rec-00.txt Thread-Index: AQHONa24X6DEamE5YkiAUekhbTiIJZjO8ISQ Importance: high X-Priority: 1 Date: Wed, 10 Apr 2013 06:46:54 +0000 Message-ID: <54E302958EBE2A4FBC6403165D8C1599025686DE@MX101CL02.corp.emc.com> References: <20130410053835.15174.30949.idtracker@ietfa.amsl.com> In-Reply-To: <20130410053835.15174.30949.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.77.123] Content-Type: multipart/alternative; boundary="_000_54E302958EBE2A4FBC6403165D8C1599025686DEMX101CL02corpem_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "apvelan.ietf@gmail.com" , "Black, David" , "dward@cisco.com" , "dkatz@juniper.net" 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, 10 Apr 2013 06:47:23 -0000 --_000_54E302958EBE2A4FBC6403165D8C1599025686DEMX101CL02corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGhhdmUgcG9zdGVkIGEgKEJDUCBpbnRlbmRlZCkgZHJhZnQgICggIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbGFuaXZlbGFuLWJmZC1nci1yZWMtMDApIHRv ZGF5Lg0KVGhlIGludGVudGlvbiBvZiB0aGUgZHJhZnQgaXMgYWRkcmVzc2luZyB0aGUgcHJvYmxl bSBhcyBub3RlZCBpbiBteSBwcmV2aW91cyBkcmFmdC4NCg0KSG93ZXZlciwgdGhlIHByb2JsZW0g aXMgYWRkcmVzc2VkIGJhc2VkIHdpdGhpbiB0aGUgZXhpc3RpbmcgZnJhbWV3b3JrIG9mIGJmZC4g VGhlIGFwcGxpY2FiaWxpdHkgaXMgYWxzbyBkaXNjdXNzZWQgaW4gdGhpcyBkb2N1bWVudC4NClRo ZSBjb250ZW50IGFuZCBhcHByb2FjaCBpbiB0aGlzIGRyYWZ0IGFyZSBiYXNlZCBvbiB0aGUgZmVl ZGJhY2ssIGNvbW1lbnRzIGFuZCBpbnB1dHMgdmlhIGVtYWlscyBhbmQgaW4tcGVyc29uIGludGVy YWN0aW9ucyB3aXRoaW4gYW5kIG91dHNpZGUgb2YgdGhpcyB3b3JraW5nIGdyb3VwLg0KDQpUaGlz IGlzIGEgMCB2ZXJzaW9uIGRyYWZ0IGFuZCBoZW5jZSB1bmRlcnN0YW5kIHRoZSBwb3RlbnRpYWwg aW1wcm92ZW1lbnRzIGluIG1vdmluZyB0b3dhcmRzIGFuIGFjY2VwdGFibGUgZG9jdW1lbnQuDQoN ClRoYW5rcyBhbmQgUmVnYXJkcywNCkEuUGFsYW5pdmVsYW4NClByaW5jaXBhbCBTb2Z0d2FyZSBF bmdpbmVlciwNCk5ldHdvcmtpbmcgJiBTdG9yYWdlIFZpcnR1YWxpemF0aW9uLCBFTUMgQ29ycG9y YXRpb24uDQoNCg0KDQo= --_000_54E302958EBE2A4FBC6403165D8C1599025686DEMX101CL02corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SGkgYWxsLDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+SSBoYXZlIHBvc3RlZCBhIChCQ1AgaW50ZW5kZWQpIGRyYWZ0Jm5ic3A7ICgmbmJz cDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFsYW5pdmVsYW4t YmZkLWdyLXJlYy0wMCI+PGZvbnQgY29sb3I9ImJsdWUiPjx1Pmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXBhbGFuaXZlbGFuLWJmZC1nci1yZWMtMDA8L3U+PC9mb250PjwvYT4pIHRv ZGF5LjwvZGl2Pg0KPGRpdj5UaGUgaW50ZW50aW9uIG9mIHRoZSBkcmFmdCBpcyBhZGRyZXNzaW5n IHRoZSBwcm9ibGVtIGFzIG5vdGVkIGluIG15IHByZXZpb3VzIGRyYWZ0LiA8L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2Pkhvd2V2ZXIsIHRoZSBwcm9ibGVtIGlzIGFkZHJlc3NlZCBiYXNl ZCB3aXRoaW4gdGhlIGV4aXN0aW5nIGZyYW1ld29yayBvZiBiZmQuIFRoZSBhcHBsaWNhYmlsaXR5 IGlzIGFsc28gZGlzY3Vzc2VkIGluIHRoaXMgZG9jdW1lbnQuPC9kaXY+DQo8ZGl2PlRoZSBjb250 ZW50IGFuZCBhcHByb2FjaCBpbiB0aGlzIGRyYWZ0IGFyZSBiYXNlZCBvbiB0aGUgZmVlZGJhY2ss IGNvbW1lbnRzIGFuZCBpbnB1dHMgdmlhIGVtYWlscyBhbmQgaW4tcGVyc29uIGludGVyYWN0aW9u cyB3aXRoaW4gYW5kIG91dHNpZGUgb2YgdGhpcyB3b3JraW5nIGdyb3VwLjwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+VGhpcyBpcyBhIDAgdmVyc2lvbiBkcmFmdCBhbmQgaGVuY2UgdW5k ZXJzdGFuZCB0aGUgcG90ZW50aWFsIGltcHJvdmVtZW50cyBpbiBtb3ZpbmcgdG93YXJkcyBhbiBh Y2NlcHRhYmxlIGRvY3VtZW50LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhhbmtz IGFuZCBSZWdhcmRzLDwvZGl2Pg0KPGRpdj5BLlBhbGFuaXZlbGFuPC9kaXY+DQo8ZGl2Pjxmb250 IGNvbG9yPSIjMDAyMDYwIj5QcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIsPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMjA2MCI+TmV0d29ya2luZyAmYW1wOyBTdG9yYWdlIFZp cnR1YWxpemF0aW9uLCBFTUMgQ29ycG9yYXRpb24uPC9mb250PjwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9zcGFuPjwvZm9u dD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_54E302958EBE2A4FBC6403165D8C1599025686DEMX101CL02corpem_-- From marc@sniff.de Tue Apr 16 07:27:40 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 21BDA21F9717 for ; Tue, 16 Apr 2013 07:27:40 -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 YyHVhmr5VZpW for ; Tue, 16 Apr 2013 07:27:39 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EB021F9718 for ; Tue, 16 Apr 2013 07:27:38 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 53D7B2AA0F for ; Tue, 16 Apr 2013 14:27:30 +0000 (GMT) From: Marc Binderberger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: I-D Action: draft-mmm-bfd-on-lags-07.txt Date: Tue, 16 Apr 2013 16:27:28 +0200 References: <20130412234203.32330.20990.idtracker@ietfa.amsl.com> To: rtg-bfd@ietf.org Message-Id: <3CE4C82A-44B3-42AE-BFD8-922972A1ADE3@sniff.de> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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: Tue, 16 Apr 2013 14:27:40 -0000 Hello BFD experts, FYI, we have updated the draft draft-mmm-bfd-on-lags to version 7. The = changes are: * replace the "to-be-assigned" text parts with the UDP port and Ethernet = MAC meanwhile assigned by IANA. * section 2.3, the use of the MAC learned from peer packets is now = optional, i.e. MAY, instead of being a SHOULD. This keeps the basic = protocol simple (no MAC change, always using the dedicated MAC), a = lesson we learned from interoperability testing being done. * section 3.1, we have added the "standby" in addition to "distributed" = as another port state that triggers the start/removal of the BFD = session. This keeps the overall logic simpler in case of active/standby = scenarios. As always, comments are welcome :-) Thanks & Regards, Marc Begin forwarded message: > From: internet-drafts@ietf.org > Date: April 13, 2013 1:42:03 GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-mmm-bfd-on-lags-07.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Bidirectional Forwarding Detection (BFD) on = Link Aggregation Group (LAG) Interfaces > Author(s) : Manav Bhatia > Mach(Guoyi) Chen > Sami Boutros > Marc Binderberger > Jeffrey Haas > Filename : draft-mmm-bfd-on-lags-07.txt > Pages : 11 > Date : 2013-04-12 >=20 > Abstract: > This document proposes a mechanism to run BFD on Link Aggregation > Group (LAG) interfaces. It does so by running an independent > Asynchronous mode BFD session on every LAG member link. >=20 > This mechanism allows the verification of member link continuity, > either in combination with, or in absence of, LACP. It provides a > shorter detection time than what LACP offers. The continuity check > can also cover elements of layer 3 bidirectional forwarding. >=20 > This mechanism utilizes a well-known UDP port distinct from that of > single-hop BFD over IP. This new UDP port removes the ambiguity of > BFD over LAG packets from BFD over single-hop IP. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-mmm-bfd-on-lags >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-mmm-bfd-on-lags-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From internet-drafts@ietf.org Thu Apr 18 01:47:35 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 D069421F8B3A; Thu, 18 Apr 2013 01:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 X5yw8KRJNTAN; Thu, 18 Apr 2013 01:47:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C39721F8A38; Thu, 18 Apr 2013 01:47:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-generic-crypto-auth-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130418084735.26162.35879.idtracker@ietfa.amsl.com> Date: Thu, 18 Apr 2013 01:47:35 -0700 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: Thu, 18 Apr 2013 08:47:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Generic Cryptographic Authentication Author(s) : Manav Bhatia Vishwas Manral Dacheng Zhang Filename : draft-ietf-bfd-generic-crypto-auth-04.txt Pages : 12 Date : 2013-04-18 Abstract: This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of arbitary cryptographic authentication algorithms in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure that is required for supporting algorithm and key agility for BFD. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-generic-crypto-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-generic-crypto-auth-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Apr 18 02:04:36 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 2CDF121F8E79; Thu, 18 Apr 2013 02:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 D9oi1xmUB9Pj; Thu, 18 Apr 2013 02:04:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEF621F8E3C; Thu, 18 Apr 2013 02:04:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-hmac-sha-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130418090435.5088.26775.idtracker@ietfa.amsl.com> Date: Thu, 18 Apr 2013 02:04:35 -0700 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: Thu, 18 Apr 2013 09:04:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : Authenticating BFD using HMAC-SHA-2 procedures Author(s) : Dacheng Zhang Manav Bhatia Vishwas Manral Filename : draft-ietf-bfd-hmac-sha-03.txt Pages : 9 Date : 2013-04-18 Abstract: This document describes the mechanism to authenticate Bidirectional Forwarding Detection (BFD) protocol packets using Hashed Message Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 algorithms. The described mechanism uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This document updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-hmac-sha There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-hmac-sha-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hammondjohnson@hushmail.com Sat Apr 27 14:06: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 5D46221F9916 for ; Sat, 27 Apr 2013 14:06:57 -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 2kN0lCqezS+1 for ; Sat, 27 Apr 2013 14:06:57 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCC121F9929 for ; Sat, 27 Apr 2013 14:06:54 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id E8C99580C3 for ; Sat, 27 Apr 2013 18:03:45 +0000 (UTC) X-hush-relay-time: 220 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 18:03:45 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id B9D3DE6736; Sat, 27 Apr 2013 18:03:45 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 14:03:45 -0400 To: rtg-bfd@ietf.org Subject: Biggest Fake Conference in Computer Science From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427180345.B9D3DE6736@smtp.hushmail.com> 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: Sat, 27 Apr 2013 21:06:57 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.