Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt

[Maoke <[e-mail]>]

my technical understanding on this issue:

1. (the reason of using unified CPE) unified CPE is a sort of CPE that is
used by an ISP that wants to
    A. simultaneously deploy MAP and lw4o6 and 4rd (and/or something else,
out-of-scope or not?) there and here respectively but doesn't want to
distinguish the device distribution among those subscribers;
    B. potentially deploy MAP or lw4o6 according to backbone strategy but
currently hasn't be sure there will be no change in the future and
therefore doesn't like to leave limitations at the subscribers' side.
    C. deploy either MAP or lw4o6 but doesn't care what to distribute to
the subscribers as long as compatibility is ensured.

2. (the reason of not using unified CPE) for some ISPs, they may not use
unified CPE because
    A. they are clearly know they only need either MAP or lw4o6 and does
want to use the MAP- or lw4o6-specific devices with MAP- or lw4o6-oriented
optimization, with the low cost corresponding to supporting only one
protocol;
    B. they are concerning the future extensions of MAP, e.g. the
inter-domain operation (making a cross-ISP MAP domain), where the
MAP-specific implementation is needed while current unified CPE is unsure
of supporting that.

for the 2B, i don't argue it is a problem that currently the unified CPE
doesn't cover any topic of cross-ISP provisioning at all. i do accept it is
an issue out of the scope of the unified CPE --- including this topic, too
early to discuss for most people, into unified CPE draft may delay its
progress much more.

but i worry, if citing unified CPE, the MAP as an architecture
specification might become restricted so that inter-domain (and potentially
other) extensions may not be available. we have logically checked current
MAP does work in an inter-domain environment (of course, currently only
through manual configuration) and we don't like this feature is hurt by any
extra, not much necessary references. unified CPE is about an
implementation while MAP draft is architecture specification. generally
speaking, an architecture specification should stand on itself rather than
depending upon any specific implementation.

if the citation is DEFINITELY needed for any non-technical reason, the
above explanation on the understanding  must also be included in order to
avoid any misleading or restrictions on extensive usage.

cheers,
- maoke



2013/8/13 <[e-mail]>

> Re-,
>
> It seems we are in disagreement here. Looking to have more feedback for
> the list.
>
> Thanks for engaging.
>
> Cheers,
> Med
>
> >-----Message d'origine-----
> >De : Ole Troan [mailto:[e-mail]]
> >Envoyé : mardi 13 août 2013 15:00
> >À : BOUCADAIR Mohamed OLNC/OLN
> >Cc : [e-mail]
> >Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt
> >
> >Med,
> >
> >> We both agree there is no justification to maintain the dhcp draft in
> the
> >normative section. I consider that point closed and will wait to see this
> >fixed in the document. Given that this document does not rely on how
> >provisioning is achieved and given the unified CPE is where this is
> >supposed to be discussed, I do still think any reference to provisioning
> >should refer to the unified CPE.
> >
> >"not necessarily against...", is quite far from agree. ;-)
> >MAP doesn't discuss the details of provisioning, but it does have a SHOULD
> >to implement the MAP DHCP option. the reason for this is so that all MAP
> >implementations at least support one provisioning mechanism in common.
> >
> >does the unified CPE propose something conflicting with the current text
> in
> >MAP?
> >(the temptation is of course to remove the normative reference, given that
> >progress on a 'unified' DHCP option is slow).
> >
> >> It really does not make sense to not require the CE to follow the
> unified
> >CPE behavior (in particular
> http://tools.ietf.org/html/draft-ietf-softwire-
> >unified-cpe-01#section-3.2) if we want a minimum of coherency among the
> >solutions discussed so far.
> >
> >that's for the unified CPE document to say.
> >
> >> I don't think that referring to the unified CPE draft will block the
> >publication of the MAP document. This is not a technical reason BTW.
> >
> >no, it is not a technical reason. it is a design goal to keep MAP
> >independent of the other mechanisms, i.e. it must be possible to implement
> >routers that only support MAP and no other of the mechanisms.
> >
> >> If we maintain the same positive energy as we have started to do in the
> >Atlanta meeting, I do think that we will be able to deliver all these
> >documents as a package.
> >
> >positive energy is good! might be a little misplaced here though. ;-)
> >to me it looks like we've moved the contentious parts that led to all of
> >DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to the
> >DHCP/unified CPE documents.
> >
> >cheers,
> >Ole
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>