Hi Ahmad, I am not a MIP expert. Please forgive me if I am wrong.
This draft merely specifies that the gateway is the B4 element and describes how a CID can be constructed to tunnel the packets to AFTR. That's it. The draft didn't alter the MH. If the MH decides to use CMIP, it can still create a tunnel to the HA. The ds-lite softwire could happen behind the HA which leaves the MH and HA stay untouched. For PMIP, the ds-lite gateway "could possibly coexit" with the MAG. Since Sri is one of the author of RFC5213, I will let him explain the details. So, I think this draft can be used independently with or without mobility. Cheers, Yiu On 5/14/10 12:11 PM, "Ahmad Muhanna" <[email protected]> wrote: > Hi Olaf, > > I thought that your comment was not a technical one:) so, I wanted to comment > on the procedural aspect of it. > But anyhow, the draft claims applicability to network mobility with RFC3775 > and RFC5213 being referenced. Having that claim in the draft is not justified > and there is a need for IETF mobility group to evaluate if the current IETF > mobility suite of protocols need this solution to start with. > > On the other hand, following the discussion, it is quite clear that this tool > is needed when 3GPP GTP network based mobility is used. If that the case, then > the draft need to reflect that specifically. Also, not to mention that > although this approach moves the NAT to a single network element, but it also > concentrates IPv4 traffic through a single network element creating a single > point of failure. > > Regards, > Ahmad > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Friday, May 14, 2010 9:28 AM >> To: Ahmad Muhanna >> Cc: [email protected] >> Subject: AW: [Softwires] GI-DS-lite as working group item? >> >> Hi Ahmad, >> >> thanks for your answer. I've frankly to say that I've not >> totally understood your concerns regarding this I-D: >> - Is it to limited to only one scenario or is it to broad in >> its approach? >> - Should such a document in your understanding serve for >> several different network scenarios (if it could) or should >> it be specific and applicable only to a specific migration need? >> - Would it help you to sharpen the text regarding the >> intent/scope of this document? >> >> Thank you and kind regards >> Olaf >> >>> -----Ursprüngliche Nachricht----- >>> Von: Ahmad Muhanna [mailto:[email protected]] >>> Gesendet: Freitag, 14. Mai 2010 14:45 >>> An: Bonneß, Olaf; [email protected] >>> Cc: [email protected] >>> Betreff: RE: [Softwires] GI-DS-lite as working group item? >>> >>> Hi Olaf, >>> Please see inline. >>> >>>> -----Original Message----- >>>> From: [email protected] >>>> [mailto:[email protected]] On Behalf Of >>>> [email protected] >>>> Sent: Friday, May 14, 2010 3:18 AM >>>> To: [email protected] >>>> Cc: [email protected] >>>> Subject: Re: [Softwires] GI-DS-lite as working group item? >>>> >>>> Hi folks, >>>> >>>> And to be clear: A WG document still needs work and discussion >>>> inside the WG. >>> >>>> But sometimes I have the feeling that today very often the >>>> requirements for a document to become a WG item are set >> equal to the >>>> requirements for a WG LC. >>> [Ahmad] >>> Not exactly. >>> >>> I understand very well that some operators need certain >> specific tools >>> to fit their own migration strategy. >>> Additionally, I do not want to debate the best way for operators to >>> achieve their specific migration strategy. But, the least >> acceptable >>> common sense is: We can not accept a document that claim >>> one-size-fits-all concept in order to satisfy the forth mentioned >>> specific migration strategy. IMO, before accepting whatever >> document, >>> that document needs to be specific and applicable only to that >>> specific migration need. >>> >>> Regards, >>> Ahmad >>> >>>> But this may be my personal feeling only. >>>> >>>> Kind regards >>>> Olaf >>>> _______________________________________________ >>>> Softwires mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >> > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
