Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document?

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 1 Mar 2005 11:17:44 -0500

This takes me back to where i had the post on the neighbor info in the
FEObject.

There will always be a need to configure neighbors - Joel, do you
disagree with this statement? i.e this is a fundamental aspect of what
we need to do in Forces first deliverable even if its for just IPV4
forwarding. 

Let me illustrate with an example - hopefully this will help other
people tune into the discussion.

Consider FE0 (that for the sake of illustration) is connected to 3
neighbors, FE1 via a CSIX fabric interface (lets call it CSIX1); FE2 via
a L2TP tunnel (lets call it l2pt0) and, FE3 via ethernet interface that
we shall call eth0. I could have just shown CSIX or SPIx fabric
connection instead which is more realistic, but this example
demonstrates the variety of interfaces that could be found in a forces
NE.

With the above knowledge about each FE, a NE topology can be computed if
needed by the CE.

In the minimal a simple tool could be written to achieve this via static
config, example when you run this at the CE:

feconfig FE0 yourfeneighbor FE1 yourIFtoneigh CSIX1 IFatneigh CSIX0
feconfig FE0 yourfeneighbor FE2 yourIFtoneigh l2tp0 IFatneigh l2tp1
feconfig FE0 yourfeneighbor FE3 yourIFtoneigh eth0 IFatneigh eth1

What you just did is teach FE0 who its neighbors are. 

CSIX1 is an example of whats known as an "internal" interface. It is
never exposed to the outside world. 

Now show me one existing protocol that can do what the feconfig neighbor
configuration above does dynamically without:

a) being heavyweight (the 1000 other features BFD has)
b) insufficient for the core need (eg OSPF is fine if you have a V4/6
address but would not work for CSIX interfaces which have no IP
addresses)

I contend that the amount of effort to hack any existing protocol
to meet these desires is more intensive than to write a simple
protocol that is contrained within the NE.

cheers,
jamal

---

From: Furquan Ansari <[email-masked]>
Date: Tue, 1 Mar 2005 11:32:58 -0500

Joel,
 Comments inline.....

Joel M. Halpern wrote:

> If we assume that the interfaces are dedicated to being either 
> internal or external to the NE, and we assume that the CE actually has 
> per-interface OSPF configuration, then it won't start OSPF on those 
> interfaces.
> In that case, a protocol such as BFD would seem sensible. 

OSPF and other link state protocols are, in general, configured and 
enabled on a per-interface basis - surely one could
aggregate the configuration and enable on a whole bunch at a time (but 
from the protocol perspective, it is still on
per-interface). Further, one doesn't necessarily need to dedicate an 
interface to be either internal or external - it's a

As for BFD, it is a possibility - as has been mentioned in the draft. 
However, the focus of BFD is not topology discovery, it is detection of 
faults in bi-directional paths (One can start from there and extend it, 
as a possibility.
I wonder if it will become heavy-weight with all the other features in 
it that may not be needed for our purposes). It
provides the necessary (hello/lieveness), but not the sufficient 
condition (topology).

>
> I could equally easily imagine the normal configuration being
> "run OSPF'
> "noroute internal"
> which would enable OSPF on all interfaces, and then tell the enigne 
> not to bother exchanging routing information on internal interfaces.

Not sure what you mean by routing information, but I presume link state 
information in the case of OSPF. If you are not
exchanging link state information, then you are not generating the 
topology that you actually are intersted in.

If link state information is in fact generated and passed around and 
only routes shouldn't be calculated using these
links, I am not sure how one would go about doing it without changing 
OSPF. Like I mentioned before, this functionality
can be achieved by running a completely separate instance of OSPF, if 
one likes. But once you enable OSPF on all interfaces, the link state 
information will be flooded out to the rest of the network and the 
resulting link state database obtained will be used for route 
calculation  - with the internal nodes and link exposed to the external 
network elements.

>
> There are probably other existing alternatives I have not thought of 
> that can be used.
> We should be very cautious before inventing another protocol for a 
> problem that comes up repeatedly (neighbor detection.)
>
> It may be that we do need a very light weight specialized protocol.
> I want to understand what problem it is to solve and its relationship 
> to existing work before discussing the design details of the protocol.

I guess this is a very reasonable request and we should certainly 
discuss it more.

Thanks,

>
> At 04:40 PM 2/28/2005, Furquan Ansari wrote:
>
>> Joel,
>>    I am trying to understand what you are saying. Let's take this 
>> simple example of an NE with three
>> different FEs in it - See figure below. If a routing protocol such as 
>> OSPF is started on this NE, the CE
>> will send hello packets to neighboring NEs (NE2 and NE3) only through 
>> interfaces configured in OSPF -
>> which would be interface "D" on FE1 and "B" on FE2. It would not be 
>> correct behavior if the CE
>> decides to send the routing protocol Hellos through all the 
>> interfaces on an FE - that haven't been
>> configured for that routing protocol - i.e. CE should not send hellos 
>> on interface "B" and "C" on FE1
>> and "C" and "D" of FE2. Further FE3 is completely internal to the NE 
>> and who is it sending it's hello
>> packets to?
>> The discovery is meant to discover the internal topology - albiet 
>> through as simple a mechanim as
>> a hello protocol - but has been delineated from the routing protocol 
>> Hellos.
>>
>> Thanks,
>

-- 
Furquan Ansari
Bell Labs Research			Ph : 732-949-5249
Holmdel, NJ				Fax: 732-949-4556

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Mar 2005 12:24:51 -0500

