hi Ian, 2013/2/8 <[email protected]>
> HI Maoke, > > Comments in line. > > Cheers, > Ian > > > Deutsche Telekom AG > Group Technology > Ian Farrer > IP Engineering > Landgrabenweg 151, 53227 Bonn, Germany > +49 228 93638046 (Phone) > +49 170 4557418 (Mobile) > E-Mail: [email protected] > > Life is for sharing. > > Deutsche Telekom AG > Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) > Board of Management: René Obermann (Chairman), > Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, > Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick > Commercial register: Amtsgericht Bonn HRB 6794 > Registered office: Bonn > VAT identification no. DE 123475223 > > *Big changes start small **–** conserve resources by not printing every > e-mail.* > > From: Maoke <[email protected]> > Date: Wednesday, 6 February 2013 02:58 > To: Ian Farrer <[email protected]> > Cc: "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > > Subject: Re: [Softwires] Call for adoption of > draft-bfmk-softwire-unified-cpe-02 > > > > 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. > > [ian] That's not the intention. Only section 3.3 discusses DHCP in depth > to show how this works. The implementation is given as a should req. to be > in line with the DHCP provisioning should requirements in both MAP and > lw4o6. Point taken however – I'll try and make the rest of the document > (e.g. Except sec 3.3) less DHCP focused. > [maoke] in contrast, i don't think DHCP MUST be the only way for provisioning. i'd prefer the "e.g." rather than limiting the further mechanisms DHCP-focused. > > >> 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] If there are overlapping source ports, then this is also a problem > for the concentrator. If multiple initiators share the same v4 destination > address / source ports, on what basis can the initiator forward ingress > traffic? > [maoke] we have had at least 3 alternative strategies regarding source port overlapping and are comparing their pros/cons. practical usage has proved the availability to some extent. > > >> [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... > > [ian] Let's see what the outcome of the adoption call is then. > [maoke] i insist to propose considering the problems: 1) if DHCP is the only way that the unified CPE can do with? 2) if participating multiple domain is/cannot definitely be supported? 3) how the CPE support source port overlapping and fragmentation with multiple domain exits? i contributed these concerns to the community -- it is enough for me. if the draft is less qualified with my criteria, i just do not use it. as to the adoption, i have expressed my comments. the result is not in my concern. thanks and regards, maoke > > > - 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
