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 protected]> 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 ?

>
> 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?
>
[Qiong] This is the term in VRRP. It is not the anycast address.


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

Reply via email to