Hi Pierrick, I hope you know how to read. I said noone so far said SGW should be multihomed, i.e. it should send some of its traffic to fixed network.
In fact multihomed is wrong here as it is used for the hosts while we are talking here about SGW or RG which have LAN and WAN side interfaces. I believe this draft is not ready for adoption. Regards, Behcet On Wed, Dec 2, 2015 at 2:21 AM, <pierrick.se...@orange.com> wrote: > Hi Behcet, > > This extension is for any use-case requiring a MAG to be multihomed. For > sure, multihomed RG can be one of them, but there is no reason to restrict > MCoA to this use-case. > > Pierrick > >> -----Message d'origine----- >> De : dmm [mailto:dmm-boun...@ietf.org] De la part de Behcet Sarikaya >> Envoyé : mardi 1 décembre 2015 18:18 >> À : Jong-Hyouk Lee >> Cc : dmm >> Objet : Re: [DMM] Call for adoption confirmation: >> draft-seite-dmm-rg-multihoming- >> 02 >> >> Hi Jong-Hyouk, >> >> On Mon, Nov 30, 2015 at 10:34 AM, Jong-Hyouk Lee <jonghy...@gmail.com> >> wrote: >> > Hi all >> > >> > I support the adoption of this draft as a WG draft even with the >> > concerns pointed by Mingui. This draft has a merit of the introduction >> > of the generic protocol extension allowing a multihomed MAG >> >> No, the extension is for the RG, i.e. Residential Gateway which is a >> broadband or >> fixed network element. >> >> >> > to register more than one PCoA >> > to the LMA. It is definitely useful for a multihomed environment. >> >> Why would a MAG be multihomed? I am not aware of any proposals that e..g the >> serving gateway in 3GPP network where MAG is placed should be multihomed. >> >> >> Regards, >> Behcet >> > Authors >> > may update this draft to address Mingui’s comments if needed. >> > >> > J. >> > -- >> > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >> > Protocol Engineering Lab., Sangmyung University >> > >> > #email: jonghy...@gmail.com >> > #webpage: https://sites.google.com/site/hurryon >> > >> > On Nov 26, 2015, at 5:00 PM, Mingui Zhang <zhangmin...@huawei.com> wrote: >> > >> > Hi, >> > >> > I remember it was suggested to remove DSL, “Hybrid Access”, etc, and >> > the suggestion was acknowledged. We haven’t seen an updated version >> > yet. It is not ready to be adopted, I think. >> > >> > I have read the draft. I found the scope greatly shrinked from the 01 to >> > 02. >> > I guess the draft wants to fight through by providing a more generic >> > protocol extension, while awaiting for real use cases. And, Hybrid >> > Access could be treated as a potential use case (Actually, the DSL+LTE >> > scenario is now intentionally inherited from the 00 version as a use >> > case.). If I guess right, I don’t think it’s a good starting point >> > since it only covers a fragment of a possible solution. Besides the >> > care of addresses, there are many other gaps that have not been >> > touched: per-packet traffic classification and recombination, >> > performance measurement, the bypass requirement, etc. From the draft, >> > we cannot figure out a clear architectural overview. Section 3 doesn’t >> > help much. >> > >> > Hence, I oppose its adoption. >> > >> > Thanks, >> > Mingui >> > >> > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dapeng Liu >> > Sent: Thursday, November 26, 2015 12:22 AM >> > To: dmm >> > Subject: [DMM] Call for adoption confirmation: >> > draft-seite-dmm-rg-multihoming-02 >> > >> > Hello all, >> > >> > In IETF94, we initiated the call for adoption for the draft: >> > draft-seite-dmm-rg-multihoming-02: >> > http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02 >> > Seems have got sufficient support during the meeting. We'd like to >> > confirm the call for adoption in the mailing list for 2 weeks. >> > Please send your opinion and comments to the list before December 9. >> > >> > >> > Thanks, >> > ------ >> > Best Regards, >> > Dapeng&Jouni >> > >> > >> > >> > >> > >> > -- >> > >> > ------ >> > Best Regards, >> > Dapeng Liu >> > _______________________________________________ >> > dmm mailing list >> > dmm@ietf.org >> > https://www.ietf.org/mailman/listinfo/dmm >> > >> > >> > >> > _______________________________________________ >> > dmm mailing list >> > dmm@ietf.org >> > https://www.ietf.org/mailman/listinfo/dmm >> > >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
