Subject: Re: [trill] Comments on draft-ietf-trill-directory-assist-mechanisms-00

From: Donald Eastlake <[email-masked]>
Date: Tue, 8 Apr 2014 16:49:25 -0400

So, I'm working on editing
draft-ietf-trill-directory-assist-mechanisms. If the discussions on
the list were followed literally, there would be three Push Directory
relevant bits in the ESADI-Parameter APPsub-TLV:  PSH (announcing that
the originator is a Push Directory Server), COP (announcing that the
originator has pushed complete data and given enough time for it to be
distributed), and some new bit TBD (announcing that the originator is
a push directory in passive mode).

But these bits could be inconsistent in various ways and seem like a
bit of a mess. What do you do if both Passive and Complete Push are 1?
Etc.

I think it would be better to have a two-bit field as follows:

00 - not a Push Directory Server
01 - Push Directory Server in Passive Mode
10 - Push Directory Server in Active Mode but not complete
11 - Push Directory Server in Active Mode that has pushed complete data

This seems to be all the information you want to send and does not
have any inconsistent states.

So, I'm planning on going with two bits unless someone objects.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]
Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Wed, Mar 26, 2014 at 8:05 AM, hongjun ZHAI <[email-masked]> wrote:
> Hi Donald,
>
> Thanks for your response. My response is inserted in-line.
>
>
> Thanks,
> Hongjun Zhai
> -----------------------------------------------------------------------------
> Yuhuatai District, Nanjing City, People's Republic of China
> Mobile: +086-025-5287-7345
> Email: [email-masked]
> -----------------------------------------------------------------------------
>
>
>>
> On Wed, Mar 26, 2014 at 2:16 AM, Donald Eastlake <[email-masked]> wrote:
>>
>> >
>> Hi Hongjun,
>> >
>> >
>> On Sun, Mar 16, 2014 at 11:24 PM, <[email-masked]> wrote:
>> >
>> >
>> >
>> > Hi Donald,
>> >
>> >
>> >
>> > Thanks for your response. My comments is inserted below.
>> >
>>
>> >
>> I'll just respond below where we still seem to not agree...
>> >
>> >
>> >
>> >
>> Thanks,
>> >
>> > Hongjun Zhai
>> >
>> > ---------------------------------------------
>> >
>> > Add: No.68 Zijinghua Road, Yuhuatai District,
>> >
>> > Nanjing City, R.P. China, 210012
>> >
>> >
>> >
>> > Tel: +86 025 52877345
>> >
>> > Email: [email-masked]
>> >
>> > ---------------------------------------------
>> >
>> >
>> >
>> > Donald Eastlake <[email-masked]>
>> >
>> > 发件人:  "trill" <[email-masked]>
>> >
>> >
>> >
>> > 2014-03-16 11:51
>> >
>> >
>> >
>> > 收件人
>> >
>> >
>> hongjun ZHAI <[email-masked]>
>> >
>> >
>> 抄送
>> >
>> > [email-masked], "[email-masked]" <[email-masked]>, Radia Perlman
>> > <[email-masked]>, Liyizhou <[email-masked]>, [email-masked]
>> >
>> > 主题
>> >
>> >
>> Re: [trill] Comments on
>> draft-ietf-trill-directory-assist-mechanisms-00
>> >
>> >
>>
>> >
>> >
>> > Hi,
>> > >
>> >
>>
>> > >
>> >
>> Thanks for your comments. See below...
>> > >
>> >
>>
>> > >
>> >>
>> On 3/7/14, hongjun ZHAI <[email-masked]> wrote:
>> > >>
>> >
>> Hi authors,
>> > >>
>> >
>>
>> > >>
>> >
>> I have some comments on the state transition of Push Directory server.
>> > >>
>> >
>>
>> > >>
>> >
>> 1. According to the current state transition table, when the event 4
>> > >>
>> >
>> occurs,the server will change to Reducing state from the current
>> > >>
>> >
>> Complete or Reducing state. But I think that transition is
>> > >>
>> >
>> wrong. Indeed, when the event 4 occurs, the server should change to
>> > >>
>> >
>> Passive state even if it is now in Complete/Reducing
>> > >>
>> >
>> state. Otherwise, the server will not be able to change to Passive
>> > >>
>> >
>> state even the Activate condition is not met. Right?
>> >
>> >
>>
>> > >
>> >
>> The idea is that the Push Directory server needs to stay in the
>> > >
>> >
>> Reducing state long enough to be reasonably sure that any clients know
>> > >
>> >
>> that it is now longer claiming to be complete. Thus, the only safe way
>> > >
>> >
>> to transitiion out of the Reducing state is the passage of enough
>> > >
>> >
>> time, which is event 7.
>> >
>> >
>>
>> >
>> >
>>
>> Since event 4 is "The server determines that the Pacify Condition is met",
>> >
>> >
>> for an Push Directory server that is in Complete/Reducing state, I think
>> >
>> >
>>  it should transition to Passive state at last if *event 4 occurs and then
>> >
>> >
>>  event 7 occurs later* but there is no event 3 or 5 (the Active Condition
>> >
>> >
>>  is met) occurring between event 4 and event 7.  But according to the
>> current
>> >
>>
>> >
>> I agree. It should transition to the Passive state after event 4
>> >
>> occurs and then event 7 occurs.
>> >
>> >
>> >> state transition table (see the last two columns in the last row in the
>> >> following table), I am not sure its final state will become Passive
>> >> after
>> >> amount of time (i.e., event 7 occurs).
>> >>
>> >>       Event || Down  |Passive   |Active  |Completing|Complete|Reducing|
>> >>       ------++-------+----------+--------+----------+--------+--------+
>> >>          1  ||Passive|Passive   |Active  |Completing|Complete|Reducing|
>> >>          2  || Down  | Down     |Passive |Passive   |Reducing|Reducing|
>> >>          3  || Down  |Active    |Active  |Active    |Reducing|Reducing|
>> >>          4  || Down  |Passive   |Passive |Passive   |Reducing|Reducing|
>> >>          5  || Down  |Completing|Complete|Completing|Complete|Complete|
>> >>          6  || Down  |Passive   |Active  |Active    |Reducing|Reducing|
>> >>          7  || Down  |Passive   |Active  |Complete  |Complete|Active  |
>> >
>> >
>> Yes, the table is wrong. The problem is that there are two different
>> >
>> reasons for transitioning from Complete to "Reducing". The table is
>> >
>> correct if the Push Directory transitioned to Reducing for events 6 or
>> >
>> 3. However, if the Push Directory transitioned to Reducing for events
>> >
>> 2 or 4, the a later event 7 should move it to Passive, not to Active.
>> >
>>
>> >
>> I don't immediately see any way to fix this with the style of state
>> >
>> machine in the draft except to split Reducing into two different
>> >
>> states, perhaps called "Uncompleting" and "Passifying". From the
>> >
>> Complete state, 3 and 6 would take you to Uncompleting and then 7
>> >
>> would take you to Active. While, from the Complete state, 2 and 4
>> >
>> would take you to Passifying and then 7 would take you to Passive...
>
>
>   OK, if the idea behind Reducing state is required to
>   insist on, I think that it is a good idea to split
>   Reducing into two different states. After the splitting,
>   the state transition table might be as follows:
>
>  Event || Down  |Passive   |Active    |Completing|Complete
> |Uncompleting|Passifying|
>
> ------++-------+----------+----------+----------+------------+------------+----------+
>     1  ||Passive|Passive   |Active    |Completing|Complete
> |Uncompleting|Passifying|
>     2  || Down  | Down     |Passive   |Passive   |Passifying
> |Uncompleting|Passifying|
>     3  || Down  |Active    |Active    |Active
> |Uncompleting|Uncompleting|Completing|
>     4  || Down  |Passive   |Passive   |Passive   |Passifying  |Passifying
> |Passifying|
>     5  || Down  |Completing|Completing|Completing|Complete    |Complete
> |Completing|
>     6  || Down  |Passive   |Active    |Active
> |Uncompleting|Uncompleting|Passifying|
>     7  || Down  |Passive   |Active    |Complete  |Complete    |Active
> |Passive   |
>
>
>>> Furthermore, for a Push Directory server, when its state becomes Passive,
>>> I think it should, as soon as possible, flush its Directory data from
>>> the client switches that it has advertised when it was in
>>> Active/Complete/
>>> Completing/Reducing. And the most convenient way to do that is to have
>>> a flag bit set 1 in its update messages to tell its client switches to
>>> flush its advertised directory data locally in the related data labels.
>>> How about registering a new flag in the ESADI-Parameter APPsub-TLV Flag
>>> Bits
>>> for that purpose?
>   >
>>
>> >
>> I do not agree with that. The Push Directories make use of the ESADI
>> >
>> update mechanism which is simply the IS-IS reliable flooding
>> >
>> mechanism. How would this "flush flag bit" interact with the ESADI
>> >
>> purge mechanism and the different sequence numbers in different
>> >
>> fragments? What if a Directory server went Passive but then went
>> >
>> Active again quickly and, due to errors or propagation delays, some
>> >
>> clients got new LSP fragments from the newly Active Push Directory
>> >
>> Server before they got the old fragment zero update with the "flush"
>> >
>> flag?
>> >
>>
>> >
>> So, I don't like the idea of a "flush flag"; however, it might make
>> >
>> sense to have a "passive flag". If the Passive flag was set in the
>> >
>> ESADI-Parameters APPsub-TLV for a Push Directory Server, it would tell
>> >
>> clients to ignore any pushed data from that server. So, when a Push
>> >
>> Directory Server became Passive, it would set this flag, which is in
>> >
>> fragment zero and so would be flooded with somewhat higher priority.
>> >
>> It could then purge the data it had pushed when it was convenient to
>> >
>> do so.
>
>
> Well, the "passive flag" is a good idea, it interprets what I
>  really wanted to express.
>
>
>> >>> 2. ...
>>
>> >
>> >
>>
>> >
>> >
>> >> 3. When the event 2 occurs, why the states Complete/Reducing do not
>> >
>> >
>> >> transition to Passive/Passive as the Active/Completing states do? If
>> > >
>> >
>> > they transition to Passive, the Push Directory server can try to
>> > >>
>> >
>> clear the directory data it has advertised before it shuts down.
>> >
>> >
>>
>> >
>> >
>> > Similar to your point 1 above, it wants to have enough time that its
>> > >
>> >
>> clearing of the COP bit is communicated to its clients. If it
>> > >
>> >
>> immediately started withdrawing data, some client might think the data
>> >
>> >
>> > was still complete for a while and be confused by some data that had
>> > >
>> >
>> been withdrawn and was now missing.
>> >
>> >
>>
>> >
>> >
>> OK. Since the server will shut down at last and become data unreachable
>> >
>> >
>> to its client after event 2 occurs, its advertised data will be removed
>> >
>> >
>> by its clients after its data un-reachablity is found. I think it is
>> >
>> >
>> also OK for the state of the server to change to Reducing after event 2
>> >
>> >
>> occurs.
>> >
>>
>> >
>> There are two cases. If the TRILL switch that is hosting the Push
>> >
>> Directory server is shutting down or crashes, then becoming
>> >
>> unreachable will immediately stop clients from using the data it
>> >
>> pushed. However, if the TRILL switch is staying up but either the Push
>> >
>> Directory server is shutting down or the Push Directory server is
>> >
>> becoming Passive, then it want to first flood its fragment zero with
>> >
>> the COP (complete push) flag zero, then wait in some intermediate
>> >
>> state, then purge its pushed data from the clients after the clients
>> >
>> have learned that its data will not be complete.
>
>
>   Thanks for your explanation. I catch the two cases now.
>   With the help of the two new states and that of the
>   "passive flag", I think the latter case as well as the
>   former one can be well fixed.
>>
>>
>> >
>> >
>> >> 4. ...
>> >
>> >
>>
>> > >
>> >
>> > Thanks,
>> > >>
>> >
>> Hongjun Zhai
>> > >>
>> >
>>
>> -----------------------------------------------------------------------------
>> > >
>> >
>> > Yuhuatai District, Nanjing City, People's Republic of China
>> > >
>> >
>> > Mobile: +086-025-5287-7345
>> > >>
>> >
>> Email: [email-masked]
>> > >
>> >
>> >
>> > -----------------------------------------------------------------------------
>> >
>>
>> >
>> Thanks,
>> >
>> Donald
>> >
>> =============================
>> >
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>> >
>>  155 Beaver Street, Milford, MA 01757 USA
>>
>> [email-masked]
>
>