Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Dave Dolson]

(I haven't paid close attention to the list, so apologies if I'm raising old 
issues.)

1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but 
in this draft, Nomadic IP addresses do not move around; they are replaced. 
"Ephemeral IP Address" might convey the idea more clearly.

2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE" in 
IPV6_REQ_FIXED_IP etc.
 - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC

3. There is a "TDB" in section 3.4. "TBD: Disallow this case?"  This needs to 
be resolved. I suggest the most restrictive flag applies.

4. Must resolve "Application of this solution to IPv4 is TBD." 
 - clearly the socket option is IPV6_something, but...
 - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses 
(https://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option 
IPV6_V6ONLY is false.
 - I think the goal should be that the API *does* apply to IPv4 via 
IPv4-mapped-IPv6 addresses, while acknowledging that the operating system or 
network may not be able to fulfill the request.
- I.e., permit the application to request constraints on IPv4, but also 
expect the application to try for a relaxed address if the initial request 
fails.
 - I see no need to support the API with AF_INET sockets, since AF_INET6 can be 
used with IPV6_ONLY=false and IPv4-mapped-IPv6 addresses.

5. The error codes are not clearly defined. What is the errno for failure of 
setsockopt() and others?

6. I'm unclear on when the on-demand resolution occurs? I don't think it can be 
done at the time of setsockopt(); as I understand it, the addresses are 
resolved later, at connect() or listen(). I'm not sure about this, but it 
should be explained. If the resolution is done at connect() time, is a new 
errno required?

7. Some socket interfaces are not mentioned. What about sendto(), sendmsg(), 
which are not connection-oriented?

8. In section 4.1, support for legacy applications does not really say how to 
support legacy applications.
 - my opinion: the default (lacking new socket options) should be to require 
Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for 
non-connected datagrams.



-Dave




-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Tuesday, December 01, 2015 1:07 PM
To: dmm@ietf.org; Jouni; Dapeng Liu
Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Folks,

This mail starts two week WGLC for the I-D:
https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01

The WGLC ends 12/15/2015.

Provide your reviews and comments to the mailing list. For the better 
tracking of issues and proposed changed use the Issue Tracker to submit 
your issues/proposals.

- Jouni & Dapeng

___
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

[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,   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 
>> 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
>
> _
>
> 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 

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

_

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] The DMM WG has placed draft-gundavelli-dmm-lma-controlled-mag-params in state "Call For Adoption By WG Issued"

[pierrick.seite]

Hi,

I have read draft-gundavelli-dmm-lma-controlled-mag-params and support it.

>From my point of view, this document would allow in-band device management, 
>which can facilitate deployment of PMIP based architecture. Moreover, this 
>option could be used together with notification messages, and possibly flow 
>policy in-band provisioning, for a full and complete device management 
>framework.

Just a question and an editorial suggestion (only suggestion :-): 

In section 4.1, it is stated many times " When this flag on the mobile access 
gateway is set to a value of
  (1), the local mobility anchor SHOULD include this sub-option in
  the Proxy Binding Acknowledge messages that it sends to the mobile
  access gateway; otherwise, it SHOULD NOT include..."

is it SHOULD NOT, or MUST NOT? If it is SHOULD NOT, the MAG must be able to 
ignore unknown options; maybe to be added in section 5.2?

I'd suggest the following rewording:

 OLD TEXT -

The
   option can be included in Proxy Binding Acknowledgement (PBA) message
   only, and there MUST NOT be more than a single instance of this
   mobility option in a mobility message.

--- NEW TEXT ---

Only Proxy Binding Acknowledgement (PBA) message can piggyback this option
  , and there MUST NOT be more than a single instance of this
   mobility option in a mobility message.

--

BR,
Pierrick

> -Message d'origine-
> De : dmm [mailto:dmm-boun...@ietf.org] De la part de IETF Secretariat
> Envoyé : mardi 1 décembre 2015 18:47
> À : dmm-cha...@ietf.org; dmm@ietf.org; draft-gundavelli-dmm-lma-controlled-
> mag-par...@ietf.org
> Objet : [DMM] The DMM WG has placed draft-gundavelli-dmm-lma-controlled-mag-
> params in state "Call For Adoption By WG Issued"
> 
> 
> The DMM WG has placed draft-gundavelli-dmm-lma-controlled-mag-params in
> state Call For Adoption By WG Issued (entered by Jouni Korhonen)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-gundavelli-dmm-lma-controlled-mag-params/
> 
> 
> Comment:
> https://mailarchive.ietf.org/arch/msg/dmm/DoK7mbwZCsIMq64mybOd2pMedn4
> 
> Ends 12/9/2015
> 
> ___
> 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-yan-dmm-hnprenum-03

[jfguan]

Hi, all,
I have been following the DMM WG and the MIP/PMIP related extensions.
I personally think the HNP-renumbering support is a necessary extension of the 
basic RFC5213.
I support the adoption of this draft to be a WG work.
BR, 




+---+
  Jianfeng GUAN
  Institute of Network Technology  
  Beijing University of Posts and Communications   
  Phone: +86-10-18611211658
  Email: jfg...@bupt.edu.cn
  http://int.bupt.edu.cn/
+---+___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm