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

[Dapeng Liu]

2015-12-03 3:02 GMT+08:00 Behcet Sarikaya :

> Hi Jouni,
>
>
> On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen 
> wrote:
> > As an individual contributor I support the adoption of this I-D. MCoA is
> a
> > feature that we still lack..
> >
>
> Are you sure?
>
> MCoA is solved in Netext Flow Mobility draft,
>
> draft-ietf-netext-pmipv6-flowmob-14
>
> is the latest draft.
>
> BTW there was an issue in WG adoption call in IETF 93 in Yokohama. The
> chair asked only those who accept. The chair unfortunately did not ask
> those who oppose.
>
> As you know, if the chair wishes to ask a single question then the
> right one is any opposes.
>
>
Hi Behcet,
As said during the meeting, the final call for adoption will be made on the
mailing list.  Not all the people who is interested in this work attended
the meeting. The question that asked during the meeting only to get
 general sense of the room for the adoption.

Thansk,
Dapeng



> Regards,
>
> Behcet
> > The document itself still needs quite a bit of work. For example, I
> wonder
> > if the caption for Figure 2 is correct. Also, Section 4.1. option fiels
> > descriptions are somewhat broken it seems. And so on multiple small nits
> > like unexpanded acronyms etc. However, these are mainly editorials. I
> have
> > no problem with the technical solution.
> >
> > - Jouni
> >
> >
> >
> > 11/25/2015, 8:22 AM, Dapeng Liu kirjoitti:
> >>
> >> 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
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> --
> >> 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
>



-- 

--
Best Regards,
Dapeng Liu
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Muley, Praveen V (Praveen)]

Hi :

-Original Message-
From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com] 
Sent: Friday, December 04, 2015 1:16 AM
To: Muley, Praveen V (Praveen); sarik...@ieee.org; 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:praveen.mu...@alcatel-lucent.com]
> Envoyé : vendredi 4 décembre 2015 09:45 À : SEITE Pierrick IMT/OLN; 
> sarik...@ieee.org; 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:dmm-boun...@ietf.org] On Behalf Of 
> pierrick.se...@orange.com
> Sent: Wednesday, December 02, 2015 12:22 AM
> To: sarik...@ieee.org; 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: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

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

[pierrick.seite]

Hi Suresh,

> -Message d'origine-
> De : dmm [mailto:dmm-boun...@ietf.org] De la part de Suresh Krishnan
> Envoyé : jeudi 10 décembre 2015 00:39
> À : Dapeng Liu; dmm
> Objet : Re: [DMM] Call for adoption confirmation: 
> draft-seite-dmm-rg-multihoming-
> 02
> 
> 
> On 11/25/2015 05:22 PM, Dapeng Liu wrote:
> > 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>:
> > 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.
> 
> I am generally open to exploring multipath binding support for PMIPv6. I do 
> have
> some comments on the content of the draft.
> 
> The example call flow in the draft is extremely confusing. Figure 1 shows LTE 
> and
> DSL as the access technologies and I am assuming the CPE/RG is where the MAG
> functionality is going to reside. If this is the case, why is WLAN being 
> shown like
> an uplink technology? Can you please clarify?
> 

Access technologies are only examples but I agree we should keep the same 
example across the document to avoid confusion.

RG shall be removed, only MAG will be used in next release.

> Also the term "hybrid access" is used in the draft without being defined. I 
> think it
> would make sense to define it, refer to an existing definition, or reword. I 
> am
> guessing lot of the confusion people are having regarding the relationship 
> this has
> to BBF work is related to the use of this term.
> 

Agreed. This term shall be removed.

Thanks

> Thanks
> Suresh
> 
> 
> ___
> 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,
France Telecom - 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 authorization.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this 
message was modified, changed or falsified.
Thank you.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[pierrick.seite]

Hi,

> -Message d'origine-
> De : Mingui Zhang [mailto:zhangmin...@huawei.com]
> Envoyé : mercredi 9 décembre 2015 03:54
> À : dirk.von-h...@telekom.de; SEITE Pierrick IMT/OLN; dmm@ietf.org
> Cc : alexandre.petre...@gmail.com
> Objet : RE: [DMM] Call for adoption confirmation: 
> draft-seite-dmm-rg-multihoming-
> 02
> 
> Hi,
> 
> I am not alone who find Figure 1 is misleading. Lots of people around know
> 'DSL+LTE' is a peculiar use case of BBF WT-348. 

Do you mean that using DSL and LTE together is a BBF trademark? ... come on. 
:-).. anyway, I don't care about using another example... why not WiFi and 
LTE... is it ok? Is there any SDO which claims exclusivity on this use-case ;-) 
?

Now that the draft intends to
> provide a generic protocol extension for mobility management systems, please
> drop that use case.
> 
> Looking at the structure of the doc, Figure 1 is obviously a good position to 
> give a
> generic reference model rather than a specific example, not to mention a
> misleading one.
> 
> In the text,
>" Flow-1,2 and 3 are distributed either on
>Tunnel-1 (over LTE) or Tunnel-2 (ober DSL), while Flow-4 is spread on
>both Tunnel-1 and 2. "
> s/ober/over/
> So, this indicates the doc aims to support both per-flow and per-packet 
> traffic
> distribution. This point could be explicitly stated.
> 

It is stated on section 3.2. but, you are right, it is maybe worth to clarify 
this in the introduction as well.


> In the figure,
> s/Flow0=-4/ Flow-4 /
> 
> I guess authors would produce an updated version to address the issues we've
> found.
> 

Yes of course. Thanks for the comments.

