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: [email protected] [mailto:[email protected]] 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.
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
