Subject: Re: Graceful Restart

From: John Smith <[email-masked]>
Date: Fri, 4 Apr 2003 12:54:13 +0100

Krishna,
my 2 euros (dollars are out !!!)

>
> draft-ietf-ospf-hitless-restart-07.txt:
> 2.  Operation of restarting router:
>
> Point 2) If the restarting router determines that it was
> Designated
>           Router on a given segment immediately prior to the
> restart,
>           it elects itself as Designated Router again
>
> Q1)Why does this need to be done while restarting?
>     AND
>     How does it help ??

Its helps in maintaining sanity in the network. Others think that this router is still up
and continue trusting him as DR. When he comes up he should not break this trust and
should ideally start operating as a DR.

The basic concept is that if he resigns from DRship then the BDR will take over and they
will need to again re-elect the BDR .. which is a messy affair. The whole point of
graceful restart is to avoid such events !!

>
> Q2)What if normal DR/BDR election takes place "on exiting
>     graceful restart"

Why do you want to land in this mess? You will again need to re-issue your LSAs, etc.
Everybody will have to re-synch .. and the whole purpose of graceful restart will be
defeated.

Others more informed about this protocol can correct me whatever i missed out!

JS

__________________________________________________
Yahoo! Plus
For a better Internet experience
http://www.yahoo.co.uk/btoffer

---

From: Acee Lindem <[email-masked]>
Date: Fri, 4 Apr 2003 09:36:39 -0500

John, Krishna,

John has it pretty much right but there is one additional key
point. If the restarting router doesn't succeed its role as
DR on interfaces where it was previously DR the specification
is broken. The restarting router uses his own pre-restart
router and network LSAs to determine when graceful restart
has converged. A DR election would change the topology and
the restarting router would detect an LSA inconsistency and
exit graceful restart prematurely.

Thanks,
Acee

--
Acee

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 4 Apr 2003 08:11:09 -0800

One important point is that the DR is the one who issues
the network LSA and have adjacency with. If you change
the DR then this would imply that

- All the routers will have to tear down their previous
adj to the restarting router and build a new one to the DR.
Flooding patterns will change which is not desirable.

- the new DR will build the new network LSA for the
network and this will cause the restart to abort on
change in topology.

Padma

---

From: Erblichs <[email-masked]>
Date: Fri, 4 Apr 2003 11:49:46 -0800

Krishna and group,

        Under the assumption that "network topology
        remains static" (1. Overview, 4th paragraph),
        then election of a DR / BDR really only
        requires the exchange of DBD packets. This
        is pretty lightweight in my opinion.

        On the assumption, that a more capable system
        had booted-up after the wait time, it
        actually, might make sense for the DR or
        the BDR to resign his position upon exiting
        graceful restart.

        Mitchell Erblich
        ---------------------

---

From: Erblichs <[email-masked]>
Date: Fri, 4 Apr 2003 12:53:57 -0800

Group,

        1) Within 2.1 "Entering graceful restart", iff all
           the LSAs were from DC specified NBRs with DNA
           LSAs should the LS RefreshTime still be followed?

        2) Within 2.2 "When to exit graceful restart", number
           (3) "The grace period expires".

           What happens if we follow #3 and your #1 "reestablished
           all its adjacencies" criteria is not met?

           Or are you stating that the specified "grace period" was
           to short to perform what was required?

        3) Within 2.2. Would seeing a hello without the graceful
           restarting router id", force it to exit?

        4) Within 2.2. Would seeing a hello without the graceful
           restarting router id as the earlier DR or BDR, cause
           it to exit, if it was a DR / BDR?

        5) Within 2.2. Is it implimentation dependent on how we
           determine our existing nbrs and place their router ids
           in a hello?

        6) Within 2.2 (1), isn't adj establishment partly the
           recieving of hellos, with your own router-id? Shouldn't
           that inform others that we are back and to cancel
           their helper graceful nbr timer?

        7 & 8) Within 2.3 "Actions on exiting graceful restart".

          7) Shouldn't the sending hellos be performed that
             identify full adj be a criteria here?

          8) I am unsure whether you are specifying the
           storage of part of restarting router's LSDB into
           non-volatile memory. If so, then upon retrieval,
           shouldn't some elements of the LSDB be aged
           by the amount that the actual amount of time
           the LSAs were in NV memory?

        Mitchell Erblich
        ==================================