> Thanks,
> Mingui
> 
> > -Original Message-
> > From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]
> > Sent: Tuesday, December 08, 2015 6:06 PM
> > To: pierrick.se...@orange.com; dmm@ietf.org
> > Cc: alexandre.petre...@gmail.com
> > Subject: RE: [DMM] Call for adoption confirmation:
> > draft-seite-dmm-rg-multihoming-02
> >
> > Hi Pierrick,
> > Thank you for the clarification!
> > May I recommend then to exchange also the multiple occurrences of RG
> > in the draft text by - why not MAG?
> >
> > Your approach which I think of as mainly opting towards future
> > mobility management systems with multiple connections (e.g.
> > backhauling of vehicular/nomadic access nodes or MRs) otherwise might
> > be interpreted in a misleading direction ...
> >
> > Having said this I also would appreciate to replace the expression
> > 'hybrid' by 'multi-link' or 'multi-connected'. For an BBF-related
> > aggregated access bundling often called 'hybrid access' (see e.g.
> > BANANA activity) there are - as Mingui already pointed out - other
> > solution proposals available which consider in detail the specific existing 
> > gaps.
> >
> > IMHO I would also opting to replace the use case DSL+LTE by a more
> > general one e.g. multiple wireless and cellular links as WiFi+LTE or
> > LTE(provided by operator x) + LTE(provided by operator y) or even LTE+future
> 5G air interface ...
> > ;-)
> >
> > Thanks a lot!
> >
> > Best Regards
> > Dirk
> >
> > -Original Message-
> > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of
> > pierrick.se...@orange.com
> > Sent: Freitag, 4. Dezember 2015 12:07
> > To: Alexandre Petrescu; dmm
> > Subject: Re: [DMM] Call for adoption confirmation:
> > draft-seite-dmm-rg-multihoming-02
> >
> > Good point... moreover, "rg" means nothing here...
> >
> > > -Message d'origine-
> > > De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alexandre
> > > Petrescu Envoyé : vendredi 4 décembre 2015 12:02 À : dmm Objet : Re:
> > > [DMM] Call for adoption confirmation:
> > > draft-seite-dmm-rg-multihoming-
> > > 02
> > >
> > > Hi,
> > >
> > > I support adoption.
> > >
> > > One little note: the -rg- in filename makes think of Research Group.
> > > It would make sense to change the filename to avoid the use of -rg-,
> > > if it's not
> > too complicated.
> > >
> > > Alex
> > >
> > > Le 25/11/2015 17:22, Dapeng Liu a écrit :
> > > > 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>:
> > > > http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02
> > > > Seem

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

[pierrick.seite]

Hi Dirk,



> -Message d'origine-

> De : dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]

> Envoyé : mardi 8 décembre 2015 11:06

> À : SEITE Pierrick IMT/OLN; dmm@ietf.org

> Cc : alexandre.petre...@gmail.com

> Objet : RE: [DMM] Call for adoption confirmation: 
> draft-seite-dmm-rg-multihoming-

> 02

>

> Hi Pierrick,

> Thank you for the clarification!

> May I recommend then to exchange also the multiple occurrences of RG in the

> draft text by - why not MAG?

>


Sure, this doc must not refer to RG, MAG should be used instead . Thanks


> Your approach which I think of as mainly opting towards future mobility

> management systems with multiple connections (e.g. backhauling of

> vehicular/nomadic access nodes or MRs) otherwise might be interpreted in a

> misleading direction ...

>

> Having said this I also would appreciate to replace the expression 'hybrid' by

> 'multi-link' or 'multi-connected'. For an BBF-related aggregated access 
> bundling

> often called 'hybrid access' (see e.g. BANANA activity) there are - as Mingui

> already pointed out - other solution proposals available which consider in 
> detail the

> specific existing gaps.

>



Agreed. Let's use IETF terminology as per RFC4885 and talk about multihoming 
instead.



> IMHO I would also opting to replace the use case DSL+LTE by a more general one

> e.g. multiple wireless and cellular links as WiFi+LTE or LTE(provided by 
> operator x)

> + LTE(provided by operator y) or even LTE+future 5G air interface ...

> ;-)

>



Even if I do not see why Wifi+LTE is more general than DSL+LTE,  I have no 
problem with using another example :-) we will change the example in next 
revision.



Thanks,

Pierrick



> Thanks a lot!

>

> Best Regards

> Dirk

>

> -Original Message-

> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of

> pierrick.se...@orange.com<mailto:pierrick.se...@orange.com>

> Sent: Freitag, 4. Dezember 2015 12:07

> To: Alexandre Petrescu; dmm

> Subject: Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-

> multihoming-02

>

> Good point... moreover, "rg" means nothing here...

>

> > -----Message d'origine-----

> > De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alexandre

> > Petrescu Envoyé : vendredi 4 décembre 2015 12:02 À : dmm Objet : Re:

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

> > 02

> >

> > Hi,

> >

> > I support adoption.

> >

> > One little note: the -rg- in filename makes think of Research Group.

> > It would make sense to change the filename to avoid the use of -rg-, if 
> > it's not

> too complicated.

> >

> > Alex

> >

> > Le 25/11/2015 17:22, Dapeng Liu a écrit :

> > > 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>:

> > > 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

> > >

> > >

> > >

> > >

> > >

> > > --

> > >

> > > --

> > > Best Regards,

> > > Dapeng Liu

> > >

> > >

> > > ___

> > > dmm mailing list

> > > dmm@ietf.org<mailto:dmm@ietf.org>

> > > https://www.ietf.org/mailman/listinfo/dmm

> > >

> >

> > ___

> > dmm mailing list

> > dmm@ietf.org<mailto: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 et

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

[pierrick.seite]

> -Message d'origine-
> De : Mingui Zhang [mailto:zhangmin...@huawei.com]
> Envoyé : mercredi 9 décembre 2015 10:32
> À : SEITE Pierrick IMT/OLN; dirk.von-h...@telekom.de; dmm@ietf.org
> Cc : alexandre.petre...@gmail.com
> Objet : RE: [DMM] Call for adoption confirmation: 
> draft-seite-dmm-rg-multihoming-
> 02
> 
> Hi Pierrick,
> 
> > Do you mean that using DSL and LTE together is a BBF trademark? ...
> > come on. :-).. anyway, I don't care about using another example... why
> > not WiFi and LTE... is it ok? Is there any SDO which claims exclusivity on 
> > this
> use-case ;-) ?
> 
> :-)
> 
> I would say "exclusivity" is exaggerated. The fact is that people already 
> have that
> background knowledge so that they can easily get the impression that this is
> talking about the BBF use case. Also, the older versions did refer to WT-348 
> use
> case.
> 
> There are alternative examples, as you've already suggested, that can be used 
> in
> the placeholder. It would be easier to use them.
> 

