Re: BFD spec updates

[Vishwas Manral <[e-mail]>]

Hi Dave,

>> Ok it is like this. When you calculate the hash you actually use 64
>> bits, but the higher order 32 bits are assumed to be known. So we
>> start with 0 and as the lower order sequence wraps around, both ends
>> increment the higher order bits. So the number is implicitly known to
>> the two ends but never sent across. So we can only be exchanging 32
>> bit numbers but using 64 bit numbers for hash calculations.
>>
>> An older packet replayed will not work if the higher order bits do not
>> match as the sequence numbers will not match.
>
> Ah, got it.  This would be an incompatible change to the protocol, though it
> is effectively the same as changing the shared key.  An implementation is
> free to add one to the shared key every time the sequence number rolls over
> and do so without changing the spec.
No, but the hash we currently use only uses a 32-bit sequence number
so it will not work. If we want the mechanism we need to specify where
we need to keep the higher order bits when calculating the hash.

>>>
>> Let me dig deeper and see if I find something. Also let me see if I
>> remember some other issues I have had with the implementation.
>>
>> One interesting one was if the slow timer value configured is actually
>> faster than the tx/ rx interval used and we change the inactivity
>> interval (detect interval - but you could call it an off scenario).
>
> I'm not sure I follow.  Do you mean if you're using 1 second intervals
> during session bringup but then use 10 second intervals when the session is
> established?  Seems like the poll sequence thing should take care of it.
>  (Note that if you want 10 second intervals when the session is up, you're
> free to negotiate 10 second intervals while down as well;  the spec just
> says "at least [one second]" and either end can unilaterally push back on
> the interval.
>
Thats exactly how it should be done. In the sense we do not use the
new interval till we have completed the poll sequence. I found all
these issues while testing that is why informing you in case if it is
of help

Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9C13A6808 for <[e-mail]>; Tue,  3 Feb 2009 16:50:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.148
X-Spam-Level: 
X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.451,  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 GU1WCjD6TFs5 for <[e-mail]>; Tue,  3 Feb 2009 16:50:26 -0800 (PST)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 22F0D3A67DD for <[e-mail]>; Tue,  3 Feb 2009 16:50:26 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSYjmNkGPZUeDuodUK1BNgjj/[e-mail]; Tue, 03 Feb 2009 16:50:07 PST
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.336.0; Tue, 3 Feb 2009 16:49:13 -0800
Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Feb 2009 16:49:13 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: Re: draft-palanivelan-bfd-v2-gr-01
Date: Tue, 3 Feb 2009 16:49:12 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: draft-palanivelan-bfd-v2-gr-01
Thread-Index: AcmGYmVThhxLBgEuTGCCrADrG/c6fQ==
From: Nitin Bahadur <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 04 Feb 2009 00:49:13.0476 (UTC) FILETIME=[661B6C40:01C98662]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 00:50:27 -0000

Hi,

  You really do not need GR extensions to BFD to help with
planned restart. There is enough text in draft-ietf-bfd-generic=20
(Section 4.3.2.2) to help you accomplish what you want.

 At the top of my head, I can think of 2 ways:

1) Restarting router brings down BFD session with diag code of
   ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency
   on the peer. So the peer BFD session will go down but ISIS/OSPF
   will not treat it as an adjacency down event.

2) Restarting router increases the BFD session timer to XXX=20
   seconds (XXX > restart time). It can save some state locally
   to note this. After restart, the restarting router reads the local
   state and continues the BFD session from the UP state.
  =20
Thanks
Nitin


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE663A6875 for <[e-mail]>; Tue,  3 Feb 2009 17:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j2OgKy6214V for <[e-mail]>; Tue,  3 Feb 2009 17:02:49 -0800 (PST)
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 1E95C3A67DB for <[e-mail]>; Tue,  3 Feb 2009 17:02:48 -0800 (PST)
Received: by fxm13 with SMTP id 13so2710000fxm.13 for <[e-mail]>; Tue, 03 Feb 2009 17:02:28 -0800 (PST)
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=WEkfKTPfXPCPdLUd7WlWxpNf/biWz0TCEkGRP1SvagA=; b=SD3YBY8xwHyJQ6xl6nd5tjk/svpxdGz4RxPcOJifW/AHRmmN+1mpbpDd91cfbWWYnH l0vCoQ24HHzmH5tWjwGm/nj2e143rUSaOGSYRG784iQ3U3tMeaND199jF2EivjfOq28L 95SpwgdvFv6eNkv7pvZsd5s8xMf3SqnAYnsD0=
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=rJFlv/QIwM1rfCLogBGnpcS+F9pTdvgn+75u/p3o/XPNU3jdqD1VR9rIHRmHWpmsXY 0iGY8be0BnyrFPik+gArK6eXDJVhQyhCMsss3VhODgXZBWrLHYR+Ml8yaud7kExNn6Q5 mikf0Z57Gjr4jDl5EsUZGeUh6FrqdxKpmQtK8=
MIME-Version: 1.0
Received: by 10.181.238.16 with SMTP id p16mr1308066bkr.112.1233709348325;  Tue, 03 Feb 2009 17:02:28 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 3 Feb 2009 17:02:28 -0800
Message-ID: <[e-mail]>
Subject: Re: draft-palanivelan-bfd-v2-gr-01
From: Vishwas Manral <[e-mail]>
To: Nitin Bahadur <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 01:02:50 -0000

Hi Nitin,

I agree with you. This is something like how we have done it too.

One small part is weeding out any sessions that were not updated in
the restart time.

Thanks,
Vishwas

On Tue, Feb 3, 2009 at 4:49 PM, Nitin Bahadur <[e-mail]> wrote:
> Hi,
>
>  You really do not need GR extensions to BFD to help with
> planned restart. There is enough text in draft-ietf-bfd-generic
> (Section 4.3.2.2) to help you accomplish what you want.
>
>  At the top of my head, I can think of 2 ways:
>
> 1) Restarting router brings down BFD session with diag code of
>   ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency
>   on the peer. So the peer BFD session will go down but ISIS/OSPF
>   will not treat it as an adjacency down event.
>
> 2) Restarting router increases the BFD session timer to XXX
>   seconds (XXX > restart time). It can save some state locally
>   to note this. After restart, the restarting router reads the local
>   state and continues the BFD session from the UP state.
>
> Thanks
> Nitin
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057D53A63D3 for <[e-mail]>; Tue,  3 Feb 2009 17:06:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 peyoCx4MKXbV for <[e-mail]>; Tue,  3 Feb 2009 17:06:56 -0800 (PST)
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 2EBF83A6809 for <[e-mail]>; Tue,  3 Feb 2009 17:06:52 -0800 (PST)
Received: by fxm13 with SMTP id 13so2711626fxm.13 for <[e-mail]>; Tue, 03 Feb 2009 17:06:31 -0800 (PST)
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=yZeEqlHjrLLS3T3XpX6f0V9ITsVLTlD2qZT909vORFM=; b=XOxAl8yPqbOF3uatyIwUXpXq/xRr7c4tMUQNaAW3Yv1zyaRh7kFvxvw1dw2zzcEm7+ GOlFVlob0X2dt3UoMgtfXZ5XR6yJwR2OrExbGZuMkPQFWYBeCrJoX4JeHeLEXJHZRBFo HXggFr66re0EuHPd+fyywNypeAju+nPQ0EnII=
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=WzeeTI9JnDuVPHA6ONKJqaQogovVvU433eOvGuJQ4qvaTmnOGAx1/05ejq0Fqrg89O qqpDTYjFa0kk/XM8dG0WZFa691dvrMrdN2sIIbZXgOK3VBeqt1Ip0EykkpQSRPHZ3zUo ksfnHpozNjF1hYN1Qob5p+y/iRxPwUvzXh5po=
MIME-Version: 1.0
Received: by 10.181.222.5 with SMTP id z5mr2285031bkq.151.1233709591763; Tue,  03 Feb 2009 17:06:31 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 3 Feb 2009 17:06:31 -0800
Message-ID: <[e-mail]>
Subject: Re: draft-palanivelan-bfd-v2-gr-01
From: Vishwas Manral <[e-mail]>
To: Nitin Bahadur <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 01:06:57 -0000

Hi Nitin,

Also note the first case may not work when BFD is sharing fate with
the control plane and we have an unplanned restart.

Thanks,
Vishwas

On Tue, Feb 3, 2009 at 5:02 PM, Vishwas Manral <[e-mail]> wrote:
> Hi Nitin,
>
> I agree with you. This is something like how we have done it too.
>
> One small part is weeding out any sessions that were not updated in
> the restart time.
>
> Thanks,
> Vishwas
>
> On Tue, Feb 3, 2009 at 4:49 PM, Nitin Bahadur <[e-mail]> wrote:
>> Hi,
>>
>>  You really do not need GR extensions to BFD to help with
>> planned restart. There is enough text in draft-ietf-bfd-generic
>> (Section 4.3.2.2) to help you accomplish what you want.
>>
>>  At the top of my head, I can think of 2 ways:
>>
>> 1) Restarting router brings down BFD session with diag code of
>>   ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency
>>   on the peer. So the peer BFD session will go down but ISIS/OSPF
>>   will not treat it as an adjacency down event.
>>
>> 2) Restarting router increases the BFD session timer to XXX
>>   seconds (XXX > restart time). It can save some state locally
>>   to note this. After restart, the restarting router reads the local
>>   state and continues the BFD session from the UP state.
>>
>> Thanks
>> Nitin
>>
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2132128C0F5 for <[e-mail]>; Wed,  4 Feb 2009 11:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Osby2axFyfYO for <[e-mail]>; Wed,  4 Feb 2009 11:23:40 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 7B19528C0ED for <[e-mail]>; Wed,  4 Feb 2009 11:23:39 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id l26so1296386fgb.41 for <[e-mail]>; Wed, 04 Feb 2009 11:23:18 -0800 (PST)
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:content-type :content-transfer-encoding; bh=el93vBU9qzPk0jTc7cNTJXlzltmhiMvBjM3DbrBuc48=; b=brrouPmQkEXMhutGDRaKIVmrbxAaO1P8z2DMVk9D6cvHf/7iVMFm1gbR1DWOz+6MUo GdsFiBGD32ct/b49Y9ZWLK99/jCcXRnAPHOER54JX7Q8buu5RIYfkFYhI9wuy+HzmUAB pYVytZgw3e6cA8hX2TyK9jaCcGkcfgXdzN99g=
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 :content-type:content-transfer-encoding; b=RNcPuGZV6eyYcJ+FtJuPr66rrisIBs2LfZJDb7z4Ms/RGz+05GgSqA2spEuM9360ig XZvmfbAkdAuVQvw95pHG/cp/IzWlcYLqbPE0+qjulEaUgUSMmSV//hgWALLp9mbI1kdo PxHM2Dx4P0okeGdatkvdF1eada4u/Z/04gRhI=
MIME-Version: 1.0
Received: by 10.181.197.1 with SMTP id z1mr481804bkp.118.1233775398471; Wed,  04 Feb 2009 11:23:18 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 4 Feb 2009 11:23:18 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 19:23:41 -0000

