Re: New version available (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

[Mikael Abrahamsson <[e-mail]>]

On Fri, 10 Sep 2010, Jari Arkko wrote:

> Host support is important because that is an area where neither the 
> IETF, any single vendor, or the DSL operators have any easy way to 
> change the situation. But it is of course by no means the only 
> constraint. The operators have their issues as well. Even though they 
> are in control of their own networks, they probably want to keep their 
> underlying L2 network architecture as it is, despite introduction of 
> IPv6 or other new features.

Reading draft-krishnan-6man-rs-mark-06.txt I read this as an "dhcp option 
82"-analogy in the IPv6 SLAAC world. Please correct me if I'm wrong.

We are using the deployment model where this is applicable, and the 
concept seems like it makes sense for using SLAAC in this deployment model 
(I wouldn't really want to, but it might be nice in case of lack of DHCPv6 
support in end nodes).

Some questions though, on the interface on the edge router towards the 
access node (which will receive the tunneled RS packet), it seems there 
should be a recommendation for the edge router to not accept untunneled 
RS, or at least a recommendation that a knob for this behaviour should 
exist? If the interface is only used for customer traffic then there 
should never be an untunneled RS packet if the access node is correctly 
configured?

Also, in 5.1 perhaps there could be a clarification that the new packet is 
still a RS packet, it took me a few readings before I understood that 
part? (did I understand it correctly?) I'm still uncertain, there is text 
about "tunneled packet" and I was looking for the layout of this packet, 
and then I deduced that it's probably RS packet with added option header?

I like that the fields are TLV, makes for easy extension in the future. 
Should perhaps the "option length" be more than 0-255, perhaps 16 bits 
instead of 8?

Has the SAVI WG been involved or seen this draft before? I can see some 
recommendations that they need to implement as well, such as disallowing 
LIO packets from the end customers (drop on floor or replace), rate 
limiting the RS packets per second from the end users, etc.

-- 
Mikael Abrahamsson    email: [e-mail]