Re: Open issue: Degree of CE-FE Separation - Comment Please

Avri,

[...]
> interest. I therefore accept, somewhat grudgingly, the ADs
> having barred us from talking about the not-close issues.

<ad>
To make sure there's no confusion here: we're not barring
from talking about the not-close issues, but rather supporting
the idea of not requiring the WG to work on those right now
to ensure faster progress.
</ad>

> I
> also accept that it will be easier to solve the close then
> the not-close.  I am concerned however, that solutions for
> the close will be unsuitable for the not-close if they are
> not forced to take not-close considerations into account. In
> other words. the current focus may, and in my opinion
> probably will, hobble the solution so that it only works in
> close or very close situations.

Let's make sure that the solution we come up with is not selected
so shortsightedly that it does not allow us to move forward
in future. So, please do see where you would put your feet with
the second step, but secure the first one before actually making
it :)

Best regards!
Alex

Re: Open issue: Degree of CE-FE Separation - Comment Please

Hi
I agree to first focus on the "very close" case, then to deal with the "close"
one. Although I'm not so sure that restricting ourselves to the very close
gives all the needed answers :

John Renwick wrote:
> - FE and CE are at different points on a common medium (i.e. no
>   intermediate system between them).

Do we consider that this medium is in the scope of CE control, or
do we assume that this is a different medium ? In the first case,
I'm still concern by the fact that the CE could configure the FE in
such a way that the traffic between FE and CE would be broken.

Wouldn't be better to first consider that the control medium
and data medium are different ? This would help us to better understand
what it is needed between FE/CE, then we could deal with the ugly case
of fate-sharing.

--
Olivier Marce
Alcatel R&I Dept                        Tel: +33 (0) 1 69 63 41 67
Route de Nozay                          Fax: +33 (0) 1 69 63 11 69
F-91461 Marcoussis Cedex (France)

Re: HA issues, applicability etc

I agree that calling the requirement 'High Availability' is vague.  How
about either "CE Failover" or "CE Redundancy" support?  Will align
Applicability Stmt with Requirements, once the design team resolves this.

Alan

">"-----Original Message-----
">"From: Galina Pildush [mailto:galina <at> juniper.net]
">"Sent: Thursday, March 28, 2002 2:44 PM
">"To: FORCES <at> PEACH.EASE.LSOFT.COM
">"Subject: Re: [FORCES] HA issues, applicability etc
">"
">"How about "redundancy"?
">"
">"-----Original Message-----
">"From: Lily Yang [mailto:lily.l.yang <at> INTEL.COM]
">"Sent: Thursday, March 28, 2002 4:32 PM
">"To: FORCES <at> peach.ease.lsoft.com
">"Subject: Re: HA issues, applicability etc
">"
">"
">"I agree that "high availability" is too vague and too marketingnish.
">"Failover sounds ok to me. But is there other suggestion?
">"
">"Lily
">"
">"On Mon, 25 Mar 2002 15:26:59 -0800, Khosravi, Hormuzd M
">"<hormuzd.m.khosravi <at> intel.com> wrote:
">"
">">Hi Jamal

Re: Open issue: Degree of CE-FE Separation - Comment Please

Hi John,

> - Other qualities?

The metrics you mention are components of bandwidth*delay product metric
that I believe to be a good discriminator, although I did not explain very
well that delay includes the estimate of round-trip time, retransmissions
due to errors, etc. - derived from the usual utilisation formulae. What I
miss is an idea of the amount of data that will be in flight for any
individual ForCES transaction. If this is limited to one frame then your
scenario is fine; otherwise I would also include RTT in the list.

The situation you describe is appropriate to very close but I would like to
see RTT as a quality.

> With a few assumptions like this, we can understand what problems
> the protocol has to solve.

Unfortunately, RTT estimates mean we have to guess how big ForCES messages
will be...

Regards,

Alistair

Re: Open issue: Degree of CE-FE Separation - Comment Please

