Subject: nasreq NAS Package for megaco/H.248 returned to IETF

From: Chip Sharp <[email-masked]>
Date: Fri, 18 Feb 2000 10:57:32 -0500

FYI,
At the latest SG16 meeting discussing the megaco/H.248 protocol, it was 
decided that the IETF would be the best place to develop the NAS package 
defining how to control NASes using the megaco protocol.

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

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 22 Feb 2000 05:43:00 -0800 (PST)

Well, there goes any hopes of wrapping up this WG anytime soon :)

PatC

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 22 Feb 2000 18:47:00 -0800

NASREQ (via ISOC) can always respond to SG16 and say that H.248 "as is" 
works fine for NAS's and no other response is required. In fact any other 
response would invalidate the way NAS's are supposed to work.

Those who read the MEGACO list know my arguments. If not, I'd be happy to 
elucidate in Adelaide.

---

From: Chip Sharp <[email-masked]>
Date: Wed, 23 Feb 2000 22:13:46 -0800

Yes, please read through the megaco archives if you wish to know our 
disagreement.

I agree with Matt that NASes work fine with current operation.  The main 
disagreement I believe is that i believe enhancements can be made to the 
NAS package to allow other capabilities.

Basically, though there is no NAS package currently defined for 
megaco.  SG16 doesn't want to do any more work to define the 
package.  Currently it is just a draft.

But perhaps this doesn't fall within the NASREQ charter and should be the 
subject of a separate BOF.

chip

---

From: "David Mitton" <[email-masked]>
Date: Wed, 23 Feb 2000 15:10:21 -0500

ummm...

>Yes, please read through the megaco archives if you wish to know our 

that's only 35MB of text in my mail reader.  But please do not attempt to 
explain here.  Just direct us to the prime temporal location of the discussion.

>NAS package to allow other capabilities.

You know, "package" is a real general term in english.  I usually use UPS 
or FedEx.  Can you explain in about 64 words or less what this means to megaco?

>subject of a separate BOF.

That is hard to assess until we understand the issue. It might be more 
expedient to use the Nasreq group that is already formed, than to go 
through the overhead of starting another, if this is a fairly simple item.

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

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Carrier Packet Solutions, Preside             978-288-3030 FAX
Billerica, MA 01821                    [email-masked]

---

From: Chip Sharp <[email-masked]>
Date: Thu, 24 Feb 2000 00:54:20 -0800

>explain here.  Just direct us to the prime temporal location of the discussion.

Don't you keep 35 Mbytes in your In box in Eudora?  ;-)

The latest round of discussion can be found in a thread titled
"Basic Package and NAS"  which occured between 10/6/99 and 10/18/99

The megaco archive search page at 
http://standards.nortelnetworks.com/scripts/wa.exe?S1=megaco

can be used to search for this.

>or FedEx.  Can you explain in about 64 words or less what this means to megaco?

Megaco defines a base protocol for allowing a Media Gateway Controller to 
control what are called "terminations" on Media Gateways.  A "termination" 
could be physical (e.g., DS0) or "ephemeral"  (e.g., RTP endpoint).  The 
specific parameters, events and signals for a particular type of 
termination are defined in "packages."  A package defines the events that 
can be detected on a termination (e.g., Dial tone), signals to be 
transmitted on a termination (e.g., dtmf, dial tone, etc.) and parameters 
that can be used to configure the termination (e.g., what codec to use on a 
RTP termination).

A NAS package would define a NAS termination and would define the events, 
signals and configuration parameters that a MGC could use to control a NAS 
(acting as a media gateway).  Basically,  the MGC would handle the call 
control and then configure the NAS to accept the call.  The NAS would then 
do its normal PPP (or whatever) and RADIUS thing.

The sticking point seems to be whether or not the protocol would allow the 
MGC to send down various configuration parameters (e.g., modem type, AAA 
server to use, L2TP LNS to connect to , etc.) based on the Calling/Called 
number (or other call info).

If something is done in this area, it should probably be done in close 
cooperation with the megaco group.

>>>works fine for NAS's and no other response is required. In fact any 
>>>other response would invalidate the way NAS's are supposed to work.
>>>
>>>Those who read the MEGACO list know my arguments. If not, I'd be happy 
>>>to elucidate in Adelaide.
>>>
>>>

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 23 Feb 2000 17:52:10 -0800

>explain here.  Just direct us to the prime temporal location of the discussion.

I wouldn't wish reading the MEGACO archive on my worst enemy. :)

Please add some time in the NASREQ agenda for me to discuss this in 
Adelaide. I'm not going to try on email. No way.

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 23 Feb 2000 18:03:13 -0800

>number (or other call info).

Yes, one of my arguments is that a lot of work has gone into developing the 
NAS-Radius interface/protocol to make AAA items such as L2TP Radius 
attributes work well. By redirecting or encapsulating or translating those 
attributes into another protocol and having them pass through an 
intermediate device/function, we are stepping into dangerous territory for 
no good reason.

>cooperation with the megaco group.

Ipso facto. What I've been pushing for in Megaco is that they work closely 
with NASREQ where the proper experts are.

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 Feb 2000 08:09:08 -0800

> Adelaide.

i look forward.  is there a differing view that should also be soliticted to
speak?

randy

---

From: Chip Sharp <[email-masked]>
Date: Thu, 24 Feb 2000 09:36:39 -0800

If I make it to Adelaide, I can help out with that.

Chip

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 24 Feb 2000 15:33:01 -0800

Chip and I know of a couple MEGACO folks who could fill in if Chip can't 
make it.

---

From: Chip Sharp <[email-masked]>
Date: Thu, 24 Feb 2000 16:31:07 -0800

Yes, I'm sure. I'm planning to be there, but I'm kinda burned out on travel 
now.

BTW, if the group is expecting a big oppositional debate on this issue 
might be disappointed to learn that I agree with just about everything Matt 
has said on the issue.
:-)

Chip

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 24 Feb 2000 16:44:51 -0800 (PST)

Oh, if you are looking for opinions, the IETF is normally a pretty easy place
to find some :)

PatC