(Ram Gopal | 1 Aug 15:15 2003
Picon

Re: framework draft v07 uploaded to IETF

Good - I agree.
Regards
Ramg

> -----Original Message-----
> From: ext Yang, Lily L [mailto:lily.l.yang <at> intel.com]
> Sent: Wednesday, July 30, 2003 12:52 PM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: Re: framework draft v07 uploaded to IETF
> 
> 
> ------ Apologize if this is duplicte, I didn't see my first 
> posting coming back to me, so I thought it might not get 
> through. ---------
> 
> Hi, Jamal --
> To answer your questions:
> 
> 1) It was a conscious decision that framework does NOT 
> dictate transport. The first two paragraphs in Section 7.2 
> make it very clear:
> 
>     "The requirements document [3] suggested that ForCES 
> protocol should 
>     support reliability over Fp interface, but no particular 
> transport 
>     protocol is yet specified for ForCES. This framework 
> document does 
>     not intend to specify the particular transport either, and so we 
>     only provide recommendations and guidelines based on the existing 
(Continue reading)

(Ram Gopal | 1 Aug 15:35 2003
Picon

Re: framework draft v07 uploaded to IETF

Hello Jamal,

Comments are inline. 

> I think it would be simpler to just break it explicitly into:
> - No security and say when this is not recommended

<Ramg>

We have mentioned that even in "No secuirty case" its up to the administrator to 
choose security option.

<Ramg>

> - simple security (example some initial authentication maybe even
> password based)
> - Data Integrity; make the recomendation on what would be a good thing
> to use.For example i think OSPF like signature with proper
> infrastructure would fit here.

<Ramg>
Let me try to answer in two parts, 

1)
w.r.t OSPF, OSPFv2 had Authentication header inbuilt in the protocol itself. OSPFv3 runs on IPv6 and it
leverage 
integrity service from IPv6 (AH). OSPFv3 doesn't have  integrity service inbuilt.

Since ForCES requirement states that for IPv4 and IPv6 its better to use IPsec and if we follow OSPF
mechanism operator 
(Continue reading)

Putzolu, David | 1 Aug 18:39 2003
Picon

ForCES Requirements Issue summary: Vague use of the word hop

All,

We have rough consensus on the ForCES requirements
as they currently stand.  The vague use of the word "hop"
came up as a final issue, and the sense of the list
that I am seeing is that it should be clarified to be
"L3 routing hop".  This can be done during the author's 
48 hour period from the RFC editor.

Hormuzd, please prepare a note for the RFC editor that
specifies where the changes are that will be made to address
the hop issue.  In the meanwhile,  I am asking our ADs to
take the ForCES requirements document to IESG review during
the next scheduled IESG conference call.

Thanks,
David

Steven Blake | 1 Aug 22:17 2003

Re: WG question: Accept draft-yang-forces-model-02.txt as WG doc?

On Fri, 2003-07-25 at 19:22, Putzolu, David wrote:

> All,
>
> At the 57th IETF meeting last week the authors of
> draft-yang-forces-model-02.txt asked that the draft
> be made a working group document.   The sense of
> the room was that it should be.   I would like
> to see if there is consensus on the list on this.
>
> Please indicate by August 1st whether you feel that
> the following draft is ready to become a ForCES
> working group document:
>
> http://www.ietf.org/internet-drafts/draft-yang-forces-model-02.txt
>
> Note that becoming a working group document does
> not finalize the document -  it means that the
> general direction and structure of the document
> is accepted as correct, and that the working
> group is willing to adopt is as the basis for
> further work.  If accepted as a WG document, it
> will remain a draft and will be subject to
> change based on feedback from the participants
> of the working group.

What is the expected disposition of this document?  Informational RFC?

ForCES will have to produce a standards-track RFC that defines the
schema for the forwarding model, along definitions on how it is
(Continue reading)

Yang, Lily L | 2 Aug 02:04 2003
Picon

Re: WG question: Accept draft-yang-forces-model-02.txt as WG doc?

Hi, Steve --

