Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode?

From: Ole Troan <[email-masked]>
Date: Thu, 14 Feb 2013 11:14:25 +0100

> #25: Maintain or remove MAP1:1 Mode?

OK, so here is a task for whomever thinks MAP 1:1 mode should be removed.

- what does "remove MAP 1:1 mode mean"?
- please suggest text changes to the mechanism that removes 1:1 mode.

given that my opinion is that 1:1 mode is an unremovable part of MAP, the question just doesn't make sense to me.

I don't want this issue to be an excuse to block a last call, can we quickly resolve this, and can we agree to drop it if there are no significant contributions within the next week?

cheers,
Ole

> 
> The WG discussed several times this point (refer to the mailing list
> archives).
> 
> MAP1:1 mode is a particular mode which may re-use some of the provisioning
> methods defined for MAP.
> 
> MAP1:1 vs. Lw4o6:
> * MAP1:1 is not fully stateless.
> * Lw4o6 is a standalone specification which provides the same service as
> MAP1:1.
> 
> -- 
> -------------------------------------+-------------------------------------
> Reporter:                           |      Owner:  draft-ietf-softwire-
>  [email-masked]       |  [email-masked]
>     Type:  defect                   |     Status:  new
> Priority:  major                    |  Milestone:
> Component:  map-e                    |    Version:
> Severity:  -                        |   Keywords:
> -------------------------------------+-------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/softwire/trac/ticket/25>
> softwire <http://tools.ietf.org/softwire/>
>

---

From: <[email-masked]>
Date: Thu, 14 Feb 2013 11:55:31 +0100

Hi Ole,

To start with, there was no consensus to include MAP1:1 in the MAP spec. Unless I'm mistaken, objection to include that mode in the base MAP spec was raised several times in the mailing list. It was mainly raised by authors of Lw4o6 but they are also contributors to softwire.

As an editor of this document, with all due respect, you should ask the opinion of the WG before recording the consensus into the document. The WG owns this document and it can decide what to put on it.

I'm personally in favour of removing MAP1:1 section from this document as this mode can not be packaged as stateless. But, this is only my opinion. 

Cheers,
Med

>-----Message d'origine-----
>De : Ole Troan [mailto:[email-masked]] 
>Envoyé : jeudi 14 février 2013 11:14
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]; [email-masked]
>Objet : Re: [softwire] #25: Maintain or remove MAP1:1 Mode?
>
>given that my opinion is that 1:1 mode is an unremovable part 
>of MAP, the question just doesn't make sense to me.
>
>I don't want this issue to be an excuse to block a last call, 
>can we quickly resolve this, and can we agree to drop it if 
>there are no significant contributions within the next week?
>
>cheers,
>Ole
>
>
>>

---

From: Ole Troan <[email-masked]>
Date: Thu, 14 Feb 2013 12:12:17 +0100

Med,

> I'm personally in favour of removing MAP1:1 section from this document as this mode can not be packaged as stateless. But, this is only my opinion. 

you didn't answer my question.
1:1 mode has always been part of MAP. are we arguing over whether we should explicitly mention that fact in the MAP draft.
or are we arguing over making it technically impossible to do MAP 1:1 mode?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 14 Feb 2013 16:15:41 +0100

> 1:1 mode has always been part of MAP.

Untrue:

- Initially, the MAP draft was limited to stateless, WITHOUT any reference to 1:1 (October 2011 to January 2012, ref http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-00 to -03)

- It is only when the MAP draft had to be re-issued a WG document that, without previous discussion in the WG, applicability to 1:1 was added by its editor(s) (June 2012).

- When MAP became restricted to MAP-E, as per WG decision, applicability to 1:1 has been kept despite the lack of WG consensus (September 2012).

> are we arguing over whether we should explicitly mention that fact in the MAP draft.

Suggested way to solve the problem: 
- Delete section 7.4  (whose ONLY purpose is to introduce 1:1 applicability).
- In Appendix A, delete examples 4 and 5 (ONLY devoted to 1:1 mappings).    

RD

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 14 Feb 2013 15:30:43 +0000

My vote is to keep 1:1 mode in MAP. Removing it just doesn't make sense
(else, we might as well remove supporting host routing (/32 or /128) from
dynamic routing protocols).

Cheers,
Rajiv

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Thursday, February 14, 2013 5:55 AM
To: Ole Troan <[email-masked]>
Cc: Softwires-wg list <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode?

