Re: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>

[Suresh Krishnan <[e-mail]>]

Hi Ole,
   Thanks for your comments.

On 10-10-28 05:45 AM, Ole Troan wrote:
> Comments/Questions:
> 
> 1) N:1 deployment model. reference 5517, 3069, 4562 perhaps

OK. Will do.

> 2) I don't think the deployment model, i.e where you are using a single link that you are trying to create some level
>    of 'subscriber isolation on, and require "routing (e.g. on line-ids" in a middlebox, is restricted to DSL. generalise
>    the Introduction?

Jari suggested the same. Will do in the next revision.

> 3) define how the tunneling works, which source / destination addresses are used. are there other existing signaling mechanisms that be used instead of 'piggybacking' on user traffic to signal to the network.

OK.

> 
> 4) the proposal is to tunnel ND packets between the AN and the edge router. are you certain that in this model there aren't other IPv6 protocols that also have to be tunneled? which would call for a slightly more general approach?


> 
> 5) does the AN have to do any other action based on the fact that it is receiving an RS? I'm specifically thinking of state required for SAVI for example. DHCPv6 is stateful and even though DHCPv6 snooping isn't architecturally very clean, it is technically a more sound design than trying to achieve the same with ND. if the answer is no, then please ignore. ;-)

The AN does not need to setup any kind of savi-like state on the receipt 
of the RS. The AN does need to setup such state on the receipt of the RA 
as is already described in the BBF document WT-177.

> 
> 6) in section 5.3 you state that the AN MAY retransmit RSs. is how this is done going to be implementation dependent?
> continue forever as in DHCP or timeout after 3 tries as in ND?

My thought was to indefinitely retransmit until an RA is received and 
not stop with 3 retries.

> if ANCP is available as the section says, is it then specifies how the signaling would be done? or would that require additional standardisation? I guess the question is, is this a problem statement, a requirements document or a solution?


> 
> 7) why does section 6.2 say that the edge router mustn't decrement the hop limit of the RA message?

RA messages with hop count <> 255 will be dropped by the receivers as 
specified in Section 6.1.2. of RFC4861.

> 
> 8) in section 6.3. are you stating that you require something like ANCMP to be able to clean up state at the edge router?


> 
> 9) section 7. LineIDlen is not in the figure. could you just encode the Remote-ID dhcp option instead? (RFC4649) 
> 
> <soapbox statement>: I'm biased against this subnet model (N:1)... recreating PPP functionality over Ethernet, trying to create user isolation on a shared IPv6 link, which after all IPv6 protocols are not designed for.

Fine. I do see why you are objecting to the subnet model. The fact 
remains that there are operators using this model and are looking for a 
solution to move to IPv6.

> 
> what are the options?
> - tell BBF not to use DHCPv6?

I think you mean "to use DHCPv6" instead of "not to use DHCPv6"?

> - go somewhere else? ANCP? BBF?

There are no other solutions on the table.

> - adopt in 6man... 
> 
> I'm not sure if 6man has the required expertise for this work.

By "this work" Do you mean that 6man

* does not have the expertise for defining a Destination Option
* does not have the expertise for for specifying the process for usage 
of the destination option?

Thanks
Suresh