Subject: Re: [Softwires] Comments on MAP-E draft

From: "Qi Sun" <[email-masked]>
Date: Thu, 1 Mar 2012 17:15:43 +0800

Hi Murakami,
    Thank you for your reply. Please see my comments in lines.

From: Tetsuya Murakami
Date: 2012-03-01 10:14
To: sunqi.csnet.thu
CC: Tetsuya Murakami; softwires WG
Subject: Re: Comments on MAP-E draft
Hi Qi,

Thank you for your comments. Please see my comments in line.

On 2012/02/29, at 1:18, Qi Sun wrote:

Hi Murakami,
     It's a good draft and makes a nice support for the MAP mechanism. I would like to propose some comments on the draft(sorry if they've been discussed ever). Please check below.
-----------------------------------------------------------------
 Section  5.2 Packet Forwarding Behavior on MAP-E BR
Part (b) BR reception of an IPv6 packet
            BR derives a CE IPv6 address from
            the IPv4 source address or the IPv4 source
            address and the source port in the encapsulated
            IPv4 packet based on the BMR.  If the CE IPv6
            address is eqaul to the IPv6 source address in
            the received IPv6 packet, BR decapsulates the
            IPv4 packet and then forward it via the IPv4
            interface.
I have a few questions here.
1. How can the BR get from an IPv6 packet the IPv4 source address or the IPv4 source address and the source port in the encapsulated IPv4 packet?
In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above text is for check the validation of the received packet. In terms of IPv6 packet received at BR, the IPv6 source address should be based on the IPv6 prefix delegated to CE. Also, according to the MAP rule, IPv4 address and port number can be derived from the same delegated IPv6 prefix. So, BR can calculate CE IPv6 address from the IPv4 source address and source port number in IPv4 packet encapsulated in the received IPv6 packet. If the calculation is failed, then the packet could be dropped. If the calculation is succeeded but the calculated CE IPv6 address is not matched to the source IPv6 address in the received IPv6 packet, then the packet could be dropped.

[Qi Sun]  I have 2 questions here.
[Qi Sun] 1.My understanding is that the BR get the IPv4 related info from the IPv6 packet by reading the specific bits in the IPv6 packet, that is the IPv4 address is put in the exact position in the IPv6 packet. Right?
[Qi Sun]  2.You said,'If the calculation is failed, then the packet could be dropped.' I think this action may cause the data loss of normal IPv6 flow.

2. If the received IPv6 packet is a normal one, instead of an IPv4-encapsulated packet, what will the BR do?  That is, dose the BR can act as a normal router?

In this case, BR should handle this IPv6 packet based on the normal IPv6 routing because the next header is not IPv4 in this case.

[Qi Sun] Agree :)

3. What can cause the inequality between the derived CE IPv6 address and the IPv6 source address in the received IPv6 packet? And what will BR do with it, discard it ?

It might depend on the implementation. But the derived CE IPv6 address must be same as the IPv6 source address in case of MAP-E because the derived CE IPv6 address should be the tunnel end-point address on the CE. So, the received packet should be discarded or not processed as MAP-E packet.

[Qi Sun]  You mean, in the MAP-E case, the inequality won't happen, right? 

My question is that whether the MAP-E nodes can be deployed with the normal IPv6 nodes. If can't, won't it cost too much to deploy brand new MAP-E domains for SP? If can, is it possible to be stated in the draft, with the considerations of BR handling non-MAP-E IPv6 packets ?

Looking forward to ur reply~

[Qi Sun] 
Best Regards,
Qi Sun

------------------------------------------------------------------- 

Thanks,
Tetsuya Murakami

I'm looking forward to your reply~

Best Regards,

Qi Sun
Tsinghua University, Beijing, China

---

From: Ole Trøan <[email-masked]>
Date: Thu, 1 Mar 2012 10:22:44 +0100

Qi,

>>  Section 
>> 5.2
>>  Packet Forwarding Behavior on MAP-E 
>>   BR
>> 

