Re: [Pana] Explicit error indication

[Yoshihiro Ohba <[e-mail]>]

Alper,

If Jari is ok with your suggested text, there is no reason for me to
object it.

Regards,
Yoshihiro Ohba


(2011/06/01 17:32), Alper Yegin wrote:
> 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
>>>
>>>
> 
>