> Hi Dave,
>
> I think the detectection time interval is not correct at all. Let me
> quote a few parts of the text:
>
>   In Asynchronous mode, the Detection Time calculated in the local
>   system is equal to the value of Detect Mult received from the remote
>   system, multiplied by the agreed transmit interval of the remote
>   system (the greater of bfd.RequiredMinRxInterval and the last
>   received Desired Min TX Interval.)
>
> Also note that
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
> bfd.RemoteMinRxInterval.
>
> And note that we need to do a jitter of 0 to 25 % in the timer values.
> This means that the actual transmit interval has to be may be atleast
> 0 to 25% more than the larger of the Tx and RecvRx interval (let us
> call it actual receive interval ActTx).
>
> So if we have a detect Multiplier of 2, we will receive only 1 packet
> in the detect within the interval.
>
> So let us take a time line:
>
> At t1 a BFD packet is sent. The remote system receives the packet at
> t1 time (assuming 0 transit and processing time). The detection timer
> will be fired at t1 + (2 * ActTx time).
>
> The next packet will be sent at t1 + (actTx + random1) time. Assume
> this packet is lost.
>
> The next packet will be sent at t1 + (actTx + random1) + (actTx +
> random2). Only one packet will ever be ever received in the detect
> interval. So even if the detect multiplier is 2 a loss of 1 packet
> will cause the session down.
>
> I think to solve this issue as well as the specific case of detect
> mult 1. To calculate the detect interval we should use (recvd detect
> mult + 1) * ActTx and not recvd detect mult * ActTx.
>
> Here are some more comments below.
>
> 1. Shouldn't we on getting a packet with state UP, go to Init state.
>
>   "Init state means that the remote system is communicating, and the
>   local system desires to bring the session up, but the remote system
>   does not yet realize it."
>
> 2. Do we need to put some information about congestion control
> especially in the Multihop case.
>
> 3.  The draft states
>
>   One possible approach is to build an implementation such that
>   authentication is configured, but not considered "in use" until the
>   first packet containing a matching authentication section is received
>   (providing the necessary synchronization.)
>
> I do not know what it means by a matching authentication section. If
> it means enabling authentication once a packet with the A bit is set
> is got, then I think this is an easy way of DoS attacks. Send a packet
> with the A bit and the neighbors will not be able to communicate after
> that.
>
> 4. I do not see the way mentioned below as the right solution:
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
> bfd.RemoteMinRxInterval.
>
>   The periodic transmission of BFD Control packets SHOULD be jittered
>   by up to 25%, that is, the interval SHOULD be reduced by a random
>   value of 0 to 25%, in order to avoid self-synchronization.  Thus, the
>   average interval between packets may be up to 12.5% less than that
>   negotiated.
>
>   If bfd.DetectMult is equal to 1, the interval between transmitted BFD
>   Control packets MUST be no more than 90% of the negotiated
>   transmission interval, and MUST be no less than 75% of the negotiated
>   transmission interval.
>
> So if we have a DetectMult of 1. We have the bfd.RemoteMinRxInterval <
> bfd.DesiredMinTxInterval. The Remote system has no control of how fast
> the packets are sent. In my view in this case we should have the
> Remote system calculate the detection interval to be 25 % more than
> the actual detection interval however the Hellos are always sent at
> the right rate - never less than the minimum of the 2 intervals.
>
> 5. What is to be done to packets for which the Tx or Rx Interval is
> changed but the poll sequence is not initiated?
>
>   If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
>   the previous value of bfd.RequiredMinRxInterval MUST be used when
>   calculating the Detection Time for the remote system until the Poll
>   Sequence described above has terminated.
>
> Thanks,
> Vishwas
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C973A69F5 for <[e-mail]>; Wed,  4 Feb 2009 11:47:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.584
X-Spam-Level: 
X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015,  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 5UOtRqL15u-Q for <[e-mail]>; Wed,  4 Feb 2009 11:47:20 -0800 (PST)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 8E0313A69AB for <[e-mail]>; Wed,  4 Feb 2009 11:47:20 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSYnwrUJlDXYEdTlYQhUAH72xaS2Kve/[e-mail]; Wed, 04 Feb 2009 11:47:01 PST
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.336.0; Wed, 4 Feb 2009 11:44:08 -0800
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, 4 Feb 2009 11:44:08 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 11:44:08 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 11:44:06 -0800
Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n14Ji5M67452; Wed, 4 Feb 2009 11:44:05 -0800 (PST)	(envelope-from [e-mail])
Message-ID: <[e-mail]>
From: Dave Katz <[e-mail]>
To: Vishwas Manral <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 12:44:03 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 04 Feb 2009 19:44:06.0894 (UTC) FILETIME=[F0F270E0:01C98700]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 19:47:21 -0000

On Feb 4, 2009, at 12:23 PM, Vishwas Manral wrote:

>> Hi Dave,
>>
>> I think the detectection time interval is not correct at all. Let me
>> quote a few parts of the text:
>>
>>  In Asynchronous mode, the Detection Time calculated in the local
>>  system is equal to the value of Detect Mult received from the remote
>>  system, multiplied by the agreed transmit interval of the remote
>>  system (the greater of bfd.RequiredMinRxInterval and the last
>>  received Desired Min TX Interval.)
>>
>> Also note that
>>
>>  With the exceptions listed in the remainder of this
>>  section, a system MUST NOT transmit BFD Control packets at an
>>  interval less than the larger of bfd.DesiredMinTxInterval and
>> bfd.RemoteMinRxInterval.
>>
>> And note that we need to do a jitter of 0 to 25 % in the timer  
>> values.
>> This means that the actual transmit interval has to be may be atleast
>> 0 to 25% more than the larger of the Tx and RecvRx interval (let us
>> call it actual receive interval ActTx).

No; jitter is always *subtracted*.

    The periodic transmission of BFD Control packets SHOULD be jittered
    by up to 25%, that is, the interval SHOULD be reduced by a random
    value of 0 to 25%, in order to avoid self-synchronization.  Thus,  
the
    average interval between packets may be up to 12.5% less than that
    negotiated.

>>
>> 1. Shouldn't we on getting a packet with state UP, go to Init state.
>>
>>  "Init state means that the remote system is communicating, and the
>>  local system desires to bring the session up, but the remote system
>>  does not yet realize it."

No, we need a three-way handshake that ensures that both sides see the  
path fail:

    Once a session has been declared down, it cannot come back up until
    the remote end first signals that it is down (by leaving the Up
    state), thus implementing a three-way handshake.

>>
>>
>> 2. Do we need to put some information about congestion control
>> especially in the Multihop case.

The new draft (in internal review, to be popping out forthwith) has  
suitably vague language to the effect that the transmit interval  
manipulation is the necessary hook, and that particular algorithms do  
not impact interoperability and are therefore outside the scope of the  
spec.  Somebody can write a BCP if they like, but there's an  
opportunity for product differentiation here.

>>
>>
>> 3.  The draft states
>>
>>  One possible approach is to build an implementation such that
>>  authentication is configured, but not considered "in use" until the
>>  first packet containing a matching authentication section is  
>> received
>>  (providing the necessary synchronization.)
>>
>> I do not know what it means by a matching authentication section. If
>> it means enabling authentication once a packet with the A bit is set
>> is got, then I think this is an easy way of DoS attacks. Send a  
>> packet
>> with the A bit and the neighbors will not be able to communicate  
>> after
>> that.

The new draft has a bit more explicative language;  the idea of this  
whole thing was to provide a way for a network to transition to using  
authentication without tearing down sessions.  One would expect that  
someone would configure "I would like to do authentication when you're  
ready" at one end and then configure "I want to do configuration  
*now*" at the other end, and then authentication would be up and stay  
up.  This sensitivity to receiving an authenticated packet and turning  
it on is not meant to be the long-term state of the device, but a  
transition mechanism.  Also note that the DoS attack scenario is no  
worse than having no authentication at all.

>>
>>
>> 4. I do not see the way mentioned below as the right solution:
>>
>>  With the exceptions listed in the remainder of this
>>  section, a system MUST NOT transmit BFD Control packets at an
>>  interval less than the larger of bfd.DesiredMinTxInterval and
>> bfd.RemoteMinRxInterval.
>>
>>  The periodic transmission of BFD Control packets SHOULD be jittered
>>  by up to 25%, that is, the interval SHOULD be reduced by a random
>>  value of 0 to 25%, in order to avoid self-synchronization.  Thus,  
>> the
>>  average interval between packets may be up to 12.5% less than that
>>  negotiated.
>>
>>  If bfd.DetectMult is equal to 1, the interval between transmitted  
>> BFD
>>  Control packets MUST be no more than 90% of the negotiated
>>  transmission interval, and MUST be no less than 75% of the  
>> negotiated
>>  transmission interval.
>>
>> So if we have a DetectMult of 1. We have the  
>> bfd.RemoteMinRxInterval <
>> bfd.DesiredMinTxInterval. The Remote system has no control of how  
>> fast
>> the packets are sent.

Sure it does;  that's what bfd.RemoteMinRXInterval is for.  I don't  
see what you're saying here.

>> In my view in this case we should have the
>> Remote system calculate the detection interval to be 25 % more than
>> the actual detection interval however the Hellos are always sent at
>> the right rate - never less than the minimum of the 2 intervals.

I see no difference between this and the text as written, except that  
the packet transmission and detection are happening a little more  
slowly.  Raising the value of DesiredMinTxInterval by 25% or whatever  
would have the same effect.

>>
>>
>> 5. What is to be done to packets for which the Tx or Rx Interval is
>> changed but the poll sequence is not initiated?
>>
>>  If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
>>  the previous value of bfd.RequiredMinRxInterval MUST be used when
>>  calculating the Detection Time for the remote system until the Poll
>>  Sequence described above has terminated.

It's broken, and the transmission rate will not change, and the vendor  
will be humiliated in public for having an implementation that is  
seriously out of spec.

--Dave

>>
>>
>> Thanks,
>> Vishwas
>>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F713A683D for <[e-mail]>; Wed,  4 Feb 2009 12:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 UtB6t2LBDQan for <[e-mail]>; Wed,  4 Feb 2009 12:07:41 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id C70EC3A682B for <[e-mail]>; Wed,  4 Feb 2009 12:07:40 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id l26so1306422fgb.41 for <[e-mail]>; Wed, 04 Feb 2009 12:07:19 -0800 (PST)
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=JnaWU5lvepgsegoTeX1l4IMJY1mYHr8NDrF0RNiLIFM=; b=vOUeCNGodBDZBfHU+EUFP/4ss8+iShOM2j0zbBETj+fWPbiv5/u/A6b5XixqD870IC mfTiX1E5VZ9v8ZX3hfdirpS1+aiAgJUzMWAzv4oLwA+1cp4WORJ3On1fBif83b0w0IjW GvttrNEw9tlRlbyrFYNJXAxKTNE338UZztvXg=
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=NQrYVnnyfTxv6mvb9LBwXgJfnoRyxAkM4Eo9ilAOjzEIaNUz3atsr81CdBYVhFho17 tmNnEIjLreBqCM6FKf3YPVWXk95BZj+lRtpfE87eoKdY6ZfJbkZPoq2lgXPoCJ+J76Gw DswoDGgUXpjORqBT3yXiBvbd1aatJ1ZrtFLqc=
MIME-Version: 1.0
Received: by 10.181.222.5 with SMTP id z5mr71747bkq.151.1233778039679; Wed, 04  Feb 2009 12:07:19 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 4 Feb 2009 12:07:19 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: Dave Katz <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 20:07:42 -0000

Hi Dave,

Thanks for the very quick reply.

>>> I think the detectection time interval is not correct at all. Let me
>>> quote a few parts of the text:
>>>
>>>  In Asynchronous mode, the Detection Time calculated in the local
>>>  system is equal to the value of Detect Mult received from the remote
>>>  system, multiplied by the agreed transmit interval of the remote
>>>  system (the greater of bfd.RequiredMinRxInterval and the last
>>>  received Desired Min TX Interval.)
>>>
>>> Also note that
>>>
>>>  With the exceptions listed in the remainder of this
>>>  section, a system MUST NOT transmit BFD Control packets at an
>>>  interval less than the larger of bfd.DesiredMinTxInterval and
>>> bfd.RemoteMinRxInterval.
>>>
>>> And note that we need to do a jitter of 0 to 25 % in the timer values.
>>> This means that the actual transmit interval has to be may be atleast
>>> 0 to 25% more than the larger of the Tx and RecvRx interval (let us
>>> call it actual receive interval ActTx).
>
> No; jitter is always *subtracted*.

That is correct but we cannot have the Tx Interval lesser than ActTx
ever right?

The way I was seeing it was that except for the Detect Multiplier 1
case, we will never have a transmit interval less that ActTx. To not
get the synchronization we will use a jitter. Otherwise if you never
use the value of Tx and RecvRx as is the values do not hold
significance. Otherwise we should change the definitions like
(asuuming probability for randomness the definition is wrong 100% of
the time):

    bfd.RequiredMinRxInterval

         The minimum interval, in microseconds, between received BFD
         Control packets that this system requires.

The definition should be changed to if say we want 25% jitter we would state:

         133.33% of the minimum interval, in microseconds, between received BFD
         Control packets that this system requires.

Similarly if we want 20% it should be 125%. The point is if a user
configures value X for the minimum interval required they never get it
- so this should be clearly mentioned.

>   The periodic transmission of BFD Control packets SHOULD be jittered
>   by up to 25%, that is, the interval SHOULD be reduced by a random
>   value of 0 to 25%, in order to avoid self-synchronization.  Thus, the
>   average interval between packets may be up to 12.5% less than that
>   negotiated.
>
>>>
>>> 1. Shouldn't we on getting a packet with state UP, go to Init state.
>>>
>>>  "Init state means that the remote system is communicating, and the
>>>  local system desires to bring the session up, but the remote system
>>>  does not yet realize it."
>
> No, we need a three-way handshake that ensures that both sides see the path
> fail:
Yes, I agree, but if I see a packet from the neighbor why should I not
go in Init state. Please see the definition of Init state I have
attached above, otehrwise we should trigger this packet as a error
packet in the flow.

>   Once a session has been declared down, it cannot come back up until
>   the remote end first signals that it is down (by leaving the Up
>   state), thus implementing a three-way handshake.
>
>>>
>>>
>>> 2. Do we need to put some information about congestion control
>>> especially in the Multihop case.
>
> The new draft (in internal review, to be popping out forthwith) has suitably
> vague language to the effect that the transmit interval manipulation is the
> necessary hook, and that particular algorithms do not impact
> interoperability and are therefore outside the scope of the spec.  Somebody
> can write a BCP if they like, but there's an opportunity for product
> differentiation here.
Great thanks.

>>>
>>> 3.  The draft states
>>>
>>>  One possible approach is to build an implementation such that
>>>  authentication is configured, but not considered "in use" until the
>>>  first packet containing a matching authentication section is received
>>>  (providing the necessary synchronization.)
>>>
>>> I do not know what it means by a matching authentication section. If
>>> it means enabling authentication once a packet with the A bit is set
>>> is got, then I think this is an easy way of DoS attacks. Send a packet
>>> with the A bit and the neighbors will not be able to communicate after
>>> that.
>
> The new draft has a bit more explicative language;  the idea of this whole
> thing was to provide a way for a network to transition to using
> authentication without tearing down sessions.  One would expect that someone
> would configure "I would like to do authentication when you're ready" at one
> end and then configure "I want to do configuration *now*" at the other end,
> and then authentication would be up and stay up.  This sensitivity to
> receiving an authenticated packet and turning it on is not meant to be the
> long-term state of the device, but a transition mechanism.  Also note that
> the DoS attack scenario is no worse than having no authentication at all.
Thanks,

>>>
>>>
>>> 4. I do not see the way mentioned below as the right solution:
>>>
>>>  With the exceptions listed in the remainder of this
>>>  section, a system MUST NOT transmit BFD Control packets at an
>>>  interval less than the larger of bfd.DesiredMinTxInterval and
>>> bfd.RemoteMinRxInterval.
>>>
>>>  The periodic transmission of BFD Control packets SHOULD be jittered
>>>  by up to 25%, that is, the interval SHOULD be reduced by a random
>>>  value of 0 to 25%, in order to avoid self-synchronization.  Thus, the
>>>  average interval between packets may be up to 12.5% less than that
>>>  negotiated.
>>>
>>>  If bfd.DetectMult is equal to 1, the interval between transmitted BFD
>>>  Control packets MUST be no more than 90% of the negotiated
>>>  transmission interval, and MUST be no less than 75% of the negotiated
>>>  transmission interval.
>>>
>>> So if we have a DetectMult of 1. We have the bfd.RemoteMinRxInterval <
>>> bfd.DesiredMinTxInterval. The Remote system has no control of how fast
>>> the packets are sent.
>
> Sure it does;  that's what bfd.RemoteMinRXInterval is for.  I don't see what
> you're saying here.
It is related to the first point I am raising.

>>> In my view in this case we should have the
>>> Remote system calculate the detection interval to be 25 % more than
>>> the actual detection interval however the Hellos are always sent at
>>> the right rate - never less than the minimum of the 2 intervals.
>
> I see no difference between this and the text as written, except that the
> packet transmission and detection are happening a little more slowly.
>  Raising the value of DesiredMinTxInterval by 25% or whatever would have the
> same effect.
>
>>>
>>>
>>> 5. What is to be done to packets for which the Tx or Rx Interval is
>>> changed but the poll sequence is not initiated?
>>>
>>>  If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
>>>  the previous value of bfd.RequiredMinRxInterval MUST be used when
>>>  calculating the Detection Time for the remote system until the Poll
>>>  Sequence described above has terminated.
>
> It's broken, and the transmission rate will not change, and the vendor will
> be humiliated in public for having an implementation that is seriously out
> of spec.
Humiliation is another thing!!!

What I am eager to know is should I just see the poll bit to realize
something may have changed in the Tx and ReqRx or not. I think we need
to make this more explicit. The spec needs to be clear about such
things.

In my view the poll/ final bit are used to see if the neighbor has got
a particular message I sent across. There could be cases where I do
not care f the neighbor knows immediately (I do not need to verify a
handshake).

Like I said the spec should be explicit and not assume things. I would
also want the explicit note of when the Final bit is unset too. I
think for a good spec it is better to clearly specify than to assume
the other person understands what we are thinking.

Thanks,
Vishwas


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9BD3A6921 for <[e-mail]>; Wed,  4 Feb 2009 12:36:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 pFGo2s8KoGiL for <[e-mail]>; Wed,  4 Feb 2009 12:36:19 -0800 (PST)
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by core3.amsl.com (Postfix) with ESMTP id EF19428C11F for <[e-mail]>; Wed,  4 Feb 2009 12:36:18 -0800 (PST)
Received: by mu-out-0910.google.com with SMTP id w9so666083mue.9 for <[e-mail]>; Wed, 04 Feb 2009 12:35:58 -0800 (PST)
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=9zDitp/dyxnLbL7iUCRpi0iiRBgp2hL6l9b8xQhwTNY=; b=is5lSZ2smInclyJaUq/gp/9LhfH7d+MW14j0BU7V4DrBa3UQKe5Mp1MLw7LEJeQFv0 lxq2+75/QS9eBGOOXq2XnZugBvcrMuuZcvaUTI+Oa+fSXeZvi3t2zRZWowwEcm4nv/mj JBauyXvrmOAeMIE8WAW9+grxd6cqwDhy61KzE=
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=EMK7fzyIT1/8fiqM7tr/+4ZzVDBj7M9beRIdm7ma1QBkt8atwffiPPkQyndX05ElsQ O32wj3g1ebGCdhoheI4+SKOfAuwCgLNKonOj9Dl/8UDC54Nv2UTPTHIAxDtT81sW7/Xu /HdBoNepOKEEUR/a/yf/J3GzR232QSdUjMnMA=
MIME-Version: 1.0
Received: by 10.181.145.7 with SMTP id x7mr2623344bkn.177.1233779758023; Wed,  04 Feb 2009 12:35:58 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 4 Feb 2009 12:35:57 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: Dave Katz <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 20:36:20 -0000

Hi Dave,

>From the Section on timer negotiation. If you note that if I make my
timer 133.3% of the ActTx interval and then use a 25% less jitter (so
ActTx to 1.33 ActTx), I get the exact behavior as below and do not
violate the below or any definition in Section 6.2.

However you will note with the scheme you state we violate the statement

   With the exceptions listed in the remainder of this
   section, a system MUST NOT transmit BFD Control packets at an
   interval less than the larger of bfd.DesiredMinTxInterval and
   bfd.RemoteMinRxInterval.

It is never transmitted as above (without exception). It becomes a
MUST instead of a MUST NOT.

>>> 3.  The draft states
>>>
>>>  One possible approach is to build an implementation such that
>>>  authentication is configured, but not considered "in use" until the
>>>  first packet containing a matching authentication section is received
>>>  (providing the necessary synchronization.)
>>>
>>> I do not know what it means by a matching authentication section. If
>>> it means enabling authentication once a packet with the A bit is set
>>> is got, then I think this is an easy way of DoS attacks. Send a packet
>>> with the A bit and the neighbors will not be able to communicate after
>>> that.
>
> The new draft has a bit more explicative language;  the idea of this whole
> thing was to provide a way for a network to transition to using
> authentication without tearing down sessions.  One would expect that someone
> would configure "I would like to do authentication when you're ready" at one
> end and then configure "I want to do configuration *now*" at the other end,
> and then authentication would be up and stay up.  This sensitivity to
> receiving an authenticated packet and turning it on is not meant to be the
> long-term state of the device, but a transition mechanism.  Also note that
> the DoS attack scenario is no worse than having no authentication at all.
A better way would be, I am ok with authenticating packets and
non-auth packets, but will send out non-auth packets. When I configure
the same on all the neighbors, I then go and configure send and
receive and the authentication is enabled. I think Cisco uses the same
mechanism to change from one Key to another in other protocols.

Thanks,
Vishwas


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887043A63CB for <[e-mail]>; Wed,  4 Feb 2009 12:46:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpPqvD8lHdmV for <[e-mail]>; Wed,  4 Feb 2009 12:45:59 -0800 (PST)
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 3B54E3A6A3B for <[e-mail]>; Wed,  4 Feb 2009 12:45:59 -0800 (PST)
Received: by fxm13 with SMTP id 13so3351747fxm.13 for <[e-mail]>; Wed, 04 Feb 2009 12:45:38 -0800 (PST)
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=P7mDQZQ2T4nnoVTdbRjWPnQvK5DDyXD7Ju4NKON//Ls=; b=LIqRU0ifK5zkwWp5l6mny8clpEAba9UGqK4mbS0EdFKPzovfl+/klsBpF30VgBrvbS hp8NcaSIcfv4UZd2AlJHPr5Ig4t65WrhLHKOIYk0+8kGaNZmNZYYUZus0S1T3MB9hSFW 584j5GfMdrPs+w3kzy/7ZjcEdRN7aBfwKjuvs=
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=q1x7IZrMcT70vdZ1IYwNLMotesuEu9796cUtVX/8YptaWyPkMCstaHlA4gwBwUVlJ8 YC0F3f+ETrizmuStfboL53TieDcowiQcMBpOtETguc6IV7cOwKnvNfoDPmG8QTxHemR9 U/5ewwFpdatkUMyQsC6xpiO6DV1Excf6xUcEs=
MIME-Version: 1.0
Received: by 10.181.227.9 with SMTP id e9mr2633950bkr.133.1233780338276; Wed,  04 Feb 2009 12:45:38 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 4 Feb 2009 12:45:38 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: Dave Katz <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 20:46:00 -0000

Hi Dave,

The packet reception algorithm does not seem to be consistent with the
Poll thing we noted earlier.

Also note:

      If the Required Min Echo RX Interval field is zero, the
      transmission of Echo packets, if any, MUST cease.

we have missed the case of in the Interval goes from zero to non-zero,
though we have mentioned the behavior of non-zero to zero.

Thanks,
Vishwas

On Wed, Feb 4, 2009 at 12:35 PM, Vishwas Manral <[e-mail]> wrote:
> Hi Dave,
>
> From the Section on timer negotiation. If you note that if I make my
> timer 133.3% of the ActTx interval and then use a 25% less jitter (so
> ActTx to 1.33 ActTx), I get the exact behavior as below and do not
> violate the below or any definition in Section 6.2.
>
> However you will note with the scheme you state we violate the statement
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
>   bfd.RemoteMinRxInterval.
>
> It is never transmitted as above (without exception). It becomes a
> MUST instead of a MUST NOT.
>
>>>> 3.  The draft states
>>>>
>>>>  One possible approach is to build an implementation such that
>>>>  authentication is configured, but not considered "in use" until the
>>>>  first packet containing a matching authentication section is received
>>>>  (providing the necessary synchronization.)
>>>>
>>>> I do not know what it means by a matching authentication section. If
>>>> it means enabling authentication once a packet with the A bit is set
>>>> is got, then I think this is an easy way of DoS attacks. Send a packet
>>>> with the A bit and the neighbors will not be able to communicate after
>>>> that.
>>
>> The new draft has a bit more explicative language;  the idea of this whole
>> thing was to provide a way for a network to transition to using
>> authentication without tearing down sessions.  One would expect that someone
>> would configure "I would like to do authentication when you're ready" at one
>> end and then configure "I want to do configuration *now*" at the other end,
>> and then authentication would be up and stay up.  This sensitivity to
>> receiving an authenticated packet and turning it on is not meant to be the
>> long-term state of the device, but a transition mechanism.  Also note that
>> the DoS attack scenario is no worse than having no authentication at all.
> A better way would be, I am ok with authenticating packets and
> non-auth packets, but will send out non-auth packets. When I configure
> the same on all the neighbors, I then go and configure send and
> receive and the authentication is enabled. I think Cisco uses the same
> mechanism to change from one Key to another in other protocols.
>
> Thanks,
> Vishwas
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A103A6A2A for <[e-mail]>; Wed,  4 Feb 2009 13:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.585
X-Spam-Level: 
X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014,  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 GuRoSwPd0rfV for <[e-mail]>; Wed,  4 Feb 2009 13:10:27 -0800 (PST)
Received: from chip3og52.obsmtp.com (chip3og52.obsmtp.com [64.18.14.169]) by core3.amsl.com (Postfix) with ESMTP id 02C733A6974 for <[e-mail]>; Wed,  4 Feb 2009 13:10:25 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob52.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Wed, 04 Feb 2009 13:10:07 PST
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.336.0; Wed, 4 Feb 2009 13:03:45 -0800
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, 4 Feb 2009 13:03:45 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 13:03:45 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 13:03:43 -0800
Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n14L3fM04319; Wed, 4 Feb 2009 13:03:41 -0800 (PST)	(envelope-from [e-mail])
Message-ID: <[e-mail]>
From: Dave Katz <[e-mail]>
To: Vishwas Manral <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 14:03:39 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 04 Feb 2009 21:03:43.0446 (UTC) FILETIME=[0FFE6F60:01C9870C]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 21:10:28 -0000

On Feb 4, 2009, at 1:07 PM, Vishwas Manral wrote:

>> The definition should be changed to if say we want 25% jitter we  
>> would state:
>
>         133.33% of the minimum interval, in microseconds, between  
> received BFD
>         Control packets that this system requires.
>
> Similarly if we want 20% it should be 125%. The point is if a user
> configures value X for the minimum interval required they never get it
> - so this should be clearly mentioned.

Well, it is explicitly mentioned when talking about jitter, as I  
quoted before:

>
>
>>  The periodic transmission of BFD Control packets SHOULD be jittered
>>  by up to 25%, that is, the interval SHOULD be reduced by a random
>>  value of 0 to 25%, in order to avoid self-synchronization.  Thus,  
>> the
>>  average interval between packets may be up to 12.5% less than that
>>  negotiated.

I can add a brief note to the definition if that would make it clearer.


>>
>>
>>>>
>>>> 1. Shouldn't we on getting a packet with state UP, go to Init  
>>>> state.
>>>>
>>>> "Init state means that the remote system is communicating, and the
>>>> local system desires to bring the session up, but the remote system
>>>> does not yet realize it."
>>
>> No, we need a three-way handshake that ensures that both sides see  
>> the path
>> fail:
> Yes, I agree, but if I see a packet from the neighbor why should I not
> go in Init state. Please see the definition of Init state I have
> attached above, otehrwise we should trigger this packet as a error
> packet in the flow.

The "definition" you quote is an attempt to describe, in a somewhat  
accessible way, the semantic meaning of the state.  The full state  
machine is very clearly documented, both with a diagram and with  
normative prose.

The receipt of Up while in Down state is not an error, it just means  
that the other end hasn't seen your end go down, or that packet got  
lost on the way.  If that packet saying you were Down was lost in  
transit, transitioning to Init state would mean that the other end  
would never signal a session failure.  And before you mention that it  
could key on your sending Init in your packet, *that* packet could be  
lost as well in which case the far end would have no idea that you  
were ever down, and the three-way handshake would fail.

Designing state machines like this is a subtle art (as evidenced by  
the fact that my first try at the state machine was broken, which is  
why we had to bump the version number awhile back.)  This one is  
tested and solid and widely implemented.  Let's move on.

>>>>
>>>> So if we have a DetectMult of 1. We have the  
>>>> bfd.RemoteMinRxInterval <
>>>> bfd.DesiredMinTxInterval. The Remote system has no control of how  
>>>> fast
>>>> the packets are sent.
>>
>> Sure it does;  that's what bfd.RemoteMinRXInterval is for.  I don't  
>> see what
>> you're saying here.
> It is related to the first point I am raising.

I'll add "except for jitter" to the places that talk about the minimum  
time values, and hopefully that will settle all this.

>
> What I am eager to know is should I just see the poll bit to realize
> something may have changed in the Tx and ReqRx or not. I think we need
> to make this more explicit. The spec needs to be clear about such
> things.

The spec is abundantly clear about what to do when you receive  
packets, regardless of whether Poll is set or not.  You update the  
timers--it's normative and explicitly spelled out.  Poll is not a  
mechanism to signal the receiver that it should further examine the  
packet (nor do I know of any text that implies this.)  Rather, Poll is  
a mechanism to ensure that the far end has heard your recent packet  
(acknowledged by setting Final.)

>
> In my view the poll/ final bit are used to see if the neighbor has got
> a particular message I sent across. There could be cases where I do
> not care f the neighbor knows immediately (I do not need to verify a
> handshake).
>
> Like I said the spec should be explicit and not assume things. I would
> also want the explicit note of when the Final bit is unset too. I
> think for a good spec it is better to clearly specify than to assume
> the other person understands what we are thinking.

I thought the spec was clear, but I can add "the Final bit MUST be  
clear otherwise" at the end of the text in section 6.8.7 if that will  
make it clearer.  I'm not sure what other assumptions you are  
referring to.

--Dave



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EFC83A6900 for <[e-mail]>; Wed,  4 Feb 2009 13:17:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.585
X-Spam-Level: 
X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014,  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 aaR0QNhpEiW3 for <[e-mail]>; Wed,  4 Feb 2009 13:17:13 -0800 (PST)
Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 68DB93A6832 for <[e-mail]>; Wed,  4 Feb 2009 13:17:13 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob60.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Wed, 04 Feb 2009 13:16:54 PST
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.336.0; Wed, 4 Feb 2009 13:11:25 -0800
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, 4 Feb 2009 13:11:25 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 13:11:25 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 13:11:24 -0800
Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n14LBNM07453; Wed, 4 Feb 2009 13:11:23 -0800 (PST)	(envelope-from [e-mail])
Message-ID: <[e-mail]>
From: Dave Katz <[e-mail]>
To: Vishwas Manral <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 14:11:22 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 04 Feb 2009 21:11:24.0130 (UTC) FILETIME=[22953C20:01C9870D]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 21:17:14 -0000

On Feb 4, 2009, at 1:35 PM, Vishwas Manral wrote:

> Hi Dave,
>
>> From the Section on timer negotiation. If you note that if I make my
> timer 133.3% of the ActTx interval and then use a 25% less jitter (so
> ActTx to 1.33 ActTx), I get the exact behavior as below and do not
> violate the below or any definition in Section 6.2.
>
> However you will note with the scheme you state we violate the  
> statement
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
>   bfd.RemoteMinRxInterval.
>
> It is never transmitted as above (without exception). It becomes a
> MUST instead of a MUST NOT.

This will be settled with the jitter text I mentioned in the last  
message.

>
>
>>>> 3.  The draft states
>>>>
>>>> One possible approach is to build an implementation such that
>>>> authentication is configured, but not considered "in use" until the
>>>> first packet containing a matching authentication section is  
>>>> received
>>>> (providing the necessary synchronization.)
>>>>
>>>> I do not know what it means by a matching authentication section.  
>>>> If
>>>> it means enabling authentication once a packet with the A bit is  
>>>> set
>>>> is got, then I think this is an easy way of DoS attacks. Send a  
>>>> packet
>>>> with the A bit and the neighbors will not be able to communicate  
>>>> after
>>>> that.
>>
>> The new draft has a bit more explicative language;  the idea of  
>> this whole
>> thing was to provide a way for a network to transition to using
>> authentication without tearing down sessions.  One would expect  
>> that someone
>> would configure "I would like to do authentication when you're  
>> ready" at one
>> end and then configure "I want to do configuration *now*" at the  
>> other end,
>> and then authentication would be up and stay up.  This sensitivity to
>> receiving an authenticated packet and turning it on is not meant to  
>> be the
>> long-term state of the device, but a transition mechanism.  Also  
>> note that
>> the DoS attack scenario is no worse than having no authentication  
>> at all.
> A better way would be, I am ok with authenticating packets and
> non-auth packets, but will send out non-auth packets. When I configure
> the same on all the neighbors, I then go and configure send and
> receive and the authentication is enabled. I think Cisco uses the same
> mechanism to change from one Key to another in other protocols.

That is also a workable mechanism, though it has the downside that you  
have to configure one machine twice.  But in any case, the existing  
text says "One possible approach" and does not preclude others.   
Implementors are free to do what they want.

In defining BFD we went out of our way to be careful about what to  
make normative and what to leave up to implementors.  We explicitly  
did *not* want to write an implementation guide (e.g. OSPF), both  
because it confuses normative requirements with particular  
implementation choices, and because we wanted to leave enough wiggle  
room to allow product differentiation for everyone insofar as it does  
not affect interoperability (we are trying to make a living here,  
after all.)

Anyone is free to publish BCPs or Informational drafts to share  
implementation ideas, but the authors of the spec have chosen not to.

--Dave



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9256F3A684A for <[e-mail]>; Wed,  4 Feb 2009 13:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.586
X-Spam-Level: 
X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013,  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 bWNlpCEZGvuA for <[e-mail]>; Wed,  4 Feb 2009 13:28:38 -0800 (PST)
Received: from chip3og58.obsmtp.com (chip3og58.obsmtp.com [64.18.14.181]) by core3.amsl.com (Postfix) with ESMTP id 7B46C3A683D for <[e-mail]>; Wed,  4 Feb 2009 13:28:35 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob58.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Wed, 04 Feb 2009 13:28:16 PST
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.336.0; Wed, 4 Feb 2009 13:20:55 -0800
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, 4 Feb 2009 13:20:56 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 13:20:55 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 13:20:54 -0800
Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n14LKqM11506; Wed, 4 Feb 2009 13:20:52 -0800 (PST)	(envelope-from [e-mail])
Message-ID: <[e-mail]>
From: Dave Katz <[e-mail]>
To: Vishwas Manral <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 14:20:47 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 04 Feb 2009 21:20:54.0502 (UTC) FILETIME=[768D1860:01C9870E]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 21:28:39 -0000

On Feb 4, 2009, at 1:45 PM, Vishwas Manral wrote:

> Hi Dave,
>
> The packet reception algorithm does not seem to be consistent with the
> Poll thing we noted earlier.
>
> Also note:
>
>      If the Required Min Echo RX Interval field is zero, the
>      transmission of Echo packets, if any, MUST cease.
>
> we have missed the case of in the Interval goes from zero to non-zero,
> though we have mentioned the behavior of non-zero to zero.

