Hi Ian,
On 2013/02/15, at 17:29, <[email protected]> wrote: > 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. 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? > > 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. > In my opinion, it is quite unreasonable. > > 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. > 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