Hi Mark,

> A useful question would be to ask how limiting the design to
> "very-close" affects the design?
>

As recent messages indicated, I do not think it affects functional and
reliability requirements, which are above the transport level.

> What do we still need to do?
>
>  - the capability/configuration/management issues are the same (and
>    this is by far the largest part of the ForCES problem)

I believe this to be independent of closeness.

>  - we still need to deal with message reliability and congestion
>    control (some people might argue about this, but I don't think it's
>    optional - it provides graceful failure in the event of
>    control-plane overload)

Do you mean reliability of delivery or reliability of execution of the
function requested in the message?
I think the later is closeness independent and characteristic on any
distributed control problem. The former will depend on the interconnect
properties, thetransport protocol and buffering in the send/receive chain.

Congestion control will be required for any closeness value I think. A
synchronous backplane will be a contention point, possibly more than a
GigE interconnect.

Re: Open issue: Degree of CE-FE Separation - Comment Please

Hi All,

> Thus it seems to me that a protocol that handles "very-close" is
> pretty nearly a strict subset of a protocol that handles "close" or
> even "not-close" scenarios.

The functions invoked/requested by the CE of the FE will be the same
regardless of closeness. So will issues of reliability, e.g. if one CE
controls multiple FEs that must be maintained in a mutually consistent
state.

As the closeness decreases, I would expect to see different session and
transports appropriate to overcome the discontinuities of separation. I
think physical discontinuity is a good discriminator: for example a GigE
could be considered very close and a synchronous bus could be considered
to be very very close. GigE introduces a MAC and link-layer framing (yes,
IP would be appropriate if there is a router in the way, possibly not
otherwise). A synchronous bus has very few electrical and physical
discontinuities. The level of coupling is quite different.

Therefore the subsetting applies to the transport/session layers, not
above, IMO. The other protocol requirements are common to all closenesses.

Regards,

Alistair

DARPA Active Networks Conference and Exposition (DANCE)

Re: DARPA Active Networks Conference and Exposition (DANCE)

Tentative ForCES Minutes, IETF 53, Minneapolis

Attached are the minutes from our last meeting. Please send
corrections to me or comment on the list. Thanks to Alan
for taking notes.

Regards,
Patrick

ForCES Working Group Meeting Minutes from the 53rd IETF, Minneapolis
--------------------------------------------------------------------

1300-1500 Monday, March 18, 2002, Salon C

Meeting Agenda
--------------
1300-1310 Agenda Bash & Intro - Chairs
  WG Status - Relevant Milestones

1310-1320 Bandwidth Methodology Working Group
  Terminology and other potential areas of commonality
  Howard C. Berkowitz

1320-1325 Netlink as an IP Services Protocol (WG informational draft)
  Jamal Hadi Salim
  http://www.ietf.org/internet-drafts/draft-ietf-forces-netlink-02.txt

1325-1345 ForCES Requirements (WG requirements draft) - Update
  Margaret Wasserman
  http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-02.txt

1345-1410 ForCES Applicability Statement
  Mark Handley
  http://www.ietf.org/internet-drafts/draft-crouch-forces-applicability-01.txt

1410-1430 ForCES Architectural Framework
  Lily Yang
  http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-00.txt

1430-1455 Forwarding Element Model and
          ForwArding and Control ElemenT (FACT) Protocol
  Ram Gopal
  http://www.ietf.org/internet-drafts/draft-gopal-forces-fact-00.txt
  http://www.ietf.org/internet-drafts/draft-gopal-forces-femodel-00.txt

1455-1500 Next steps for WG docs and individual contribs

Welcome and Charter Status
--------------------------

There were about 110 people attending the ForCES meeting.
Both ADs Bill Fenner and Alex Zinin attended the meeting.

Presentations
-------------

1) Bandwidth Methodology Working Group (BMWG) - Howard C. Berkowitz