Ok, no problem. 

> Thanks,
> Mingui
> 
> > -Original Message-
> > From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com]
> > Sent: Wednesday, December 09, 2015 5:02 PM
> > To: Mingui Zhang; dirk.von-h...@telekom.de; dmm@ietf.org
> > Cc: alexandre.petre...@gmail.com
> > Subject: RE: [DMM] Call for adoption confirmation:
> > draft-seite-dmm-rg-multihoming-02
> >
> > Hi,
> >
> > > -Message d'origine-
> > > De : Mingui Zhang [mailto:zhangmin...@huawei.com] Envoyé : mercredi
> > > 9 décembre 2015 03:54 À : dirk.von-h...@telekom.de; SEITE Pierrick
> > > IMT/OLN; dmm@ietf.org Cc : alexandre.petre...@gmail.com Objet : RE:
> > > [DMM] Call for adoption confirmation:
> > > draft-seite-dmm-rg-multihoming-
> > > 02
> > >
> > > Hi,
> > >
> > > I am not alone who find Figure 1 is misleading. Lots of people
> > > around know 'DSL+LTE' is a peculiar use case of BBF WT-348.
> >
> > Do you mean that using DSL and LTE together is a BBF trademark? ...
> > come on. :-).. anyway, I don't care about using another example... why
> > not WiFi and LTE... is it ok? Is there any SDO which claims exclusivity on 
> > this
> use-case ;-) ?
> >
> > Now that the draft intends to
> > > provide a generic protocol extension for mobility management
> > > systems, please drop that use case.
> > >
> > > Looking at the structure of the doc, Figure 1 is obviously a good
> > > position to give a generic reference model rather than a specific
> > > example, not to mention a misleading one.
> > >
> > > In the text,
> > >" Flow-1,2 and 3 are distributed either on
> > >Tunnel-1 (over LTE) or Tunnel-2 (ober DSL), while Flow-4 is spread on
> > >both Tunnel-1 and 2. "
> > > s/ober/over/
> > > So, this indicates the doc aims to support both per-flow and
> > > per-packet traffic distribution. This point could be explicitly stated.
> > >
> >
> > It is stated on section 3.2. but, you are right, it is maybe worth to
> > clarify this in the introduction as well.
> >
> >
> > > In the figure,
> > > s/Flow0=-4/ Flow-4 /
> > >
> > > I guess authors would produce an updated version to address the
> > > issues we've found.
> > >
> >
> > Yes of course. Thanks for the comments.
> >
> > > Thanks,
> > > Mingui
> > >
> > > > -Original Message-
> > > > From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]
> > > > Sent: Tuesday, December 08, 2015 6:06 PM
> > > > To: pierrick.se...@orange.com; dmm@ietf.org
> > > > Cc: alexandre.petre...@gmail.com
> > > > Subject: RE: [DMM] Call for adoption confirmation:
> > > > draft-seite-dmm-rg-multihoming-02
> > > >
> > > > Hi Pierrick,
> > > > Thank you for the clarification!
> > > > May I recommend then to exchange also the multiple occurrences of
> > > > RG in the draft text by - why not MAG?
> > > >
> > > > Your approach which I think of as mainly opting towards future
> > > > mobility management systems with multiple connections (e.g.
> > > > backhauling of vehicular/nomadic access nodes or MRs) otherwise
> > > > might be interpreted in a misleading direction ...
> > > >
> > > > Having said this I also would appreciate to replace the expression
> > &

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

[Mingui Zhang]

Hi Pierrick,

> Do you mean that using DSL and LTE together is a BBF trademark? ... come
> on. :-).. anyway, I don't care about using another example... why not WiFi and
> LTE... is it ok? Is there any SDO which claims exclusivity on this use-case 
> ;-) ?

:-)

I would say "exclusivity" is exaggerated. The fact is that people already have 
that background knowledge so that they can easily get the impression that this 
is talking about the BBF use case. Also, the older versions did refer to WT-348 
use case. 

There are alternative examples, as you've already suggested, that can be used 
in the placeholder. It would be easier to use them. 

Thanks,
Mingui