---

From: Erblichs <[email-masked]>
Date: Fri, 4 Apr 2003 14:44:33 -0800

Group,

        I had one more item for this draft.

        If the grace period could be kept within
        the router dead interval, our entire
        state stored in NVRAM for later retrieval
        would their even be a need to attempt
        to require helper routers?

        Mitchell Erblich
        -------------------------

---

From: Acee Lindem <[email-masked]>
Date: Sat, 5 Apr 2003 21:35:07 -0500

Mitchell,

See answers below.

>            LSAs should the LS RefreshTime still be followed?

LSA Refresh isn't relevant since the restarting router will
reestablish adjacencies.

>            all its adjacencies" criteria is not met?

The restarting router will exit graceful restart anyway.

>            to short to perform what was required?

Not necessarily - perhaps the topology has changed and graceful restart
cannot be completed successfully.

>            restarting router id", force it to exit?

No. The adjacency can go all the way down on the helper router. The hello
shouldn't be used as a criteria for exiting helper mode. Do not confuse
this with other graceful restart proposals.

>            it to exit, if it was a DR / BDR?

Not directly, but an inconsistency with the pre-restart LSA will cause
the restarting router to exist graceful restart prematurely.

>            determine our existing nbrs and place their router ids

This isn't changed for graceful restart.

>              identify full adj be a criteria here?

No. LSA convergence with the pre-restart LSAs is a much surer
mechanism for determining the graceful restart can be exited.

>            the LSAs were in NV memory?

There is no mention of storing LSAs in non-volatile storage.

--
Acee

---

From: Acee Lindem <[email-masked]>
Date: Sat, 5 Apr 2003 21:37:25 -0500

>         to require helper routers?

No - if you store your entire state you don't need
any protocol interaction to recover. In fact, there
are implementations that sync their state between redundant
route processors. Please note that the Link State Database
alone doesn't constitute full state ;^)

--
Acee

---

From: Erblichs <[email-masked]>
Date: Mon, 7 Apr 2003 17:29:46 -0700

Acee Lindem,

        Sometimes my logic is a little obtuse..

        Most of it is inline...

        I will first throw two new questions to you!!!!

        1) Why don't you send out the Grace LSA at full
           adj timeframe. It would take effect after
           RouterDeadinterval has expired?

           This would also take care of unscheduled restarts
           and allow you to do an unscheduled graceful
           restart!!!!

           You could also send them as DNA LSAs.. See inline.

           The only new twist is that if you then schedule
           a restart, you may want to be able to cancel your
           previous request or update the LSAs over time.
           But if you conisder a stable topology, then why
           NOT??

        2) A) 2.1 3rd, paragraph..
             "Their age field set to 0,"
             Why can't you send DNA grace-LSAs????

           B) 2.1, 4th paragraph.

           "it should retransmit... until
           they are acknowledged". If you can't retransmit the
           same LSA until 5 secs have passed, if a router
           was congested, you may want to resubmit the grace-LSA
           with a longer length timeframe to your helpers. I am
           assuming just bump your instance. Correct?

        Mitchell
        ================
> LSA Refresh isn't relevant since the restarting router will

        Then why have a suggestion of 1800 secs for LSReshTime
        in your draft at the end of the 1st paragraph in section
        2.1?

        In my scenario, there would be no reason not to let the
        value approach or exceed 3600 secs (1 hr).

        variation on a theme? Why not let the max value of your
        grace-LSA length field allow the helper determine what
        is the max that he will support?
                -- what happens if you specify a value that is
                   greater than what the helper supports?
                Ans A: The helper sees it as an invalid request
                     and throws away the whole request,

                        OR
                Ans B: The helper determines what the length he
                     will support?

               If it is B, then why have the length field. Just let
                the helper decide how long to support the request?

> The restarting router will exit graceful restart anyway.

                Why? If you still have a non-changing topology, why
                limit the value to what you had said to the helpers?

                So, what if you asked for x time and it took you
                x + y time?

