From: Satyam Sinha [mailto:satyamsinha@live.com]= =20
Sent: Friday, August 14, 2009 1:57 PM
To: Shahram Dava= ri;=20 rtg-bfd@ietf.org
Subject: RE: Timer Manipulation

Hi Shahram,

The MAY here means that BFD allows an endpoin= t to=20 set both (P) and (F) bits together in the same packet. The endpoint "MAY"=20 initiate the poll sequence even while it is responding to a poll sequence. = It is=20 not mandatory for it to wait for the poll sequence to complete before initi= ating=20 it's own poll sequence.

In case of change in local parameters while = the=20 endpoint is receiving a poll sequence, the endpoint could either use new=20 parameters and set both (P) & (F) bits or use old parameters with only = the=20 (F) bit set and then start a poll sequence following the final transmission= s. In=20 both cases the endpoint has to wait for a Final packet from the other=20 end.

Regards,

Satyam

From: davari@broadcom.com
To: rtg-bfd@ietf.org
Date: Fri, 14 Aug 2009= =20 12:44:24 -0700
Subject: Timer Manipulation

Hi,

Section 6.8.3 o= f base=20 draft says :

"If either=20 bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed= , a=20 Poll Sequence MUST be initiated (see section 6.5). If the timing is such th= at a=20 system receiving a Poll Sequence wishes to change the parameters described = in=20 this paragraph, the new parameter values MAY be carried in packets with the= =20 Final (F) bit set, even if the Poll Sequence has not yet been=20 sent."

It seems=20 that the above mentioned MAY requirement is not a good idea, because i= f a=20 Poll receiver updates any parameter in the Final packet, then how can the P= oll=20 receiver verify that those Parameters are Received by the Poll sender?=20

Regards,

Shahram

Get your vacation photos on your phone! Click here. --_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9SJEXCHCCR02co_-- From davari@broadcom.com Fri Aug 14 14:23:43 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2FF3A6A0A for ; Fri, 14 Aug 2009 14:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKBVbAEfSbxX for ; Fri, 14 Aug 2009 14:23:42 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 8D3223A69CD for ; Fri, 14 Aug 2009 14:23:42 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 14 Aug 2009 14:23:43 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Fri, 14 Aug 2009 14:23:43 -0700 From: "Shahram Davari" To: "rtg-bfd@ietf.org" Date: Fri, 14 Aug 2009 14:23:42 -0700 Subject: Induced Jitter Thread-Topic: Induced Jitter Thread-Index: AcodJX9fG4g5AFG+QgqXsTjcIKQyOQ== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5ED@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 669B0A5537015788975-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D5EDSJEXCHCCR02co_ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 21:23:43 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D5EDSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, When a local system applies Jitter to transmitted BFD control packets, is t= he remote system aware of the amount of this Jitter? or the remote bases it= s Detection time without taking to account this Jitter? If so then doesn't = this cause a problem, since the Jitter could be as much as 25% and this val= ue is added on top of the network jitter. Thanks, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D5EDSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,

When a lo= cal system=20 applies Jitter to transmitted BFD control packets, is the remote system awa= re of=20 the amount of this Jitter? or the remote bases its Detection time without t= aking=20 to account this Jitter? If so then doesn't this cause a problem, since the= =20 Jitter could be as much as 25% and this value is added on top of the networ= k=20 jitter.

Thanks,

Shahram

--_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D5EDSJEXCHCCR02co_-- From nitinb@juniper.net Fri Aug 14 14:40:11 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312BB3A6B92 for ; Fri, 14 Aug 2009 14:40:11 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCgX9hP2Phwx for ; Fri, 14 Aug 2009 14:40:10 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id A0F3F3A68C2 for ; Fri, 14 Aug 2009 14:40:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSoXZvYnN8/kpSKN9BtVa7ISR0JPlVM40@postini.com; Fri, 14 Aug 2009 14:40:14 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 14 Aug 2009 14:38:04 -0700 From: Nitin Bahadur To: Shahram Davari , "rtg-bfd@ietf.org" Date: Fri, 14 Aug 2009 14:37:53 -0700 Subject: RE: Induced Jitter Thread-Topic: Induced Jitter Thread-Index: AcodJX9fG4g5AFG+QgqXsTjcIKQyOQAAcdTA Message-ID: <05542EC42316164383B5180707A489EE1BA91139E3@EMBX02-HQ.jnpr.net> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5ED@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05542EC42316164383B5180707A489EE1BA91139E3EMBX02HQjnprn_" MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 21:40:11 -0000 --_000_05542EC42316164383B5180707A489EE1BA91139E3EMBX02HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Remote system is not aware of jitter. Application of jitter SHOULD NOT result in increase in send interval. So, if you the send interval is 1000ms and jitter is 25%, then you need to = send a packet every 750-1000 ms. Remote end does not take jitter into account when deducing it's detection t= ime. Thanks Nitin ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Shahram Davari Sent: Friday, August 14, 2009 2:24 PM To: rtg-bfd@ietf.org Subject: Induced Jitter Hi, When a local system applies Jitter to transmitted BFD control packets, is t= he remote system aware of the amount of this Jitter? or the remote bases it= s Detection time without taking to account this Jitter? If so then doesn't = this cause a problem, since the Jitter could be as much as 25% and this val= ue is added on top of the network jitter. Thanks, Shahram --_000_05542EC42316164383B5180707A489EE1BA91139E3EMBX02HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Remote system is not aware of jitter.

Application of jitter SHOULD NOT result in increase i= n send=20 interval.

So, if you the send interval is 1000ms and jitter is = 25%, then=20 you need to send a packet

every 750-1000 ms.

Remote end does not take jitter into account when ded= ucing=20 it's detection time.

Thanks
Nitin

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram=20 Davari
Sent: Friday, August 14, 2009 2:24 PM
To:=20 rtg-bfd@ietf.org
Subject: Induced Jitter

Hi,

When a = local=20 system applies Jitter to transmitted BFD control packets, is the remote s= ystem=20 aware of the amount of this Jitter? or the remote bases its Detection tim= e=20 without taking to account this Jitter? If so then doesn't this cause a=20 problem, since the Jitter could be as much as 25% and this value is added= on=20 top of the network jitter.

Thanks,

Shahram

--_000_05542EC42316164383B5180707A489EE1BA91139E3EMBX02HQjnprn_-- From davari@broadcom.com Fri Aug 14 15:49:47 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5443A6C04 for ; Fri, 14 Aug 2009 15:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc3H+jPvsPsM for ; Fri, 14 Aug 2009 15:49:46 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id B80433A68B1 for ; Fri, 14 Aug 2009 15:49:46 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 14 Aug 2009 15:49:36 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Fri, 14 Aug 2009 15:49:36 -0700 From: "Shahram Davari" To: "rtg-bfd@ietf.org" Date: Fri, 14 Aug 2009 15:49:35 -0700 Subject: DOWN state Thread-Topic: DOWN state Thread-Index: AcodMX6g43oi7O4qRoutvjtuAyhnGw== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 669B358A60079718249-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D601SJEXCHCCR02co_ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 22:49:47 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D601SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, The based draft sys that if BFD Control packet is not received during any D= etection Interval then the local system will go to Down state. I have two questions: 1) When can the local system transition out of Down state? Is it after rece= iving the first BFD packet with State=3DDOWN or INIT? or a number of such B= FD packets are required? in other words is there a Hysteresis? 2) Should the remote system apply a sliding window for Detection Time or f= ixed slotted windows that are not overlapped are acceptable? Thanks, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D601SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,

The based= draft sys=20 that if BFD Control packet is not received during any Detection Interval th= en=20 the local system will go to Down state.

I have tw= o=20 questions:

1) When c= an the=20 local system transition out of Down state? Is it after receiving the first = BFD=20 packet with State=3DDOWN or INIT? or a number of such BFD packets are requi= red? in=20 other words is there a Hysteresis?

2) S= hould=20 the remote system apply a sliding window for Detection Time= or=20 fixed slotted windows that are not overlapped are=20 acceptable?

Thanks,
Shahram

--_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D601SJEXCHCCR02co_-- From vishwas.ietf@gmail.com Fri Aug 14 16:29:25 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB8C3A6C2E for ; Fri, 14 Aug 2009 16:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwCp5UdLN+Lo for ; Fri, 14 Aug 2009 16:29:25 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 904D73A6B65 for ; Fri, 14 Aug 2009 16:28:54 -0700 (PDT) Received: by gxk17 with SMTP id 17so2304910gxk.19 for ; Fri, 14 Aug 2009 16:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4loGnXJ+OcVWgx+HP8t9ptDMyl/geRdece8K+36EcOs=; b=vpK7t7XvXHJXw49HJzzMa4yGd+NNS5YpFw7QyQN0g/lZiUUeYkUq2q8FsjywBbriKQ xruJgcefrYIh2X/i8uGDqXnlnnEcfOjWQl+c3MdKBmJGo5YYbpm6FnYRlDibPXH85Owx b5JHcjEXWUt6Ay6pVI+9Y0w2q25L7EuuwhZ/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Uzsp4sxM9Um9+uWp0gyY2WsB9QPC7esCwwbt3Z+PYtDFm1sfjGKKPcUkCgcnBgXlkM 6QRaEfseSxwVR97w0KIquiVAdGmzOUeySpio388gnY1vElz3dCp0NcfQCcmI8jyl33pV DnHr6ieTB9hzQQ55uhu7RwozYEQASo0f6HNLs= MIME-Version: 1.0 Received: by 10.150.114.9 with SMTP id m9mr3054726ybc.323.1250292534557; Fri, 14 Aug 2009 16:28:54 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5ED@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5ED@SJEXCHCCR02.corp.ad.broadcom.com> Date: Fri, 14 Aug 2009 16:28:54 -0700 Message-ID: <77ead0ec0908141628j6e0ec39r5e7b53f2710bc214@mail.gmail.com> Subject: Re: Induced Jitter From: Vishwas Manral To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 23:29:25 -0000 Hi Shahram, This was the exact issue I raised in BFD a few months back. Tat resulted in the spec being changed significantly. Look at the discussion here http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00570.html also look at the changes between the versions of the recent drafts. Thanks, Vishwas On Fri, Aug 14, 2009 at 2:23 PM, Shahram Davari wrote: > Hi, > > When a local system applies Jitter to transmitted BFD control packets, is > the remote system aware of the amount of this Jitter? or the remote bases > its Detection time without taking to account this Jitter? If so then doesn't > this cause a problem, since the Jitter could be as much as 25% and this > value is added on top of the network jitter. > > Thanks, > Shahram From vishwas.ietf@gmail.com Fri Aug 14 16:42:35 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EACB43A6B5D for ; Fri, 14 Aug 2009 16:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDgPLl+i6Sfn for ; Fri, 14 Aug 2009 16:42:35 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id C68143A67C1 for ; Fri, 14 Aug 2009 16:42:34 -0700 (PDT) Received: by ywh26 with SMTP id 26so2466231ywh.5 for ; Fri, 14 Aug 2009 16:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jwx/69a1e3vpqDLf4jGtDNGGM+IIFSe6Blcj9f31OEE=; b=JKF/LBrJmtXI3/LITLfnWmQ4Q+67GphEG/qnTCx+BL172VnAAlkuIZ5oWd9aWjGm5f a5+5UYekC1X7wMLEK364pFe4mTUgBjr1Go7SRfKDyA77G2w1E0volmQ9YUb9xcCCeUXj 5X14WowsRBMhLeo3CMoPQRvC87zIwKfhe8ts0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RrE9pzTzgrir63IC0TowdCwLxD5evePLdeqTSMXi35LgqqMrGwRG39/J/fsW2y8n3l Tm0i7lwxq23l3yDeMACAXXh/mf6BatXHNfk49umTwWIvKXevDPov/Yl4cbQyd/gK7YSK JhoQyVWkPjcRssPMoklYZzF5yOiRZQEFs1bK4= MIME-Version: 1.0 Received: by 10.150.217.14 with SMTP id p14mr3185259ybg.70.1250293356345; Fri, 14 Aug 2009 16:42:36 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> Date: Fri, 14 Aug 2009 16:42:36 -0700 Message-ID: <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> Subject: Re: DOWN state From: Vishwas Manral To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 23:42:36 -0000 Hi Saharam, On Fri, Aug 14, 2009 at 3:49 PM, Shahram Davari wrote: > Hi, > > The based draft sys that if BFD Control packet is not received during any > Detection Interval then the local system will go to Down state. > I have two questions: > > 1) When can the local system transition out of Down state? Is it after > receiving the first BFD packet with State=3DDOWN or INIT? or a number of = such > BFD packets are required? in other words is there a Hysteresis? No hysteresis is required as such. > 2)=A0Should the=A0remote system apply=A0=A0a sliding window for Detection= Time or > fixed slotted windows that are not overlapped are acceptable? What does the window contain? (I understand you are trying to do something similar to TCP). Are you using a mechanism like that for echo packets? Thanks, Vishwas From satyamsinha@live.com Fri Aug 14 16:47:08 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE893A6B79 for ; Fri, 14 Aug 2009 16:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.762 X-Spam-Level: X-Spam-Status: No, score=-99.762 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, SARE_UN7=0.917, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeHLqq2Kczqg for ; Fri, 14 Aug 2009 16:47:07 -0700 (PDT) Received: from bay0-omc3-s14.bay0.hotmail.com (bay0-omc3-s14.bay0.hotmail.com [65.54.246.214]) by core3.amsl.com (Postfix) with ESMTP id 640823A67C1 for ; Fri, 14 Aug 2009 16:47:07 -0700 (PDT) Received: from BAY117-W28 ([207.46.8.63]) by bay0-omc3-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 16:47:12 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_395bea94-9d63-4b61-9d57-018dd6ac3953_" X-Originating-IP: [64.47.51.158] From: Satyam Sinha To: , Subject: RE: Timer Manipulation Date: Fri, 14 Aug 2009 16:47:11 -0700 Importance: Normal In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Aug 2009 23:47:12.0762 (UTC) FILETIME=[8BB385A0:01CA1D39] X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 23:47:08 -0000 --_395bea94-9d63-4b61-9d57-018dd6ac3953_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Shahram=2C Clearly then we can't use the exact semantics that I suggested due to this = restriction. However=2C this statement allows an implied poll sequence whic= h the systems "MAY" implement. One example is=2C if a remote endpoint starts a poll sequence and sends out= poll packets P1=2C P2=2C P3 ... at the same time the parameters change at = the local endpoint and it sends out new parameters in F1 (Final packet resp= onding to P1)=2C F2 for P2 and so on. In such a case=2C ending of the poll = sequence (by receiving the first packet with P=3D0) is indication that the = parameters were accepted as the remote end as it must have received atleast= one of these final packets.=20 However=2C the same cannot be claimed if you start this process on F2 as th= e same cannot be claimed about the other end accepting these parameters as = the reset of poll bit could be due to the remote end receiving F1 packet. Implementations can choose to do this and regardless of the remote end impl= ementation this works fine. However=2C this is not mandatory.=20 Do you know of any case which may not work if someone implemented this "MAY= " ? Regards=2C Satyam From: davari@broadcom.com To: satyamsinha@live.com=3B rtg-bfd@ietf.org Date: Fri=2C 14 Aug 2009 14:14:28 -0700 Subject: RE: Timer Manipulation Hi=20 Satyam=2C =20 But=20 section 6.5 says " A BFD Control packet MUST NOT have=20 both the Poll (P) and Final (F) bits set.".=20 =20 Regards=2C Shahram From: Satyam Sinha [mailto:satyamsinha@live.com]=20 Sent: Friday=2C August 14=2C 2009 1:57 PM To: Shahram Davari=3B=20 rtg-bfd@ietf.org Subject: RE: Timer Manipulation Hi Shahram=2C The MAY here means that BFD allows an endpoint to=20 set both (P) and (F) bits together in the same packet. The endpoint "MAY"=20 initiate the poll sequence even while it is responding to a poll sequence. = It is=20 not mandatory for it to wait for the poll sequence to complete before initi= ating=20 it's own poll sequence. In case of change in local parameters while the=20 endpoint is receiving a poll sequence=2C the endpoint could either use new= =20 parameters and set both (P) & (F) bits or use old parameters with only the= =20 (F) bit set and then start a poll sequence following the final transmission= s. In=20 both cases the endpoint has to wait for a Final packet from the other=20 end. Regards=2C Satyam From: davari@broadcom.com To: rtg-bfd@ietf.org Date: Fri=2C 14 Aug 2009=20 12:44:24 -0700 Subject: Timer Manipulation Hi=2C =20 Section 6.8.3 of base=20 draft says : =20 "If either=20 bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed= =2C a=20 Poll Sequence MUST be initiated (see section 6.5). If the timing is such th= at a=20 system receiving a Poll Sequence wishes to change the parameters described = in=20 this paragraph=2C the new parameter values MAY be carried in packets with t= he=20 Final (F) bit set=2C even if the Poll Sequence has not yet been=20 sent." =20 It seems=20 that the above mentioned MAY requirement is not a good idea=2C because if a= =20 Poll receiver updates any parameter in the Final packet=2C then how can the= Poll=20 receiver verify that those Parameters are Received by the Poll sender?=20 =20 Regards=2C Shahram =20 Get your vacation photos on your phone! Click here. _________________________________________________________________ Get your vacation photos on your phone! http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=3D0809TL-HM= --_395bea94-9d63-4b61-9d57-018dd6ac3953_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Shahram=2C

Clearly then we can't use the exact semantics that I s= uggested due to this restriction. However=2C this statement allows an impli= ed poll sequence which the systems "MAY" implement.

One example is= =2C if a remote endpoint starts a poll sequence and sends out poll packets = P1=2C P2=2C P3 ... at the same time the parameters change at the local endp= oint and it sends out new parameters in F1 (Final packet responding to P1)= =2C F2 for P2 and so on. In such a case=2C ending of the poll sequence (by = receiving the first packet with P=3D0) is indication that the parameters we= re accepted as the remote end as it must have received atleast one of these= final packets.

However=2C the same cannot be claimed if you start = this process on F2 as the same cannot be claimed about the other end accept= ing these parameters as the reset of poll bit could be due to the remote en= d receiving F1 packet.

Implementations can choose to do this and reg= ardless of the remote end implementation this works fine. However=2C this i= s not mandatory.

Do you know of any case which may not work if some= one implemented this "MAY" ?

Regards=2C

Satyam

From: davari@broadcom.com
To: satyamsinha@live.com=3B = rtg-bfd@ietf.org
Date: Fri=2C 14 Aug 2009 14:14:28 -0700
Subject: RE:= Timer Manipulation

Hi=20 Satyam=2C

=3B

But=20 section =3B6.5 says " =3BA BFD Control packet MUS= T NOT have=20 both the Poll (P) and Final (F) bits set.".

=3B

Regards=2C

Shahram

From: Satyam Sinha [mailto:satyamsinha@live.co= m]=20
Sent: Friday=2C August 14=2C 2009 1:57 PM
To: Shahram = Davari=3B=20 rtg-bfd@ietf.org
Subject: RE: Timer Manipulation

Hi Shahram=2C

The MAY here means that BFD allows an endpo= int to=20 set both (P) and (F) bits together in the same packet. The endpoint "MAY"=20 initiate the poll sequence even while it is responding to a poll sequence. = It is=20 not mandatory for it to wait for the poll sequence to complete before initi= ating=20 it's own poll sequence.

In case of change in local parameters while = the=20 endpoint is receiving a poll sequence=2C the endpoint could either use new= =20 parameters and set both (P) &=3B (F) bits or use old parameters with onl= y the=20 (F) bit set and then start a poll sequence following the final transmission= s. In=20 both cases the endpoint has to wait for a Final packet from the other=20 end.

Regards=2C

Satyam

From: davari@broadcom.com
To: rtg-bfd@ietf.org
Date: Fri=2C 14 Aug 20= 09=20 12:44:24 -0700
Subject: Timer Manipulation

Hi=2C

<= /font> =3B

Section = 6.8.3 of base=20 draft says :

<= /font> =3B

"If either=20 bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed= =2C a=20 Poll Sequence MUST be initiated (see section 6.5). If the timing is such th= at a=20 system receiving a Poll Sequence wishes to change the parameters described = in=20 this paragraph=2C the new parameter values MAY be carried in packets with t= he=20 Final (F) bit set=2C even if the Poll Sequence has not yet been=20 sent."

=3B

It seems=20 that the above mentioned MAY requirement is not a good idea=2C because = =3Bif a=20 Poll receiver updates any parameter in the Final packet=2C then how can the= Poll=20 receiver verify that those Parameters are Received by the Poll sender?=20

=3B

Regards=2C

Shahram

=3B

Get your vacation photos on your phone! Click here.<= br />

Get your vacation photos on your phone! Click here. = --_395bea94-9d63-4b61-9d57-018dd6ac3953_-- From vishwas.ietf@gmail.com Fri Aug 14 16:50:59 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A47A3A6765 for ; Fri, 14 Aug 2009 16:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKQb4IhkuhTn for ; Fri, 14 Aug 2009 16:50:58 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 155A03A67C1 for ; Fri, 14 Aug 2009 16:50:58 -0700 (PDT) Received: by ywh26 with SMTP id 26so2470345ywh.5 for ; Fri, 14 Aug 2009 16:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xVkxVjAVnhq8cBiSwCmKZwgkHaaXN7Zoj/p9dhPQEtg=; b=UAze1dUi4gW0Mre/XkwniAnCGUriCiX9EgJisQ7yd5qjBTPcB18R9XlQYzewzPeNNd /HSdumeMCswElU/404Av0hygtpvIEFcnMjb/YdFbKrW5QbUROW5KugKHwaBfezZla7lE 4hvluk7tBf4DQcoomf9I4UTAkZ6LEp5NkNro0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KFVZEyWekG6NooFX0zELzNZBS0ZIqdMA/19eurMig3gP/QHPeI0YYiMiBkPuVVmQ81 X5VH5aEDul0Ik925eDYMUAUD4jw0X8svJWFO6quBwdL3G5kKtXQYgnqicVQQP8IIDDwz zZT1Z6tyc3qJbBf2ZH4BHJl4k2g4f4iD29X5A= MIME-Version: 1.0 Received: by 10.150.129.23 with SMTP id b23mr3047724ybd.175.1250293859041; Fri, 14 Aug 2009 16:50:59 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> Date: Fri, 14 Aug 2009 16:50:59 -0700 Message-ID: <77ead0ec0908141650w2034997fr4e6fc5a250376866@mail.gmail.com> Subject: Re: Timer Manipulation From: Vishwas Manral To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 23:50:59 -0000 Hi Shahram, If I understand you right, you are correct. I raised this issue on the list about what needs to be done when both sides change parameters symultaneously. It seems we will put this in a later version of the RFC. Thanks, Vishwas On Fri, Aug 14, 2009 at 2:14 PM, Shahram Davari wrote: > Hi Satyam, > > But section=A06.5 says "=A0A BFD Control packet MUST NOT have both the Po= ll (P) > and Final (F) bits set.". > > Regards, > Shahram > ________________________________ > From: Satyam Sinha [mailto:satyamsinha@live.com] > Sent: Friday, August 14, 2009 1:57 PM > To: Shahram Davari; rtg-bfd@ietf.org > Subject: RE: Timer Manipulation > > Hi Shahram, > > The MAY here means that BFD allows an endpoint to set both (P) and (F) bi= ts > together in the same packet. The endpoint "MAY" initiate the poll sequenc= e > even while it is responding to a poll sequence. It is not mandatory for i= t > to wait for the poll sequence to complete before initiating it's own poll > sequence. > > In case of change in local parameters while the endpoint is receiving a p= oll > sequence, the endpoint could either use new parameters and set both (P) & > (F) bits or use old parameters with only the (F) bit set and then start a > poll sequence following the final transmissions. In both cases the endpoi= nt > has to wait for a Final packet from the other end. > > Regards, > > Satyam > > ________________________________ > From: davari@broadcom.com > To: rtg-bfd@ietf.org > Date: Fri, 14 Aug 2009 12:44:24 -0700 > Subject: Timer Manipulation > > Hi, > > Section 6.8.3 of base draft says : > > "If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterv= al > is changed, a Poll Sequence MUST be initiated (see section 6.5). If the > timing is such that a system receiving a Poll Sequence wishes to change t= he > parameters described in this paragraph, the new parameter values MAY be > carried in packets with the Final (F) bit set, even if the Poll Sequence = has > not yet been sent." > > It seems that the above mentioned MAY requirement is not a good idea, > because=A0if a Poll receiver updates any parameter in the Final packet, t= hen > how can the Poll receiver verify that those Parameters are Received by th= e > Poll sender? > > Regards, > Shahram > > ________________________________ > Get your vacation photos on your phone! Click here. From davari@broadcom.com Fri Aug 14 17:00:37 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A74D3A6DBD for ; Fri, 14 Aug 2009 17:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_UN7=0.917] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nqvT2DkwTsZ for ; Fri, 14 Aug 2009 17:00:36 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 4AAF83A6D12 for ; Fri, 14 Aug 2009 17:00:36 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 14 Aug 2009 17:00:30 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Fri, 14 Aug 2009 17:00:30 -0700 From: "Shahram Davari" To: "Satyam Sinha" , "rtg-bfd@ietf.org" Date: Fri, 14 Aug 2009 17:00:28 -0700 Subject: RE: Timer Manipulation Thread-Topic: Timer Manipulation Thread-Index: AcodOZIU8/1UncOgRZm8uGI+xZ/4rAAAVe5w Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815050D60D@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 669B251437015925776-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D60DSJEXCHCCR02co_ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 00:00:37 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D60DSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Satyam, An example is if local systems is in demand mode and a single Poll sequence= is received from remote system. If the local system changes any value in t= he Final packet, it can't be sure that the remote system has received it. My be we should allow Poll =3D1 and F =3D1 in the same packet ! Regards, Shahram ________________________________ From: Satyam Sinha [mailto:satyamsinha@live.com] Sent: Friday, August 14, 2009 4:47 PM To: Shahram Davari; rtg-bfd@ietf.org Subject: RE: Timer Manipulation Hi Shahram, Clearly then we can't use the exact semantics that I suggested due to this = restriction. However, this statement allows an implied poll sequence which = the systems "MAY" implement. One example is, if a remote endpoint starts a poll sequence and sends out p= oll packets P1, P2, P3 ... at the same time the parameters change at the lo= cal endpoint and it sends out new parameters in F1 (Final packet responding= to P1), F2 for P2 and so on. In such a case, ending of the poll sequence (= by receiving the first packet with P=3D0) is indication that the parameters= were accepted as the remote end as it must have received atleast one of th= ese final packets. However, the same cannot be claimed if you start this process on F2 as the = same cannot be claimed about the other end accepting these parameters as th= e reset of poll bit could be due to the remote end receiving F1 packet. Implementations can choose to do this and regardless of the remote end impl= ementation this works fine. However, this is not mandatory. Do you know of any case which may not work if someone implemented this "MAY= " ? Regards, Satyam ________________________________ From: davari@broadcom.com To: satyamsinha@live.com; rtg-bfd@ietf.org Date: Fri, 14 Aug 2009 14:14:28 -0700 Subject: RE: Timer Manipulation Hi Satyam, But section 6.5 says " A BFD Control packet MUST NOT have both the Poll (P)= and Final (F) bits set.". Regards, Shahram ________________________________ From: Satyam Sinha [mailto:satyamsinha@live.com] Sent: Friday, August 14, 2009 1:57 PM To: Shahram Davari; rtg-bfd@ietf.org Subject: RE: Timer Manipulation Hi Shahram, The MAY here means that BFD allows an endpoint to set both (P) and (F) bits= together in the same packet. The endpoint "MAY" initiate the poll sequence= even while it is responding to a poll sequence. It is not mandatory for it= to wait for the poll sequence to complete before initiating it's own poll = sequence. In case of change in local parameters while the endpoint is receiving a pol= l sequence, the endpoint could either use new parameters and set both (P) &= (F) bits or use old parameters with only the (F) bit set and then start a = poll sequence following the final transmissions. In both cases the endpoint= has to wait for a Final packet from the other end. Regards, Satyam ________________________________ From: davari@broadcom.com To: rtg-bfd@ietf.org Date: Fri, 14 Aug 2009 12:44:24 -0700 Subject: Timer Manipulation Hi, Section 6.8.3 of base draft says : "If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval= is changed, a Poll Sequence MUST be initiated (see section 6.5). If the ti= ming is such that a system receiving a Poll Sequence wishes to change the p= arameters described in this paragraph, the new parameter values MAY be carr= ied in packets with the Final (F) bit set, even if the Poll Sequence has no= t yet been sent." It seems that the above mentioned MAY requirement is not a good idea, becau= se if a Poll receiver updates any parameter in the Final packet, then how c= an the Poll receiver verify that those Parameters are Received by the Poll = sender? Regards, Shahram ________________________________ Get your vacation photos on your phone! Click here. ________________________________ Get your vacation photos on your phone! Click here. --_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D60DSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi= =20 Satyam,

An= example is=20 if local systems is in demand mode and a single Poll sequence is recei= ved=20 from remote system. If the local system changes any value in the Final pack= et,=20 it can't be sure that the remote system has received it.

My= be we=20 should allow Poll =3D1 and F =3D1 in the same packet !

Regards,

Shahram

From: Satyam Sinha [mailto:satyamsinha@live.com]= =20
Sent: Friday, August 14, 2009 4:47 PM
To: Shahram Dava= ri;=20 rtg-bfd@ietf.org
Subject: RE: Timer Manipulation

Hi Shahram,

Clearly then we can't use the exact semantics= that=20 I suggested due to this restriction. However, this statement allows an impl= ied=20 poll sequence which the systems "MAY" implement.

One example is, if = a=20 remote endpoint starts a poll sequence and sends out poll packets P1, P2, P= 3 ...=20 at the same time the parameters change at the local endpoint and it sends o= ut=20 new parameters in F1 (Final packet responding to P1), F2 for P2 and so on. = In=20 such a case, ending of the poll sequence (by receiving the first packet wit= h=20 P=3D0) is indication that the parameters were accepted as the remote end as= it=20 must have received atleast one of these final packets.

However, the= same=20 cannot be claimed if you start this process on F2 as the same cannot be cla= imed=20 about the other end accepting these parameters as the reset of poll bit cou= ld be=20 due to the remote end receiving F1 packet.

Implementations can choos= e to=20 do this and regardless of the remote end implementation this works fine.=20 However, this is not mandatory.

Do you know of any case which may n= ot=20 work if someone implemented this "MAY" ?

Regards,

Satyam
<= BR>

From: davari@broadcom.com
To: satyamsinha@live.com; rtg-bfd@ietf.org
= Date:=20 Fri, 14 Aug 2009 14:14:28 -0700
Subject: RE: Timer Manipulation

Hi=20 Satyam,

But=20 section 6.5 says " A BFD Control packet MUST NOT = have=20 both the Poll (P) and Final (F) bits set.".

Regards,

Shahram

From: Satyam Sinha [mailto:satyamsinha@live.com]= =20
Sent: Friday, August 14, 2009 1:57 PM
To: Shahram Dava= ri;=20 rtg-bfd@ietf.org
Subject: RE: Timer Manipulation

From: davari@broadcom.com
To: rtg-bfd@ietf.org
Date: Fri, 14 Aug 2009= =20 12:44:24 -0700
Subject: Timer Manipulation

Hi,

Section 6.8.= 3 of base=20 draft says :

"If=20 either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is= =20 changed, a Poll Sequence MUST be initiated (see section 6.5). If the timing= is=20 such that a system receiving a Poll Sequence wishes to change the parameter= s=20 described in this paragraph, the new parameter values MAY be carried in pac= kets=20 with the Final (F) bit set, even if the Poll Sequence has not yet been=20 sent."

It=20 seems that the above mentioned MAY requirement is not a good idea,=20 because if a Poll receiver updates any parameter in the Final packet, = then=20 how can the Poll receiver verify that those Parameters are Received by the = Poll=20 sender?

Regards,

Shahram

Get your vacation photos on your phone! Click=20 here.

Get your vacation photos on your phone! Click here. --_000_2C2F1EBA8050E74EA81502D5740B4BD6815050D60DSJEXCHCCR02co_-- From satyamsinha@live.com Fri Aug 14 17:22:33 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAFBC3A6DC1 for ; Fri, 14 Aug 2009 17:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.112 X-Spam-Level: X-Spam-Status: No, score=-100.112 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_SORBS_WEB=0.619, SARE_UN7=0.917, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KEvsl5Yp61L for ; Fri, 14 Aug 2009 17:22:33 -0700 (PDT) Received: from bay0-omc3-s9.bay0.hotmail.com (bay0-omc3-s9.bay0.hotmail.com [65.54.246.209]) by core3.amsl.com (Postfix) with ESMTP id 016CD3A6D22 for ; Fri, 14 Aug 2009 17:22:32 -0700 (PDT) Received: from BAY117-W42 ([207.46.8.77]) by bay0-omc3-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 17:22:37 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_84eac0ae-cd00-4982-b1ee-5f643567f8a7_" X-Originating-IP: [64.47.51.158] From: Satyam Sinha To: Vishwas Manral , Subject: RE: DOWN state Date: Fri, 14 Aug 2009 17:22:37 -0700 Importance: Normal In-Reply-To: <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 15 Aug 2009 00:22:37.0406 (UTC) FILETIME=[7E1677E0:01CA1D3E] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 00:22:34 -0000 --_84eac0ae-cd00-4982-b1ee-5f643567f8a7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Shahram=2C Comments inline.... > Date: Fri=2C 14 Aug 2009 16:42:36 -0700 > Subject: Re: DOWN state > From: vishwas.ietf@gmail.com > To: davari@broadcom.com > CC: rtg-bfd@ietf.org >=20 > Hi Saharam=2C >=20 > On Fri=2C Aug 14=2C 2009 at 3:49 PM=2C Shahram Davari wrote: > > Hi=2C > > > > The based draft sys that if BFD Control packet is not received during a= ny > > Detection Interval then the local system will go to Down state. > > I have two questions: > > > > 1) When can the local system transition out of Down state? Is it after > > receiving the first BFD packet with State=3DDOWN or INIT? or a number o= f such > > BFD packets are required? in other words is there a Hysteresis? > No hysteresis is required as such. Any hysteresis would actually be a violation of the "Section 6.2 BFD state-= machine".=20 Down state means that the session is down (or has just been created.) A session remains in Down state until the remote system indicates that it agrees that the session is down by sending a BFD Control packet with the State field set to anything other than Up.>=20 > > 2) Should the remote system apply a sliding window for Detection Time = or > > fixed slotted windows that are not overlapped are acceptable? > What does the window contain? (I understand you are trying to do > something similar to TCP). Are you using a mechanism like that for > echo packets? >From a transmit perspective=2C if you take into account jitter=2C one shoul= d have the timers as sliding window based. One should schedule the next tra= nsmit at last-transmit-time + tx-timer (jittered) instead of expected-last-= transmit-time + tx-timer (jittered). The variance in the jitter alongwith s= lotted window usage between two transmits could cause the tx-time between t= wo packets to be more than the tx-timer. When the multiplier=3D1=2C such a = variance could make your session go down. >From a receive perspective you could do either. If you used slotted windows= =2C you might see more than one packet in a slot but you are still guarante= ed to see atleast one packet every slot. Regards=2C Satyam _________________________________________________________________ Get your vacation photos on your phone! http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=3D0809TL-HM= --_84eac0ae-cd00-4982-b1ee-5f643567f8a7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Shahram=2C

Comments inline....

>=3B Date: Fri=2C 14 Aug = 2009 16:42:36 -0700
>=3B Subject: Re: DOWN state
>=3B From: vishw= as.ietf@gmail.com
>=3B To: davari@broadcom.com
>=3B CC: rtg-bfd@i= etf.org
>=3B
>=3B Hi Saharam=2C
>=3B
>=3B On Fri=2C A= ug 14=2C 2009 at 3:49 PM=2C Shahram Davari<=3Bdavari@broadcom.com>=3B w= rote:
>=3B >=3B Hi=2C
>=3B >=3B
>=3B >=3B The based dr= aft sys that if BFD Control packet is not received during any
>=3B >= =3B Detection Interval then the local system will go to Down state.
>= =3B >=3B I have two questions:
>=3B >=3B
>=3B >=3B 1) When = can the local system transition out of Down state? Is it after
>=3B &g= t=3B receiving the first BFD packet with State=3DDOWN or INIT? or a number = of such
>=3B >=3B BFD packets are required? in other words is there = a Hysteresis?
>=3B No hysteresis is required as such.

Any hyste= resis would actually be a violation of the "Section 6.2 BFD state-machine".=

Down state means that the session is down (or h=
as just been created.)
   A session remains in Down state until the remo=
te system indicates
   that it agrees that the session is down by sendin=
g a BFD Control
   packet with the State field set to anything other tha=
n Up.

>=3B
>=3B >=3B 2) =3BShould the =3Bremote syst= em apply =3B =3Ba sliding window for Detection Time or
>=3B &g= t=3B fixed slotted windows that are not overlapped are acceptable?
>= =3B What does the window contain? (I understand you are trying to do
>= =3B something similar to TCP). Are you using a mechanism like that for
&= gt=3B echo packets?

From a transmit perspective=2C if you take into = account jitter=2C one should have the timers as sliding window based. One s= hould schedule the next transmit at last-transmit-time + tx-timer (jittered= ) instead of expected-last-transmit-time + tx-timer (jittered). The varianc= e in the jitter alongwith slotted window usage between two transmits could = cause the tx-time between two packets to be more than the tx-timer. When th= e multiplier=3D1=2C such a variance could make your session go down.
From a receive perspective you could do either. If you used slotted window= s=2C you might see more than one packet in a slot but you are still guarant= eed to see atleast one packet every slot.

Regards=2C

Satyam

Get your vacation photos on your phone! Click here. = --_84eac0ae-cd00-4982-b1ee-5f643567f8a7_-- From satyamsinha@live.com Fri Aug 14 17:42:38 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A5728C1E5 for ; Fri, 14 Aug 2009 17:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.529 X-Spam-Level: X-Spam-Status: No, score=-100.529 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, SARE_UN7=0.917, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq8RMdGfJGzV for ; Fri, 14 Aug 2009 17:42:36 -0700 (PDT) Received: from bay0-omc3-s30.bay0.hotmail.com (bay0-omc3-s30.bay0.hotmail.com [65.54.246.230]) by core3.amsl.com (Postfix) with ESMTP id 95D943A6D12 for ; Fri, 14 Aug 2009 17:42:36 -0700 (PDT) Received: from BAY117-W39 ([207.46.8.74]) by bay0-omc3-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 17:42:42 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_0634e907-bda0-41cf-800a-3fc4bccee766_" X-Originating-IP: [64.47.51.158] From: Satyam Sinha To: , Subject: RE: Timer Manipulation Date: Fri, 14 Aug 2009 17:42:41 -0700 Importance: Normal In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D60D@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D60D@SJEXCHCCR02.corp.ad.broadcom.com> MIME-Version: 1.0 X-OriginalArrivalTime: 15 Aug 2009 00:42:42.0037 (UTC) FILETIME=[4C1A9250:01CA1D41] X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 00:42:38 -0000 --_0634e907-bda0-41cf-800a-3fc4bccee766_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All=2C Do we know what breaks if we allow P=3D1 and F=3D1 in same packet ? Hi Shahram=2C A few thoughts here. While running BFD between highly responsive systems wh= ich are connected with high bandwidth low latency links at even low timers = like 50ms=2C a poll mode on the wire looks like one end sending a poll pack= et and the other responding with a final packet. In such a case=2C if the s= ystem wants to implement the case that I suggested=2C should that be disall= owed ?=20 I agree that it does not work in some other cases=2C including the case tha= t you mentioned and so we shouldn't use it there. This is exactly what the "MAY" allows. There is an implied poll mode that w= orks here and if one cares to add a lot of complexity to your implementatio= n then that should be optional and not disallowed. Regards=2C Satyam From: davari@broadcom.com To: satyamsinha@live.com=3B rtg-bfd@ietf.org Date: Fri=2C 14 Aug 2009 17:00:28 -0700 Subject: RE: Timer Manipulation Hi=20 Satyam=2C =20 An example is=20 if local systems is in demand mode and a single Poll sequence is received=20 from remote system. If the local system changes any value in the Final pack= et=2C=20 it can't be sure that the remote system has received it. =20 My be we=20 should allow Poll =3D1 and F =3D1 in the same packet ! =20 Regards=2C Shahram From: Satyam Sinha [mailto:satyamsinha@live.com]=20 Sent: Friday=2C August 14=2C 2009 4:47 PM To: Shahram Davari=3B=20 rtg-bfd@ietf.org Subject: RE: Timer Manipulation Hi Shahram=2C Clearly then we can't use the exact semantics that=20 I suggested due to this restriction. However=2C this statement allows an im= plied=20 poll sequence which the systems "MAY" implement. One example is=2C if a=20 remote endpoint starts a poll sequence and sends out poll packets P1=2C P2= =2C P3 ...=20 at the same time the parameters change at the local endpoint and it sends o= ut=20 new parameters in F1 (Final packet responding to P1)=2C F2 for P2 and so on= . In=20 such a case=2C ending of the poll sequence (by receiving the first packet w= ith=20 P=3D0) is indication that the parameters were accepted as the remote end as= it=20 must have received atleast one of these final packets.=20 However=2C the same=20 cannot be claimed if you start this process on F2 as the same cannot be cla= imed=20 about the other end accepting these parameters as the reset of poll bit cou= ld be=20 due to the remote end receiving F1 packet. Implementations can choose to=20 do this and regardless of the remote end implementation this works fine.=20 However=2C this is not mandatory.=20 Do you know of any case which may not=20 work if someone implemented this "MAY" ? Regards=2C Satyam From: davari@broadcom.com To: satyamsinha@live.com=3B rtg-bfd@ietf.org Date:=20 Fri=2C 14 Aug 2009 14:14:28 -0700 Subject: RE: Timer Manipulation Hi=20 Satyam=2C =20 But=20 section 6.5 says " A BFD Control packet MUST NOT have=20 both the Poll (P) and Final (F) bits set.".=20 =20 Regards=2C Shahram From: Satyam Sinha [mailto:satyamsinha@live.com]=20 Sent: Friday=2C August 14=2C 2009 1:57 PM To: Shahram Davari=3B=20 rtg-bfd@ietf.org Subject: RE: Timer Manipulation Hi Shahram=2C The MAY here means that BFD allows an endpoint to=20 set both (P) and (F) bits together in the same packet. The endpoint "MAY"=20 initiate the poll sequence even while it is responding to a poll sequence. = It is=20 not mandatory for it to wait for the poll sequence to complete before initi= ating=20 it's own poll sequence. In case of change in local parameters while the=20 endpoint is receiving a poll sequence=2C the endpoint could either use new= =20 parameters and set both (P) & (F) bits or use old parameters with only the= =20 (F) bit set and then start a poll sequence following the final transmission= s. In=20 both cases the endpoint has to wait for a Final packet from the other=20 end. Regards=2C Satyam From: davari@broadcom.com To: rtg-bfd@ietf.org Date: Fri=2C 14 Aug 2009=20 12:44:24 -0700 Subject: Timer Manipulation Hi=2C =20 Section 6.8.3 of base=20 draft says : =20 "If=20 either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is= =20 changed=2C a Poll Sequence MUST be initiated (see section 6.5). If the timi= ng is=20 such that a system receiving a Poll Sequence wishes to change the parameter= s=20 described in this paragraph=2C the new parameter values MAY be carried in p= ackets=20 with the Final (F) bit set=2C even if the Poll Sequence has not yet been=20 sent." =20 It=20 seems that the above mentioned MAY requirement is not a good idea=2C=20 because if a Poll receiver updates any parameter in the Final packet=2C the= n=20 how can the Poll receiver verify that those Parameters are Received by the = Poll=20 sender?=20 =20 Regards=2C Shahram =20 Get your vacation photos on your phone! Click=20 here. Get your vacation photos on your phone! Click here. _________________________________________________________________ Express your personality in color! Preview and select themes for Hotmail=AE= .=20 http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=3DPID233= 91::T:WLMTAGL:ON:WL:en-US:WM_HYGN_express:082009= --_0634e907-bda0-41cf-800a-3fc4bccee766_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All=2C

Do we know what breaks if we allow P=3D1 and F=3D1 in same= packet ?

Hi Shahram=2C

A few thoughts here. While running BF= D between highly responsive systems which are connected with high bandwidth= low latency links at even low timers like 50ms=2C a poll mode on the wire = looks like one end sending a poll packet and the other responding with a fi= nal packet. In such a case=2C if the system wants to implement the case tha= t I suggested=2C should that be disallowed ?

I agree that it does n= ot work in some other cases=2C including the case that you mentioned and so= we shouldn't use it there.

This is exactly what the "MAY" allows. T= here is an implied poll mode that works here and if one cares to add a lot = of complexity to your implementation then that should be optional and not d= isallowed.

Regards=2C

Satyam

F= rom: davari@broadcom.com
To: satyamsinha@live.com=3B rtg-bfd@ietf.orgDate: Fri=2C 14 Aug 2009 17:00:28 -0700
Subject: RE: Timer Manipulation=

Hi=20 Satyam=2C

=3B

An example is=20 if local systems =3Bis in demand mode and a single Poll sequence is rec= eived=20 from remote system. If the local system changes any value in the Final pack= et=2C=20 it can't be sure that the remote system has received it.

=3B

My be we=20 should allow Poll =3D1 and F =3D1 in the same packet !

=3B

Regards=2C

Shahram

From: Satyam Sinha [mailto:satyamsinha@live.co= m]=20
Sent: Friday=2C August 14=2C 2009 4:47 PM
To: Shahram = Davari=3B=20 rtg-bfd@ietf.org
Subject: RE: Timer Manipulation

Hi Shahram=2C

Clearly then we can't use the exact semanti= cs that=20 I suggested due to this restriction. However=2C this statement allows an im= plied=20 poll sequence which the systems "MAY" implement.

One example is=2C i= f a=20 remote endpoint starts a poll sequence and sends out poll packets P1=2C P2= =2C P3 ...=20 at the same time the parameters change at the local endpoint and it sends o= ut=20 new parameters in F1 (Final packet responding to P1)=2C F2 for P2 and so on= . In=20 such a case=2C ending of the poll sequence (by receiving the first packet w= ith=20 P=3D0) is indication that the parameters were accepted as the remote end as= it=20 must have received atleast one of these final packets.

However=2C t= he same=20 cannot be claimed if you start this process on F2 as the same cannot be cla= imed=20 about the other end accepting these parameters as the reset of poll bit cou= ld be=20 due to the remote end receiving F1 packet.

Implementations can choos= e to=20 do this and regardless of the remote end implementation this works fine.=20 However=2C this is not mandatory.

Do you know of any case which may= not=20 work if someone implemented this "MAY" ?

Regards=2C

Satyam

From: davari@broadcom.com
To: satyamsinha@live.com=3B rtg-bfd@ietf.orgDate:=20 Fri=2C 14 Aug 2009 14:14:28 -0700
Subject: RE: Timer Manipulation

Hi=20 Satyam=2C

=3B

But=20 section =3B6.5 says " =3BA BFD Control packet MUS= T NOT have=20 both the Poll (P) and Final (F) bits set.".

=3B

Regards=2C

Shahram

From: Satyam Sinha [mailto:satyamsinha@live.co= m]=20
Sent: Friday=2C August 14=2C 2009 1:57 PM
To: Shahram = Davari=3B=20 rtg-bfd@ietf.org
Subject: RE: Timer Manipulation

From: davari@broadcom.com
To: rtg-bfd@ietf.org
Date: Fri=2C 14 Aug 20= 09=20 12:44:24 -0700
Subject: Timer Manipulation

Hi=2C=

=3B

Secti= on 6.8.3 of base=20 draft says :

=3B

"If=20 either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is= =20 changed=2C a Poll Sequence MUST be initiated (see section 6.5). If the timi= ng is=20 such that a system receiving a Poll Sequence wishes to change the parameter= s=20 described in this paragraph=2C the new parameter values MAY be carried in p= ackets=20 with the Final (F) bit set=2C even if the Poll Sequence has not yet been=20 sent."

=3B

It=20 seems that the above mentioned MAY requirement is not a good idea=2C=20 because =3Bif a Poll receiver updates any parameter in the Final packet= =2C then=20 how can the Poll receiver verify that those Parameters are Received by the = Poll=20 sender?

=3B

Regards=2C

Shahram

=3B

Get your vacation photos on your phone! Click=20 here.

Get your vacation photos on your phone! Click here.<= br />

Express your personality in color! Preview and select themes for= Hotmail=AE. Try it now. = --_0634e907-bda0-41cf-800a-3fc4bccee766_-- From vishwas.ietf@gmail.com Fri Aug 14 17:54:26 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7A43A6D12 for ; Fri, 14 Aug 2009 17:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgrvmK3IEcaF for ; Fri, 14 Aug 2009 17:54:25 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 3C00B28B23E for ; Fri, 14 Aug 2009 17:54:24 -0700 (PDT) Received: by gxk17 with SMTP id 17so2342398gxk.19 for ; Fri, 14 Aug 2009 17:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cizv5XP0vo37EWzebwxGiZLgtMGcanikq4DA8PJWy2M=; b=EsTrQM7wZZyl7rHhorV6gAwHSxc9om3YiFN9Ism56keXkjtnmF+lMgQ1u1gs+p0BcI V4Ss4aFfin5y3qi762J9ci3Qv43nWiP4un1EmT61EKa1xnW149MRQS0QRXIMiOnNf91R nX0Br7CVZF3skSzfkXcvWBcFZFkZkyyw0Tmkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dXc296fP4a3qGMpNwwSYzNwprCv+fJKn4BkxtfDRyIVgPaFAk6JcfRkz6KdYRN04IF pzxDah9rlxorwOJzovhJTYfdW1vfzEgz7HMyZbXBlOUiEDLHPmn29jIQip7qfUISumGI jZ36l2yfLswxvlgMfDpNIFi3vnwrZVEswy4s4= MIME-Version: 1.0 Received: by 10.150.132.9 with SMTP id f9mr3096327ybd.348.1250297662678; Fri, 14 Aug 2009 17:54:22 -0700 (PDT) In-Reply-To: References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D60D@SJEXCHCCR02.corp.ad.broadcom.com> Date: Fri, 14 Aug 2009 17:54:22 -0700 Message-ID: <77ead0ec0908141754y148e0fe6w94e599dbbe59de3f@mail.gmail.com> Subject: Re: Timer Manipulation From: Vishwas Manral To: Satyam Sinha Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 00:54:26 -0000 Hi Shahram, This is the same issue I have raised earlier: http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00583.html Like I said it was determined that all similar leaks in the spec will be fixed later. Thanks, Vishwas On Fri, Aug 14, 2009 at 5:42 PM, Satyam Sinha wrote: > Hi All, > > Do we know what breaks if we allow P=3D1 and F=3D1 in same packet ? > > Hi Shahram, > > A few thoughts here. While running BFD between highly responsive systems > which are connected with high bandwidth low latency links at even low tim= ers > like 50ms, a poll mode on the wire looks like one end sending a poll pack= et > and the other responding with a final packet. In such a case, if the syst= em > wants to implement the case that I suggested, should that be disallowed ? > > I agree that it does not work in some other cases, including the case tha= t > you mentioned and so we shouldn't use it there. > > This is exactly what the "MAY" allows. There is an implied poll mode that > works here and if one cares to add a lot of complexity to your > implementation then that should be optional and not disallowed. > > Regards, > > Satyam > > ________________________________ > From: davari@broadcom.com > To: satyamsinha@live.com; rtg-bfd@ietf.org > Date: Fri, 14 Aug 2009 17:00:28 -0700 > Subject: RE: Timer Manipulation > > Hi Satyam, > > An example is if local systems=A0is in demand mode and a single Poll sequ= ence > is received from remote system. If the local system changes any value in = the > Final packet, it can't be sure that the remote system has received it. > > My be we should allow Poll =3D1 and F =3D1 in the same packet ! > > Regards, > Shahram > ________________________________ > From: Satyam Sinha [mailto:satyamsinha@live.com] > Sent: Friday, August 14, 2009 4:47 PM > To: Shahram Davari; rtg-bfd@ietf.org > Subject: RE: Timer Manipulation > > Hi Shahram, > > Clearly then we can't use the exact semantics that I suggested due to thi= s > restriction. However, this statement allows an implied poll sequence whic= h > the systems "MAY" implement. > > One example is, if a remote endpoint starts a poll sequence and sends out > poll packets P1, P2, P3 ... at the same time the parameters change at the > local endpoint and it sends out new parameters in F1 (Final packet > responding to P1), F2 for P2 and so on. In such a case, ending of the pol= l > sequence (by receiving the first packet with P=3D0) is indication that th= e > parameters were accepted as the remote end as it must have received atlea= st > one of these final packets. > > However, the same cannot be claimed if you start this process on F2 as th= e > same cannot be claimed about the other end accepting these parameters as = the > reset of poll bit could be due to the remote end receiving F1 packet. > > Implementations can choose to do this and regardless of the remote end > implementation this works fine. However, this is not mandatory. > > Do you know of any case which may not work if someone implemented this "M= AY" > ? > > Regards, > > Satyam > > ________________________________ > From: davari@broadcom.com > To: satyamsinha@live.com; rtg-bfd@ietf.org > Date: Fri, 14 Aug 2009 14:14:28 -0700 > Subject: RE: Timer Manipulation > > Hi Satyam, > > But section=A06.5 says "=A0A BFD Control packet MUST NOT have both the Po= ll (P) > and Final (F) bits set.". > > Regards, > Shahram > ________________________________ > From: Satyam Sinha [mailto:satyamsinha@live.com] > Sent: Friday, August 14, 2009 1:57 PM > To: Shahram Davari; rtg-bfd@ietf.org > Subject: RE: Timer Manipulation > > Hi Shahram, > > The MAY here means that BFD allows an endpoint to set both (P) and (F) bi= ts > together in the same packet. The endpoint "MAY" initiate the poll sequenc= e > even while it is responding to a poll sequence. It is not mandatory for i= t > to wait for the poll sequence to complete before initiating it's own poll > sequence. > > In case of change in local parameters while the endpoint is receiving a p= oll > sequence, the endpoint could either use new parameters and set both (P) & > (F) bits or use old parameters with only the (F) bit set and then start a > poll sequence following the final transmissions. In both cases the endpoi= nt > has to wait for a Final packet from the other end. > > Regards, > > Satyam > > ________________________________ > From: davari@broadcom.com > To: rtg-bfd@ietf.org > Date: Fri, 14 Aug 2009 12:44:24 -0700 > Subject: Timer Manipulation > > Hi, > > Section 6.8.3 of base draft says : > > "If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterv= al > is changed, a Poll Sequence MUST be initiated (see section 6.5). If the > timing is such that a system receiving a Poll Sequence wishes to change t= he > parameters described in this paragraph, the new parameter values MAY be > carried in packets with the Final (F) bit set, even if the Poll Sequence = has > not yet been sent." > > It seems that the above mentioned MAY requirement is not a good idea, > because=A0if a Poll receiver updates any parameter in the Final packet, t= hen > how can the Poll receiver verify that those Parameters are Received by th= e > Poll sender? > > Regards, > Shahram > > ________________________________ > Get your vacation photos on your phone! Click here. > ________________________________ > Get your vacation photos on your phone! Click here. > ________________________________ > Express your personality in color! Preview and select themes for Hotmail= =AE. > Try it now. From dkatz@juniper.net Sat Aug 15 15:28:29 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F31C3A6BC2 for ; Sat, 15 Aug 2009 15:28:29 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-OyyWlOSuMg for ; Sat, 15 Aug 2009 15:28:28 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 6F5EF3A69F7 for ; Sat, 15 Aug 2009 15:28:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSoc2kEnv0QPszixRiv1rV0TJtWRFfpKB@postini.com; Sat, 15 Aug 2009 15:28:33 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 15 Aug 2009 15:26:50 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:26:51 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:26:50 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:26:49 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7FMQn012914; Sat, 15 Aug 2009 15:26:49 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <2C4CCEED-9A28-48D2-A067-0AF6666BDB9F@juniper.net> From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="Apple-Mail-1--662415011" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Timer Manipulation Date: Sat, 15 Aug 2009 16:26:48 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Aug 2009 22:26:49.0723 (UTC) FILETIME=[7B5BECB0:01CA1DF7] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 22:28:29 -0000 --Apple-Mail-1--662415011 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 14, 2009, at 1:44 PM, Shahram Davari wrote: > Hi, > > Section 6.8.3 of base draft says : > > "If either bfd.DesiredMinTxInterval is changed or > bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be > initiated (see section 6.5). If the timing is such that a system > receiving a Poll Sequence wishes to change the parameters described > in this paragraph, the new parameter values MAY be carried in > packets with the Final (F) bit set, even if the Poll Sequence has > not yet been sent." > > It seems that the above mentioned MAY requirement is not a good > idea, because if a Poll receiver updates any parameter in the Final > packet, then how can the Poll receiver verify that those Parameters > are Received by the Poll sender? The text does not relieve the sender of the requirement to send a Poll Sequence in the other direction (thus the MUST). It simply means that if the local side has just changed its parameters, it may include them in the Final packet being sent (so it doesn't have to send the old values.) The local side then must send a Poll with the new values as per spec, and wait to change timers or whatever. --Dave --Apple-Mail-1--662415011 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

On Aug 14, 2009, = at 1:44 PM, Shahram Davari wrote:

=
Hi,

Section = 6.8.3 of base draft says :

=
"If either = bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is = changed, a Poll Sequence MUST be initiated (see section 6.5). If the = timing is such that a system receiving a Poll Sequence wishes to change = the parameters described in this paragraph, the new parameter values MAY = be carried in packets with the Final (F) bit set, even if the Poll = Sequence has not yet been sent."

It seems = that the above mentioned MAY requirement is not a good idea, = because if a Poll receiver updates any parameter in the Final = packet, then how can the Poll receiver verify that those Parameters are = Received by the Poll sender? =

The text = does not relieve the sender of the requirement to send a Poll Sequence = in the other direction (thus the MUST). It simply means that if = the local side has just changed its parameters, it may include them in = the Final packet being sent (so it doesn't have to send the old values.) = The local side then must send a Poll with the new values as per = spec, and wait to change timers or = whatever.

--Dave

= --Apple-Mail-1--662415011-- From dkatz@juniper.net Sat Aug 15 15:31:30 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326623A69F7 for ; Sat, 15 Aug 2009 15:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6DeifVuZGLa for ; Sat, 15 Aug 2009 15:31:29 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 3509B3A6A12 for ; Sat, 15 Aug 2009 15:31:29 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSoc3RVFVWNQb0z+4X7AqEFr2ddP5LQbV@postini.com; Sat, 15 Aug 2009 15:31:34 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 15 Aug 2009 15:29:52 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:29:52 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:29:52 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:29:51 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7FMTo012958; Sat, 15 Aug 2009 15:29:50 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <42D8C149-0B93-4D34-A246-0E2EFBAA5CD5@juniper.net> From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5ED@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="Apple-Mail-3--662232786" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Induced Jitter Date: Sat, 15 Aug 2009 16:29:50 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5ED@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Aug 2009 22:29:51.0186 (UTC) FILETIME=[E784FB20:01CA1DF7] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 22:31:30 -0000 --Apple-Mail-3--662232786 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 14, 2009, at 3:23 PM, Shahram Davari wrote: > Hi, > > When a local system applies Jitter to transmitted BFD control > packets, is the remote system aware of the amount of this Jitter? or > the remote bases its Detection time without taking to account this > Jitter? If so then doesn't this cause a problem, since the Jitter > could be as much as 25% and this value is added on top of the > network jitter. Jitter is always *subtracted.* I believe the text is clear on this. The receiving end neither knows nor cares; it calculates the Detection Time based on the parameters and times out. All that the jitter does is raise the frequency of received packets by an average of 12.5%, which provides more robustness rather than less. --Dave --Apple-Mail-3--662232786 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

On Aug 14, 2009, = at 3:23 PM, Shahram Davari wrote:

=
Hi,

When a = local system applies Jitter to transmitted BFD control packets, is the = remote system aware of the amount of this Jitter? or the remote bases = its Detection time without taking to account this Jitter? If so then = doesn't this cause a problem, since the Jitter could be as much as 25% = and this value is added on top of the network = jitter.

Jitter is = always *subtracted.* I believe the text is clear on = this.

The receiving end neither knows nor = cares; it calculates the Detection Time based on the parameters = and times out. All that the jitter does is raise the frequency of = received packets by an average of 12.5%, which provides more robustness = rather than = less.

--Dave

= --Apple-Mail-3--662232786-- From dkatz@juniper.net Sat Aug 15 15:41:31 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B933A688F for ; Sat, 15 Aug 2009 15:41:31 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k3yvxnlc+vM for ; Sat, 15 Aug 2009 15:41:27 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 76B443A67A8 for ; Sat, 15 Aug 2009 15:41:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSoc5m8sW00WEDak66mXAAaa9gwh6FnAa@postini.com; Sat, 15 Aug 2009 15:41:32 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 15 Aug 2009 15:40:01 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:40:01 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:40:00 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:40:00 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7FMe0013214; Sat, 15 Aug 2009 15:40:00 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <9503526F-9AE4-4C80-A0C4-A69809C2F353@juniper.net> From: Dave Katz To: Vishwas Manral In-Reply-To: <77ead0ec0908141650w2034997fr4e6fc5a250376866@mail.gmail.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Timer Manipulation Date: Sat, 15 Aug 2009 16:39:59 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908141650w2034997fr4e6fc5a250376866@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Aug 2009 22:40:00.0526 (UTC) FILETIME=[52B6E2E0:01CA1DF9] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 22:41:35 -0000 I believe the spec is clear--it is a MUST that the end changing parameters sends a Poll Sequence (and also a MUST that P and F not be set simultaneously.) It is a MAY that the new parameters are carried in F packets so that the old values don't have to be kept around (it doesn't hurt anything.) Do what it says, and it works. I don't see that this requires any further text in the spec. --Dave On Aug 14, 2009, at 5:50 PM, Vishwas Manral wrote: > Hi Shahram, > > If I understand you right, you are correct. I raised this issue on the > list about what needs to be done when both sides change parameters > symultaneously. > > It seems we will put this in a later version of the RFC. > > Thanks, > Vishwas > > On Fri, Aug 14, 2009 at 2:14 PM, Shahram Davari > wrote: >> Hi Satyam, >> >> But section 6.5 says " A BFD Control packet MUST NOT have both the >> Poll (P) >> and Final (F) bits set.". >> >> Regards, >> Shahram >> ________________________________ >> From: Satyam Sinha [mailto:satyamsinha@live.com] >> Sent: Friday, August 14, 2009 1:57 PM >> To: Shahram Davari; rtg-bfd@ietf.org >> Subject: RE: Timer Manipulation >> >> Hi Shahram, >> >> The MAY here means that BFD allows an endpoint to set both (P) and >> (F) bits >> together in the same packet. The endpoint "MAY" initiate the poll >> sequence >> even while it is responding to a poll sequence. It is not mandatory >> for it >> to wait for the poll sequence to complete before initiating it's >> own poll >> sequence. >> >> In case of change in local parameters while the endpoint is >> receiving a poll >> sequence, the endpoint could either use new parameters and set both >> (P) & >> (F) bits or use old parameters with only the (F) bit set and then >> start a >> poll sequence following the final transmissions. In both cases the >> endpoint >> has to wait for a Final packet from the other end. >> >> Regards, >> >> Satyam >> >> ________________________________ >> From: davari@broadcom.com >> To: rtg-bfd@ietf.org >> Date: Fri, 14 Aug 2009 12:44:24 -0700 >> Subject: Timer Manipulation >> >> Hi, >> >> Section 6.8.3 of base draft says : >> >> "If either bfd.DesiredMinTxInterval is changed or >> bfd.RequiredMinRxInterval >> is changed, a Poll Sequence MUST be initiated (see section 6.5). If >> the >> timing is such that a system receiving a Poll Sequence wishes to >> change the >> parameters described in this paragraph, the new parameter values >> MAY be >> carried in packets with the Final (F) bit set, even if the Poll >> Sequence has >> not yet been sent." >> >> It seems that the above mentioned MAY requirement is not a good idea, >> because if a Poll receiver updates any parameter in the Final >> packet, then >> how can the Poll receiver verify that those Parameters are Received >> by the >> Poll sender? >> >> Regards, >> Shahram >> >> ________________________________ >> Get your vacation photos on your phone! Click here. > > From dkatz@juniper.net Sat Aug 15 15:41:50 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91DA3A6AF5 for ; Sat, 15 Aug 2009 15:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_UN7=0.917] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5lc1AcC+U+W for ; Sat, 15 Aug 2009 15:41:49 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 288893A67A8 for ; Sat, 15 Aug 2009 15:41:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSoc5sHbemzuWZ+cY9shWPzSivy8aSLqj@postini.com; Sat, 15 Aug 2009 15:41:54 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 15 Aug 2009 15:40:26 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:40:26 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:40:25 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:40:25 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7FMeO013224; Sat, 15 Aug 2009 15:40:24 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <4F88D30E-9AB4-4019-B67D-18CB7C9B88BF@juniper.net> From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D60D@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="Apple-Mail-4--661599390" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Timer Manipulation Date: Sat, 15 Aug 2009 16:40:23 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D60D@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Aug 2009 22:40:25.0031 (UTC) FILETIME=[61520D70:01CA1DF9] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 22:41:50 -0000 --Apple-Mail-4--661599390 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 14, 2009, at 6:00 PM, Shahram Davari wrote: > Hi Satyam, > > An example is if local systems is in demand mode and a single Poll > sequence is received from remote system. If the local system changes > any value in the Final packet, it can't be sure that the remote > system has received it. > > My be we should allow Poll =1 and F =1 in the same packet ! No, it just sends its own poll sequence as required by the spec. --Dave > > Regards, > Shahram > > From: Satyam Sinha [mailto:satyamsinha@live.com] > Sent: Friday, August 14, 2009 4:47 PM > To: Shahram Davari; rtg-bfd@ietf.org > Subject: RE: Timer Manipulation > > Hi Shahram, > > Clearly then we can't use the exact semantics that I suggested due > to this restriction. However, this statement allows an implied poll > sequence which the systems "MAY" implement. > > One example is, if a remote endpoint starts a poll sequence and > sends out poll packets P1, P2, P3 ... at the same time the > parameters change at the local endpoint and it sends out new > parameters in F1 (Final packet responding to P1), F2 for P2 and so > on. In such a case, ending of the poll sequence (by receiving the > first packet with P=0) is indication that the parameters were > accepted as the remote end as it must have received atleast one of > these final packets. > > However, the same cannot be claimed if you start this process on F2 > as the same cannot be claimed about the other end accepting these > parameters as the reset of poll bit could be due to the remote end > receiving F1 packet. > > Implementations can choose to do this and regardless of the remote > end implementation this works fine. However, this is not mandatory. > > Do you know of any case which may not work if someone implemented > this "MAY" ? > > Regards, > > Satyam > > From: davari@broadcom.com > To: satyamsinha@live.com; rtg-bfd@ietf.org > Date: Fri, 14 Aug 2009 14:14:28 -0700 > Subject: RE: Timer Manipulation > > Hi Satyam, > > But section 6.5 says " A BFD Control packet MUST NOT have both the > Poll (P) and Final (F) bits set.". > > Regards, > Shahram > > From: Satyam Sinha [mailto:satyamsinha@live.com] > Sent: Friday, August 14, 2009 1:57 PM > To: Shahram Davari; rtg-bfd@ietf.org > Subject: RE: Timer Manipulation > > Hi Shahram, > > The MAY here means that BFD allows an endpoint to set both (P) and > (F) bits together in the same packet. The endpoint "MAY" initiate > the poll sequence even while it is responding to a poll sequence. It > is not mandatory for it to wait for the poll sequence to complete > before initiating it's own poll sequence. > > In case of change in local parameters while the endpoint is > receiving a poll sequence, the endpoint could either use new > parameters and set both (P) & (F) bits or use old parameters with > only the (F) bit set and then start a poll sequence following the > final transmissions. In both cases the endpoint has to wait for a > Final packet from the other end. > > Regards, > > Satyam > > From: davari@broadcom.com > To: rtg-bfd@ietf.org > Date: Fri, 14 Aug 2009 12:44:24 -0700 > Subject: Timer Manipulation > > Hi, > > Section 6.8.3 of base draft says : > > "If either bfd.DesiredMinTxInterval is changed or > bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be > initiated (see section 6.5). If the timing is such that a system > receiving a Poll Sequence wishes to change the parameters described > in this paragraph, the new parameter values MAY be carried in > packets with the Final (F) bit set, even if the Poll Sequence has > not yet been sent." > > It seems that the above mentioned MAY requirement is not a good > idea, because if a Poll receiver updates any parameter in the Final > packet, then how can the Poll receiver verify that those Parameters > are Received by the Poll sender? > > Regards, > Shahram > > > Get your vacation photos on your phone! Click here. > Get your vacation photos on your phone! Click here. --Apple-Mail-4--661599390 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

On Aug 14, 2009, = at 6:00 PM, Shahram Davari wrote:

Hi = Satyam,

An = example is if local systems is in demand mode and a single Poll = sequence is received from remote system. If the local system changes any = value in the Final packet, it can't be sure that the remote system has = received it.

My = be we should allow Poll =3D1 and F =3D1 in the same packet = !

No, it = just sends its own poll sequence as required by the = spec.

--Dave

Regards,
Shahram

From: Satyam Sinha [mailto:satyamsinha@live.com]
Sent: Friday, August 14, 2009 = 4:47 PM
To: Shahram Davari; rtg-bfd@ietf.org
Subject: RE: Timer = Manipulation

Hi Shahram,

Clearly = then we can't use the exact semantics that I suggested due to this = restriction. However, this statement allows an implied poll sequence = which the systems "MAY" implement.

One example is, if a remote = endpoint starts a poll sequence and sends out poll packets P1, P2, P3 = ... at the same time the parameters change at the local endpoint and it = sends out new parameters in F1 (Final packet responding to P1), F2 for = P2 and so on. In such a case, ending of the poll sequence (by receiving = the first packet with P=3D0) is indication that the parameters were = accepted as the remote end as it must have received atleast one of these = final packets.

However, the same = cannot be claimed if you start this process on F2 as the same cannot be = claimed about the other end accepting these parameters as the reset of = poll bit could be due to the remote end receiving F1 = packet.

Implementations can choose to do this and regardless of = the remote end implementation this works fine. However, this is not = mandatory.

Do = you know of any case which may not work if someone implemented this = "MAY" ?

Regards,

Satyam

From: davari@broadcom.com
To: satyamsinha@live.com; rtg-bfd@ietf.org
Date: Fri, 14 = Aug 2009 14:14:28 -0700
Subject: RE: Timer = Manipulation

Hi = Satyam,

But= section 6.5 says " A BFD Control packet MUST NOT = have both the Poll (P) and Final (F) bits = set.".

Regards,
Shahram

From: Satyam Sinha [mailto:satyamsinha@live.com]
Sent: Friday, August 14, 2009 = 1:57 PM
To: Shahram Davari; rtg-bfd@ietf.org
Subject: RE: Timer = Manipulation

Hi Shahram,

The MAY = here means that BFD allows an endpoint to set both (P) and (F) bits = together in the same packet. The endpoint "MAY" initiate the poll = sequence even while it is responding to a poll sequence. It is not = mandatory for it to wait for the poll sequence to complete before = initiating it's own poll sequence.

In case of change in local = parameters while the endpoint is receiving a poll sequence, the endpoint = could either use new parameters and set both (P) & (F) bits or use = old parameters with only the (F) bit set and then start a poll sequence = following the final transmissions. In both cases the endpoint has to = wait for a Final packet from the other = end.

Regards,

Satyam

From: davari@broadcom.com
To: rtg-bfd@ietf.org
Date: Fri, 14 = Aug 2009 12:44:24 -0700
Subject: Timer Manipulation

Hi,

Section 6.8.3 of = base draft says :

"If either bfd.DesiredMinTxInterval is changed or = bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated = (see section 6.5). If the timing is such that a system receiving a Poll = Sequence wishes to change the parameters described in this paragraph, = the new parameter values MAY be carried in packets with the Final (F) = bit set, even if the Poll Sequence has not yet been = sent."

It seems that the above mentioned MAY requirement is not a = good idea, because if a Poll receiver updates any parameter in the = Final packet, then how can the Poll receiver verify that those = Parameters are Received by the Poll = sender?

Regards,
Shahram

Get your vacation = photos on your phone! Click here.
Get your vacation photos on your = phone! Click = here.

= --Apple-Mail-4--661599390-- From dkatz@juniper.net Sat Aug 15 15:44:49 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D843A6AF5 for ; Sat, 15 Aug 2009 15:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAul6enQT7U8 for ; Sat, 15 Aug 2009 15:44:49 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id CD9F53A67A8 for ; Sat, 15 Aug 2009 15:44:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSoc6Y7tiR4W7fqe+AI8isLp2DvyBqmLG@postini.com; Sat, 15 Aug 2009 15:44:53 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 15 Aug 2009 15:43:04 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:43:04 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:43:03 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:43:03 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7FMh2013260; Sat, 15 Aug 2009 15:43:03 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <05A410D2-42CD-4853-81BD-1E0A01ACF84D@juniper.net> From: Dave Katz To: Satyam Sinha In-Reply-To: Content-Type: multipart/alternative; boundary="Apple-Mail-5--661440832" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Timer Manipulation Date: Sat, 15 Aug 2009 16:43:02 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D5DA@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D5E9@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815050D60D@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Aug 2009 22:43:03.0608 (UTC) FILETIME=[BFD6FB80:01CA1DF9] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 22:44:49 -0000 --Apple-Mail-5--661440832 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 14, 2009, at 6:42 PM, Satyam Sinha wrote: > Hi All, > > Do we know what breaks if we allow P=1 and F=1 in same packet ? This is disallowed because the spec says to send a packet with F=1 immediately upon receipt of a Poll. This requirement (trivial to implement) bounds the packet transmission rate, and provides additional protection against runaway packet transmission in the case of a broken implementation. --Dave --Apple-Mail-5--661440832 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

On Aug 14, 2009, = at 6:42 PM, Satyam Sinha wrote:

Hi All,

Do we = know what breaks if we allow P=3D1 and F=3D1 in same packet = ?

This is disallowed because = the spec says to send a packet with F=3D1 immediately upon receipt of a = Poll. This requirement (trivial to implement) bounds the packet = transmission rate, and provides additional protection against runaway = packet transmission in the case of a broken = implementation.

--Dave

= --Apple-Mail-5--661440832-- From dkatz@juniper.net Sat Aug 15 15:49:25 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B413A68FA for ; Sat, 15 Aug 2009 15:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkioJ2mBUZqA for ; Sat, 15 Aug 2009 15:49:24 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 45FF53A6A83 for ; Sat, 15 Aug 2009 15:49:01 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSoc7Yc1j0LHYKmb6d2h9r0HbcwvoYKvY@postini.com; Sat, 15 Aug 2009 15:49:06 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 15 Aug 2009 15:47:22 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:47:22 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:47:21 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:47:21 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7FMlL013427; Sat, 15 Aug 2009 15:47:21 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <05ABD27C-5CC3-4F45-A519-6778266414FC@juniper.net> From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="Apple-Mail-6--661182505" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: DOWN state Date: Sat, 15 Aug 2009 16:47:20 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Aug 2009 22:47:21.0433 (UTC) FILETIME=[5983F490:01CA1DFA] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 22:49:25 -0000 --Apple-Mail-6--661182505 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 14, 2009, at 4:49 PM, Shahram Davari wrote: > Hi, > > The based draft sys that if BFD Control packet is not received > during any Detection Interval then the local system will go to Down > state. > I have two questions: > > 1) When can the local system transition out of Down state? Is it > after receiving the first BFD packet with State=DOWN or INIT? or a > number of such BFD packets are required? in other words is there a > Hysteresis? The state machine should be clear on this (first received packet.) > > 2) Should the remote system apply a sliding window for Detection > Time or fixed slotted windows that are not overlapped are acceptable? This is an implementation issue outside of the spec. There is no interoperability issue with slow timers; it just means that it takes a bit longer for the local system to realize that things have gone bad. --Dave --Apple-Mail-6--661182505 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

On Aug 14, 2009, = at 4:49 PM, Shahram Davari wrote:

=
Hi,

The based = draft sys that if BFD Control packet is not received during any = Detection Interval then the local system will go to Down = state.

I have two questions:
=

1) When can = the local system transition out of Down state? Is it after receiving the = first BFD packet with State=3DDOWN or INIT? or a number of such BFD = packets are required? in other words is there a = Hysteresis?

The = state machine should be clear on this (first received = packet.)

2) Should the remote system = apply a sliding window for Detection Time or fixed slotted = windows that are not overlapped are = acceptable?

This is = an implementation issue outside of the spec. There is no = interoperability issue with slow timers; it just means that it = takes a bit longer for the local system to realize that things have gone = bad.

--Dave

= --Apple-Mail-6--661182505-- From dkatz@juniper.net Sat Aug 15 15:54:50 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7E83A6948 for ; Sat, 15 Aug 2009 15:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mch9VSqVBNhx for ; Sat, 15 Aug 2009 15:54:49 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 10AA03A68FA for ; Sat, 15 Aug 2009 15:54:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSoc8kirHIm1wR0c7Ok9PpAFKjjGAeDAF@postini.com; Sat, 15 Aug 2009 15:54:12 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 15 Aug 2009 15:52:42 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:52:42 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:52:42 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 15:52:41 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7FMqe013494; Sat, 15 Aug 2009 15:52:40 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <7A6C6F3F-62E7-495A-B813-2D4D39F36935@juniper.net> From: Dave Katz To: Satyam Sinha In-Reply-To: Content-Type: multipart/alternative; boundary="Apple-Mail-7--660863810" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: DOWN state Date: Sat, 15 Aug 2009 16:52:39 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Aug 2009 22:52:41.0182 (UTC) FILETIME=[1819C7E0:01CA1DFB] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Aug 2009 22:54:50 -0000 --Apple-Mail-7--660863810 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 14, 2009, at 6:22 PM, Satyam Sinha wrote: > > > > > 2) Should the remote system apply a sliding window for > Detection Time or > > > fixed slotted windows that are not overlapped are acceptable? > > What does the window contain? (I understand you are trying to do > > something similar to TCP). Are you using a mechanism like that for > > echo packets? > > From a transmit perspective, if you take into account jitter, one > should have the timers as sliding window based. One should schedule > the next transmit at last-transmit-time + tx-timer (jittered) > instead of expected-last-transmit-time + tx-timer (jittered). The > variance in the jitter alongwith slotted window usage between two > transmits could cause the tx-time between two packets to be more > than the tx-timer. This doesn't matter as long as the timers aren't severely late. In most cases the jitter subtraction will more than make up for latencies in the timer system, and even if a packet is sent a little late, it doesn't matter, so long as *some* packet arrives within the detection time. > When the multiplier=1, such a variance could make your session go > down. Not unless it is severely late; the spec explicitly caps the actual interval at 90% of the nominal value for just this reason. > > From a receive perspective you could do either. If you used slotted > windows, you might see more than one packet in a slot but you are > still guaranteed to see atleast one packet every slot. This is all very implementation-specific, and is identical in character to any hello-based protocol. The only real difference is that in some cases you may run BFD with a much shorter timeout, so all of the system components have to be up to the task, however you do it. --Dave --Apple-Mail-7--660863810 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

On Aug 14, 2009, = at 6:22 PM, Satyam Sinha wrote:

>
> > = 2) Should the remote system apply a sliding window = for Detection Time or
> > fixed slotted windows that are not = overlapped are acceptable?
> What does the window contain? (I = understand you are trying to do
> something similar to TCP). Are = you using a mechanism like that for
> echo packets?

=46rom = a transmit perspective, if you take into account jitter, one should have = the timers as sliding window based. One should schedule the next = transmit at last-transmit-time + tx-timer (jittered) instead of = expected-last-transmit-time + tx-timer (jittered). The variance in the = jitter alongwith slotted window usage between two transmits could cause = the tx-time between two packets to be more than the tx-timer. =

This doesn't matter as long as = the timers aren't severely late. In most cases the jitter = subtraction will more than make up for latencies in the timer system, = and even if a packet is sent a little late, it doesn't matter, so long = as *some* packet arrives within the detection = time.

When the multiplier=3D1,= such a variance could make your session go = down.

Not unless it is severely = late; the spec explicitly caps the actual interval at 90% of the = nominal value for just this reason.

=46rom a receive = perspective you could do either. If you used slotted windows, you might = see more than one packet in a slot but you are still guaranteed to see = atleast one packet every = slot.

This is all very = implementation-specific, and is identical in character to any = hello-based protocol. The only real difference is that in some = cases you may run BFD with a much shorter timeout, so all of the system = components have to be up to the task, however you do = it.

--Dave

<= /html>= --Apple-Mail-7--660863810-- From davari@broadcom.com Mon Aug 17 11:32:34 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242763A6F38 for ; Mon, 17 Aug 2009 11:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, SARE_UN7=0.917] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCM9+XAhKSIk for ; Mon, 17 Aug 2009 11:32:33 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id EB5EC3A67BE for ; Mon, 17 Aug 2009 11:32:32 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 17 Aug 2009 11:32:26 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Mon, 17 Aug 2009 11:32:26 -0700 From: "Shahram Davari" To: "Satyam Sinha" , "Vishwas Manral" Date: Mon, 17 Aug 2009 11:32:24 -0700 Subject: RE: DOWN state Thread-Topic: DOWN state Thread-Index: AcodPoVDDYeZjzfiQnOhzNR2NAqLpwCKisIQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157370890@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66977DB037019033666-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD68157370890SJEXCHCCR02co_ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:32:34 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD68157370890SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Satayam, Are you saying that the Jitter is calculated and applied per BFD packet? or= it is calculated once per session and applied to all packets of that sessi= on? For example can one packet of a BFD session be jittered by 10% and another = one by 20%? Thanks, Shahram ________________________________ From: Satyam Sinha [mailto:satyamsinha@live.com] Sent: Friday, August 14, 2009 5:23 PM To: Vishwas Manral; Shahram Davari Cc: rtg-bfd@ietf.org Subject: RE: DOWN state Hi Shahram, Comments inline.... > Date: Fri, 14 Aug 2009 16:42:36 -0700 > Subject: Re: DOWN state > From: vishwas.ietf@gmail.com > To: davari@broadcom.com > CC: rtg-bfd@ietf.org > > Hi Saharam, > > On Fri, Aug 14, 2009 at 3:49 PM, Shahram Davari wrot= e: > > Hi, > > > > The based draft sys that if BFD Control packet is not received during a= ny > > Detection Interval then the local system will go to Down state. > > I have two questions: > > > > 1) When can the local system transition out of Down state? Is it after > > receiving the first BFD packet with State=3DDOWN or INIT? or a number o= f such > > BFD packets are required? in other words is there a Hysteresis? > No hysteresis is required as such. Any hysteresis would actually be a violation of the "Section 6.2 BFD state-= machine". Down state means that the session is down (or has just been created.) A session remains in Down state until the remote system indicates that it agrees that the session is down by sending a BFD Control packet with the State field set to anything other than Up. > > > 2) Should the remote system apply a sliding window for Detection Time = or > > fixed slotted windows that are not overlapped are acceptable? > What does the window contain? (I understand you are trying to do > something similar to TCP). Are you using a mechanism like that for > echo packets? >From a transmit perspective, if you take into account jitter, one should ha= ve the timers as sliding window based. One should schedule the next transmi= t at last-transmit-time + tx-timer (jittered) instead of expected-last-tran= smit-time + tx-timer (jittered). The variance in the jitter alongwith slott= ed window usage between two transmits could cause the tx-time between two p= ackets to be more than the tx-timer. When the multiplier=3D1, such a varian= ce could make your session go down. >From a receive perspective you could do either. If you used slotted windows= , you might see more than one packet in a slot but you are still guaranteed= to see atleast one packet every slot. Regards, Satyam ________________________________ Get your vacation photos on your phone! Click here. --_000_2C2F1EBA8050E74EA81502D5740B4BD68157370890SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi= =20 Satayam,

Ar= e you=20 saying that the Jitter is calculated and applied per BFD packet? or it is=20 calculated once per session and applied to all packets of that=20 session?

Fo= r example=20 can one packet of a BFD session be jittered by 10% and another one by=20 20%?

Thanks,

Shahram

From: Satyam Sinha [mailto:satyamsinha@live.com]= =20
Sent: Friday, August 14, 2009 5:23 PM
To: Vishwas Manr= al;=20 Shahram Davari
Cc: rtg-bfd@ietf.org
Subject: RE: DOWN=20 state

Hi Shahram,

Comments inline....

> Date: Fri, 14= Aug=20 2009 16:42:36 -0700
> Subject: Re: DOWN state
> From:=20 vishwas.ietf@gmail.com
> To: davari@broadcom.com
> CC:=20 rtg-bfd@ietf.org
>
> Hi Saharam,
>
> On Fri, Aug = 14,=20 2009 at 3:49 PM, Shahram Davari<davari@broadcom.com> wrote:
> &= gt;=20 Hi,
> >
> > The based draft sys that if BFD Control packe= t is=20 not received during any
> > Detection Interval then the local syst= em=20 will go to Down state.
> > I have two questions:
> >
&= gt;=20 > 1) When can the local system transition out of Down state? Is it=20 after
> > receiving the first BFD packet with State=3DDOWN or INIT= ? or a=20 number of such
> > BFD packets are required? in other words is the= re a=20 Hysteresis?
> No hysteresis is required as such.

Any hysteresi= s=20 would actually be a violation of the "Section 6.2 BFD state-machine".
<= PRE class=3Dnewpage>Down state means that the session is down (or has just = been created.)
A session remains in Down state until the remote syste= m indicates
that it agrees that the session is down by sending a BFD = Control
packet with the State field set to anything other than Up.>=20
> > 2) Should the remote system apply a slid= ing=20 window for Detection Time or
> > fixed slotted windows that are no= t=20 overlapped are acceptable?
> What does the window contain? (I underst= and=20 you are trying to do
> something similar to TCP). Are you using a=20 mechanism like that for
> echo packets?

From a transmit=20 perspective, if you take into account jitter, one should have the timers as= =20 sliding window based. One should schedule the next transmit at=20 last-transmit-time + tx-timer (jittered) instead of expected-last-transmit-= time=20 + tx-timer (jittered). The variance in the jitter alongwith slotted window = usage=20 between two transmits could cause the tx-time between two packets to be mor= e=20 than the tx-timer. When the multiplier=3D1, such a variance could make your= =20 session go down.

From a receive perspective you could do either. If = you=20 used slotted windows, you might see more than one packet in a slot but you = are=20 still guaranteed to see atleast one packet every=20 slot.

Regards,

Satyam

Get your vacation photos on your phone! Click here. --_000_2C2F1EBA8050E74EA81502D5740B4BD68157370890SJEXCHCCR02co_-- From vishwas.ietf@gmail.com Mon Aug 17 11:43:37 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7BA3A6F80 for ; Mon, 17 Aug 2009 11:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I09Amu5UeBta for ; Mon, 17 Aug 2009 11:43:36 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 61DCA3A6F90 for ; Mon, 17 Aug 2009 11:43:34 -0700 (PDT) Received: by ywh26 with SMTP id 26so4085439ywh.5 for ; Mon, 17 Aug 2009 11:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B7+r86u8pVJmPS5TAY11p0+gnjeRXrGzdhsdIPDkD3w=; b=mIWS+4qzceQ9UhypH3g/ku4E2j4CEBLjP4DMv8j4MOEsDTCmsXZAXDIBLDxjPv3zZ1 KOnX31C9VqREfIi3Lj451kjY41/52kGVhkmFJhfkp0rmTvehlXGxHXFyM9hP1anTHy+p UD/Sl+busPbcj66VF1cPq2dtQt4QogjQTQVjA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PGdtPGE/fBlbByBubjwa+XxlfDxsDhIpNqPFPY+AZtDiIoGG2xxIj5hhcT9n/DoZIr LzaIehJqRgxEDhuJFTY73/lzzeyG2LKBtUXU10qkopRYKXUB9JKxYv3X0pfobrMH6AWK WKK58JqP0cmUsn4JeqG31nuuARdHe07eIM01I= MIME-Version: 1.0 Received: by 10.150.237.10 with SMTP id k10mr6155443ybh.112.1250534615772; Mon, 17 Aug 2009 11:43:35 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157370890@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370890@SJEXCHCCR02.corp.ad.broadcom.com> Date: Mon, 17 Aug 2009 11:43:35 -0700 Message-ID: <77ead0ec0908171143o437566delf4ab999f82078465@mail.gmail.com> Subject: Re: DOWN state From: Vishwas Manral To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:43:37 -0000 Hi Shahram, The more the randomness the more evenly distributed is the packet send operation. I understand your concern from the hardware perspective. It need not however be the same level of pseudo-randomness as required for security algorithms, which require specialized hardware for the same. Thanks, Vishwas On Mon, Aug 17, 2009 at 11:32 AM, Shahram Davari wrote= : > Hi Satayam, > > Are you saying that the Jitter is calculated and applied per BFD packet? = or > it is calculated once per session and applied to all packets of that > session? > For example can one packet of a BFD session be jittered by 10% and anothe= r > one by 20%? > > Thanks, > Shahram > ________________________________ > From: Satyam Sinha [mailto:satyamsinha@live.com] > Sent: Friday, August 14, 2009 5:23 PM > To: Vishwas Manral; Shahram Davari > Cc: rtg-bfd@ietf.org > Subject: RE: DOWN state > > Hi Shahram, > > Comments inline.... > >> Date: Fri, 14 Aug 2009 16:42:36 -0700 >> Subject: Re: DOWN state >> From: vishwas.ietf@gmail.com >> To: davari@broadcom.com >> CC: rtg-bfd@ietf.org >> >> Hi Saharam, >> >> On Fri, Aug 14, 2009 at 3:49 PM, Shahram Davari >> wrote: >> > Hi, >> > >> > The based draft sys that if BFD Control packet is not received during >> > any >> > Detection Interval then the local system will go to Down state. >> > I have two questions: >> > >> > 1) When can the local system transition out of Down state? Is it after >> > receiving the first BFD packet with State=3DDOWN or INIT? or a number = of >> > such >> > BFD packets are required? in other words is there a Hysteresis? >> No hysteresis is required as such. > > Any hysteresis would actually be a violation of the "Section 6.2 BFD > state-machine". > > Down state means that the session is down (or has just been created.) > A session remains in Down state until the remote system indicates > that it agrees that the session is down by sending a BFD Control > packet with the State field set to anything other than Up. > >> >> > 2)=A0Should the=A0remote system apply=A0=A0a sliding window for Detect= ion Time >> > or >> > fixed slotted windows that are not overlapped are acceptable? >> What does the window contain? (I understand you are trying to do >> something similar to TCP). Are you using a mechanism like that for >> echo packets? > > From a transmit perspective, if you take into account jitter, one should > have the timers as sliding window based. One should schedule the next > transmit at last-transmit-time + tx-timer (jittered) instead of > expected-last-transmit-time + tx-timer (jittered). The variance in the > jitter alongwith slotted window usage between two transmits could cause t= he > tx-time between two packets to be more than the tx-timer. When the > multiplier=3D1, such a variance could make your session go down. > > From a receive perspective you could do either. If you used slotted windo= ws, > you might see more than one packet in a slot but you are still guaranteed= to > see atleast one packet every slot. > > Regards, > > Satyam > > ________________________________ > Get your vacation photos on your phone! Click here. From davari@broadcom.com Mon Aug 17 11:46:44 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215D83A6FA6 for ; Mon, 17 Aug 2009 11:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gyWXTa55vja for ; Mon, 17 Aug 2009 11:46:43 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id CFF933A6FAC for ; Mon, 17 Aug 2009 11:45:59 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 17 Aug 2009 11:45:56 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Mon, 17 Aug 2009 11:45:56 -0700 From: "Shahram Davari" To: "rtg-bfd@ietf.org" Date: Mon, 17 Aug 2009 11:45:55 -0700 Subject: BFD for MPLS Thread-Topic: BFD for MPLS Thread-Index: AcofavP1pbU52YNRSJenWDXEs8qBcA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157370896@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66977AEE37019047729-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD68157370896SJEXCHCCR02co_ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:46:44 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD68157370896SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, Section 4 of draft-ietf-bfd-mpls-07 says: "If the LSP is associated with Multiple FECs, a BFD session SHOULD be estab= lished for each FEC" But this doesn't seem to be correct, since BFD can only check the LSP and i= s unaware of the FECs mapped to the LSP. Am I missing something? Thanks, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD68157370896SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,

Section 4= of=20 draft-ietf-bfd-mpls-07 says:

"If the L= SP is=20 associated with Multiple FECs, a BFD session SHOULD be established for each= =20 FEC"

But this = doesn't=20 seem to be correct, since BFD can only check the LSP and is unaware of the = FECs=20 mapped to the LSP.

Am I miss= ing=20 something?

Thanks,
Shahram

