Re: [radext] RADIUS Extension, Getting Started

["Massameno, Dan" <[e-mail]>]

Oleg,
You are correct.  When a protocol (service) wants to scale out I believe the least effective way is to throw a completely different components (load balancers) at the problem, which creates additional components that network operators need to maintain. 

Load balancing with DNS SRV records or (optimally) load balancing right within the protocol seems to have multiple operational advantages.  This draft takes the latter approach.

--Dan

-----Original Message-----
From: Oleg Pekar <[e-mail]> 
Sent: Tuesday, July 7, 2020 09:36
To: Massameno, Dan <[e-mail]>
Cc: [e-mail]; Roman Danyliw <[e-mail]>; [e-mail]; Rob Wilton (rwilton) <[e-mail]>; Stefan Winter <[e-mail]>; Joe Clarke (jclarke) <[e-mail]>; OpsAWG-Chairs <[e-mail]>; Benjamin Kaduk <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [radext] RADIUS Extension, Getting Started

Hi Dan,
So the draft describes how a NAS connected to a specific RADIUS server can obtain from that server information about other RADIUS servers on the deployment, together with their priorities. Usually the RADIUS traffic distribution is configured and conducted by a Load Balancer network component (e.g. F5 Load Balancer). The mechanism described in this draft allows RADIUS servers on the deployment to balance traffic between them dynamically according to their load or other characteristics. However it requires implementation on both sides - on NAS and RADIUS server.

Is my understanding correct?

Thanks
Oleg

