Subject: Re: [radext] [[email-masked]] New Version Notification for draft-hartman-radext-bigger-packets-00.txt

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Feb 2014 16:08:27 -0500

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:
> comment. In the text, you state that: Clients will not
    Alejandro> typically be able to adjust and resend requests when this
    Alejandro> error is received.

    Alejandro>    Having that expectation in mind, and wondering what
    Alejandro> the actual impact of just dropping the entire session is,
    Alejandro> wouldn't it be more simple to just send an Access-Reject
    Alejandro> code with the new attribute indicating the reason
    Alejandro> (eg. packet over 3500 octets), instead of defining a new
    Alejandro> code?  The client would be able to re-start the session
    Alejandro> using smaller packets, RADIUS fragmentation or just
    Alejandro> desisting from it.  Of course, this would require to
    Alejandro> start over with the current session.  But since you don't

This is only possible for access-request packets.  You cannot send an
access-reject in response to an accounting packet for example.
However, we could send an access-reject rather than a new code for
packet too big.

I don't mremember if we discussed this at IETF 88 nor what comments we
got.

It seems clear to me that we need the new code  in the
non-access-request cases.
One potential issue with access-reject is that it is end-to-end and this
is a transport issue.
On the other hand, perhaps tdhe failure should be end-to-end.

I'd appreciate thoughts from the WG on this.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 15 Feb 2014 17:37:43 -0500

> However, we could send an access-reject rather than a new code for

  If the packet is too big, it's likely to be dropped entirely.  So it
doesn't really matter what the reply is.

> On the other hand, perhaps tdhe failure should be end-to-end.

  IMHO, the failure should be hop by hop.  It's unfortunately the RADIUS
way.

  The issue then becomes how to tell hop 1 failures from hop 2 failures.
 RADIUS can't do that, so you're pretty much SoL.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Feb 2014 10:57:38 -0500

If we want the failure to be hop-by-hop then we want a new code.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Feb 2014 12:16:34 -0500

> If we want the failure to be hop-by-hop then we want a new code.

  I agree.

  Alan DeKok.