--_000_2C2F1EBA8050E74EA81502D5740B4BD68157370896SJEXCHCCR02co_-- From davari@broadcom.com Mon Aug 17 11:50:40 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1ED13A6B24 for ; Mon, 17 Aug 2009 11:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ2si0OMVbc2 for ; Mon, 17 Aug 2009 11:50:39 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id A44D33A6A4A for ; Mon, 17 Aug 2009 11:50:39 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 17 Aug 2009 11:50:29 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Mon, 17 Aug 2009 11:50:29 -0700 From: "Shahram Davari" To: "Vishwas Manral" Date: Mon, 17 Aug 2009 11:50:28 -0700 Subject: RE: DOWN state Thread-Topic: DOWN state Thread-Index: AcofaqnDB+D0dkVxQ6WkDkuU86CXdgAAGKcQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157370898@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370890@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908171143o437566delf4ab999f82078465@mail.gmail.com> In-Reply-To: <77ead0ec0908171143o437566delf4ab999f82078465@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 669779FF60082906424-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:50:40 -0000 Hi Vishwas, Thanks for your answer. But I just want to understand the requirements. Is = it required to calculate Jitter Per BFD packet or it can be calculated once per BFD session and applied to = all packets of that session? The base draft says the reason for applying Jitter is to avoid synchronizat= ion mean. What does self synchronization mean here? Thanks, Shahram=20 -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Monday, August 17, 2009 11:44 AM To: Shahram Davari Cc: Satyam Sinha; rtg-bfd@ietf.org Subject: Re: DOWN state Hi Shahram, The more the randomness the more evenly distributed is the packet send operation. I understand your concern from the hardware perspective. It need not however be the same level of pseudo-randomness as required for security algorithms, which require specialized hardware for the same. Thanks, Vishwas On Mon, Aug 17, 2009 at 11:32 AM, Shahram Davari wrote= : > Hi Satayam, > > Are you saying that the Jitter is calculated and applied per BFD packet? = or > it is calculated once per session and applied to all packets of that > session? > For example can one packet of a BFD session be jittered by 10% and anothe= r > one by 20%? > > Thanks, > Shahram > ________________________________ > From: Satyam Sinha [mailto:satyamsinha@live.com] > Sent: Friday, August 14, 2009 5:23 PM > To: Vishwas Manral; Shahram Davari > Cc: rtg-bfd@ietf.org > Subject: RE: DOWN state > > Hi Shahram, > > Comments inline.... > >> Date: Fri, 14 Aug 2009 16:42:36 -0700 >> Subject: Re: DOWN state >> From: vishwas.ietf@gmail.com >> To: davari@broadcom.com >> CC: rtg-bfd@ietf.org >> >> Hi Saharam, >> >> On Fri, Aug 14, 2009 at 3:49 PM, Shahram Davari >> wrote: >> > Hi, >> > >> > The based draft sys that if BFD Control packet is not received during >> > any >> > Detection Interval then the local system will go to Down state. >> > I have two questions: >> > >> > 1) When can the local system transition out of Down state? Is it after >> > receiving the first BFD packet with State=3DDOWN or INIT? or a number = of >> > such >> > BFD packets are required? in other words is there a Hysteresis? >> No hysteresis is required as such. > > Any hysteresis would actually be a violation of the "Section 6.2 BFD > state-machine". > > Down state means that the session is down (or has just been created.) > A session remains in Down state until the remote system indicates > that it agrees that the session is down by sending a BFD Control > packet with the State field set to anything other than Up. > >> >> > 2)=A0Should the=A0remote system apply=A0=A0a sliding window for Detect= ion Time >> > or >> > fixed slotted windows that are not overlapped are acceptable? >> What does the window contain? (I understand you are trying to do >> something similar to TCP). Are you using a mechanism like that for >> echo packets? > > From a transmit perspective, if you take into account jitter, one should > have the timers as sliding window based. One should schedule the next > transmit at last-transmit-time + tx-timer (jittered) instead of > expected-last-transmit-time + tx-timer (jittered). The variance in the > jitter alongwith slotted window usage between two transmits could cause t= he > tx-time between two packets to be more than the tx-timer. When the > multiplier=3D1, such a variance could make your session go down. > > From a receive perspective you could do either. If you used slotted windo= ws, > you might see more than one packet in a slot but you are still guaranteed= to > see atleast one packet every slot. > > Regards, > > Satyam > > ________________________________ > Get your vacation photos on your phone! Click here. From vishwas.ietf@gmail.com Mon Aug 17 12:04:59 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAED93A6F58 for ; Mon, 17 Aug 2009 12:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQx6ZN9kAedp for ; Mon, 17 Aug 2009 12:04:58 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 9A0CA3A6F9C for ; Mon, 17 Aug 2009 12:04:55 -0700 (PDT) Received: by gxk17 with SMTP id 17so4047033gxk.19 for ; Mon, 17 Aug 2009 12:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H8/xi3RwJUfFSjonnh9mMwcqo9Fq5h6CssCSa6xuzPk=; b=MfYiHyOfAam9afaCKD/vPobLVVRn5tXa0+zT9TBE7n8tiDA/qatCKnsy9ZLNxPTwr1 NQZDK4PZIonmy9knitBetfzHcGUjFwsSPKzruMJOemYOl+0n+T6cuTuT3NAVppuspY4H 9T5d3/+rB+djcDUVTRBCKX/VcWW22ZK7Jk6mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PrL+bZyq1rL+5WPDR+1xSG9obS+wQ33//ConSI1Xz/9v/Cts8d9nBoBboK1GZrFsmG BBNyNou4KMlqaeXV39FZOwoD7NLXaTefA06kZlvzJq09GOYHs3GQNBK3zYyo0teVath3 U/Ys/afkRiZsDl1lZGxBtLazHmeEIYWsI2l94= MIME-Version: 1.0 Received: by 10.150.237.10 with SMTP id k10mr6191317ybh.112.1250535894949; Mon, 17 Aug 2009 12:04:54 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157370898@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370890@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908171143o437566delf4ab999f82078465@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370898@SJEXCHCCR02.corp.ad.broadcom.com> Date: Mon, 17 Aug 2009 12:04:54 -0700 Message-ID: <77ead0ec0908171204t9702a07v25c7af342fa9c95c@mail.gmail.com> Subject: Re: DOWN state From: Vishwas Manral To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 19:05:00 -0000 Hi Shahram, It would be best to apply it per packet. Self synchronization in this case would send timers for all sessions expiring symultaneously and thus the load on the system/ network traffic not being uniform but having peaks and troughs. Thanks, Vishwas On Mon, Aug 17, 2009 at 11:50 AM, Shahram Davari wrote= : > Hi Vishwas, > > Thanks for your answer. But I just want to understand the requirements. I= s it required to calculate Jitter > Per BFD packet or it can be calculated once per BFD session and applied t= o all packets of that session? > > The base draft says the reason for applying Jitter is to avoid synchroniz= ation mean. What does self synchronization mean here? > > > Thanks, > Shahram > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Monday, August 17, 2009 11:44 AM > To: Shahram Davari > Cc: Satyam Sinha; rtg-bfd@ietf.org > Subject: Re: DOWN state > > Hi Shahram, > > The more the randomness the more evenly distributed is the packet send > operation. > > I understand your concern from the hardware perspective. It need not > however be the same level of pseudo-randomness as required for > security algorithms, which require specialized hardware for the same. > > Thanks, > Vishwas > > On Mon, Aug 17, 2009 at 11:32 AM, Shahram Davari wro= te: >> Hi Satayam, >> >> Are you saying that the Jitter is calculated and applied per BFD packet?= or >> it is calculated once per session and applied to all packets of that >> session? >> For example can one packet of a BFD session be jittered by 10% and anoth= er >> one by 20%? >> >> Thanks, >> Shahram >> ________________________________ >> From: Satyam Sinha [mailto:satyamsinha@live.com] >> Sent: Friday, August 14, 2009 5:23 PM >> To: Vishwas Manral; Shahram Davari >> Cc: rtg-bfd@ietf.org >> Subject: RE: DOWN state >> >> Hi Shahram, >> >> Comments inline.... >> >>> Date: Fri, 14 Aug 2009 16:42:36 -0700 >>> Subject: Re: DOWN state >>> From: vishwas.ietf@gmail.com >>> To: davari@broadcom.com >>> CC: rtg-bfd@ietf.org >>> >>> Hi Saharam, >>> >>> On Fri, Aug 14, 2009 at 3:49 PM, Shahram Davari >>> wrote: >>> > Hi, >>> > >>> > The based draft sys that if BFD Control packet is not received during >>> > any >>> > Detection Interval then the local system will go to Down state. >>> > I have two questions: >>> > >>> > 1) When can the local system transition out of Down state? Is it afte= r >>> > receiving the first BFD packet with State=3DDOWN or INIT? or a number= of >>> > such >>> > BFD packets are required? in other words is there a Hysteresis? >>> No hysteresis is required as such. >> >> Any hysteresis would actually be a violation of the "Section 6.2 BFD >> state-machine". >> >> Down state means that the session is down (or has just been created.) >> =A0 =A0A session remains in Down state until the remote system indicates >> =A0 =A0that it agrees that the session is down by sending a BFD Control >> =A0 =A0packet with the State field set to anything other than Up. >> >>> >>> > 2)=A0Should the=A0remote system apply=A0=A0a sliding window for Detec= tion Time >>> > or >>> > fixed slotted windows that are not overlapped are acceptable? >>> What does the window contain? (I understand you are trying to do >>> something similar to TCP). Are you using a mechanism like that for >>> echo packets? >> >> From a transmit perspective, if you take into account jitter, one should >> have the timers as sliding window based. One should schedule the next >> transmit at last-transmit-time + tx-timer (jittered) instead of >> expected-last-transmit-time + tx-timer (jittered). The variance in the >> jitter alongwith slotted window usage between two transmits could cause = the >> tx-time between two packets to be more than the tx-timer. When the >> multiplier=3D1, such a variance could make your session go down. >> >> From a receive perspective you could do either. If you used slotted wind= ows, >> you might see more than one packet in a slot but you are still guarantee= d to >> see atleast one packet every slot. >> >> Regards, >> >> Satyam >> >> ________________________________ >> Get your vacation photos on your phone! Click here. > > > From SCHOUWEN@nortel.com Mon Aug 17 12:15:00 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5E03A6F5E for ; Mon, 17 Aug 2009 12:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1JHWowmTjcI for ; Mon, 17 Aug 2009 12:14:59 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7FF2F28C2F8 for ; Mon, 17 Aug 2009 12:14:27 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7HJEO528622; Mon, 17 Aug 2009 19:14:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: DOWN state Date: Mon, 17 Aug 2009 15:14:03 -0400 Message-ID: <549FD0754C7E1D468D93A34B42AC5F9215571244@zcarhxm1.corp.nortel.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157370898@SJEXCHCCR02.corp.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DOWN state Thread-Index: AcofbuJGT0OOl7MlR/S82hpTUudSFA== References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com><77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com><2C2F1EBA8050E74EA81502D5740B4BD68157370890@SJEXCHCCR02.corp.ad.broadcom.com><77ead0ec0908171143o437566delf4ab999f82078465@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370898@SJEXCHCCR02.corp.ad.broadcom.com> From: "John Van Schouwen" To: "Shahram Davari" , "Vishwas Manral" Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 19:15:00 -0000 Jitter is to be applied on a per-packet basis. Here's a crude, simplified summary: Self-synchronization has to do with = routers throughout a network synching up their periodic transmissions = (such as with periodic hello packets) such that all routers send a burst = of packets in unison, and then quiesce together for a time. It's an = interesting phenomenon that is rooted in having all routers transmitting = their periodic packets on near indentical periods. Though their timers = may all be started randomly, over time--due to queuing latencies-- they = eventually sychronize their timers with each other. (Apparently, this = phenomenon can be seen with pendulum clocks hanging on the same wall; = they eventually synchronize and swing in unison.) The bursty = transmissions create havoc on routers' CPUs. So, there is a desire to = avoid allowing routers self-synchronize. This can be accomplished by = applying a large enough per-interval jitter on the periodic timers. If = you're really interested in the details, search on = "self-synchronization" in Google or on the IETF Web site. John van Schouwen MG15K Bidirectional Forwarding Detection Team Nortel Networks, Ottawa, Canada email: schouwen@nortel.com Phone: (613) 763-8763 (external) ESN: 393-8763 (internal) =20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com]=20 > Sent: Monday, August 17, 2009 2:50 PM > To: Vishwas Manral > Cc: rtg-bfd@ietf.org > Subject: RE: DOWN state >=20 > Hi Vishwas, >=20 > Thanks for your answer. But I just want to understand the=20 > requirements. Is it required to calculate Jitter Per BFD=20 > packet or it can be calculated once per BFD session and=20 > applied to all packets of that session? >=20 > The base draft says the reason for applying Jitter is to=20 > avoid synchronization mean. What does self synchronization mean here? >=20 >=20 > Thanks, > Shahram=20 >=20 > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Monday, August 17, 2009 11:44 AM > To: Shahram Davari > Cc: Satyam Sinha; rtg-bfd@ietf.org > Subject: Re: DOWN state >=20 > Hi Shahram, >=20 > The more the randomness the more evenly distributed is the=20 > packet send operation. >=20 > I understand your concern from the hardware perspective. It=20 > need not however be the same level of pseudo-randomness as=20 > required for security algorithms, which require specialized=20 > hardware for the same. >=20 > Thanks, > Vishwas >=20 > On Mon, Aug 17, 2009 at 11:32 AM, Shahram=20 > Davari wrote: > > Hi Satayam, > > > > Are you saying that the Jitter is calculated and applied per BFD=20 > > packet? or it is calculated once per session and applied to all=20 > > packets of that session? > > For example can one packet of a BFD session be jittered by 10% and=20 > > another one by 20%? > > > > Thanks, > > Shahram > > ________________________________ > > From: Satyam Sinha [mailto:satyamsinha@live.com] > > Sent: Friday, August 14, 2009 5:23 PM > > To: Vishwas Manral; Shahram Davari > > Cc: rtg-bfd@ietf.org > > Subject: RE: DOWN state > > > > Hi Shahram, > > > > Comments inline.... > > > >> Date: Fri, 14 Aug 2009 16:42:36 -0700 > >> Subject: Re: DOWN state > >> From: vishwas.ietf@gmail.com > >> To: davari@broadcom.com > >> CC: rtg-bfd@ietf.org > >> > >> Hi Saharam, > >> > >> On Fri, Aug 14, 2009 at 3:49 PM, Shahram=20 > Davari > >> wrote: > >> > Hi, > >> > > >> > The based draft sys that if BFD Control packet is not received=20 > >> > during any Detection Interval then the local system will=20 > go to Down=20 > >> > state. > >> > I have two questions: > >> > > >> > 1) When can the local system transition out of Down state? Is it=20 > >> > after receiving the first BFD packet with State=3DDOWN or=20 > INIT? or a=20 > >> > number of such BFD packets are required? in other words=20 > is there a=20 > >> > Hysteresis? > >> No hysteresis is required as such. > > > > Any hysteresis would actually be a violation of the=20 > "Section 6.2 BFD=20 > > state-machine". > > > > Down state means that the session is down (or has just been=20 > created.) > > A session remains in Down state until the remote system indicates > > that it agrees that the session is down by sending a BFD Control > > packet with the State field set to anything other than Up. > > > >> > >> > 2)=A0Should the=A0remote system apply=A0=A0a sliding window for=20 > Detection=20 > >> > Time or fixed slotted windows that are not overlapped are=20 > >> > acceptable? > >> What does the window contain? (I understand you are trying to do=20 > >> something similar to TCP). Are you using a mechanism like that for=20 > >> echo packets? > > > > From a transmit perspective, if you take into account jitter, one=20 > > should have the timers as sliding window based. One should schedule=20 > > the next transmit at last-transmit-time + tx-timer=20 > (jittered) instead=20 > > of expected-last-transmit-time + tx-timer (jittered). The=20 > variance in=20 > > the jitter alongwith slotted window usage between two=20 > transmits could=20 > > cause the tx-time between two packets to be more than the tx-timer.=20 > > When the multiplier=3D1, such a variance could make your=20 > session go down. > > > > From a receive perspective you could do either. If you used slotted=20 > > windows, you might see more than one packet in a slot but you are=20 > > still guaranteed to see atleast one packet every slot. > > > > Regards, > > > > Satyam > > > > ________________________________ > > Get your vacation photos on your phone! Click here. >=20 >=20 >=20 >=20 From satyamsinha@live.com Mon Aug 17 12:16:56 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A393A6817 for ; Mon, 17 Aug 2009 12:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.821 X-Spam-Level: X-Spam-Status: No, score=-100.821 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT1kVeWSiqAE for ; Mon, 17 Aug 2009 12:16:55 -0700 (PDT) Received: from bay0-omc3-s12.bay0.hotmail.com (bay0-omc3-s12.bay0.hotmail.com [65.54.246.212]) by core3.amsl.com (Postfix) with ESMTP id 3772A28C160 for ; Mon, 17 Aug 2009 12:16:55 -0700 (PDT) Received: from BAY117-W3 ([207.46.8.38]) by bay0-omc3-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 12:17:00 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_743f564b-c9b0-4718-b6ea-a8a81ccab2a2_" X-Originating-IP: [64.47.51.158] From: Satyam Sinha To: Vishwas Manral , Subject: RE: DOWN state Date: Mon, 17 Aug 2009 12:16:59 -0700 Importance: Normal In-Reply-To: <77ead0ec0908171204t9702a07v25c7af342fa9c95c@mail.gmail.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370890@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908171143o437566delf4ab999f82078465@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370898@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908171204t9702a07v25c7af342fa9c95c@mail.gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Aug 2009 19:17:00.0940 (UTC) FILETIME=[4BF10CC0:01CA1F6F] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 19:16:56 -0000 --_743f564b-c9b0-4718-b6ea-a8a81ccab2a2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Vishwas. This is indeed per packet basis. Satyam > Date: Mon=2C 17 Aug 2009 12:04:54 -0700 > Subject: Re: DOWN state > From: vishwas.ietf@gmail.com > To: davari@broadcom.com > CC: satyamsinha@live.com=3B rtg-bfd@ietf.org >=20 > Hi Shahram=2C >=20 > It would be best to apply it per packet. Self synchronization in this > case would send timers for all sessions expiring symultaneously and > thus the load on the system/ network traffic not being uniform but > having peaks and troughs. >=20 > Thanks=2C > Vishwas >=20 > On Mon=2C Aug 17=2C 2009 at 11:50 AM=2C Shahram Davari wrote: > > Hi Vishwas=2C > > > > Thanks for your answer. But I just want to understand the requirements.= Is it required to calculate Jitter > > Per BFD packet or it can be calculated once per BFD session and applied= to all packets of that session? > > > > The base draft says the reason for applying Jitter is to avoid synchron= ization mean. What does self synchronization mean here? > > > > > > Thanks=2C > > Shahram > > > > -----Original Message----- > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > Sent: Monday=2C August 17=2C 2009 11:44 AM > > To: Shahram Davari > > Cc: Satyam Sinha=3B rtg-bfd@ietf.org > > Subject: Re: DOWN state > > > > Hi Shahram=2C > > > > The more the randomness the more evenly distributed is the packet send > > operation. > > > > I understand your concern from the hardware perspective. It need not > > however be the same level of pseudo-randomness as required for > > security algorithms=2C which require specialized hardware for the same. > > > > Thanks=2C > > Vishwas > > > > On Mon=2C Aug 17=2C 2009 at 11:32 AM=2C Shahram Davari wrote: > >> Hi Satayam=2C > >> > >> Are you saying that the Jitter is calculated and applied per BFD packe= t? or > >> it is calculated once per session and applied to all packets of that > >> session? > >> For example can one packet of a BFD session be jittered by 10% and ano= ther > >> one by 20%? > >> > >> Thanks=2C > >> Shahram > >> ________________________________ > >> From: Satyam Sinha [mailto:satyamsinha@live.com] > >> Sent: Friday=2C August 14=2C 2009 5:23 PM > >> To: Vishwas Manral=3B Shahram Davari > >> Cc: rtg-bfd@ietf.org > >> Subject: RE: DOWN state > >> > >> Hi Shahram=2C > >> > >> Comments inline.... > >> > >>> Date: Fri=2C 14 Aug 2009 16:42:36 -0700 > >>> Subject: Re: DOWN state > >>> From: vishwas.ietf@gmail.com > >>> To: davari@broadcom.com > >>> CC: rtg-bfd@ietf.org > >>> > >>> Hi Saharam=2C > >>> > >>> On Fri=2C Aug 14=2C 2009 at 3:49 PM=2C Shahram Davari > >>> wrote: > >>> > Hi=2C > >>> > > >>> > The based draft sys that if BFD Control packet is not received duri= ng > >>> > any > >>> > Detection Interval then the local system will go to Down state. > >>> > I have two questions: > >>> > > >>> > 1) When can the local system transition out of Down state? Is it af= ter > >>> > receiving the first BFD packet with State=3DDOWN or INIT? or a numb= er of > >>> > such > >>> > BFD packets are required? in other words is there a Hysteresis? > >>> No hysteresis is required as such. > >> > >> Any hysteresis would actually be a violation of the "Section 6.2 BFD > >> state-machine". > >> > >> Down state means that the session is down (or has just been created.) > >> A session remains in Down state until the remote system indicates > >> that it agrees that the session is down by sending a BFD Control > >> packet with the State field set to anything other than Up. > >> > >>> > >>> > 2) Should the remote system apply a sliding window for Detection T= ime > >>> > or > >>> > fixed slotted windows that are not overlapped are acceptable? > >>> What does the window contain? (I understand you are trying to do > >>> something similar to TCP). Are you using a mechanism like that for > >>> echo packets? > >> > >> From a transmit perspective=2C if you take into account jitter=2C one = should > >> have the timers as sliding window based. One should schedule the next > >> transmit at last-transmit-time + tx-timer (jittered) instead of > >> expected-last-transmit-time + tx-timer (jittered). The variance in the > >> jitter alongwith slotted window usage between two transmits could caus= e the > >> tx-time between two packets to be more than the tx-timer. When the > >> multiplier=3D1=2C such a variance could make your session go down. > >> > >> From a receive perspective you could do either. If you used slotted wi= ndows=2C > >> you might see more than one packet in a slot but you are still guarant= eed to > >> see atleast one packet every slot. > >> > >> Regards=2C > >> > >> Satyam > >> > >> ________________________________ > >> Get your vacation photos on your phone! Click here. > > > > > > _________________________________________________________________ Get back to school stuff for them and cashback for you. http://www.bing.com/cashback?form=3DMSHYCB&publ=3DWLHMTAG&crea=3DTEXT_MSHYC= B_BackToSchool_Cashback_BTSCashback_1x1= --_743f564b-c9b0-4718-b6ea-a8a81ccab2a2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Vishwas. This is indeed per packet basis.

