From jhaas@pfrc.org Thu Nov 1 07:53:19 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A764321F8668 for ; Thu, 1 Nov 2012 07:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWQWNgTTyb5B for ; Thu, 1 Nov 2012 07:53:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F37E021F869F for ; Thu, 1 Nov 2012 07:53:16 -0700 (PDT) Received: from [192.168.1.85] (99-59-194-154.lightspeed.livnmi.sbcglobal.net [99.59.194.154]) by slice.pfrc.org (Postfix) with ESMTPSA id 17E90C0A3 for ; Thu, 1 Nov 2012 10:53:16 -0400 (EDT) From: PFRC - jhaas Content-Type: multipart/alternative; boundary="Apple-Mail=_7595E5E7-711F-47A1-91D5-A0B77E36DE9B" Subject: Help the NomCom Date: Thu, 1 Nov 2012 10:53:15 -0400 References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> To: rtg-bfd@ietf.org Message-Id: <3277058C-9F34-48DE-B1E5-9CAFE89E4EE6@pfrc.org> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:53:19 -0000 --Apple-Mail=_7595E5E7-711F-47A1-91D5-A0B77E36DE9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The NomCom would appreciate candidate feedback. Begin forwarded message: > From: NomCom Chair > Subject: CORRECTION: Help the NomCom > Date: November 1, 2012 8:17:22 AM EDT > To: Working Group Chairs >=20 > I sent a message several hours ago requesting that you help and make=20= > your working group aware that the NomCom is looking for input from the=20= > community. This message had a minor error. The NomCom needs to=20 > receive community input by November 11, 2012.=20 >=20 > The full text of the corrected message is below > --------------------------------------------------- >=20 > The IETF Nominations Committee (NomCom) continues to seek input from > the IETF Community. The NomCom would greatly appreciate any help you > could provide in making members of your working group aware of ways in > which they can provide valuable feedback to the NomCom. >=20 > In order to ensure that your input is received in time to be useful, = the=20 > NomCom needs to receive community feedback on or before Sunday, = November 11. >=20 > The final list of candidates (as per RFC 5680) that the NomCom is=20 > considering for open positions can be found at:=20 > https://www.ietf.org/group/nomcom/2012/input/ >=20 > The NomCom will be holding office hours during IETF 85, Monday- > Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes=20 > comments on specific individuals, as well as general feedback related = to=20 > any of the positions that NomCom is considering. >=20 > Note: A list of leadership positions that the NomCom is considering = can be=20 > found at: https://www.ietf.org/group/nomcom/2012/ >=20 > If the NomCom office hours are inconvenient for you or if you cannot=20= > attend IETF 85, the NomCom is happy to take community input via email=20= > to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange = a=20 > meeting outside of office hours, just send us email and we can set=20 > something up. >=20 > Comments on specific candidates can also be provided to the NomCom > via the web feedback tool:=20 > https://www.ietf.org/group/nomcom/2012/input/ >=20 > Thank you for your help, > - Matt Lepinski > nomcom-chair at ietf.org --Apple-Mail=_7595E5E7-711F-47A1-91D5-A0B77E36DE9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = NomCom would appreciate candidate feedback.

Begin = forwarded message:

From: NomCom Chair <nomcom-chair@ietf.org>
Subject: CORRECTION: Help the = NomCom
Date: November 1, 2012 8:17:22 AM EDT
To: Working Group = Chairs <wgchairs@ietf.org>

I sent a message several hours ago requesting that you help = and make
your working group aware that the NomCom is looking for = input from the
community. This message had a minor error. The NomCom = needs to
receive community input by November 11, 2012.

The = full text of the corrected message is = below
---------------------------------------------------

The = IETF Nominations Committee (NomCom) continues to seek input from
the = IETF Community. The NomCom would greatly appreciate any help = you
could provide in making members of your working group aware of = ways in
which they can provide valuable feedback to the = NomCom.

In order to ensure that your input is received in time to = be useful, the
NomCom needs to receive community feedback on or = before Sunday, November 11.

The final list of candidates (as per = RFC 5680) that the NomCom is
considering for open positions can be = found at:
https://www.ietf.or= g/group/nomcom/2012/input/

The NomCom will be holding office = hours during IETF 85, Monday-
Thursday from 1:00pm to 3:00pm in Room = 305. The NomCom welcomes
comments on specific individuals, as well = as general feedback related to
any of the positions that NomCom is = considering.

Note: A list of leadership positions that the NomCom = is considering can be
found at: = https://www.ietf.org/group/nomcom/2012/

If the NomCom office = hours are inconvenient for you or if you cannot
attend IETF 85, the = NomCom is happy to take community input via email
to nomcom12 at = ietf.org. Additionally, the NomCom is happy to arrange a
meeting = outside of office hours, just send us email and we can set
something = up.

Comments on specific candidates can also be provided to the = NomCom
via the web feedback tool: =
https://www.ietf.org/group/nomcom/2012/input/

Thank you for = your help,
- Matt Lepinski
 nomcom-chair at = ietf.org

= --Apple-Mail=_7595E5E7-711F-47A1-91D5-A0B77E36DE9B-- From jhaas@slice.pfrc.org Sun Nov 4 08:00:44 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E56D21F86C7 for ; Sun, 4 Nov 2012 08:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.851 X-Spam-Level: X-Spam-Status: No, score=-99.851 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0rqhKm6nocf for ; Sun, 4 Nov 2012 08:00:44 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 29D9621F860D for ; Sun, 4 Nov 2012 08:00:44 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 86A27C2A7; Sun, 4 Nov 2012 11:00:43 -0500 (EST) Date: Sun, 4 Nov 2012 11:00:43 -0500 From: Jeffrey Haas To: Havard Eidnes Subject: Re: Monitoring BFD sessions Message-ID: <20121104160043.GA30108@pfrc> References: <20121030.103101.409931545.he@uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121030.103101.409931545.he@uninett.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 16:00:44 -0000 Havard, On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes wrote: > I'm maintaining a small software package we use to monitor > certain aspects of our network, and among them I'm monitoring BFD > session states, using a couple of vendors' interim versions of > the BFD MIB (implanted in their own enterprises tree for the time > being). > > With one of the vendors I'm observing strange behaviour, in that > almost every time a BFD session goes through an operational > down->up state transition (after first going through an up->down > state transition), the implementation chooses a new BFD > discriminator for the session. This behavior is likely desirable in the grand scheme of things. In particular, it helps prevent replay attacks against the protocol. > Furthermore, it looks as if the vendor is using the value of the > local discriminator when forming the bfdSessIndex value in the > MIB. This is probably the problematic thing for you. The MIB session index ideally should be a management facing entity and thus have a level of stability imposed by configuration. Nothing prohibits it from changing in the way you're noticing, but it's something I'd press my vendor to fix. > So my questions here are twofold: > > 1) Is there a problem with the specifications as written that > allows an implementor to (in my opinion) totally de-value the > usefulness of the bfdSessTable? I'd argue the table is fine. Your vendor should not bind the session index to the local discriminator. > 2) Is the implementor in question defending unreasonable > behaviour which instead belongs in the "implementation bug" > category? Unfortunately, it's in the "compliant, but annoying" category. -- Jeff (Who realizes the vendor in question may be his employer. If so, please feel free to involve me in applying the hammer of clue to the problem report.) From marc@sniff.de Mon Nov 5 03:32:50 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C406921F8606 for ; Mon, 5 Nov 2012 03:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gblwfNbPmgpP for ; Mon, 5 Nov 2012 03:32:39 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7307421F85FC for ; Mon, 5 Nov 2012 03:32:38 -0800 (PST) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 11B3F2AA0F; Mon, 5 Nov 2012 11:32:35 +0000 (GMT) Subject: Re: Monitoring BFD sessions Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20121104160043.GA30108@pfrc> Date: Mon, 5 Nov 2012 12:32:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <921D4A38-D923-4BEC-81BE-11D2BA87DD95@sniff.de> References: <20121030.103101.409931545.he@uninett.no> <20121104160043.GA30108@pfrc> To: Havard Eidnes , Jeffrey Haas X-Mailer: Apple Mail (2.1084) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 11:32:50 -0000 Hello Havard, Jeff et al. >> With one of the vendors I'm observing strange behaviour, in that >> almost every time a BFD session goes through an operational >> down->up state transition (after first going through an up->down >> state transition), the implementation chooses a new BFD >> discriminator for the session. >=20 > This behavior is likely desirable in the grand scheme of things. In > particular, it helps prevent replay attacks against the protocol. Let me guess: BFD is requested by OSPF or ISIS? At least one vendor I know requests the BFD session after OSPF/ISIS has = discovered a neighbor with the Hello mechanism. The consequence of BFD = going down, which is treated like a Hello failure, is that the = discovered neighbor information is - strictly speaking - not valid = anymore. The BFD session is deleted. Once OSPF/ISIS re-detect the = neighbor a _new_ BFD session is started. Which uses a new Discriminator. As Jeff said, "in the grand scheme of things" this makes sense, even = when it looks odd from the BFD level. Regards, Marc On 2012-11-04, at 17:00 , Jeffrey Haas wrote: > Havard, >=20 > On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes wrote: >> I'm maintaining a small software package we use to monitor >> certain aspects of our network, and among them I'm monitoring BFD >> session states, using a couple of vendors' interim versions of >> the BFD MIB (implanted in their own enterprises tree for the time >> being). >>=20 >> With one of the vendors I'm observing strange behaviour, in that >> almost every time a BFD session goes through an operational >> down->up state transition (after first going through an up->down >> state transition), the implementation chooses a new BFD >> discriminator for the session. >=20 > This behavior is likely desirable in the grand scheme of things. In > particular, it helps prevent replay attacks against the protocol. >=20 >> Furthermore, it looks as if the vendor is using the value of the >> local discriminator when forming the bfdSessIndex value in the >> MIB. >=20 > This is probably the problematic thing for you. The MIB session index > ideally should be a management facing entity and thus have a level of > stability imposed by configuration. Nothing prohibits it from = changing in > the way you're noticing, but it's something I'd press my vendor to = fix.=20 >=20 >> So my questions here are twofold: >>=20 >> 1) Is there a problem with the specifications as written that >> allows an implementor to (in my opinion) totally de-value the >> usefulness of the bfdSessTable? >=20 > I'd argue the table is fine. Your vendor should not bind the session = index > to the local discriminator. >=20 >> 2) Is the implementor in question defending unreasonable >> behaviour which instead belongs in the "implementation bug" >> category? >=20 > Unfortunately, it's in the "compliant, but annoying" category. >=20 > -- Jeff > (Who realizes the vendor in question may be his employer. If so, = please > feel free to involve me in applying the hammer of clue to the problem = report.) >=20 -- Marc Binderberger From binnyjeshan@gmail.com Mon Nov 5 03:51:19 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE09621F85DD for ; Mon, 5 Nov 2012 03:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzTf9hiqA+Jp for ; Mon, 5 Nov 2012 03:51:19 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C990F21F85D8 for ; Mon, 5 Nov 2012 03:51:18 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id 25so2080259qao.10 for ; Mon, 05 Nov 2012 03:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5sPs7g1EuGgDsIuUHi6BEcKpd8vq5qfvOM8PuxbnJSc=; b=zypTlJsvGgll6GIatgVqxIM9TGDz8h6icGM96efWMae78LWG0vGJ4qzgVGaNrtn2Ad 9NexoVz0+rcwKyOTZkEb+KVDH6P7UMY4XYJEfrzHu1qj3anjVqxSKivGVN2uxLINbciK kqi7mRgmlN19qSz409XKKlhXoIusc+0v0lVczMjNE9Z77GS5qfEh8hF51cZcZUPkQZCg XbfOs7gCZsU0Wp44WlIiXrvdl/2QXw7AjvqjoHAOOjASIOsIWGvTY6TntDyhtMqazv6y sZCKZOSl1V1uRE7mfBfn3cZj7+qWWuimx1KHqv6pWI3PepyKrBt7i3iSuaUdE3B1m7N9 Ovcg== MIME-Version: 1.0 Received: by 10.49.72.199 with SMTP id f7mr16746251qev.43.1352116278263; Mon, 05 Nov 2012 03:51:18 -0800 (PST) Received: by 10.49.61.69 with HTTP; Mon, 5 Nov 2012 03:51:18 -0800 (PST) In-Reply-To: <921D4A38-D923-4BEC-81BE-11D2BA87DD95@sniff.de> References: <20121030.103101.409931545.he@uninett.no> <20121104160043.GA30108@pfrc> <921D4A38-D923-4BEC-81BE-11D2BA87DD95@sniff.de> Date: Mon, 5 Nov 2012 17:21:18 +0530 Message-ID: Subject: Re: Monitoring BFD sessions From: Binny Jeshan To: Marc Binderberger Content-Type: multipart/alternative; boundary=047d7b676b3e75fdce04cdbe1ab1 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 11:51:20 -0000 --047d7b676b3e75fdce04cdbe1ab1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, I think changing discriminator is fine, if i go as per section 6.3 of RFC 5880.. What do you think of the below lines Havard / Jeff? " Note that it is permissible for a system to change its discriminator during a session without affecting the session state, since only that system uses its discriminator for demultiplexing purposes (by having the other system reflect it back). The implications on an implementation for changing the discriminator value is outside the scope of this specification." Ofcourse if there are any implications then i'd think that has to be dealt with. Example is that if the receive processing is affected so as to cause a session going down. or may be it could be some attacker sending BFD packets. This need to be fixed at the receiver end. But if i'd there to be implementing BFD, i'd inititate a poll sequence to finish the job clean and make the remote understand the parameter change better. " If the Your Discriminator field is nonzero, it MUST be used to select the session with which this BFD packet is associated. If no session is found, the packet MUST be discarded=93 What do you think? Regards, Binny Jeshan On 5 November 2012 17:02, Marc Binderberger wrote: > Hello Havard, Jeff et al. > > >> With one of the vendors I'm observing strange behaviour, in that > >> almost every time a BFD session goes through an operational > >> down->up state transition (after first going through an up->down > >> state transition), the implementation chooses a new BFD > >> discriminator for the session. > > > > This behavior is likely desirable in the grand scheme of things. In > > particular, it helps prevent replay attacks against the protocol. > > > > Let me guess: BFD is requested by OSPF or ISIS? > > At least one vendor I know requests the BFD session after OSPF/ISIS has > discovered a neighbor with the Hello mechanism. The consequence of BFD > going down, which is treated like a Hello failure, is that the discovered > neighbor information is - strictly speaking - not valid anymore. The BFD > session is deleted. Once OSPF/ISIS re-detect the neighbor a _new_ BFD > session is started. Which uses a new Discriminator. > > > As Jeff said, "in the grand scheme of things" this makes sense, even when > it looks odd from the BFD level. > > > Regards, Marc > > > > On 2012-11-04, at 17:00 , Jeffrey Haas wrote: > > > Havard, > > > > On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes wrote: > >> I'm maintaining a small software package we use to monitor > >> certain aspects of our network, and among them I'm monitoring BFD > >> session states, using a couple of vendors' interim versions of > >> the BFD MIB (implanted in their own enterprises tree for the time > >> being). > >> > >> With one of the vendors I'm observing strange behaviour, in that > >> almost every time a BFD session goes through an operational > >> down->up state transition (after first going through an up->down > >> state transition), the implementation chooses a new BFD > >> discriminator for the session. > > > > This behavior is likely desirable in the grand scheme of things. In > > particular, it helps prevent replay attacks against the protocol. > > > >> Furthermore, it looks as if the vendor is using the value of the > >> local discriminator when forming the bfdSessIndex value in the > >> MIB. > > > > This is probably the problematic thing for you. The MIB session index > > ideally should be a management facing entity and thus have a level of > > stability imposed by configuration. Nothing prohibits it from changing > in > > the way you're noticing, but it's something I'd press my vendor to fix. > > > >> So my questions here are twofold: > >> > >> 1) Is there a problem with the specifications as written that > >> allows an implementor to (in my opinion) totally de-value the > >> usefulness of the bfdSessTable? > > > > I'd argue the table is fine. Your vendor should not bind the session > index > > to the local discriminator. > > > >> 2) Is the implementor in question defending unreasonable > >> behaviour which instead belongs in the "implementation bug" > >> category? > > > > Unfortunately, it's in the "compliant, but annoying" category. > > > > -- Jeff > > (Who realizes the vendor in question may be his employer. If so, pleas= e > > feel free to involve me in applying the hammer of clue to the problem > report.) > > > > -- > Marc Binderberger > > --047d7b676b3e75fdce04cdbe1ab1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello,

