Subject: Re: physical vs. ephemeral terminations

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 2 Feb 2001 09:02:11 -0500

I've never seen a system that didn't need some provisioning.
That does not diminish my argument that provisioning is evil.
I think most operators agree - provisioning is an aspect of their
business that is problematic, and there is a very large
pressure on vendors to eliminate provisioning.  Self service,
automatic discovery, load balancing, etc, etc are in
great demand.

If you want to have multiple million termination systems, you
don't want any provisioning, because whatever provisioning you
need to do, you have to do multiple million times, and each on
of those means people time, and lots of mistakes.  The larger
systems get, the more the imperative to eliminate provisioning.
For example, the GMPLS effort seeks to eliminate the majority of
provisioning for optical trails.  Operators most certainly do
want to uncrate a box, plug it in to the network and have it
start working without any provisioning.  They might not be
there yet, but that is definitely a goal.

No one wants to "hope" that something works, you want to have
confidence that it will work.  Operators used to roll trucks
to install DSL, they now let consumers self-install.  An operator
wants to get to the point where a customer places an order on a
website and no manual provisioning of any kind is done to get
service.  Some aspects of that might still be actually accomplished
by automated provisioning, but the closer the device come to
discovery rather than provisioning, the more likely such
systems are to be reliable, scalable, and flexible.

The single largest problem people have with provisioning is errors.
The advantage of discovery over provisioning is the elimination
of errors.  Provisioning is almost always used when it is
considered too hard to discover.  It's essentially NEVER
a desired capability.  I think in most cases provisioning is
a crutch a product designer falls back on when he can't come up
with a better way to solve the problem.  Think about the way
Megaco was designed.  Whenever we made a provisioning decision,
it was always because we didn't have an acceptable way to
discover.  No one every voiced an argument that provisioning
was a better answer - provisioning was just the one answer
that everyone could see how to implement.  Given what I know
now about how SIP does discovery of proxy servers, I think
provisioning of the MGC name in the MG was a mistake, which I hope
we will rectify in V2.  The only thing we should provision is
name for the MG.  We haven't figured out a way to discover that
one yet!

There are two kinds of "multiple million" termination systems -
those that have multiple million MGs with a small number of
terminations, and those that have far fewer MGs each with
a much larger number of terminations.

I think you would agree that the former are good candidates for
no-provisioning.  I happen to think the latter are also good
candidates, and especially in areas that concern one termination --
it's one thing to provision the name of the MG, it's another
to provision every port with its default settings.

In the Internet, there is not a lot of provisioning, and there
is a concerted effort to get rid of what there is.  The
routing protocols work by discovery.  There are databases
that are used to maintain the routing, and some of that information
is manually entered, but it's done once and then automatically
propagated to the devices - when you replace a device, you don't
have to reload the routing information -- you have to tell it
its name, the names of its peers, etc., but then it knows how to pull
routing information from the network.

Consider DHCP as an excellent example of getting rid of provisioning --
you used to have to provision end devices with an IP address.
Now you don't, it discovers a DHCP server, and the server leases
it an IP address. Do you know any ISPs that would prefer to provision
IP addresses to customers rather than use DHCP?

