Subject: [Softwires] Comments on draft-hu-softwire-multicast-radius-ext

From: "[email-masked]" <[email-masked]>
Date: Mon, 6 Oct 2014 11:38:50 +0800

Dear authors, 

I have read this document and think it is meaningful to propose a new RADIUS attribute to carry the IPv6 prefixes together with the DHCPv6 option defined in draft-ietf-softwire-multicast-prefix-option-07. 

Here are some comments about this document. 

1. The following paragraph repeats twice (section 3 and section 4) in this document. 
'If the NAS does not receive the Multicast-Prefixes-64 attribute in the Access-Accept message, it MAY fall back to a pre-configured default Multicast-Prefixes-64, if any. If the NAS does not have any pre-configured, the delivery of multicast traffic is not supported.' 
Do you think it is more suitable to remove the repeated one in section 3? 

2. The architecture of this document seems not very reasonable. Do you think it could be of a better structure? Here are my suggestions. 
a) The section 4 is intended to specify the new RADIUS attribute, it seems that the most content of the section 4.1 is describing the RADIUS client behavior. Do you think it is appropriate to treat this part as a separate section called the Client Behavior. 
b) And I think the sequence of the sections could be modified to become better organized. The section RADIUS Attribute could be introduced first, then the section Client Behavior would be discussed later. While the Multicast-Prefixes-64 Configuration with RADIUS and DHCPv6 section is more appropriate to locate in the rear of those two sections. 

3. The ‘DHCPv6 Advertisement’ in Figure 1,2 could be modified as ‘DHCPv6 Advertise’ in a more standardized way according to the RFC 3315. 

4. There seems to be a conflict between the figure 1 and its corresponding description. 
From the Figure 1, we can conclude that the DHCPv6 Advertise message carries the DHCPv6 OPTION_PREFIX64 option. 
However, if we refer to the content, it states that ‘the NAS SHALL use the prefixes returned in the RADIUS Multicast-Prefixes-64 attribute to populate the DHCPv6 OPTION_PREFIX64 option in the DHCPv6 reply message’ in section 3. 
Do you think it could be better to keep the consistence between the figure and its description. 

5. Could you please explain why the DHCPv6 Request message in the Figure 2 does not carry a DHCPv6 OPTION_PREFIX64? 

6. Do you think it is necessary to add a separate paragraph that defines how the NAS will communicate with the AAA server when the mB4 is at its DHCP renew stage to make the document more comprehensive? 

Best regards, 
Linhui Sun 

[email-masked]

---

From: [email-masked]
Date: Thu, 9 Oct 2014 15:42:18 +0800

Hi, Linhui,

  Thanks for your comments. Please see inline.
  And all your comments we will update them in the next version.

  Many thanks.

BRs
Linda Wang

"[email-masked]" <[email-masked]> 写于 2014-10-06 11:38:50:

> "[email-masked]" <[email-masked]> 
> 2014-10-06 11:38
> 
> 收件人
> 
> [email-masked], [email-masked], 
> [email-masked], [email-masked], 
> 
> 抄送
> 
> softwires <[email-masked]>
> 
> 主题
> 
> Comments on draft-hu-softwire-multicast-radius-ext
> 
> Dear authors, 
> 
> I have read this document and think it is meaningful to propose a 
> new RADIUS attribute to carry the IPv6 prefixes together with the 
> DHCPv6 option defined in draft-ietf-softwire-multicast-prefix-option-07. 

> 'If the NAS does not receive the Multicast-Prefixes-64 attribute in 
> the Access-Accept message, it MAY fall back to a pre-configured 
> default Multicast-Prefixes-64, if any. If the NAS does not have any 
> pre-configured, the delivery of multicast traffic is not supported.' 
//Linda: I do agree with you. Thanks.

> 
> 2. The architecture of this document seems not very reasonable. Do 
> you think it could be of a better structure? Here are my suggestions. 
> a) The section 4 is intended to specify the new RADIUS attribute, it
> seems that the most content of the section 4.1 is describing the 
> RADIUS client behavior. Do you think it is appropriate to treat this
> part as a separate section called the Client Behavior. 
> b) And I think the sequence of the sections could be modified to 
> become better organized. The section RADIUS Attribute could be 
> introduced first, then the section Client Behavior would be 
> discussed later. While the Multicast-Prefixes-64 Configuration with 
> RADIUS and DHCPv6 section is more appropriate to locate in the rear 
> of those two sections. 
//Linda: Originally, we considered it would be clearer to present the 
the whole message exchange flow first, then follow this flow, readers 
can catch a better understanding of where this attribute would be brought
with and how this attribute would be used. After that, we illustrated the 
format of this attribute naturally. Do you think this can explain 
why we presented this draft in this structure?
As for your proposal about section 4.1, in fact, in this section we wanted 

to emphasize the changed details which were caused by this new attribute,
not emphasize the separated client behavior or server behavior. So we 
integrated them together. 
But, we still will carefully consider your proposal structure later. 
Thanks. 

> 
> 3. The ‘DHCPv6 Advertisement’ in Figure 1,2 could be modified as 
> ‘DHCPv6 Advertise’ in a more standardized way according to the RFC 
3315. 
//Linda: I do agree with you. Thanks.

> From the Figure 1, we can conclude that the DHCPv6 Advertise message
> carries the DHCPv6 OPTION_PREFIX64 option. 
> However, if we refer to the content, it states that ‘the NAS SHALL 
> use the prefixes returned in the RADIUS Multicast-Prefixes-64 
> attribute to populate the DHCPv6 OPTION_PREFIX64 option in the 
> DHCPv6 reply message’ in section 3. 
//Linda: I do agree with you. Thanks.

> 5. Could you please explain why the DHCPv6 Request message in the 
> Figure 2 does not carry a DHCPv6 OPTION_PREFIX64? 
//Linda: Yes, you are right. The DHCPv6 Request message should carry this 
option.

> 6. Do you think it is necessary to add a separate paragraph that 
> defines how the NAS will communicate with the AAA server when the 
> mB4 is at its DHCP renew stage to make the document more comprehensive? 
//Linda: In the last paragraph in section 3, we explain the DHCP RENEW 
stage, do
you think it is enough for your question?

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 11 Oct 2014 09:44:16 +0800

Hi, Linda.

    Thank you for your reply and explannation!

    As for the question 6, the last paragraph in section 3 seems to describe the communication when T1 expires. Does it mean that when the mB4 is responded in T1 there is no communication between NAS and AAA server?

Best regards,
Linhui Sun

[email-masked]
 
发件人： wang.cui1
发送时间： 2014-10-09 15:42
收件人： [email-masked]
抄送： meng.wei2; mohamed.boucadair; wang.cui1; wangqian; softwires
主题： RE:Comments on draft-hu-softwire-multicast-radius-ext
Hi, Linhui, 

  Many thanks. 

BRs 
Linda Wang 

But, we still will carefully consider your proposal structure later. Thanks. 

> ‘DHCPv6 Advertise’ in a more standardized way according to the RFC 3315. 

> Figure 2 does not carry a DHCPv6 OPTION_PREFIX64? 
//Linda: Yes, you are right. The DHCPv6 Request message should carry this option.

> mB4 is at its DHCP renew stage to make the document more comprehensive? 
//Linda: In the last paragraph in section 3, we explain the DHCP RENEW stage, do 
you think it is enough for your question?