I think changing discriminator is fine, if i go a= s per section 6.3 of RFC 5880.. What do you think of the below lines Havard= / Jeff?=A0

" = Note that it is permissible for a system to change its discriminator= 
   during a session without affecting the session state, since only th=
at
   system uses its discriminator for demultiplexing purposes (by having
   the other system reflect it back).  The implications on an
   implementation for changing the discriminator value is outside the
   scope of this specification."

Ofcourse if there=
 are any implications then i'd think that has to be dealt with. Example=
 is that if the receive processing is affected so as to cause =A0a session =
going down. or may be it could be some attacker sending BFD packets. This n=
eed to be fixed at the receiver end. But if i'd there to be implementin=
g BFD, i'd inititate a poll sequence to finish the job clean and make t=
he remote understand the parameter change better.=A0
<=
br>
"      If the Your Discriminator field is non=
zero, it MUST be used to
      select the session with which this BFD packet is associated.  If
      no session is found, the packet MUST be discarded=93

<=
/pre>

What do you think?

Regards,=A0


B=
inny Jeshan


On 5 November 2012 17:02, Mar=
c Binderberger <marc@sniff.de> wrote:

Hello Havard, Jeff et al.




>> With one of the vendors I'm observing strange behaviour, in th=
at

>> almost every time a BFD session goes through an operational

>> down->up state transition (after first going through an up->=
down

>> state transition), the implementation chooses a new BFD

>> discriminator for the session.

>

> This behavior is likely desirable in the grand scheme of things. =A0In=


> particular, it helps prevent replay attacks against the protocol.








Let me guess: BFD is requested by OSPF or ISIS?



At least one vendor I know requests the BFD session after OSPF/ISIS has dis=
covered a neighbor with the Hello mechanism. The consequence of BFD going d=
own, which is treated like a Hello failure, is that the discovered neighbor=
 information is - strictly speaking - not valid anymore. The BFD session is=
 deleted. Once OSPF/ISIS re-detect the neighbor a _new_ BFD session is star=
ted. Which uses a new Discriminator.






As Jeff said, "in the grand scheme of things" this makes sense, e=
ven when it looks odd from the BFD level.





Regards, Marc








On 2012-11-04, at 17:00 , Jeffrey Haas wrote:



> Havard,

>

> On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes wrote:

>> I'm maintaining a small software package we use to monitor

>> certain aspects of our network, and among them I'm monitoring =
BFD

>> session states, using a couple of vendors' interim versions of=


>> the BFD MIB (implanted in their own enterprises tree for the time<=
br>
>> being).

>>

>> With one of the vendors I'm observing strange behaviour, in th=
at

>> almost every time a BFD session goes through an operational

>> down->up state transition (after first going through an up->=
down

>> state transition), the implementation chooses a new BFD

>> discriminator for the session.

>

> This behavior is likely desirable in the grand scheme of things. =A0In=


> particular, it helps prevent replay attacks against the protocol.

>

>> Furthermore, it looks as if the vendor is using the value of the
>> local discriminator when forming the bfdSessIndex value in the

>> MIB.

>

> This is probably the problematic thing for you. =A0The MIB session ind=
ex

> ideally should be a management facing entity and thus have a level of<=
br>
> stability imposed by configuration. =A0Nothing prohibits it from chang=
ing in

> the way you're noticing, but it's something I'd press my v=
endor to fix.

>

>> So my questions here are twofold:

>>

>> 1) Is there a problem with the specifications as written that

>> =A0 allows an implementor to (in my opinion) totally de-value the<=
br>
>> =A0 usefulness of the bfdSessTable?

>

> I'd argue the table is fine. =A0Your vendor should not bind the se=
ssion index

> to the local discriminator.

>

>> 2) Is the implementor in question defending unreasonable

>> =A0 behaviour which instead belongs in the "implementation bu=
g"

>> =A0 category?

>

> Unfortunately, it's in the "compliant, but annoying" cat=
egory.

>

> -- Jeff

> (Who realizes the vendor in question may be his employer. =A0If so, pl=
ease

> feel free to involve me in applying the hammer of clue to the problem =
report.)

>




--

Marc Binderberger =A0 =A0 =A0 =A0 =A0 <=
marc@sniff.de>







--047d7b676b3e75fdce04cdbe1ab1--

From marc@sniff.de  Mon Nov  5 05:37:26 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF3A21F86F9 for ; Mon,  5 Nov 2012 05:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.044
X-Spam-Level: 
X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ue0GV8sOin9 for ; Mon,  5 Nov 2012 05:37:25 -0800 (PST)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2B21F86E3 for ; Mon,  5 Nov 2012 05:37:24 -0800 (PST)
Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 2C7E32AA0F; Mon,  5 Nov 2012 13:37:23 +0000 (GMT)
Subject: Re: Monitoring BFD sessions
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Marc Binderberger 
In-Reply-To: 
Date: Mon, 5 Nov 2012 14:37:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121030.103101.409931545.he@uninett.no> <20121104160043.GA30108@pfrc> <921D4A38-D923-4BEC-81BE-11D2BA87DD95@sniff.de> 
To: Binny Jeshan 
X-Mailer: Apple Mail (2.1084)
Cc: rtg-bfd@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 13:37:26 -0000

Hello Binny,

> But if i'd there to be implementing BFD, i'd inititate a poll sequence =
to finish the job clean and make the remote understand the parameter =
change better.=20

point is there is nothing to understand for the remote system "R2" when =
"R1" is changing it's local discriminator. For R2 this is just a number =
to be used for the your_discr field.

Any attempt to help "R2" to "understand" is just weakening a clean & =
simple statement: that R2 has no business in understanding the =
discriminator of R1.

And the comment about the "implication" simply points out the fact that =
you are not automatically covered yourself by the RFC when you change =
your discriminator. In other words: you must know what you do :-)


Regards, Marc

P.S.: of course you can send P/F, should not cause any harm either.





On 2012-11-05, at 12:51 , Binny Jeshan wrote:

> Hello,
>=20
> I think changing discriminator is fine, if i go as per section 6.3 of =
RFC 5880.. What do you think of the below lines Havard / Jeff?=20
>=20
> " Note that it is permissible for a system to change its discriminator
>    during a session without affecting the session state, since only =
that
>    system uses its discriminator for demultiplexing purposes (by =
having
>    the other system reflect it back).  The implications on an
>    implementation for changing the discriminator value is outside the
>    scope of this specification."
>=20
>=20
> Ofcourse if there are any implications then i'd think that has to be =
dealt with. Example is that if the receive processing is affected so as =
to cause  a session going down. or may be it could be some attacker =
sending BFD packets. This need to be fixed at the receiver end. But if =
i'd there to be implementing BFD, i'd inititate a poll sequence to =
finish the job clean and make the remote understand the parameter change =
better.=20
>=20
> "      If the Your Discriminator field is nonzero, it MUST be used to
>       select the session with which this BFD packet is associated.  If
>       no session is found, the packet MUST be discarded=93
>=20
>=20
>=20
> What do you think?
>=20
> Regards,=20
> Binny Jeshan
>=20
>=20
> On 5 November 2012 17:02, Marc Binderberger  wrote:
> Hello Havard, Jeff et al.
>=20
> >> With one of the vendors I'm observing strange behaviour, in that
> >> almost every time a BFD session goes through an operational
> >> down->up state transition (after first going through an up->down
> >> state transition), the implementation chooses a new BFD
> >> discriminator for the session.
> >
> > This behavior is likely desirable in the grand scheme of things.  In
> > particular, it helps prevent replay attacks against the protocol.
>=20
>=20
>=20
> Let me guess: BFD is requested by OSPF or ISIS?
>=20
> At least one vendor I know requests the BFD session after OSPF/ISIS =
has discovered a neighbor with the Hello mechanism. The consequence of =
BFD going down, which is treated like a Hello failure, is that the =
discovered neighbor information is - strictly speaking - not valid =
anymore. The BFD session is deleted. Once OSPF/ISIS re-detect the =
neighbor a _new_ BFD session is started. Which uses a new Discriminator.
>=20
>=20
> As Jeff said, "in the grand scheme of things" this makes sense, even =
when it looks odd from the BFD level.
>=20
>=20
> Regards, Marc
>=20
>=20
>=20
> On 2012-11-04, at 17:00 , Jeffrey Haas wrote:
>=20
> > Havard,
> >
> > On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes wrote:
> >> I'm maintaining a small software package we use to monitor
> >> certain aspects of our network, and among them I'm monitoring BFD
> >> session states, using a couple of vendors' interim versions of
> >> the BFD MIB (implanted in their own enterprises tree for the time
> >> being).
> >>
> >> With one of the vendors I'm observing strange behaviour, in that
> >> almost every time a BFD session goes through an operational
> >> down->up state transition (after first going through an up->down
> >> state transition), the implementation chooses a new BFD
> >> discriminator for the session.
> >
> > This behavior is likely desirable in the grand scheme of things.  In
> > particular, it helps prevent replay attacks against the protocol.
> >
> >> Furthermore, it looks as if the vendor is using the value of the
> >> local discriminator when forming the bfdSessIndex value in the
> >> MIB.
> >
> > This is probably the problematic thing for you.  The MIB session =
index
> > ideally should be a management facing entity and thus have a level =
of
> > stability imposed by configuration.  Nothing prohibits it from =
changing in
> > the way you're noticing, but it's something I'd press my vendor to =
fix.
> >
> >> So my questions here are twofold:
> >>
> >> 1) Is there a problem with the specifications as written that
> >>   allows an implementor to (in my opinion) totally de-value the
> >>   usefulness of the bfdSessTable?
> >
> > I'd argue the table is fine.  Your vendor should not bind the =
session index
> > to the local discriminator.
> >
> >> 2) Is the implementor in question defending unreasonable
> >>   behaviour which instead belongs in the "implementation bug"
> >>   category?
> >
> > Unfortunately, it's in the "compliant, but annoying" category.
> >
> > -- Jeff
> > (Who realizes the vendor in question may be his employer.  If so, =
please
> > feel free to involve me in applying the hammer of clue to the =
problem report.)
> >
>=20
> --
> Marc Binderberger           
>=20
>=20

--
Marc Binderberger           