> -Original Message-
> From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com]
> Sent: Wednesday, December 09, 2015 5:02 PM
> To: Mingui Zhang; dirk.von-h...@telekom.de; dmm@ietf.org
> Cc: alexandre.petre...@gmail.com
> Subject: RE: [DMM] Call for adoption confirmation:
> draft-seite-dmm-rg-multihoming-02
> 
> Hi,
> 
> > -Message d'origine-
> > De : Mingui Zhang [mailto:zhangmin...@huawei.com] Envoyé : mercredi 9
> > décembre 2015 03:54 À : dirk.von-h...@telekom.de; SEITE Pierrick
> > IMT/OLN; dmm@ietf.org Cc : alexandre.petre...@gmail.com Objet : RE:
> > [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-
> > 02
> >
> > Hi,
> >
> > I am not alone who find Figure 1 is misleading. Lots of people around
> > know 'DSL+LTE' is a peculiar use case of BBF WT-348.
> 
> Do you mean that using DSL and LTE together is a BBF trademark? ... come
> on. :-).. anyway, I don't care about using another example... why not WiFi and
> LTE... is it ok? Is there any SDO which claims exclusivity on this use-case 
> ;-) ?
> 
> Now that the draft intends to
> > provide a generic protocol extension for mobility management systems,
> > please drop that use case.
> >
> > Looking at the structure of the doc, Figure 1 is obviously a good
> > position to give a generic reference model rather than a specific
> > example, not to mention a misleading one.
> >
> > In the text,
> >" Flow-1,2 and 3 are distributed either on
> >Tunnel-1 (over LTE) or Tunnel-2 (ober DSL), while Flow-4 is spread on
> >both Tunnel-1 and 2. "
> > s/ober/over/
> > So, this indicates the doc aims to support both per-flow and
> > per-packet traffic distribution. This point could be explicitly stated.
> >
> 
> It is stated on section 3.2. but, you are right, it is maybe worth to clarify 
> this in
> the introduction as well.
> 
> 
> > In the figure,
> > s/Flow0=-4/ Flow-4 /
> >
> > I guess authors would produce an updated version to address the issues
> > we've found.
> >
> 
> Yes of course. Thanks for the comments.
> 
> > Thanks,
> > Mingui
> >
> > > -Original Message-
> > > From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]
> > > Sent: Tuesday, December 08, 2015 6:06 PM
> > > To: pierrick.se...@orange.com; dmm@ietf.org
> > > Cc: alexandre.petre...@gmail.com
> > > Subject: RE: [DMM] Call for adoption confirmation:
> > > draft-seite-dmm-rg-multihoming-02
> > >
> > > Hi Pierrick,
> > > Thank you for the clarification!
> > > May I recommend then to exchange also the multiple occurrences of RG
> > > in the draft text by - why not MAG?
> > >
> > > Your approach which I think of as mainly opting towards future
> > > mobility management systems with multiple connections (e.g.
> > > backhauling of vehicular/nomadic access nodes or MRs) otherwise
> > > might be interpreted in a misleading direction ...
> > >
> > > Having said this I also would appreciate to replace the expression
> > > 'hybrid' by 'multi-link' or 'multi-connected'. For an BBF-related
> > > aggregated access bundling often called 'hybrid access' (see e.g.
> > > BANANA activity) there are - as Mingui already pointed out - other
> > > solution proposals available which consider in detail the specific 
> > > existing
> gaps.
> > >
> > > IMHO I would also opting to replace the use case DSL+LTE by a more
> > > general one e.g. multiple wireless and cellular links as WiFi+LTE or
> > > LTE(provided by operator x) + LTE(provided by operator y) or even
> > > LTE+future
> > 5G air interface ...
> > > ;-)
> > >
> > > Thanks a lot!
> > >
> > > Best Regards
> > > Dirk
> > >
> > > -Original Message-
> > > From: dmm [mailto:dmm

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

[pierrick.seite]

Hi,


> -Message d'origine-
> De : dmm [mailto:dmm-boun...@ietf.org] De la part de Erunika
> Envoyé : mercredi 9 décembre 2015 05:13
> À : dmm@ietf.org
> Objet : Re: [DMM] Call for adoption confirmation: 
> draft-seite-dmm-rg-multihoming-
> 02
> 
> Hi,
> 
> I also support the adoption.
> 
> However, I have a slight concern.I find Figure 1 little too specific and it 
> might
> mislead the audience.
> Maybe the wording should be changed in order to emphasize that this is just an
> instance.

You're right. Next revision shall clarify this.

> Or else, I think the use case should be dropped.
> However, having an example would be extremely helpful in understanding.
> So I would suggest the former.
> 

Agreed. Thanks for your comments.

Pierrick

> Regards,
> IRU
> 
> On 12/4/2015 8:01 PM, Alexandre Petrescu wrote:
> > Hi,
> >
> > I support adoption.
> >
> > One little note: the -rg- in filename makes think of Research Group.
> > It would make sense to change the filename to avoid the use of -rg-,
> > if it's not too complicated.
> >
> > Alex
> >
> > Le 25/11/2015 17:22, Dapeng Liu a écrit :
> >> 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>:
> >> 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
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> --
> >> 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,
France Telecom - 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 authorization.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this 
message was modified, changed or falsified.
Thank you.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Sri Gundavelli (sgundave)]

>>>
>>>
>>>
>>> Do you mean that using DSL and LTE together is a BBF trademark? ...
>>> come on. :-).. anyway, I don't care about using another example... why
>>> not WiFi and LTE... is it ok? Is there any SDO which claims
>>>exclusivity on this
>>use-case ;-) ?

> Ok, no problem.

Now, I guess, it significantly improves of odds of some new protocol that
folks plan to define to be adopted as THE solution for the target SDO :)

FWIW, we will absolutely make sure this extension stays relevant to any
pairs of access technologies, with no restrictions.


Sri 





___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Erunika]

Hi,

I also support the adoption.

However, I have a slight concern.I find Figure 1 little too specific and 
it might mislead the audience.
Maybe the wording should be changed in order to emphasize that this is 
just an instance.

Or else, I think the use case should be dropped.
However, having an example would be extremely helpful in understanding. 
So I would suggest the former.


Regards,
IRU

On 12/4/2015 8:01 PM, Alexandre Petrescu wrote:

Hi,

I support adoption.

One little note: the -rg- in filename makes think of Research Group.  
It would make sense to change the filename to avoid the use of -rg-, 
if it's not too complicated.


Alex

Le 25/11/2015 17:22, Dapeng Liu a écrit :

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





--

--
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

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

[Jouni]

> On 08 Dec 2015, at 18:53, Mingui Zhang <zhangmin...@huawei.com> wrote:
> 
> Hi,
> 
> I am not alone who find Figure 1 is misleading. Lots of people around know 
> 'DSL+LTE' is a peculiar use case of BBF WT-348. Now that the draft intends to 
> provide a generic protocol extension for mobility management systems, please 
> drop that use case. 

I do not see why giving an example which happens to depict access technologies 
such as LTE and DSL would be somehow exclusive to some specific SDO. 

- Jouni