>Hi Ole,
>
>To start with, there was no consensus to include MAP1:1 in the MAP spec.
>Unless I'm mistaken, objection to include that mode in the base MAP spec
>was raised several times in the mailing list. It was mainly raised by
>authors of Lw4o6 but they are also contributors to softwire.
>
>As an editor of this document, with all due respect, you should ask the
>opinion of the WG before recording the consensus into the document. The
>WG owns this document and it can decide what to put on it.
>
>I'm personally in favour of removing MAP1:1 section from this document as
>this mode can not be packaged as stateless. But, this is only my opinion.
>
>Cheers,
>Med
>

---

From: <[email-masked]>
Date: Fri, 15 Feb 2013 09:29:20 +0100

Hi Ole,

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.

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.

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.

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.

Best regards,
Ian

On 14/02/2013 11:14, "Ole Troan" <[email-masked]> wrote:

>I don't want this issue to be an excuse to block a last call, can we
>quickly resolve this, and can we agree to drop it if there are no
>significant contributions within the next week?
>
>cheers,
>Ole
>
>
>>

---

From: Maoke <[email-masked]>
Date: Fri, 15 Feb 2013 17:48:34 +0900

2013/2/15 Rajiv Asati (rajiva) <[email-masked]>

> dynamic routing protocols).

+1

i prefer to say  that the early version did not include the 1:1 mode
because of lack of understanding at that moment, on both the demands and
what we can do with MAP.

the 1:1 mode may enable MAP domain totally independent of the AS
administration so that a MAP domain crossing over multiple regular routing
domains is enabled. of course, we need more tools to deploy such an MAP
overlay but the MAP supporting 1:1 mode is anyway a needed building block.

- maoke

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 15 Feb 2013 18:00:25 +0900

Hi Ian,

> even if the underlying mechanism that this function is implemented with is

I believe that supporting bunch of provision ways is most significant role of your 'unified CPE' work. I also think that there are another work for unified-cpe to support not only encap solution but also translation such as MAP-T, 4rd and 464XLAT. While hesitate to do that, I recommend wg to postpone the adoption of unified-CPE draft. I suppose you would argue that these aren't scope of softwire, but what does mean 'unified' for?

> CE, then it should interpret these to mean EA=0 and configure itself

In my opinion, it is quite unreasonable. 

> describe what it is and how it is used.

I agree that the document has to be concise but MAP document should be consistent so let us make clear for a case when EA-len configured to zero in the document.

cheers,
--satoru

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 15 Feb 2013 09:03:29 +0000

Hi Ian,

>range) and also through a BMR with EA=0.

The unified CPE draft, at this stage, still does not reflect some of the
main feedback provided in :
http://www.ietf.org/mail-archive/web/softwires/current/msg04960.html

Namely: Functional decomposition...

>even if the underlying mechanism that this function is implemented with is

...And this is the essence of the problem in the "unified CPE" draft. The
underlying implementation MUST not be different, otherwise we're not
unifying anything here.
I will assert that it is possible to have a single implementation that
delivers both MAP and Lw46 characteristics. The proof point of that can
also be found in the existing MAP implementations.

>describe what it is and how it is used.

It's quite the opposite. A hub&spoke topology is a subset of a mesh, and
MAP covers both. Changing from one mode to the other is actually nothing
more than installing a IPv4 route on the CPE.
In example terms: Each MAP CE is configured with a BMR and a default
route. The BMR conveys the CPE the info about it's port-set to use. Just
with this information the CE can happily operate in hub&spoke mode. When
the BMR is marked with a "use for forwarding" flag, the CE is able to
communicate in mesh mode. Changing from one mode to the other is nothing
but setting a flag in the same BMR.

It is my opinion that we've discussed this 1:1 mode many many times
before, and at each time concluded that a) it is a natural characteristic
of MAP ii) it would actually require *more text* (and complexity) to
remove it.

That said, the biggest take away for me of this thread so far is that the
unified CPE draft seems to be going with the assumption of two
implementations for what is essentially the same functionality. This is a
show-stopper IMO for the unified-cpe draft.

Regards,
Woj..

>>>-------------------------------------+----------------------------------
>>>-
>>>--
>>>-------------------------------------+----------------------------------
>>>-
>>>--
>>>

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Feb 2013 10:06:28 +0100

