I am not talking about whether a MAP-domain should support 1 or N CEs.
What I am trying to say is MAP-E 1:1 requires the BR to know per
subscriber information and the operator must pre-provision per-subscriber
based rules to every BR in the same domain. In addition, the BR can't use
programatic logic to reduce states. When the WG first decided to work on a
"stateless" solution, the goal was to make BR as stateless as possible.
MAP-E 1:1 in contrast requires to store all subscriber rules in the BR and
can't derive the CE's IPv6 address using programatic logic. I found it odd
to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a
stateful solution to me.


On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" <[email protected]> wrote:

>
>One can define a MAP-domain consisting of 1 CE or N CEs. This is more of a
>deployment choice.
>
>Cheers,
>Rajiv
>
>
>-----Original Message-----
>From: <Lee>, Yiu Lee <[email protected]>
>Date: Friday, November 9, 2012 2:43 PM
>To: Softwires-wg list <[email protected]>
>Subject: [Softwires] MAP-E 1:1 for HA
>
>>I have a question for the HA design concept of MAP-E 1:1. The central
>>theme of MAP-E is to make BR as stateless as possible and use Anycast
>>address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the
>>operator must have to pre-provision all
>> the subscribe rules to all the BRs sharing the same Anycast address for
>>reliable HA. This requires operators to carefully plan out which BRs
>>support which subscribers. It is because BR is "per-subscriber stateful"
>>in MAP-E 1:1 mode. Compared to the MAP-E design,
>> HA in MAP-E only requires the operators to use the same set of rules to
>>cover the entire domain. IMHO, this contradicts  the original spirit of
>>stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E
>>name. MAP-E and 1:1 MAP-E are two completely
>> different solutions and target to different deployment scenarios. I
>>would love to hear others to comment in the ML how to resolve this issue.
>>
>>
>>Thanks,
>>Yiu
>>
>>
>>
>>
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to