Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

[Mingui Zhang <[e-mail]>]

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:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Friday, December 04, 2015 5:16 PM
> To: Muley, Praveen V (Praveen); [e-mail]; 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:[e-mail]]
> > Envoyé : vendredi 4 décembre 2015 09:45 À : SEITE Pierrick IMT/OLN;
> > [e-mail]; 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:[e-mail]] On Behalf Of
> > [e-mail]
> > Sent: Wednesday, December 02, 2015 12:22 AM
> > To: [e-mail]; 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:[e-mail]] 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
> > > <[e-mail]>
> > > 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: [e-mail]
> > > > #webpage: https://sites.google.com/site/hurryon
> > > >
> > > > On Nov 26, 2015, at 5:00 PM, Mingui Zhang <[e-mail]>
> > 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:[e-mail]] 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dmm
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > dmm mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dmm
> > > >
> > >
> > > _______________________________________________
> > > dmm mailing list
> > > [e-mail]
> > > 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
> > [e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm