[forces] AD Review of draft-ietf-forces-ceha

["Adrian Farrel" <[e-mail]>]

Hi,

I have done my AD review of your document and see nothing major to hold
it back, but there are a large number of nits and a few petty questions.
We have a responsibility to send the I-D to IETF last call in the best 
possible shape so that it gets a good review.

Therefore, I have put the I-D into "Revised I-D Needed" state and will 
issue IETF last call when I see a new revision.

Thanks for the work,
Adrian

===

Section 1

Need to fix the 2119 boilerplate to include a reference to [RFC2119]

---

Section 1

OLD
   The following definitions are taken from [RFC3654]and [RFC3746]:
NEW
   The following definitions are taken from [RFC3654] and [RFC3746].  
   They are repeated here for convenience, but the normative definitions
   are found in the referenced RFCs.
END

---

Section 1

   o  ForCES Protocol -- The protocol used at the Fp reference point in
      the ForCES Framework in [RFC3746].

You need to explain what "Fp" is.

---

Section 1

   o  ForCES Protocol Layer (ForCES PL) -- A layer in the ForCES
      architecture that embodies the ForCES protocol and the state
      transfer mechanisms as defined in [RFC5810].

How can this definition come from 3654 or 3746 when it has a reference to
5810?

---

Figure 1

Maybe more normal to use "CEn" rather than "CEN"

---

Section 2

   The master CE controls the FEs via
   the ForCES protocol operating in the Fp interface.

s/in/on/

---

Section 3

   To achieve CE High Availability (HA), FEs and CEs MUST inter-operate
   per [RFC5810] definition which is repeated for contextual reasons in
   Section 3.1.

While you are repeating some of the material from 5810, you are also
restating some of it in new words, and adding text.

This gives a real problem with determining where the normative 
definition sits. We have to fix this!

Can you determine which sections are informational for this document and
which contain new text? 

Possibly the whole of Section 3 is just informational. If this is the
case you can replace the text quoted above with the following:

   To achieve CE High Availability (HA), FEs and CEs MUST inter-operate
   per [RFC5810].  The normative description of cold standby for CE HA
   is provided in [RFC5810].  This section provides a more wordy
   description of the procedures and is purely informational.  In the 
   event of any discrepancies between this text and that in RFC 5810,
   the text in RFC 5810 takes precedence.

---

Figure 2

Will it be obvious to the reader of this document what is meant by
"Asso Estb,Caps exchg"

---

Section 3.1.1

"CEID" is used without expansion. Although sometimes I find "CE ID" for
example in 3.1.2.

---

Section 3.1.1 has

   The FE connects to the CE specified on FEPO CEID component.  If it
   fails to connect to the defined CE, it moves it to the bottom of
   table BackupCEs and sets its CEID component to be the first CE
   retrieved from table BackupCEs.

This is not a problem, but is unusual. In many redundancy cases, the
primary object remains the favorite even when it has failed so that
when there is a restoration opportunity (such as a failure of the new
primary) it will resume its position as primary.


The question here is perhaps whether there is any distinction between
CEs except their role as primary or backup.

---

Figure 3 has "CEFTI" without explanation.

---

Section 3.1.1 has

   If the FE's FEPO CE Failover Policy is configured to mode 1, it
   indicates that the FE will run in HA restart recovery.  In such a
   case, the FE transitions to the Not Associated state and the CEFTI
   timer [RFC5810] is started.  The FE MAY continue to forward packets
   during this state.

This use of "MAY" implies to me that it is at least as common that the
FE does not forward packets in this state. Is that the intention?

---

Section 3.1.1

"HB" is used without expansion.

---

Section 4.2

"CEHB" and "FEHB" are used without expansion

---

Need to fix the line-length problems in Figure 4

---

Figure 5 implies that the association with the primary CE is the first
association formed. Is this a requirement?

---

Section 5 needs to give clear and unambiguous instructions to the IANA.
It seems that the text in Section 5 is currently a placeholder for the
correct text.

The shepherd write-up notes the need for this section to be reviewed by 
"ForCES IANA experts". If these people are not to be found in the ForCES
working group, then they exist nowhere. So the WG needs to look at this
section and work out what it should really say.

---

Section 6 is too sparse.

The Security Section in RFC 5810 is sound, so that is not the issue.
However, in considering HA you are considering a more complex scenario
where each CE must have its communications secured with the FE, and each
CE must be authenticated to the FE. That needs discussion.

Additionally, can the system be disrupted by simulating CE failure or by
disrupting CE-FE communications?

---

Section 7.2

I think 5812 is used in a normative way.