Satyam
>=3B Date: Mon=2C 17 Aug 2009 12:04:54 -0700
>=3B Subject: Re: DOWN= state
>=3B From: vishwas.ietf@gmail.com
>=3B To: davari@broadcom= .com
>=3B CC: satyamsinha@live.com=3B rtg-bfd@ietf.org
>=3B
&= gt=3B Hi Shahram=2C
>=3B
>=3B It would be best to apply it per p= acket. Self synchronization in this
>=3B case would send timers for al= l sessions expiring symultaneously and
>=3B thus the load on the syste= m/ network traffic not being uniform but
>=3B having peaks and troughs= .
>=3B
>=3B Thanks=2C
>=3B Vishwas
>=3B
>=3B On = Mon=2C Aug 17=2C 2009 at 11:50 AM=2C Shahram Davari<=3Bdavari@broadcom.co= m>=3B wrote:
>=3B >=3B Hi Vishwas=2C
>=3B >=3B
>=3B &g= t=3B Thanks for your answer. But I just want to understand the requirements= . Is it required to calculate Jitter
>=3B >=3B Per BFD packet or it = can be calculated once per BFD session and applied to all packets of that s= ession?
>=3B >=3B
>=3B >=3B The base draft says the reason fo= r applying Jitter is to avoid synchronization mean. What does self synchron= ization mean here?
>=3B >=3B
>=3B >=3B
>=3B >=3B Thank= s=2C
>=3B >=3B Shahram
>=3B >=3B
>=3B >=3B -----Origin= al Message-----
>=3B >=3B From: Vishwas Manral [mailto:vishwas.ietf@= gmail.com]
>=3B >=3B Sent: Monday=2C August 17=2C 2009 11:44 AM
&= gt=3B >=3B To: Shahram Davari
>=3B >=3B Cc: Satyam Sinha=3B rtg-bf= d@ietf.org
>=3B >=3B Subject: Re: DOWN state
>=3B >=3B
>= =3B >=3B Hi Shahram=2C
>=3B >=3B
>=3B >=3B The more the ran= domness the more evenly distributed is the packet send
>=3B >=3B ope= ration.
>=3B >=3B
>=3B >=3B I understand your concern from th= e hardware perspective. It need not
>=3B >=3B however be the same le= vel of pseudo-randomness as required for
>=3B >=3B security algorith= ms=2C which require specialized hardware for the same.
>=3B >=3B
= >=3B >=3B Thanks=2C
>=3B >=3B Vishwas
>=3B >=3B
>=3B= >=3B On Mon=2C Aug 17=2C 2009 at 11:32 AM=2C Shahram Davari<=3Bdavari@= broadcom.com>=3B wrote:
>=3B >=3B>=3B Hi Satayam=2C
>=3B &g= t=3B>=3B
>=3B >=3B>=3B Are you saying that the Jitter is calcula= ted and applied per BFD packet? or
>=3B >=3B>=3B it is calculated = once per session and applied to all packets of that
>=3B >=3B>=3B = session?
>=3B >=3B>=3B For example can one packet of a BFD session= be jittered by 10% and another
>=3B >=3B>=3B one by 20%?
>= =3B >=3B>=3B
>=3B >=3B>=3B Thanks=2C
>=3B >=3B>=3B Sh= ahram
>=3B >=3B>=3B ________________________________
>=3B >= =3B>=3B From: Satyam Sinha [mailto:satyamsinha@live.com]
>=3B >=3B= >=3B Sent: Friday=2C August 14=2C 2009 5:23 PM
>=3B >=3B>=3B To:= Vishwas Manral=3B Shahram Davari
>=3B >=3B>=3B Cc: rtg-bfd@ietf.o= rg
>=3B >=3B>=3B Subject: RE: DOWN state
>=3B >=3B>=3B>=3B >=3B>=3B Hi Shahram=2C
>=3B >=3B>=3B
>=3B >=3B&= gt=3B Comments inline....
>=3B >=3B>=3B
>=3B >=3B>=3B>= =3B Date: Fri=2C 14 Aug 2009 16:42:36 -0700
>=3B >=3B>=3B>=3B Su= bject: Re: DOWN state
>=3B >=3B>=3B>=3B From: vishwas.ietf@gmail= .com
>=3B >=3B>=3B>=3B To: davari@broadcom.com
>=3B >=3B&= gt=3B>=3B CC: rtg-bfd@ietf.org
>=3B >=3B>=3B>=3B
>=3B >= =3B>=3B>=3B Hi Saharam=2C
>=3B >=3B>=3B>=3B
>=3B >=3B= >=3B>=3B On Fri=2C Aug 14=2C 2009 at 3:49 PM=2C Shahram Davari<=3Bdav= ari@broadcom.com>=3B
>=3B >=3B>=3B>=3B wrote:
>=3B >=3B= >=3B>=3B >=3B Hi=2C
>=3B >=3B>=3B>=3B >=3B
>=3B >= =3B>=3B>=3B >=3B The based draft sys that if BFD Control packet is no= t received during
>=3B >=3B>=3B>=3B >=3B any
>=3B >=3B&= gt=3B>=3B >=3B Detection Interval then the local system will go to Down= state.
>=3B >=3B>=3B>=3B >=3B I have two questions:
>=3B= >=3B>=3B>=3B >=3B
>=3B >=3B>=3B>=3B >=3B 1) When can = the local system transition out of Down state? Is it after
>=3B >=3B= >=3B>=3B >=3B receiving the first BFD packet with State=3DDOWN or INI= T? or a number of
>=3B >=3B>=3B>=3B >=3B such
>=3B >=3B= >=3B>=3B >=3B BFD packets are required? in other words is there a Hys= teresis?
>=3B >=3B>=3B>=3B No hysteresis is required as such.>=3B >=3B>=3B
>=3B >=3B>=3B Any hysteresis would actually b= e a violation of the "Section 6.2 BFD
>=3B >=3B>=3B state-machine"= .
>=3B >=3B>=3B
>=3B >=3B>=3B Down state means that the s= ession is down (or has just been created.)
>=3B >=3B>=3B =3B = =3BA session remains in Down state until the remote system indicates>=3B >=3B>=3B =3B =3Bthat it agrees that the session is d= own by sending a BFD Control
>=3B >=3B>=3B =3B =3Bpacket= with the State field set to anything other than Up.
>=3B >=3B>=3B=
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B >=3B 2) = =3BShould the =3Bremote system apply =3B =3Ba sliding window fo= r Detection Time
>=3B >=3B>=3B>=3B >=3B or
>=3B >=3B>= =3B>=3B >=3B fixed slotted windows that are not overlapped are acceptab= le?
>=3B >=3B>=3B>=3B What does the window contain? (I understan= d you are trying to do
>=3B >=3B>=3B>=3B something similar to TC= P). Are you using a mechanism like that for
>=3B >=3B>=3B>=3B ec= ho packets?
>=3B >=3B>=3B
>=3B >=3B>=3B From a transmit p= erspective=2C if you take into account jitter=2C one should
>=3B >= =3B>=3B have the timers as sliding window based. One should schedule the = next
>=3B >=3B>=3B transmit at last-transmit-time + tx-timer (jitt= ered) instead of
>=3B >=3B>=3B expected-last-transmit-time + tx-ti= mer (jittered). The variance in the
>=3B >=3B>=3B jitter alongwith= slotted window usage between two transmits could cause the
>=3B >= =3B>=3B tx-time between two packets to be more than the tx-timer. When th= e
>=3B >=3B>=3B multiplier=3D1=2C such a variance could make your = session go down.
>=3B >=3B>=3B
>=3B >=3B>=3B From a recei= ve perspective you could do either. If you used slotted windows=2C
>= =3B >=3B>=3B you might see more than one packet in a slot but you are s= till guaranteed to
>=3B >=3B>=3B see atleast one packet every slot= .
>=3B >=3B>=3B
>=3B >=3B>=3B Regards=2C
>=3B >=3B= >=3B
>=3B >=3B>=3B Satyam
>=3B >=3B>=3B
>=3B >= =3B>=3B ________________________________
>=3B >=3B>=3B Get your = vacation photos on your phone! Click here.
>=3B >=3B
>=3B >= =3B
>=3B >=3B

Get back to school stuff for them and c= ashback for you. Try BingT now. = --_743f564b-c9b0-4718-b6ea-a8a81ccab2a2_-- From dkatz@juniper.net Mon Aug 17 14:46:20 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7D13A6CB4 for ; Mon, 17 Aug 2009 14:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ltFt9SxWGro for ; Mon, 17 Aug 2009 14:46:19 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 3E0AF3A688D for ; Mon, 17 Aug 2009 14:46:18 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSonPrklUFrNM438y9Bcu7ZfOusljeMRg@postini.com; Mon, 17 Aug 2009 14:46:24 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 17 Aug 2009 14:42:48 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 14:42:48 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 14:42:47 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 14:42:47 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7HLgk079481; Mon, 17 Aug 2009 14:42:46 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <6051167D-134E-4EC5-92EE-397D0DD80E31@juniper.net> From: Dave Katz To: Satyam Sinha In-Reply-To: Content-Type: multipart/alternative; boundary="Apple-Mail-4--492257201" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: DOWN state Date: Mon, 17 Aug 2009 15:42:45 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD6815050D601@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908141642y32b35b08iac7cc9f9086d4038@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370890@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908171143o437566delf4ab999f82078465@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370898@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0908171204t9702a07v25c7af342fa9c95c@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2009 21:42:47.0042 (UTC) FILETIME=[A9064E20:01CA1F83] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 21:46:20 -0000 --Apple-Mail-4--492257201 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I'll make this more clear in the spec, which I'm spinning at the moment. Note that the new spec is going to make jitter mandatory rather than optional (MUST rather than SHOULD). This is necessary in order for the congestion avoidance algorithm that's being added to work. (The IESG required that a congestion avoidance algorithm be specified.) --Dave On Aug 17, 2009, at 1:16 PM, Satyam Sinha wrote: > I agree with Vishwas. This is indeed per packet basis. > > Satyam > > > Date: Mon, 17 Aug 2009 12:04:54 -0700 > > Subject: Re: DOWN state > > From: vishwas.ietf@gmail.com > > To: davari@broadcom.com > > CC: satyamsinha@live.com; rtg-bfd@ietf.org > > > > Hi Shahram, > > > > It would be best to apply it per packet. Self synchronization in > this > > case would send timers for all sessions expiring symultaneously and > > thus the load on the system/ network traffic not being uniform but > > having peaks and troughs. > > > > Thanks, > > Vishwas > > > > On Mon, Aug 17, 2009 at 11:50 AM, Shahram > Davari wrote: > > > Hi Vishwas, > > > > > > Thanks for your answer. But I just want to understand the > requirements. Is it required to calculate Jitter > > > Per BFD packet or it can be calculated once per BFD session and > applied to all packets of that session? > > > > > > The base draft says the reason for applying Jitter is to avoid > synchronization mean. What does self synchronization mean here? > > > > > > > > > Thanks, > > > Shahram > > > > > > -----Original Message----- > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > > Sent: Monday, August 17, 2009 11:44 AM > > > To: Shahram Davari > > > Cc: Satyam Sinha; rtg-bfd@ietf.org > > > Subject: Re: DOWN state > > > > > > Hi Shahram, > > > > > > The more the randomness the more evenly distributed is the > packet send > > > operation. > > > > > > I understand your concern from the hardware perspective. It need > not > > > however be the same level of pseudo-randomness as required for > > > security algorithms, which require specialized hardware for the > same. > > > > > > Thanks, > > > Vishwas > > > > > > On Mon, Aug 17, 2009 at 11:32 AM, Shahram Davari > wrote: > > >> Hi Satayam, > > >> > > >> Are you saying that the Jitter is calculated and applied per > BFD packet? or > > >> it is calculated once per session and applied to all packets of > that > > >> session? > > >> For example can one packet of a BFD session be jittered by 10% > and another > > >> one by 20%? > > >> > > >> Thanks, > > >> Shahram > > >> ________________________________ > > >> From: Satyam Sinha [mailto:satyamsinha@live.com] > > >> Sent: Friday, August 14, 2009 5:23 PM > > >> To: Vishwas Manral; Shahram Davari > > >> Cc: rtg-bfd@ietf.org > > >> Subject: RE: DOWN state > > >> > > >> Hi Shahram, > > >> > > >> Comments inline.... > > >> > > >>> Date: Fri, 14 Aug 2009 16:42:36 -0700 > > >>> Subject: Re: DOWN state > > >>> From: vishwas.ietf@gmail.com > > >>> To: davari@broadcom.com > > >>> CC: rtg-bfd@ietf.org > > >>> > > >>> Hi Saharam, > > >>> > > >>> On Fri, Aug 14, 2009 at 3:49 PM, Shahram Davari > > > >>> wrote: > > >>> > Hi, > > >>> > > > >>> > The based draft sys that if BFD Control packet is not > received during > > >>> > any > > >>> > Detection Interval then the local system will go to Down > state. > > >>> > I have two questions: > > >>> > > > >>> > 1) When can the local system transition out of Down state? > Is it after > > >>> > receiving the first BFD packet with State=DOWN or INIT? or a > number of > > >>> > such > > >>> > BFD packets are required? in other words is there a > Hysteresis? > > >>> No hysteresis is required as such. > > >> > > >> Any hysteresis would actually be a violation of the "Section > 6.2 BFD > > >> state-machine". > > >> > > >> Down state means that the session is down (or has just been > created.) > > >> A session remains in Down state until the remote system > indicates > > >> that it agrees that the session is down by sending a BFD > Control > > >> packet with the State field set to anything other than Up. > > >> > > >>> > > >>> > 2) Should the remote system apply a sliding window for > Detection Time > > >>> > or > > >>> > fixed slotted windows that are not overlapped are acceptable? > > >>> What does the window contain? (I understand you are trying to do > > >>> something similar to TCP). Are you using a mechanism like that > for > > >>> echo packets? > > >> > > >> From a transmit perspective, if you take into account jitter, > one should > > >> have the timers as sliding window based. One should schedule > the next > > >> transmit at last-transmit-time + tx-timer (jittered) instead of > > >> expected-last-transmit-time + tx-timer (jittered). The variance > in the > > >> jitter alongwith slotted window usage between two transmits > could cause the > > >> tx-time between two packets to be more than the tx-timer. When > the > > >> multiplier=1, such a variance could make your session go down. > > >> > > >> From a receive perspective you could do either. If you used > slotted windows, > > >> you might see more than one packet in a slot but you are still > guaranteed to > > >> see atleast one packet every slot. > > >> > > >> Regards, > > >> > > >> Satyam > > >> > > >> ________________________________ > > >> Get your vacation photos on your phone! Click here. > > > > > > > > > > > Get back to school stuff for them and cashback for you. Try BingT now. --Apple-Mail-4--492257201 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I'll make this more clear in = the spec, which I'm spinning at the moment.

Note that = the new spec is going to make jitter mandatory rather than optional = (MUST rather than SHOULD). This is necessary in order for the = congestion avoidance algorithm that's being added to work. (The = IESG required that a congestion avoidance algorithm be = specified.)

--Dave

On = Aug 17, 2009, at 1:16 PM, Satyam Sinha wrote:

I agree with Vishwas. = This is indeed per packet basis.

Satyam

> Date: Mon, 17 = Aug 2009 12:04:54 -0700
> Subject: Re: DOWN state
> = From: vishwas.ietf@gmail.com
> = To: davari@broadcom.com
> = CC: satyamsinha@live.com; rtg-bfd@ietf.org
>
> Hi = Shahram,
>
> It would be best = to apply it per packet. Self synchronization in this
> case would = send timers for all sessions expiring symultaneously and
> thus = the load on the system/ network traffic not being uniform but
> = having peaks and troughs.
>
> Thanks,
> = Vishwas
>
>= On Mon, Aug 17, 2009 at 11:50 AM, Shahram Davari<davari@broadcom.com> = wrote:
> > Hi Vishwas,
> >
> > Thanks for = your answer. But I just want to understand the requirements. Is it = required to calculate Jitter
> > Per BFD packet or it can be = calculated once per BFD session and applied to all packets of that = session?
> >
> > The base draft says the reason for = applying Jitter is to avoid synchronization mean. What does self = synchronization mean here?
> >
> >
> > = Thanks,
> > Shahram
> >
> > -----Original = Message-----
> > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]<= br>> > Sent: Monday, August 17, 2009 11:44 AM
> > To: = Shahram Davari
> > Cc: Satyam Sinha; rtg-bfd@ietf.org
> > = Subject: Re: DOWN state
> >
> > Hi Shahram,
> = >
> > The more the randomness the more evenly distributed is = the packet send
> > operation.
> >
> > I = understand your concern from the hardware perspective. It need = not
> > however be the same level of pseudo-randomness as = required for
> > security algorithms, which require specialized = hardware for the same.
> >
> > Thanks,
> > = Vishwas
> >
> > On Mon, Aug 17, 2009 at 11:32 AM, = Shahram Davari<davari@broadcom.com> = wrote:
> >> Hi Satayam,
> >>
> >> = Are you saying that the Jitter is calculated and applied per BFD packet? = or
> >> it is calculated once per session and applied to all = packets of that
> >> session?
> >> For example = can one packet of a BFD session be jittered by 10% and another
> = >> one by 20%?
> >>
> >> Thanks,
> = >> Shahram
> >> = ________________________________
> >> From: Satyam Sinha [mailto:satyamsinha@live.com]
&= gt; >> Sent: Friday, August 14, 2009 5:23 PM
> >> To: = Vishwas Manral; Shahram Davari
> >> Cc: rtg-bfd@ietf.org
> >> = Subject: RE: DOWN state
> >>
> >> Hi = Shahram,
> >>
> >> Comments inline....
> = >>
> >>> Date: Fri, 14 Aug 2009 16:42:36 = -0700
> >>> Subject: Re: DOWN state
> >>> = From: vishwas.ietf@gmail.com
> = >>> To: davari@broadcom.com
> = >>> CC: rtg-bfd@ietf.org
> = >>>
> >>> Hi Saharam,
> = >>>
> >>> On Fri, Aug 14, 2009 at 3:49 PM, = Shahram Davari<davari@broadcom.com>
> = >>> wrote:
> >>> > Hi,
> >>> = >
> >>> > The based draft sys that if BFD Control = packet is not received during
> >>> > any
> = >>> > Detection Interval then the local system will go to = Down state.
> >>> > I have two questions:
> = >>> >
> >>> > 1) When can the local system = transition out of Down state? Is it after
> >>> > = receiving the first BFD packet with State=3DDOWN or INIT? or a number = of
> >>> > such
> >>> > BFD packets = are required? in other words is there a Hysteresis?
> >>> = No hysteresis is required as such.
> >>
> >> Any = hysteresis would actually be a violation of the "Section 6.2 BFD
> = >> state-machine".
> >>
> >> Down state = means that the session is down (or has just been created.)
> = >> A session remains in Down state until the remote = system indicates
> >> that it agrees that the = session is down by sending a BFD Control
> >> = packet with the State field set to anything other than Up.
> = >>
> >>>
> >>> > 2) Should = the remote system apply a sliding window for Detection = Time
> >>> > or
> >>> > fixed = slotted windows that are not overlapped are acceptable?
> = >>> What does the window contain? (I understand you are trying = to do
> >>> something similar to TCP). Are you using a = mechanism like that for
> >>> echo packets?
> = >>
> >> =46rom a transmit perspective, if you take = into account jitter, one should
> >> have the timers as = sliding window based. One should schedule the next
> >> = transmit at last-transmit-time + tx-timer (jittered) instead of
> = >> expected-last-transmit-time + tx-timer (jittered). The variance = in the
> >> jitter alongwith slotted window usage between = two transmits could cause the
> >> tx-time between two = packets to be more than the tx-timer. When the
> >> = multiplier=3D1, such a variance could make your session go down.
> = >>
> >> =46rom a receive perspective you could do = either. If you used slotted windows,
> >> you might see more = than one packet in a slot but you are still guaranteed to
> = >> see atleast one packet every slot.
> >>
> = >> Regards,
> >>
> >> Satyam
> = >>
> >> ________________________________
> = >> Get your vacation photos on your phone! Click here.
> = >
> >
> >

Get back to school stuff for = them and cashback for you. Try BingT = now.

