Subject: Cisco SG16: Virtual MG & Root

From: Chip Sharp <[email-masked]>
Date: Tue, 25 Jan 2000 20:07:43 -0500

Section:        11.1, second last paragraph
Category:       Technical/Editorial
Issue:          The draft text specifies that "Each virtual MG has its own Root
Termination" but "ServiceChange may only be applied to the Root by the
Master MGC". The two statements seem to be inconsistent as the purpose of
the virtual MG (and thereby the root termination for that virtual MG) is to
allow the MGC for the virtual MG to control that virtual MG.
Proposal:       It is proposed, that the last sentence is removed since each
virtual MG has its own Root termination.

v13 Status:     OPEN. No relevant text changed.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 15:32:39 -0600

I think this is a reasonable proposal.  When the sentence in question was
placed there, people had visions of one MGC knocking out the whole
(physical) MG.  If we simply interpret ServiceChange to be limited in scope
to the virtual MG, it allows, for instance, an MGC to shed load by handing
over responsibility for that virtual MG to another controller.

> -----Original Message-----
> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Tuesday, January 25, 2000 8:08 PM
> To:   [email-masked]
> Subject:      Cisco SG16: Virtual MG & Root
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 28 Jan 2000 14:27:55 -0500

The problem is Restart of Root.  This is a "warm boot".  If one Virtual MG
does it,
it will happen to all Virtual MGs unless you have a pretty complex
implementation
that can "fake" a warm boot without actually restarting the system.

Brian

        -----Original Message-----
From:   Chip Sharp [SMTP:[email-masked]]
Sent:   Tuesday, January 25, 2000 8:08 PM
To:     [email-masked]
Subject:        Cisco SG16: Virtual MG & Root

Issue:          The draft text specifies that "Each virtual MG has its own
Root

        Support NetAid!  http://www.netaid.org <http://www.netaid.org>

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 31 Jan 2000 15:27:34 -0500

We're not talking about reboot in the sense of restarting the operating
system -- the operations involved have a much narrower scope.  How strongly
do you feel on this one?

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, January 28, 2000 2:28 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
> Subject:      RE: Cisco SG16: Virtual MG & Root
>
>       I think this is a reasonable proposal.  When the sentence in
> question was placed there, people had visions of one MGC knocking out the
> whole (physical) MG.  If we simply interpret ServiceChange to be limited
> in scope to the virtual MG, it allows, for instance, an MGC to shed load
> by handing over responsibility for that virtual MG to another controller.
>
>               Support NetAid!  <http://www.netaid.org>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 31 Jan 2000 16:35:09 -0500

I can't imagine having a situation where the MGC can't tell the MG to at
least warm boot.  Maybe you think
of that as "management".  I'm not very worked up about this issue - I
suspect that when we really implement
Virtual MGs, we will find some issues that need more work.

Brian

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Friday, January 28, 2000 2:28 PM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
Subject:        RE: Cisco SG16: Virtual MG & Root

        The problem is Restart of Root.  This is a "warm boot".  If one
Virtual MG does it,
it will happen to all Virtual MGs unless you have a pretty complex
implementation
that can "fake" a warm boot without actually restarting the system.

Brian

        -----Original Message-----
From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Thursday, January 27, 2000 4:33 PM
To: [email-masked]
Subject: Re: Cisco SG16: Virtual MG & Root

        I think this is a reasonable proposal.  When the sentence in
question was placed there, people had visions of one MGC knocking out the
whole (physical) MG.  If we simply interpret ServiceChange to be limited in
scope to the virtual MG, it allows, for instance, an MGC to shed load by
handing over responsibility for that virtual MG to another controller.

                -----Original Message-----
From:   Chip Sharp [SMTP:[email-masked]]
Sent:   Tuesday, January 25, 2000 8:08 PM
To:     [email-masked]
Subject:        Cisco SG16: Virtual MG & Root

                Support NetAid!  < http://www.netaid.org
<http://www.netaid.org> >
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 31 Jan 2000 15:57:59 -0600

I'd like to follow through on Chip's suggestion, then, and delete the
offending sentence.  Not sure whether to class this as "Erratum" or "Missing
functionality", but I'll try the former.

> Sent: Monday, January 31, 2000 4:35 PM
>       We're not talking about reboot in the sense of restarting the
> operating system -- the operations involved have a much narrower scope.
> How strongly do you feel on this one?
>
>               The problem is Restart of Root.  This is a "warm boot".  If
> one Virtual MG does it,
>               From: Tom-PT Taylor [ <mailto:[email-masked]>]
>                       I think this is a reasonable proposal.  When the
> sentence in question was placed there, people had visions of one MGC
> knocking out the whole (physical) MG.  If we simply interpret
> ServiceChange to be limited in scope to the virtual MG, it allows, for
> instance, an MGC to shed load by handing over responsibility for that
> virtual MG to another controller.
>
>                               Support NetAid!  < <http://www.netaid.org>>