2013/2/5 <[email protected]> > Hi Maoke, > > Thanks for your response. Comments inline. > > Cheers, > Ian > > From: Maoke <[email protected]> > Date: Tuesday, 5 February 2013 06:54 > To: Suresh Krishnan <[email protected]> > Cc: Softwires WG <[email protected]>, Yong Cui <[email protected]>, > Ralph Droms <[email protected]> > Subject: Re: [Softwires] Call for adoption of > draft-bfmk-softwire-unified-cpe-02 > > > hi Suresh and all, > > personally i think this work is still premature for the WG adoption. > reasons are below: > > 1. current draft makes a logic for the CPE to decide its mode according to > what information it received from DHCP options. however, DHCP options are > not the only available provision mean. what if my CPE get MAP information > through DHCP, while lw4over6 information from PCP, while another MAP > domain's provision through manually configuration? when such kind of basic > questions not yet fully discussed, i doubt it is suitable to adopt this > work at so early stage. > > [ian] The intention for the draft is to describe using the presence (or > absence) of configuration parameters so that a CPE can work out which mode > to configure. The DHCP section is there to show how this would work if you > were using DHCP as the config mechanism, but it doesn't > > [maoke] the draft states "e.g." for the DHCP configuration firstly but later the total discussion is based on only DHCP. i doubt this can be a good direction for the further approach.
> 2. some important issues are not yet comprehensively discussed, or almost > missing, in the current draft. e.g. (but not limited to), > - what is the correct NAPT source port overlapping behaviour for the > unified CPE? > - what is the correct fragment/reassemble behaviour for the unified > CPE? > > [ian] I agree that these are problems that need to be addressed across > both MAP and LW, but both of these problems need solutions that are aligned > at both ends of the softwire, not just the CPE. > [maoke] NAPT issue is totally CPE issue. i don't agree it is a problem for the *both* ends. fragmentation issue involves both sides, but CPE behaviour impacting the anycast BR/AFTR performance is a well-known issue in the community. even BR/AFTR has any change, the CPE must contain a work on this issue. > [ian] For the fragmentation question, Ole proposed this as being a > suitable task to tackle as it is common to all solutions. I would propose > that this is how it is tackled, and then any affected drafts are updated > based on the outcome. > > as currently there is no MAP members joins this draft, i am worrying that > the draft has fully reflected the concern from the MAP side. > > > [ian] As there haven't been any comments on the draft for some time from > anyone involved in the WG, I'm hoping that this means that everyone is > happy with the content! > [maoke] happy with the content at current stage = acknowledge to the authors' effort != happy with the content at the level of WG adoption. ;-) for the time being... - maoke > > thanks and regards, > maoke > > 2013/2/5 Suresh Krishnan <[email protected]> > >> Hi all, >> This draft was a result of the discussion initiated at the softwire >> meeting in Atlanta to attempt to come up with a unified CPE >> specification that can work with both MAP and lw4o6. This call is being >> initiated to determine whether there is WG consensus towards adoption of >> draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state >> whether or not you're in favor of the adoption by replying to this >> email. If you are not in favor, please also state your objections in >> your response. This adoption call will complete on 2013-02-18. >> >> Regards >> Suresh & Yong >> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
