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

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

Hi Jamal,

Cut down to issues for debate...

>> 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?
>
> 3654 and 3746 talked about the protocol in generalities.
> 5810 talks about the protocol. It came later and is only added
> there for sake of clarity of what we mean when we say PL.

I have no issue with this text, per se. However, the top of the section is
pretty clear that it is supposed to be a restatement of 3654 and 3746. You can't
have this cake and eat it.

>> 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?
>
> Ok, we'll review, however, note that there is intent in this document 
> to provide clarity in what is prescribed in 5810. 
> This is stated in Section 2.1, to quote:
>
> "
> The problem scope addressed by this document falls into 2 areas:
>   1.  To describe with more clarity (than [RFC5810]) how current cold-
>       standby approach operates within the NE cluster.
>   2.  To describe how to evolve the [RFC5810] cold-standby setup to a
>       hot-standby redundancy setup to improve the failover time and NE
>       availability.
> "
[snip]
> The goal is for someone reading 5810 and not getting clarity on the
cold-standby HA\
> to read this document instead. I think the part where you say "purely
informational"
> may be overriding that intent.

OK. So it sounds (by point 1) like you *really* intend to update 5810 by
providing new normative text for cold-standby. If that is the case, let's go for
it full-steam ahead!
- metadata for updates 5810
- note in Abstract "This document updates RFC 5810 by doing foo"
- paragraph in Introduction to explain the update
- note in this section to say that this is a new normative description that
updates 5810

>> 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.
>
> Depends. I actually have seen the sticky prioritization scheme you have
described being
> requested for, but that desire subsidises after we describe that we  provide
for the master
> CE to change the mastership if the older CE shows  up again i.e whatever the
FE does
> it could be overriden by the CE. 

OK, if it is a deliberate decision.

Thanks for the work,
Adrian