From he@uninett.no  Mon Nov  5 06:12:12 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DEA21F8701 for ; Mon,  5 Nov 2012 06:12:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.872
X-Spam-Level: 
X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.727,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mNO7bWR16t6 for ; Mon,  5 Nov 2012 06:12:12 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 1490821F867F for ; Mon,  5 Nov 2012 06:12:11 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id E01793D0B4; Mon,  5 Nov 2012 15:12:09 +0100 (CET)
Date: Mon, 05 Nov 2012 15:12:09 +0100 (CET)
Message-Id: <20121105.151209.213953459.he@uninett.no>
To: jhaas@pfrc.org
Subject: Re: Monitoring BFD sessions
From: Havard Eidnes 
In-Reply-To: <20121104160043.GA30108@pfrc>
References: <20121030.103101.409931545.he@uninett.no> <20121104160043.GA30108@pfrc>
X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: rtg-bfd@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 14:12:13 -0000

>> With one of the vendors I'm observing strange behaviour, in that
>> almost every time a BFD session goes through an operational
>> down->up state transition (after first going through an up->down
>> state transition), the implementation chooses a new BFD
>> discriminator for the session.
>
> This behavior is likely desirable in the grand scheme of things.  In
> particular, it helps prevent replay attacks against the protocol.

OK, I understand there may be good reasons to do this.

>> Furthermore, it looks as if the vendor is using the value of the
>> local discriminator when forming the bfdSessIndex value in the
>> MIB.
>
> This is probably the problematic thing for you.  The MIB session inde=
x
> ideally should be a management facing entity and thus have a level of=

> stability imposed by configuration.  Nothing prohibits it from changi=
ng in
> the way you're noticing, but it's something I'd press my vendor to fi=
x. =


I agree -- this would probably be the best thing.  The current
text for the bfdSessIndex is:

    bfdSessIndex OBJECT-TYPE
        SYNTAX     BfdSessIndexTC
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION
            "This object contains an index used to represent a
             unique BFD session on this device."
        ::=3D { bfdSessEntry 1 }

Now...  As Marc Binderber guesses, the BFD sessions are in my
case configured as part of the IS-IS configuration.  And as he
says, the device acts as if the BFD session is deleted (I beleive
this is also evident via the CLI, it will then not be there at
all) when the BFD adjacency is lost and subsequently also the
IS-IS adjacency is lost.

So then the question comes up: what is the administrative
lifetime of a BFD session which is configured in this way, and is
the administrator in control of it?  Or can one say that since
something appears to delete the session (the IS-IS process?),
strictly speaking, a new session is created when the neighborship
is re-established, so since this is a different session than the
one who existed earlier, it makes sense to not use the same
bfdSessIndex value to refer to this different session?

That would be ... most annoying, and leaves me exactly where I
started, with no straight-forward way to automatically dig out
the longer-term state changes for the BFD neighborship between
these two neighboring routers using the BFD MIB.  The only way
would be to construct my own "bfd session index", possibly
consisting of "interface, ip-address-type, dest-ip-addr" (or
possibly more, to support multiple BFD sessions between two
neighboring routers).  However, to me this smells of bad MIB
design -- if those are the values an administrator have to build
an index on, why are they not already index values in the BFD
session table?

Is all this the way it should be?

Is there some text which needs to go in somewhere to discourage
this behaviour?

Regards,

- H=E5vard

From binnyjeshan@gmail.com  Mon Nov  5 10:02:21 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929AB21F8417 for ; Mon,  5 Nov 2012 10:02:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKPpJqPA+wDa for ; Mon,  5 Nov 2012 10:02:20 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42C4821F886F for ; Mon,  5 Nov 2012 10:01:20 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id b25so396964qca.31 for ; Mon, 05 Nov 2012 10:01:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jWGvM0h6NI9Lft7SpH0siJ8CgyTMvTzXrsN+W+D6IFg=; b=i2O6ESTTfvG+cTVIBcTiTf5zGwKckiG4me8PHBe7Y4g4p7Q9f2ir38dJxBGyB5Niyz dGhVyUmY+0ogr8vRYLZ+bKU8ydgf02y8y+sa4O/hZ9YhvKD++N5FitiMG/kRbNU55gcO +Mhm/O615t0IAf9KKys1On+AJ9YawANQisN/5cu8so6eL6ciLKi3wYLHQFJRCiE0HXz7 bmeAd0iqLORIsjMHajPtN6UYimUhWZHJ9QBacEFhE9MD5h6Tue1YDul+4483f9Ti6wxz opj4WGnQe3MaZwD0cHP62rckONj1eBK5i8EJG0dXS7mAVn8XVh35YgVJtWmVqMK3hl0x o8fg==
MIME-Version: 1.0
Received: by 10.49.71.38 with SMTP id r6mr18739157qeu.42.1352138480475; Mon, 05 Nov 2012 10:01:20 -0800 (PST)
Received: by 10.49.61.69 with HTTP; Mon, 5 Nov 2012 10:01:20 -0800 (PST)
In-Reply-To: 
References: <20121030.103101.409931545.he@uninett.no> <20121104160043.GA30108@pfrc> <921D4A38-D923-4BEC-81BE-11D2BA87DD95@sniff.de>  
Date: Mon, 5 Nov 2012 23:31:20 +0530
Message-ID: 
Subject: Re: Monitoring BFD sessions
From: Binny Jeshan 
To: Marc Binderberger 
Content-Type: multipart/alternative; boundary=047d7b5d8b5dd0de9104cdc3453c
Cc: rtg-bfd@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 18:02:21 -0000

--047d7b5d8b5dd0de9104cdc3453c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello Mark,

What i meant is this - If R1 changes its Local discriminator and sends new
packets, R1 should be still able to receive packets from R2 which sends
packets using old "Your discriminator" of R1, which R2 learnt earlier
before the discriminator change. The receive processing of R1 should be in
a position to remember its old discriminator somewhere to demultiplex the
packet to its correct session.

Thats where I'd prefer to do a Poll Sequence to do any such parameter
changes in packet, be it be a Authentication change or a Discriminator
change. Because that would ensure the session state undisturbed.

Regards,
Binny.

On 5 November 2012 19:07, Marc Binderberger  wrote:

> Hello Binny,
>
> > But if i'd there to be implementing BFD, i'd inititate a poll sequence
> to finish the job clean and make the remote understand the parameter chan=
ge
> better.
>
> point is there is nothing to understand for the remote system "R2" when
> "R1" is changing it's local discriminator. For R2 this is just a number t=
o
> be used for the your_discr field.
>
> Any attempt to help "R2" to "understand" is just weakening a clean &
> simple statement: that R2 has no business in understanding the
> discriminator of R1.
>
> And the comment about the "implication" simply points out the fact that
> you are not automatically covered yourself by the RFC when you change you=
r
> discriminator. In other words: you must know what you do :-)
>
>
> Regards, Marc
>
> P.S.: of course you can send P/F, should not cause any harm either.
>
>
>
>
>
> On 2012-11-05, at 12:51 , Binny Jeshan wrote:
>
> > Hello,
> >
> > I think changing discriminator is fine, if i go as per section 6.3 of
> RFC 5880.. What do you think of the below lines Havard / Jeff?
> >
> > " Note that it is permissible for a system to change its discriminator
> >    during a session without affecting the session state, since only tha=
t
> >    system uses its discriminator for demultiplexing purposes (by having
> >    the other system reflect it back).  The implications on an
> >    implementation for changing the discriminator value is outside the
> >    scope of this specification."
> >
> >
> > Ofcourse if there are any implications then i'd think that has to be
> dealt with. Example is that if the receive processing is affected so as t=
o
> cause  a session going down. or may be it could be some attacker sending
> BFD packets. This need to be fixed at the receiver end. But if i'd there =
to
> be implementing BFD, i'd inititate a poll sequence to finish the job clea=
n
> and make the remote understand the parameter change better.
> >
> > "      If the Your Discriminator field is nonzero, it MUST be used to
> >       select the session with which this BFD packet is associated.  If
> >       no session is found, the packet MUST be discarded=93
> >
> >
> >
> > What do you think?
> >
> > Regards,
> > Binny Jeshan
> >
> >
> > On 5 November 2012 17:02, Marc Binderberger  wrote:
> > Hello Havard, Jeff et al.
> >
> > >> With one of the vendors I'm observing strange behaviour, in that
> > >> almost every time a BFD session goes through an operational
> > >> down->up state transition (after first going through an up->down
> > >> state transition), the implementation chooses a new BFD
> > >> discriminator for the session.
> > >
> > > This behavior is likely desirable in the grand scheme of things.  In
> > > particular, it helps prevent replay attacks against the protocol.
> >
> >
> >
> > Let me guess: BFD is requested by OSPF or ISIS?
> >
> > At least one vendor I know requests the BFD session after OSPF/ISIS has
> discovered a neighbor with the Hello mechanism. The consequence of BFD
> going down, which is treated like a Hello failure, is that the discovered
> neighbor information is - strictly speaking - not valid anymore. The BFD
> session is deleted. Once OSPF/ISIS re-detect the neighbor a _new_ BFD
> session is started. Which uses a new Discriminator.
> >
> >
> > As Jeff said, "in the grand scheme of things" this makes sense, even
> when it looks odd from the BFD level.
> >
> >
> > Regards, Marc
> >
> >
> >
> > On 2012-11-04, at 17:00 , Jeffrey Haas wrote:
> >
> > > Havard,
> > >
> > > On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes wrote:
> > >> I'm maintaining a small software package we use to monitor
> > >> certain aspects of our network, and among them I'm monitoring BFD
> > >> session states, using a couple of vendors' interim versions of
> > >> the BFD MIB (implanted in their own enterprises tree for the time
> > >> being).
> > >>
> > >> With one of the vendors I'm observing strange behaviour, in that
> > >> almost every time a BFD session goes through an operational
> > >> down->up state transition (after first going through an up->down
> > >> state transition), the implementation chooses a new BFD
> > >> discriminator for the session.
> > >
> > > This behavior is likely desirable in the grand scheme of things.  In
> > > particular, it helps prevent replay attacks against the protocol.
> > >
> > >> Furthermore, it looks as if the vendor is using the value of the
> > >> local discriminator when forming the bfdSessIndex value in the
> > >> MIB.
> > >
> > > This is probably the problematic thing for you.  The MIB session inde=
x
> > > ideally should be a management facing entity and thus have a level of
> > > stability imposed by configuration.  Nothing prohibits it from
> changing in
> > > the way you're noticing, but it's something I'd press my vendor to fi=
x.
> > >
> > >> So my questions here are twofold:
> > >>
> > >> 1) Is there a problem with the specifications as written that
> > >>   allows an implementor to (in my opinion) totally de-value the
> > >>   usefulness of the bfdSessTable?
> > >
> > > I'd argue the table is fine.  Your vendor should not bind the session
> index
> > > to the local discriminator.
> > >
> > >> 2) Is the implementor in question defending unreasonable
> > >>   behaviour which instead belongs in the "implementation bug"
> > >>   category?
> > >
> > > Unfortunately, it's in the "compliant, but annoying" category.
> > >
> > > -- Jeff
> > > (Who realizes the vendor in question may be his employer.  If so,
> please
> > > feel free to involve me in applying the hammer of clue to the problem
> report.)
> > >
> >
> > --
> > Marc Binderberger           
> >
> >
>
> --
> Marc Binderberger           
>
>

--047d7b5d8b5dd0de9104cdc3453c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello Mark,

What i meant is this - If R1 changes its Loc=
al discriminator and sends new packets, R1 should be still able to receive =
packets from R2 which sends packets using old "Your discriminator"=
; of R1, which R2 learnt earlier before the discriminator change. The recei=
ve processing of R1 should be in a position to remember its old discriminat=
or somewhere to demultiplex the packet to its correct session.=A0



Thats where I'd prefer to do a Poll Sequence to do =
any such parameter changes in packet, be it be a Authentication change or a=
 Discriminator change. Because that would ensure the session state undistur=
bed.



Regards,
Binny.

On 5 November 2012 19:07, Marc Binderberger <marc@sniff=
.de> wrote:


Hello Binny,




> But if i'd there to be implementing BFD, i'd inititate a poll =
sequence to finish the job clean and make the remote understand the paramet=
er change better.




point is there is nothing to understand for the remote system "R=
2" when "R1" is changing it's local discriminator. For R=
2 this is just a number to be used for the your_discr field.



Any attempt to help "R2" to "understand" is just weaken=
ing a clean & simple statement: that R2 has no business in understandin=
g the discriminator of R1.



And the comment about the "implication" simply points out the fac=
t that you are not automatically covered yourself by the RFC when you chang=
e your discriminator. In other words: you must know what you do :-)






Regards, Marc



P.S.: of course you can send P/F, should not cause any harm either.












On 2012-11-05, at 12:51 , Binny Jeshan wrote:



> Hello,

>

> I think changing discriminator is fine, if i go as per section 6.3 of =
RFC 5880.. What do you think of the below lines Havard / Jeff?

>

> " Note that it is permissible for a system to change its discrimi=
nator

> =A0 =A0during a session without affecting the session state, since onl=
y that

> =A0 =A0system uses its discriminator for demultiplexing purposes (by h=
aving

> =A0 =A0the other system reflect it back). =A0The implications on an
> =A0 =A0implementation for changing the discriminator value is outside =
the

> =A0 =A0scope of this specification."

>

>

> Ofcourse if there are any implications then i'd think that has to =
be dealt with. Example is that if the receive processing is affected so as =
to cause =A0a session going down. or may be it could be some attacker sendi=
ng BFD packets. This need to be fixed at the receiver end. But if i'd t=
here to be implementing BFD, i'd inititate a poll sequence to finish th=
e job clean and make the remote understand the parameter change better.


>

> " =A0 =A0 =A0If the Your Discriminator field is nonzero, it MUST =
be used to

