Hi, Thanks for letting us know the draft does not intend to define the BBF hybrid access arch any more. And yes, I noticed the reference [WT-348] had been removed in the 02 version, but "Hybrid Access" is a term defined by BBF WT-348 so it should be removed from the text to avoid misleading.
> > As mentioned in Prague and Yokohama, the use case defined is the > > broadband use case for hybrid access. Without having proper discussion > > on the use case it will improper to look for the solution as we MAY > > not even know the complete architecture issues involved in broadband > > access hybrid use case which is what the Figure 1 refers too. <snip> Definitely. As the draft intends not to refer to BBF WT-348's "DSL+LTE" use-case, Figure 1 should be removed. Thanks, Mingui > -----Original Message----- > From: dmm [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Friday, December 04, 2015 5:16 PM > To: Muley, Praveen V (Praveen); [email protected]; Jong-Hyouk Lee > Cc: dmm > Subject: Re: [DMM] Call for adoption confirmation: > draft-seite-dmm-rg-multihoming-02 > > Hi, > > I think there is big misunderstood here... this draft does not intend to > define > the BBF hybrid access architecture... not even to address this specific > use-case. > Few months ago, we had a consensus (including AD) to not focus on a specific > use-case; we thus have removed all references to BBF use-case from this draft. > > As already said, this draft defines protocol extension. How to use this > extension > is part of system design and is out of the scope. > > BTW, PMIP is not a tunneling but a control protocol, underlying tunneling can > be GRE, IP-in-IP,... > > Pierrick > > > -----Message d'origine----- > > De : Muley, Praveen V (Praveen) > > [mailto:[email protected]] > > Envoyé : vendredi 4 décembre 2015 09:45 À : SEITE Pierrick IMT/OLN; > > [email protected]; Jong-Hyouk Lee Cc : dmm Objet : RE: [DMM] Call for > > adoption confirmation: draft-seite-dmm-rg-multihoming- > > 02 > > > > Hi : > > > > As mentioned in Prague and Yokohama, the use case defined is the > > broadband use case for hybrid access. Without having proper discussion > > on the use case it will improper to look for the solution as we MAY > > not even know the complete architecture issues involved in broadband > > access hybrid use case which is what the Figure 1 refers too. So its > > too pre-mature (oppose) to adopt this as WG document. > > > > If the use case different than multihomed RG then please have > > that network diagram in document and explain properly the use case. > > > > If you are saying this solution can be used for multi-homed RG , first > > of all why would you solve that use case using layers of tunnel as > > there are some other better solutions which doesn't require tunneling > > overlay. Given that these RG is very cheap device the performance of > > these devices goes down dramatically so obviously doesn't address the > > fundamental requirement of increasing the bandwidth to the end user. > > > > Why PMIP even if I have to use tunnel ? There are many other better > > tunneling technologies like soft-GRE. > > > > One another point is how fast the failure of underlay tunnel on LTE > > and DSL detected by LMA to avoid blackholing of traffic. It will be > > good if you can touch base on this in your draft. > > > > > > This draft only deals with mPCoAfailure detection is adressed > > > > > -Praveen > > > > > > > > > > > > -----Original Message----- > > From: dmm [mailto:[email protected]] On Behalf Of > > [email protected] > > Sent: Wednesday, December 02, 2015 12:22 AM > > To: [email protected]; Jong-Hyouk Lee > > Cc: dmm > > Subject: Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg- > > multihoming-02 > > > > 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:[email protected]] 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 > > > <[email protected]> > > > 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: [email protected] > > > > #webpage: https://sites.google.com/site/hurryon > > > > > > > > On Nov 26, 2015, at 5:00 PM, Mingui Zhang <[email protected]> > > 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 > > > > DSL+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:[email protected]] 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > > > > > > > > > _______________________________________________ > > > > dmm mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > > > _______________________________________________ > > > dmm mailing list > > > [email protected] > > > 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 > > [email protected] > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
