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

From: "Putzolu, David" <[email-masked]>
Date: Fri, 25 Feb 2005 19:15:47 -0800

All,

draft-ansari-forces-discovery-01.txt has been proposed
as a working group document.  This draft defines a 
controlled objects (aka LFB) as mentioned in the 
following charter deliverable:

o A formal definition of the controlled objects in the
  functional model of a forwarding element. This
  includes IP forwarding, IntServ and DiffServ QoS. An
  existing specification language shall be used for
  this task. 

We would like to request that WG participants please
review this draft and provide feedback as to whether
it should be accepted as a WG document.  Acceptance as
a WG document means that the WG participants have read
the document, approve of the concept and general approach,
and believe it is ready to form the basis of a solution
to the problem the document addresses, and is within the
WG charter.  It does not require that the document be in 
a final form or be 100% correct.

Document URL:
http://www.ietf.org/internet-drafts/draft-ansari-forces-discovery-01.txt

All feedback should be provided either via email to the
WG list or in the upcoming WG meeting in Minneapolis.

Thanks,
David and Patrick

> -----Original Message-----
> From: Forwarding and Control Element Separation 
> [mailto:[email-masked]] On Behalf Of Furquan Ansari
> Sent: Thursday, February 24, 2005 10:51 AM
> To: [email-masked]
> Subject: Re: [FORCES] Model comments: FE Object and FE topology
> 
> Folks,
>         As part of the discussion that Jamal has brought up, I would 
> request the WG members to read the draft on topology
> discovery - i.e. draft-ansari-forces-discovery-01.txt that 
> was submitted 
> at the last IETF and provide any feedback. Since many WG 
> members had not 
> read the draft the last time, a decision on making it a WG 
> item couldn't 
> be made. I hope that decision can be made at this time.
> 
> Thanks,
> 
> 
> Jamal Hadi Salim wrote:
> 
> >Folks,
> >
> >I wish to reopen the discussion on the FE topology mostly 
> given light of
> >newer developments such as working towards making
> >draft-ansari-forces-discovery-01.txt a WG item  (as discussed in last
> >meeting). 
> >Besides that i do believe that FEConfiguredNeighborType violates the
> >simple rules we have imposed on separation (unnecessarily if 
> i may add).
> >
> >The FEObjects view of the neighbor at the moment is a little too
> >intrusive. It tries to aggregate things that are found in a few other
> >LFBs within this single spot (ARP, etc) when there is no 
> need to do so.
> >If we need to lookup an IP to address mapping surely that 
> would be ARP
> >LFBs job. If we are to have static entries mapping the two, then that
> >still belongs to the ARP LFB. Ok, worst case create a "static
> >configuration LFB" (although static config files should do 
> just fine).
> >I dont expect a human (other than a developer) to be looking at this
> >LFBs details. I do expect tools to look at this LFB for the 
> purpose of
> >gathering and correlating info about an FE and its neighbors but they
> >woul be looking at a lot more LFBs.
> >i.e there is no point in breaking the rules just for this one thing.
> >
> >Additionaly:
> >FEConfiguredNeighborType also asumes MAC addresses and IP 
> addresses as
> >the underlying connection for the Neighbor. This is bad.
> >I do expect we will see various technologies interconnecting FEs
> >(anywhere from sockets, ethernet, ethernet VLANS, CSIX, SPI-X to
> >PCI-Express AS- switches.)
> >
> >My suggestion:
> >
> >The most meaningful things to show that will suffice for all 
> >configuration is:
> >
> >- Neighbors FEID
> >- The interface of the above neighbor
> >- FE's interface that connects to this neighbor
> >
> >Even the above maybe intrusive, but make less assumptions.
> >Any other information should be accessible elsewhere. You oughta know
> >where to find it because it is documented in LFB definitions.
> >
> >cheers,
> >jamal
> >  
> >
> 
> -- 
> Furquan Ansari
> Bell Labs Research			Ph : 732-949-5249
> Holmdel, NJ				Fax: 732-949-4556
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 26 Feb 2005 11:51:50 -0500