> =A0 =A0 =A0 select the session with which this BFD packet is associate=
d. =A0If

> =A0 =A0 =A0 no session is found, the packet MUST be discarded=93

>

>

>

> What do you think?

>

> Regards,

> Binny Jeshan

>

>

> On 5 November 2012 17:02, Marc Binderberger <marc@sniff.de> wrote:

> Hello Havard, Jeff et al.

>

> >> With one of the vendors I'm observing strange behaviour, =
in that

> >> almost every time a BFD session goes through an operational
> >> down->up state transition (after first going through an up=
->down

> >> state transition), the implementation chooses a new BFD

> >> discriminator for the session.

> >

> > This behavior is likely desirable in the grand scheme of things. =
=A0In

> > particular, it helps prevent replay attacks against the protocol.=


>

>

>

> Let me guess: BFD is requested by OSPF or ISIS?

>

> At least one vendor I know requests the BFD session after OSPF/ISIS ha=
s discovered a neighbor with the Hello mechanism. The consequence of BFD go=
ing down, which is treated like a Hello failure, is that the discovered nei=
ghbor information is - strictly speaking - not valid anymore. The BFD sessi=
on is deleted. Once OSPF/ISIS re-detect the neighbor a _new_ BFD session is=
 started. Which uses a new Discriminator.


>

>

> As Jeff said, "in the grand scheme of things" this makes sen=
se, even when it looks odd from the BFD level.

>

>

> Regards, Marc

>

>

>

> On 2012-11-04, at 17:00 , Jeffrey Haas wrote:

>

> > Havard,

> >

> > On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes wrote:
> >> I'm maintaining a small software package we use to monito=
r

> >> certain aspects of our network, and among them I'm monito=
ring BFD

> >> session states, using a couple of vendors' interim versio=
ns of

> >> the BFD MIB (implanted in their own enterprises tree for the =
time

> >> being).

> >>

> >> With one of the vendors I'm observing strange behaviour, =
in that

> >> almost every time a BFD session goes through an operational
> >> down->up state transition (after first going through an up=
->down

> >> state transition), the implementation chooses a new BFD

> >> discriminator for the session.

> >

> > This behavior is likely desirable in the grand scheme of things. =
=A0In

> > particular, it helps prevent replay attacks against the protocol.=


> >

> >> Furthermore, it looks as if the vendor is using the value of =
the

> >> local discriminator when forming the bfdSessIndex value in th=
e

> >> MIB.

> >

> > This is probably the problematic thing for you. =A0The MIB sessio=
n index

> > ideally should be a management facing entity and thus have a leve=
l of

> > stability imposed by configuration. =A0Nothing prohibits it from =
changing in

> > the way you're noticing, but it's something I'd press=
 my vendor to fix.

> >

> >> So my questions here are twofold:

> >>

> >> 1) Is there a problem with the specifications as written that=


> >> =A0 allows an implementor to (in my opinion) totally de-value=
 the

> >> =A0 usefulness of the bfdSessTable?

> >

> > I'd argue the table is fine. =A0Your vendor should not bind t=
he session index

> > to the local discriminator.

> >

> >> 2) Is the implementor in question defending unreasonable

> >> =A0 behaviour which instead belongs in the "implementati=
on bug"

> >> =A0 category?

> >

> > Unfortunately, it's in the "compliant, but annoying"=
; category.

> >

> > -- Jeff

> > (Who realizes the vendor in question may be his employer. =A0If s=
o, please

> > feel free to involve me in applying the hammer of clue to the pro=
blem report.)

> >

>

> --

> Marc Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>

>

>




--

Marc Binderberger =A0 =A0 =A0 =A0 =A0 <=
marc@sniff.de>







--047d7b5d8b5dd0de9104cdc3453c--

From dkatz@juniper.net  Mon Nov  5 10:25:26 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DB421F8970 for ; Mon,  5 Nov 2012 10:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsUFpqk1nRx8 for ; Mon,  5 Nov 2012 10:25:25 -0800 (PST)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7121F898F for ; Mon,  5 Nov 2012 10:25:13 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUJgEiaOoCdXY3MjVN4MwBWMtmuPBxek3@postini.com; Mon, 05 Nov 2012 10:25:14 PST
Received: from nimbus-sf.juniper.net (172.16.12.139) by smtp.juniper.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 5 Nov 2012 10:24:50 -0800
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Monitoring BFD sessions
From: Dave Katz 
In-Reply-To: <20121105.151209.213953459.he@uninett.no>
Date: Mon, 5 Nov 2012 11:24:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <9E7AB7F5-D627-481C-A98E-5A015535EA6B@juniper.net>
References: <20121030.103101.409931545.he@uninett.no> <20121104160043.GA30108@pfrc> <20121105.151209.213953459.he@uninett.no>
To: Havard Eidnes 
X-Mailer: Apple Mail (2.1499)
Cc: "rtg-bfd@ietf.org WG" 
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 18:25:26 -0000

Conceptually, the IGP is creating and destroying BFD sessions as the =
adjacencies come and go.  There is no inherent relationship between the =
"old" and the "new" session after a flap.  Having said that, =
implementations are free to carry the state (in particular the =
discriminator value) across flaps.  The implementation I wrote did this, =
though I can't comment on the current state of our code.  Fundamentally, =
a BFD session is an ephemeral thing.

Using the discriminator value as the session ID seems inappropriate to =
me since it is, in theory at least, unstable even during a running =
session.  This doesn't really address your problem, of course, since the =
discriminator is likely stable during the session, but the two sessions =
aren't correlated.

If you want to associate the old session with the new session in the =
context of your management application, I think the only reasonable way =
is to extract the address/interface information, as that is the only =
thing guaranteed to be the same under a new session.  This is going to =
be more robust in other situations as well (protocol restarts, reboots, =
etc.)

--Dave


On Nov 5, 2012, at 7:12 AM, Havard Eidnes  wrote:

>>> With one of the vendors I'm observing strange behaviour, in that
>>> almost every time a BFD session goes through an operational
>>> down->up state transition (after first going through an up->down
>>> state transition), the implementation chooses a new BFD
>>> discriminator for the session.
>>=20
>> This behavior is likely desirable in the grand scheme of things.  In
>> particular, it helps prevent replay attacks against the protocol.
>=20
> OK, I understand there may be good reasons to do this.
>=20
>>> Furthermore, it looks as if the vendor is using the value of the
>>> local discriminator when forming the bfdSessIndex value in the
>>> MIB.
>>=20
>> This is probably the problematic thing for you.  The MIB session =
index
>> ideally should be a management facing entity and thus have a level of
>> stability imposed by configuration.  Nothing prohibits it from =
changing in
>> the way you're noticing, but it's something I'd press my vendor to =
fix.=20
>=20
> I agree -- this would probably be the best thing.  The current
> text for the bfdSessIndex is:
>=20
>   bfdSessIndex OBJECT-TYPE
>       SYNTAX     BfdSessIndexTC
>       MAX-ACCESS not-accessible
>       STATUS     current
>       DESCRIPTION
>           "This object contains an index used to represent a
>            unique BFD session on this device."
>       ::=3D { bfdSessEntry 1 }
>=20
> Now...  As Marc Binderber guesses, the BFD sessions are in my
> case configured as part of the IS-IS configuration.  And as he
> says, the device acts as if the BFD session is deleted (I beleive
> this is also evident via the CLI, it will then not be there at
> all) when the BFD adjacency is lost and subsequently also the
> IS-IS adjacency is lost.
>=20
> So then the question comes up: what is the administrative
> lifetime of a BFD session which is configured in this way, and is
> the administrator in control of it?  Or can one say that since
> something appears to delete the session (the IS-IS process?),
> strictly speaking, a new session is created when the neighborship
> is re-established, so since this is a different session than the
> one who existed earlier, it makes sense to not use the same
> bfdSessIndex value to refer to this different session?
>=20
> That would be ... most annoying, and leaves me exactly where I
> started, with no straight-forward way to automatically dig out
> the longer-term state changes for the BFD neighborship between
> these two neighboring routers using the BFD MIB.  The only way
> would be to construct my own "bfd session index", possibly
> consisting of "interface, ip-address-type, dest-ip-addr" (or
> possibly more, to support multiple BFD sessions between two
> neighboring routers).  However, to me this smells of bad MIB
> design -- if those are the values an administrator have to build
> an index on, why are they not already index values in the BFD
> session table?
>=20
> Is all this the way it should be?
>=20
> Is there some text which needs to go in somewhere to discourage
> this behaviour?
>=20
> Regards,
>=20
> - H=E5vard
>=20
>=20


From dkatz@juniper.net  Mon Nov  5 10:45:44 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C669621F8908 for ; Mon,  5 Nov 2012 10:45:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpeH6fkVYoLl for ; Mon,  5 Nov 2012 10:45:42 -0800 (PST)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 302E921F8900 for ; Mon,  5 Nov 2012 10:45:38 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUJgJUfd6wYV+l84tBvj6ymx2lgI6MA23@postini.com; Mon, 05 Nov 2012 10:45:41 PST
Received: from nimbus-sf.juniper.net (172.16.12.139) by smtp.juniper.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 5 Nov 2012 10:45:18 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF6F1075-69C6-4A28-B378-C822B4C87776"
MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Monitoring BFD sessions
From: Dave Katz 
In-Reply-To: 
Date: Mon, 5 Nov 2012 11:45:16 -0700
Message-ID: <9BB8297A-27E2-49D3-8E4B-CFB1FEC36117@juniper.net>
References: <20121030.103101.409931545.he@uninett.no> <20121104160043.GA30108@pfrc> <921D4A38-D923-4BEC-81BE-11D2BA87DD95@sniff.de>   
To: Binny Jeshan 
X-Mailer: Apple Mail (2.1499)
Cc: rtg-bfd@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 18:45:44 -0000

--Apple-Mail=_CF6F1075-69C6-4A28-B378-C822B4C87776
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"

As has been noted, you're free to do a poll sequence exchange at any =
time.  It's required on a discriminator change for Demand mode:

   If Demand mode is active on either or both systems, a Poll Sequence
   MUST be initiated whenever the contents of the next BFD Control
   packet to be sent would be different than the contents of the
   previous packet, with the exception of the Poll (P) and Final (F)
   bits.  This ensures that parameter changes are transmitted to the
   remote system and that the remote system acknowledges these changes.

Note, however, that the impetus of having a changeable discriminator =
value was to allow for a certain level of amnesia in the BFD process;  =
the discriminator is most likely changing because the BFD process has =
moved within the system and the discriminator was forgotten, so in that =
case it couldn't receive packets with the old value since it wouldn't =
recognize it.  (At least I think this was the reason the language was =
put into the spec in the first place.)

In Async mode, the session stability will only be at risk if the far end =
continues to send packets with the old discriminator for the entire =
detection interval.  This in turn can happen only if all outgoing =
packets from the near end with the new discriminator are lost on the way =
(in which case the session *should* fail).  For that matter, a poll =
sequence won't help here either, since packets are just getting dropped =
either way.

A poll sequence won't typically speed things up, since everybody should =
send an event-driven packet upon the change of discriminator anyhow:

   A BFD Control packet SHOULD be transmitted during the interval
   between periodic Control packet transmissions when the contents of
   that packet would differ from that in the previously transmitted
   packet (other than the Poll and Final bits) in order to more rapidly
   communicate a change in state.

Also, for what it's worth, the reason that a poll sequence is required =
on parameter changes is to ensure that the session doesn't fail because =
of a change in the detection time. The handshake is required to ensure =
that both ends are on the same page before packet transmission slows or =
timers are sped up.  This isn't necessary for a discriminator change in =
async mode.

So I guess I don't see the value in sending a poll sequence at this =
point (except perhaps in Demand mode) but it doesn't hurt anything.

--Dave


On Nov 5, 2012, at 11:01 AM, Binny Jeshan  wrote:

