Re: [Pana] Explicit error indication

["Alper Yegin" <[e-mail]>]

Yoshi,

I'm afraid my worries are coming true. I was worried that this would grow on
us. Now we are talking about supporting different classes of error cases.
Most probably we'd have to define bunch of error types. We'll try to be
complete there. And then there are also case handling (e.g., whether session
id is available, etc.). On top of that, defining general error messaging in
this "extension" draft is not the right thing. That better have a separate
base, if we decide to do such a work. One more thing: this impacts the PaC.
Relaying did not have any impact on the PaC until that.

On top of that, defining such error signaling is something we had debated
long time in the base spec development and had agreed to remove. And again
we had the same discussion in the context of PANA-relay, and then again
decided to remove. Both after long debates and coming to conscious
decisions. Such error messages are not useful for protocol operation, it is
only good for debugging. As far as I know, we don't do these kind of error
signaling in our IETF protocols. Silent discarding and optionally logging an
error is what we do.

I'm recapping Jari's email below. I'd like to go with his "I don't mind that
we skip specifying this functionality now.", and take care of his "At the
very least, we should
specify what happens if you end up receiving an already relayed message." as
follows:


	If the PRE is not configured with any PAA information, it SHALL
silently discard the 
	incoming PANA messages and it MAY log an error.

	If the PRE receives an PRY message from another PRE, then it SHOULD
silently discard 
	that message and it MAY log an error. Future extensions may define a
multi-hop relay 
	procedure which can change the PRE behavior in this respect.


What do you think?

Alper


------- Jari's email ----------------

> This specification assumes there is at most one PRE between the PaC
> and the PAA.  Performing relay operation on a PANA message that is
> already relayed (i.e., carried inside a PRY message) is out-of scope
> of this specification.
>   

This is problematic, as it may occur. At the very least, we should
specify what happens if you end up receiving an already relayed message.
Loops may also occur.

I don't mind that we skip specifying this functionality now. What I'm
worried about is the upgrade to doing something better in the future. If
we don't do something now, how do we know tomorrow that our messages are
being correctly relayed?

I would recommend the following behaviour, actually. If the relay
detects an already existing relay attributes or has no configuration to
actually be able to send something to a PAA, it would reply with the
relevant PANA message and set Result-Code to <TBD = Relay cannot route
message>. This would allow the client to at least know something is
wrong. This would also allow the relay to signal other erroneous
conditions to the client.

-----------------------------






> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[e-mail]]
> Sent: Tuesday, May 31, 2011 5:22 PM
> To: Alper Yegin
> Cc: 'Jari Arkko'; 'Ralph Droms'; [e-mail]
> Subject: Re: [Pana] Explicit error indication
> 
> Hi Alper,
> 
> In the first part of your email, PRE-to-PRE error indication is
> mentioned.  I only considered PRE-to-PaC error indication in my
> previous email, but I think we can support PRE-to-PRE error indication
> as well.  I think both PRY with an error indication AVP and a new
> error indication message can be workable here, but
> a Result-Code AVP may not be appropriate for temporal errors (see
> below) because the use of a Result-Code AVP is to indicate whether EAP
> authentication was completed successfully.
> 
> For PRE-to-PaC error indication, I thought that using a
> Result-Code for that purpose has an impact on existing RFC 5191
> implementations that do not expect to receive a Result-Code in the
> first PAR with the 'S' bit set, because in the current use of a
> Result-Code is for the last PAR message with the 'C' bit set, but RFC
> 5191 explicitly prohibits to set both the 'S' bit and 'C' bit at the
> same time.  So I thought defining a new message (just as we define
> PRY) has less impact on RFC 5191 as an implementation that does not
> support the new message will simply discard the message and the
> initial PAR-PAN exchange part is kept intact.  Maybe I am missing
> something.  If a Result-Code in the initial PAR works without
> impacting on RFC 5191, then I am also ok with it.
> 
> Regarding types of error, some error can be temporary.  For example,
> temporal buffer shortage or temporal routing fluctuations (e.g., even
> if the PRE has the  PAA information there may be no next hop towards
> the PAA), both can be recoverable (so a PaC may retry PANA
> authentication later on).  I think it would be good we can
> support both non-temporal and temporal errors as long as the impact on
> RFC 5191 is low.
> 
> Regarding which session identifier should be used for a new message
> for error indication, I think the session id contained in the message
> that caused the error should be used.  When the error indication
> message is sent in response to PCI or PRY, then session id is zero,
> otherwise non-zero.
> 
> Regards,
> Yoshihiro Ohba
> 
> 
> 
> (2011/05/30 17:52), Alper Yegin wrote:
> >
> >
> > For relaying already relayed messages... The Result-Code AVP
> (something like
> > MULTIPLE-RELAYING-DISALLOWED) would be included in the PRY message
> sent from
> > one PRE to the other.
> > In response to a PRY that was received from the latter one.
> >
> > How seq no and PANA SA are used for PRY is already defined. There'd
> not be
> > any special considerations here.
> >
> > Right?
> >
> >
> > The other Result-Code would be something like RELAY-REJECTED-NO-PAA-
> INFO.
> > This can be carried in a PAR in response to the PCI received from the
> PaC.
> > (Defining it in response to any other message is less justified [why
> would
> > PER lose the PAA info in the middle of a session relaying?], and also
> less
> > trivial [what would the session id be set to??]
> >
> > I'm trying to see if we can achieve this with the minimum impact.
> >
> > I don't think we need a new message. We just need new Result-Codes.
> >
> >
> > We shouldn't have to touch RFC 5191.
> >
> > Alper
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> >> Jari Arkko
> >> Sent: Monday, May 30, 2011 9:48 AM
> >> To: Yoshihiro Ohba
> >> Cc: Ralph Droms; [e-mail]
> >> Subject: Re: [Pana] Explicit error indication
> >>
> >> That would work for me.
> >>
> >> Jari
> >>
> >> Yoshihiro Ohba kirjoitti:
> >>> Let me start a new thread on this subject.
> >>>
> >>> I remember a ZigBee member asked if explicit error indication can
> be
> >>> sent by a PRE when a PANA message cannot be relayed for some
> reasons
> >>> (buffer shortage, no route to PAA, etc.).  I think it would be
> useful
> >>> to add such a feature if there is little impact to RFC 5191 to
> >> support
> >>> the feature, as it could reduce unnecessarily retransmissions of
> PCIs
> >>> from PaCs.  Reduce unnecessarily retransmissions may be good for
> >>> resource constrained networks such as ZigBee.
> >>>
> >>> Explicit error indication can be by means of a new PANA message or
> a
> >>> new Result-Code.
> >>>
> >>> Processing explicit error indication is like handling
> >>> exceptions/interruptions.  So considerations would be necessarily
> >>> not to interfere with the PANA sequence number processing rule.
> >>> Especially this would be the case where an error indication is
> >>> protected by a PANA SA.  I would expect that we don't need to
> support
> >>> protected error indication as it would require a complex sequence
> >>> number processing rule such as a separate sequence number space
> >>> dedicated to error indications.
> >>>
> >>> IMHO, a new PANA message (e.g., PANA-Error-Indication)
> >>> carrying sequence number of zero (0) may be simple, something like
> >> this:
> >>>
> >>> PaC     PRE
> >>>      --->      PCI
> >>>      <---     PEI[Error-Code="Relay-failed"] // seqno=0
> >>>
> >>> PEI message is unprotected and it can be used only as a hint.
> >>>
> >>> Regards,
> >>> Yoshihiro Ohba
> >>>
> >>> (2011/05/26 13:58), Jari Arkko wrote:
> >>>
> >>>> Yoshihiro,
> >>>>
> >>>>
> >>>>> Let me give some time to analyze the impact of this
> recommendation.
> >>>>>
> >>>>>
> >>>> Ok. I' not claiming that my solution is necessarily the way
> forward,
> >> but
> >>>> I am worried about the issue.
> >>>>
> >>>> Jari
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Pana mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/pana
> >
> >