This is because the ceasing of Echo transmission is normative, but  
starting transmission is non-normative.  The bit you quote here is  
normative and procedural, and is saying what must be done upon receipt  
of a zero.  Nothing in particular must be done when receiving nonzero.

There is also the following bit of text:

6.8.9. Transmission of BFD Echo Packets

    BFD Echo packets MUST NOT be transmitted when bfd.SessionState is  
not
    Up.  BFD Echo packets MUST NOT be transmitted unless the last BFD
    Control packet received from the remote system contains a nonzero
    value in Required Min Echo RX Interval.

    BFD Echo packets MAY be transmitted when bfd.SessionState is Up.   
The
    interval between transmitted BFD Echo packets MUST NOT be less than
    the value advertised by the remote system in Required Min Echo RX
    Interval, except as follows:

       A 25% jitter MAY be applied to the rate of transmission, such  
that
       the actual interval MAY be between 75% and 100% of the advertised
       value.  A single BFD Echo packet MAY be transmitted between
       normally scheduled Echo transmission intervals.

    The transmission of BFD Echo packets is otherwise outside the scope
    of this specification.

See previous discussion about keeping normative text tight.  There is  
a general problem of trying to list all of the things that MAY be done  
at any particular time, which is essentially infinite.  Trying to be  
more explicit in cases like this will bloat the spec even further than  
it already is (for a protocol that purports to be "simple" the spec is  
getting pretty beefy.)  The authors feel that the existing text is  
sufficient for implementors versed in the art to build correct and  
interoperable implementations.

--Dave



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27553A698C for <[e-mail]>; Wed,  4 Feb 2009 13:36:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.587
X-Spam-Level: 
X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012,  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 NF+RaVwWORTc for <[e-mail]>; Wed,  4 Feb 2009 13:36:40 -0800 (PST)
Received: from chip3og61.obsmtp.com (chip3og61.obsmtp.com [64.18.14.187]) by core3.amsl.com (Postfix) with ESMTP id DF5303A683D for <[e-mail]>; Wed,  4 Feb 2009 13:36:39 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob61.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Wed, 04 Feb 2009 13:36:20 PST
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.336.0; Wed, 4 Feb 2009 13:30:33 -0800
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, 4 Feb 2009 13:30:33 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 13:30:33 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 13:30:31 -0800
Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n14LUUM15660; Wed, 4 Feb 2009 13:30:30 -0800 (PST)	(envelope-from [e-mail])
Message-ID: <[e-mail]>
From: Dave Katz <[e-mail]>
To: Vishwas Manral <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 14:30:29 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 04 Feb 2009 21:30:31.0920 (UTC) FILETIME=[CEB81700:01C9870F]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 21:36:44 -0000

On Feb 4, 2009, at 1:35 PM, Vishwas Manral wrote:

> Hi Dave,
>
>> From the Section on timer negotiation. If you note that if I make my
> timer 133.3% of the ActTx interval and then use a 25% less jitter (so
> ActTx to 1.33 ActTx), I get the exact behavior as below and do not
> violate the below or any definition in Section 6.2.
>
> However you will note with the scheme you state we violate the  
> statement
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
>   bfd.RemoteMinRxInterval.
>
> It is never transmitted as above (without exception). It becomes a
> MUST instead of a MUST NOT.


Actually, this one is already fine in the spec.  The paragraph  
immediately following the one you quote contains one of the  
exceptions, which is the application of jitter.

--Dave



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225E33A685A for <[e-mail]>; Wed,  4 Feb 2009 13:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyTsZm0Tht-c for <[e-mail]>; Wed,  4 Feb 2009 13:59:06 -0800 (PST)
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id C4FDF3A6921 for <[e-mail]>; Wed,  4 Feb 2009 13:59:05 -0800 (PST)
Received: by fxm13 with SMTP id 13so3387824fxm.13 for <[e-mail]>; Wed, 04 Feb 2009 13:58:44 -0800 (PST)
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=TNJAaGQgIowdMZcT/3OQ8NB22FOooE8/dg3e/fvLkuM=; b=s8uOBHGBinS4q/NPTm67M5Nyu4YUGKbq2K8aEni4O7ZhBqIU+qwQeCHKlLEYTPq9lK UIV4xhaqaUAjvcV2hPmR/jo3aODjCn7+pzogoJ3oeSlYvK30dPfNhouVQPuVaQ8R8qcp FZK2RfpOztAtBx8br0QlE+D11lfljMAUvnjDc=
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=AcxcS6zTDIOId1zHBZoOXzWzF2f5AxMlszuL2bdrLMEiBHkC+zm4DZMFkRp95uk0DU JMq33FkzVO574BhpmUQMBIlndUHmE/DZPZTIZn9os4FSIXRNAtb1y3X6pawDOyQeaTz1 KBjepWOjdx8LxeP0p8yjr9+oY9I0CqMvMtaPQ=
MIME-Version: 1.0
Received: by 10.181.153.1 with SMTP id f1mr1257325bko.173.1233784724226; Wed,  04 Feb 2009 13:58:44 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 4 Feb 2009 13:58:44 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: Dave Katz <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 21:59:07 -0000

Hi Dave,

Thanks for your replies. I am good with most of the agreements.

>>  With the exceptions listed in the remainder of this
>>  section, a system MUST NOT transmit BFD Control packets at an
>>  interval less than the larger of bfd.DesiredMinTxInterval and
>>  bfd.RemoteMinRxInterval.
>>
>> It is never transmitted as above (without exception). It becomes a
>> MUST instead of a MUST NOT.
>
> Actually, this one is already fine in the spec.  The paragraph immediately
> following the one you quote contains one of the exceptions, which is the
> application of jitter.
But jitter is not the exception it is the rule for every packet (its
like saying do x for every packet except for all packets). I think it
is confusing to say it mildly.

> we have missed the case of in the Interval goes from zero to non-zero,
> though we have mentioned the behavior of non-zero to zero.

>  This is because the ceasing of Echo transmission is normative, but
> starting transmission is non-normative.  The bit you quote here is
> normative and procedural, and is saying what must be done upon
> receipt of a zero.  Nothing in particular must be done when receiving
> nonzero.

May be for the non-zero case we should mention that based on
conditions in section 6.8.9 the echo function may be started. From the
code perspective that is exactly what would be done.

The next 2 lines state the below and I think we can be consistent.

      Update the transmit interval as described in section 6.8.2.

      Update the Detection Time as described in section 6.8.4.

> Anyone is free to publish BCPs or Informational drafts to share
> implementation ideas, but the authors of the spec have chosen not to
I would be ok with the specification if it did not introduce new holes
into the specification. Particular implementations can be changed.

> The spec is abundantly clear about what to do when you receive packets,
> regardless of whether Poll is set or not.  You update the timers--it's normative
> and explicitly spelled out.  Poll is not a mechanism to signal the receiver that
> it should further examine the packet (nor do I know of any text that implies
> this.)  Rather, Poll is a mechanism to ensure that the far end has heard your
> recent packet (acknowledged by setting Final.)
That is exactly what I said too. So when we state

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

My question was do we need to verify the same at the receiving end or
not? If not it would be good to state it.

Thanks,
Vishwas


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475F53A68F7 for <[e-mail]>; Wed,  4 Feb 2009 14:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.587
X-Spam-Level: 
X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012,  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 Nzl+e6RvZ9tu for <[e-mail]>; Wed,  4 Feb 2009 14:27:46 -0800 (PST)
Received: from chip3og61.obsmtp.com (chip3og61.obsmtp.com [64.18.14.187]) by core3.amsl.com (Postfix) with ESMTP id 2C5603A6934 for <[e-mail]>; Wed,  4 Feb 2009 14:27:46 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob61.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Wed, 04 Feb 2009 14:27:27 PST
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.336.0; Wed, 4 Feb 2009 14:20:01 -0800
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, 4 Feb 2009 14:20:01 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 14:20:01 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 14:20:00 -0800
Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n14MJwM37299; Wed, 4 Feb 2009 14:19:59 -0800 (PST)	(envelope-from [e-mail])
Message-ID: <[e-mail]>
From: Dave Katz <[e-mail]>
To: Vishwas Manral <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 15:19:57 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 04 Feb 2009 22:20:00.0229 (UTC) FILETIME=[B7F81950:01C98716]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 22:27:47 -0000

On Feb 4, 2009, at 2:58 PM, Vishwas Manral wrote:

> Hi Dave,
>
> Thanks for your replies. I am good with most of the agreements.
>
>>> With the exceptions listed in the remainder of this
>>> section, a system MUST NOT transmit BFD Control packets at an
>>> interval less than the larger of bfd.DesiredMinTxInterval and
>>> bfd.RemoteMinRxInterval.
>>>
>>> It is never transmitted as above (without exception). It becomes a
>>> MUST instead of a MUST NOT.
>>
>> Actually, this one is already fine in the spec.  The paragraph  
>> immediately
>> following the one you quote contains one of the exceptions, which  
>> is the
>> application of jitter.
> But jitter is not the exception it is the rule for every packet (its
> like saying do x for every packet except for all packets). I think it
> is confusing to say it mildly.

It is a SHOULD, so it is indeed an exception.

>
>
>> we have missed the case of in the Interval goes from zero to non- 
>> zero,
>> though we have mentioned the behavior of non-zero to zero.
>
>> This is because the ceasing of Echo transmission is normative, but
>> starting transmission is non-normative.  The bit you quote here is
>> normative and procedural, and is saying what must be done upon
>> receipt of a zero.  Nothing in particular must be done when receiving
>> nonzero.
>
> May be for the non-zero case we should mention that based on
> conditions in section 6.8.9 the echo function may be started. From the
> code perspective that is exactly what would be done.
>
> The next 2 lines state the below and I think we can be consistent.
>
>      Update the transmit interval as described in section 6.8.2.
>
>      Update the Detection Time as described in section 6.8.4.
>
>> Anyone is free to publish BCPs or Informational drafts to share
>> implementation ideas, but the authors of the spec have chosen not to
> I would be ok with the specification if it did not introduce new holes
> into the specification. Particular implementations can be changed.

The authors feel that this is not a "hole" and in fact this text has  
existed for a number of years now without any complaint or apparent  
difficulty in interpretation.

>
>
>   If either bfd.DesiredMinTxInterval is changed or
>   bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
>   initiated (see section 6.5).
>
> My question was do we need to verify the same at the receiving end or
> not? If not it would be good to state it.

As the spec notes,

    This section discusses the normative requirements of the protocol in
    order to achieve interoperability.  It is important for implementors
    to enforce only the requirements specified in this section, as
    misguided pedantry has been proven by experience to adversely affect
    interoperability.

In other words, don't make checks that the spec doesn't say to make.   
I think that is sufficient.

The receiving system is not a conformance tester.

--Dave


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5223A68BC for <[e-mail]>; Wed,  4 Feb 2009 14:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soY1yJJVvmFu for <[e-mail]>; Wed,  4 Feb 2009 14:52:02 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 5419A3A685E for <[e-mail]>; Wed,  4 Feb 2009 14:52:01 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id l26so1346645fgb.41 for <[e-mail]>; Wed, 04 Feb 2009 14:51:40 -0800 (PST)
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=t2ydU66yyBMc3aRRrY7PF2m8TH1KVzU/DOJI26M63oE=; b=QxYLy8l71AWFPgF7aN/Sdhf0KR/FvXHF9RImkUEYZrgul/NvcT+eZzGV/jVimMx9hr OMry+paeECzRXW/9S4i606CTjB5Eqoi2huNKjbcstrqrl7ah+zl51Td78h7Jr2Jo57jp X7z3y98DDr/vnOpdKnPhSuA98TpID4EW0Iqhw=
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=awIHtjfDol68LDtzbEMfpSa0Jere3rHbYco97r//bhcJ8+xxu4s+yPXsGXU2HXbE11 TbUKsnqNJYvPbQgdWWtNZsjV5WijLNP2CX/CM8neIsPdcp/7HnZrFQQHWBwkYiM8xNv5 MYnumF873yw45hmeHvIra9HRF+/qy+lO8NaGo=
MIME-Version: 1.0
Received: by 10.181.141.18 with SMTP id t18mr1023133bkn.205.1233787900742;  Wed, 04 Feb 2009 14:51:40 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 4 Feb 2009 14:51:40 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: Dave Katz <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 22:52:03 -0000

