Subject: RE: Tunnel-Medium-Type value for FR and ATM

From: "Shriver, John" <[email-masked]>
Date: Thu, 20 Apr 2000 13:48:02 -0700

The medium is inherent in the Tunnel-Server-Endpoint.  That is a "name" that
encodes a interface and medium.  So the tunnel initiatior must have a
mapping from that name to something it understands.
 
What are we going to do for change control if we make an attribute that
includes Frame Relay and ATM when someone wants to add a new interface, say
G.shdsl?  It's endless.
 
Plus, knowing the medium still tells you absolutely NOTHING when you have
two interfaces of the same medium.  It adds no value above
Tunnel-Server-Endpoint.

-----Original Message-----
From: Verma, Rohit (US - Chicago) [mailto:[email-masked]]
Sent: Thursday, April 20, 2000 4:40 PM
To: Shriver, John; 'Verma, Rohit (US - Chicago)'; [email-masked]; Madhvi
Verma; [email-masked]
Subject: RE: Tunnel-Medium-Type value for FR and ATM

John I see your point however, we should definitely have an attribute that
can be used to specify what medium to use for the tunnel, because the TI can
not take that decision on its own.

Regards 
Rohit Verma 
Deloitte Consulting 
180, N. Stetson Avenue 
Chicago, Illinois 60601 
Phone:312-374-2475 

-----Original Message----- 
From: Shriver, John [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, April 20, 2000 2:57 PM 
To: 'Verma, Rohit (US - Chicago)'; [email-masked] <mailto:[email-masked]> ;
Madhvi Verma; 
[email-masked] 
Subject: RE: Tunnel-Medium-Type value for FR and ATM 

As a co-author of the RFC (and author of the text in question), note that 
when Tunel-Medium-Type isn't IPv4 or IPv6, Tunnel-Client-Endpoint and 
Tunnel-Server-Endpoint are string names.  Freeform.  Not structured 
according to any rule based on the value of Tunnel-Medium-Type.  Note that 
Tunnel-Client-Endpoint can be an address, or an interface, as necessary. 
  
These strings are tags that refer to some part of the tunnel initiator's 
configuration database, which indicates the interface to be used and the 
endpoint theron.  It's done this way because there is no IETF standard 
syntax for naming interfaces.  
  
Yes, this does mean that you have to coordinate the configuration of the 
RADIUS server and the RADIUS client.  But by making it be this way, you can 
serve three different brands of RADIUS clients with one RADIUS server.  If 
the Ascend RADIUS client wanted a Tunnel-Client-Endpoint in the format 
"FrameRelaySlot3:Port4", and the Cisco RADIUS client wanted "Frame Relay 
3/4", you would be screwed.  The RADIUS server could not provide an answer 
that was correct for both.  By making it clear that it must be a tag 
indendpendent from the configuration of any particular product, you're not 
screwed in this case. 
  
I put this in because when we were Shiva, we had to add mappings to map our 
configuration to Ascend syntax for some of their proprietary attributes that

we implemented.  I wanted this standard to be vendor-neutral, and this was 
the simplest way to do that. 
  
 -----Original Message----- 
From: Verma, Rohit (US - Chicago) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, April 20, 2000 12:01 AM 
To: [email-masked]; Madhvi Verma; [email-masked] 
Subject: RE: Tunnel-Medium-Type value for FR and ATM 

Please see comments below. 
  
Regards 

Rohit Verma 
Deloitte Consulting 
180, N. Stetson Avenue 
Chicago, Illinois 60601 
Phone:312-374-2475 

-----Original Message----- 
From: Glen Zorn [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, April 19, 2000 8:30 PM 
To: Verma, Rohit (US - Chicago); Madhvi Verma; [email-masked] 
Subject: RE: Tunnel-Medium-Type value for FR and ATM 

The mediuam-type field is a guideline to the Tunnel Initiator what to expect

in the Tunnel Endpoint Address field. 
I do agree with you that it does not clearly capture the medium (For 
Example: E.164 is the addressing standard and it does not specify (SMDS, FR 
or ATM). 

Is it really necessary to do so, though?  If so, why? 
[Rohit Verma] 

Yes, it is important for tunnel initiators (TI) that support both ATM and FR

type interfaces. When a TI receives a RADIUS accept with tunne type set to 
L2TP and the medium type to an E.164 address, it needs to figure out what 
interface (FR or ATM) to use for the tunnel. 

Pardon my ignorance but I am not sure if E.164 address on its own can be 
used to do that distinction. Can anybody confirm that ? 

May be we need to add a more specific value to the set of AVPs retrieved 
from RADIUS. 

Regards 

Rohit Verma 
Deloitte Consulting 
180, N. Stetson Avenue 
Chicago, Illinois 60601 
Phone:312-374-2475 

-----Original Message----- 
From: Madhvi Verma [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: Wednesday, April 19, 2000 1:45 PM 
To: [email-masked] 
Subject: Tunnel-Medium-Type value for FR and ATM 

Hi, 
What do you use as the tunnel-medium-type (RADIUS attribute :65) value for 
the 
following media? 
FR: 
AAL5: 

The draft "draft-ietf-radius-tunnel-auth-09.txt" mentions the following 
address 
values : 
       1      IPv4 (IP version 4) 
       2      IPv6 (IP version 6) 
       3      NSAP 
       4      HDLC (8-bit multidrop) 
       5      BBN 1822 
       6      802 (includes all 802 media plus Ethernet "canonical format") 
       7      E.163 (POTS) 
       8      E.164 (SMDS, Frame Relay, ATM) 
       9      F.69 (Telex) 
       10     X.121 (X.25, Frame Relay) 
       11     IPX 
       12     Appletalk 
       13     Decnet IV 
       14     Banyan Vines 
       15     E.164 with NSAP format subaddress 

Does this mean that the value is addressing dependent, and not media 
dependent ! 
Inputs appreciated? 

Madhvi

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 20 Apr 2000 22:31:14 -0400

This rings of the Sub-Address argument of long ago. I am inclined to
agree with John here that freeform strings are best when there is no
clear IETF addressing standard.