Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

[Wojciech Dec <[e-mail]>]

Hi Ted,


my comment refers specifically to the "characterization" of MAP in the
introduction of the lw46 draft. I keep on restating this, because this
characterization of MAP is not correct - the current text states "..If this
type of meshed interconnectivity is required,
[I-D.ietf-softwire-map<http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07#ref-I-D.ietf-softwire-map>]
provides a suitable solution.", alongside  a previous point of "

The reduction of maintained state results in a greatly reduced
      logging overhead on the service provider."

Hence re-stating: The defining characteristic of MAP is the optimization,
or reduction if you prefer, of state via route aggregation. A by product of
this also the optional mesh mode.
Since the lw46 draft mentions that reduction of state is "greatly reduced"
in positive terms, the text that I proposed is justified.
Needless to say I do not agree with the current text, as it paints an
incorrect picture to the reader of this space.

As discussed with Ian, I'm willing to support text in the MAP-E draft along
the lines of  "the per-subscriber (1:1 mapping) rule case is further
detailed in lw46", etc.
This seemed like a reasonable re-solution to me and Ian.

Regards,
Wojciech.




On 3 March 2014 16:40, Ted Lemon <[e-mail]> wrote:

> On Mar 3, 2014, at 2:10 PM, Wojciech Dec <[e-mail]> wrote:
> > From a previous mail (that you perhaps missed):
>
> I didn't miss it.   The distinction you are making is finally making sense
> to me after many repetitions.   Sorry for being dense.
>
> I think what you are trying to avoid is the situation where a reader of
> this specification decides to implement it rather than a hub-and-spoke-only
> subset of MAP, even though MAP provides hub-and-spoke as well as the mesh
> mode.
>
> But in practice, someone who does not want to implement full MAP probably
> _is_ going to prefer lw4over6.   Someone who reads both specs, wants to
> implement MAP anyway, and is seeing no market pressure to implement
> lw4over6 isn't going to decide to implement lw4over6 as well because of
> this text.
>
> So I think the text actually says the right thing as currently written,
> and is likely to be more confusing to the intended reader with your
> proposed change.  That's my opinion as a participant, not as AD--if the
> working group disagrees with me, I'm totally okay with that.
>
>