You raised a good point about what will come out of the FE model effort. At Vienna, a group of us (Lily Y., Joel,
Ram G, Zsolt, Hormuzd, Jon Maloy, David Putzolu) interested in FE model gathered together discussing the
model work. One of the topic was on disposition of the documents, and we envisioned that there would be two
standard documents coming out of this FE model effort in the near term: first one will be based on the
current document (design consideration and basic concept) plus the XML schema for the base model to
define how to model an LFB class (Zsolt&Steve's contribution can be a good starting point for this); the
second one will be the actual definitions of important classes for the necessary LFBs (forwarding,
DiffServ, etc.). Both of these should become standard track RFCs eventually.

Now there were different opinion on whether or not the first document should be further splitted into two,
one being information RFC (on design consideration & basic concept) while the other one (XML schema) as
standard RFC. Some prefer them to be combined while others prefer to separate them. My take is that it is too
early to debate on this. Lets focus on the content first and then we will figure out the packaging later.

Does this answer your question?

Thanks,
Lily

> -----Original Message-----
> From: Steven Blake [mailto:slblake <at> torrentnet.com]
> Sent: Friday, August 01, 2003 1:18 PM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: Re: WG question: Accept draft-yang-forces-model-02.txt as WG
> doc?
> 
> 
> On Fri, 2003-07-25 at 19:22, Putzolu, David wrote:
(Continue reading)

Jamal Hadi | 4 Aug 03:47 2003

Re: framework draft v07 uploaded to IETF

Hi Ram,

Your security "recommendations" do make certain assumptions, the most
important being that CE<->FE is a unicast connection. With TLS you go
further to make assumption of need for TCP. Now this may be fine for FACT
but it is not for Netlink2 (because we could be running either as unicast
or multicast). And you cant make "recommendations" if we havent decided on
the protocol - unless you can tell me how to run TLS using multicast. This
is why i called this a show stopper.

So what i am asking for is objective text which encompases both points of
views. For example, no problem with IPSEC ESP being "recommended" because
that is fine for multicast as well - but it would make sense to see
generic text which covers both uni and multicast in that section.
[I have reservations about TLS but i am willing to ignore its presence. I
think it would be anti-progress (if such a word exists) on my part to say
in addition to TLS lets also "recommend" a security mechanism that would
work well only with multicast.]

Maybe the chairs could invite someone else to write that text since we
have been arguing about this for a long time - and i sincerely think it is
a showstopper. I dont think you are being intentionaly difficult - i just
think you are in one zone and i on another.

And btw, have we finally reached an agreement that we cant run Forces over
Ethernet directly? If no, what security mechanisms are you proposing that
cover both uni and multicast?

cheers,
jamal
(Continue reading)

Putzolu, David | 4 Aug 17:40 2003
Picon

Re: framework draft v07 uploaded to IETF

Hi Jamal.

ForCES will run between CEs and FEs.  The decision
of actual hardware components used to construct the
CEs and FEs in a ForCES-compliant network element
is up to the implementer.  Building CEs and FEs using
general purpose processors is certainly a possible 
implementation.  One could even imagine building a 
FE and a CE on a single processor in separate 
processes using a localhost socket, which, while odd,
should not be precluded in ForCES.  This would be 
the ultimate "very close" scenario!

-David

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:hadi <at> znyx.com] 
> Sent: Monday, July 28, 2003 1:04 AM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: Re: [FORCES] framework draft v07 uploaded to IETF
> 
> 
> Alex,
> 
> If you dont have much processing horsepower, true.
> I have basic PPC 8245 on the line cards here(which may be 
> considered by some to be "powerful") and i think in a small setup i
should 
> be able to happily use them as a loosely coupled CE while the line
card fabric is
(Continue reading)

Steven Blake | 4 Aug 17:56 2003

Re: WG question: Accept draft-yang-forces-model-02.txt as WG doc?

On Fri, 2003-08-01 at 20:04, Yang, Lily L wrote:

> Hi, Steve --
>
> You raised a good point about what will come out of the FE model effort. At
> Vienna, a group of us (Lily Y., Joel, Ram G, Zsolt, Hormuzd,
> Jon Maloy, David Putzolu) interested in FE model gathered together
> discussing the model work. One of the topic was on disposition of the
> documents, and we envisioned that there would be two standard
> documents coming out of this FE model effort in the near term: first
> one will be based on the current document (design consideration and
> basic concept) plus the XML schema for the base model to define how to
> model an LFB class (Zsolt&Steve's contribution can be a good starting
> point for this); the second one will be the actual definitions of
> important classes for the necessary LFBs (forwarding, DiffServ, etc.).
> Both of these should become standard track RFCs eventually.
>
> Now there were different opinion on whether or not the first document
> should be further splitted into two, one being information RFC (on
> design consideration & basic concept) while the other one (XML schema)
> as standard RFC. Some prefer them to be combined while others prefer
> to separate them. My take is that it is too early to debate on this.
> Lets focus on the content first and then we will figure out the
> packaging later.
>
> Does this answer your question?

Yes, thanks.  I think your draft should be adopted as the base to move
forward from.

(Continue reading)

Jamal Hadi Salim | 4 Aug 19:04 2003

Re: framework draft v07 uploaded to IETF

Hi David,

I realized afterwards the architecture allows it.
For completion sake, i was refering to "legacy" standalone,
typically 1U form factor, hardware based L2/3 switches - typically these
devices have a CPU and a switch fabric of sorts. CPU acts as the CE in
each of these standalone devices. I refered to them as line cards to
simplify the question.
If i put a rackmount of such devices Forces allows me to liberate them
from a management point of view.

cheers,
jamal

On Mon, 4 Aug 2003, Putzolu, David wrote:

> Hi Jamal.
>
> ForCES will run between CEs and FEs.  The decision
> of actual hardware components used to construct the
> CEs and FEs in a ForCES-compliant network element
> is up to the implementer.  Building CEs and FEs using
> general purpose processors is certainly a possible
> implementation.  One could even imagine building a
> FE and a CE on a single processor in separate
> processes using a localhost socket, which, while odd,
> should not be precluded in ForCES.  This would be
> the ultimate "very close" scenario!
>
> -David
(Continue reading)

Tal Lavian | 5 Aug 00:49 2003

Re: framework draft v07 uploaded to IETF

Hi Jamal,

This is Tal Lavian from Nortel. I was following this work, however, now,
I'm up to new things.
How can I remove myself from this mailing list?

Tal

At 10:04 AM 8/4/2003, you wrote:
>Hi David,
>
>I realized afterwards the architecture allows it.
>For completion sake, i was refering to "legacy" standalone,
>typically 1U form factor, hardware based L2/3 switches - typically these
>devices have a CPU and a switch fabric of sorts. CPU acts as the CE in
>each of these standalone devices. I refered to them as line cards to
>simplify the question.
>If i put a rackmount of such devices Forces allows me to liberate them
>from a management point of view.
>
>cheers,
>jamal
>
>On Mon, 4 Aug 2003, Putzolu, David wrote:
>
> > Hi Jamal.
> >
> > ForCES will run between CEs and FEs.  The decision
> > of actual hardware components used to construct the
> > CEs and FEs in a ForCES-compliant network element
(Continue reading)


Gmane