The purpose of Howard's presentation was to share information on the
opportunity for common terminology on control plane and data
plane. May be that we have a standard terminology. Working on a
document with that reflects thinking of major router vendors. Goal of
this presentation is to acquaint the ForCES WG on these documents, and
see if we can work together.

The current drafts are:
draft-ietf-bmwg-conterm-01.txt
draft-ietf-bmwg-bgpbas-01.txt
Both drafts should be updated soon.

2) Netlink as an IP Services Protocol (draft-ietf-forces-netlink-02.txt)
by Jamal Hadi Salim

Jamal presented changes in version 2 of the draft.  Removed some
sections as well to focus the draft. Next draft will be last-called.
Questions have been raised on Linux and GPL - answer is that it is just
a reference implementation. Jamal is working on taking Netlink, and
extending it to meet the ForCES requirements.

2) ForCES Requirements(draft-ietf-forces-requirements-02.txt)
by Margaret Wasserman, Wind River

Margaret presented the latest requirements draft, which is getting
close to last call. She asked how many people had read the draft
(about half of folks in room). Changes:
- Added Architectural requirement for High Availability (HA)
- Added a Management mechanisms section
- Removed high-level, low-level model, and switched instead to listing
  the requirements of the FE Model (with the understanding that the FE
  Model will be specificed in a separate document).
- Updated the protocol requirements section. Added text on CE-FE
  communication and for elements joining.
- Added a command bundling feature, with all-or-nothing semantics
- Adding details on what Query Statistics are (this did not make it in
  to 02 but will be in the next draft, 03)
- Questions

Comments from Jon Sadler:
  1) part of doc seems to have troubles with tunnels.
  2) don't see all the issues coming out regarding stack partitioning.
     Imagine an FE that can do tunnel termination.  there seem to be
     issues with stack partitioning
  3) Currently the document only talks about IPv4/6. Should be more
     neutral
Jonathan agreed to send these comments to the list.

Plan: issue a v3.  After v3 out, hoping last call, will ask chairs to
last-call the document.  David: we tried to last-call the last draft

3) ForCES Applicability Statement (draft-crouch-forces-applicability-01.txt)
by Mark Handley

David explained that the Applicability Statement is now an official WG
document.

Mark explained that he will re-submit the document immediately after this
IETF with the WG document name (draft-ietf-forces-applicability-00.txt).
Mark described "what is an applicability statement"
- a kind of "anti-requirements"
- A little like lower and upper bounds
- Normally an applicability statement is only produced toward the end
  of the process
Mark explained what has changed:
- Diagnostics
- Redundancy:  now included a short section saying whilst we're not
  trying to rule out. Mark claimed this generally reflects consensus.

Joel Halpern:  requirements says "high-availability is solving the
problem".  Seems to be wrong in Requirements/Applicability documents
to prohibit a solution.
Mark:  ForCES won't be the way to do CE-FE redundancy.
Joel:  is High-Availability part of the problem? AS draft should
       not preclude CE redundancy.
Mark:  divide the problem up into manageable chunks.

Margaret:  need to solve High-Availability problem, and need to solve
what is Requirements vs. Applicability problem/

David:  post problems to the list:  should High Availability be in the
scope?

Close and Very Close definitions: need to be rewritten. The goal was
to get people to think carefully about the problems.

Conclusions
- Reflect what the protocol designers view what the protocol is for.
- Meant to help people think through the failure modes.  Clear that
  the text now does not do that.

Comment from Mic:  no talk about the motivation.  What is the protocol
intended for.  What is the motivation for this work. The original BOF
talked about it, but not much now. Mark agreed to add text on that.

Howard:  is there an opening for the CE-CE protocol?  Answer: no

Avri: too many limitations right from the start. Until we have a
      protocol we have nothing to talk about in terms of applicability.
      Too early to talk about applicability statement. Need to solidify
      requirements, framework, protocol first.

Mark: it is the result of IESG/etc saying we need bounds up front to
      make progress

