Subject: [forces] Fwd: Comments on ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06

From: "[email-masked]" <[email-masked]>
Date: Mon, 22 Apr 2013 19:23:51 -0400

Comments on the CE HA draft

ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06

( http://www.ietf.org/id/draft-ietf-forces-ceha-06.txt )

(1)Please avoid using Acronyms in the Abstract

(2)If you have used an XML validator, include the results of validation of
the XML files in the Appendix of the draft

(3)Change the Title of Section 1 to “Definitions and Acronyms”

(4)Add a list of Acronyms in updated Section 1; CE, CCM, FE, FEM, NE, HB,
TML, … etc.

(5)Add RFC 2119 under the “Normative” ref. Section

(6)For subsections in Sec. 2, 3, and 4, use i, ii, iii, etc. or a, b, c,
etc. instead of 1, 2, 3, and so on

(7)Replace “High Availability” by “HA” throughout the draft

(8)In Sec. 4.1, under 1, please consider adding +6, +7, and +8,  and
Reserve these for future use

(9)In Sec. 4.1 under 2, please consider adding, +3, and Reserve it for
future use

(10) The are many partially complete or incomplete sentence in the draft
... PLEASE correct these sentences … a few examples are as follows..

(a) In Section 3.1 of this document draft, we discuss further details
of these knobs. further

      (b) It should be noted that in this default setup, which

      MUST be implemented by CEs and FEs needing requiring HA, the Fr
plane is out of scope (and if available is proprietary to an
implementation).

(c ) Figure 3 illustrates the defined state machine that facilitates

   connection   the recovery of connection state.

(d) To put the two together, if a path to a primary CE is down, the TML

   would take care of failing over tohelp recover from a failure using
a backup path, if one is available.

(e)

  +  0 (No HA Mode)represents that tThe FE is not running in HA mode

           +  1 (HA Mode - Cold Standby) represents that tThe FE is in
HA mode cold Standby

           +  and 2 (HA Mode - Hot Standby) represents that tThe FE is
in HA mode hot Standby

Thanks.

Best.

Bhumip

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 22 Apr 2013 20:01:38 -0400

Thanks Bhumip.
The authors will look at these and likely publish a new version.
We really want to move forward and publish this document.

cheers,
jamal

On Mon, Apr 22, 2013 at 7:23 PM, [email-masked] <[email-masked]>wrote:

> (2)If you have used an XML validator, include the results of validation
> of the XML files in the Appendix of the draft
>
> (a) In Section 3.1 of this document draft, we discuss further details of these knobs. further
>
>
>
>       MUST be implemented by CEs and FEs needing requiring HA, the Fr plane is out of scope (and if available is proprietary to an implementation).
>
>
>
>    would take care of failing over tohelp recover from a failure using a backup path, if one is available.
>
>
>
> (e)
>
>            +  1 (HA Mode - Cold Standby) represents that tThe FE is in HA mode cold Standby
>
>
>
>            +  and 2 (HA Mode - Hot Standby) represents that tThe FE is in HA mode hot Standby
>
> Thanks.
>
> Best.
>
> Bhumip
>
>

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Tue, 30 Apr 2013 17:02:11 +0300

Greetings,

Thank you very much for your comments.

These changes will appear on the next version of the document.

Please see inline for responses.

Regards,

Evangelos Haleplidis.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, April 23, 2013 2:24 AM
To: [email-masked]
Cc: [email-masked]
Subject: [forces] Fwd: Comments on ForCES Intra-NE High Availability,
draft-ietf-forces-ceha-06

 

[ΕΗ] Ok.

[ΕΗ] We added a text stating: "The xml has been validated against the schema
defined in the [RFC5812]."

(3)Change the Title of Section 1 to "Definitions and Acronyms"

TML, . etc.

[ΕΗ] Added most of your suggestion. Copied them from previous RFCs.

(5)Add RFC 2119 under the "Normative" ref. Section 

[ΕΗ] Done, thanks.

[ΕΗ] Is this needed?

(7)Replace "High Availability" by "HA" throughout the draft

[ΕΗ] Done.

(8)In Sec. 4.1, under 1, please consider adding +6, +7, and +8,  and Reserve
these for future use

[ΕΗ] For 8 & 9, my current thinking is that they are unnecessary. Tampering
with the FEPO special values may result in non-interoperable implementations
of ForCES. Changes for these special values should be done within the ForCES
working group.

Why do you think this is required? Anyone else's thoughts on this?

(10) The are many partially complete or incomplete sentence in the draft ...
PLEASE correct these sentences . a few examples are as follows..

(a) In Section 3.1 of this draft, we discuss further details of these knobs.

[ΕΗ] I will keep the "document" word, as it is more generic. When the draft
becomes RFC, it would be best to have that word as document. Made the rest
of the change though.
 
      (b) It should be noted that in this default setup, which
      MUST be implemented by CEs and FEs requiring HA, the Fr plane is out
of scope (and if available is proprietary to an implementation).
 
(c ) Figure 3 illustrates the defined state machine that facilitates
     the recovery of connection state.
 
(d) To put the two together, if a path to a primary CE is down, the TML
   would help recover from a failure using a backup path, if one is
available.
 
(e)
  +  0 (No HA Mode)represents that the FE is not running in HA mode
 
           +  1 (HA Mode - Cold Standby) represents that the FE is in HA
mode cold Standby
 
           +  and 2 (HA Mode - Hot Standby) represents that the FE is in HA
mode hot Standby
 
 [ΕΗ] Made these changes, thanks.

Thanks.

Best.

Bhumip

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 30 Apr 2013 10:19:21 -0400

On Tue, Apr 30, 2013 at 10:02 AM, Haleplidis Evangelos <[email-masked]>wrote:

> Reserve these for future use****
>
> future use  ****
> *[ΕΗ] For 8 & 9, my current thinking is that they are unnecessary.
> Tampering with the FEPO special values may result in non-interoperable
> implementations of ForCES. Changes for these special values should be done
> within the ForCES working group.*
>
> *Why do you think this is required? Anyone else’s thoughts on this?*
>

Agree with Evangelos.
There is no need to reserve fields for future use. It will infact cause
interop problems if someone
starts using those fields.

cheers,
jamal