> 
> Looking at the structure of the doc, Figure 1 is obviously a good position to 
> give a generic reference model rather than a specific example, not to mention 
> a misleading one. 
> 
> In the text, 
>   " Flow-1,2 and 3 are distributed either on
>   Tunnel-1 (over LTE) or Tunnel-2 (ober DSL), while Flow-4 is spread on
>   both Tunnel-1 and 2. "
> s/ober/over/
> So, this indicates the doc aims to support both per-flow and per-packet 
> traffic distribution. This point could be explicitly stated. 
> 
> In the figure,
> s/Flow0=-4/ Flow-4 /
> 
> I guess authors would produce an updated version to address the issues we've 
> found.
> 
> Thanks,
> Mingui
> 
>> -Original Message-
>> From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]
>> Sent: Tuesday, December 08, 2015 6:06 PM
>> To: pierrick.se...@orange.com; dmm@ietf.org
>> Cc: alexandre.petre...@gmail.com
>> Subject: RE: [DMM] Call for adoption confirmation:
>> draft-seite-dmm-rg-multihoming-02
>> 
>> Hi Pierrick,
>> Thank you for the clarification!
>> May I recommend then to exchange also the multiple occurrences of RG in the
>> draft text by - why not MAG?
>> 
>> Your approach which I think of as mainly opting towards future mobility
>> management systems with multiple connections (e.g. backhauling of
>> vehicular/nomadic access nodes or MRs) otherwise might be interpreted in a
>> misleading direction ...
>> 
>> Having said this I also would appreciate to replace the expression 'hybrid' 
>> by
>> 'multi-link' or 'multi-connected'. For an BBF-related aggregated access 
>> bundling
>> often called 'hybrid access' (see e.g. BANANA activity) there are - as Mingui
>> already pointed out - other solution proposals available which consider in 
>> detail
>> the specific existing gaps.
>> 
>> IMHO I would also opting to replace the use case DSL+LTE by a more general
>> one e.g. multiple wireless and cellular links as WiFi+LTE or LTE(provided by
>> operator x) + LTE(provided by operator y) or even LTE+future 5G air 
>> interface ...
>> ;-)
>> 
>> Thanks a lot!
>> 
>> Best Regards
>> Dirk
>> 
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of
>> pierrick.se...@orange.com
>> Sent: Freitag, 4. Dezember 2015 12:07
>> To: Alexandre Petrescu; dmm
>> Subject: Re: [DMM] Call for adoption confirmation:
>> draft-seite-dmm-rg-multihoming-02
>> 
>> Good point... moreover, "rg" means nothing here...
>> 
>>> -Message d'origine-
>>> De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alexandre
>>> Petrescu Envoyé : vendredi 4 décembre 2015 12:02 À : dmm Objet : Re:
>>> [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-
>>> 02
>>> 
>>> Hi,
>>> 
>>> I support adoption.
>>> 
>>> One little note: the -rg- in filename makes think of Research Group.
>>> It would make sense to change the filename to avoid the use of -rg-, if 
>>> it's not
>> too complicated.
>>> 
>>> Alex
>>> 
>>> Le 25/11/2015 17:22, Dapeng Liu a écrit :
>>>> 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>:
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> --
>>>> Best Regards,
>>>> Dapeng 

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

[Mingui Zhang]

Hi,

I am not alone who find Figure 1 is misleading. Lots of people around know 
'DSL+LTE' is a peculiar use case of BBF WT-348. Now that the draft intends to 
provide a generic protocol extension for mobility management systems, please 
drop that use case. 

Looking at the structure of the doc, Figure 1 is obviously a good position to 
give a generic reference model rather than a specific example, not to mention a 
misleading one. 

In the text, 
   " Flow-1,2 and 3 are distributed either on
   Tunnel-1 (over LTE) or Tunnel-2 (ober DSL), while Flow-4 is spread on
   both Tunnel-1 and 2. "
s/ober/over/
So, this indicates the doc aims to support both per-flow and per-packet traffic 
distribution. This point could be explicitly stated. 

In the figure,
s/Flow0=-4/ Flow-4 /

I guess authors would produce an updated version to address the issues we've 
found.

Thanks,
Mingui

> -Original Message-
> From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]
> Sent: Tuesday, December 08, 2015 6:06 PM
> To: pierrick.se...@orange.com; dmm@ietf.org
> Cc: alexandre.petre...@gmail.com
> Subject: RE: [DMM] Call for adoption confirmation:
> draft-seite-dmm-rg-multihoming-02
> 
> Hi Pierrick,
> Thank you for the clarification!
> May I recommend then to exchange also the multiple occurrences of RG in the
> draft text by - why not MAG?
> 
> Your approach which I think of as mainly opting towards future mobility
> management systems with multiple connections (e.g. backhauling of
> vehicular/nomadic access nodes or MRs) otherwise might be interpreted in a
> misleading direction ...
> 
> Having said this I also would appreciate to replace the expression 'hybrid' by
> 'multi-link' or 'multi-connected'. For an BBF-related aggregated access 
> bundling
> often called 'hybrid access' (see e.g. BANANA activity) there are - as Mingui
> already pointed out - other solution proposals available which consider in 
> detail
> the specific existing gaps.
> 
> IMHO I would also opting to replace the use case DSL+LTE by a more general
> one e.g. multiple wireless and cellular links as WiFi+LTE or LTE(provided by
> operator x) + LTE(provided by operator y) or even LTE+future 5G air interface 
> ...
> ;-)
> 
> Thanks a lot!
> 
> Best Regards
> Dirk
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of
> pierrick.se...@orange.com
> Sent: Freitag, 4. Dezember 2015 12:07
> To: Alexandre Petrescu; dmm
> Subject: Re: [DMM] Call for adoption confirmation:
> draft-seite-dmm-rg-multihoming-02
> 
> Good point... moreover, "rg" means nothing here...
> 
> > -Message d'origine-
> > De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alexandre
> > Petrescu Envoyé : vendredi 4 décembre 2015 12:02 À : dmm Objet : Re:
> > [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-
> > 02
> >
> > Hi,
> >
> > I support adoption.
> >
> > One little note: the -rg- in filename makes think of Research Group.
> > It would make sense to change the filename to avoid the use of -rg-, if 
> > it's not
> too complicated.
> >
> > Alex
> >
> > Le 25/11/2015 17:22, Dapeng Liu a écrit :
> > > 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>:
> > > 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
> > >
> > >
> > >
> > >
> > >
> > > --
> > >
> > > --
> > > 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
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites o

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

[Mingui Zhang]

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.


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:dmm-boun...@ietf.org] On Behalf Of
> pierrick.se...@orange.com
> Sent: Friday, December 04, 2015 5:16 PM
> To: Muley, Praveen V (Praveen); sarik...@ieee.org; 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:praveen.mu...@alcatel-lucent.com]
> > Envoyé : vendredi 4 décembre 2015 09:45 À : SEITE Pierrick IMT/OLN;
> > sarik...@ieee.org; 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:dmm-boun...@ietf.org] On Behalf Of
> > pierrick.se...@orange.com
> > Sent: Wednesday, December 02, 2015 12:22 AM
> > To: sarik...@ieee.org; 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: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

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

