Re: TSVDIR Review for draft-ohba-pana-relay-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Ohba-san,

Thank you so much for your quick response.
I agree with your comments and won't have further comments as long as
the doc is updated based on your response.

Regards,
--
Yoshifumi Nishida
nishida@xxxxxxxxxxxxxx

2011年6月6日5:59 Yoshihiro Ohba <yoshihiro.ohba@xxxxxxxxxxxxx>:
> Nishida-san,
>
> Thank you very much for reviewing the draft.
>
> Please see my comments below.
>
> (2011/06/06 17:39), Yoshifumi Nishida wrote:
>> Hello,
>> I've reviewed this document as part of the transport area
>> directorate's ongoing effort to review key IETF documents. These
>> comments were written primarily for the transport area directors, but
>> are copied to the document's authors for their information and to
>> allow them to address any issues raised. The authors should consider
>> this review together with any other last-call comments they
>> receive. Please always CC tsv-dir@xxxxxxxx if you reply to or forward
>> this review.
>>
>> Summary:
>>
>> This draft specifies protocol for PANA Relay Element that can relay
>> messages between a PaC and a PAA where they cannot reach each other.
>> The proposed function is simple and straightforward and useful.
>> I couldn't find any transport related issues in the draft.
>>
>>
>> Minor comments:
>>
>> Please consider clarifying the following points.
>>
>> 1)  I think clarifying communication model of this proposal will be
>> helpful for readers.
>>       It seems to me that a PRE should communicate only one PAA. But, can a PAA
>>       communicate multiple PREs?
>
> PANA allows multiple PAAs in an access network.  For example, RFC 5192
> defines a DHCP option to carry a list of PAA addresses and a PaC will
> choose one PAA to communicate with.  Similarly, there can be multiple
> PAAs in an access network with PREs.  In this case, a PRE will choose
> one PAA to communicate with for a given PaC.  Next, a PAA can
> communicate with multiple PREs.  We can clarify these in the draft.
>
>>
>> 2)  The draft seems to presume PRE to be a multi-homed node. But, is
>> this mandatory
>>        requirement? Is it possible to use single-homed node as a PRE?
>
> You are right, PRE can be either single-homed or multi-homed.  In
> fact, in ZigBee IP, each mesh router is a PRE having a single 802.15.4
> radio interface.  We can clarify this in the draft as well.
>
>>
>> 3)  Is it possible to place a PRE behind NAT? Is there any concern for this?
>>
>
> There are two cases, (i) a NAT between a PaC and a PRE, and (ii) a
> NAT between a PRE and a PAA.  I don't see a NAT issue specific to PANA
> relay for both cases.
>
>> 4)  How p2 (PRE-assigned UDP port number) is determined? Is it possible to use
>>       ephemeral port? If so, the protocol will need to be robust
>> against PRE rebooting.
>>       Similarly, can we use dhcp-ed address for IP2b?
>
> Yes, p2 can be ephemeral.  Since a PAA just uses the UDP and IP
> headers received from the relay to generate UDP and IP headers of its
> response PRY to the relay, I think the protocol is robust against PRE
> rebooting.  For the same reason, use of DHCP-ed address for IP2b
> works.  Even when IPsec is used between a PRE and a PAA, I think
> DHCP-ed address for IP2b works as long as IKEv2 identity for the PRE
> is not based on IP address.
>
> Kind Regards,
> Yoshihiro Ohba
>
>>
>> Regards,
>> --
>> Yoshifumi Nishida
>> nishida@xxxxxxxxxxxxxx
>>
>
>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]