Hi Dave,

Please do whatever you feel, however in my view the first case is a
gaping hole. Just to clarify it is equivalent to saying "MUST do X for
all packets, and SHOULD NOT do X for all packets". You seem to state
SHOULD is an "exception" so the statement is correct.

One more case, I come across is what if the Poll is inititiated by the
two ends symultaneously. I know you can all these exceptional
conditions, but we finally had to write similar stuff in BGP when
parallel connections are initiated symultaneously. The Poll isnt
cleared till the final bit is got. So do we set the Poll and the Final
bit togather (which is not allowed by the spec). Please clarify?

>> But jitter is not the exception it is the rule for every packet (its
>> like saying do x for every packet except for all packets). I think it
>> is confusing to say it mildly.
>
> It is a SHOULD, so it is indeed an exception.
You seem to be stating that for an implementation doing a SHOULD is an
exception (is there an IETF document which has chnaged the definition
of should to the way you mention). Is that how we intended it to be?
It does not match the language in the IETF. If that is true I guess we
have no point of contention (though it does amuse me).

> The authors feel that this is not a "hole" and in fact this text has existed
> for a number of years now without any complaint or apparent difficulty in
> interpretation.
I agree it may not qualify as a gaping hole necessarily. It helps to
however fill in all not so big holes if they can be improved by adding
a few lines in the text (and anyway adds no ned functionality as it is
'obvious').

>>  If either bfd.DesiredMinTxInterval is changed or
>>  bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
>>  initiated (see section 6.5).
>>
>> My question was do we need to verify the same at the receiving end or
>> not? If not it would be good to state it.
>
> As the spec notes,
>
>   This section discusses the normative requirements of the protocol in
>   order to achieve interoperability.  It is important for implementors
>   to enforce only the requirements specified in this section, as
>   misguided pedantry has been proven by experience to adversely affect
>   interoperability.
>
> In other words, don't make checks that the spec doesn't say to make.  I
> think that is sufficient.
>
> The receiving system is not a conformance tester.
Ok. In my view if we specify the behavior in unknown cases we may
avoid unnecessary issues. You seem to state let us leave it for the
intelligent implementor. I however feel we have to understand that not
everyone has the same intelligence as the senior architects in
Juniper.

Thanks,
Vishwas


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92BB3A6997 for <[e-mail]>; Thu,  5 Feb 2009 10:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 T9yhAC9lUHmj for <[e-mail]>; Thu,  5 Feb 2009 10:13:35 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id B97393A68AC for <[e-mail]>; Thu,  5 Feb 2009 10:13:34 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id l26so247238fgb.41 for <[e-mail]>; Thu, 05 Feb 2009 10:13:13 -0800 (PST)
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=t5/3CZL8Eof2pw3250gHfzLYcCuH9CI8Pfyv5H8zB/o=; b=itIK0kvHb3ftG9OIviWq+IMXvOvXtAuDU9zDxyJezFnK4ie6QhRFWsO4XwloJQGc3K GJ0R4ZG6UjHCRtQPJkP1sh+au751VnHyJEb+MYX4/JMy0brWpSwpWKuVN+WUBTp5RcUA HWq+rz9rrzTVpSr5In+8u0Pc7S0uk3dRsyEuc=
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=hQ0G3OdcWmaYpjlYZxCxO7RxyBWCTR8svblQD0v1XNpmOpjWdctWh9Y5rIH1TRhwul kI8l/0lcUJh/VgfGnqbaVyzO45pR6FDuww/Xpnd55mhjRFiBBX0WSEHU4lrGKPyHoOuC a8gbpaaTIYa9a9sDytV2VgL3uwDGprcWVBpN0=
MIME-Version: 1.0
Received: by 10.181.218.14 with SMTP id v14mr251098bkq.111.1233857593097; Thu,  05 Feb 2009 10:13:13 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 5 Feb 2009 10:13:13 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: Dave Katz <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 18:13:35 -0000

Hi Dave,

I thought over this issue.

> One more case, I come across is what if the Poll is inititiated by the
> two ends symultaneously. I know you can all these exceptional
> conditions, but we finally had to write similar stuff in BGP when
> parallel connections are initiated symultaneously. The Poll isnt
> cleared till the final bit is got. So do we set the Poll and the Final
> bit togather (which is not allowed by the spec). Please clarify?
I think the best way would be to allow FINAL and POLL bit in the same
packet. Is there a reason to explicitly disallow it?

Thanks,
Vishwas


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4561B3A6827 for <[e-mail]>; Thu,  5 Feb 2009 11:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.587
X-Spam-Level: 
X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012,  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 jqvKGOq060QX for <[e-mail]>; Thu,  5 Feb 2009 11:02:43 -0800 (PST)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 45B133A67CF for <[e-mail]>; Thu,  5 Feb 2009 11:02:40 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Thu, 05 Feb 2009 11:02:45 PST
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.336.0; Thu, 5 Feb 2009 10:35:46 -0800
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 10:35:46 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 10:35:45 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Feb 2009 10:35:45 -0800
Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n15IZiM08824; Thu, 5 Feb 2009 10:35:44 -0800 (PST)	(envelope-from [e-mail])
Message-ID: <[e-mail]>
From: Dave Katz <[e-mail]>
To: Vishwas Manral <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: More BFD base issues
Date: Thu, 5 Feb 2009 11:35:43 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 05 Feb 2009 18:35:45.0010 (UTC) FILETIME=[8E725D20:01C987C0]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 19:02:44 -0000

On Feb 5, 2009, at 11:13 AM, Vishwas Manral wrote:

> Hi Dave,
>
> I thought over this issue.
>
>> One more case, I come across is what if the Poll is inititiated by  
>> the
>> two ends symultaneously. I know you can all these exceptional
>> conditions, but we finally had to write similar stuff in BGP when
>> parallel connections are initiated symultaneously. The Poll isnt
>> cleared till the final bit is got. So do we set the Poll and the  
>> Final
>> bit togather (which is not allowed by the spec). Please clarify?
> I think the best way would be to allow FINAL and POLL bit in the same
> packet. Is there a reason to explicitly disallow it?

Yes, it's to avoid the possibility of packet floods.  Since packets  
with Final can be sent without regard to rate control, it would open  
up a possibility of wire-rate packets being exchanged in both  
directions if packets with Poll could be sent the same way.  It would  
require a broken implementation for it to happen, but one of the  
overriding design criteria in BFD was to avoid catastrophic meltdown  
due to excessive packet transmission.  It was felt that this  
requirement would provide some protection at little or no cost on the  
wire (potentially one extra packet if both sides feel the need to poll  
simultaneously) and a negligible increase in implementation complexity.

The authors have watched networks melt into silicon sludge too many  
times over the years because of runaway control traffic (AOL down for  
19 hours;  ATT SS7 down for hours;  MCI frame relay down for 10 days  
along with the Chicago Board of Trade) and we wanted to make double- 
sure that we weren't creating yet another way of taking down the  
infrastructure.  There is ample empirical data showing that most  
control protocol implementations do not behave well when they get  
overloaded.

In any case, the scenario you describe is trivially dealt with if you  
consider packets with Final to be "extra" (not subject to scheduling)  
since they are supposed to be sent "as soon as practicable", and by  
definition any packet with Poll is done on a regular periodic basis.   
Slightly different code paths for the two cases and you're done.

--Dave

>
>
> Thanks,
> Vishwas
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F5F28C134 for <[e-mail]>; Thu,  5 Feb 2009 11:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 XY0hUMSyYx-a for <[e-mail]>; Thu,  5 Feb 2009 11:26:03 -0800 (PST)
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id A4F7B3A69F2 for <[e-mail]>; Thu,  5 Feb 2009 11:26:02 -0800 (PST)
Received: by fk-out-0910.google.com with SMTP id f33so360670fkf.5 for <[e-mail]>; Thu, 05 Feb 2009 11:26:02 -0800 (PST)
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=wfdLTRnsUOfAfReu1fi9tukwmEOU8BVhsjv+rTMrmJg=; b=eOXIOExuQ8CK8nSaXf/vfl87s9YlN4xrEhdYAAFHY5gv/CdnP7G09nzdunbSiUFNmS Abbm34OVLCFjBax////MoUAQZNe3WtfDyY9MPwzEX99Dwpflc3+59WUxfR9we3LMVINv l7P4Tey3Gu19xki9WfzfCPcR/VsJDxVwyQknU=
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=eStO8IcpJs5JkD/k2ZstOnzRhPNFghvmU+IaMKwL5ysW2sHOVD297PXEVLENhnuHTW FZ9KskjbjfktdIxPGS0SQl7FlhO/qzHHfhCnwR/EOSnErY1nyCgyWZbvRx7sHXtNnphT aDl4iTPPTe+8emOPx6WSnN/lL5RQvsGGZzXcE=
MIME-Version: 1.0
Received: by 10.181.146.11 with SMTP id y11mr279752bkn.5.1233861962263; Thu,  05 Feb 2009 11:26:02 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 5 Feb 2009 11:26:02 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: Dave Katz <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 19:26:04 -0000

Hi Dave,

You miss the basic point of networking!!! Two machines operate
independently and that is the reason they can both initiate poll at
the same time. There is no broken implementation required for this.
Try put a time buffer in you receive queue (this is to like simulating
overload - not a change of behavior) and change the parameters in both
the ends of the session. Your implementation will show you the same
behavior.

> Yes, it's to avoid the possibility of packet floods.  Since packets with
> Final can be sent without regard to rate control, it would open up a
> possibility of wire-rate packets being exchanged in both directions if
> packets with Poll could be sent the same way.  It would require a broken
> implementation for it to happen, but one of the overriding design criteria
> in BFD was to avoid catastrophic meltdown due to excessive packet
> transmission.
We have two different machines. They can initiate the poll at the same
time. There is no broken implementation at all. Poll can be initiated
at both ends symultaneously. Please explain what you mean by a broken
implementation? I have given you basic examples of how the same
problem has manifested in BGP.

You seem to be adding a lot of complexity into the spec for protecting
a case of some timer value which can change (which will rearly
happen). You are now stating that Poll bit is not sticky for certain
packets.

The problem is you are not seeing the difference between where the
spec needs to specify things and where the spec can let the
implementor do things themselves.

Thanks,
Vishwas