= --Apple-Mail-4--492257201-- From vishwas.ietf@gmail.com Mon Aug 17 16:34:53 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D4128C2DA for ; Mon, 17 Aug 2009 16:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36heWihISKCq for ; Mon, 17 Aug 2009 16:34:53 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 1B0ED28C22F for ; Mon, 17 Aug 2009 16:34:28 -0700 (PDT) Received: by ywh26 with SMTP id 26so4320001ywh.5 for ; Mon, 17 Aug 2009 16:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M7u70iz2nRftcTgGBZosj/9rNpBYvmvepOqc6q00Wyo=; b=wMm5whWmk30uuQ3cdlnDxDsmAxL/hxT7EvsmTEgDD5UCuyphdF4QthETBvgjjGMIeG 4cYt+rUdGdUYTFUvutwqAvP29lEFe/aEBNoGbZMdZpdxatU2JL8WssbS2tfkzlq/J0ov oNvfq19OCauGKHG5hSDnEE48bEeEWud/LzGbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x9OY1IPqmnjTBunX1K1eVcssvR1gM8hzQJq5e/3sP6bx6qsGSGN9tp68BfqivJJ2hN rb4kAAhlqf8/GK15cDZeFHmACqo40gQ8YTZYFeuJ+E3+Ew8Dyr8H1iHOFTjE1bbbbj47 tiKww2XVdk7es/DWE65CtBGR0G2JdS+lsMk6g= MIME-Version: 1.0 Received: by 10.150.62.4 with SMTP id k4mr6643127yba.251.1250552070581; Mon, 17 Aug 2009 16:34:30 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157370896@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD68157370896@SJEXCHCCR02.corp.ad.broadcom.com> Date: Mon, 17 Aug 2009 16:34:30 -0700 Message-ID: <77ead0ec0908171634n183a9bedj78f3a5a355b469bd@mail.gmail.com> Subject: Re: BFD for MPLS From: Vishwas Manral To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 23:34:53 -0000 Hi Shahram, The document section 6 states the below: "To establish a BFD session a LSP-Ping echo request message MUST carry the local discriminator assigned by the ingress LSR for the BFD session. This MUST subsequently be used as the My Discriminator field in the BFD session packets sent by the ingress LSR." Thanks, Vishwas On Mon, Aug 17, 2009 at 11:45 AM, Shahram Davari wrote: > Hi, > > Section 4 of draft-ietf-bfd-mpls-07 says: > > "If the LSP is associated with Multiple FECs, a BFD session SHOULD be > established for each FEC" > > But this doesn't seem to be correct, since BFD can only check the LSP and is > unaware of the FECs mapped to the LSP. > > Am I missing something? > > Thanks, > Shahram From vishwas.ietf@gmail.com Mon Aug 17 16:49:58 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79323A6F67 for ; Mon, 17 Aug 2009 16:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3hjFcV-5s+x for ; Mon, 17 Aug 2009 16:49:58 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 371BC3A6DB5 for ; Mon, 17 Aug 2009 16:49:58 -0700 (PDT) Received: by gxk17 with SMTP id 17so4283489gxk.19 for ; Mon, 17 Aug 2009 16:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=v8+YVVQYRg00Q3gySLXvyo5zraOVw2ZwEtGadVFFTbA=; b=ezdypLqcR1nih/0/RG+kPZqIQ9Fbk0fgVMOaswebHFeRozwvTAVpjOUKnKAgDrJBSX kd1JQLsQtcEemTpGUPbK56Nm2ReVCBQcsbHF9uKcHX+6/zyM2OwOS5Ncl3yxCKKzER7P OLTJaVPswnJkINVLHFbIpedZOBducznfcd220= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=mNIcZ9XPVqpzWU6vXOy+Q7uVD5qA5roo1ErQbhOOfy1uJgy+74FjWD6kstvqGaFRT0 J2UWgp9HBZSQ709R30LhZXVei7RwI7lXWkqwRmUqLfw/HCkVNU1d4FOv6nSjXlAluW09 IKVOR2vdsWVGVOQtRB/Qy09EzhQ5JzkInoero= MIME-Version: 1.0 Received: by 10.151.86.15 with SMTP id o15mr6656472ybl.193.1250552996481; Mon, 17 Aug 2009 16:49:56 -0700 (PDT) Date: Mon, 17 Aug 2009 16:49:56 -0700 Message-ID: <77ead0ec0908171649h67a18ec4ic76d0a48f6f92013@mail.gmail.com> Subject: BFD For MPLS LSPs From: Vishwas Manral To: rtg-bfd@ietf.org, rahul@juniper.net, Kireeti Kompella , Thomas Nadeau , George Swallow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 23:49:59 -0000 Hi authors, I noticed you have wrongly used the address "0:0:0:0:0:FFFF:7F00/104" which is not a valid IPv6 address. Can you use the addresse as defined in the draft-ietf-pwe3-vccv-bfd-07? It has been agreed upon when we had a discussion between Carlos, Brian Carpenter and I (for the other drafts that use the same wrong address). Thanks, Vishwas From davari@broadcom.com Mon Aug 17 18:23:40 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD64A28C216 for ; Mon, 17 Aug 2009 18:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6vBoWVdKUp7 for ; Mon, 17 Aug 2009 18:23:37 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 28B8228C20D for ; Mon, 17 Aug 2009 18:23:37 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 17 Aug 2009 18:23:33 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Mon, 17 Aug 2009 18:23:33 -0700 From: "Shahram Davari" To: "rtg-bfd@ietf.org" Date: Mon, 17 Aug 2009 18:23:31 -0700 Subject: Authentication Question Thread-Topic: Authentication Question Thread-Index: AcoflXYzEzxvwIT3QdiZkTH7a/ZTKwADE3fg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD681573708D8@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0908171649h67a18ec4ic76d0a48f6f92013@mail.gmail.com> In-Reply-To: <77ead0ec0908171649h67a18ec4ic76d0a48f6f92013@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6694DD1F60083272069-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 18 Aug 2009 01:23:40 -0000 Hi, For BFD processing, the Base text says: "If the A bit is set and no authentication is in use (bfd.AuthType is zero)= , the packet MUST be discarded." Isn't the bdf.AuthType set based on the A bit? If so then isn't this statem= ent a circular logic? Shouldn't it be changed to: "If the A bit is set and no authentication is in use (Authentication header= is not present), the packet MUST be discarded." And a general question. Since each packet is Authenticated on its own, can = Authentication type change in the middle of a Session? Or can some BFD pack= ets be transmitted with Authentication and some without (off course with pr= oper setting of A flag)? Thanks, Shahram= From vishwas.ietf@gmail.com Mon Aug 17 20:19:58 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F22F3A6A2A for ; Mon, 17 Aug 2009 20:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE9C1HBRgFcQ for ; Mon, 17 Aug 2009 20:19:57 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) by core3.amsl.com (Postfix) with ESMTP id 6A5AC3A6D2D for ; Mon, 17 Aug 2009 20:19:57 -0700 (PDT) Received: by yxe3 with SMTP id 3so387687yxe.29 for ; Mon, 17 Aug 2009 20:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RihuYGe450Plr7zazRGM7wrPXAEohbXG6wfJi2AmpMY=; b=Ky/FbTHmqaAL7AHdrPy02XVEJi0pMUJXTZKTQqOEvl0KOT/p960OHMLze+4cY6bxk7 ObFD/ryP/1Bbu27CQfYJeoMKb2ln4Ln6RdzZmPOKDn9rGxZUuG0P06ibI04lUBeNWINt xXDH2KtVt1M6gZoc5Mmj6YNeaMZqTsHoXi2WU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=l/9LmhEdii8FS45C9StkX+ozy8yHGoEHfH+CHMzlpPS6/2VMhRUCGShIDADjmQIEu9 CBxqXEDiUd4+bhpIhjRnIm/dgNDRI+xC6dzKOb6C+Vfyd1d35j3BJr5v3CFntuNwVA+J LBrOSNy/p7e5BY1gOH0Z59ln68tjVKeDkMLL4= MIME-Version: 1.0 Received: by 10.150.63.16 with SMTP id l16mr7023528yba.12.1250565595794; Mon, 17 Aug 2009 20:19:55 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD681573708D8@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0908171649h67a18ec4ic76d0a48f6f92013@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD681573708D8@SJEXCHCCR02.corp.ad.broadcom.com> Date: Mon, 17 Aug 2009 20:19:55 -0700 Message-ID: <77ead0ec0908172019r205b752cqf1144a6cbf319716@mail.gmail.com> Subject: Re: Authentication Question From: Vishwas Manral To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 18 Aug 2009 03:19:58 -0000 Hi Shahram, I think the sentence is ok in the spec. Yes we should be able to change Keys as well. I think something related to that is given in the spec already. Thanks, Vishwas On Mon, Aug 17, 2009 at 6:23 PM, Shahram Davari wrote: > Hi, > > For BFD processing, the Base text says: > > "If the A bit is set and no authentication is in use (bfd.AuthType is zero), the packet MUST be discarded." > > Isn't the bdf.AuthType set based on the A bit? If so then isn't this statement a circular logic? Shouldn't it be changed to: > > "If the A bit is set and no authentication is in use (Authentication header is not present), the packet MUST be discarded." > > > And a general question. Since each packet is Authenticated on its own, can Authentication type change in the middle of a Session? Or can some BFD packets be transmitted with Authentication and some without (off course with proper setting of A flag)? > > Thanks, > Shahram > From dkatz@juniper.net Mon Aug 17 21:36:45 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CDB3A6DF1 for ; Mon, 17 Aug 2009 21:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j3SaOqtHVqd for ; Mon, 17 Aug 2009 21:36:44 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 975723A6841 for ; Mon, 17 Aug 2009 21:36:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSoov4A4u7QTyClByTvaKsgyw9y1BsazL@postini.com; Mon, 17 Aug 2009 21:36:50 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 17 Aug 2009 21:34:37 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 21:34:38 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 21:34:37 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 21:34:36 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7I4Ya089187; Mon, 17 Aug 2009 21:34:36 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <65DE7B08-77B7-4B78-BFDB-D57BF2FE23F2@juniper.net> From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD681573708D8@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Authentication Question Date: Mon, 17 Aug 2009 22:34:35 -0600 References: <77ead0ec0908171649h67a18ec4ic76d0a48f6f92013@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD681573708D8@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Aug 2009 04:34:36.0879 (UTC) FILETIME=[313C35F0:01CA1FBD] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 18 Aug 2009 04:36:45 -0000 On Aug 17, 2009, at 7:23 PM, Shahram Davari wrote: > Hi, > > For BFD processing, the Base text says: > > "If the A bit is set and no authentication is in use (bfd.AuthType > is zero), the packet MUST be discarded." > > Isn't the bdf.AuthType set based on the A bit? If so then isn't this > statement a circular logic? Shouldn't it be changed to: > > "If the A bit is set and no authentication is in use (Authentication > header is not present), the packet MUST be discarded." No. bfd.AuthType is the local authentication setting; the text you refer to deals with received packet processing. The check ensures that if the remote system is specifying authentication (A bit set) but the local system isn't doing authentication (bfd.AuthType is zero) the packet is tossed. The Authentication Header consistency check with the A bit comes a bit earlier in the acceptance tests (by examining the packet length.) > > > And a general question. Since each packet is Authenticated on its > own, can Authentication type change in the middle of a Session? Or > can some BFD packets be transmitted with Authentication and some > without (off course with proper setting of A flag)? No, because bfd.AuthType is going to be static and unsynchronized with the far end. See section 6.7.1 for a discussion on enabling and disabling authentication. --Dave > > Thanks, > Shahram > > From davari@broadcom.com Tue Aug 18 14:52:37 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FFE93A6BBC for ; Tue, 18 Aug 2009 14:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw9HpRRuKqAJ for ; Tue, 18 Aug 2009 14:52:37 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 0437E3A67B7 for ; Tue, 18 Aug 2009 14:52:36 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 18 Aug 2009 14:49:00 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 18 Aug 2009 14:49:00 -0700 From: "Shahram Davari" To: "rtg-bfd@ietf.org" Date: Tue, 18 Aug 2009 14:48:59 -0700 Subject: BFD Authentication Thread-Topic: BFD Authentication Thread-Index: AcogTbEU1gcJVuCBTbG2AVtKPRDfMQ== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD681573709A9@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6695FE4637020621209-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD681573709A9SJEXCHCCR02co_ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 18 Aug 2009 21:52:37 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD681573709A9SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, Reading through base draft, it seems that the suggested Authentication meth= ods (password, MD5 and SHA1) are all very weak authentications and not real= ly used any more. Is it too late to propose another simple but yet powerful= Authentication such as GMAC? Also since the Authentication Type is communicated in each packet does it m= ean that it is allowed to change Authentication type in the middle of a BFD= session? Thanks, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD681573709A9SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,

Reading t= hrough base=20 draft, it seems that the suggested Authentication methods (password, MD5 an= d=20 SHA1) are all very weak authentications and not really used any more. Is it= too=20 late to propose another simple but yet powerful Authentication such as=20 GMAC?

Also sinc= e the=20 Authentication Type is communicated in each packet does it mean that it is= =20 allowed to change Authentication type in the middle of a BFD=20 session?

Thanks,

Shahram

--_000_2C2F1EBA8050E74EA81502D5740B4BD681573709A9SJEXCHCCR02co_-- From dkatz@juniper.net Tue Aug 18 15:50:46 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7364E3A6B14 for ; Tue, 18 Aug 2009 15:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuxkgUMHpqQo for ; Tue, 18 Aug 2009 15:50:45 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 57FA13A6A17 for ; Tue, 18 Aug 2009 15:50:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSoswSuXdpE3KzZsp6SAU07j3JN6+mMLs@postini.com; Tue, 18 Aug 2009 15:50:51 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 18 Aug 2009 15:47:07 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 15:47:07 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 15:47:06 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 15:47:06 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7IMl5016287; Tue, 18 Aug 2009 15:47:05 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <60C76E7A-21C8-4F46-8EDC-374CCA9A66F7@juniper.net> From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD681573709A9@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="Apple-Mail-1--401998702" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: BFD Authentication Date: Tue, 18 Aug 2009 16:47:04 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD681573709A9@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Aug 2009 22:47:06.0048 (UTC) FILETIME=[CF95A400:01CA2055] Cc: "rtg-bfd@ietf.org"

Detect Mult

"Detection time multiplier. The= =20 negotiated transmit interval, multi= plied=20 by this value, provides the Detection Time for the transmitting system in Asynchronous mode= ."

May be=20 you could explain it in the following example:

A=20 ------------------------------->B
A<------------------------------= --B

BFD=20 packets send from A --> B:

Detect=20 Mult=3DA1, Desired Min Tx Interval =3D A2, Require Min RX Interval=20 =3DA3

BFD=20 packets send from B --> A:

Detect=20 Mult=3DB1, Desired Min Tx Interval =3D B2, Require Min RX Interval=20 =3DB3

The=20 Detection Window at B =3D A1 * Max (A2, B3)

The Detection Window at A =3D B1 * M= ax (B2,=20 A3)

Is this computation correct?

T<= SPAN=20 class=3D792490317-19082009>hanks,=

Shahram

From: David Ward [mailto:dward@cisco.co= m]=20
Sent: Tuesday, August 18, 2009 10:22 PM
To: Shahram=20 Davari
Cc: David Ward; rtg-bfd@ietf.org
Subject: Re:=20 Parameter change

Shahram -

6.8 and 10 clearly state that the rules of 6.8.3 apply. I don't believ= e=20 there is a need for more verbiage than exists.

6.8.12 is discussing a different attribute, the detect multiplier. It= =20 clearly states that a poll sequence is not necessary. This should be obviou= s as=20 the detectmult is a local matter and doesn't affect anything on the remote= =20 end.

You do need to use the poll sequence in all cases. Demand mode setting= is=20 orthogonal.

-DWard

On Aug 18, 2009, at 9:30 PM, Shahram Davari wrote:

Hi,

There i= s a=20 discrepancy in the base draft regarding when any of the BFD parameter cha= nges.=20 Section 6.8.10, 11 and 12 say that poll sequence is not required when=20 bfd.DesiredMinTxInterval or bfd.RequiredMinRxInterval are cha= nged,=20 while section 6.8.3 says:

" If=20 either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval i= s=20 changed, a Poll Sequence MUST be initiated (see section=20 6.5)"

Which o= ne is=20 correct? If not in demand mode is there any need to initiate Poll if any = of=20 the local parameters change?

Thanks,

Shahram

--_000_2C2F1EBA8050E74EA81502D5740B4BD68157370A8DSJEXCHCCR02co_-- From dkatz@juniper.net Wed Aug 19 11:21:29 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047D23A68CE for ; Wed, 19 Aug 2009 11:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SJdOmgfp2VT for ; Wed, 19 Aug 2009 11:21:27 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 7D1693A6ADD for ; Wed, 19 Aug 2009 11:21:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSoxCq128hdXqvVHFdQaEabT8At/p6nly@postini.com; Wed, 19 Aug 2009 11:21:33 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 19 Aug 2009 11:14:26 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 11:14:26 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 11:14:25 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 11:14:25 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7JIEO045351; Wed, 19 Aug 2009 11:14:24 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <240845C5-DAAF-49CA-AE93-F755ACB5F982@juniper.net> From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157370A8D@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="Apple-Mail-5--331958815" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Parameter change Date: Wed, 19 Aug 2009 12:14:24 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD681573709C0@SJEXCHCCR02.corp.ad.broadcom.com> <82A71445-BDEA-4B53-8ACC-16C8F85300B6@cisco.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370A8D@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Aug 2009 18:14:25.0349 (UTC) FILETIME=[E242D750:01CA20F8] Cc: "rtg-bfd@ietf.org" , David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 19 Aug 2009 18:21:29 -0000 --Apple-Mail-5--331958815 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit DaveW misspoke slightly. Your computation is correct. There is no need for a poll sequence when the multiplier is changed because the timing of the packet transmission doesn't change. The poll sequence is needed to coordinate timing changes if the packet transmission interval might change, as the detection time change needs to be coordinated with the transmission rate change so that the session doesn't fail by mistake. --Dave On Aug 19, 2009, at 11:28 AM, Shahram Davari wrote: > Hi David, > > I thought Detection Multiplier is a parameter sent by a local system > to a remote system, so that the remote system can compute the > Detection Interval Timer. What do you mean by "Detection Multiplier > is a Local matter"? If it is a local matter then why is it > communicated to the remote system? > > I think I am not clear on the definition of Detection Multiplier. > The base draft defines it as: > > Detect Mult > > "Detection time multiplier. The negotiated transmit interval, > multiplied by this value, provides the Detection Time for the > transmitting system in Asynchronous mode." > > > May be you could explain it in the following example: > > A ------------------------------->B > A<--------------------------------B > > BFD packets send from A --> B: > > Detect Mult=A1, Desired Min Tx Interval = A2, Require Min RX > Interval =A3 > > BFD packets send from B --> A: > > Detect Mult=B1, Desired Min Tx Interval = B2, Require Min RX > Interval =B3 > > The Detection Window at B = A1 * Max (A2, B3) > > The Detection Window at A = B1 * Max (B2, A3) > > Is this computation correct? > > Thanks, > Shahram > > From: David Ward [mailto:dward@cisco.com] > Sent: Tuesday, August 18, 2009 10:22 PM > To: Shahram Davari > Cc: David Ward; rtg-bfd@ietf.org > Subject: Re: Parameter change > > Shahram - > > 6.8 and 10 clearly state that the rules of 6.8.3 apply. I don't > believe there is a need for more verbiage than exists. > > 6.8.12 is discussing a different attribute, the detect multiplier. > It clearly states that a poll sequence is not necessary. This should > be obvious as the detectmult is a local matter and doesn't affect > anything on the remote end. > > You do need to use the poll sequence in all cases. Demand mode > setting is orthogonal. > > -DWard > > On Aug 18, 2009, at 9:30 PM, Shahram Davari wrote: > >> Hi, >> >> There is a discrepancy in the base draft regarding when any of the >> BFD parameter changes. Section 6.8.10, 11 and 12 say that poll >> sequence is not required when bfd.DesiredMinTxInterval or >> bfd.RequiredMinRxInterval are changed, while section 6.8.3 says: >> >> " If either bfd.DesiredMinTxInterval is changed or >> bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be >> initiated (see section 6.5)" >> >> Which one is correct? If not in demand mode is there any need to >> initiate Poll if any of the local parameters change? >> >> Thanks, >> Shahram > --Apple-Mail-5--331958815 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable DaveW misspoke = slightly.

Your computation is = correct.

There is no need for a poll sequence = when the multiplier is changed because the timing of the packet = transmission doesn't change.

The poll sequence = is needed to coordinate timing changes if the packet transmission = interval might change, as the detection time change needs to be = coordinated with the transmission rate change so that the session = doesn't fail by = mistake.

--Dave

On Aug = 19, 2009, at 11:28 AM, Shahram Davari wrote:

Hi David,

I thought Detection Multiplier is a parameter sent by a local = system to a remote system, so that the remote system can compute the = Detection Interval Timer. What do you mean by "Detection Multiplier is a = Local matter"? If it is a local matter then why is it communicated to = the remote system?

I think I am not clear on the definition of Detection = Multiplier. The base draft defines it as:

Detect = Mult
"Detection time = multiplier. The negotiated transmit interval, multiplied by this value, provides = the Detection Time for the = transmitting system in Asynchronous mode."

May be you could explain it in the following = example:
A = ------------------------------->B
A<-----------------------------= ---B
BFD packets send from A = --> B:
Detect Mult=3DA1, Desired = Min Tx Interval =3D A2, Require Min RX Interval = =3DA3
BFD packets send from B --> A: =
Detect Mult=3DB1, Desired = Min Tx Interval =3D B2, Require Min RX Interval = =3DB3
The = Detection Window at B =3D A1 * Max = (A2, B3)
The Detection Window at A = =3D B1 * Max (B2, = A3)

Is this computation correct?

Thanks,

Shahram

From: David Ward [mailto:dward@cisco.com] =
Sent: Tuesday, August 18, 2009 10:22 PM
To: Shahram = Davari
Cc: David Ward; rtg-bfd@ietf.org
Subject: = Re: Parameter change

Shahram - =

6.8 and 10 clearly state that the rules of 6.8.3 = apply. I don't believe there is a need for more verbiage than = exists.

6.8.12 is discussing a = different attribute, the detect multiplier. It clearly states that a = poll sequence is not necessary. This should be obvious as the detectmult = is a local matter and doesn't affect anything on the remote end.
=

You do need to use the poll sequence in all cases. = Demand mode setting is orthogonal.

=
-DWard

On Aug 18, 2009, at 9:30 = PM, Shahram Davari wrote:

=

Hi,
=

There is a = discrepancy in the base draft regarding when any of the BFD parameter = changes. Section 6.8.10, 11 and 12 say that poll sequence is not = required when bfd.DesiredMinTxInterval or = bfd.RequiredMinRxInterval are changed, while section 6.8.3 = says:

" If either bfd.DesiredMinTxInterval is changed or = bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be = initiated (see section 6.5)"

Which one = is correct? If not in demand mode is there any need to initiate Poll = if any of the local parameters change?

Thanks,

Shahram

= --Apple-Mail-5--331958815-- From davari@broadcom.com Wed Aug 19 11:52:00 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24FB3A6C4C for ; Wed, 19 Aug 2009 11:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMb6RD0FvUKm for ; Wed, 19 Aug 2009 11:51:58 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id D13233A67DB for ; Wed, 19 Aug 2009 11:51:58 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 19 Aug 2009 11:51:48 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Wed, 19 Aug 2009 11:51:48 -0700 From: "Shahram Davari" To: "Dave Katz" Date: Wed, 19 Aug 2009 11:51:47 -0700 Subject: RE: Parameter change Thread-Topic: Parameter change Thread-Index: Acog+eSsekhs9BV2R7ameQY/uqZ/VgAA0ZkA Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157370AAC@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD681573709C0@SJEXCHCCR02.corp.ad.broadcom.com> <82A71445-BDEA-4B53-8ACC-16C8F85300B6@cisco.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370A8D@SJEXCHCCR02.corp.ad.broadcom.com> <240845C5-DAAF-49CA-AE93-F755ACB5F982@juniper.net> In-Reply-To: <240845C5-DAAF-49CA-AE93-F755ACB5F982@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6692964E37021768162-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD68157370AACSJEXCHCCR02co_ Cc: "rtg-bfd@ietf.org" , David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 19 Aug 2009 18:52:00 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD68157370AACSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Dave K, But the draft says" provides the Detection Time for the transmitting system= ". Shouldn't this be changed to "provides the Detection Time for the receiv= ing system" Yours, Shahram ________________________________ From: Dave Katz [mailto:dkatz@juniper.net] Sent: Wednesday, August 19, 2009 11:14 AM To: Shahram Davari Cc: David Ward; rtg-bfd@ietf.org Subject: Re: Parameter change DaveW misspoke slightly. Your computation is correct. There is no need for a poll sequence when the multiplier is changed because= the timing of the packet transmission doesn't change. The poll sequence is needed to coordinate timing changes if the packet tran= smission interval might change, as the detection time change needs to be co= ordinated with the transmission rate change so that the session doesn't fai= l by mistake. --Dave On Aug 19, 2009, at 11:28 AM, Shahram Davari wrote: Hi David, I thought Detection Multiplier is a parameter sent by a local system to a r= emote system, so that the remote system can compute the Detection Interval = Timer. What do you mean by "Detection Multiplier is a Local matter"? If it = is a local matter then why is it communicated to the remote system? I think I am not clear on the definition of Detection Multiplier. The base = draft defines it as: Detect Mult "Detection time multiplier. The negotiated transmit interval, multiplied by= this value, provides the Detection Time for the transmitting system in Asy= nchronous mode." May be you could explain it in the following example: A ------------------------------->B A<--------------------------------B BFD packets send from A --> B: Detect Mult=3DA1, Desired Min Tx Interval =3D A2, Require Min RX Interval = =3DA3 BFD packets send from B --> A: Detect Mult=3DB1, Desired Min Tx Interval =3D B2, Require Min RX Interval = =3DB3 The Detection Window at B =3D A1 * Max (A2, B3) The Detection Window at A =3D B1 * Max (B2, A3) Is this computation correct? Thanks, Shahram ________________________________ From: David Ward [mailto:dward@cisco.com] Sent: Tuesday, August 18, 2009 10:22 PM To: Shahram Davari Cc: David Ward; rtg-bfd@ietf.org Subject: Re: Parameter change Shahram - 6.8 and 10 clearly state that the rules of 6.8.3 apply. I don't believe the= re is a need for more verbiage than exists. 6.8.12 is discussing a different attribute, the detect multiplier. It clear= ly states that a poll sequence is not necessary. This should be obvious as = the detectmult is a local matter and doesn't affect anything on the remote = end. You do need to use the poll sequence in all cases. Demand mode setting is o= rthogonal. -DWard On Aug 18, 2009, at 9:30 PM, Shahram Davari wrote: Hi, There is a discrepancy in the base draft regarding when any of the BFD para= meter changes. Section 6.8.10, 11 and 12 say that poll sequence is not requ= ired when bfd.DesiredMinTxInterval or bfd.RequiredMinRxInterval are chang= ed, while section 6.8.3 says: " If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterva= l is changed, a Poll Sequence MUST be initiated (see section 6.5)" Which one is correct? If not in demand mode is there any need to initiate P= oll if any of the local parameters change? Thanks, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD68157370AACSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi=20 Dave K,

But=20 the draft says" pro= vides the=20 Detection Time for the transmitting= =20 system". Shouldn't this be changed to "provides the Detection Tim= e for=20 the receiving=20 system"

Yours,

Shahram

From: Dave Katz [mailto:dkatz@juniper.n= et]=20
Sent: Wednesday, August 19, 2009 11:14 AM
To: Shahram= =20 Davari
Cc: David Ward; rtg-bfd@ietf.org
Subject: Re:=20 Parameter change

DaveW misspoke slightly.

Your computation is correct.

There is no need for a poll sequence when the multiplier is changed be= cause=20 the timing of the packet transmission doesn't change.

The poll sequence is needed to coordinate timing changes if the packet= =20 transmission interval might change, as the detection time change needs to b= e=20 coordinated with the transmission rate change so that the session doesn't f= ail=20 by mistake.

--Dave

On Aug 19, 2009, at 11:28 AM, Shahram Davari wrote:

Hi=20 David,

I=20 thought Detection Multiplier is a parameter sent by a local system to a r= emote=20 system, so that the remote system can compute the Detection Interval Time= r.=20 What do you mean by "Detection Multiplier is a Local matter"? If it is a = local=20 matter then why is it communicated to the remote system?

I=20 think I am not clear on the definition of Detection Multiplier. The base = draft=20 defines it as:

Detect Mult

"Detection time multiplier. Th= e=20 negotiated transmit interval, mul= tiplied=20 by this value, provides the Detection Time for the transmitting system in Asynchronous=20 mode."

May be=20 you could explain it in the following example:

A=20 ------------------------------->B
A<----------------------------= ----B

BFD=20 packets send from A --> B:

Detect=20 Mult=3DA1, Desired Min Tx Interval =3D A2, Require Min RX Interval=20 =3DA3
<= FONT=20 face=3DArial color=3D#0000ff size=3D2>
BFD=20 packets send from B --> A:

Detect=20 Mult=3DB1, Desired Min Tx Interval =3D B2, Require Min RX Interval=20 =3DB3

The=20 Detection Window at B =3D A1 * Max (A2, B3)=

The Detection Window at A =3D B1 *= Max (B2,=20 A3)

Is this computation correct?=

Thanks,

