Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-01

[Qi Sun <[e-mail]>]

Dear Roberta,

> The DS-Lite ATFR Name option defined in RFC 6334 is used to carry a fully qualified domain name of the AFTR not an IPv6 address.
> There was a proposal and a long discussion on the dhc working group about to be able to use the same option to provision either  the name or the address but the wg did not reach consensus on that idea.  So in my understanding you cannot carry an IPv6 address into the DS-Lite AFTR Name option

[Qi] Sorry for not expressing it correctly. My intension was that the DS-Lite AFTR Name option could be used to tell the CE the BR's IPv6 info. The option should be used as it is designed. I didn't try to change that. 

> it would sound confusing in my opinion, using a DS-Lite specific option to provision MAP specific parameters.

[Qi] In the Unified CPE draft, it using the  DS-Lite AFTR Name option to provision the IPv6 info of BR. The map dhcp draft is going to remove the DMR option. So I think these drafts should be aligned. 

Best Regards,
Qi Sun


On 2013-7-15, at 上午7:40, Roberta Maglione (robmgl) wrote:

> Hi Qu,
> A comment on point 2:
> >2. Currently, there is no DMR in MAP-E. The IPv6 address of the BR could be
> > provisioned by the DS-Lite AFTR Name option.
>  
> The DS-Lite ATFR Name option defined in RFC 6334 is used to carry a fully qualified domain name of the AFTR not an IPv6 address.
> There was a proposal and a long discussion on the dhc working group about to be able to use the same option to provision either  the name or the address but the wg did not reach consensus on that idea.  So in my understanding you cannot carry an IPv6 address into the DS-Lite AFTR Name option.
> In addition even if you could, it would sound confusing in my opinion, using a DS-Lite specific option to provision MAP specific parameters.
>                           
> Thanks
> Regards
> Roberta
>  
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Qi Sun
> Sent: Saturday, July 13, 2013 12:39 PM
> To: Softwires
> Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-01
>  
> Dear wg, 
>  
> I've reviewed the draft and have some comments in addition to Tom's.  May the comments make the draft better. 
> Please correct me if there is any mistake.
>  
> Best Regards,
> Qi
>  
> 1. In Fig 1, there is an element called the Core Router. Does it mean MAP BR? I think the terms should be consistent. 
> 2. Currently, there is no DMR in MAP-E. The IPv6 address of the BR could be provisioned by the DS-Lite AFTR Name option. But the DMR is still in use in MAP-T. IMO, this is an issue. But maybe the WG could give some guidance on handling this. 
> 3. Section 4.2.2
> This part talks about sub-domain, which is a term that is not defined in the MAP draft. I think there should be some text about the what a 'sub-domain' is and how to differentiate 'sub-domain' from a MAP domain.
> 4. Section 4.2.5, para 3:
> It is the wg consensus that the non-contiguous port set has nothing to do with 'better security'. I recommend text about this be removed.
> 5. Section 4.3, page 14:
>    'as long as it is up and ready to take over the virtual IPv6 address,
>    quick failover can be achieved.'
> Does the term 'virtual IPv6 address' stand for anycast IPv6 address, or something else?
> 6. Section 4.3, page 14:
>   'Therefore, when using anycast addresses, it is RECOMMENDED that they
>   be only used as destination address, and never as source addresses.
>   BRs SHOULD be configured to accept traffic sent to the anycast
>    address, but use an unicast address as source.'
>  
> The packets from the BR to the CE is :
> Src: BR's unicast addr, Dest: CE's unicast addr
> But what should be the destination address of the packets from CE to BR after the CE receives the responses sent from/via the BR? The BR's unicast addr, or the anycast addr? IMO, there should be some text like 'The CE SHOULD always use the anycast address of the BR if there is one when sending packets to the BR.'  But there is another issue (maybe minor): how can the CE determine which is the anycast address?
>  
>  
> Some Nits:
> 1. There are some acronyms in the draft, which are better to be expanded when first used.
> 2. The para below Fig 2: 
>    For model A/B, one CE
>    only need (needs) to correspond to a BR, while in model C one CE have (has) to
>    correspond with multiple BRs.  Figure 3 illustrate (illustrates) a typical case,
>    where the home network have (has) multiple connections to multiple
>    providers or multiple logical connections to the same provider.
> 3. Section 4.2, 1st para:
>     However, all CEs within the sub-domain will have the same BMR. in which the BMR of all CEs is the same.
>     => However, all CEs within the sub-domain will have the same BMR.
> 4. Section 4.2.3.2, 1st para:
>    Assigning all BMRs in MAP domain to each CE as FMRs, Mesh
>    communications can be achieved among all CEs.
>    =>   By assigning all BMRs in a MAP domain to each CE as the FMR, Mesh
>    communications can be achieved among all CEs.
> 5. Section 4.2.6, para 3:
>    For the ISP who have number
>    of scattered IPv4 address prefixes, in order to reduce the FMRs,
>    according to needs of ports they can divide different class.
>   => have -> has, reduce the FMRs -> reduce the number of FMRs, class -> classes
> 6. Section 4.2.7, 3. PMTU and fragmentation, para 2
>      cannot to -> cannot do
> 7. Section 4.3, para 2
>   the path from the CE to an IPv4 peer via the BR should be close
>   to the one that would be taken if the CE had native IPv4 connectivity.
>   =>   the path from the CE to an IPv4 peer via the BR should be closer
>   than that would be taken if the CE had native IPv4 connectivity.
> 8. Section 6.2.2, para 1
> When a network evolve (evolves) to a post-IPv6 era. (,) It might
>    be good for ISP to consider implement enforcements rules to help IPv6
>    migration.
>    => When a network evolves to a post-IPv6 era, it might
>    be good for ISPs to consider to implement enforcement rules to help IPv6
>    migration.