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

From: hongjun ZHAI <[email-masked]>
Date: Fri, 7 Mar 2014 19:55:10 +0800

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?

2. For a Push Directory server in Active state, it should change to
Completing state rather
than the current Complete state in the current state table. I think the
Completing state
can give it some time to push its Directory data to the interested client
TRILL switch
before it tells its client that it is complete Push Directory server. And
for a Push
Directory server in Reducing state, it should also change to Completing
state rather than
the current Complete state in the current state table.

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.

4. For a Push Directory server, what conditions should be met before the
administrator
believes it has being complete data and configure it as a complete Push
Directory server?

Thanks,
Hongjun Zhai
-----------------------------------------------------------------------------
Yuhuatai District, Nanjing City, People's Republic of China
Mobile: +086-025-5287-7345
Email: [email-masked]
-----------------------------------------------------------------------------

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 15 Mar 2014 23:51:04 -0400

Hi,

Thanks for your comments. See below...

On 3/7/14, hongjun ZHAI <[email-masked]> wrote:
> 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.

> Completing state rather than the current Complete state in the
> current state table. I think the Completing state can give it some
> time to push its Directory data to the interested client TRILL
> switch before it tells its client that it is complete Push Directory
> server. And for a Push Directory server in Reducing state, it should
> also change to Completing state rather than the current Complete
> state in the current state table.

Yes, you are correct. Event 5 should cause a transition from Active to
Completing, not to Complete. We can fix that in the next revision.

> 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.

> 4. For a Push Directory server, what conditions should be met before
> the administrator believes it has being complete data and configure
> it as a complete Push Directory server?

The assumption is that you have some sort of orchestration system that
knows where all the MAC addresses, VMs, etc. are. I would say that for
an administrator to configure push directory servers as complete, the
orchestration system need to communicate with the Push Directories in
a timely fashion.  For example, if a new VM is being spun up, the
directory needs to know where it is reachable before the VM's MAC
become active. If a MAC moves from one point of attachment to another,
then it needs to be effecitvely reachable at both while the push
directories are pushing out the new point of attachment (I believe
that Vmotion systems usually achieve this).

> Hongjun Zhai

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

---

From: [email-masked]
Date: Mon, 17 Mar 2014 11:24:01 +0800

Hi Donald,

Thanks for your response. My comments is inserted below.

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

> to transitiion out of the Reducing state is the passage of enough

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 there is no event 3 or 5 
(the Active Condition is met) occurs later. But according to the current 
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  |

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?

> Completing, not to Complete. We can fix that in the next revision.

OK.

> 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.

> that Vmotion systems usually achieve this).

Thanks for your answer.

Thanks,
Donald

_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 25 Mar 2014 14:16:13 -0400

Hi Hongjun,

> Thanks for your response. My comments is inserted below.

I'll just respond below where we still seem to not agree...

> [email-masked], "[email-masked]" <[email-masked]>, Radia Perlman <[email-masked]>, Liyizhou <[email-masked]>, [email-masked]
> 主题
>  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.

>       Event || Down  |Passive   |Active  |Completing|Complete|Reducing|

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...

> 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.

> >> 2. ...

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.

> >> 4. ...

Thanks,
Donald

---

From: hongjun ZHAI <[email-masked]>
Date: Wed, 26 Mar 2014 20:05:54 +0800

Hi Donald,

Thanks for your response. My response is inserted in-line.

Thanks,
Hongjun Zhai

On Wed, Mar 26, 2014 at 2:16 AM, Donald Eastlake <[email-masked]> wrote:

> > [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,
> > >
> >
>
> > >
> >

  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   |

Bits

> It could then purge the data it had pushed when it was convenient to

 Well, the "passive flag" is a good idea, it interprets what I
 really wanted to express.

> 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.