Hi Robert, > It seems that the complexity why this procedure is proposed lies in > suggestion to exchange those 4 messages: > > SleepPrepareAck 1 Receiver accepts preparation > SleepPrepareNak 2 Receiver rejects preparation > > GoSleep 3 Sender authorizes power-sleep > GoSleepAck 4 Receiver confirms power-sleep > > In respect to the first reply the draft just says this: > > " If it cannot participate, it continues to be in Operating mode and sends > negative acknowledgement. If it can participate, it sends acknowledgement and > transitions to Ready mode." > > What are the criteria the receiver should use to make the above judgement ?
That’s a matter of local policy plus whether there are active LSPs on the link. > Also how is this related to timing of flooding "sleep capable" state for a > link in ISIS ? It is not. All of the IS-IS flooding is not timing sensitive and is all static information. > Should Sender even attempt to send anything to the peer here if there was no > indication in flooding that specific interface of specific power group is > sleep capable ? Probably not. If the interface is not power-sleep capable, requesting that it go to sleep is pointless. > Or is that flooding to start after SleepPrepare Ack ? Not clear. Again, the flooding is static information and should happen after a configuration change. > Now what happens after sending GoSleep and never receiving the GoSleepAck ? As always, time out and retry. Binary exponential backoff with a ceiling is your friend. > Last but not least ... why for this p2p communication would one use the RSVP > protocol ? Couldn't those indications be instead part of ISIS new Hello > Capabilities Les is proposing ? Because in the case of the wakeup message, it is initiated by the headend. This cannot be carried by IS-IS IIH PDUs. Cheers, Tony Li
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
