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

["Muley, Praveen V (Praveen)" <[e-mail]>]

Hi :

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, December 04, 2015 1:16 AM
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.  

PM >> Thanks for clarification. In that case removing figure 1 and referring correct reference diagram will help.

As already said, this draft defines protocol extension. How to use this extension is part of system design and is out of the scope.

PM >> It is important to explain what you are solving so that we  understand need for  protocol extension. Use case will also help knowing the completeness of the extension.

BTW, PMIP is not a tunneling but a control protocol, underlying tunneling can be GRE, IP-in-IP,...

PM >>  I meant PMIP signaled tunnels.  More importantly the question why use PMIP for control plane signaling in the use of hybrid access (specifically BBF use case) and what is its value add over say soft-GRE which doesn't require any state maintenance. We know from wifi deployment that there are some signaling load issues.


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.