> this with other graceful restart proposals.

        I see that my question with the hello was answered in the
        2. (3) "an hello packet is received"..

        I am confused. One router may list you as the DR and another
        may not? If one is a helper, then why would it take the adj
        down if all the crieria were met?

        I thought that helpers
        MUST send hellos as if you (graceful restarting router) were
        still there!!
        "an Hello packet is received from a neighbor listing the
         router as the Designated Router".

        If it did keep anouncing you in the hellos (you weren't
        the DR) and lets say that the DR went down. Could you
        then be elected as the DR while you were still rebooting?

> This isn't changed for graceful restart.

                I thought that you could save past nbr-ids in NVRAM
                and then compare to existing hellos...
> There is no mention of storing LSAs in non-volatile storage.

        Ok, you aren't suggesting saving the LSDB in NVRAM
        or some other type of storage media..

---

From: Acee Lindem <[email-masked]>
Date: Mon, 7 Apr 2003 21:18:38 -0400

>            RouterDeadinterval has expired?

How do you know, apriori, that the OSPF instance is
restarting and not completely dead?

>              Why can't you send DNA grace-LSAs????

You wouldn't gain anything since the grace interval cannot
exceed the LSA refresh time.

>            assuming just bump your instance. Correct?

There are implementations that back off LSA retransmissions and the
"Prioritized Treatment of Specific OSPF Packets and Congestion
Avoidance" draft recommends this. However, this is not standard
OSPF flooding as described in RFC2328 and it is an independent
issue.

--
Acee

---

From: Erblichs <[email-masked]>
Date: Tue, 8 Apr 2003 16:15:52 -0700

Acee Lindem,

        Since,, you skipped the inline re-comments, I will assume
        that at least you read them.. :)

        I think I have expressed as best as I could (I am not
        a tech writer) how I feel that this draft should evolve.

        So in summary...

`       0) Remove the length (seconds) field from the grace-LSA.

        1) Transmit DNA grace-LSAs at adj creation time.

        2) Let the helpers determine amount of time that
           they will function as a helper. Suggest a minimum
           of 1 hr time.

        3) Reflood the DNA grace-LSAs anytime the contents
           have changed.

        4) If the restart router expects to be down for a period
           longer than X, then retransmit the Grace-LSAs as
           MAXage LSAs.

        This would minimize bandwidth requirements and allow a
        restarting router to have either scheduled or unscheduled
        restarts.

        I don't know what else to add, except if you adopt one or
        more of these suggestions, then please add my name to your
        comment list. :)

        Mitchell Erblich
        Sr Software Engineer
        ============================

> restarting and not completely dead?

        Why do you care? As long as the topology isn't changing
        then everything is ok.

        Wwhy not minimize the effects of unnecessary SPF computations?

> exceed the LSA refresh time.

                So, first why do you need to specify the grace-LSA
                timeframe. Let it be implicitly known to be 1 hr!

                 With DNA grace-LSAs, we
                don't need to reflood them. If I sent them out
                at adj creation time and the topology isn't
                changing, then I don't need to consume
                resources and keep on re-flooding them..

                Thus, they can last multiple hours or longer..

> OSPF flooding as described in RFC2328 and it is an independent

        No, no, you are missing my point. Until all of your grace-LSAs are
        ack'ed, you can't continue successfully with a graceful-restart.

        This delay consumes time that you specified in your grace-LSA. Yea,
        again, I don't know why you need to specify the amount of time!!
        The timeframe that the helpers will help you can be set independently
        and your spec doesn't allow them to communicate the amount of time
        that they will keeep around a grace-LSA.

        Sorry, minor sidetrack. So, the time consumed to get the ack, actually
        reduces the amount of time before the grace-LSA expires.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 8 Apr 2003 16:56:49 -0700

Mitchell,

I'll try to address your comments

> `       0) Remove the length (seconds) field from the grace-LSA.
This is using the TLV format .. so you want to keep the length

>         1) Transmit DNA grace-LSAs at adj creation time.
This is not very useful. Today unless you have DNA lsa you cannot
expect to be requesting a grace period of over one hour -- as
all the LSA in the other routers database will expire at the
most in 1hr.
So if you decide to send a grace LSA it would be the most recent one
that you built and hence if it has time to expire then the previous
would already be gone.

>            they will function as a helper. Suggest a minimum

This is a matter of policy .. even if the helper decides that
he is not going to help for the whole period .. as he is not
going to signal it to the restarting router .. I do not see
the use of doing so.

