[Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture

["Ahmad Muhanna" <amuhanna at nortel.com>]

Hi Pete,

> 
> Ahmad Muhanna wrote:
> > 2. The point here is not about Diameter as an AAA protocol, 
> however, 
> > it is about the concept of coupling the MIPv4 control 
> signaling to AAA 
> > signaling. Which many people do not think it is a good idea and 
> > believe that it is a deviation from RFC3344 initial MIPv4
> > registration procedure. Do not you agree?    
> 
> No, I don't.  Putting the Registration Request in the AMR is 
> a feature.
> It allows the registration to happen in one round-trip.

[Ahmad]
Well, I do not understand what you mean by a feature. Initial RRQ/RRP is
coupled with AMR/AMA, as a matter of fact they are carried in
attributes. In other words, we can not relay initial RRQ/RRP outside
AMR/AMA as per RFC3344. Even if you want to call it a feature, that
feature makes D-MIP4 architecture different from RADIUS and at the same
time makes AAA infrastructure more vulnerable.

>  
> > 6. Actually, we are going to publish a new revision of this 
> draft and 
> > address the scenario of allocating a HA in the visited 
> network. Have 
> > you looked into the difference between the RADIUS and D-MIP4 
> > performance in this scenario and what will happen if the MN happened
> > to retransmit?    
> 
> Obviously this scenario takes longer to process the RRQ and 
> so the chance of hitting a retransmission is greater.

[Ahmad]
Okay.. Then that is bad and has bad consequences on the AAA
infrastructure and on the current MIPv4 deployment. Operators, expects
the current network infrastructure to work, at least, better when
upgrading AAA to Diameter not to degrade their network performance and
start spending moneys on studies and tweaking mechanisms here and there
to compromise for the D-MIPv4 feature. IMO, that is not a bad feature
and we need to fix it.

>  
> >> I agree that a Diameter (or RADIUS, for that matter) 
> infrastructure 
> >> might take more than 1 second to respond to an AMR or an 
> >> Access-Request. It seems that the solution is to recommend 
> a longer 
> >> timeout value for the initial retransmission.  Another 
> solution would 
> >> be to allow the MN to complete its registration successfully by 
> >> receiving an RRP matching a previous RRQ (not just the 
> most recently 
> >> retransmitted one).
> >> 
> >> I don't think we should turn the MIP4 Diameter application into a 
> >> 2-round-trips protocol.  The goal of RFC4004 is to provide MIP 
> >> registration in one round-trip.
> >> 
> 
> -Pete
> 
> 


--
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/