Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - May 10-24

From: Shyam prasad <[email-masked]>
Date: Thu, 16 May 2002 02:29:11 -0400

Alex and Hormuzd,

Thanks for your responses. Please see my comments below:

> -----Original Message-----
> From: Khosravi, Hormuzd M [mailto:[email-masked]]
> Sent: Thursday, May 16, 2002 3:07 AM
> To: [email-masked]
> Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t -
> May 10-24
>
>
> Thanks for the comments, Alex.
> I'll try to answer the 3rd question below.
>
> Hormuzd
>
> Shyam prasad wrote:
>
> > Hi all,
> >
> > I have a few questions/comments on the draft. I am new to
> this group.
> Sorry
> > if the questions are elementary ones.
> >
> > 1. Are CEs and FEs expected to be part of a single system?
> If the answer
> is
> > yes, isn't implementing security mechanisms such as
> IPSec/IKE for ForCES
> > protocol an overkill?
> >
>
> Section 7.4 (Multihop)  states that CE and FE may be
> seperated by more than
> one hop. This may justify use of IPSec/IKE.
>

The basic doubt still remains. CEs and FEs could be multiple hops away, they
could reside on multiple cards but are they components within a single box??

> >
> > 2. The requirements draft does not mention FE redundancy
> and failover. I
> > think FE redundancy support would involve certain amount of
> CE-FE control
> > messaging if CE is viewed as the master and FE, the slave.
> >
>
> See section 7.8 (CE Redundancy or CE Failover). I think this
> section also
> covers
>
> FE redundancy/failover.

Here's the text under 7.8 :
"The ForCES protocol MUST support mechanisms for CE redundancy or CE
   failover. This includes the ability for CEs and FEs to determine
   when there is a loss of association between them, ability to restore
   association and efficient state (re)synchronization mechanisms. This
   also includes the ability to preset the actions an FE will take in
   reaction to loss of association to its CE e.g., whether the FE will
   continue to forward packets or whether it will halt operations."

Even if this section is intended to include the FE redundancy requirement,
it's not so obvious. Can it be stated explicitly? Or could you add another
section for FE redundancy?

>
> >
> > 3. Section 5, point #6 says that an FE MUST be able to
> asynchronously
> inform
> > the CE an increase/decrease in available resources or
> capabilities on the
> > FE. Can this requirement be extended to enable FEs to
> notify failures
> (port
> > failure, internal fault, etc.)?
> >
> [HK] This requirement & section 7 #13 is suppose to cover any failure
> notification
> by the FE. The example talks about change in the number of
> ports (port down
> event).

Great! But can the verbiage be changed to explicitly state that all failure
notifications are supported and not just "increase/decrease in available
resources".

Thanks.
Shyam

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 16 May 2002 08:04:42 -0400

On Thursday 16 May 2002 02:29, Shyam prasad wrote:

> The basic doubt still remains. CEs and FEs could be multiple hops away,
> they could reside on multiple cards but are they components within a single
> box??
>

I may have misunderstood what you are saying, but:
Do you see anything in the draft that precludes an NE being a single box? 

> section for FE redundancy?

Stating it explicitly opens a lot of rat holes, thats why it was taken away.
(look at the earlier drafts)
When protocol drafts show up, it will be stated explicitly.
Does the above generic text miss any failover mechanisms?

> notifications are supported and not just "increase/decrease in available

Can you be more specific? 

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Thu, 16 May 2002 10:13:29 -0500

Shyam,

Once a FE and its controlling CE are distributed in such a way that you need a
transport
protocol to carry the FORCes protocol messages between them, then you run the
risk of
exposing that comunication link to security attacks.  The risk grows with
physical separation
between the two.  But you are right; if  both CE and FE are in the same box,
then you may
not need an elaborate security scheme (section 7.4). However, there is nothing
that says they
must be in the same box. Remember, this is a "distributed" architecture.

Alex.