>         3) Reflood the DNA grace-LSAs anytime the contents
See my response in 1.

>            longer than X, then retransmit the Grace-LSAs as
I do not see the benefit or I am missing your point

Padma

---

From: Erblichs <[email-masked]>
Date: Tue, 8 Apr 2003 18:20:30 -0700

Padma,

        These are my last comments!!

        Also inline...

        Why doesn't the draft RFC authors want to
        allow non-scheduled restarts in this
        draft?

        Is there something wrong with the idea
        of un-scheduled restarts?

        Why restrict it to only scheduled
        restarts???

        Why require
        the grace-LSAs to be reflooded every
        30 minutes to 1 hr???

        Why not send the grace-LSAs without
        the Type=1, Length=4 grace period field??
        It will be determined by the helpers
        anyway.

        The sentance is.

        "The number of seconds that the router's
        neighbors should continue to advertise the
        router as fully adjacent"....

        Thus, without the word "MUST", implimentations
        will probably follow their own rules. Thus, the
        grace period field really isn't needed and just
         consumes bandwidth!!!

        Mitchell Erblich
        ===================

> This is using the TLV format .. so you want to keep the length

        Of course, Type, Length, Value... Fine. Reword..
        Remove
        the Grace-Period field of (Type =1, Length = 4).
        Why transmit the field value?????
> that you built and hence if it has time to expire then the previous

        Think ahead of tomarrow, not today...
        How should this work in the utopian word? If the graceful
        restart is a good idea, then it NOT should be used for ALL
        possible restarts??

        Why not restrict the amount of flooding with THESE types
        of LSAs if this draft becomes a standard RFC??

        What happens if I send the grace-LSAs at adj formation
        time and then reflood them every 55 minutes?? This
        removes the lightweight mechanism of the draft, but
        still gets me unscheduled restart functionality? Maybe
        i will just do that.. BTW, and also do unscheduled
        restarts with my BGP protocol once it becomes a
        standard.

        Thus, a restriction of 1 hr isn't sensible. Else, even if
        I follow your logic, then why do I ask for 1 hr? Should
        my implimentation in the helper not ack the grace-LSA if
        the specified grace-period is over 1 hr from the restarting
        router? This is unspecified behavior!!!

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 8 Apr 2003 19:01:44 -0700

>         allow non-scheduled restarts in this

But it does - I actually contributed a lot to that ;-)

>         of un-scheduled restarts?

No - Absolutely
>         Why restrict it to only scheduled
see above

>         the grace-LSAs to be reflooded every

It doesn't need to - nor require but the general
mechanism od refresh is the same for all LSA and
grace happens to be one of them.

>         It will be determined by the helpers

This is a "accepted norm" TLV ... What is the
advantage ?
let say in the future you want to send more infos
there .. by using TLV you know where an info starts
and finishes. Unknown TLV should be just ignored by
implementations. Here you have a very easy way to
extend without breaking older implementation.

>         grace period field really isn't needed and just

Now I like the way the sentence is written ;-) because -
An implementation can keep the state shown as FULL for
the restarting neighbor but keep track of the real
state for grace-period or just blocks rebuilding LSAs to
reflect the real state for that time.

the "should" enables us to do whatever is implementation
architecture is simplest.

The grace period is important for the helpers to know when they
will eventually tear down the adjacency/rebuild lsa to reflect
the real state . If the grace period did not exist then the
restarting router would have to be in FULL state within the
Dead Router Interval .. which is configurable and can be very
short for a big DBD exchange.

Padma

---

From: Acee Lindem <[email-masked]>
Date: Thu, 10 Apr 2003 01:50:19 -0400

>         allow non-scheduled restarts in this

Michell,

As Padma stated, the draft supports unscheduled restarts (there
are multiple interoperable implementations). Your proposal to
announce graceful restart in advance will unnecessarily delay
the detection of a black hole if the restarting router is really dead
or was abruptly decommissioned. The current draft doesn't suffer
from this flaw.

--
Acee

---

From: Erblichs <[email-masked]>
Date: Thu, 10 Apr 2003 11:41:16 -0700

Acee, et al,

        I didn't really want to continue this thread
        but I feel, I should restate some items here. :)