On Tue, Jul 7, 2020 at 12:13 PM Massameno, Dan <[e-mail]> wrote:
>
> Dear Ops and Management Area WG,
>
> There have been a number of great suggestions on where to post this document (Thanks Stefan!).   I'm now emailing [e-mail] and cc'ing [e-mail].
>
> The draft is posted here... 
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-massameno-radius-lb-00&amp;data=02%7C01%7Cda
> n.massameno%40yale.edu%7C34e34cfac5704a9c76c808d8227aa66c%7Cdd8cbebb21
> 394df8b4114e3e87abeb5c%7C0%7C0%7C637297257462087673&amp;sdata=gXtQoloW
> qvXsjTdwk%2B%2FuBe7WfpNs4LZYBeApKYNwqjQ%3D&amp;reserved=0
>
> Do I need an official IETF sponsor?  Would it help to try and get a vendor interested in implementing the protocol?  Cisco is our primary vendor at Yale University.  I was wondering if there is anyone on either of these working groups that communicates with Cisco people on a regular basis?
>
> Thank you for your help.
>
> --Dan
>
> -----Original Message-----
> From: Stefan Winter <[e-mail]>
> Sent: Friday, July 3, 2020 01:52
> To: Joe Clarke (jclarke) <[e-mail]>; Massameno, Dan 
> <[e-mail]>
> Cc: [e-mail]; Benjamin Kaduk <[e-mail]>; Roman Danyliw 
> <[e-mail]>; Rob Wilton (rwilton) <[e-mail]>; 
> OpsAWG-Chairs <[e-mail]>; [e-mail]
> Subject: Re: RADIUS Extension, Getting Started
>
> Hello Joe,
>
>
> thanks for reaching out. RADEXT is dormant since a number of years already. I'm afraid if you were to send the document that way, you would get little to no review.
>
>
> I think the best way forward is to take this to OPSAWG and send a mail to radext about the draft just in case.
>
>
> Greetings,
>
>
> Stefan Winter
>
>
> Am 30.06.20 um 17:21 schrieb Joe Clarke (jclarke):
> > Thanks, Dan.  I’m also copying the radext-chairs to get their perspective on this.
> >
> > Joe
> >
> >> On Jun 30, 2020, at 11:03, Massameno, Dan <[e-mail]> wrote:
> >>
> >> Warren,
> >>
> >> I have the RADIUS extension draft now posted:
> >> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ft
> >> oo 
> >> ls.ietf.org%2Fhtml%2Fdraft-massameno-radius-lb-00&amp;data=02%7C01%
> >> 7C 
> >> dan.massameno%40yale.edu%7Cc0b3c01a3a9d44d004c308d81f152ef2%7Cdd8cb
> >> eb 
> >> b21394df8b4114e3e87abeb5c%7C0%7C0%7C637293523139392341&amp;sdata=7d
> >> Op
> >> ZmU5Xsj2tusf2Fiukqv1oxd2b8uL4Po%2BI04hw%2BE%3D&amp;reserved=0
> >>
> >> Abstract
> >>
> >>   This document describes a method for a Network Access Server (NAS) to
> >>   dynamically discover all available RADIUS servers.  It defines a new
> >>   message type within the STATUS-SERVER message, which is requested by
> >>   the NAS and provided by the RADIUS server.  The NAS is then able to
> >>   load balance its RADIUS messages across multiple RADIUS servers based
> >>   on priority and weight supplied by the initial server.
> >>
> >> Base on the draft do you have a better idea on if this should be posed into RADEXT or OPSAWG?  I must admit I am not familiar with either of these groups.
> >>
> >> Thank you for your help.
> >>
> >> --Dan
> >>
> >> -----Original Message-----
> >> From: Massameno, Dan
> >> Sent: Thursday, June 25, 2020 10:56
> >> To: Rob Wilton (rwilton) <[e-mail]>
> >> Cc: Benjamin Kaduk <[e-mail]>; Roman Danyliw <[e-mail]>; 
> >> OpsAWG-Chairs <[e-mail]>; Warren Kumari 
> >> <[e-mail]>
> >> Subject: RE: RADIUS Extension, Getting Started
> >>
> >> Rob,
> >> Thank you and the extended team for all your help.  I have uploaded draft-massameno-radius-lb to the I-D Submission system.  Also attached is the PDF version.
> >>
> >> I'm very much interested in seeing how the process goes from here.  Please let me know how I may be of assistance.
> >>
> >> --Dan
> >>
> >> -----Original Message-----
> >> From: Warren Kumari <[e-mail]>
> >> Sent: Monday, June 22, 2020 18:00
> >> To: Rob Wilton (rwilton) <[e-mail]>
> >> Cc: Benjamin Kaduk <[e-mail]>; Massameno, Dan 
> >> <[e-mail]>; Roman Danyliw <[e-mail]>; 
> >> OpsAWG-Chairs <[e-mail]>
> >> Subject: Re: RADIUS Extension, Getting Started
> >>
> >> On Mon, Jun 22, 2020 at 1:06 PM Rob Wilton (rwilton) <[e-mail]> wrote:
> >>> Hi Ben,
> >>>
> >>> Good catch re Radext, copying Warren.  Warren, the question is whether RADEXT is still active and taking new work, or whether it should go to OPSAWG instead?  I have a slight concern whether we will get enough interest for this work in OPSAWG ...
> >> Without knowing a bunch more about the draft I don't really think that this is a question that I can usefully weigh in on.
> >>
> >> If it is an extension to RADIUS/is heavily RADIUS focused, then RADEXT is probably the right place -- but, it could always be aimed at RADEXT (put -radext- in the draft name), but we can try and stir up some interest in OPSAWG. If it turns out that it is RADIUS related, and RADEXT doesn't want to pick it up and run with it, perhaps that's a strong signal that RADEXT should be closed...?
> >>
> >> W
> >>
> >>> Regards,
> >>> Rob
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Benjamin Kaduk <[e-mail]>
> >>>> Sent: 21 June 2020 03:42
> >>>> To: Massameno, Dan <[e-mail]>
> >>>> Cc: Rob Wilton (rwilton) <[e-mail]>; Roman Danyliw 
> >>>> <[e-mail]>; OpsAWG-Chairs <[e-mail]>
> >>>> Subject: Re: RADIUS Extension, Getting Started
> >>>>
> >>>> On Fri, Jun 19, 2020 at 12:58:12PM +0000, Massameno, Dan wrote:
> >>>>> Rob,
> >>>>> This sounds great.  With the links provided by Roman I am 
> >>>>> reviewing the
> >>>> literature to make sure my draft has everything it needs to start 
> >>>> the process.  I found references to xml2rfc and kramdown, which I 
> >>>> also want to run it through.
> >>>>> Thank you for your help.  I would be happy to have someone take 
> >>>>> a look
> >>>> before it's posted.  As soon as I have it formatted correctly 
> >>>> I'll send it over.  Is there someone in particular I should send it to?
> >>>>
> >>>> I would recommend uploading the internet-draft to the IETF 
> >>>> datatracker at 
> >>>> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>> Fd
> >>>> a
> >>>> tatracker.ietf.org%2Fsubmit%2F&amp;data=02%7C01%7Cdan.massameno%4
> >>>> 0y
> >>>> a
> >>>> le.edu%7C112cacc6da6a40e6560708d816f7c0b9%7Cdd8cbebb21394df8b4114
> >>>> e3
> >>>> e
> >>>> 87abeb5c%7C0%7C0%7C637284600637313249&amp;sdata=EkkSwHAB%2BAV3XQDz%2FsYJMsBLiKymz6n4BROVWGbg7Yg%3D&amp;reserved=0 and then sending a link to that document to both [e-mail] and [e-mail].  It's also okay to skip the first part and send the document itself to those addresses.
> >>>>
> >>>> The radext (RADIUS Extensions) working group is not very active 
> >>>> at the moment, which is why I agree with the others' 
> >>>> recommendations to ask the OPSAWG working group chairs' advice as well.
> >>>>
> >>>> Hope this helps,
> >>>>
> >>>> Ben
> >>
> >>
> >> --
> >> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> >> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
> >>   ---maf
> _______________________________________________
> radext mailing list
> [e-mail]
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fradext&amp;data=02%7C01%7Cdan.massamen
> o%40yale.edu%7C34e34cfac5704a9c76c808d8227aa66c%7Cdd8cbebb21394df8b411
> 4e3e87abeb5c%7C0%7C0%7C637297257462087673&amp;sdata=jaaVVmgUe8Y2uOermp
> AKYq6iM6OQcEJCUMNZ%2F8CGw6k%3D&amp;reserved=0