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

From: Qi Sun <[email-masked]>
Date: Sun, 14 Jul 2013 00:39:13 +0800

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.

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Sun, 14 Jul 2013 23:40:24 +0000

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-masked] [mailto:[email-masked]] 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,

Best Regards,
Qi

Some Nits:

---

From: Qi Sun <[email-masked]>
Date: Mon, 15 Jul 2013 09:18:47 +0800

Dear Roberta,

> 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

---

From: Qiong <[email-masked]>
Date: Mon, 15 Jul 2013 09:20:55 +0800

Dear Qi,

Thanks for your detailed review. I have incorporated most of your comments
into the next version and will be submitted soon.

Some comments are inline.

On Sun, Jul 14, 2013 at 12:39 AM, Qi Sun <[email-masked]> wrote:

>
> 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.
>
[Qiong] This is also the question for the WG. I'm wondering what's the
reason of this change in MAP-E. Is this the final decision that MAP-E and
MAP-T will deal with it differently ?

> Does the term 'virtual IPv6 address' stand for anycast IPv6 address, or
[Qiong] This is the term in VRRP. It is not the anycast address.

> 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?
>
[Qiong] I agree this recommendation has problems as you state. I would like
to change the  recommendation to increase the MTU so that no fragmentation
will occur. Is this ok ?

For other comments, I agree with you and I have updated in my text.

Thanks!

Best wishes
Qiong

>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Qiong <[email-masked]>
Date: Mon, 15 Jul 2013 09:27:43 +0800

Hi Roberta,

On Mon, Jul 15, 2013 at 7:40 AM, Roberta Maglione (robmgl) <[email-masked]
> wrote:
>
>  In addition even if you could, it would sound confusing in my opinion,
> using a DS-Lite specific option to provision MAP specific parameters.
>

[Qiong] I agree with you. I think using DMR is more clear.

Best wishes
Qiong

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Mon, 15 Jul 2013 12:53:09 +0000

Hi Qi,
Thanks for the clarifications.
I still think that having a DMR option for MAP would more clear, but if the WG has decided to re-use the DS-Lite AFTR Name option I’m ok with that as long as it is used as designed.
Regards
Roberta

From: Qi Sun [mailto:[email-masked]]
Sent: Sunday, July 14, 2013 9:19 PM
To: Roberta Maglione (robmgl)
Cc: Softwires
Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-01

Dear Roberta,

Best Regards,
Qi Sun

Hi Qu,

Thanks
Regards
Roberta