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

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

 



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]