On Thu, Feb 5, 2009 at 10:35 AM, Dave Katz <[e-mail]> wrote:
>
> On Feb 5, 2009, at 11:13 AM, Vishwas Manral wrote:
>
>> Hi Dave,
>>
>> I thought over this issue.
>>
>>> One more case, I come across is what if the Poll is inititiated by the
>>> two ends symultaneously. I know you can all these exceptional
>>> conditions, but we finally had to write similar stuff in BGP when
>>> parallel connections are initiated symultaneously. The Poll isnt
>>> cleared till the final bit is got. So do we set the Poll and the Final
>>> bit togather (which is not allowed by the spec). Please clarify?
>>
>> I think the best way would be to allow FINAL and POLL bit in the same
>> packet. Is there a reason to explicitly disallow it?
>
> Yes, it's to avoid the possibility of packet floods.  Since packets with
> Final can be sent without regard to rate control, it would open up a
> possibility of wire-rate packets being exchanged in both directions if
> packets with Poll could be sent the same way.  It would require a broken
> implementation for it to happen, but one of the overriding design criteria
> in BFD was to avoid catastrophic meltdown due to excessive packet
> transmission.  It was felt that this requirement would provide some
> protection at little or no cost on the wire (potentially one extra packet if
> both sides feel the need to poll simultaneously) and a negligible increase
> in implementation complexity.
>
> The authors have watched networks melt into silicon sludge too many times
> over the years because of runaway control traffic (AOL down for 19 hours;
>  ATT SS7 down for hours;  MCI frame relay down for 10 days along with the
> Chicago Board of Trade) and we wanted to make double-sure that we weren't
> creating yet another way of taking down the infrastructure.  There is ample
> empirical data showing that most control protocol implementations do not
> behave well when they get overloaded.
>
> In any case, the scenario you describe is trivially dealt with if you
> consider packets with Final to be "extra" (not subject to scheduling) since
> they are supposed to be sent "as soon as practicable", and by definition any
> packet with Poll is done on a regular periodic basis.  Slightly different
> code paths for the two cases and you're done.
>
> --Dave
>
>>
>>
>> Thanks,
>> Vishwas
>>
>
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BBE33A6ABB for <[e-mail]>; Thu,  5 Feb 2009 13:01:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.588
X-Spam-Level: 
X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011,  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 xY3JfJWbpiu9 for <[e-mail]>; Thu,  5 Feb 2009 13:01:30 -0800 (PST)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 039403A6765 for <[e-mail]>; Thu,  5 Feb 2009 13:01:29 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSYtTpsGqaTqi1gUDnQCEiYfC6pdEB/[e-mail]; Thu, 05 Feb 2009 13:01:31 PST
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.336.0; Thu, 5 Feb 2009 12:55:18 -0800
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, 5 Feb 2009 12:55:18 -0800
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 12:55:18 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 12:55:17 -0800
Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n15KtGM85504; Thu, 5 Feb 2009 12:55:16 -0800 (PST)	(envelope-from [e-mail])
Message-ID: <[e-mail]>
From: Dave Katz <[e-mail]>
To: Vishwas Manral <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: More BFD base issues
Date: Thu, 5 Feb 2009 13:55:16 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 05 Feb 2009 20:55:17.0552 (UTC) FILETIME=[0CDEE300:01C987D4]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 21:01:31 -0000

On Feb 5, 2009, at 12:26 PM, Vishwas Manral wrote:

> Hi Dave,
>
> You miss the basic point of networking!!! Two machines operate
> independently and that is the reason they can both initiate poll at
> the same time. There is no broken implementation required for this.
> Try put a time buffer in you receive queue (this is to like simulating
> overload - not a change of behavior) and change the parameters in both
> the ends of the session. Your implementation will show you the same
> behavior.

And you're missing the point of what I'm saying.  There is nothing  
broken in having both sides wanting to Poll at the same time (and it  
in fact is quite likely to happen when a session first comes up, as  
both sides will likely be negotiating new transmit times.)  This works  
just fine with the spec as defined.

>
>
>> Yes, it's to avoid the possibility of packet floods.  Since packets  
>> with
>> Final can be sent without regard to rate control, it would open up a
>> possibility of wire-rate packets being exchanged in both directions  
>> if
>> packets with Poll could be sent the same way.  It would require a  
>> broken
>> implementation for it to happen, but one of the overriding design  
>> criteria
>> in BFD was to avoid catastrophic meltdown due to excessive packet
>> transmission.
> We have two different machines. They can initiate the poll at the same
> time. There is no broken implementation at all. Poll can be initiated
> at both ends symultaneously. Please explain what you mean by a broken
> implementation? I have given you basic examples of how the same
> problem has manifested in BGP.

The scenario we're trying to avoid is one in which two machines  
rapidly exchange packets with both P and F set.  The receipt of P  
requires an immediate response with F, but if P happens to be set in  
that rapid response, the first machine will rapidly respond with F.   
The brokenness would happen if one machine kept sending P with its F;   
in that case the packets would ricochet forever at wire speed.

The simple expedient of not allowing P and F together provides some  
leverage against this brokenness, at a cost of an extra packet.  Yes,  
we can't avoid all broken software (since by definition it could  
ignore this rule as well), but the rule provides some cheap insurance  
at very low cost.

>
>
> You seem to be adding a lot of complexity into the spec for protecting
> a case of some timer value which can change (which will rearly
> happen). You are now stating that Poll bit is not sticky for certain
> packets.

As we have discussed before, packet contents are *not* state  
variables.  This is clearly defined in the spec.  There is no such  
thing as a "sticky" value in a packet--packets are ephemeral.  How  
this is handled in an implementation is not the concern of the spec.

Further, this is not "a lot" of complexity.  I explained how one could  
code it in one sentence.  In our implementation it requires a handful  
of lines of code to pull off.

>
>
> The problem is you are not seeing the difference between where the
> spec needs to specify things and where the spec can let the
> implementor do things themselves.

Well, as the first implementor of BFD (and an active developer in our  
products) I do have a solid footing on what's spec and what's  
implementation.  I explained at length why the spec reads the way it  
does.  I see no use in belaboring this point.

--Dave



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40DE83A69E8 for <[e-mail]>; Thu,  5 Feb 2009 13:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 RidM9CwYa8dZ for <[e-mail]>; Thu,  5 Feb 2009 13:45:37 -0800 (PST)
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 7D9D23A67F6 for <[e-mail]>; Thu,  5 Feb 2009 13:45:36 -0800 (PST)
Received: by fxm13 with SMTP id 13so683714fxm.13 for <[e-mail]>; Thu, 05 Feb 2009 13:45:36 -0800 (PST)
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=76NloPa8nE65B/0snTH9fcjaHzr0i1JM8tZJ+hh4DB4=; b=KwsFVwf7DwtanMRDXnEThHqScyIeBt0uV/j/PSb4p5R/OQaevTWXaz6nEHxWAHd0hM tUoD1chg5hxuSiBIouQSQ9SCDjT/eaa+iOFgivKgjazXZOP0K+zgdbORSmHtkuKZF4sL UcFg8oicQAvwNrCBg0sS3gR9EYNnCQ04E2wLY=
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=xNqUjs4G1RkNtDMynfsuh4rUTnEGoaSDKVsWKw4P8zS3BJvA8z7L1I9HAo4RHBhmiN v7Mb5ZbGXzXol20vZINR/BsnsMBH2NoPPUqeuxrrU6NL44F2E2TnUEtJ+KCPmy5GUwa6 jfQqad6hIfbaV9PITcH49OvqKRWgCPYKkXKKQ=
MIME-Version: 1.0
Received: by 10.181.238.16 with SMTP id p16mr312861bkr.112.1233870336124; Thu,  05 Feb 2009 13:45:36 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 5 Feb 2009 13:45:36 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: Dave Katz <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 21:45:38 -0000

Hi Dave,

Atleast we now agree its not a broken implementation when the two ends
send the Poll symultaneously.

I have sent a simple suggestion to you in private a while back - will
wait for your reply. Another solution to prevent one extra packet
would be to just restart the Hello timer (which I think sound a lot
more simpler).

> The scenario we're trying to avoid is one in which two machines rapidly
> exchange packets with both P and F set.
The idea you said was to help avoid one packet send. I have told you
exactly how you can avoid the one extra packet send case.

It seems you want to go to great lengths to prevent one packet send.
My view is such things have generally been un-optimal and result in
more issues than fixes.

> Well, as the first implementor of BFD (and an active developer in our
> products) I do have a solid footing on what's spec and what's implementation.
>I explained at length why the spec reads the way it does.  I see no
> use in belaboring this point.
I do not deny the fact. You said that it was a broken implementation
if it happens (which we now agree was not the case). You also said
that it prevents a packet send, I have mentioned other ways to do the
same.

You could restart your packet send in case you send a Final bit and it
gets you the same behavior. Please explain how a simple and obvious
solution is not better than the solution you propose.

I also wanted to know if you felt your implementation is currently
handling this case correctly?

Thanks,
Vishwas

On Thu, Feb 5, 2009 at 12:55 PM, Dave Katz <[e-mail]> wrote:
>
> On Feb 5, 2009, at 12:26 PM, Vishwas Manral wrote:
>
>> Hi Dave,
>>
>> You miss the basic point of networking!!! Two machines operate
>> independently and that is the reason they can both initiate poll at
>> the same time. There is no broken implementation required for this.
>> Try put a time buffer in you receive queue (this is to like simulating
>> overload - not a change of behavior) and change the parameters in both
>> the ends of the session. Your implementation will show you the same
>> behavior.
>
> And you're missing the point of what I'm saying.  There is nothing broken in
> having both sides wanting to Poll at the same time (and it in fact is quite
> likely to happen when a session first comes up, as both sides will likely be
> negotiating new transmit times.)  This works just fine with the spec as
> defined.
>
>>
>>
>>> Yes, it's to avoid the possibility of packet floods.  Since packets with
>>> Final can be sent without regard to rate control, it would open up a
>>> possibility of wire-rate packets being exchanged in both directions if
>>> packets with Poll could be sent the same way.  It would require a broken
>>> implementation for it to happen, but one of the overriding design
>>> criteria
>>> in BFD was to avoid catastrophic meltdown due to excessive packet
>>> transmission.
>>
>> We have two different machines. They can initiate the poll at the same
>> time. There is no broken implementation at all. Poll can be initiated
>> at both ends symultaneously. Please explain what you mean by a broken
>> implementation? I have given you basic examples of how the same
>> problem has manifested in BGP.
>
> The scenario we're trying to avoid is one in which two machines rapidly
> exchange packets with both P and F set.  The receipt of P requires an
> immediate response with F, but if P happens to be set in that rapid
> response, the first machine will rapidly respond with F.  The brokenness
> would happen if one machine kept sending P with its F;  in that case the
> packets would ricochet forever at wire speed.
>
> The simple expedient of not allowing P and F together provides some leverage
> against this brokenness, at a cost of an extra packet.  Yes, we can't avoid
> all broken software (since by definition it could ignore this rule as well),
> but the rule provides some cheap insurance at very low cost.
>
>>
>>
>> You seem to be adding a lot of complexity into the spec for protecting
>> a case of some timer value which can change (which will rearly
>> happen). You are now stating that Poll bit is not sticky for certain
>> packets.
>
> As we have discussed before, packet contents are *not* state variables.
>  This is clearly defined in the spec.  There is no such thing as a "sticky"
> value in a packet--packets are ephemeral.  How this is handled in an
> implementation is not the concern of the spec.
>
> Further, this is not "a lot" of complexity.  I explained how one could code
> it in one sentence.  In our implementation it requires a handful of lines of
> code to pull off.
>
>>
>>
>> The problem is you are not seeing the difference between where the
>> spec needs to specify things and where the spec can let the
>> implementor do things themselves.
>
> Well, as the first implementor of BFD (and an active developer in our
> products) I do have a solid footing on what's spec and what's
> implementation.  I explained at length why the spec reads the way it does.
>  I see no use in belaboring this point.
>
> --Dave
>
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB3A28C145 for <[e-mail]>; Thu,  5 Feb 2009 14:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.588
X-Spam-Level: 
X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011,  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 CiO7+swHHjGr for <[e-mail]>; Thu,  5 Feb 2009 14:10:23 -0800 (PST)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id DE4123A68E5 for <[e-mail]>; Thu,  5 Feb 2009 14:10:22 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Thu, 05 Feb 2009 14:10:24 PST
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.336.0; Thu, 5 Feb 2009 14:04:27 -0800
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, 5 Feb 2009 14:04:26 -0800
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 14:04:26 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 14:04:25 -0800
Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n15M4OM19470; Thu, 5 Feb 2009 14:04:25 -0800 (PST)	(envelope-from [e-mail])
Message-ID: <[e-mail]>
From: Dave Katz <[e-mail]>
To: Vishwas Manral <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: More BFD base issues
Date: Thu, 5 Feb 2009 15:04:24 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 05 Feb 2009 22:04:25.0535 (UTC) FILETIME=[B542DCF0:01C987DD]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 22:10:24 -0000

