Re: Rtg-bfd Digest, Vol 15, Issue 4

Carlos Garcia Braschi <cgbraschi@gmail.com> Wed, 26 October 2005 14:49 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmaa-00013C-M7; Wed, 26 Oct 2005 10:49:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmaZ-0000zW-29 for rtg-bfd@megatron.ietf.org; Wed, 26 Oct 2005 10:49:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24510 for <rtg-bfd@ietf.org>; Wed, 26 Oct 2005 10:48:59 -0400 (EDT)
Received: from nproxy.gmail.com ([64.233.182.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUmnj-0004GN-0K for rtg-bfd@ietf.org; Wed, 26 Oct 2005 11:02:52 -0400
Received: by nproxy.gmail.com with SMTP id o25so39376nfa for <rtg-bfd@ietf.org>; Wed, 26 Oct 2005 07:49:11 -0700 (PDT)
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=WBA3npMOfqqMu249T7/DAUtmnNm/hiX7d+GvtIc63Liu2bxyrulZxzD5H5y3mkd3Eqr/MFy+UxwJKuDZc3p9mJkgRaedwNTHJNpyOAmfdc1EHIPeWBl6+qLjWkZsEQ8XkfXUic0id44n/gGJ6nogFPbC3tXfMhKm7Sbgt3IKv64=
Received: by 10.49.5.10 with SMTP id h10mr222837nfi; Wed, 26 Oct 2005 07:49:11 -0700 (PDT)
Received: by 10.49.2.20 with HTTP; Wed, 26 Oct 2005 07:49:11 -0700 (PDT)
Message-ID: <9e31186f0510260749v2eb5a8a3g@mail.gmail.com>
Date: Wed, 26 Oct 2005 16:49:11 +0200
From: Carlos Garcia Braschi <cgbraschi@gmail.com>
To: rtg-bfd@ietf.org
In-Reply-To: <435e59cb.3c6b0262.01d8.ffffb661SMTPIN_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: <435e59cb.3c6b0262.01d8.ffffb661SMTPIN_ADDED@mx.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Content-Transfer-Encoding: quoted-printable
Subject: Re: Rtg-bfd Digest, Vol 15, Issue 4
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

2005/10/25, rtg-bfd-request@ietf.org <rtg-bfd-request@ietf.org>:
> Date: Tue, 25 Oct 2005 09:52:49 -0600
> From: Dave Katz <dkatz@juniper.net>
> Subject: Re: BFD w/ static routes and single-hop eBGP
>

[...]

> The interaction between BFD and its clients is not an
> interoperability issue, as it is purely an internal implementation
> issue. The interaction does not need to be the same (or even
> present) at both ends; it would be entirely reasonable for only
> one eBGP peer to be caring about the BFD session (which
> might have been bootstrapped for some other reason
> independent of eBGP) and it would still be useful and would still
> not cause interoperability issues. This is identical to other
> mechanisms (say, SONET alarms.) There is no specification
> for how OSPF interacts with SONET alarms, but it is arguably
> useful, and it doesn't have to be done the same way (or at all)
> on every system in order for things to interoperate.
>
> This is equally true of bootstrapping. The fundamental issue is
> in finding (or launching, if it's not there already) a BFD session
> that corresponds to your protocol session in terms of the
> identity of the neighbor. This doesn't have to be done the same
> way (or at all) at each end of the protocol session. For that
> matter, if you managed to end up with two parallel BFD
> sessions due to addressing issues, you could even have each
> end of the protocol session interacting with a *different* BFD
> session and it would all still work.

These things are very good points, if they keep popping up is either
because they are not so obvious in the generic draft, or something
like this explanation is missing there.

Although if you end up with two parallel BFD sessions I would not
qualify that as interoperable implementations, as the resources used
are the double than needed...

> If anything substantive is missing, it should be added to
> the generic document. eBGP is just not particularly special.
> For that matter we could probably rip out most of the
> OSPF- and ISIS-specific stuff in the 1hop draft, since the
> techniques should be amply documented in the generic draft.
> I'm not too excited about revisiting those documents, however.

I think the most obvious thing out of place in the drafts right now is
that the whole section 7 in the one-hop draft deals with some non-BFD
questions specifically for OSPF and IS-IS (interaction, bootstrapping,
adjacencies, graceful restart and virtual links), that from this point
of view ("nothing needed is missing to use BFD for BGP") are not
needed for interoperability of OSPF or a generic 1hop situation (for
example, graceful restart comes to mind as not being 1hop- or OSPF-
specific).

BTW, I think all of that section 7 could apply for BGP also (it also
has graceful restart, adjacencies and so on).

The easiest way out would be to rip it away... or at least rip the
references to specific protocols. Taking something away from a draft
should not hurt in terms of moving it forward.

I don't know once you take that part away if there is interest in
mentioning anyway those issues that may appear for each protocols
(inter-level interaction, session bootstrapping, graceful restart and
virtual links) in another document, be it normative (generic draft) or
informative (an annex of the generic draft or an informational RFC).

An alternative to this ripping is to mention those issues for all the
protocols on the table right now... the issues would be very similar
for all, and would mostly correspond to the five points of section 7.
That is probably not what we want...

That still leaves us with the question of having something to be used
as a reference for CFT. It seems that you point as the generic draft
as the only thing needed. There are many manufacturers here on the
list, is there anyone needing more detail than what is described on
the generic draft? (Suping probably could help in that, being a
non-neutral third party).

In any case I favor any way out that could kill this issue and let the
draft move on...

Regards,
Carlos.
--
Telefonica Empresas


> --Dave
>
> On Oct 25, 2005, at 4:28 AM, Pekka Savola wrote:
>
> > Hi,
> >
> > I still want to see the details of BFD with:
> >  - single-hop static routes
> >  - single-hop eBGP
> >
> > .. in some document.  At the last meeting, David said that he
> > didn't believe these are necessary as the bfd-generic-01 doc
> > includes this information but I disagree.  Even if the details are
> > trivial (they may or may not be), as an operator I think it's vital
> > to see them spelled out anywhere so that we can point vendors to a
> > specific section of a spec in CFTs and ensure the protocols will be
> > interoperable.
> >
> > I suggest a section or two either in the main body of the spec or
> > in an appendix either in draft-ietf-bfd-v4v6-1hop or draft-ietf-bfd-
> > generic.
> >
> > All of this would likely fit in one or two pages -- and if not,
> > that would be even stronger reason that those details must be
> > written out. At least one deployed implementation of static routes
> > + BFD already exists.
> >
> > --
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> >
>