Conclusions: need to get alignment between AS and requirements on
the following topics:
- high availability
  - Jamal: a protocol like COPS does it
- fate sharing
  - what should be done if CE or FE goes down.
    Conclusion: study hitless restart discussion from the OSPF WG.
    Partial operation of an FE will be needed.
- capability exchange

4) ForCES Architectural Framework (draft-anderson-forces-arch-00.txt)
by Lily Yang,

Lily presented an individual contribution.  David asked that the WG
consider whether this should eventually be a ForCES wg document.  New
in this draft:  removed definitions section (refer to the terminology
in the requirements document).  Lily showed a diagram showing the
entities of ForCES, and what is in scope, and what is out of scope.
Described the following pieces of the architecture
- Pre-association Phase (out of scope for ForCES)
- Post-association Phase
- Association Re-establishment:  need to re-establish.

Question:  scope of WG - like GSMP?  GSMP controls MPLS label
switching.  This is packet-based forwarding, GSMP is
connection-oriented.  With MPLS, .  Asked us to review the GSMP
Avri:  quite possible that people ewill take GSMP and propose additions
to is. Need requirements before we pick a protocol

Consensus was reached that it is a good idea to have a framework
document.

5) Forwarding Element Model and (draft-gopal-forces-fact-00.txt)
   ForwArding and Control ElemenT (FACT) Protocol
   (draft-gopal-forces-femodel-00.txt)
by Ram Gopal

Ram presented a draft on a FE model. He introduced the building
blocks and their functions. The building blocks represent the
data path. He used to DiffServ as an example.

Joel:  This DiffServ models was not intended to used as an
       implementation. Capabilites are very tricky to handle.

Jonathan Sadler:  What about IS-IS?  Answer:  encapsulate it.
                  What about capabilities of Ingress/Egress?
Jamal: Why are BER are used instead of TLV's. He just picked
       one but TLV could be used as well

Ram is looking for contributers to his draft.

Conclusions
-----------

Agreed to
- Netlink informational draft:  RFC it in July 2002
- Discuss High Availability on the list
- Sync up the requirements and applicability statement before requirements
  foes last call
- Applicability statement will stay open for a while,
- Want a working group document on Framework
- FE Model and FACT:  proposing coming a WG document, or look for
co-authors.
- No model draft was made a WG document
- Howard: will post references to the BMWG work to the list.

List and Archive Info
---------------------

General Discussion:forces <at> peach.ease.lsoft.com
To Subscribe: listserv <at> peach.ease.lsoft.com
In Body: subscribe forces (your name)
Archive: http://peach.ease.lsoft.com/archives/FORCES.html

FW: DARPA Active Networks Conference and Exposition (DANCE)

[David: Forwarded due to email address mismatch - will be fixed asap.]

-----Original Message-----
From: Jon Crowcroft [mailto:Jon.Crowcroft <at> cl.cam.ac.uk]
Sent: Sunday, April 07, 2002 12:41 AM
To: Forwarding and Control Element Separation
Cc: Jon.Crowcroft <at> cl.cam.ac.uk
Subject: Re: DARPA Active Networks Conference and Exposition (DANCE)

In message <3CAFF6C6.46AAA189 <at> degree2.com>, Alistair Munro typed:

 >>The last time I looked at active networking, it was more concerned with
 >>distributed processing, not forwarding. An active network element does
 >>processing more than it does forwarding; the languages and protocols
 >>address the problem of task mobility, AAA, object naming and location;
 >>i.e. mainly things above the communications domain.

 >>As far as solving our current problems goes, could you give us a brief
 >>guide to how active networks address some of the issues of the
 >>requirements and applicability statement that we are trying to write? A
 >>few URLs would suffice.

lots of darpa funded actvie nets  projects are erxplicitly about
forwarding! see
http://www.cs.ucl.ac.uk/research/radioactive/
for example.....and
http://www.cs.ucl.ac.uk/research/alpine/references.html
esp. references....