> announce graceful restart in advance

        I don't see how one can send out grace-LSAs and possibly be
        able to retransmit a grace-LSA OTHER than in advance,
        AND still support unscheduled graceful restarts!!!

        You must do it in advance, else it is scheduled..

        My definition of unscheduled is that some event occurs and
        the non-forwarding portion of the router is DOWN... No,
        time for an sys admin to do anything...

        The ONLY possible way is to have trap level code call
        the xmit grace-LSA code section. However, no time to
        see if acks have been rec'vd and no time for a 5 sec
        rexmit....

        Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your
        guys opinion????

        On the assumption that if the router fails and
        still abides by the condition that it is still
        forwarding as if it was still up.., then

        As long as there isn't any topologoy changes
        as stated within your document, that is one
        reason to allow for a graceful restart, I don't
        see the blackhole..

        If the topology changes then it would invalidate
        my graceful restart, as it would also invalidate
        the graceful restart specified in the draft.

        The only deltas that I was asking for was:
        -  the issue of sending out a minimal grace-LSA at
            adj timeframe,
        - being able to minimally update our grace-LSA as
          topology changes,
        -  or we decide that we want to withdraw our grace-LSA
           via MAXAGE,

        As of this time, I have not read in your document,
        EXPLICITLY whether
        -  you suggest to ONLY send out the grace-LSA when you
           have planned to do a restart (scheduled),
        -  how to withdraw the grace-LSAs from accepted helpers
           when one proto-helper (to be helper), will not ack
           your LSA,
        - etc..

        Mitchell Erblich
        Sr Software Engineer

---

From: Acee Lindem <[email-masked]>
Date: Thu, 10 Apr 2003 14:58:39 -0400

Mitchell,

In the case of unscheduled restart you may send the grace LSA a couple
times but you don't want for an acknowledge (you don't necessarily know your
neighbors since you are learning the state from the networks).

I suggest you read or review section 5 of the draft. It covers all of your
concerns below.

--
Acee

---

From: Erblichs <[email-masked]>
Date: Fri, 11 Apr 2003 17:31:42 -0700

Group,

        First of all I would want to apologize for continuing
        this discussion thread!

        I realize that some implimentions may exist based on
        this draft and what I am suggesting, may effect changes
        to them.

        In my past emails I have implicitly ignored the section
        5 within this draft of "Unplanned outages". I will now
        explicitly state why I have ignored its suggested method.

        Why?
                * " must originate grace-LSAs *after* its control
                  software resumes operation", we now lose our DR or
                  BDR status, if it had existed.

                  - This forces a SPF recomputation..
                  - This can forces many full adj reformations.
                  - Removes the helper relationship with
                    respect to the restarting router
                    (monitoring, continues to (its) advertise its
                     LSAs, etc) NIT: remove the first "its".
                  - etc..

                 Thus this section invalidates many of the reasons
                 for the draft's existance.

                * If the draft's unplanned outages did not have these
                  negative effects and more, then anytime > 1 hr
                  graceful restart is planned, then this would be a
                  solid alternative. I just cannot see anyone
                  forwarding any pkts accross a non-adj, so even if
                  your forwarding table contents are sanitized, it
                  will be ignored.

        So, from may past information dump, the only true side effect
        other than mentioned in the draft (clean flag for the forwarding
        table should remove the table sanity issue) are the issues of the
        reflooding bandwidth of early grace-LSAs, just in case the router
        has an unplanned restart. And the extra work that is placed on
        helper routers to "monitor" the network for topology changes,
        and its other assigned helper duties.

        Thus, I believe that I have more than sufficiently identified
        a graceful restart mechanism that removes the AFTER requirement
        and allows the planned graceful restart method to be used in a
        unplanned way. Plus, I agree that a knob/CLI command should be
        used to enable or disable this type of feature.

        Mitchell Erblich
        Sr Software Engineer
        ----------------------

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 11 Apr 2003 22:00:04 -0700

>                   - This forces a SPF recomputation..

What makes you think that it forces a SPF computation ?

Padma

---

From: Acee Lindem <[email-masked]>
Date: Sun, 13 Apr 2003 17:46:58 -0400

Mitchell,

No apologies necessary for discussion of the draft. However, please make
every attempt to read and understand it before suggesting substantive
changes.