> Hello Mark,
>=20
> What i meant is this - If R1 changes its Local discriminator and sends =
new packets, R1 should be still able to receive packets from R2 which =
sends packets using old "Your discriminator" of R1, which R2 learnt =
earlier before the discriminator change. The receive processing of R1 =
should be in a position to remember its old discriminator somewhere to =
demultiplex the packet to its correct session.=20
>=20
> Thats where I'd prefer to do a Poll Sequence to do any such parameter =
changes in packet, be it be a Authentication change or a Discriminator =
change. Because that would ensure the session state undisturbed.
>=20
> Regards,
> Binny.
>=20
> On 5 November 2012 19:07, Marc Binderberger  wrote:
> Hello Binny,
>=20
> > But if i'd there to be implementing BFD, i'd inititate a poll =
sequence to finish the job clean and make the remote understand the =
parameter change better.
>=20
> point is there is nothing to understand for the remote system "R2" =
when "R1" is changing it's local discriminator. For R2 this is just a =
number to be used for the your_discr field.
>=20
> Any attempt to help "R2" to "understand" is just weakening a clean & =
simple statement: that R2 has no business in understanding the =
discriminator of R1.
>=20
> And the comment about the "implication" simply points out the fact =
that you are not automatically covered yourself by the RFC when you =
change your discriminator. In other words: you must know what you do :-)
>=20
>=20
> Regards, Marc
>=20
> P.S.: of course you can send P/F, should not cause any harm either.
>=20
>=20
>=20
>=20
>=20
> On 2012-11-05, at 12:51 , Binny Jeshan wrote:
>=20
> > Hello,
> >
> > I think changing discriminator is fine, if i go as per section 6.3 =
of RFC 5880.. What do you think of the below lines Havard / Jeff?
> >
> > " Note that it is permissible for a system to change its =
discriminator
> >    during a session without affecting the session state, since only =
that
> >    system uses its discriminator for demultiplexing purposes (by =
having
> >    the other system reflect it back).  The implications on an
> >    implementation for changing the discriminator value is outside =
the
> >    scope of this specification."
> >
> >
> > Ofcourse if there are any implications then i'd think that has to be =
dealt with. Example is that if the receive processing is affected so as =
to cause  a session going down. or may be it could be some attacker =
sending BFD packets. This need to be fixed at the receiver end. But if =
i'd there to be implementing BFD, i'd inititate a poll sequence to =
finish the job clean and make the remote understand the parameter change =
better.
> >
> > "      If the Your Discriminator field is nonzero, it MUST be used =
to
> >       select the session with which this BFD packet is associated.  =
If
> >       no session is found, the packet MUST be discarded=93
> >
> >
> >
> > What do you think?
> >
> > Regards,
> > Binny Jeshan
> >
> >
> > On 5 November 2012 17:02, Marc Binderberger  wrote:
> > Hello Havard, Jeff et al.
> >
> > >> With one of the vendors I'm observing strange behaviour, in that
> > >> almost every time a BFD session goes through an operational
> > >> down->up state transition (after first going through an up->down
> > >> state transition), the implementation chooses a new BFD
> > >> discriminator for the session.
> > >
> > > This behavior is likely desirable in the grand scheme of things.  =
In
> > > particular, it helps prevent replay attacks against the protocol.
> >
> >
> >
> > Let me guess: BFD is requested by OSPF or ISIS?
> >
> > At least one vendor I know requests the BFD session after OSPF/ISIS =
has discovered a neighbor with the Hello mechanism. The consequence of =
BFD going down, which is treated like a Hello failure, is that the =
discovered neighbor information is - strictly speaking - not valid =
anymore. The BFD session is deleted. Once OSPF/ISIS re-detect the =
neighbor a _new_ BFD session is started. Which uses a new Discriminator.
> >
> >
> > As Jeff said, "in the grand scheme of things" this makes sense, even =
when it looks odd from the BFD level.
> >
> >
> > Regards, Marc
> >
> >
> >
> > On 2012-11-04, at 17:00 , Jeffrey Haas wrote:
> >
> > > Havard,
> > >
> > > On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes wrote:
> > >> I'm maintaining a small software package we use to monitor
> > >> certain aspects of our network, and among them I'm monitoring BFD
> > >> session states, using a couple of vendors' interim versions of
> > >> the BFD MIB (implanted in their own enterprises tree for the time
> > >> being).
> > >>
> > >> With one of the vendors I'm observing strange behaviour, in that
> > >> almost every time a BFD session goes through an operational
> > >> down->up state transition (after first going through an up->down
> > >> state transition), the implementation chooses a new BFD
> > >> discriminator for the session.
> > >
> > > This behavior is likely desirable in the grand scheme of things.  =
In
> > > particular, it helps prevent replay attacks against the protocol.
> > >
> > >> Furthermore, it looks as if the vendor is using the value of the
> > >> local discriminator when forming the bfdSessIndex value in the
> > >> MIB.
> > >
> > > This is probably the problematic thing for you.  The MIB session =
index
> > > ideally should be a management facing entity and thus have a level =
of
> > > stability imposed by configuration.  Nothing prohibits it from =
changing in
> > > the way you're noticing, but it's something I'd press my vendor to =
fix.
> > >
> > >> So my questions here are twofold:
> > >>
> > >> 1) Is there a problem with the specifications as written that
> > >>   allows an implementor to (in my opinion) totally de-value the
> > >>   usefulness of the bfdSessTable?
> > >
> > > I'd argue the table is fine.  Your vendor should not bind the =
session index
> > > to the local discriminator.
> > >
> > >> 2) Is the implementor in question defending unreasonable
> > >>   behaviour which instead belongs in the "implementation bug"
> > >>   category?
> > >
> > > Unfortunately, it's in the "compliant, but annoying" category.
> > >
> > > -- Jeff
> > > (Who realizes the vendor in question may be his employer.  If so, =
please
> > > feel free to involve me in applying the hammer of clue to the =
problem report.)
> > >
> >
> > --
> > Marc Binderberger           
> >
> >
>=20
> --
> Marc Binderberger           
>=20
>=20


--Apple-Mail=_CF6F1075-69C6-4A28-B378-C822B4C87776
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="windows-1252"

As =
has been noted, you're free to do a poll sequence exchange at any time. =
 It's required on a discriminator change for Demand =
mode:

   If =
Demand mode is active on either or both systems, a Poll Sequence
   MUST be initiated whenever the contents of the next BFD Control
   packet to be sent would be different than the contents of the
   previous packet, with the exception of the Poll (P) and Final (F)
   bits.  This ensures that parameter changes are transmitted to the
   remote system and that the remote system acknowledges these =
changes.

Note, however, that the impetus of =
having a changeable discriminator value was to allow for a certain level =
of amnesia in the BFD process;  the discriminator is most likely =
changing because the BFD process has moved within the system and the =
discriminator was forgotten, so in that case it couldn't receive packets =
with the old value since it wouldn't recognize it.  (At least I =
think this was the reason the language was put into the spec in the =
first place.)

In Async mode, the session =
stability will only be at risk if the far end continues to send packets =
with the old discriminator for the entire detection interval.  This =
in turn can happen only if all outgoing packets from the near end with =
the new discriminator are lost on the way (in which case the session =
*should* fail).  For that matter, a poll sequence won't help here =
either, since packets are just getting dropped either =
way.

A poll sequence won't typically speed =
things up, since everybody should send an event-driven packet upon the =
change of discriminator anyhow:

   A BFD Control packet =
SHOULD be transmitted during the interval
   between periodic Control packet transmissions when the contents of
   that packet would differ from that in the previously transmitted
   packet (other than the Poll and Final bits) in order to more rapidly
   communicate a change in state.


Also, for what it's worth, the reason =
that a poll sequence is required on parameter changes is to ensure that =
the session doesn't fail because of a change in the detection time. The =
handshake is required to ensure that both ends are on the same page =
before packet transmission slows or timers are sped up.  This isn't =
necessary for a discriminator change in async =
mode.

So I guess I don't see the value in =
sending a poll sequence at this point (except perhaps in Demand mode) =
but it doesn't hurt =
anything.

--Dave


On Nov 5, 2012, at 11:01 AM, Binny Jeshan <binnyjeshan@gmail.com> =
wrote:

Hello Mark,

What i meant is this - If =
R1 changes its Local discriminator and sends new packets, R1 should be =
still able to receive packets from R2 which sends packets using old =
"Your discriminator" of R1, which R2 learnt earlier before the =
discriminator change. The receive processing of R1 should be in a =
position to remember its old discriminator somewhere to demultiplex the =
packet to its correct session. 



Thats where I'd prefer to do a Poll Sequence to do =
any such parameter changes in packet, be it be a Authentication change =
or a Discriminator change. Because that would ensure the session state =
undisturbed.

=


Regards,
Binny.

On 5 November 2012 19:07, Marc Binderberger =
<marc@sniff.de> wrote:


Hello Binny,




> But if i'd there to be implementing BFD, i'd inititate a poll =
sequence to finish the job clean and make the remote understand the =
parameter change better.




point is there is nothing to understand for the remote system "R2" =
when "R1" is changing it's local discriminator. For R2 this is just a =
number to be used for the your_discr field.



Any attempt to help "R2" to "understand" is just weakening a clean & =
simple statement: that R2 has no business in understanding the =
discriminator of R1.



And the comment about the "implication" simply points out the fact that =
you are not automatically covered yourself by the RFC when you change =
your discriminator. In other words: you must know what you do :-)






Regards, Marc



P.S.: of course you can send P/F, should not cause any harm either.












On 2012-11-05, at 12:51 , Binny Jeshan wrote:



> Hello,

>

> I think changing discriminator is fine, if i go as per section 6.3 =
of RFC 5880.. What do you think of the below lines Havard / Jeff?

>

> " Note that it is permissible for a system to change its =
discriminator

>    during a session without affecting the session state, =
since only that

>    system uses its discriminator for demultiplexing =
purposes (by having

>    the other system reflect it back).  The =
implications on an

>    implementation for changing the discriminator value is =
outside the

>    scope of this specification."

>

>

> Ofcourse if there are any implications then i'd think that has to =
be dealt with. Example is that if the receive processing is affected so =
as to cause  a session going down. or may be it could be some =
attacker sending BFD packets. This need to be fixed at the receiver end. =
But if i'd there to be implementing BFD, i'd inititate a poll sequence =
to finish the job clean and make the remote understand the parameter =
change better.


>

> "      If the Your Discriminator field is nonzero, =
it MUST be used to

>       select the session with which this BFD packet =
is associated.  If

>       no session is found, the packet MUST be =
discarded=93

>

>

>

> What do you think?

>

> Regards,

> Binny Jeshan

>

>

> On 5 November 2012 17:02, Marc Binderberger <marc@sniff.de> wrote:

> Hello Havard, Jeff et al.

>

> >> With one of the vendors I'm observing strange behaviour, =
in that

> >> almost every time a BFD session goes through an =
operational

> >> down->up state transition (after first going through an =
up->down

> >> state transition), the implementation chooses a new =
BFD

> >> discriminator for the session.

> >

> > This behavior is likely desirable in the grand scheme of =
things.  In

> > particular, it helps prevent replay attacks against the =
protocol.

>

>

>

> Let me guess: BFD is requested by OSPF or ISIS?

>

> At least one vendor I know requests the BFD session after OSPF/ISIS =
has discovered a neighbor with the Hello mechanism. The consequence of =
BFD going down, which is treated like a Hello failure, is that the =
discovered neighbor information is - strictly speaking - not valid =
anymore. The BFD session is deleted. Once OSPF/ISIS re-detect the =
neighbor a _new_ BFD session is started. Which uses a new =
Discriminator.


>

>

> As Jeff said, "in the grand scheme of things" this makes sense, =
even when it looks odd from the BFD level.

>

>

> Regards, Marc

>

>

>

> On 2012-11-04, at 17:00 , Jeffrey Haas wrote:

>

> > Havard,

> >

> > On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes =
wrote:

> >> I'm maintaining a small software package we use to =
monitor

> >> certain aspects of our network, and among them I'm =
monitoring BFD

> >> session states, using a couple of vendors' interim =
versions of

> >> the BFD MIB (implanted in their own enterprises tree for =
the time

> >> being).

> >>

> >> With one of the vendors I'm observing strange behaviour, =
in that

> >> almost every time a BFD session goes through an =
operational

> >> down->up state transition (after first going through an =
up->down

> >> state transition), the implementation chooses a new =
BFD

> >> discriminator for the session.

> >

> > This behavior is likely desirable in the grand scheme of =
things.  In

> > particular, it helps prevent replay attacks against the =
protocol.

> >

> >> Furthermore, it looks as if the vendor is using the value =
of the

> >> local discriminator when forming the bfdSessIndex value in =
the

> >> MIB.

> >

> > This is probably the problematic thing for you.  The MIB =
session index

> > ideally should be a management facing entity and thus have a =
level of

> > stability imposed by configuration.  Nothing prohibits it =
from changing in

> > the way you're noticing, but it's something I'd press my =
vendor to fix.

> >

> >> So my questions here are twofold:

> >>

> >> 1) Is there a problem with the specifications as written =
that

> >>   allows an implementor to (in my opinion) totally =
de-value the

> >>   usefulness of the bfdSessTable?

> >

> > I'd argue the table is fine.  Your vendor should not bind =
the session index

> > to the local discriminator.

> >

> >> 2) Is the implementor in question defending =
unreasonable

> >>   behaviour which instead belongs in the =
"implementation bug"

> >>   category?

> >

> > Unfortunately, it's in the "compliant, but annoying" =
category.

> >

> > -- Jeff

> > (Who realizes the vendor in question may be his employer. =
 If so, please

> > feel free to involve me in applying the hammer of clue to the =
problem report.)

> >

>

> --

> Marc Binderberger           <marc@sniff.de>

>

>




--

Marc Binderberger           <marc@sniff.de>








=

--Apple-Mail=_CF6F1075-69C6-4A28-B378-C822B4C87776--

From jhaas@slice.pfrc.org  Mon Nov  5 11:40:19 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF23E21F8441 for ; Mon,  5 Nov 2012 11:40:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.058
X-Spam-Level: 
X-Spam-Status: No, score=-101.058 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t98wcwrNwNLX for ; Mon,  5 Nov 2012 11:40:18 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 31F8621F8665 for ; Mon,  5 Nov 2012 11:40:18 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id A9D01C3F2; Mon,  5 Nov 2012 14:40:13 -0500 (EST)
Date: Mon, 5 Nov 2012 14:40:13 -0500
From: Jeffrey Haas 
To: Havard Eidnes 
Subject: Re: Monitoring BFD sessions
Message-ID: <20121105194013.GA19437@pfrc>
References: <20121030.103101.409931545.he@uninett.no> <20121104160043.GA30108@pfrc> <20121105.151209.213953459.he@uninett.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20121105.151209.213953459.he@uninett.no>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rtg-bfd@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 19:40:19 -0000

