IETF 63 agreements

Carlos Garcia Braschi <cgbraschi@gmail.com> Tue, 30 August 2005 08:47 UTC

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z+x0+bJMVhnsynRjE64L+MGqppQvp61nHg8kt3l1heiYMUhE9QVoGr/kus/kMZzggf1QLLYZgX3Ua+R9gv8NjdbbNHgzbGUOpSqWvA+YICS/rQ8upqdbcDwNjwm1jLnqEyFaqTEHsL3+WbqNM7nT9dK9w0SMjhvxrgca3nb1iqk=
Message-ID: <9e31186f050830014627aff97d@mail.gmail.com>
Date: Tue, 30 Aug 2005 10:46:59 +0200
From: Carlos Garcia Braschi <cgbraschi@gmail.com>
To: rtg-bfd@ietf.org
In-Reply-To: <42fcbf72.7c98d4c4.641f.0bfdSMTPIN_ADDED@mx.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <42fcbf72.7c98d4c4.641f.0bfdSMTPIN_ADDED@mx.gmail.com>
Content-Transfer-Encoding: quoted-printable
Subject: IETF 63 agreements
Precedence: list
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

Hi,

Rereading the IETF 63 minutes, I have some doubts about what was agreed there: 

Dave said that applications would be inlined in the text of the
generic applications draft, but I am not sure if the applications
would be the ones that are now there (static routes), or others like
BGP or RIP would be added.

Are the slides from Suping archived somewhere? In the minutes Pekka
refers to the first bullet point of the presentation but it is not
clear from the context what is it about.

On the generic draft, something that worries me is the problem of
having multiple peers in a client application (broadcast subnets with
many peers, it happens in Nework PoPs and Ethernet Access networks or
BGP peering points), some that support BFD and some that don't.

Figuring out which ones do and which ones don't is something not
trivial: it either requires configuration (work for the network
operators, and may not even be feasible if there are many peers), or
protocol work to signal it.

So the current recommended approach (if I get it right) is to just let
the BFD session never reach the Up state, and as in the Down state it
only has to transmit at the sedate rate, it may not be that great of a
problem. Should a mention about this be added to the generic
application draft or is it too obvious?

I don't know if even the sedate rate can cause problems for some
systems (1p/s can cause some load, depending on the implementation and
number of peers). Given that a router should respond with an ICMP port
unreachable to BFD packets if it does not implement BFD (although it
may not due to security purposes, it would be required per the host
requirements standard), could this be taken as a sign of
non-implementation that causes packets not to be sent? (for example,
on receipt take a passive role and enter the AdminDown state).

Regards,
Carlos.
--
Telefonica Empresas.

IETF 63 agreements Carlos Garcia Braschi