Hi Robert, all I am in favour to leave it out completely. I think the text is fine without that sentence.
Best regards. On Dec 1, 2010, at 4:18 PM, Robert Cragie wrote: > Hi Rafa, > > I agree it is not relevant relevant for *switching* to non-relay operation > but may be necessary to continue a session when communicating directly > (in an IP sense) with the PAA. > > I suggest we either leave it out completely: > > "If direct IP routing becomes available and the PaC is notified about the > PAA's IP address using an out-of-band mechanism that is not specified in this > document, the PaC may choose to directly communicate with the PAA without use > of the relay operation." > > or change it to the following to suggest it may still have a place: > > "If direct IP routing becomes available and the PaC is notified about the > PAA's[ IP address using an out-of-band mechanism that is not specified in > this document, the PaC may choose to directly communicate with the PAA > without use of the relay operation. The PaC IP address update procedure > defined in [RFC5191] may additionally need to be performed using[1] the > directly reachable IP address of the PAA." > > [1] "be performed to switch to non-relay operation, using" -> "need to be > performed using" > > Robert > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 01/12/2010 2:30 PM, Rafa Marin Lopez wrote: >> >> Hi all, >> >> my apologies for answering a bit late to this. >> >> I do not completely understand the sentence: >> >> "The PaC IP address update procedure defined in [RFC5191] may additionally >> be performed to switch to non-relay operation, using the directly >> reachable IP address of the PAA." >> >> I think that the PaC IP address update procedure defined in [RFC5191] is >> useless for this scenario where the PAA "changes" its IP address. I >> believe what PaC must simply do is to update the IP address in the PANA >> session with the PAA's IP address obtained with this out of band mechanism. >> >> This, my suggestion would be to remove that sentence. >> >> Best regards. >> >> El 01/12/2010, a las 14:50, Robert Cragie escribió: >> >>> Maybe I'm missing something but switching to direct communication has >>> nothing to do with a *change* in the PAA address. I would suggest the >>> following: >>> >>> "If direct IP routing becomes available[1] and the PaC is notified about >>> the PAA's[2] IP address using an out-of-band mechanism that is not >>> specified in this document, the PaC may choose to directly communicate with >>> the PAA without use of the relay operation. The PaC[3] IP address update >>> procedure defined in [RFC5191] may additionally[4] be performed to switch >>> to non-relay operation, using the directly reachable IP address of the PAA." >>> >>> [1] Removed ZigBee IP reference >>> [2] "the change of PAA's" -> "the PAA's" >>> [3] Added PaC as per Alper's suggestion >>> [4] Added "additionally" as this is independent from getting the PAA address >>> >>> Comments? >>> Robert Cragie (Pacific Gas & Electric) >>> >>> Gridmerge Ltd. >>> 89 Greenfield Crescent, >>> Wakefield, WF4 4WA, UK >>> +44 1924 910888 >>> +1 415 513 0064 >>> http://www.gridmerge.com >>> >>> >>> On 30/11/2010 9:20 PM, Alper Yegin wrote: >>>> >>>> Looks good to me. >>>> >>>> One minor update: >>>> >>>> "The IP address update procedure" --> "PaC IP address update procedure" >>>> >>>> >>>> Alper >>>> >>>> >>>>> -----Original Message----- >>>>> From: Yoshihiro Ohba [mailto:yoshihiro.o...@toshiba.co.jp] >>>>> Sent: Tuesday, November 30, 2010 3:52 AM >>>>> To: Alper Yegin >>>>> Cc: 'Rafa Marin Lopez'; pana@ietf.org; 'Ralph Droms'; >>>>> robert.cra...@gridmerge.com; 'Samita Chakrabarti'; 'Paul Duffy >>>>> (paduffy)' >>>>> Subject: Re: Switching to direct communication [was Re: PANA relay >>>>> draft] >>>>> >>>>> OK. How about the following change? >>>>> >>>>> Current text: >>>>> >>>>> "If direct IP routing becomes available (e.g., after the successful >>>>> PANA authentication as in the case of Zigbee IP), the PaC may >>>>> choose to directly communicate with the PAA without use of the relay >>>>> operation. The IP address update procedure defined in >>>>> [RFC5191] may be performed to switch to non-relay operation." >>>>> >>>>> Propose text: >>>>> >>>>> "If direct IP routing becomes available (e.g., after the successful >>>>> PANA authentication as in the case of Zigbee IP) and the PaC is >>>>> notified about the change of PAA's IP address using an out-of-band >>>>> mechanism that is not specified in this document, the PaC may choose >>>>> to directly communicate with the PAA without use of the relay >>>>> operation. The IP address update procedure defined in [RFC5191] may >>>>> be performed to switch to non-relay operation, using the directly >>>>> reachable IP address of the PAA." >>>>> >>>>> Yoshihiro Ohba >>>>> >>>>> (2010/11/29 21:10), Alper Yegin wrote: >>>>>> Rafa, >>>>>> >>>>>>> El 26/11/2010, a las 08:21, Alper Yegin escribió: >>>>>>> >>>>>>>>> Let me create a new thread on this specific topic. >>>>>>>>> >>>>>>>>> It has been identified that switching from relay to direct >>>>>>>>> communication requires not only change of PaC's address but also >>>>>>>>> change of PAA's address. >>>>>>>>> >>>>>>>>> But RFC 5191 supports change of PaC's address for a given PANA >>>>>>> session >>>>>>>>> but does not support change of PAA's address. >>>>>>>> Yes, RFC 5191 has an explicit support for that. >>>>>>>> >>>>>>>> >>>>>>>>> So it seems that switching to direct communication requires to go >>>>>>>>> through a full PANA authentication. >>>>>>>> I don't think that's necessary at all. >>>>>>>> >>>>>>>> If the PaC learns another (or new) IP address of the PAA by some >>>>> out- >>>>>>> of >>>>>>>> scope mechanism, then it can start using that IP address. And >>>>> that's >>>>>>> the >>>>>>>> case in Zigbee. >>>>>>> [Rafa] What I believed is that a new PANA authentication was >>>>> necessary >>>>>>> when you switch the PAA's interface, as Yoshi has mentioned. It does >>>>>>> not mean that it is the best option of course, but what happens is >>>>> that >>>>>>> there is no support for PAA's address change. I believe this >>>>> scenario >>>>>>> was not considered in RFC 5191. >>>>>> We didn't envision this scenario. Hence RFC 5191 is "silent" about >>>>> it. >>>>>> In other words, there is no explicit facility to realize that (PAA IP >>>>>> address change), and there is no prohibition against it either. Which >>>>> means, >>>>>> if some implementation/SDO/deployment can figure out a way to enable >>>>> that >>>>>> w/o breaking the RFC, it's OK. And that's the case with this Zigbee >>>>> Alliance >>>>>> usage. >>>>>> >>>>>> >>>>>>> In the same way that "In order to >>>>>>> maintain the PANA session, the PAA needs to be notified about the >>>>>>> change of PaC address.", I would expect a mechanism saying that: "In >>>>>>> order to maintain the PANA session, the PaC needs to be notified >>>>> about >>>>>>> the change of PAA address." >>>>>> We can say something to that affect in the relay I-D. >>>>>> >>>>>> Alper >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Alper >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> So if we mention "direct IP routing MAY be available" then we may >>>>>>> also >>>>>>>>> need to mention that "switching to direct communication requires a >>>>>>>>> full PANA authentication using the new PaC's and PAA's addresses." >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Yoshihiro Ohba >>>>>>>>> >>>>>>>>> >>>>>>>>> (2010/11/24 21:32), Alper Yegin wrote: >>>>>>>>>>> [Rafa] In my opinion, after the successful PAA authentication, I >>>>>>>>>>> believe that it would be better that PaC does not require the >>>>> PRE >>>>>>>>>>> anymore. In other words, the PaC and the PAA know each other. >>>>>>>>> Moreover >>>>>>>>>>> I assume that after the successful PAA authentication the PaC >>>>> will >>>>>>>>> be >>>>>>>>>>> able to contact directly the PAA without the assistance of the >>>>>>> PRE. >>>>>>>>> If >>>>>>>>>>> these assumptions are reasonable, there will not be PAA-initated >>>>>>>>>>> messages that go through the PRE. >>>>>>>>>> I think this spec shall not mandate or prohibit use of PRE after >>>>>>> the >>>>>>>>> first >>>>>>>>>> successful PANA auth. Spec shall allow both, and the consumers >>>>>>>>> (deployments, >>>>>>>>>> architectures) shall decide. >>>>>>>>>> >>>>>>>>>>>>> If direct IP routing becomes available (e.g., after the >>>>>>>>> successful >>>>>>>>>>>>> PANA authentication as in the case of Zigbee IP), >>>>>>>>>>>>> >>>>>>>>>>>>> [Rafa]. Is the PRE informed by the PAA?. If it is, how?. In >>>>>>> other >>>>>>>>>>>>> words, how is this enabled after a successful PANA >>>>>>> authentication? >>>>>>>>>>>> The PRE is not informed by the PAA when direct IP routing >>>>> becomes >>>>>>>>>>> available. >>>>>>>>>>> >>>>>>>>>>> [Rafa] I mean that it is mentioned that direct IP routing is >>>>>>>>> available >>>>>>>>>>> , how is this enabled after a successful PANA authentication? is >>>>>>> the >>>>>>>>>>> PaC enabled to use a non link-local IPv6 address?. >>>>>>>>>> I think the spec shall say "direct IP routing MAY be available". >>>>> In >>>>>>>>> the >>>>>>>>>> specific case of zigbee, PaC receives RA and configures a global >>>>>>> IPv6 >>>>>>>>>> address. Such details belong to zigbee spec. >>>>>>>>>> >>>>>>>>>>>>> On the other hand, what entity is acting as EP?. >>>>>>>>>>>>> >>>>>>>>>>>> An EP may reside in the PRE, or it could be a separate entity >>>>>>> from >>>>>>>>>>> the PRE. >>>>>>>>>>>>> the PaC may choose >>>>>>>>>>>>> to directly communicate with the PAA without use of the >>>>> relay >>>>>>>>>>>>> operation. >>>>>>>>>>>>> >>>>>>>>>>>>> [Rafa] However, it has been said that PaC that "From the PaC's >>>>>>>>>>>>> perspective, the PRE appears as the PAA." >>>>>>>>>>>>> This sentences seems to mean that PaC knows that it is talking >>>>>>>>> with >>>>>>>>>>>>> a relay first. >>>>>>>>>>>> The PaC may not know that it is talking with a relay first. >>>>>>> OTOH, >>>>>>>>>>>> the PaC may know, after successful PANA authentication, that it >>>>>>> was >>>>>>>>>>> talking with a relay, by using some out-of-band mechanism. But >>>>>>> this >>>>>>>>>>> does not mean that switching to direct communication is needed. >>>>>>> The >>>>>>>>>>> point here is that we try to describe possible cases as much as >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>>>> The IP address update procedure defined in [RFC5191] may >>>>>>>>>>>>> be performed to switch to non-relay operation. >>>>>>>>>>>>> >>>>>>>>>>>>> [Rafa] Who is sending this notification? >>>>>>>>>>>> The notification is generated locally by the node that has >>>>>>> updated >>>>>>>>> an >>>>>>>>>>> IP address. >>>>>>>>>>> >>>>>>>>>>> [Rafa] What is that node? the PAA? the PaC? both?. I mean to >>>>>>> switch >>>>>>>>> to >>>>>>>>>>> non-relay operation, under PaC point of view the PAA is >>>>> switching >>>>>>>>> the >>>>>>>>>>> IP address (PaC thought the PAA was the PRE but now it is the >>>>> real >>>>>>>>> PAA) >>>>>>>>>> That's right. Both PaC's and PAA's IP address are changing for >>>>> the >>>>>>>>> given >>>>>>>>>> PANA session. >>>>>>>>>> >>>>>>> ------------------------------------------------------- >>>>>>> Rafael Marin Lopez, PhD >>>>>>> Dept. Information and Communications Engineering (DIIC) >>>>>>> Faculty of Computer Science-University of Murcia >>>>>>> 30100 Murcia - Spain >>>>>>> Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es >>>>>>> ------------------------------------------------------- >>>>>>> >>>>>>> >>>>>> >> >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es >> ------------------------------------------------------- >> >> >> >> ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es -------------------------------------------------------
_______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