Shahram

From: David Ward [mailto:dward@cisco.com]
Sent:<= /B>=20 Tuesday, August 18, 2009 10:22 PM
To: Shahram Davari
Cc:<= /B>=20 David Ward; rtg-bfd@ietf.org
Subject: = Re:=20 Parameter change

Shahram -=20

6.8 and 10 clearly state that the rules of 6.8.3 apply. I don't beli= eve=20 there is a need for more verbiage than exists.

6.8.12 is discussing a different attribute, the detect multiplier. I= t=20 clearly states that a poll sequence is not necessary. This should be obvi= ous=20 as the detectmult is a local matter and doesn't affect anything on the re= mote=20 end.

You do need to use the poll sequence in all cases. Demand mode setti= ng is=20 orthogonal.

-DWard

On Aug 18, 2009, at 9:30 PM, Shahram Davari wrote:

Hi,

There= is a=20 discrepancy in the base draft regarding when any of the BFD parameter=20 changes. Section 6.8.10, 11 and 12 say that poll sequence is not requir= ed=20 when bfd.DesiredMinTxInterval or bfd.RequiredMinRxInterval = are=20 changed, while section 6.8.3 says:

" If either bfd.DesiredMinTxInterval is changed or=20 bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated= (see=20 section 6.5)"

Which= one is=20 correct? If not in demand mode is there any need to initiate Poll if an= y of=20 the local parameters change?

Thanks,

Shahram

--_000_2C2F1EBA8050E74EA81502D5740B4BD68157370AACSJEXCHCCR02co_-- From dkatz@juniper.net Wed Aug 19 13:28:05 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF3E3A6B82 for ; Wed, 19 Aug 2009 13:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lkSsCnx6GWP for ; Wed, 19 Aug 2009 13:28:04 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id D5A913A6D0B for ; Wed, 19 Aug 2009 13:28:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSoxgWJ1XcYWs5k8O44w7ln+Lcc2gFySH@postini.com; Wed, 19 Aug 2009 13:28:09 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 19 Aug 2009 13:20:17 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 13:20:17 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 13:20:16 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 13:20:16 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7JKKF048834; Wed, 19 Aug 2009 13:20:15 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157370AAC@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="Apple-Mail-8--324408112" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Parameter change Date: Wed, 19 Aug 2009 14:20:15 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD681573709C0@SJEXCHCCR02.corp.ad.broadcom.com> <82A71445-BDEA-4B53-8ACC-16C8F85300B6@cisco.com> <2C2F1EBA8050E74EA81502D5740B4BD68157370A8D@SJEXCHCCR02.corp.ad.broadcom.com> <240845C5-DAAF-49CA-AE93-F755ACB5F982@juniper.net> <2C2F1EBA8050E74EA81502D5740B4BD68157370AAC@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Aug 2009 20:20:16.0123 (UTC) FILETIME=[76DF84B0:01CA210A] Cc: "rtg-bfd@ietf.org" , David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 19 Aug 2009 20:28:05 -0000 --Apple-Mail-8--324408112 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Right you are, fixed in the next version. --Dave On Aug 19, 2009, at 12:51 PM, Shahram Davari wrote: > Hi Dave K, > > But the draft says" provides the Detection Time for the transmitting > system". Shouldn't this be changed to "provides the Detection Time > for the receiving system" > > Yours, > Shahram > > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Wednesday, August 19, 2009 11:14 AM > To: Shahram Davari > Cc: David Ward; rtg-bfd@ietf.org > Subject: Re: Parameter change > > DaveW misspoke slightly. > > Your computation is correct. > > There is no need for a poll sequence when the multiplier is changed > because the timing of the packet transmission doesn't change. > > The poll sequence is needed to coordinate timing changes if the > packet transmission interval might change, as the detection time > change needs to be coordinated with the transmission rate change so > that the session doesn't fail by mistake. > > --Dave > > On Aug 19, 2009, at 11:28 AM, Shahram Davari wrote: > >> Hi David, >> >> I thought Detection Multiplier is a parameter sent by a local >> system to a remote system, so that the remote system can compute >> the Detection Interval Timer. What do you mean by "Detection >> Multiplier is a Local matter"? If it is a local matter then why is >> it communicated to the remote system? >> >> I think I am not clear on the definition of Detection Multiplier. >> The base draft defines it as: >> >> Detect Mult >> >> "Detection time multiplier. The negotiated transmit interval, >> multiplied by this value, provides the Detection Time for the >> transmitting system in Asynchronous mode." >> >> >> >> May be you could explain it in the following example: >> >> A ------------------------------->B >> A<--------------------------------B >> >> BFD packets send from A --> B: >> >> Detect Mult=A1, Desired Min Tx Interval = A2, Require Min RX >> Interval =A3 >> >> BFD packets send from B --> A: >> >> Detect Mult=B1, Desired Min Tx Interval = B2, Require Min RX >> Interval =B3 >> >> The Detection Window at B = A1 * Max (A2, B3) >> >> The Detection Window at A = B1 * Max (B2, A3) >> >> Is this computation correct? >> >> Thanks, >> Shahram >> >> From: David Ward [mailto:dward@cisco.com] >> Sent: Tuesday, August 18, 2009 10:22 PM >> To: Shahram Davari >> Cc: David Ward; rtg-bfd@ietf.org >> Subject: Re: Parameter change >> >> Shahram - >> >> 6.8 and 10 clearly state that the rules of 6.8.3 apply. I don't >> believe there is a need for more verbiage than exists. >> >> 6.8.12 is discussing a different attribute, the detect multiplier. >> It clearly states that a poll sequence is not necessary. This >> should be obvious as the detectmult is a local matter and doesn't >> affect anything on the remote end. >> >> You do need to use the poll sequence in all cases. Demand mode >> setting is orthogonal. >> >> -DWard >> >> On Aug 18, 2009, at 9:30 PM, Shahram Davari wrote: >> >>> Hi, >>> >>> There is a discrepancy in the base draft regarding when any of the >>> BFD parameter changes. Section 6.8.10, 11 and 12 say that poll >>> sequence is not required when bfd.DesiredMinTxInterval or >>> bfd.RequiredMinRxInterval are changed, while section 6.8.3 says: >>> >>> " If either bfd.DesiredMinTxInterval is changed or >>> bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be >>> initiated (see section 6.5)" >>> >>> Which one is correct? If not in demand mode is there any need to >>> initiate Poll if any of the local parameters change? >>> >>> Thanks, >>> Shahram >> > --Apple-Mail-8--324408112 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Right you are, fixed in the = next version.

--Dave

On Aug = 19, 2009, at 12:51 PM, Shahram Davari wrote:

Hi Dave K,

But the draft says" provides the Detection Time for the transmitting = system". Shouldn't this be changed to "provides the Detection = Time for the receiving = system"

Yours,

Shahram

=
From: Dave = Katz [mailto:dkatz@juniper.net] =
Sent: Wednesday, August 19, 2009 11:14 AM
To: = Shahram Davari
Cc: David Ward; rtg-bfd@ietf.org
Subject: = Re: Parameter change

DaveW misspoke = slightly.

Your computation is correct.
=

There is no need for a poll sequence when the = multiplier is changed because the timing of the packet transmission = doesn't change.

The poll sequence is needed = to coordinate timing changes if the packet transmission interval might = change, as the detection time change needs to be coordinated with the = transmission rate change so that the session doesn't fail by = mistake.

--Dave

On = Aug 19, 2009, at 11:28 AM, Shahram Davari wrote:

Hi David,

I thought Detection Multiplier is a parameter sent by a = local system to a remote system, so that the remote system can compute = the Detection Interval Timer. What do you mean by "Detection = Multiplier is a Local matter"? If it is a local matter then why is it = communicated to the remote system?

I think I am not clear on the definition of Detection = Multiplier. The base draft defines it as:
=

Detect = Mult
"Detection time = multiplier. The negotiated transmit interval, multiplied by this value, = provides the Detection Time for the = transmitting system in Asynchronous mode."

May be you could explain it in the following = example:
A = ------------------------------->B
A<-----------------------------= ---B
BFD packets send from A = --> B:
Detect Mult=3DA1, Desired = Min Tx Interval =3D A2, Require Min RX Interval = =3DA3
BFD packets send from B --> A: =
Detect Mult=3DB1, Desired = Min Tx Interval =3D B2, Require Min RX Interval = =3DB3
The = Detection Window at B =3D A1 * Max = (A2, B3)
The Detection Window at A = =3D B1 * Max (B2, = A3)

Is this computation correct?

Thanks,

Shahram

From: David Ward [mailto:dward@cisco.com] =
Sent: Tuesday, August 18, 2009 10:22 PM
To: = Shahram Davari
Cc: David Ward; rtg-bfd@ietf.org
Subject: = Re: Parameter change

Shahram - =

6.8 and 10 clearly state that the rules of 6.8.3 = apply. I don't believe there is a need for more verbiage than = exists.

6.8.12 is discussing a = different attribute, the detect multiplier. It clearly states that a = poll sequence is not necessary. This should be obvious as the = detectmult is a local matter and doesn't affect anything on the remote = end.

You do need to use the poll sequence = in all cases. Demand mode setting is orthogonal.
=

-DWard

On Aug = 18, 2009, at 9:30 PM, Shahram Davari wrote:

=

Hi,

There is a = discrepancy in the base draft regarding when any of the BFD parameter = changes. Section 6.8.10, 11 and 12 say that poll sequence is not = required when bfd.DesiredMinTxInterval or = bfd.RequiredMinRxInterval are changed, while section 6.8.3 = says:

" If either bfd.DesiredMinTxInterval is changed or = bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated = (see section 6.5)"

Which one = is correct? If not in demand mode is there any need to initiate Poll = if any of the local parameters change?
=

Thanks,

Shahram

= --Apple-Mail-8--324408112-- From davari@broadcom.com Thu Aug 20 11:25:39 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81DB3A672E for ; Thu, 20 Aug 2009 11:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgOWNHtD4T04 for ; Thu, 20 Aug 2009 11:25:39 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id EA5893A69A2 for ; Thu, 20 Aug 2009 11:25:38 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 20 Aug 2009 11:22:52 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 20 Aug 2009 11:22:52 -0700 From: "Shahram Davari" To: "rtg-bfd@ietf.org" Date: Thu, 20 Aug 2009 11:22:50 -0700 Subject: bfd.AuthType Thread-Topic: bfd.AuthType Thread-Index: AcohwznuW2ZWChRrQ+OaU6QBemJLFg== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157370BAD@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66934BF63WW41612674-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD68157370BADSJEXCHCCR02co_ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 18:25:39 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD68157370BADSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I have a question regarding Authentication. The BFD reception rules say: "If the A bit is set and no authentication is in use (bfd.AuthType is zero)= , the packet MUST be discarded." "If the A bit is clear and authentication is in use (bfd.AuthType is nonzer= o), the packet MUST be discarded." How do we know the value of bfd.AuthType? Is it a configured value or is it= derived from the "Auth Type" field of the received BFD packets? if it is d= erived from received BFD packets the value zero is reserved for "Auth Type"= and is not defined. Any explanations? Also I noticed that the text says SHA1 is mandatory and others are optional= . Which SHA1 does it mean? the Keyed or Meticulous Keyed SHA1? Can we chang= e then Mandatory to Simple Password? Thanks, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD68157370BADSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi,

I have a = question=20 regarding Authentication. The BFD reception rules say:

"If the A=20 bit is set and no authentication is in use (bfd.AuthType is zero), the packet MUST be discarded.<= SPAN=20 class=3D022371518-20082009>"

"If the A bit is clear and authentic= ation=20 is in use (bfd.AuthType is nonzero)= , the=20 packet MUST be discarded."

How do we know the value of bfd.AuthTyp= e? Is=20 it a configured value or is it derived from the "Auth Type" field of the=20 received BFD packets? if it is derived from received BFD packets the value = zero=20 is reserved for "Auth Type" and is not defined.

Any=20 explanations?

Also I noti= ced that=20 the text says SHA1 is mandatory and others are optional. Which SHA1 does it= =20 mean? the Keyed or Meticulous Keyed SHA1? Can we change then Mandatory to S= imple=20 Password?

Thanks,

Shahram
--_000_2C2F1EBA8050E74EA81502D5740B4BD68157370BADSJEXCHCCR02co_-- From vishwas.ietf@gmail.com Thu Aug 20 11:37:06 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6AD3A6F5A for ; Thu, 20 Aug 2009 11:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoCFZRy3uE0E for ; Thu, 20 Aug 2009 11:37:06 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) by core3.amsl.com (Postfix) with ESMTP id D63FC3A6E28 for ; Thu, 20 Aug 2009 11:37:05 -0700 (PDT) Received: by yxe3 with SMTP id 3so117694yxe.29 for ; Thu, 20 Aug 2009 11:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uicRjIVn/5197JzmHftoYxmSHtO7oHoObYeHWHeW5j4=; b=UGoW5312V+fO7YB7xBEcC9N1Gmcgu+m2GepHz/V2cu6GsoIoM8cHcvyE2EB4VX4MmN oc3hhygjaCjv/7JBjcOsLoSdMfcqBc0K4/mgOa8zFReZYYwFUmgEv70nqI7ulm/OrgRi oOa6kbcXJckwn4hbPrpbEXkuJcn1VGY+L8SuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tiWvwyKk42PkYSL0sjeiB3Oahqvuh01Gzmm8ImrfKtltP67ory2rjXWjcaoBWCNkqh 1wHjh2zO/ANlEf+v+TYQUXJOAlpfqmaPP81UPEjI+J98yKOrCs/mJCSfRvYR1pyxQIvE wxrtRJS7a5nUnzc6AJe+rt9GRlodIG7dHA7uU= MIME-Version: 1.0 Received: by 10.151.87.18 with SMTP id p18mr292025ybl.342.1250793350806; Thu, 20 Aug 2009 11:35:50 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157370BAD@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD68157370BAD@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 20 Aug 2009 11:35:50 -0700 Message-ID: <77ead0ec0908201135h54cd6caeledd6fdb195afdd2a@mail.gmail.com> Subject: Re: bfd.AuthType From: Vishwas Manral To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 18:37:06 -0000 Hi Shahram, Its an interesting way you have put the question. The way I see it is, if Authentication is enabled on an interface we expect the packet to have the A-bit set, however if we do not get a packet with the A bit clear we discard the packet. There have been issues raised regarding the security in BFD, because of which we have written another draft. We intend to make meticulously keyed HMAC-SHA-1 to be a MUST in the future. Thanks, Vishwas On Thu, Aug 20, 2009 at 11:22 AM, Shahram Davari wrote= : > Hi, > > I have a question regarding Authentication. The BFD reception rules say: > > > "If the A bit is set and no authentication is in use (bfd.AuthType is zer= o), > the packet MUST be discarded." > > "If=A0the A bit is clear and authentication is in use (bfd.AuthType is > nonzero), the packet MUST be discarded." > > How do we know the value of bfd.AuthType? Is it a configured value or is = it > derived from the "Auth Type" field of the received BFD packets? if it is > derived from received BFD packets the value zero is reserved for "Auth Ty= pe" > and is not defined. > > Any explanations? > > Also I noticed that the text says SHA1 is mandatory and others are option= al. > Which SHA1 does it mean? the Keyed or Meticulous Keyed SHA1? Can we chang= e > then Mandatory to Simple Password? > > Thanks, > > Shahram From dkatz@juniper.net Thu Aug 20 13:19:46 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B653A6D07 for ; Thu, 20 Aug 2009 13:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag9jsUWGMSsx for ; Thu, 20 Aug 2009 13:19:45 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 270043A6AD3 for ; Thu, 20 Aug 2009 13:19:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSo2vy9us/VgNwcUmxramfyMUWWZuDwcw@postini.com; Thu, 20 Aug 2009 13:19:51 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 20 Aug 2009 13:10:24 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 13:10:24 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 13:10:23 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 13:10:23 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7KKAM084889; Thu, 20 Aug 2009 13:10:23 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157370BAD@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="Apple-Mail-20--238601118" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: bfd.AuthType Date: Thu, 20 Aug 2009 14:10:22 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD68157370BAD@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Aug 2009 20:10:23.0287 (UTC) FILETIME=[3FEDAC70:01CA21D2] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 20:19:46 -0000 --Apple-Mail-20--238601118 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 20, 2009, at 12:22 PM, Shahram Davari wrote: > Hi, > > I have a question regarding Authentication. The BFD reception rules > say: > > "If the A bit is set and no authentication is in use (bfd.AuthType > is zero), the packet MUST be discarded." > > "If the A bit is clear and authentication is in use (bfd.AuthType is > nonzero), the packet MUST be discarded." > > How do we know the value of bfd.AuthType? Is it a configured value > or is it derived from the "Auth Type" field of the received BFD > packets? if it is derived from received BFD packets the value zero > is reserved for "Auth Type" and is not defined. > It's a known value outside of the spec; configuration is one way to do it. > Any explanations? > > Also I noticed that the text says SHA1 is mandatory and others are > optional. Which SHA1 does it mean? the Keyed or Meticulous Keyed > SHA1? Can we change then Mandatory to Simple Password? > SHA1 is mandatory to implement (for interoperability) but not to deploy. The spec is ambiguous as to regular vs. meticulous; I'll fix it to say that both must be supported (99.9% of the work is in the hash algorithm itself; the difference between regular and meticulous is a few lines of code.) --Dave > Thanks, > > Shahram > --Apple-Mail-20--238601118 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
On Aug 20, 2009, = at 12:22 PM, Shahram Davari wrote:

=
Hi,

I have a = question regarding Authentication. The BFD reception rules = say:

"If the A bit is set and no = authentication is in use (bfd.AuthType = is zero), the packet MUST be discarded."
"If the A bit is clear and = authentication is in use (bfd.AuthType = is nonzero), the packet MUST be discarded."
How do we know the value of bfd.AuthType? = Is it a configured value or is it derived from the "Auth Type" field of = the received BFD packets? if it is derived from received BFD packets the = value zero is reserved for "Auth Type" and is not = defined.
It's= a known value outside of the spec; configuration is one way to do = it.

Any = explanations?
Also I noticed that the text says SHA1 is = mandatory and others are optional. Which SHA1 does it mean? the Keyed or = Meticulous Keyed SHA1? Can we change then Mandatory to Simple = Password?
<= div>SHA1 is mandatory to implement (for interoperability) but not to = deploy. The spec is ambiguous as to regular vs. meticulous; = I'll fix it to say that both must be supported (99.9% of the work = is in the hash algorithm itself; the difference between regular = and meticulous is a few lines of = code.)

--Dave

Thanks,
Shahram

= --Apple-Mail-20--238601118-- From davari@broadcom.com Thu Aug 27 12:41:59 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0B73A6E85 for ; Thu, 27 Aug 2009 12:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huRII8-C726p for ; Thu, 27 Aug 2009 12:41:58 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 58E9D3A6C19 for ; Thu, 27 Aug 2009 12:41:58 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 27 Aug 2009 12:39:32 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 27 Aug 2009 12:39:32 -0700 From: "Shahram Davari" To: "rtg-bfd@ietf.org" Date: Thu, 27 Aug 2009 12:39:31 -0700 Subject: Demand Mode Thread-Topic: Demand Mode Thread-Index: AconThj0kQz8IezJRmKQxesxkrfeMA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD681573710E1@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66883F7E60095695268-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD681573710E1SJEXCHCCR02co_ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 27 Aug 2009 19:41:59 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD681573710E1SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, What happens if a system is in Demand Mode and UP state and then due to som= e reason it exists the UP state? Does it automatically cause the local syst= em to also exit the Demand mode? if so should this be signaled in the "D" b= it? Also When in Demand mode, if a system wants to check connectivity, should i= t issue periodic Poll packets at the Max {bfd.RemoteMinRxInterval, bfd.Desi= redMinTxInterval} or it can send Poll packets at any rate or it must send o= ne BFD packets and wait for the reception of the Final packet (or expiry of= Detection Time) before sending the next BFD packet? Thanks, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD681573710E1SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi,

What happens if a system is in Demand Mode and UP state and then du= e to=20 some reason it exists the UP state? Does it automatically cause the local s= ystem=20 to also exit the Demand mode? if so should this be signaled in the "D"=20 bit?

Also When= in Demand=20 mode, if a system wants to check connectivity, should it issue periodic Pol= l=20 packets at the Max {bfd.RemoteMinRxInterval, bfd.DesiredMinTxInterval} or i= t can=20 send Poll packets at any rate or it must send one BFD packets and wait for = the=20 reception of the Final packet (or expiry of Detection Time) before sending = the=20 next BFD packet?

Thanks,

Shahram
--_000_2C2F1EBA8050E74EA81502D5740B4BD681573710E1SJEXCHCCR02co_-- From dkatz@juniper.net Thu Aug 27 16:04:01 2009 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE1A3A6E9C for ; Thu, 27 Aug 2009 16:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxNkKV68ITlw for ; Thu, 27 Aug 2009 16:04:01 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id EA2B33A69ED for ; Thu, 27 Aug 2009 16:04:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSpcQ52Zy6EZvzq/SP3VQJTJrvOwjOAQA@postini.com; Thu, 27 Aug 2009 16:04:08 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 27 Aug 2009 16:01:15 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 16:01:15 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 16:01:14 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 16:01:13 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n7RN1D043678; Thu, 27 Aug 2009 16:01:13 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Shahram Davari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD681573710E1@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="Apple-Mail-8-376449815" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Demand Mode Date: Thu, 27 Aug 2009 17:01:12 -0600 References: <2C2F1EBA8050E74EA81502D5740B4BD681573710E1@SJEXCHCCR02.corp.ad.broadcom.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Aug 2009 23:01:13.0949 (UTC) FILETIME=[46B0D0D0:01CA276A] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 27 Aug 2009 23:04:02 -0000 --Apple-Mail-8-376449815 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 27, 2009, at 1:39 PM, Shahram Davari wrote: > Hi, > > What happens if a system is in Demand Mode and UP state and then due > to some reason it exists the UP state? Does it automatically cause > the local system to also exit the Demand mode? if so should this be > signaled in the "D" bit? Please read the spec: Note that the Demand bit MUST NOT be set unless both systems perceive the session to be Up (the local system thinks the session is Up, and the remote system last reported Up state in the State (Sta) field of the BFD Control packet.) > > Also When in Demand mode, if a system wants to check connectivity, > should it issue periodic Poll packets at the Max > {bfd.RemoteMinRxInterval, bfd.DesiredMinTxInterval} or it can send > Poll packets at any rate or it must send one BFD packets and wait > for the reception of the Final packet (or expiry of Detection Time) > before sending the next BFD packet? Please read the spec: A Poll Sequence consists of a system sending periodic BFD Control packets with the Poll (P) bit set. > > Thanks, > Shahram --Apple-Mail-8-376449815 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
On Aug 27, 2009, = at 1:39 PM, Shahram Davari wrote:

=
Hi,

What happens if a system is in Demand Mode and UP state and = then due to some reason it exists the UP state? Does it automatically = cause the local system to also exit the Demand mode? if so should this = be signaled in the "D" = bit?

Please = read the spec:

   Note = that
   the Demand bit MUST NOT be set unless both = systems perceive the
   session to be Up (the local = system thinks the session is Up, and the
   remote = system last reported Up state in the State (Sta) field of = the
   BFD Control = packet.)

Also When = in Demand mode, if a system wants to check connectivity, should it issue = periodic Poll packets at the Max {bfd.RemoteMinRxInterval, = bfd.DesiredMinTxInterval} or it can send Poll packets at any rate or it = must send one BFD packets and wait for the reception of the Final packet = (or expiry of Detection Time) before sending the next BFD = packet?

Please read the spec:

   A Poll = Sequence consists of a system sending periodic BFD = Control
   packets with the Poll (P) bit set. =

Thanks,

Shahram

= = --Apple-Mail-8-376449815--