> My vote is to keep 1:1 mode in MAP. Removing it just doesn't make sense

Your point, similar to that of Ole, is that 1:1 is intrinsic to the design.
Even if not explicitly stated, it therefore cannot be removed from it.

To put an end to this time-wasting controversy, it is then easy to just delete explicit references to 1:1 (section 7.4 and examples 4 and 5). 

> dynamic routing protocols).

Of course you aren't serious here ;-).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Feb 2013 10:11:31 +0100

2013-02-15  10:03, Wojciech Dec (wdec) <[email-masked]> :
...
> of MAP ii) it would actually require *more text* (and complexity) to

Would you see anything needing to be reworded if section 7.4 and examples 4 an 5 are simply deleted (the only texts AFAIK that explicitly refer to 1:1 as being an objective)?

RD

---

From: Xing Li <[email-masked]>
Date: Fri, 15 Feb 2013 17:34:51 +0800

Hi, Ian,

The 1:1 mode is a natural characteristic of MAP and removing it from the 
draft will cause more confusion. Please also see 
https://datatracker.ietf.org/doc/draft-xli-softwire-map-testing/
which shows that a MAP CPE can naturally support 1:1 mode.

Regards,

xing

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 15 Feb 2013 18:46:14 +0900

On 2013/02/15, at 18:34, Xing Li <[email-masked]> wrote:

> Hi, Ian,
> 
> The 1:1 mode is a natural characteristic of MAP and removing it from the draft will cause more confusion. Please also see https://datatracker.ietf.org/doc/draft-xli-softwire-map-testing/

ASAMAP too.

cheers,
--satoru

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 15 Feb 2013 10:16:08 +0000

On 15/02/2013 10:11, "Rémi Després" <[email-masked]> wrote:

>Would you see anything needing to be reworded if section 7.4 and examples
>4 an 5 are simply deleted (the only texts AFAIK that explicitly refer to
>1:1 as being an objective)?

Let's take a step back: Long long time ago, in an era of many ills with
the softwire WG, a pseudo WG-draft was set-up whose primary reason for
existence was the supposed lack of 1:1 mode in MAP...
The text you reference was included to provide examples of how the 1:1 is
realized. Removing such text will thus take us back to answering "how does
MAP do 1:1?", not doing anyone a favor really (noting that existing
implementations support the 1:1 mode, as a natural part of the
implementation and that at least the developers involved I know didn't
find the implementation to be an issue.)
Of course we can always write N drafts, but that's not the point of why
we're here (IMO).

-Woj..

---

From: Qi Sun <[email-masked]>
Date: Fri, 15 Feb 2013 18:30:06 +0800

Hi Ole,

There are 2 ways to achieve address sharing in MAP-E-04, one is algorithmic mapping IPv4 address and PSID into IPv6 prefix, the other is non-algorithmic binding of IPv4 address, port-set and IPv6 address. The former is advocating the designed algorithm to achieve stateless, while the latter achieves IPv4/IPv6 address independence by abandoning the algorithm. It conflicts with itself.

Now that the algorithm is still there when EA = 0 (even though not used), MAP-E still requires the implementation of the algorithm and planning IPv4 and IPv6 address together. This increases the cost for operators.

Removing MAP 1:1 mode helps MAP be cleaner as a stateless solution for operators.

My vote is to remove MAP 1:1 mode.

Best Regards,
Qi Sun

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Feb 2013 12:06:07 +0100

> Of course we can always write N drafts, but that's not the point of why

It is thus clear that, if section 7.4 and examples 4 and 5 are deleted from the MAP draft, *no more text* is NEEDED in the draft itself.

Applicability of MAP and of other solutions to 1:1 can be clarified in some other document(s) when consensus is reached.

Thanks,
RD

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 15 Feb 2013 11:16:02 +0000

Remi,

The question Ole posed still stands:
- what does "remove MAP 1:1 mode mean"?

As evidenced by some of the emails (evidence being phrases like [sic]
"Removing MAP 1:1 mode helps MAP be cleaner as a stateless solution for
operators.", etc) on this thread, some folks appear to mean that MAP is
*technically* specified as being prevented from realizing the 1:1 mode.
This would require extra text and is radically different to moving a
description of how MAP is used in 1:1 mode (to some informative draft).

Rgds,
Woj..

On 15/02/2013 12:06, "Rémi Després" <[email-masked]> wrote:

>It is thus clear that, if section 7.4 and examples 4 and 5 are deleted
>from the MAP draft, *no more text* is NEEDED in the draft itself.
>
>Applicability of MAP and of other solutions to 1:1 can be clarified in
>some other document(s) when consensus is reached.
>
>Thanks,
>RD
>
>  
>
>> 
>> -Woj..
>> 
>>> 
>>> RD
>>> 
>>> 
>>> 
>>

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Feb 2013 14:30:32 +0100

> - what does "remove MAP 1:1 mode mean"?

This question was in Ole's answer to Med saying he is "in favour of removing MAP1:1 section" (ref. http://www.ietf.org/mail-archive/web/softwires/current/msg05182).

But Med's request was already perfectly clear.
(I just noted that, for consistency, removal of examples 4 and 5 of Appendix A goes with that of section 7.4.)

Since consensus to have this section never exited, the editor should remove it *before WGLC*.
(Editors must AFAIK remain neutral.)

Regards,
RD

...

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 15 Feb 2013 13:40:20 +0000

On 15/02/2013 14:30, "Rémi Després" <[email-masked]> wrote:

>This question was in Ole's answer to Med saying he is "in favour of
>removing MAP1:1 section" (ref.
>http://www.ietf.org/mail-archive/web/softwires/current/msg05182).
>

Likely a truism but, if it was perfectly clear, then Ole wouldn't have
asked the question.
The e-mails that ensued (eg from Qi) make it clear that at least for some
the removal request is a technical one not an editorial.

>(I just noted that, for consistency, removal of examples 4 and 5 of
>Appendix A goes with that of section 7.4.)
>

We've previously established consensus that MAP supports 1:1 mode (it
likely happened at the meeting after you bid farewell to the group).
Suresh can confirm.

-Woj..

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Feb 2013 14:51:26 +0100

> Likely a truism but, if it was perfectly clear, then Ole wouldn't have

"Removing MAP1:1 section" isn't "removing MAP1:1" 

> the removal request is a technical one not an editorial.

Different subject.

> likely happened at the meeting after you bid farewell to the group).

Please understand that "Removing MAP1:1 section" isn't against this (as I suppose Med and Suresh can confirm too).

RD

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 15 Feb 2013 15:14:36 +0000

>suppose Med and Suresh can confirm too).

If the current text is technically flawed, which appears not to be the
case, let's fix it (eg propose text).
In all other cases, what is the request for?

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Feb 2013 16:17:03 +0100

> In all other cases, what is the request for?

Already explained.
End of this thread for me.
RD

---

From: Qiong <[email-masked]>
Date: Sun, 17 Feb 2013 10:03:47 +0800

Hi Woj,

Please see inline.

> of MAP ii) it would actually require *more text* (and complexity) to

Sorry I can hardly find such conclusion.
1) In the current text, the PSID option is only used in this 1:1 mode which
will have impact on both DHCPv6 server and CPE.
2) From the testing draft, there is a dedicated parameter "-X" to indicate
no embedding EA-bits in IPv6 prefix which is not used in normal
MAP-E/MAP-T.
So for me, it is hard to say this 1:1 mode is a natural characteristic of
MAP.

Long long time ago, we spent two days in Beijing Interim meeting to discuss
what need to be covered in MAP, what's the motivation and requirement of
each functional element, including Encapsulation, Translation, Hub&Sope and
Mesh. That comes to be the draft-ietf-softwire-map-00. But now, 1:1 mode
was just simply added without any discussion about the motivation,
requirement in the working group, and not covered in stateless motivation
draft either. It did raise confusion of why this is needed in MAP (two
address sharing mechanisms in one solution), and how it should be used. So
I suggest to reach consensus on motivation and requirement text first
before processing 1:1 mode in MAP.

For MAP-base draft, I do think removing 1:1 mode would help MAP to be a
more cleaner stateless solution and easy understanding.

Best wishes
Qiong

---

From: Ole Troan <[email-masked]>
Date: Sun, 17 Feb 2013 22:06:37 +0100

Ian,

> range) and also through a BMR with EA=0.

a MAP CE has only one way of configuring 1:1 mode.

> even if the underlying mechanism that this function is implemented with is

indeed.

> CE, then it should interpret these to mean EA=0 and configure itself

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.

