Subject: Re: other comments for single-hop bfd

From: Carlos Garcia Braschi <[email-masked]>
Date: Thu, 24 Feb 2005 19:05:00 +0100

On Thu, 24 Feb 2005 09:06:02 -0800 (PST), [email-masked]
<[email-masked]> wrote:
> Message: 5
> Date: Thu, 24 Feb 2005 10:28:32 -0600
> From: David Ward <[email-masked]>
> Subject: Re: other comments for single-hop bfd [Re: I-D
>         ACTION:draft-ietf-bfd-v4v6-1hop-01.txt]
> To: Dave Katz <[email-masked]>, [email-masked]
> Cc: [email-masked], Pekka Savola <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> 
> Dave, et al -
> 
> There should be a simple, 'how to bootstrap a BFD session and what to do
> when you rx a BFD event' doc. The pros are that we don't have to increment
> this doc every time we think about another protocol to interact w/ BFD, the
> cons are that it is just about all contained in this doc. There are some
> nuances of IGP interaction but, for the most part  protocols/applications that
> want to be dependent on  BFD as a forwarding failure detection, will have
> very generic interactions.
> 
> I am hoping that  the new draft will be  very, very short and not call out
> each and every application, scenario or potential usage. If we keep it
> generic, we can get it through the process much more quickly. If a protocol
> or application actually has specific needs (e.g. LSPping), then it deserves
> it's own draft/spec. I think Dave and I can crank this out very quickly.
> 

Seems like a good approach, although I'd favor publishing (in the same
or other drafts) the specific application of BFD 1hop to the specific
cases known today, OSPF, IS-IS, BGP, and static routes.

The text seems to exist already for most of them, and having a
separate draft for the nuances of each one of them seems to be quite
messy. And not having them seems to leave a door open for incompatible
implementaions...

Carlos.

> -DWard

---

From: Dave Katz <[email-masked]>
Date: Thu, 24 Feb 2005 11:22:41 -0700

> messy. And not having them seems to leave a door open for incompatible

The problem is that folding it into the 1hop spec will delay 
progressing that spec for another four months, whereas we should be 
able to go to last call soon if we keep it separate.

Frankly, I think there's very little to say about the interworking of 
BFD with other protocols, and almost no opportunity for 
interoperability problems (since for the most part the spec will say 
"if BFD goes down, do the appropriate teardown procedure in the 
protocol".)  I forsee a few SHOULDs and not much else.

--Dave

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Feb 2005 13:33:17 -0500

> protocol".)  I forsee a few SHOULDs and not much else.

I would tend to agree.  Also, it's likely that it would be up to
each WG to specify how their protocol utilizes BFD.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Feb 2005 20:37:08 +0200 (EET)

On Thu, 24 Feb 2005, Dave Katz wrote:
> The problem is that folding it into the 1hop spec will delay progressing that 
> spec for another four months, whereas we should be able to go to last call 
> soon if we keep it separate.

There is procedurally no need to wait for the face-to-face meetings to 
go to last call.

It's (procedurally) entirely fine to revise the 1hop draft with BGP 
and static routes immediately after Minneapolis, and fire off a WG 
last call a week after that.

The chairs should judge the appropriate procedures, of course, but the 
spec getting delayed is (IMHO) not a concern here.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Dave Katz <[email-masked]>
Date: Thu, 24 Feb 2005 11:45:29 -0700

> spec getting delayed is (IMHO) not a concern here.

Fine with me if true.  Less typing on my part.  If the WG chairs could 
advise on parliamentary procedure that would be most appreciated.

--Dave

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Feb 2005 14:02:47 -0500

> advise on parliamentary procedure that would be most appreciated.

The business of the Working Group takes place on the mailing list.
The primary purpose of our meetings is to try to hash out issues
that take too much bandwidth to convey simply on a mailing list.

Several issues related to the most recent drafts have been raised on
the mailing list.  It would be to the authors' benefit to summarize
the issues and the relevant responses as part of their presentations
during the meeting.  This helps us with last call issues.

As for the static route/eBGP single hop items, placing them in the base
document is probably fine.  Static routes seem to be a reasonably simple
case.  

I'm vaguely concerned about BGP with regards to third party nexthops.
While this is unusual in practice (since most eBGP is over p2p
links) the protocol allows for it.  There's also the question as to
whether or not we have a BFD session to cover the transport session,
one for each discovered BGP Nexthop that is determined to be resolvable
(if different than the endpoints for the transport session).  There's
the further question as to how we handle the same issues when doing
multihop eBGP or whether we should worry about this case at all.

My personal inclination is that BGP has enough issues to warrant a
mini-draft.  

In all cases, when we involve a particular protocol that isn't BFD,
we require consensus with the group that owns the protocol.  This
further entangles us in last call issues.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Feb 2005 17:58:00 +0200 (EET)

> My personal inclination is that BGP has enough issues to warrant a

Well, I'm not sure if I'm concerned about these, but I see these as 
potential items for debate.  In my opinion, I see the following as 
obvious:

  - BFD session is between BGP peers, not between nexthops
    (that could be even used to perform a DoS attack on 3rd parties,
    as it could trigger initiating BFD sessions to random
    destinations).

    I.e., if you use 3rd party nexthops, you're on your own for
    validating that the 3rd party nexthop stays up -- as with BGP.
    BGP doesn't have Hello's to 3rd party nexthops either, why should
    BFD?

  - we are only addressing single-hop eBGP here (1hop document)
    (though the only obvious difference I see is that you can't use
    TTL=255 check here)

  - I'm also not all that concerned about review delays.  I mean, this
    already has to go through two WGs (OSPF, IS-IS).  What's third to
    the mix?

That said, I'm not strongly objecting to putting BGP in a separate 
document, just as long as there is a framework what the document 
should look like.

---

From: David Ward <[email-masked]>
Date: Fri, 25 Feb 2005 14:41:12 -0600

I am still of the opinion that
a generic draft is of greater utility to cover the next round of
protocols that want to bootstrap a BFD session. We can go to last call on
the list after we have a discussion period. Although requiring more typing,
let's go w/ a 'generic interaction'  draft. 

I know of implementations that
exist today that allow for more than IGP, static and EBGP bootstrapping ...
I think that if we just focus on including these two in the 1-hop draft, it
simply isn't going to close (with or w/o the ability to LC after MSP) due
to a 'me too' problem w/ other protocols.

-DWard