RE: Posted a new copy of CPE Rtr draft

["Hemant Singh (shemant)" <shemant@cisco.com>]

Teemu,

Thanks for the review.  Please see inline below between <hs> and </hs>.

-----Original Message-----
From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] 
Sent: Friday, March 20, 2009 10:17 AM
To: Hemant Singh (shemant); v6ops@ops.ietf.org
Cc: Wes Beebee (wbeebee)
Subject: RE: Posted a new copy of CPE Rtr draft

Hi,

Thank you for the revision. I read it trough and I have following
comments/questions/nits:

- 5.3.1: I guess SLAAC can also be used to aquire global IPv6 address
for WAN interface as said in 5.?

<hs>
Yes. We will fix the statement sentence in 5.3.1 for SLAAC.
</hs>

- After reading the document I was not completely certain what level of
DHCPv6 server functionality it is envisioned to be implemented by CPE.
In 5.5. it is said that CPE router can pass DNS server information to
clients -> does this mean CPE router should have at least Stateless
DHCPv6 server in order to serve these queries? Or alternatively, is it
ok for CPE router to act as DHCPv6 relay and relay information requests
to SP? Which way is preferred (MUST/SHOULD/MAY..)? I understand stateful
DHCPv6 server functionality is a question mark still.

<hs>
Yes, as you say, at least a stateless DHCPv6 server will be needed to
pass parameters like DNS IP to the clients in the home.  However, soon
as CPE Rtr supports cascading CPE Rtrs or the Rtr is sub-delegating more
PDs than what the SP gave to the Rtr, then the CPE Rtr has got to
support stateful DHCPv6 server - this is obvious.  A relay agent won't
suffice if multiple prefixes are delegated to LAN clients.
</hs>

- You mention DNS64 in the document (8.6), do you envision CPE router
could implement NAT64 as wall? I think NAT64 could be left out or just
mentioned shortly - without going into details (so that completing this
work would not pend on NAT64 work's progress), but how do you see?

<hs>
We have deliberately stayed away from NAT64 so far.  However, if a CGN
document says the CGN cannot support NA64 and the CPE Rtr must do so, we
are open to adding NAT64 to the CPE Rtr.
</hs>

- Last paragraph of 7 says "A route SHOULD be added..." and later:"...
null route MAY be automatic.". Should it say "A _null_ route SHOULD be
added"?  I was unclear which route should be added to prevent routing
loops, or just a route.

<hs>
It's the same null route.  We will make the text better as follows:

[Old text]
A route SHOULD be added to the routing table (to prevent routing loops)
that is lower priority than any route except the default route. The
choice to drop the packet or send an ICMPv6 Destination Unreachable to
the source address of the packet is implementation-dependent. The
installation of the null route MAY be automatic. 

[New text]
A null route SHOULD be added to the routing table (to prevent routing
loops) that is lower priority than any route except the default route.
The choice to drop the packet or send an ICMPv6 Destination Unreachable
to the source address of the packet is implementation-dependent. The
installation of this null route MAY be automatic.
</hs>

- 7.1. In 3GPP case the /64 prefix is not only for LAN interfaces, but
also for the WAN interface. Thus I'd rather say:".. across multiple LAN
interfaces, possibly including WAN interfase as well, and the CPE
router..". Then "..any two LAN interfaces.." -> "..any two
interfaces..". And still later "..if any two disparate LAN
interfaces..." -> "..if any two disparate interfaces..".

<hs>
Disagree. You are suggesting one implement ND Proxy between the WAN and
LAN interfaces.  For the CPE Rtr, the WAN and LAN interface(s) are two
different routing domains - if one can perform routing between domains,
why support ND Proxy?  We are also making the last sentence better in
section 7.1 as follows:

[Old text]
However, if the CPE Router has more than multiple prefixes available for
use on LAN interfaces(s), and still any two interfaces on the LAN have
disparate MAC layer, the CPE Router MUST NOT support ND Proxy.

[New text]
However, if the CPE Router has multiple prefixes available for use on
LAN interfaces(s), and still any two interfaces on the LAN have
disparate MAC layer, the CPE Router MUST NOT use ND Proxy between the
two interfaces.
</hs>

- 7.1. Says "..has more than multiple prefixes available.." should it
just be:"..has multiple prefixes available.."?

<hs>
Sure, we will fix the English.
</hs>

- 10. introduces WAN_IP_ACQUIRE_TIMEOUT constant. I would like to see
comment here that particular L2 specifications may override this
constant with some other value, as this is L2 dependent. In some L2
mechanisms one can see right at the L2 setup whether it supports native
IPv4/IPv6 and it can be detected quickly if the address family is
available natively or not. Also in some cases where L2 is setup
on-demand, there is no time to wait for this long timeouts (user may be
waiting) but its better proceed quickly with tunnel setups. 

<hs>
Sure thing.  A new line will be added to the definition as follows:

The default value of the WAN_IP_ACQUIRE_TIMEOUT can be overridden by
link-type specific documents.

Best Regards and thanks much.

Hemant & Wes.
</hs>

Best regards,

	Teemu