On Mon, Nov 05, 2012 at 03:12:09PM +0100, Havard Eidnes wrote:
> So then the question comes up: what is the administrative
> lifetime of a BFD session which is configured in this way, and is
> the administrator in control of it?  Or can one say that since
> something appears to delete the session (the IS-IS process?),
> strictly speaking, a new session is created when the neighborship
> is re-established, so since this is a different session than the
> one who existed earlier, it makes sense to not use the same
> bfdSessIndex value to refer to this different session?
> 
> That would be ... most annoying, and leaves me exactly where I
> started, with no straight-forward way to automatically dig out
> the longer-term state changes for the BFD neighborship between
> these two neighboring routers using the BFD MIB.  The only way
> would be to construct my own "bfd session index", possibly
> consisting of "interface, ip-address-type, dest-ip-addr" (or
> possibly more, to support multiple BFD sessions between two
> neighboring routers).  However, to me this smells of bad MIB
> design -- if those are the values an administrator have to build
> an index on, why are they not already index values in the BFD
> session table?
> 
> Is all this the way it should be?

Regardless of "the way it should be", it's a common issue across a number of
MIBs. :-(

bfdSessIpMapTable is there to let you look up the session that is likely to
be what you care about.  However, noting that things have moved to a new
session index requires tracking the fact that the session has dropped and
then using the table to discover the new session index.  This could be done
on each polling cycle (with the usual atomicity issues when polling
disparate tables) or whenever a notification related to the session going
down/coming up happens.

Or the vendor could be requested to put in place measures that result in
stable session indices for dynamically allocated BFD sessions.

-- Jeff

From jhaas@juniper.net  Fri Nov  9 04:43:42 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906FA21F8524 for ; Fri,  9 Nov 2012 04:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.466
X-Spam-Level: 
X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGS1gunV86y4 for ; Fri,  9 Nov 2012 04:43:41 -0800 (PST)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 831C621F8525 for ; Fri,  9 Nov 2012 04:43:41 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUJz6fRC8DCPNYqu+7BoLNV9uP7q9M+oM@postini.com; Fri, 09 Nov 2012 04:43:41 PST
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Nov 2012 04:43:01 -0800
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 9 Nov 2012 04:43:00 -0800
Received: from db3outboundpool.messaging.microsoft.com (213.199.154.139) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 9 Nov 2012 04:45:29 -0800
Received: from mail10-db3-R.bigfish.com (10.3.81.227) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 9 Nov 2012 12:42:56 +0000
Received: from mail10-db3 (localhost [127.0.0.1])	by mail10-db3-R.bigfish.com (Postfix) with ESMTP id 3D982100313	for ; Fri,  9 Nov 2012 12:42:56 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -2
X-BigFish: PS-2(zf7Iz9371I936eIc85fh1432I62a3I9a6kzz1de0h1202h1d1ah1d2ahzz8275ch17326ah8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h14ddh1504h1537h1155h)
Received: from mail10-db3 (localhost.localdomain [127.0.0.1]) by mail10-db3 (MessageSwitch) id 1352464974324218_25813; Fri,  9 Nov 2012 12:42:54 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.229])	by mail10-db3.bigfish.com (Postfix) with ESMTP id 42F64160091	for ; Fri,  9 Nov 2012 12:42:54 +0000 (UTC)
Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 9 Nov 2012 12:42:51 +0000
Received: from ifarinic-sslvpn-nc.jnpr.net (66.129.232.2) by pod51010.outlook.com (10.255.116.40) with Microsoft SMTP Server (TLS) id 14.16.233.3; Fri, 9 Nov 2012 12:42:49 +0000
From: Jeffrey Haas 
MIME-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7DD4099B-F145-45DA-870F-F02210719CA6"
Date: Fri, 9 Nov 2012 07:42:47 -0500
Subject: Fwd: [IANA #608048] Application for a Port Number "bfd-lag" 
References: 
To: 
Message-ID: 
X-Mailer: Apple Mail (2.1283)
X-Originating-IP: [66.129.232.2]
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-Mailman-Approved-At: Fri, 09 Nov 2012 05:10:46 -0800
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2012 12:43:42 -0000

--Apple-Mail=_7DD4099B-F145-45DA-870F-F02210719CA6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"



Begin forwarded message:

> From: Pearl Liang via RT 
> Subject: [IANA #608048] Application for a Port Number "bfd-lag"=20
> Date: November 8, 2012 6:04:02 PM EST
> Cc: , , , =

> Reply-To: 
>=20
> Dear Jeff, et al.
>=20
> Your request has been processed.  We have assigned the following=20
> UDP port to bfd-lag:
>=20
> bfd-lag            6784        udp    Bidirectional Forwarding =
Detection (BFD)
> on Link Aggregation Group (LAG) Interfaces
> [IESG]   =20
> [IETF_Chair] =20
> 2012-11-08
> [draft-mmm-bfd-on-lags-05]
>=20
> See:=20
> http://www.iana.org/assignments/service-names-port-numbers
>=20
> Please notify IANA if there is any change in contact information by=20
> completing the following template:
>=20
> http://www.iana.org/cgi-bin/mod_portno.pl
>=20
> This ticket [IANA #608048] is considered resolved.
>=20
> Regards,
>=20
> Pearl Liang
> IANA=20
>=20
> ***************************************************************
> Internet Assigned Numbers Authority (IANA)
> 4676 Admiralty Way, Suite 330
> Marina del Rey, California 90292
>=20
> Voice: (310) 823-9358
> FAX:   (310) 823-8649
> email: iana-ports@iana.org
> ***************************************************************
>=20
>=20


--Apple-Mail=_7DD4099B-F145-45DA-870F-F02210719CA6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"


From: Pearl Liang via RT =
<iana-ports@iana.org>
=

Subject: =
[IANA #608048] Application for a Port Number =
"bfd-lag" 
Date: November 8, 2012 6:04:02 PM EST
Cc: <adrian@olddog.co.uk>, <touch@isi.edu>, <lear@cisco.com>, <jhaas@juniper.net>
Reply-To: =
<iana-ports@iana.org>
=


Dear Jeff, et al.

Your request has been processed. =
 We have assigned the following 
UDP port to =
bfd-lag:

bfd-lag =
           6784 =
       udp =
   Bidirectional Forwarding Detection (BFD)
on Link =
Aggregation Group (LAG) Interfaces
[IESG] =
   
[IETF_Chair] =
 
2012-11-08
[draft-mmm-bfd-on-lags-05]

See: 
http:/=
/www.iana.org/assignments/service-names-port-numbers

Please =
notify IANA if there is any change in contact information by =

completing the following =
template:

http://www.iana.org/cgi-bin/mod_portno.pl

This =
ticket [IANA #608048] is considered =
resolved.

Regards,

Pearl Liang
IANA =


***************************************************************Internet Assigned Numbers Authority (IANA)
4676 Admiralty Way, Suite =
330
Marina del Rey, California 90292

Voice: (310) =
823-9358
FAX:   (310) 823-8649
email: =
iana-ports@iana.org
***************************************************=
************



=

--Apple-Mail=_7DD4099B-F145-45DA-870F-F02210719CA6--

From marc@sniff.de  Tue Nov 27 14:48:00 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA69B21F8457 for ; Tue, 27 Nov 2012 14:48: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXidpWhWXPkI for ; Tue, 27 Nov 2012 14:48:00 -0800 (PST)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 312B121F8452 for ; Tue, 27 Nov 2012 14:48:00 -0800 (PST)
Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id C89882AA0F; Tue, 27 Nov 2012 22:47:57 +0000 (GMT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Fwd: I-D Action: draft-mbind-bfd-redundancy-00.txt
From: Marc Binderberger 
Date: Tue, 27 Nov 2012 23:47:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <07F60A12-559D-4C8E-91D0-8F460FF8E052@sniff.de>
References: <20121127223218.5615.43543.idtracker@ietfa.amsl.com>
To: rtg-bfd@ietf.org
X-Mailer: Apple Mail (2.1084)
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Nov 2012 22:48:01 -0000

Hello BFD experts,

Nobo and me are interested in your feedback for a new proposal we make =
to enhance the redundancy characteristics of BFD.

With requirements (*) to run BFD practically without interruption at =
short timer intervals we think it's worthwhile to think about and =
discuss it.

(*: I'm sure you either have similar requests from your customers or you =
are one of these customers asking for it ;-)


Best regards,
Marc



Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: November 27, 2012 23:32:18 GMT+01:00
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-mbind-bfd-redundancy-00.txt
> Reply-To: internet-drafts@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
> 	Title           : Redundant BFD sessions
> 	Author(s)       : Marc Binderberger
>                          Nobo Akiya
> 	Filename        : draft-mbind-bfd-redundancy-00.txt
> 	Pages           : 7
> 	Date            : 2012-11-27
>=20
> Abstract:
>   This document defines a second or "shadow" BFD session to an =
existing
>   "primary" BFD session, providing resilience against BFD failures =
that
>   are not legitimate.
>=20
>   Scenarios will be discussed on how presence of a shadow BFD session
>   will be beneficial in the context of high availability.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mbind-bfd-redundancy
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-mbind-bfd-redundancy-00
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20


From gregory.mirsky@ericsson.com  Tue Nov 27 18:35:13 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A007621F87B3 for ; Tue, 27 Nov 2012 18:35:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri3ptadzi46c for ; Tue, 27 Nov 2012 18:35:12 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id AB5B521F8760 for ; Tue, 27 Nov 2012 18:35:12 -0800 (PST)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qAS2ZB6S030847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 20:35:11 -0600
Received: from EUSAAHC004.ericsson.se (147.117.188.84) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 27 Nov 2012 21:35:10 -0500
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 21:35:10 -0500
From: Gregory Mirsky 
To: Marc Binderberger , "rtg-bfd@ietf.org" 
Subject: RE: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Topic: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Index: AQHNzPFN3g4DSybx2kOVKNJpsT4xqpf+hVOg
Date: Wed, 28 Nov 2012 02:35:09 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF11201C95D@eusaamb103.ericsson.se>
References: <20121127223218.5615.43543.idtracker@ietfa.amsl.com> <07F60A12-559D-4C8E-91D0-8F460FF8E052@sniff.de>
In-Reply-To: <07F60A12-559D-4C8E-91D0-8F460FF8E052@sniff.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2012 02:35:13 -0000

Hi Marc,
in section 2 you list four possible causes for positive negatives due to BF=
D monitoring interruption, not path failure. But I believe that detecting c=
ases 2 and 4 is actually what is expected of BFD as FPGA and LC failures di=
rectly affect data path. Which of remaining scenarios 1 and 3, in your opin=
ion, will be excluded by shadow BFD session to justify new version of BFD?

	Regards,
		Greg

-----Original Message-----
From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf =
Of Marc Binderberger
Sent: Tuesday, November 27, 2012 2:48 PM
To: rtg-bfd@ietf.org
Subject: Fwd: I-D Action: draft-mbind-bfd-redundancy-00.txt

Hello BFD experts,

Nobo and me are interested in your feedback for a new proposal we make to e=
nhance the redundancy characteristics of BFD.

With requirements (*) to run BFD practically without interruption at short =
timer intervals we think it's worthwhile to think about and discuss it.

(*: I'm sure you either have similar requests from your customers or you ar=
e one of these customers asking for it ;-)


Best regards,
Marc



Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: November 27, 2012 23:32:18 GMT+01:00
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-mbind-bfd-redundancy-00.txt
> Reply-To: internet-drafts@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
>=20
> 	Title           : Redundant BFD sessions
> 	Author(s)       : Marc Binderberger
>                          Nobo Akiya
> 	Filename        : draft-mbind-bfd-redundancy-00.txt
> 	Pages           : 7
> 	Date            : 2012-11-27
>=20
> Abstract:
>   This document defines a second or "shadow" BFD session to an existing
>   "primary" BFD session, providing resilience against BFD failures that
>   are not legitimate.
>=20
>   Scenarios will be discussed on how presence of a shadow BFD session
>   will be beneficial in the context of high availability.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mbind-bfd-redundancy
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-mbind-bfd-redundancy-00
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20


From davari@broadcom.com  Tue Nov 27 21:43:14 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43A121E8043 for ; Tue, 27 Nov 2012 21:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.442
X-Spam-Level: 
X-Spam-Status: No, score=-5.442 tagged_above=-999 required=5 tests=[AWL=1.157,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIj7w1uWIc-E for ; Tue, 27 Nov 2012 21:43:14 -0800 (PST)
Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0721E803F for ; Tue, 27 Nov 2012 21:43:14 -0800 (PST)
Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 27 Nov 2012 21:41:10 -0800
X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261
Received: from SJEXCHCAS02.corp.ad.broadcom.com (10.16.192.37) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 27 Nov 2012 21:43:02 -0800
Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by sjexchcas02.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 27 Nov 2012 21:42:42 -0800
From: "Shahram Davari" 
To: "Marc Binderberger" 
Subject: Re: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Topic: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Index: AQHNzPFJ5Dtg24aBNEuN3WUMDfQ56Zf+vHuY
Date: Wed, 28 Nov 2012 05:42:41 +0000
Message-ID: <18E90492-8795-4BFB-938F-8EA2ED949C16@broadcom.com>
References: <20121127223218.5615.43543.idtracker@ietfa.amsl.com>, <07F60A12-559D-4C8E-91D0-8F460FF8E052@sniff.de>
In-Reply-To: <07F60A12-559D-4C8E-91D0-8F460FF8E052@sniff.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-WSS-ID: 7CAB7C7C1QK10859876-01-01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "rtg-bfd@ietf.org" 
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2012 05:43:15 -0000

Hi,

In failure scenarios that you have mentioned, there are ways for NMS to inf=
orm the remote nodes of the failure.=20

Also as you mentioned, the worst case is that protection is triggered and n=
othing bad happens. So I am not convinced we need a backup BFD session.

Even if a backup BFD is needed, then why not us a different "my Discriminat=
or" and "your discriminator" to distinguish them?

Regards,
Shahram


On Nov 27, 2012, at 2:48 PM, "Marc Binderberger"  wrote:

> Hello BFD experts,
>=20
> Nobo and me are interested in your feedback for a new proposal we make to=
 enhance the redundancy characteristics of BFD.
>=20
> With requirements (*) to run BFD practically without interruption at shor=
t timer intervals we think it's worthwhile to think about and discuss it.
>=20
> (*: I'm sure you either have similar requests from your customers or you =
are one of these customers asking for it ;-)
>=20
>=20
> Best regards,
> Marc
>=20
>=20
>=20
> Begin forwarded message:
>=20
>> From: internet-drafts@ietf.org
>> Date: November 27, 2012 23:32:18 GMT+01:00
>> To: i-d-announce@ietf.org
>> Subject: I-D Action: draft-mbind-bfd-redundancy-00.txt
>> Reply-To: internet-drafts@ietf.org
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>>=20
>>=20
>>    Title           : Redundant BFD sessions
>>    Author(s)       : Marc Binderberger
>>                         Nobo Akiya
>>    Filename        : draft-mbind-bfd-redundancy-00.txt
>>    Pages           : 7
>>    Date            : 2012-11-27
>>=20
>> Abstract:
>>  This document defines a second or "shadow" BFD session to an existing
>>  "primary" BFD session, providing resilience against BFD failures that
>>  are not legitimate.
>>=20
>>  Scenarios will be discussed on how presence of a shadow BFD session
>>  will be beneficial in the context of high availability.
>>=20
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-mbind-bfd-redundancy
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-mbind-bfd-redundancy-00
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20


From Alexander.Vainshtein@ecitele.com  Tue Nov 27 21:48:36 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CF921F858B for ; Tue, 27 Nov 2012 21:48:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4,  UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSbHV9j71JCp for ; Tue, 27 Nov 2012 21:48:36 -0800 (PST)
Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7108D21F85ED for ; Tue, 27 Nov 2012 21:48:34 -0800 (PST)
Received: from [85.158.143.99:7235] by server-3.bemta-4.messagelabs.com id 00/76-06841-1B5A5B05; Wed, 28 Nov 2012 05:48:33 +0000
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1354081712!31608965!1
X-Originating-IP: [147.234.242.234]
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30715 invoked from network); 28 Nov 2012 05:48:32 -0000
Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-15.tower-216.messagelabs.com with SMTP; 28 Nov 2012 05:48:32 -0000
X-AuditID: 93eaf2e7-b7fc26d000006f95-a8-50b59f1efc18
Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id C7.15.28565.E1F95B05; Wed, 28 Nov 2012 07:20:30 +0200 (IST)
Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 28 Nov 2012 07:48:31 +0200
Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.01.0379.000; Wed, 28 Nov 2012 07:48:31 +0200
From: Alexander Vainshtein 
To: Gregory Mirsky , Marc Binderberger 
Subject: RE: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Topic: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Index: AQHNzO8Y733xZZXVH0+8LT0ip9lpo5f+SKzpgAAd5oCAAE5gZw==
Date: Wed, 28 Nov 2012 05:48:30 +0000
Message-ID: 
References: <20121127223218.5615.43543.idtracker@ietfa.amsl.com> <07F60A12-559D-4C8E-91D0-8F460FF8E052@sniff.de>, <7347100B5761DC41A166AC17F22DF11201C95D@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF11201C95D@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.234.1.2]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0zTUBTObbdRkGoZItfFaK3iAx1honEK80FCnImJI0g08kPLdtkat65Z pzL/iC/UkShGYxB/DHU+ECJxuIkPxOATEiMxGCMqRlk0Do0RfATiq6WCJMb++s75vnO+05tz CFxbGacjON6LPDzrZDQJqsOxvph+ciBsyTzdudD4NuoHxuOdv3Bj//cIWIabB7881piDwQHM vKeuQmXB15eBHJbn3V7Wi2gbEq0mxuLhtrBWH0NzNhNjYGjByVqRC/FeE8MKAuJtzJIE+p8v R5JxPI14q9vG8XYTs7Jgtd5oXLBIb2CWzJhmyMpOWOPgRBrpXSznpF1IFFk7oqXMxku4ozHW gQnB9NLXbZ9AGXg51Q/iCUjNh4EHHzAFT4Ad3Q0aP0ggtFQLgB2vD2NK0ARgv79brQR3ACz/ fgrIJRrKBEN1LzQyHk8VwuvNH1QyxqnZcOf9/jgZJ1OL4ZuaN0DRZMOq5r0qBefCh5/CQ3kV lQYHBr+qZUxSFlh39ytQzEIAdl0ODRHx1Cr4o7diqBhIs35rr8cUs1TYFQ38+QcKBq8/xBWc At/1/FQreApsDPeoFf1cWHOtT6PgOfDMiV5cMU6CbceiQ/21lB623/djlQBWj7KoHlVePaq8 elR5DVCdBymcU/AWu+yZhgxk5bzIiTKsblcIKMvztgkMBqa3AooATCJZmRO2aNXsFtHnagUT CYxJIScHpdTYYrfN52BFxwbPZicSWwEkcGY8mVgucaSN9W1DHvcwlSc94SFcN8bqltaU927I ysz8f8CkkmfL1q7WUnZpITchJCDPcJ9JBMFA8qhsn+RBdlRawjm9f2mMiJfHSJTGqJU1pCiw LpGzK3w7yCIiff4oIPa1VkSBVsW7eaRLJYOylJKljs38SLfhQ4qBVOkZksmIrEqUzmykX0yy wiQr65OLspV0PiOUrgwUlBxxrahv9t9YkWtctS5i9uMnx2XtJh/dztd1f35frl104hFOt/TV ZexI7yyqqRIDN2dmXzZfaEmb5xNqm2Km5cFe4/P9L3eVP23bPuWLPq6haumBW3kFtT3nDtiv doXS3INC0b4rhYYnx0ue5ha92jU3cvDZvaXh2Xn5sz4yWzsnMCrRwRrScY/I/gZNbpDAIwQA AA==
Cc: "rtg-bfd@ietf.org" 
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2012 05:48:36 -0000

Hi all,
I've read the draft, and I concur with Greg's comment: at least some of the=
 scenarios described as possible causes for false detection of the session f=
ailure look like legitimate path failures to me.

I also assume (even if the draft does not spell this out) that the problem i=
s false detection of the BFD session failure by the peers of the router that=
 experiences one of the scenarios described in the draft.
IMHO and FWIW handling of "local" problems with the BFD session does not req=
uire any modifications to the BFD standards, it is an implementation issue.=
 As a consequence, I wonder why the shadow session would be really helpful i=
n differentiating between "true" and "false" path failures. 

E.g., consider crash of the BFD-handling process in a SW-based BFD scenario:=
 does the draft suggest that "main" and ""shadow" BFD sessions would be hand=
led by two different BFD processes? (This probably would not help n the case=
 of CPU starvation.) Or does the draft assume that the crashed process could=
 be restarted fast enough to maintain at least one of the two paired session=
s intact for the peers? If this is what the draft proposes, would not the sa=
me result be achieved by simply increasing the session failure detection tim=
e?

Failure of the routing processor card in the centralized BFD scheme looks li=
ke another valid use case of false path failures. But how would the "shadow=
 session" help in this scenario? Does the draft assume that the "shadow" ses=
sion would be handled by the backup routing processor (assuming there is one=
)? This is possible, but is it sufficiently different from implementing "hot=
 standby" for the BFD sessions in the  backup rouging processor?

Yet another side of the problem is a (pretty obvious IMHO) requirement for t=
he mechanism differentiating between "true" and "false" data path failures n=
ot to increase the time it takes to detect the "true"/"legitimate" failure.=
 The draft does nt explicitly describe how the "shadow" session is used in h=
e case of "true" failures, so it is not clear to me if the proposed mechanis=
m really meets this requirement.
If this requirement is not met, simply increasing the session failure detect=
ion time looks like a trivial answer for most (if not all) of the scenarios=
 mentioned in the draft.

My 2c.
     Sasha



 




________________________________________
From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] on behalf of Grego=
ry Mirsky [gregory.mirsky@ericsson.com]
Sent: Wednesday, November 28, 2012 3:35 AM
To: Marc Binderberger; rtg-bfd@ietf.org
Subject: RE: I-D Action: draft-mbind-bfd-redundancy-00.txt

Hi Marc,
in section 2 you list four possible causes for positive negatives due to BFD=
 monitoring interruption, not path failure. But I believe that detecting cas=
es 2 and 4 is actually what is expected of BFD as FPGA and LC failures direc=
tly affect data path. Which of remaining scenarios 1 and 3, in your opinion,=
 will be excluded by shadow BFD session to justify new version of BFD?

        Regards,
                Greg

-----Original Message-----
From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf O=
f Marc Binderberger
Sent: Tuesday, November 27, 2012 2:48 PM
To: rtg-bfd@ietf.org
Subject: Fwd: I-D Action: draft-mbind-bfd-redundancy-00.txt

Hello BFD experts,

Nobo and me are interested in your feedback for a new proposal we make to en=
hance the redundancy characteristics of BFD.

With requirements (*) to run BFD practically without interruption at short t=
imer intervals we think it's worthwhile to think about and discuss it.

(*: I'm sure you either have similar requests from your customers or you are=
 one of these customers asking for it ;-)


Best regards,
Marc



Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: November 27, 2012 23:32:18 GMT+01:00
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-mbind-bfd-redundancy-00.txt
> Reply-To: internet-drafts@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directo=
ries.
>
>
>       Title           : Redundant BFD sessions
>       Author(s)       : Marc Binderberger
>                          Nobo Akiya
>       Filename        : draft-mbind-bfd-redundancy-00.txt
>       Pages           : 7
>       Date            : 2012-11-27
>
> Abstract:
>   This document defines a second or "shadow" BFD session to an existing
>   "primary" BFD session, providing resilience against BFD failures that
>   are not legitimate.
>
>   Scenarios will be discussed on how presence of a shadow BFD session
>   will be beneficial in the context of high availability.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mbind-bfd-redundancy
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-mbind-bfd-redundancy-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

This e-mail message is intended for the recipient only and contains informat=
ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo=
u have received this transmission in error, please inform us by e-mail, phon=
e or fax, and then delete the original and all copies thereof.


From jeff.tantsura@ericsson.com  Tue Nov 27 22:00:55 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D52D21F876F for ; Tue, 27 Nov 2012 22:00:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUsV8bgyPtTS for ; Tue, 27 Nov 2012 22:00:54 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 64B0021F8763 for ; Tue, 27 Nov 2012 22:00:54 -0800 (PST)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAS697R2018304; Wed, 28 Nov 2012 00:09:09 -0600
Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 28 Nov 2012 01:00:48 -0500
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 01:00:48 -0500
From: Jeff Tantsura 
To: Gregory Mirsky 
Subject: Re: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Topic: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Index: AQHNzPFN8EvyV1D7LEeeBn/TSnDxxZf+2+aA///lo4M=
Date: Wed, 28 Nov 2012 06:00:47 +0000
Message-ID: <50B5BAD3-EEAA-4AD6-A9B3-B00BF55A7EBD@ericsson.com>
References: <20121127223218.5615.43543.idtracker@ietfa.amsl.com> <07F60A12-559D-4C8E-91D0-8F460FF8E052@sniff.de>, <7347100B5761DC41A166AC17F22DF11201C95D@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF11201C95D@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtg-bfd@ietf.org" 
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2012 06:00:55 -0000

I concur with Greg's comments.

Regards,
Jeff

On Nov 27, 2012, at 18:35, "Gregory Mirsky"  w=
rote:

> Hi Marc,
> in section 2 you list four possible causes for positive negatives due to =
BFD monitoring interruption, not path failure. But I believe that detecting=
 cases 2 and 4 is actually what is expected of BFD as FPGA and LC failures =
directly affect data path. Which of remaining scenarios 1 and 3, in your op=
inion, will be excluded by shadow BFD session to justify new version of BFD=
?
>=20
>    Regards,
>        Greg
>=20
> -----Original Message-----
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal=
f Of Marc Binderberger
> Sent: Tuesday, November 27, 2012 2:48 PM
> To: rtg-bfd@ietf.org
> Subject: Fwd: I-D Action: draft-mbind-bfd-redundancy-00.txt
>=20
> Hello BFD experts,
>=20
> Nobo and me are interested in your feedback for a new proposal we make to=
 enhance the redundancy characteristics of BFD.
>=20
> With requirements (*) to run BFD practically without interruption at shor=
t timer intervals we think it's worthwhile to think about and discuss it.
>=20
> (*: I'm sure you either have similar requests from your customers or you =
are one of these customers asking for it ;-)
>=20
>=20
> Best regards,
> Marc
>=20
>=20
>=20
> Begin forwarded message:
>=20
>> From: internet-drafts@ietf.org
>> Date: November 27, 2012 23:32:18 GMT+01:00
>> To: i-d-announce@ietf.org
>> Subject: I-D Action: draft-mbind-bfd-redundancy-00.txt
>> Reply-To: internet-drafts@ietf.org
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>>=20
>>=20
>>    Title           : Redundant BFD sessions
>>    Author(s)       : Marc Binderberger
>>                         Nobo Akiya
>>    Filename        : draft-mbind-bfd-redundancy-00.txt
>>    Pages           : 7
>>    Date            : 2012-11-27
>>=20
>> Abstract:
>>  This document defines a second or "shadow" BFD session to an existing
>>  "primary" BFD session, providing resilience against BFD failures that
>>  are not legitimate.
>>=20
>>  Scenarios will be discussed on how presence of a shadow BFD session
>>  will be beneficial in the context of high availability.
>>=20
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-mbind-bfd-redundancy
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-mbind-bfd-redundancy-00
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20

From marc@sniff.de  Wed Nov 28 01:00:16 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74D421F85ED for ; Wed, 28 Nov 2012 01:00:16 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Afj0Puq32XL for ; Wed, 28 Nov 2012 01:00:16 -0800 (PST)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B181B21F86BA for ; Wed, 28 Nov 2012 01:00:15 -0800 (PST)
Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id B8B702AA0F; Wed, 28 Nov 2012 09:00:11 +0000 (GMT)
Subject: Re: I-D Action: draft-mbind-bfd-redundancy-00.txt
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Marc Binderberger 
In-Reply-To: <7347100B5761DC41A166AC17F22DF11201C95D@eusaamb103.ericsson.se>
Date: Wed, 28 Nov 2012 10:00:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121127223218.5615.43543.idtracker@ietfa.amsl.com> <07F60A12-559D-4C8E-91D0-8F460FF8E052@sniff.de> <7347100B5761DC41A166AC17F22DF11201C95D@eusaamb103.ericsson.se>
To: Gregory Mirsky 
X-Mailer: Apple Mail (2.1084)
Cc: "rtg-bfd@ietf.org" 
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2012 09:00:17 -0000

Hello Gregory,

thanks for your feedback.=20

> in section 2 you list four possible causes for positive negatives due =
to BFD monitoring interruption, not path failure. But I believe that =
detecting cases 2 and 4 is actually what is expected of BFD as FPGA and =
LC failures directly affect data path.

you are right, depending on the hardware design these may be true =
failures that should be detected with BFD. What we should have mentioned =
for (2) is that depending on the design you have FPGAs that are "extra" =
chips to handle the rapid packet generation/detection needed for OAM. In =
some architectures the forwarding may be distributed but the OAM may be =
centralized (for cost reasons, one FPGA can produce large volumes of =
BFD, no need to distribute).

The case (4) is similar in the sense that the linecard (*) where you =
produce the BFD packets is not or not always the linecard with the =
physical path. An example is BFD over a logical bundle, i.e. the single =
BFD session into the "big pipe" LAG. If the LAG member links are spread =
across linecards L1 and L2 then a failure of L1 may be still "okay" for =
the LAG if L2 carries enough member links. But when the BFD packet =
generation happens on L1 then a BFD failure would be detected on the =
peer, without a need.

(*: i.e. the card with the physical ports; you may use a different term =
for it)

You can extend this to other "virtual" interfaces, GRE tunnels, =
MPLS-TE/-TP and so on.


> Which of remaining scenarios 1 and 3, in your opinion, will be =
excluded by shadow BFD session to justify new version of BFD?

both, assuming that you have a 2nd Route processor (RP) in case (3) as =
you could run the shadow session on the "standby RP". And for (1) the =
crash could be handled with a 2nd BFD process, if possible on another =
CPU.


Again, very helpful comment, looks like we need to explain more the =
possible scenarios.


Thanks & Regards,
Marc



>=20
> 	Regards,
> 		Greg
>=20
> -----Original Message-----
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On =
Behalf Of Marc Binderberger
> Sent: Tuesday, November 27, 2012 2:48 PM
> To: rtg-bfd@ietf.org
> Subject: Fwd: I-D Action: draft-mbind-bfd-redundancy-00.txt
>=20
> Hello BFD experts,
>=20
> Nobo and me are interested in your feedback for a new proposal we make =
to enhance the redundancy characteristics of BFD.
>=20
> With requirements (*) to run BFD practically without interruption at =
short timer intervals we think it's worthwhile to think about and =
discuss it.
>=20
> (*: I'm sure you either have similar requests from your customers or =
you are one of these customers asking for it ;-)
>=20
>=20
> Best regards,
> Marc
>=20
>=20
>=20
> Begin forwarded message:
>=20
>> From: internet-drafts@ietf.org
>> Date: November 27, 2012 23:32:18 GMT+01:00
>> To: i-d-announce@ietf.org
>> Subject: I-D Action: draft-mbind-bfd-redundancy-00.txt
>> Reply-To: internet-drafts@ietf.org
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>=20
>>=20
>> 	Title           : Redundant BFD sessions
>> 	Author(s)       : Marc Binderberger
>>                         Nobo Akiya
>> 	Filename        : draft-mbind-bfd-redundancy-00.txt
>> 	Pages           : 7
>> 	Date            : 2012-11-27
>>=20
>> Abstract:
>>  This document defines a second or "shadow" BFD session to an =
existing
>>  "primary" BFD session, providing resilience against BFD failures =
that
>>  are not legitimate.
>>=20
>>  Scenarios will be discussed on how presence of a shadow BFD session
>>  will be beneficial in the context of high availability.
>>=20
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-mbind-bfd-redundancy
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-mbind-bfd-redundancy-00
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>=20
>=20

--
Marc Binderberger           


From nobo@cisco.com  Wed Nov 28 06:42:56 2012
Return-Path: 
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF43321F87DE for ; Wed, 28 Nov 2012 06:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ0x8c2Rr6z8 for ; Wed, 28 Nov 2012 06:42:54 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7D95C21F886A for ; Wed, 28 Nov 2012 06:42:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8011; q=dns/txt; s=iport; t=1354113774; x=1355323374; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lokd3oz7gDf4EIgGI4oHCtmMX4ifob8Lfte/ijkHI7Y=; b=GKQetEeoAftMr8thEi8GHS41GKAXz0tkj+NnCtSKNsSl9AMd7ankDe/p +dvAg4Vo2OomJQoWmq+wpAd0oYOpKwzaSH/33SzRDalNKFDOKVrNqAxtT RAJlgjorw+8BZai2cjIrcmonJKXXYqaLp3YDb1w8/gGjQowgTYm1sXc9y c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAKYitlCtJV2Y/2dsb2JhbAA7CoJsvSkWc4IeAQEBAwEBAQE3MQMLBQcEAgEIEQMBAQELFAkHJwsUCQgCBAENBQgBEoduBgELvnWMPwIPCoNFYQOXHYobhQ2CcIFsNQ
X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="144109367"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 28 Nov 2012 14:42:53 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qASEgrTv003178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 14:42:53 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 08:42:52 -0600
From: "Nobo Akiya (nobo)" 
To: Alexander Vainshtein , Gregory Mirsky , Marc Binderberger 
Subject: RE: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Topic: I-D Action: draft-mbind-bfd-redundancy-00.txt
Thread-Index: AQHNzPFDn88MP7nyQ02zt3TH752KBJf+7KqAgAA2BQCAACZkAA==
Date: Wed, 28 Nov 2012 14:42:51 +0000
Message-ID: 
References: <20121127223218.5615.43543.idtracker@ietfa.amsl.com> <07F60A12-559D-4C8E-91D0-8F460FF8E052@sniff.de>, <7347100B5761DC41A166AC17F22DF11201C95D@eusaamb103.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [161.44.213.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtg-bfd@ietf.org" 
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2012 14:42:56 -0000

Hello Sasha,

Thanx for comments. Please see inline.

> -----Original Message-----
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
> Behalf Of Alexander Vainshtein
> Sent: Wednesday, November 28, 2012 12:49 AM
> To: Gregory Mirsky; Marc Binderberger
> Cc: rtg-bfd@ietf.org
> Subject: RE: I-D Action: draft-mbind-bfd-redundancy-00.txt
>=20
> Hi all,
> I've read the draft, and I concur with Greg's comment: at least some of
> the scenarios described as possible causes for false detection of the
> session failure look like legitimate path failures to me.

Hopefully explanations that Marc provided on another thread have cleared th=
is up. It's clear that we need to better write this section.

>=20
> I also assume (even if the draft does not spell this out) that the proble=
m
> is false detection of the BFD session failure by the peers of the router
> that experiences one of the scenarios described in the draft.
> IMHO and FWIW handling of "local" problems with the BFD session does not
> require any modifications to the BFD standards, it is an implementation
> issue. As a consequence, I wonder why the shadow session would be really
> helpful in differentiating between "true" and "false" path failures.

Yes this is where we started as well. Based on my experience, that trying t=
o address some "local" problems w/o flapping BFD sessions can be (1) very d=
ifficult ex: not enough time to detect & react, or (2) can result in very c=
omplex & potentially timing sensitive design. Thus we wanted to see if some=
thing simpler can be done, which is this draft.

>=20
> E.g., consider crash of the BFD-handling process in a SW-based BFD
> scenario: does the draft suggest that "main" and ""shadow" BFD sessions
> would be handled by two different BFD processes? (This probably would
> not help n the case of CPU starvation.)=20

[snip]
   A logic
   SHOULD be applied to identify where in the system to host the two
   sessions.  The logic should maximize the failure detection validity
   by minimizing the chances of both sessions being impacted by a single
   local failure. =20
[snip]

We kept this a bit vague on purpose, allowing implementations to choose the=
 placement logic. However, if there are multiple CPU instances on your syst=
em, it may be more desirable to run primary and shadow BFD sessions on sepa=
rate CPU to avoid one CPU starvation instance impacting both primary and sh=
adow sessions.

> Or does the draft assume that
> the crashed process could be restarted fast enough to maintain at least
> one of the two paired sessions intact for the peers? If this is what the
> draft proposes, would not the same result be achieved by simply increasin=
g
> the session failure detection time?

Operators often push for faster detection time, I'm sure all vendors have f=
elt that "heat". So we wanted to avoid a solution requiring longer failure =
detection time.

>=20
> Failure of the routing processor card in the centralized BFD scheme looks
> like another valid use case of false path failures. But how would the
> "shadow session" help in this scenario? Does the draft assume that the
> "shadow" session would be handled by the backup routing processor
> (assuming there is one)? This is possible, but is it sufficiently
> different from implementing "hot standby" for the BFD sessions in the
> backup rouging processor?

Difference is that this draft allows "fully hot" instead of "hot standby", =
and eliminates any potential synchronizations between "primary" and "hot st=
andby".

>=20
> Yet another side of the problem is a (pretty obvious IMHO) requirement
> for the mechanism differentiating between "true" and "false" data path
> failures not to increase the time it takes to detect the
> "true"/"legitimate" failure. The draft does nt explicitly describe how
> the "shadow" session is used in he case of "true" failures, so it is not
> clear to me if the proposed mechanism really meets this requirement.

This is a great feedback. We described this a bit in section 6, but it's cl=
ear that we need to be clear-er on this topic. Noted.

Again, thanx for great feedback.

Regards,
Nobo

> If this requirement is not met, simply increasing the session failure
> detection time looks like a trivial answer for most (if not all) of the
> scenarios mentioned in the draft.
>=20
> My 2c.
>      Sasha
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> ________________________________________
> From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] on behalf of
> Gregory Mirsky [gregory.mirsky@ericsson.com]
> Sent: Wednesday, November 28, 2012 3:35 AM
> To: Marc Binderberger; rtg-bfd@ietf.org
> Subject: RE: I-D Action: draft-mbind-bfd-redundancy-00.txt
>=20
> Hi Marc,
> in section 2 you list four possible causes for positive negatives due
> to BFD monitoring interruption, not path failure. But I believe that
> detecting cases 2 and 4 is actually what is expected of BFD as FPGA and
> LC failures directly affect data path. Which of remaining scenarios 1
> and 3, in your opinion, will be excluded by shadow BFD session to justify
> new version of BFD?
>=20
>         Regards,
>                 Greg
>=20
> -----Original Message-----
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
> Behalf Of Marc Binderberger
> Sent: Tuesday, November 27, 2012 2:48 PM
> To: rtg-bfd@ietf.org
> Subject: Fwd: I-D Action: draft-mbind-bfd-redundancy-00.txt
>=20
> Hello BFD experts,
>=20
> Nobo and me are interested in your feedback for a new proposal we make
> to enhance the redundancy characteristics of BFD.
>=20
> With requirements (*) to run BFD practically without interruption at shor=
t
> timer intervals we think it's worthwhile to think about and discuss it.
>=20
> (*: I'm sure you either have similar requests from your customers or you
> are one of these customers asking for it ;-)
>=20
>=20
> Best regards,
> Marc
>=20
>=20
>=20
> Begin forwarded message:
>=20
> > From: internet-drafts@ietf.org
> > Date: November 27, 2012 23:32:18 GMT+01:00
> > To: i-d-announce@ietf.org
> > Subject: I-D Action: draft-mbind-bfd-redundancy-00.txt
> > Reply-To: internet-drafts@ietf.org
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> >       Title           : Redundant BFD sessions
> >       Author(s)       : Marc Binderberger
> >                          Nobo Akiya
> >       Filename        : draft-mbind-bfd-redundancy-00.txt
> >       Pages           : 7
> >       Date            : 2012-11-27
> >
> > Abstract:
> >   This document defines a second or "shadow" BFD session to an existing
> >   "primary" BFD session, providing resilience against BFD failures that
> >   are not legitimate.
> >
> >   Scenarios will be discussed on how presence of a shadow BFD session
> >   will be beneficial in the context of high availability.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-mbind-bfd-redundancy
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-mbind-bfd-redundancy-00
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
>=20
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform
> us by e-mail, phone or fax, and then delete the original and all copies
> thereof.