[Sri Gundavelli (sgundave)]

> but "Hybrid Access" is a term defined by BBF WT-348 so it should be
>removed from the text to avoid misleading.

We will consider this feedback.


> As the draft intends not to refer to BBF WT-348's "DSL+LTE" use-case,
>Figure 1 should be removed.
 

The extension is not tied to any specific access technology and its
perfectly reasonable to refer to any access technology. We will make the
wording clear that its only an example.



Sri





On 12/6/15, 7:29 PM, "dmm on behalf of Mingui Zhang" <dmm-boun...@ietf.org
on behalf of zhangmin...@huawei.com> wrote:

>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.
>
>
>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:dmm-boun...@ietf.org] On Behalf Of
>> pierrick.se...@orange.com
>> Sent: Friday, December 04, 2015 5:16 PM
>> To: Muley, Praveen V (Praveen); sarik...@ieee.org; 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:praveen.mu...@alcatel-lucent.com]
>> > Envoyé : vendredi 4 décembre 2015 09:45 À : SEITE Pierrick IMT/OLN;
>> > sarik...@ieee.org; 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:dmm-boun...@ietf.org] O

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

[Alexandre Petrescu]

Hi,

I support adoption.

One little note: the -rg- in filename makes think of Research Group.  It 
would make sense to change the filename to avoid the use of -rg-, if 
it's not too complicated.


Alex

Le 25/11/2015 17:22, Dapeng Liu a écrit :

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





--

--
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

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

[pierrick.seite]

Good point... moreover, "rg" means nothing here... 

> -Message d'origine-
> De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alexandre Petrescu
> Envoyé : vendredi 4 décembre 2015 12:02
> À : dmm
> Objet : Re: [DMM] Call for adoption confirmation: 
> draft-seite-dmm-rg-multihoming-
> 02
> 
> Hi,
> 
> I support adoption.
> 
> One little note: the -rg- in filename makes think of Research Group.  It 
> would make
> sense to change the filename to avoid the use of -rg-, if it's not too 
> complicated.
> 
> Alex
> 
> Le 25/11/2015 17:22, Dapeng Liu a écrit :
> > 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>:
> > 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
> >
> >
> >
> >
> >
> > --
> >
> > --
> > 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

_

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

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

[Sri Gundavelli (sgundave)]

> For me (as an individual contributor) the I-D gives a standard way to
>register multiple transport connections/tunnels between a MAG and a LMA,
potentially over different technologies (wired, wireless, ..) on the
transport network side without needing to rely on engineering solutions


Ack. MAG's ability to register multiple IP transport end points is a basic
protocol semantic which is always present in enterprise architectures.

Problem with this thread it confuses the hell out of every thing. You
cannot explain and you cannot have a meaningful conversation. Pierrick
gave up and now I give up. But, this is not new; WG after WG, same folks
and same pattern.



Sri











On 12/3/15 11:38 AM, "dmm on behalf of Jouni Korhonen"
 wrote:

>Behcet,
>
>12/3/2015, 10:43 AM, Behcet Sarikaya kirjoitti:
>> Hi Jouni,
>>
>> On Wed, Dec 2, 2015 at 2:29 PM, Jouni Korhonen 
>>wrote:
>>> Behcet,
>>>
>>> 12/2/2015, 11:02 AM, Behcet Sarikaya kirjoitti:

 Hi Jouni,


 On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen

 wrote:
>
> As an individual contributor I support the adoption of this I-D.
>MCoA is
> a
> feature that we still lack..
>

 Are you sure?

 MCoA is solved in Netext Flow Mobility draft,

 draft-ietf-netext-pmipv6-flowmob-14

 is the latest draft.
>>>
>>>
>>> Sorry for my improper wording regarding which part of the MCoA I
>>>meant. I
>>> don't see how draft-ietf-netext-pmipv6-flowmob-14 would handle the
>>>case of
>>> registration when the Proxy-CoAs are from the same MAG.
>>
>> I wonder why would that be needed?
>> MN doesn't need it.
>> So this draft seems to be addressing a non-problem.
>
>I'll let the WG to determine whether the feature is needed or not.
>
>For me (as an individual contributor) the I-D gives a standard way to
>register multiple transport connections/tunnels between a MAG and a LMA,
>potentially over different technologies (wired, wireless, ..) on the
>transport network side without needing to rely on engineering solutions
>to achieve the same (yes - I could do a somewhat similar solution e.g.
>using MPLS but that would then be loaded with all kinds of assumptions
>that may or may not work in multi vendor and cross operator environment).
>
>- JOuni
>
>>
>> Regards,
>>
>> Behcet
>>> The netext draft
>>> specifically states Proxy-CoAs are from different MAGs.
>>>
>>> But it was a good thing you brought this up. The two I-Ds need to be in
>>> sync.
>>>

 BTW there was an issue in WG adoption call in IETF 93 in Yokohama. The
