Subject: [GSMP] dyn part draft

From: avri doria <[email-masked]>
Date: Fri, 11 Oct 2002 15:57:53 +0200

hi,

a few points:

- one funny coincidence while this draft has no real reference to router 
partitioning anymore, the ForCES req. draft which i am also rereading 
references the req-part draft, i.e. this one, on info relating to router 
partitioning.

- not related to the comments received but i re-read the entire draft. 
i find 2 of the definitions mildly confusing.

--Static Partitioning.  the last sentence makes it sound like the act of 
disconnecting a controller from vSE before partitioning is enough to 
render it a static partition.  i think the confusion goes away if the 
last phrase read ...can be reallocated therefore ...  i.e. replace the 'are'

--Implicit Reactive Notification:  it is not really some unspecified 
error - i expect the error to be a resource not available error. it is 
non reallocation specific error message.

- i did not see any microsoftisms.  then again i missed them before. 
anyone else?

-on page 5 last sentence of 1st para of Dynamic Partitioning: While the 
point is true, isn't it the obverse of what the comment was about.  I 
think he was arguing that partitions not involved in the reapportionment 
would not be affected.

-i am confused by your reference on starvation in Req. 4/8.  what are we 
trying to avoid starving, the PM or the controller/SE.  i read your 
answer as relating to starvation of the PM.

- and a trivial point, but i don't know if the header is legitimate. 
doesn't it need to be something like:
Internet Draft    the_name_of_the_draft    date
especially if we are sending it on to the RFC editor.

thanks for preparing an update so quickly.

a.

_______________________________________________
GSMP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gsmp

---

From: "Anderson, Todd A" <[email-masked]>
Date: Tue, 22 Oct 2002 11:12:02 -0700

New version attached.

Todd

> > The idea was that explicit reactive notification would have an error
> > such as "resource unavailable."  In an implicit 
> notification, all the
> > controller would get is "general error" or "unknown error" 
> the controller
> > could then possibly infer it was from a resource reapportionment.
> > 
> > I added some text to try to clarify these two definitions.
> 
> That wasn't what I thought it was.
> I thought Explicit was - resources aren't available - they 
> were reassigned
> I thought Implicit was - resources aren't available - no idea why

Ok...I think I can agree to the following:

explicit = resources aren't available because they were reassigned
implicit = either "general error", "unknown error" or a generic
"resource error"

> > I don't like this sentence either.  I think the gist of this
> > statement is that we have two partitions, A and B, and A has
> > excess resources (some resources unused) and B has no free
> > resources.  If we transfer resources from A to B then both
> > A and B would have to be shutdown if all we had was static
> > partitioning.  I think the previous paragraph makes this point
> > clear and this sentence only confuses things so I'll remove it.
> > 
> > I added paranthetical statement earlier in the paragraph to try to
> > enforce this point.
> 
> 
> But what about partition C that has no role in the 
> reapportionment at all.
> I thought that was what was being asked about.

Added a sentence explicit saying that unaffected partitions on the
SE would not be transitioned to the down state and back up.

> > Yes, my modifications were with respect to starvation of the PM in
> > its attempts to reapportion.  Is there another kind of starvation
> > at work here?
> 
> Yeah, starvation of the Controller.  It has resources it has 
> been tracking
> and then all of a sudden doesn't.

Through the proactive or reactive notifications the controller will
have to deal with this potentiality.