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:yoshihiro.o...@toshiba.co.jp] >> Sent: Tuesday, May 31, 2011 5:22 PM >> To: Alper Yegin >> Cc: 'Jari Arkko'; 'Ralph Droms'; pana@ietf.org >> 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: pana-boun...@ietf.org [mailto:pana-boun...@ietf.org] On Behalf >> Of >>>> Jari Arkko >>>> Sent: Monday, May 30, 2011 9:48 AM >>>> To: Yoshihiro Ohba >>>> Cc: Ralph Droms; pana@ietf.org >>>> 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 >>>> Pana@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pana >>> >>> > > _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