What we have in Megaco is the collision of the telco heavy provisioning
world and the IP little provisioning world.  Provisioning is evil.
Some evils are necessary, but let's try REAL HARD to get rid of
provisioning.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Friday, February 02, 2001 1:17 AM
> To: [email-masked]
> Subject: Re: physical vs. ephemeral terminations
>
>
> G'Day Brian,
>
> CHOOSE is applicable in a provisioned network.
>
> Are you saying that all the operators who have provisioning in their
> network are Evil? For myself and "associates" (whoever they may be)
> developing MGC/MGs that handle multiple million termination
> systems, it
> would surprise me if any vendor has sold an implementation to an
> operator that had no provisioning at all. If fact if there was such a
> system it would be completely non-standard proprietory as nothing has
> been defined as standard yet. Having the MGC discover the names of
> terminationIDs doesn't solve all your provisioning problems. Operator
> certainly don't like uncertainty in their networks. They like
> predictable behaviour. They won't stick a box in their network turn it
> on and hope for the best and let it auto configure.
> Residential MG users
> may want this.
>
> Finding having no provisioning on a 2 termination MG may be completely
> achievable but as the complexity of a system increases so does the
> need for provisioning.
>
> I think you and I will have to agree to disagree on this one (again).
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > Rosen's First rule of Provisioning - Provisioning is evil
> > Rosen's Second rule of Provisioning - Cross Provisioning
> (both MG and MGC)
> >         is monstrously evil
> >
> > DON'T DO IT (Please)
> >
> > Of course, nothing prevents you from making some
> proprietary MG and MGC that
> > requires this, but I have been quite adamant, and I think
> successfully,
> > that it is very reasonable to:
> >         Not have ANY knowledge of MG capability by MGC
> >                 You can audit everything you need to know
> >         Never need ANY cross provisioning
> >
> > So if Christian and his associates make MG/MGC pairs that need cross
> > provisioning, they certainly might be completely Megaco
> compliant, but
> > a customer may or may not wish to deal with such
> complexity.  Of course,
> > unless that cross provisioning was standardized by someone,
> it would be
> > completely proprietary.
> >
> > A compliant Megaco implementation has to handle CHOOSE.  It
> is a little
> > tricky, but not much, to determine the characteristics of the
> > termination from the descriptors.  It is required that an MG do so.
> >
> > We can argue about what error to return, and we need to
> come to agreement
> > about that.
> >
> > If you design an MG to not have a relationship between the
> terminationID
> > schema and the packages implemented on the terminations,
> then you force the
> > MGC to audit each termination separately.  MGCs will always
> need a flexible
> > representation mechanism - this is a degenerate case, but
> it will work,
> > albeit inefficiently.  If you intelligently name your
> terminations, then
> > the MGC's database will be very compact.  I expect to see
> most profiles
> > specify compact naming schemes for this reason.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Wednesday, January 31, 2001 9:40 PM
> > > To: [email-masked]
> > > Subject: Re: physical vs. ephemeral terminations
> > >
> > >
> > > G'Day Troy,
> > >
> > > I think you have to make the assumption that the MGC
> knows something
> > > about the MG. It can audit terminations to find out the
> capabilities
> > > supported. If the MGC asks a particular termination to do
> something
> > > that's not supported then the 44"x" ie. 445 unsupported
> property could
> > > be returned.
> > >
> > > I don't think the MG is as dumb as some people try to make
> > > out and there
> > > will have to be a number of things provisioned in both the
> > > MGC and MG to
> > > make this all work. We didn't document all this because if
> > > there are 200
> > > companies represented on this list I'm sure you'd have
> 300 different
> > > view (and yes I meant 300 :) )
> > >
> > > Cheers, Christian
> > >
> > > Troy Cauble wrote:
> > > >
> > > > Tom Taylor wrote:
> > > >
> > > > > >What is the error returned if an MG is asked to do something
> > > > > >it doesn't support (or doesn't even make sense) on that type
> > > > > >of termination?
> > > > > >        If it's asked to detect hook flash on an ephemeral
> > > > > >        termination?
> > > > >
> > > > > [PTT]
> > > > > 440 Unsupported or unknown package
> > > > >
> > > > > >        If it's asked to apply Local or Remote Descriptors
> > > > > >        to a physical termination?
> > > > >
> > > > > [PTT]
> > > > > Not an error, though the I-D describing SDP naming
> > > conventions (SDP nettype, addrtype) for TDM circuits has to
> > > be written.  You
> > > > > need the descriptors to describe the codec (as Madhue has
> > > pointed out) and the bearer capability.
> > > >
> > > > Tom,
> > > >
> > > > Well, it's an error for a POTS line.  What's the error code
> > > for that?
> > > > (Don't say 440; we're not talking about packages here.)
> > > >
> > > > >
> > > > > >
> > > > > >This seems to indicate a whole class of
> syntactically correct,
> > > > > >but nonsensical combinations.
> > > > >
> > > > > [PTT]
> > > > > Error code 440 covers a lot of it.
> > > >
> > > > But not all :(
> > > >
> > > > > >Also, it seems that given a termination id of
> CHOOSE, an MG must
> > > > > >traverse descriptors looking for clues that indicate
> whether it
> > > > > >should CHOOSE an ephemeral or physical termination.  Correct?
> > > > > >What if there is no forcing hint?
> > > > >
> > > > > [PTT]
> > > > > I gave my own answer to that a while ago.  Basically the
> > > termination is treated as an empty software container waiting
> > > to be filled
> > > > > with detail.
> > > >
> > > > This makes for nice viewgraphs, but difficult implementations :(
> > > >
> > > > >
> > > > > >
> > > > > >        A termination id schema must clearly
> distinguish between
> > > > > >        physical and ephemeral so the MGC knows how to pick a
> > > > > >        termination associated with some physical attribute
> > > > > >        (such as "POTS line 7"), yes?
> > > > >
> > > > > [PTT]
> > > > > It has been pointed out that there is no necessary
> > > association between termination type and name, even if the
> > > latter is based on a
> > > > > physical schema (e.g. shelf/slot). It might be possible
> > > to insert various card types (ATM, TDM, ethernet) into
> the same slot.
> > > >
> > > > I guess you're saying that the schema doesn't have to
> > > > explicity distinguish between termination types, as
> > > > long as the MGC and MG both know the mapping.  Correct?
> > > >
> > > > So a schema could be simply integers 1-1000, and the MGC just
> > > > knows that the POTS line to my house is 37, while 36
> > > > and 38 are to be used for RTP streams?
> > > >
> > > > Thanks,
> > > > -troy
> > >
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 2 Feb 2001 13:27:49 -0500

You can respond to an AuditCapability.  The response to AuditCapability
does not require that the ephemeral exist, because no state is required
to determine the output.  The matching logic could quite reasonably
determine
that.

Note that you actually can already do an "Add", although it creates
a context in the process.

Modify is interesting.  How do you mark an Ethernet interface out of
service?
If you have one, the flows might be RTP/*, ephemeral of course.
Do you want to be able to say:
  Modify=RTP/*{TerminationState{ServiceStates=OutOfService}}

Brian

> From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 8:06 PM
> To: 'Rosen, Brian'; [email-masked]
> Subject: RE: physical vs. ephemeral terminations
>
>
> Hi Brian,list,
> How can MG/MGC responds on terminations that are not
> existing. Ephemeral
> terminations are created and destroyed by Add and Subtract commands.
> Commands to Ephemeral terminations always should be addressed
> with valid
> Context Identifiers. I'm confused how MGC can Audit on
> terminations that
> doesn't exist (Irrespective of the naming schema)? Am I
> missing anything
> here!!
>
> Best Regards.
> Madhubabu
>
> From: Media Gateway Control (megaco)
> [mailto:[email-masked]]On Behalf Of Rosen, Brian
> Sent: Thursday, February 01, 2001 1:39 PM
> y'know, I saw that discussion, and never said anything because
> I never knew where the idea came from that you can't audit
> a non-existent ephemeral.  I believed you could, precisely for
> the reason we are discussing.  I'm glad you are as confused as
> I.  Maybe we can claim you can in the absence of language to
> the contrary in the spec.
>
> More specifically, I think that if you do:
> Context=-{W-AuditCapabilities=foo/*{Audit{Packages}}}}
> you should get a meaningful response.
>
> Brian
>
> > From: Tom Taylor [mailto:[email-masked]]
> > Sent: Thursday, February 01, 2001 12:31 PM
> > In saying what I did about audits, I was quoted consensus
> > doctrine (with
> > which I do not personally agree) that you cannot audit
> capabilities of
> > terminations which have not yet been instantiated.  I just
> > tried to find
> > any mention of this restriction in H.248 and failed.  Brian,
> > do you know
> > where it is, or is my memory of the position incorrect?
> >
> > Troy Cauble wrote:
> > >
> > > > Tom-PT Taylor wrote:
> > > >
> > > > Hi.
> > > >
> > > > > From: Troy Cauble [mailto:[email-masked]]
> > > > > Sent: Wednesday, January 31, 2001 7:53 PM
> > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > > > > Cc: [email-masked]
> > > > > Well, it's an error for a POTS line.  What's the error
> > code for that?
> > > > Even for an analogue line you need SDP saying that it is
> > carrying an audio
> > > > stream.
> > >
> > > Really?!  What does that SDP look like?
> > >
> > > I thought you identified the codec, etc. in the ephemeral RTP
> > > termination and added that and the analogue line termination
> > > to the same context, a la #12 in Appendix A.
> > >
> > > > Don't forget audits, at least for physical terminations.
> > There is a missing
> > > > link for ephemerals: they can't be named or audited until
> > they exist.  I
> > > > think the answer has to be in defining container
> > terminations representing
> > > > the physical interfaces, as I mentioned yesterday.  I
> > think I'll have a go at
> > > > the necessary package definition today.
> > >
> > > "can't be named until they exist"
> > >
> > > OK. Let's see if I've got this right...
> > >
> > > Physical terminations always "exist", they just move to and from
> > > the null context.
> > > Ephemeral terminations are created and destroyed.
> > >
> > > Does CHOOSE mean "choose among the existing" or "choose
> > > among the entire schema".  I guess it means the latter
> > > otherwise we couldn't create an ephemeral with Add/CHOOSE.
> > >
> > > So by "can't be named", do you mean by the MGC?  As in the
> > > MGC can't say "Add termination RTP/8" for ephemerals even
> > > though it knows the schema and knows that it's not in use
> > > (doesn't "exist")?
> > > So the MGC *MUST* use Add/CHOOSE for ephemerals?
> > >
> > > Thanks,
> > > -troy
> >
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 2 Feb 2001 13:28:37 -0500

> It's not at all clear (to me) that an MGC can't say
>
>         Add = ephemeral/1 { ... }
>
> if it knows the schema and knows ephemeral/1 is not in use
> (doesn't "exist").
>
It can

Brian

---

From: Dan Elbert <[email-masked]>
Date: Fri, 9 Feb 2001 14:30:12 -0500

Hi All

Is there a consensus in how to get the capabilities of the ephemeral
terminations without creating one ? And I think capabilities include media
as well as supported packages . Am I wrong ?
Thanks

Dan Elbert

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, February 02, 2001 1:28 PM
To: [email-masked]
Subject: Re: physical vs. ephemeral terminations

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 21 Feb 2001 15:24:18 -0500

I agree that in conjunction with allowing wildcard response
on wildcarded ephemerals in Audit, we would allow same in
ServiceChange.

Brian

> Sent: Wednesday, February 21, 2001 3:10 PM
> To: 'Willy Reheul'; 'megaco'
> HI Willy,
> Yes this sounds correct and should be legal. Since when the 
> MG registered
> itself with MGC ..it is a common understanding  what physical 
> and ephemeral
> terminations are present in the MG. If the board with some physical
> terminations go out, service change is generated for all of 
> them. This is
> true for ephemeral terminations also.
> 
> Best Regards.
> Madhubabu
> 
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Willy Reheul
> Sent: Wednesday, February 21, 2001 1:25 PM
> To: megaco
> Continuing with the same line of thinking ( ".....A MG knows 
> what is the
> range of ephemeral termination that it can create, etc. ......" ) can
> one then also assume that a Media Gateway shall send a 
> ServiceChange to
> its MGC when boards that realise these ephemeral terminations are
> going/taken out of service or return to in service, even when NO
> ephemerals are created on them ?
> Or can Media Gateways only do that when ALL ephemerals are affected by
> the ServiceChange ?
> 
> thanks,
> Willy.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 22 Feb 2001 08:52:54 -0500

The reason you want to execute a service change against
an ephemeral is to notify the MGC that the network
interface is down, and it can no longer ask the MG
to create that range of ephemerals.  That is the
point of ServiceChange - terminations out of service.

Yes, you can get an error when you try.  We could have
done that for physical terminations.  However, we
believed it useful for the MG to tell the MGC in
advance that terminations are being taken out of 
service.

In the same light, you want to be able to AuditCapabilities
of these terminations, so that you can discover, in 
advance of attempting an Add/Modify, what capabilities
the terminations have.  You could try it and get an error,
but that might be a hard way to find out what ephemerals
the MG supports!

Brian

> From: Kevin Boyle [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 4:27 PM
> To: Madhu Babu Brahmanapally
> Cc: 'Willy Reheul'; 'megaco'
> Unless the MGC explicitly audits looking for ephemeral 
> terminations, the MGC
> has NO idea about them until such time as they are created.  
> ServiceChanges on
> ephemerals sounds like a bad idea, as it could be confusing 
> to the MGC.
> 
> Further, Why would you want/need to perform ServiceChanges on 
> ephemerals?
> There are error codes in existence for denoting that a MG is 
> in service but not
> able to comply with requests due to resource limitations.  
> Ephemerals would
> fall under that category, IMHO.
> 
> Kevin
> 
> Madhu Babu Brahmanapally wrote:
> 
> > HI Willy,
> > itself with MGC ..it is a common understanding  what 
> physical and ephemeral
> > Continuing with the same line of thinking ( ".....A MG 
> knows what is the

---

From: "Alan Whitton" <[email-masked]>
Date: Mon, 26 Feb 2001 08:43:00 -0500

What to do on a "catastrophic" loss? Good question!
 
How does a gateway say, "I have lost this T1 card (or worse, this T3 card)
(or even worse, my ETHERNET card!).
 
Enquiring minds gotta know!
 
Alan

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B881:EXCH] 
Sent: Monday, February 26, 2001 5:51 AM
To: Rosen, Brian; Boyle, Kevin [NCRTP:3Z70:EXCH]; Madhu Babu Brahmanapally
Cc: 'Willy Reheul'; 'megaco'
Subject: RE: physical vs. ephemeral terminations

I never thought about it up to now -- I tended to think of single
terminations going out of service.  What context would the action containing
the ServiceChange for a group of terminations show? 

> From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, February 22, 2001 8:53 AM 
> To: Boyle, Kevin [NCRTP:3Z70:EXCH]; Madhu Babu Brahmanapally 
> > From: Kevin Boyle [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of 
> Willy Reheul