> 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

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 18 Feb 2013 11:01:41 +0000

Hello Qiong,

From: Qiong <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 17 February 2013 03:03
To: Wojciech Dec <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode?

Hi Woj,

Please see inline.

On Fri, Feb 15, 2013 at 5:03 PM, Wojciech Dec (wdec) <[email-masked]<mailto:[email-masked]>> wrote:

Sorry I can hardly find such conclusion.
1) In the current text, the PSID option is only used in this 1:1 mode which will have impact on both DHCPv6 server and CPE.

And so? In any scheme where a port assignment is to be made a configuration component will be involved.

2) From the testing draft, there is a dedicated parameter "-X" to indicate no embedding EA-bits in IPv6 prefix which is not used in normal MAP-E/MAP-T.
So for me, it is hard to say this 1:1 mode is a natural characteristic of MAP.

The is an artifact of the implementation AFAIK. In fact we have successfully used a software version without –X to test the 1:1 mode. It's also worthwhile adding that other implementations never had a –X parameter, etc, and that in general implementers are free to design and write software as they wish.

Long long time ago, we spent two days in Beijing Interim meeting to discuss what need to be covered in MAP, what's the motivation and requirement of each functional element, including Encapsulation, Translation, Hub&Sope and Mesh. That comes to be the draft-ietf-softwire-map-00. But now, 1:1 mode was just simply added without any discussion about the motivation, requirement in the working group, and not covered in stateless motivation draft either. It did raise confusion of why this is needed in MAP (two address sharing mechanisms in one solution), and how it should be used. So I suggest to reach consensus on motivation and requirement text first before processing 1:1 mode in MAP.

Update: in Atlanta we discussed the technology (the chairs were present too). It was  rather clear that 1:1 mode is inherent in MAP and the Lw46 solution. We also had a all-parties meeting in Ottawa on that topic, where a similar conclusion was reached. Thus,  I'll continue to assert that 1:1 was possible in MAP all along (although not exemplified to start with).

We come to the IETF to create standards that solve more than just point problems, and to discuss how we can do so in a manner that minimizes the number of solutions - I appreciate that you have a problem with that because your stance appears to indicate that you need a totally separate solution for a point problem.  With all due respect, but taking on such a purely rhetorical point as justification is not really how to get a technical standard done IMO.

For MAP-base draft, I do think removing 1:1 mode would help MAP to be a more cleaner stateless solution and easy understanding.

We've been there before: Stateless doesn't exist. All solutions need configuration. But thanks anyway. It is now clear that what you are proposing is that MAP be technically described as not handling 1:1 mode.
There appears to be 0 technical merit to that argument as far as I can tell. The only argument appears to be that you don't care about the problem, but rather about having prefer to a standalone solution draft.

Regards,
Woj..

Best wishes
Qiong

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Feb 2013 15:04:25 +0100

2013-02-17  03:03, Qiong <[email-masked]> :
...

+1

> 1) In the current text, the PSID option is only used in this 1:1 mode which will have impact on both DHCPv6 server and CPE.

Existence in MAP of a DHCPv6 option whose only purpose is 1:1 is a PROOF that, contrary to a superficial belief, 1:1 isn't a "natural characteristic" of MAP.

> Long long time ago, we spent two days in Beijing Interim meeting to discuss what need to be covered in MAP, what's the motivation and requirement of each functional element, including Encapsulation, Translation, Hub&Sope and Mesh. That comes to be the draft-ietf-softwire-map-00. But now, 1:1 mode was just simply added without any discussion about the motivation, requirement in the working group, and not covered in stateless motivation draft either.

Accurate summary of what happened.

I hope the editor will accept to remain neutral, and have in the draft intended for WG last call nothing more than conclusions reached in the WG s a whole.

Regards,
RD

> It did raise confusion of why this is needed in MAP (two address sharing mechanisms in one solution), and how it should be used. So I suggest to reach consensus on motivation and requirement text first before processing 1:1 mode in MAP. 
>

---

From: <[email-masked]>
Date: Wed, 20 Feb 2013 12:55:31 +0100

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

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Feb 2013 13:07:44 +0100

Ian,

> 1:1 mode and EA=0 as the way that it is implemented.

yes, I think so. while the MAP mode is configured with the BMR/Rule IPv4 prefix.
that doesn't force how the bits are represented in the provisioning option of course.

Best,
Ole