I may be missing something, but I don't think we are trying to discover a
topology.  We are trying to discover which FEs that are under
control of a single CE are directly adjacent to each other.  So
sending and receiving OSPF or IS-IS hellos provides the necessary
information.

We do not need full link state information.  However, the more I
look the more inclined I am to use BFD.

Looking at available drafts on this problem, I find

draft-ietf-bfd-v4v6-1hop-01.txt

which states in its introduction:

One very desirable application for BFD [BFD] is to
track IPv4
and IPv6 connectivity between directly-connected systems.
This could be used to supplant the detection mechanisms in
IS-IS and OSPF, or to monitor router-host connectivity,
among other applications.

This document describes the particulars necessary to use
BFD
in this environment,

The draft notes that the mechanism is suitable for use with
liveness detection for tunnels.

Given that it provides detection and liveness monitoring of adjacencies,
it has the relevant properties.  If we need extra information
carried, we can work with the BFD working group to add them.

I would expect the IESG to look askance at us inventing a protocol to do
a job that is already being done.

"Too heavyweight" is rarely the a good reason.  And
particularly when the protocol has been designed from the bottom up to be
as lightweight as possible, one has to assume the additional elements are
there for a reason.  Remember that BFD was specifically designed for
implementation in the forwarding engine of a system.

Yours,

Joel M. Halpern

At 11:32 AM 3/1/2005, Furquan Ansari wrote:

Not sure what you mean by
routing information, but I presume link state information in the case of
OSPF. If you are not

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 1 Mar 2005 13:40:47 -0500

On Tue, 2005-03-01 at 12:24, Joel M. Halpern wrote:

[..]
> We do not need full link state information.  However, the more I look
> the more inclined I am to use BFD.

[..]

> The draft notes that the mechanism is suitable for use with liveness
> detection for tunnels.
> Given that it provides detection and liveness monitoring of
> adjacencies, it has the relevant properties.  If we need extra
> information carried, we can work with the BFD working group to add
> them.
> 
> I would expect the IESG to look askance at us inventing a protocol to
> do a job that is already being done.
> 
> "Too heavyweight" is rarely the a good reason.  And particularly when
> the protocol has been designed from the bottom up to be as lightweight
> as possible, one has to assume the additional elements are there for a
> reason.  Remember that BFD was specifically designed for

I just remembered why BFD would be the wrong protocol after reading a
couple of pages of the base draft. Its very important we capture this in
the draft.

- BFD's main focus is path liveliness.

- The protocol being pushed for WG item is _FE neighbor discovery_.

Recall that mythical command: "feconfig FE0 yourfeneighbor FE1
yourIFtoneigh CSIX1 IFatneigh CSIX0". Thats what we need to achieve as a
minimal.

BFD does NOT do discovery - it assumes you already know who your
neighbors are and that all you want to detect liveliness between them.
>From section 

-------
3.1. Addressing and Session Establishment

   A BFD session is established based on the needs of the application
   that will be making use of it.  It is up to the application to
   determine the need for BFD, and the addresses to use--there is no
   discovery mechanism in BFD.  For example, an OSPF [OSPF]
   implementation may request a BFD session to be established to a
   neighbor discovered using the OSPF Hello protocol.

---------

So clearly the basic desires are very different.

Having said that in the topology LFB draft, we do somehow assume that 
because we have hellos running around, we can also assume that livelines
detection is a given(i.e. free). Perhaps we need to decouple the two or
clearly make the liveliness feature as an optional add on. I would
rather leave it there.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Mar 2005 18:32:29 -0500

You are correct.  I had thought the discovery was there, and it is not.

This is unfortunate because there are a lot of pieces we are going to have 
to reinvent, including congestion response and authentication in order to 
make this work.

The primary requirement then is the ability to discover, over any 
interface, which FEs within the control of a CE are adjacent?
Presumably we must also monitor the liveness of that adjacency.  (No, I am 
not going to suggest using a different protocol for monitoring.)
Presumably, we have scale and responsiveness requirements?

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Mar 2005 18:44:37 -0500

Given this conclusion, the ansari draft seems to be a good place to start.

I do believe we should get explicit AD permission to develop the necessary 
protocol.

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Mar 2005 19:06:28 -0500

In case it is unclear to the list, I explicitly apologies for dragging the 
draft authors through this.  They were right all along.  (And no, they did 
not ask for an apology.  I feel they deserve one.)
Yours,
Joel

At 06:44 PM 3/1/2005, Joel M. Halpern wrote:
>>This is unfortunate because there are a lot of pieces we are going to 
>>have to reinvent, including congestion response and authentication in 
>>order to make this work.
>>
>>Presumably we must also monitor the liveness of that adjacency.  (No, I 
>>am not going to suggest using a different protocol for monitoring.)

---

From: Patrick Droz <[email-masked]>
Date: Wed, 2 Mar 2005 15:29:13 +0100

Hi Joel,

I am supposed to meet with them and I will talk to them.
My assumptions is there won't be much opposition.

Regards,
Patrick

Joel M. Halpern wrote:

> I do believe we should get explicit AD permission to develop the 
> necessary protocol.
> 
> Yours,
> Joel M. Halpern
> 
>> Presumably we must also monitor the liveness of that adjacency.  (No, 
>> I am not going to suggest using a different protocol for monitoring.)

-- 
   Dr. Patrick Droz 			| [email-masked]
   IBM Zurich Research Laboratory 	| http://www.zurich.ibm.com/~dro
   Saumerstrasse 4 			| Tel. +41-1-724-85-25 CH-8803
   Rueschlikon/Switzerland 		| Fax. +41-1-724-85-78