>                   BDR status, if it had existed.

The restarting router will succeed DR status if it was previously DR. See
section 2 number 3. Also note section 5 for applicablility to unplanned
restarts.  Changes in BDR should have no effect on adjacencies or LSA
contents.

--
Acee

---

From: Erblichs <[email-masked]>
Date: Mon, 14 Apr 2003 12:57:43 -0700

Padma,

        Inline comment.

        Mitchell Erblich
        ---------------------

> What makes you think that it forces a SPF computation ?

        If I read/interpreted the section 5 correctly..

        Then, "*after*" section imples xmiting no LSAs
        prior to shutdown.

        With this assumption, during the downtime of
        the router, all the adjs will timeout. No helpers
        will be requested before shutdown.

        Due to this fact the SPF computation interval
        will probably expire which will result in a
        SPF computation.

        Mitchell Erblich

---

From: Erblichs <[email-masked]>
Date: Mon, 14 Apr 2003 13:14:36 -0700

Acee Lindem,

        Inline...

        Mitchell Erblich
        ----------------------

> restarts.  Changes in BDR should have no effect on adjacencies or LSA

        I am really lost here..

        IFF we are unplanned, won't the normal deadrouterinterval
        timeouts take down the adjs? Remember the "*after*"
        section.

        If the restarting router was the DR or a BDR, a new election
        will occur to re-elect a new DR and/or BDR, and new adjs
        will form. Now, the premise of minimizing topological changes
        as a reason to keep the pre-shutdown DR / BDR combo, will
        no longer apply.

        Even if we declare ourselves the DR after re-start, there
        is only a chance that the reason why we were initially
        elected still applies, thus we may no longer have the
        highest priority of eligible routers.

        Mitchell Erblich
        ---------------------------

---

From: Acee Lindem <[email-masked]>
Date: Mon, 14 Apr 2003 16:45:55 -0400

>         Mitchell Erblich

What you are missing is that for unplanned restarts the restarting OSPF
router (or process) must at least start graceful restart within
the RouterDeadInterval period. For planned restarts, this is not a
restriction.

--
Acee

---

From: Erblichs <[email-masked]>
Date: Mon, 14 Apr 2003 15:28:47 -0700

Acee Lindem,,

        Inline..

        Mitchell Erblich
        Sr Software Engineer
        -----------

> the RouterDeadInterval period. For planned restarts, this is not a

        That is nice....................

        No, not "start graceful restart" process. Start sending hellos within
        routerdeadinterval which is after grace-LSAs are sent and recived.

        Yes, sending multiple grace-LSAs, but don't they need to be
        5 secs apart? So, to send three will take 15 secs. Right??

        In Version 07, section 5, of the draft where is that
        ROUTERDEADINTERVAL  stated???
        Isn't that an important enough concept to be explicitly stated
        here?

        I only see "restarted router has no adjacencies and no
        knowledge of previous adjacencies". As a statement about
        adj in section 5.

        Wow.. Can I second and third my unplanned restart as an
        option that follows the planned restart logic without
        the routerdeadinterval restriction????   :)

---

From: Acee Lindem <[email-masked]>
Date: Wed, 16 Apr 2003 10:11:57 -0400

>         Inline..
     Mitchell Erblich
     Sr Software Engineer
     -----------,

            Inline...

>         5 secs apart? So, to send three will take 15 secs. Right??

In the case of implementation, I only wait 1 second between grace LSAs for
unplanned restart.

>         Isn't that an important enough concept to be explicitly stated

It seems obvious to me. Did anyone else miss this? I'll see about
adding something during the AD comments.

>         the routerdeadinterval restriction????   :)

You are welcome to submit an alternate proposal but please do it
in the form of a draft rather than E-mails extolling the benefits.
I believe the current draft is a reasonable approach to unplanned
restart. One cannot signal unplanned graceful restart apriori since
you don't know whether the router or OSPF process is going to
come back.

--
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 16 Apr 2003 10:33:07 -0700

Acee,

        Inline..

        Mitchell Erblich
        ---------------------

> you don't know whether the router or OSPF process is going to

        I am first planning on submitting a draft on another
        feature.

        I will consider an experimental draft on what I am
        suggesting in May.