MAP-E is no different than any other tunnel in this regard. MAP-E packets are terminated at a single IPv6 address on the BR. all other IPv6 traffic will be forwarded like normal. i.e. traffic with a destination address not being the BR's MAP-E IPv6 address.

cheers,
Ole

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 1 Mar 2012 07:52:03 -0800

On Mar 1, 2012 1:22 AM, "Ole Trøan" <[email-masked]> wrote:
>
> Qi,
>
> >>      It's a good draft and makes a nice support for the MAP mechanism.
I would like to propose some comments on the draft(sorry if they've been
discussed ever). Please check below.
> >> 1. How can the BR get from an IPv6 packet the IPv4 source address or
the IPv4 source address and the source port in the encapsulated IPv4 packet?
> > In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above text
is for check the validation of the received packet. In terms of IPv6 packet
received at BR, the IPv6 source address should be based on the IPv6 prefix
delegated to CE. Also, according to the MAP rule, IPv4 address and port
number can be derived from the same delegated IPv6 prefix. So, BR can
calculate CE IPv6 address from the IPv4 source address and source port
number in IPv4 packet encapsulated in the received IPv6 packet. If the
calculation is failed, then the packet could be dropped. If the calculation
is succeeded but the calculated CE IPv6 address is not matched to the
source IPv6 address in the received IPv6 packet, then the packet could be
dropped.
> > [Qi Sun] 1.My understanding is that the BR get the IPv4 related info
from the IPv6 packet by reading the specific bits in the IPv6 packet, that
is the IPv4 address is put in the exact position in the IPv6 packet. Right?
> > [Qi Sun]  2.You said,'If the calculation is failed, then the packet
could be dropped.' I think this action may cause the data loss of normal
IPv6 flow.
> >
> >> 2. If the received IPv6 packet is a normal one, instead of an
IPv4-encapsulated packet, what will the BR do?  That is, dose the BR can
act as a normal router?
> >
> > In this case, BR should handle this IPv6 packet based on the normal
IPv6 routing because the next header is not IPv4 in this case.
> >
> > [Qi Sun] Agree :)
> >> 3. What can cause the inequality between the derived CE IPv6 address
and the IPv6 source address in the received IPv6 packet? And what will BR
do with it, discard it ?
> >
> > It might depend on the implementation. But the derived CE IPv6 address
must be same as the IPv6 source address in case of MAP-E because the
derived CE IPv6 address should be the tunnel end-point address on the CE.
So, the received packet should be discarded or not processed as MAP-E
packet.
> > My question is that whether the MAP-E nodes can be deployed with the
normal IPv6 nodes. If can't, won't it cost too much to deploy brand new
MAP-E domains for SP? If can, is it possible to be stated in the draft,
with the considerations of BR handling non-MAP-E IPv6 packets ?
>
> MAP-E is no different than any other tunnel in this regard. MAP-E packets
are terminated at a single IPv6 address on the BR. all other IPv6 traffic
will be forwarded like normal. i.e. traffic with a destination address not
being the BR's MAP-E IPv6 address.

What is the expected behavior when that address becomes unavailable?

Cb

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

---

From: Ole Trøan <[email-masked]>
Date: Thu, 1 Mar 2012 18:02:43 +0100

> What is the expected behavior when that address becomes unavailable?

reliability is achieved through anycast. there are multiple BRs advertising the same address into the IGP.
did that address your question?

cheers,
Ole

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 1 Mar 2012 10:28:55 -0800

> did that address your question?

Sorry, i have not really been able to find this out on my own.

But, i thought there was tight coupling of the BR address resources
and CPE address assignments.

Meaning BR1 has for me (the subscriber) the public address 1.1.1.1
with ports 2000-3000 and that is communicated to CPE1

BR1 goes has a fault, goes off line.

BR2 is now the closest anycast path to CPE1

My CPE is sending packets to BR2 (as anycast) assuming BR2 owns
1.1.1.1 and port set 2000-3000.

But, how does BR2 know anything about 1.1.1.1?  Does BR2 now announce
in BGP to the world it owns 1.1.1.1?

Is that going to work?  If so, where is it documented?

Or, does the CPE have to reboot and get some new config assignment
based on BR2 now being the closest?

How does this oscillating load (BR failure, shortest path changes, ...
) associated with anycast bode for the IPv4 address reserves ?  Seems
like the public IPv4 address pool on each BR would have to be
over-provisioned to handle some N*X level of load.

Sorry if i am missing something obvious.

Cameron

---

From: Ole Trøan <[email-masked]>
Date: Thu, 1 Mar 2012 20:43:35 +0100

Cameron,

> 1.1.1.1 and port set 2000-3000.

the BR doesn't really have any port sets, although it could.
the anycast address is an IPv6 address.

> Sorry if i am missing something obvious.

sounds like we need to make this a little clearer in the draft.

it isn't quite like you describe.
the BR is used for out of domain traffic.
other traffic is 'on-link'.

e.g. the CE has a default route:
0.0.0.0/0 -> 2001::1, MAP0.

2001::1 is advertised from every BR.

cheers,
Ole

---

From: Tetsuya Murakami <[email-masked]>
Date: Thu, 1 Mar 2012 20:42:35 -0800

Hi Qi,

> [Qi Sun]  2.You said,'If the calculation is failed, then the packet could be dropped.' I think this action may cause the data loss of normal IPv6 flow.

EA-bits can be gotten from IPv6 prefix. In case of MAP-E, it is based on the encapsulation. Similar to other tunnel, IPv4 packet is encapsulated in IPv6.

As Ole mentioned, there is no difference than any other tunnel. Only if the IPv6 packet can be terminated at a tunnel end-point address, the packet can be processed as MAP-E packet. In other cases, the IPv6 packet can be processed normally.

If the IPv6 packet is terminated at the tunnel end-point address, the packet can be processed as MAP-E packet. At this time, if the encapsulated IPv4 packet has invalid address as its source address, it could be a invalid MAP-E packet.

> My question is that whether the MAP-E nodes can be deployed with the normal IPv6 nodes. If can't, won't it cost too much to deploy brand new MAP-E domains for SP? If can, is it possible to be state…

As Ole mentioned, if the IPv6 packet can not be terminated at the tunnel end-point address of MAP-E, this packet can be processed as the normal IPv6 packet.

Thanks,
Tetsuya Murakami

---

From: "Qi Sun" <[email-masked]>
Date: Fri, 2 Mar 2012 16:52:07 +0800

Hi,
    Thank you for your reply~
    Here is my understanding and i'm not sure if it's right.
    When BR1 is down and the IPv4-encapsulated packet comes to BR2, BR2 can handle the packet properly using the same MAP rules with CE1 because they are in the same domain. BR2 doesn't have to handle the source IPv4 address, saying 1.1.1.1. Right?

Best Regards,

Qi Sun

From: Ole Tr鴄n
Date: 2012-03-02 03:43
To: Cameron Byrne
CC: softwires WG; sunqi.csnet.thu
Subject: Re: [Softwires] Comments on MAP-E draft
Cameron,

cheers,
Ole

---

From: Tetsuya Murakami <[email-masked]>
Date: Fri, 2 Mar 2012 11:28:52 -0800

Hi Qi,

BR1 and BR2 have an same IPv6 anycast address. CE can send out BR anycast IPv6 packet where IPv4 packet is encapsulated. So, when BR1 is going down, BR2 can receive the packet from CE.

From CE perspective, as Ole mentions, CE needs to maintain a default route toward to MAP in order to forward IPv4 packet over MAP domain. At CE, IPv4 packet is encapsulated in IPv6 and then IPv6 packet is reached to BR. If this IPv6 packet is terminated on the tunnel end-point address at BR, MAP in BR can process this packet.

On the other hand, when BR receives IPv4 packet from IPv4 network, BR needs to forward the IPv4 packet over MAP domain. For this, BR needs to maintain an IPv4 route corresponding to Rule IPv4 prefix. For example,

BR has a following IPv4 route.

1.1.0.0/16 -> MAP0

In the above example, I assume 1.1.0.0/16 is used for Rule IPv4 prefix.

Thanks,
Tetsuya Murakami