>>>
>>>
>>> IETF 94 I presume.. AFAIR we did not ask for adoption in IETF 93.
>>>
 chair asked only those who accept. The chair unfortunately did not ask
 those who oppose.

 As you know, if the chair wishes to ask a single question then the
 right one is any opposes.
>>>
>>>
>>> Obviously you are right here but I cannot really comment on this what
>>> happened in Yokohama since I was not on site or not even participating
>>> remotely.
>>>
>>> Anyway, all adoption calls are confirmed on the mailing list and the
>>>"sense
>>> of the room" during the meeting merely serves as informative quidance
>>>for
>>> chairs.
>>>
>>> - Jouni
>>>
>>>

 Regards,

 Behcet
>
> The document itself still needs quite a bit of work. For example, I
> wonder
> if the caption for Figure 2 is correct. Also, Section 4.1. option
>fiels
> descriptions are somewhat broken it seems. And so on multiple small
>nits
> like unexpanded acronyms etc. However, these are mainly editorials. I
> have
> no problem with the technical solution.
>
> - Jouni
>
>
>
> 11/25/2015, 8:22 AM, Dapeng Liu kirjoitti:
>>
>>
>> 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
>>
>>
>>
>>
>>
>> --
>>
>> --
>> 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

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

[Lyle Bertz]

As an individual contributor I support the adoption of the draft as a WG
draft.

Lyle

On Wed, Nov 25, 2015 at 10:22 AM, Dapeng Liu  wrote:

> 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
>
>
>
>
>
> --
>
> --
> 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

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

[Jouni Korhonen]

Behcet,

12/3/2015, 10:43 AM, Behcet Sarikaya kirjoitti:

Hi Jouni,

On Wed, Dec 2, 2015 at 2:29 PM, Jouni Korhonen  wrote:

Behcet,

12/2/2015, 11:02 AM, Behcet Sarikaya kirjoitti:


Hi Jouni,


On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen 
wrote:


As an individual contributor I support the adoption of this I-D. MCoA is
a
feature that we still lack..



Are you sure?

MCoA is solved in Netext Flow Mobility draft,

draft-ietf-netext-pmipv6-flowmob-14

is the latest draft.



Sorry for my improper wording regarding which part of the MCoA I meant. I
don't see how draft-ietf-netext-pmipv6-flowmob-14 would handle the case of
registration when the Proxy-CoAs are from the same MAG.


I wonder why would that be needed?
MN doesn't need it.
So this draft seems to be addressing a non-problem.


I'll let the WG to determine whether the feature is needed or not.

For me (as an individual contributor) the I-D gives a standard way to 
register multiple transport connections/tunnels between a MAG and a LMA, 
potentially over different technologies (wired, wireless, ..) on the 
transport network side without needing to rely on engineering solutions 
to achieve the same (yes - I could do a somewhat similar solution e.g. 
using MPLS but that would then be loaded with all kinds of assumptions 
that may or may not work in multi vendor and cross operator environment).


- JOuni



Regards,

Behcet

The netext draft
specifically states Proxy-CoAs are from different MAGs.

But it was a good thing you brought this up. The two I-Ds need to be in
sync.



BTW there was an issue in WG adoption call in IETF 93 in Yokohama. The



IETF 94 I presume.. AFAIR we did not ask for adoption in IETF 93.


chair asked only those who accept. The chair unfortunately did not ask
those who oppose.

As you know, if the chair wishes to ask a single question then the
right one is any opposes.



Obviously you are right here but I cannot really comment on this what
happened in Yokohama since I was not on site or not even participating
remotely.

Anyway, all adoption calls are confirmed on the mailing list and the "sense
of the room" during the meeting merely serves as informative quidance for
chairs.

- Jouni




Regards,

Behcet


The document itself still needs quite a bit of work. For example, I
wonder
if the caption for Figure 2 is correct. Also, Section 4.1. option fiels
descriptions are somewhat broken it seems. And so on multiple small nits
like unexpanded acronyms etc. However, these are mainly editorials. I
have
no problem with the technical solution.

- Jouni



11/25/2015, 8:22 AM, Dapeng Liu kirjoitti:



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





--

--
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

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

[Alper Yegin]

I, obviously, support adoption of this I-D.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Sri Gundavelli (sgundave)]

I support the adoption of draft-seite-dmm-rg-multihoming as. WG document. 

The ability for the MAG to register multiple transport end points with the LMA 
is a basic protocol semantic. How a system architecture uses this extension is 
a deployment consideration.

Sri


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Behcet Sarikaya]

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
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> > --
>> > Best Regards,
>> > Dapeng Liu
>> > ___
>> > dmm mailing list
>> > dmm@ietf.org
>> > ht

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

[Behcet Sarikaya]

Hi Jouni,


On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen  wrote:
> As an individual contributor I support the adoption of this I-D. MCoA is a
> feature that we still lack..
>

Are you sure?

MCoA is solved in Netext Flow Mobility draft,

draft-ietf-netext-pmipv6-flowmob-14

is the latest draft.

BTW there was an issue in WG adoption call in IETF 93 in Yokohama. The
chair asked only those who accept. The chair unfortunately did not ask
those who oppose.

As you know, if the chair wishes to ask a single question then the
right one is any opposes.

Regards,

Behcet
> The document itself still needs quite a bit of work. For example, I wonder
> if the caption for Figure 2 is correct. Also, Section 4.1. option fiels
> descriptions are somewhat broken it seems. And so on multiple small nits
> like unexpanded acronyms etc. However, these are mainly editorials. I have
> no problem with the technical solution.
>
> - Jouni
>
>
>
> 11/25/2015, 8:22 AM, Dapeng Liu kirjoitti:
>>
>> 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
>>
>>
>>
>>
>>
>> --
>>
>> --
>> 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

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

