Hi Ole,

So, are we in agreement on the following points?

* A MAP-CE only has one way of configuring 1:1 mode.
* There should only be a single way of provisioning 1:1 mode.

If so, then the unified CPE draft describes a single method for
provisioning 1:1 mode irrespective of the underlying implementation method
(MAP-E & lw4o6). MAP-E should then use this method for provisioning its
1:1 mode and EA=0 as the way that it is implemented.

Cheers,
Ian



On 17/02/2013 22:06, "Ole Troan" <[email protected]> wrote:

>Ian,
>
>> Assuming that the Unified CPE draft gets adopted by the workgroup, then
>> there needs to be alignment of the different drafts reflecting this.
>> 
>> The unified CPE draft describes how a CPE interprets the presence (or
>>lack
>> of) configuration parameters to understand which softwire mode to
>> configure. If a MAP CE implemented this (to be a 'unified MAP CE'), then
>> it would have two ways of configuring 1:1 mode - via the presence of the
>> tunnel endpoint address, an IPv4 address (and optionally a restricted
>>port
>> range) and also through a BMR with EA=0.
>
>a MAP CE has only one way of configuring 1:1 mode.
>
>> Two ways of configuring the same function doesn't seem like a good idea,
>> even if the underlying mechanism that this function is implemented with
>>is
>> different.
>
>indeed.
>
>> So, what I would propose is that EA=0 for MAP is not included as a
>> provisioning option in the MAP draft. If the parameters described in the
>> unified CPE draft required for 1:1 mode are configured on the unified
>>MAP
>> CE, then it should interpret these to mean EA=0 and configure itself
>> accordingly.
>
>a MAP CE will always configure itself with the BMR.
>that consists of the Rule IPv6 prefix, the Rule IPv4 prefix and the EA
>length.
>
>from a MAP perspective there is not two ways of doing 1:1 mode.
>
>> I also think that it would be cleaner if this 1:1 functionality was
>> described in a separate document to the current MAP draft. As the 1:1
>>mode
>> functionality of MAP is a big architectural change to the mesh mode
>> function, it really needs a lot more than 2 paragraphs in order to
>> describe what it is and how it is used.
>
>1:1 is a configured tunnel with provisioning support.
>as others have said, that's a simple subset of the mesh functionality.
>hardly a big architectural change.
>
>cheers,
>Ole

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

Reply via email to