I have a concern about accepting this document as a working group document.
In addition to defining a controlled object (an LFB class), this document 
defines a whole new protocol for discovery.
The IETF arguably has too many discovery protocols all ready.
Heck, we just chartered a working group for another one.

Further, it would seem to me that any discovery protocol ought to be able 
to discover the FE neighbors whether they are parts of the same ForCES NE, 
part of a different ForCES NE, or part of some other kind of 
device.  Hence, defining such a discovery protocol seems out of scope for 
ForCES.  Defining / requesting additions to existing discovery protocols 
may make sense.

At the very least, if we are going to invent yet another discovery 
protocol, we need to state that we know about the existing set of tools, 
and explain why they are not sufficient.  And for me, I would need to see 
and buy into such an explanation before I would be comfortable with this as 
a working group document.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 26 Feb 2005 12:46:21 -0500

> Heck, we just chartered a working group for another one.

Yes, but thats not good reasoning. Let me list even more for you:
- Cisco has CDP (Cisco Discovery Protocol); 
- Extreme Networks has EDP (Extreme Discovery Protocol)
- Enterasys Networks has yet another CDP (Cabletron Discovery Protocol);
- Nortel Networks has NDP (Nortel Discovery Protocol).
- and every other chip vendor i have seen has one too
- etc

And of course none of them work with each other although most do the
same concepts in different ways. 
I assure you that every vendor building some distributed box that i
didnt list above has one as well.
And if you want to go to the heck direction, heck the IEEE is also
working on one as well (off top of my head its called 802.1ab and is 
based on CISCO CDP and UDLD iirc).

But again, thats beside the point ...

The point is we need some very lightweight FE neighbor discovery that
is not going to be mandated to implement.
If Nortel wishes to continue using NDP. so be it. If some fool wishes to
run OSPF to do such discovery, so be it. If i wish to just write a tool
to do configs of neighbors on the CLI to achieve that goal, so be it.

> device.  

No Joel: this is very speacial purpose and works only within the
constraints of an NE. This is design intent to cut the fat.
The CE instructs the FE where to go find neighbors.
The CE could have found the FEs neighbors and told it. As an
optimization, the CE offloads some of that funtionality to the FE. 

We have agreed to allow offloading of LFBs to the FE (i think the
example listed in the drafts is that of offloading OSPF hellos to the
FE). This optimization is no different from just that.

> Hence, defining such a discovery protocol seems out of scope for 

I cant think of  one protocol that we could ask extensions for that
would not be both heavyweight (implementing the 1000 other features we
dont need).
I can write and test the code for this protocol (once a Forces framework
exists) in a day or two and i consider myself an average programmer.

> a working group document.

I think this is a fair request. I have listed some of these motivations
above; but we need to be more explicit.

cheers,
jamal

---

From: Alistair Munro <[email-masked]>
Date: Sun, 27 Feb 2005 23:12:51 +0000

Hi All,

I support adopting this document as a WG draft so that it is properly 
discussed. The functions are useful even if the protocol may be redundant 
when the multitude of other discovery protocols are properly taken into 
account. If there are genuine competitors then it is a debate that is worth 
having.

Regards,

Alistair

--
Alistair Munro,
Principal Engineer, U4EA Technologies Ltd.
City Point, Temple Gate, Bristol, BS1 6PL, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-373-6751
Web: http://www.u4eatech.com

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 27 Feb 2005 22:32:35 -0500

We should determine that there is a problem, and that we need to solve it, 
before adopting as a work item for the working group a specific 
solution.  I would be interested in seeing a draft that outlined what 
problem needed to be solved, why the many existing solutions among 
themselves did not provide sufficient coverage, and what properties a 
solution might need to have.  It does not need to be a full "requirements" 
document.

It could also be that we have extended email and face to face discussion of 
the problem, conclude it really needs to be addressed without a 
problem-oriented ID, and then see what we want to do about solutions.

But adopting a solution document as a working group work item is not the 
way to decide if there is a problem to be solved.

Yours,
Joel M. Halpern

At 06:12 PM 2/27/2005, Alistair Munro wrote:
>account. If there are genuine competitors then it is a debate that is 
>worth having.
>
>Regards,
>
>Alistair
>
>--
>Alistair Munro,