[Jouni Korhonen]

Behcet,

12/2/2015, 11:02 AM, Behcet Sarikaya kirjoitti:

Hi Jouni,


On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen  wrote:

As an individual contributor I support the adoption of this I-D. MCoA is a
feature that we still lack..



Are you sure?

MCoA is solved in Netext Flow Mobility draft,

draft-ietf-netext-pmipv6-flowmob-14

is the latest draft.


Sorry for my improper wording regarding which part of the MCoA I meant. 
I don't see how draft-ietf-netext-pmipv6-flowmob-14 would handle the 
case of registration when the Proxy-CoAs are from the same MAG. The 
netext draft specifically states Proxy-CoAs are from different MAGs.


But it was a good thing you brought this up. The two I-Ds need to be in 
sync.




BTW there was an issue in WG adoption call in IETF 93 in Yokohama. The


IETF 94 I presume.. AFAIR we did not ask for adoption in IETF 93.


chair asked only those who accept. The chair unfortunately did not ask
those who oppose.

As you know, if the chair wishes to ask a single question then the
right one is any opposes.


Obviously you are right here but I cannot really comment on this what 
happened in Yokohama since I was not on site or not even participating 
remotely.


Anyway, all adoption calls are confirmed on the mailing list and the 
"sense of the room" during the meeting merely serves as informative 
quidance for chairs.


- Jouni



Regards,

Behcet

The document itself still needs quite a bit of work. For example, I wonder
if the caption for Figure 2 is correct. Also, Section 4.1. option fiels
descriptions are somewhat broken it seems. And so on multiple small nits
like unexpanded acronyms etc. However, these are mainly editorials. I have
no problem with the technical solution.

- Jouni



11/25/2015, 8:22 AM, Dapeng Liu kirjoitti:


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





--

--
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

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

[pierrick.seite]

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
> >
> >
> >
> >
> >
> > --
> >
> > --
> > 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

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

[Jouni Korhonen]

As an individual contributor I support the adoption of this I-D. MCoA is 
a feature that we still lack..


The document itself still needs quite a bit of work. For example, I 
wonder if the caption for Figure 2 is correct. Also, Section 4.1. option 
fiels descriptions are somewhat broken it seems. And so on multiple 
small nits like unexpanded acronyms etc. However, these are mainly 
editorials. I have no problem with the technical solution.


- Jouni



11/25/2015, 8:22 AM, Dapeng Liu kirjoitti:

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





--

--
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

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

[Behcet Sarikaya]

Hi Jong-Hyouk,

On Mon, Nov 30, 2015 at 10:34 AM, Jong-Hyouk Lee  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  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
>
>
>
>
>
> --
>
> --
> 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

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

[Moses, Danny]

Hi,

I support the adoption of this draft.

Regards,
/Danny



-
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[pierrick.seite]

Hi Dirk,

Tanks for the review, we will modify the doc accordingly.

Pierrick

De : dmm [mailto:dmm-boun...@ietf.org] De la part de dirk.von-h...@telekom.de
Envoyé : mardi 1 décembre 2015 15:32
À : maxpass...@gmail.com; dmm@ietf.org
Objet : Re: [DMM] Call for adoption confirmation: 
draft-seite-dmm-rg-multihoming-02

Dear co-chairs,  all,
I join early adopters of the draft and agree that it should become WG document.

To the co-authors I propose to check whether all what I detected as nits/typos  
really are ones:

p.3:

multihomed achitecture =>  multihomed architecture

using GRE as mobile tuneling => using GRE as mobile tunneling

Tunnel-2 (ober DSL) => Tunnel-2 (over DSL)

Fig.1:

Flow0=-4 => Flow-4



P.4:

Care-of-Adresse => Care-of-Address

one MAG/LMA link, i.e. IP-in-IP tunnel, tunnel can be used => one MAG/LMA link, 
i.e. IP-in-IP tunnel, can be used

This document overcome => This document overcomes



p.5:

delegated mobile network prefix. => delegated mobile network prefix (DMNP).



> BTW IMHO also the acronym for MAG Multipath-Binding (MMB) should be 
> introduced anywhere around Fig. 2.



p.6:

ans thus => and thus

may require the RG and the to

   exchange interface metrics

=> may require the RG and the LMA/mobility anchor to

   exchange interface metrics



p.7:

on a flow basis => on a per-flow basis

care-addresses => care-of addresses



p.8:

Here the parameters to be explained/defined are missing – e.g.



If-ATT



This 8-bit field identifies the Access-Technology type …



If-Label



This 8-bit field represents the interface label …

Etc.



p.9:

from the Mobile Node Identifier Option

  Subtypes registry.

=> from the Mobile Node Identifier Option

  Subtypes registry at 
<http://www.iana.org/assignments/mobility-parameters>.

Or perhaps better: include direct reference to draft-ietf-dmm-4283mnids ??





Also I wonder whether not some more security considerations should be added 
like that a new risk emerges in case not all multipath tunnels, tunnel 
technologies, and used access links don’t exhibit similar high security ?



Thanks!


Best Regards
Dirk
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dapeng Liu
Sent: Mittwoch, 25. November 2015 17:22
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>:
  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





--

--
Best Regards,
Dapeng Liu

_

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

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

[Jong-Hyouk Lee]

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 to register more than one PCoA to 
the LMA. It is definitely useful for a multihomed environment. 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  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
>  
>  
> 
> 
> 
> -- 
> 
> --
> 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

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

[Mingui Zhang]

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





--

--
Best Regards,
Dapeng Liu
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Seil Jeon]

Hi All,

 

I support the adoption of this draft as a WG draft as I expressed my support in 
Yokohama meeting.

 

Regards,

Seil Jeon

 

 

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dapeng Liu
Sent: Wednesday, November 25, 2015 4:22 PM
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

 

 




-- 

--
Best Regards,
Dapeng Liu

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm