Dear authors, Thank you for your hard work! I think we are trying to move forward.
I have some comments on the provisioning method. In the section 4.4 that there is a new sub-option OPTION_MAP_BIND. It is the sub-option of OPTION_MAP (OPTION_SW) used to convey an IPv4 address. Considering OPTION_MAP (OPTION_SW) is a DHCPv6 option, it is a little confusing that we are going to use DHCPv6 for IPv4 resources allocation. IMHO, this should be the decision of DHC WG, which hasn't published the outcome of this issue. Is it possible that we make this part clearer? Best Regards, Qi On 2012-12-6, at 下午2:35, <mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com> wrote: > Hi Tina, > > Many thanks for the comments. Some clarifications below: > > * DS-Lite is included in the scope for the reasons detailed in the draft (see > Section 1.1): > (2) Simplify solution migration paths: Define a unified CPE behavior > which allows for smooth migration between the different modes > and > (4) Re-usability: Maximize the re-use of existing functional blocks > including Tunnel Endpoint, port restricted NAPT44, Forwarding > behavior, etc. > * Public 4over6 is already included in the draft: > (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) > [I-D.cui-softwire-b4-translated-ds-lite], > [I-D.ietf-softwire-public-4over6] or MAP 1:1 > [I-D.ietf-softwire-map] ): Requires a single per-subscriber > state (or a few) to be maintained in the Service Provider's > network. > * I agree with you the title should be updated to reflect the scope of the > draft. The proposed scope is IPv4 service continuity over IPv6 mechanisms. > > Cheers, > Med > > De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la > part de Tina TSOU > Envoyé : mercredi 5 décembre 2012 19:34 > À : ian.far...@telekom.de > Cc : softwires@ietf.org > Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe > > Dear Med, Ian and Suresh, > Great job! Draft-bfmk is written very well to reach consensus. > Two small comments are below. > 1. I’m not sure whether it is appropriate to put DS-Lite case into the > document, since in DS-Lite case the CPE is only the tunnel end point without > NAT, which is basically different with lw4over6/MAP. But if the objective of > this document is to define an unified CPE for all the 4over6 mechanisms, > other mechanisms like public 4over6 should also be included in the document. > My understanding may be wrong. > 2. The title says “unified softwire CPE”, but in softwire, there are > many other transition technologies, e.g., 6rd. To be specific, maybe 4over6 > CPE is more appropriate. > > Thank you, > Tina > > On Dec 4, 2012, at 9:53 AM, "ian.far...@telekom.de" <ian.far...@telekom.de> > wrote: > >> Hi Ole, >> >> Answers inline. >> >> Cheers, >> Ian >> >> -----Original Message----- >> From: Ole Trøan [mailto:otr...@employees.org] >> Sent: Montag, 3. Dezember 2012 10:06 >> To: Farrer, Ian >> Cc: simon.perrea...@viagenie.ca; softwires@ietf.org >> Subject: Re: [Softwires] Unified Softwire CPE: >> draft-bfmk-softwire-unified-cpe >> >> Ian, >> >>> Whichever state is selected, NAT is certainly fundamental to how the state >>> will operate and so we tried to weave it into the functional description. >>> I'm not sure that provisioned NAT info enough to be able to use to >>> unambiguously define with operating 'mode' (for want of a better word) to >>> use. >>> >>> One of the reasons for the use of state in the draft is try and define the >>> operating modes with as little overlap as possible (it's not 100%, but >>> there's only 1 exception at the moment for binding mode and MAP1:1). From >>> this, then it is easier to align the specific solution names to the state >>> characteristics. >> >> I don't think you should try to define modes such that the map (no pun >> intended) into the specific solution names. >> shouldn't the purpose of a "unified CPE", be for the CPE not to have to care >> about the different "deployment modes" on the head end? >> >> Ian: But a MAP CPE does have to care about what is on the tunnel head end as >> it could be another mesh client, or it could be the BR. It uses a different >> mapping rule type for each, so it is aware of the capabilities of the head >> end. >> >>> But, with what you've suggested, there is more overlap, i.e. both 2&4 have >>> NAT functions that are supported by two different mechanisms. >>> >>> However, what you've said does raise the following point: >>> >>> The way that state is described in the draft at the moment is actually >>> taken from a concentrator perspective. This could be taken to be almost the >>> inverse of the amount of state that is required from the CPEs perspective >>> (i.e. if all of the state is in the providers network (DS-Lite), then the >>> CPE doesn't need it. If the providers network has less state >>> ('per-customer', 'stateless'), then the CPE needs to have more - i.e. >>> dynamic state table for NAT, configuration for local IPv4/port set, MAPing >>> rules etc. >>> >>> Would describing the different states more from the CPE's perspective make >>> this clearer? >> >> that would certainly help. although I don't think "state" is the defining >> characteristic. >> >> Ian: Is the problem with the what's being described (i.e. the content and >> functional differentiations) or the naming and terminology used to describe >> it? >> >> >> cheers, >> Ole >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