On Feb 5, 2009, at 2:45 PM, Vishwas Manral wrote:

>>
> The idea you said was to help avoid one packet send. I have told you
> exactly how you can avoid the one extra packet send case.

No, you have it backwards.  The point is to avoid a meltdown, at the  
cost of one *extra* packet, which is essentially zero cost.

>
>
> It seems you want to go to great lengths to prevent one packet send.
> My view is such things have generally been un-optimal and result in
> more issues than fixes.

No, we go to small lengths to try not to destroy networks.

>
>
>> Well, as the first implementor of BFD (and an active developer in our
>> products) I do have a solid footing on what's spec and what's  
>> implementation.
>> I explained at length why the spec reads the way it does.  I see no
>> use in belaboring this point.
> I do not deny the fact. You said that it was a broken implementation
> if it happens (which we now agree was not the case). You also said
> that it prevents a packet send, I have mentioned other ways to do the
> same.
>
> You could restart your packet send in case you send a Final bit and it
> gets you the same behavior. Please explain how a simple and obvious
> solution is not better than the solution you propose.

You are free to implement it any way you want.  You just have to meet  
the transmission rate constraints and can't set P and F in the same  
packet.

>
>
> I also wanted to know if you felt your implementation is currently
> handling this case correctly?

Yes, and it is widely deployed, as are others'.

But the fact of the matter is that the spec has read this way for  
several years, it is technically sound, it has been reviewed by  
experts, there are multiple interoperable implementations out there,  
and the spec is in last call.  You are free to go to the WG and  
introduce a document to change the spec as you see fit.  But frankly  
this discussion is a waste of everyone's bandwidth.

--Dave


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A873A6ADF for <[e-mail]>; Thu,  5 Feb 2009 14:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tmntl4CHZHin for <[e-mail]>; Thu,  5 Feb 2009 14:25:59 -0800 (PST)
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 976263A6ADB for <[e-mail]>; Thu,  5 Feb 2009 14:25:58 -0800 (PST)
Received: by fxm13 with SMTP id 13so701552fxm.13 for <[e-mail]>; Thu, 05 Feb 2009 14:25:58 -0800 (PST)
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=PPmd+ErN9YnvaLIKPE4xc8WchqDZwBGCrZkliX6Shek=; b=jDSirGpunJZDM9pAWbH7QLC17mIfkhg8x/wGodlunbS90g0gfmemOedckNIMCnUYTP Qmf/bbvjVfygvbxq2tEl3yeUxpGiAbhOAfAh81fpe5PcGKprFBvHJY+RtEGnFumyxNwO EpRPgt3i3cXbSZjAgqUUDmgiATW6qr/Obevdk=
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=RaAIbqM68fFvXwt/9cvFzIA3Va8gIYOfgdf2xVJ1OtS6mM0De1Yx1FusTgA0m483sw bSoqKeqPQw/AI+Ima6jaKNeDh1WrY3/AxgK4nWlLt0hj5JnnKdqJ97e4ocZEYyyQ9f4M 6Ey0E3sTot1/+Y2zsbDW2OV+CXzWCISMR47hk=
MIME-Version: 1.0
Received: by 10.180.213.14 with SMTP id l14mr325923bkg.107.1233872758666; Thu,  05 Feb 2009 14:25:58 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 5 Feb 2009 14:25:58 -0800
Message-ID: <[e-mail]>
Subject: Re: More BFD base issues
From: Vishwas Manral <[e-mail]>
To: Dave Katz <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 22:26:00 -0000

Hi Dave,

You are unwilling to compare alternate similar/ simpler solutions.

I think we can leave the dicussion like you suggested.

Thanks,
Vishwas

On Thu, Feb 5, 2009 at 2:04 PM, Dave Katz <[e-mail]> wrote:
>
> On Feb 5, 2009, at 2:45 PM, Vishwas Manral wrote:
>
>>>
>> The idea you said was to help avoid one packet send. I have told you
>> exactly how you can avoid the one extra packet send case.
>
> No, you have it backwards.  The point is to avoid a meltdown, at the cost of
> one *extra* packet, which is essentially zero cost.
>
>>
>>
>> It seems you want to go to great lengths to prevent one packet send.
>> My view is such things have generally been un-optimal and result in
>> more issues than fixes.
>
> No, we go to small lengths to try not to destroy networks.
>
>>
>>
>>> Well, as the first implementor of BFD (and an active developer in our
>>> products) I do have a solid footing on what's spec and what's
>>> implementation.
>>> I explained at length why the spec reads the way it does.  I see no
>>> use in belaboring this point.
>>
>> I do not deny the fact. You said that it was a broken implementation
>> if it happens (which we now agree was not the case). You also said
>> that it prevents a packet send, I have mentioned other ways to do the
>> same.
>>
>> You could restart your packet send in case you send a Final bit and it
>> gets you the same behavior. Please explain how a simple and obvious
>> solution is not better than the solution you propose.
>
> You are free to implement it any way you want.  You just have to meet the
> transmission rate constraints and can't set P and F in the same packet.
>
>>
>>
>> I also wanted to know if you felt your implementation is currently
>> handling this case correctly?
>
> Yes, and it is widely deployed, as are others'.
>
> But the fact of the matter is that the spec has read this way for several
> years, it is technically sound, it has been reviewed by experts, there are
> multiple interoperable implementations out there, and the spec is in last
> call.  You are free to go to the WG and introduce a document to change the
> spec as you see fit.  But frankly this discussion is a waste of everyone's
> bandwidth.
>
> --Dave
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309863A6A31 for <[e-mail]>; Thu,  5 Feb 2009 14:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.178
X-Spam-Level: 
X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.421,  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 iWPccEnSs7FL for <[e-mail]>; Thu,  5 Feb 2009 14:35:36 -0800 (PST)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 57DCE3A6886 for <[e-mail]>; Thu,  5 Feb 2009 14:35:36 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Thu, 05 Feb 2009 14:35:38 PST
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.336.0; Thu, 5 Feb 2009 14:30:05 -0800
Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 14:30:05 -0800
Received: from 172.23.4.86 ([172.23.4.86]) by emailcorp3.jnpr.net ([66.129.254.13]) with Microsoft Exchange Server HTTP-DAV ; Thu,  5 Feb 2009 22:30:04 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Thu, 5 Feb 2009 14:31:01 -0800
Subject: Re: More BFD base issues
From: Nitin Bahadur <[e-mail]>
To: Dave Katz <[e-mail]>, Vishwas Manral <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: More BFD base issues
Thread-Index: AcmH4Ww7ZXnXdlHcCE2eqszZ7wDhXQ==
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Feb 2009 22:30:05.0146 (UTC) FILETIME=[4AF0DBA0:01C987E1]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 22:35:37 -0000

Folks,

  The BFD base spec is in IESG processing and close to being approved as an
RFC. Please do not make further protocol behavior changes to the spec unless
it's a big necessity and something is badly broken.

  That said, if there are optimizations that can be performed, then a new
draft can be written towards that effect.

  The discussion of allowing P & F bits simultaneously is moot at this point
IMO...since the spec has been stable for a while and any changes in that
regard would not only break existing implementations (if version number is
not bumped) but also more importantly push the spec another 6-9 months from
becoming an RFC.

> But the fact of the matter is that the spec has read this way for
> several years, it is technically sound, it has been reviewed by
> experts, there are multiple interoperable implementations out there,
> and the spec is in last call.  You are free to go to the WG and
> introduce a document to change the spec as you see fit.  But frankly
> this discussion is a waste of everyone's bandwidth.
> 
> --Dave

Thanks
Nitin



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B444528C14B for <[e-mail]>; Thu,  5 Feb 2009 14:53:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level: 
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023,  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 Kq+tA2Kb06Gz for <[e-mail]>; Thu,  5 Feb 2009 14:53:30 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C2F8328C148 for <[e-mail]>; Thu,  5 Feb 2009 14:53:29 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,388,1231113600"; d="scan'208";a="36101948"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2009 22:53:30 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n15MrUmR030683;  Thu, 5 Feb 2009 17:53:30 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n15MrULZ010568; Thu, 5 Feb 2009 22:53:30 GMT
Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 5 Feb 2009 17:53:30 -0500
Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 5 Feb 2009 17:53:30 -0500
Message-Id: <[e-mail]>
From: David Ward <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: BFD specs moving forward
Date: Thu, 5 Feb 2009 16:53:29 -0600
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 05 Feb 2009 22:53:30.0168 (UTC) FILETIME=[90663380:01C987E4]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=653; t=1233874410; x=1234738410; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20David=20Ward=20<[e-mail]> |Subject:=20BFD=20specs=20moving=20forward |Sender:=20 |To:=[e-mail]; bh=fSyJmRRmxZ3AEvfgOliKntpzSRQ36QPZHD4v2iGWbN0=; b=PmHDkmc8LFm3lsR+mz14b+joLHv8KMBYPYlaAzLtGxhl2Xg9mphRjF+Q/f UeD4y32jothlby+dvv3xs9p8iG8iXhligBXo6FXoBQTkmmsYKQgjVSLA0TCM Qi555fc7i4;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); 
Cc: David Ward <[e-mail]>, Dave Katz <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 22:53:30 -0000

We'll be publishing the specs w/ changes to address the IESG DISCUSS  
points and nits picked shortly. I know that everyone has wanted BFD to  
be an RFC long before now and originally we promised to have the  
fastest specification to RFC in the history of the IETF but, we've all  
learned a lot from wide implementation and deployment experience. As  
one should expect, it produced a much more sound protocol.

Not trying to be premature and irrational exuberance but, next on the  
plate will be a resubmission of the D&D p2mp draft. many other  
technologies are dependent on the point to multipoint solution.

Thanks

Dave and Dave



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 2603828C125; Thu,  5 Feb 2009 18:15:02 -0800 (PST)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-ietf-bfd-base-09.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 02:15:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.


	Title           : Bidirectional Forwarding Detection
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-ietf-bfd-base-09.txt
	Pages           : 49
	Date            : 2009-02-05

This document describes a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including
interfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency.  It operates
independently of media, data protocols, and routing protocols.



Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-bfd-base-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 3A47328C13C; Thu,  5 Feb 2009 18:15:02 -0800 (PST)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-ietf-bfd-v4v6-1hop-09.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 02:15:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.


	Title           : BFD for IPv4 and IPv6 (Single Hop)
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-ietf-bfd-v4v6-1hop-09.txt
	Pages           : 8
	Date            : 2009-02-05

This document describes the use of the Bidirectional Forwarding
Detection protocol over IPv4 and IPv6 for single IP hops.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-bfd-v4v6-1hop-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 4CF1028C14B; Thu,  5 Feb 2009 18:15:02 -0800 (PST)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-ietf-bfd-generic-05.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 02:15:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.


	Title           : Generic Application of BFD
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-ietf-bfd-generic-05.txt
	Pages           : 18
	Date            : 2009-02-05

This document describes the generic application of the Bidirectional
Forwarding Detection (BFD) protocol.



Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-bfd-generic-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 4FE4528C151; Thu,  5 Feb 2009 18:15:02 -0800 (PST)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-ietf-bfd-multihop-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 02:15:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.


	Title           : BFD for Multihop Paths
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-ietf-bfd-multihop-07.txt
	Pages           : 7
	Date            : 2009-02-05

This document describes the use of the Bidirectional Forwarding
Detection protocol (BFD) over multihop paths, including
unidirectional links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-bfd-multihop-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 6494D28C13C; Thu,  5 Feb 2009 18:15:02 -0800 (PST)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-katz-ward-bfd-multipoint-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 02:15:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.


	Title           : BFD for Multipoint Networks
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-katz-ward-bfd-multipoint-02.txt
	Pages           : 29
	Date            : 2009-02-05

This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast
networks.  Comments on this draft should be directed to rtg-
[e-mail].


Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-katz-ward-bfd-multipoint-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-katz-ward-bfd-multipoint-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--