Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Carlos Jesús Bernardos Cano]

Hi Satoru,

Thanks a lot for the feedback. I think exploring SRv6 as user plane
protocol is a very valid point.

Regarding the white paper Kalyani leads, I'm definitely interested.

Thanks,

Carlos

On Tue, 2018-03-20 at 15:02 +, Satoru Matsushima wrote:
> Thanks authors,
> 
> Actually this draft sounds interesting for me. Some points for that
> are following:
> 
> 1. Utilizing existing control plane for distributed mobility
> functions.
> 2. Those mobility functions could be programmed through some
> interface, i.e: FPC
> 3. I’d see some similarity with MFA ideas.
> 4. SRv6 could be user plane protocol with the control plane protocol.
> 
> One question here is that whether the authors are interested in User
> Plane white paper which Kalyani lead files this solution.
> 
> Cheers,
> --satoru
> 
> > 2018/03/06 22:17、Carlos Jesús Bernardos Cano のメール:
> > 
> > Hi,
> > 
> > We have submitted a revised version of our draft addressing the
> > comments we got in Singapore:
> > 
> > - Added some statements about which model from draft-ietf-dmm-
> > deployment-models our solution follows (addressing a comment
> > received
> > from Sri).
> > - Added some text relating to draft-ietf-dmm-ondemand-mobility
> > (addressing a comment received from Danny).
> > 
> > Additionally, we added some terminology from draft-ietf-dmm-
> > deployment-
> > models and other minor changes.
> > 
> > In Singapore we got quite good support of the document. I'd like to
> > request feedback/reviews from the WG.
> > 
> > Thanks!
> > 
> > Carlos
> > 
> > 差出人: internet-dra...@ietf.org
> > 件名: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt
> > 日付: 2018年3月2日 17:16:29 GMT
> > 宛先: 
> > 返信先: internet-dra...@ietf.org
> > 
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > 
> > 
> >Title   : Proxy Mobile IPv6 extensions for
> > Distributed Mobility Management
> >Authors : Carlos J. Bernardos
> >  Antonio de la Oliva
> >  Fabio Giust
> >  Juan Carlos Zuniga
> >  Alain Mourad
> > Filename: draft-bernardos-dmm-pmipv6-dlif-01.txt
> > Pages   : 32
> > Date: 2018-03-02
> > 
> > Abstract:
> >   Distributed Mobility Management solutions allow for setting up
> >   networks so that traffic is distributed in an optimal way and
> > does
> >   not rely on centralized deployed anchors to provide IP mobility
> >   support.
> > 
> >   There are many different approaches to address Distributed
> > Mobility
> >   Management, as for example extending network-based mobility
> > protocols
> >   (like Proxy Mobile IPv6), or client-based mobility protocols (as
> >   Mobile IPv6), among others.  This document follows the former
> >   approach, and proposes a solution based on Proxy Mobile IPv6 in
> > which
> >   mobility sessions are anchored at the last IP hop router (called
> >   mobility anchor and access router).  The mobility anchor and
> > access
> >   router is an enhanced access router which is also able to operate
> > as
> >   local mobility anchor or mobility access gateway, on a per prefix
> >   basis.  The document focuses on the required extensions to
> >   effectively support simultaneously anchoring several flows at
> >   different distributed gateways.
> > 
> >   This document introduces the concept of distributed logical
> >   interface, which is a software construct that allows to easily
> > hide
> >   the change of anchor from the mobile node.
> > 
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-bernardos-dmm-pmipv6-dlif/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-bernardos-dmm-pmipv6-dlif-01
> > https://datatracker.ietf.org/doc/html/draft-bernardos-dmm-pmipv6-dl
> > if-01
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-bernardos-dmm-pmipv6-dlif-0
> > 1
> > 
> > 
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at
> > tools.ietf.org.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > ___
> > I-D-Announce mailing list
> > i-d-annou...@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > ___
> > 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] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Satoru Matsushima]

Thanks authors,

Actually this draft sounds interesting for me. Some points for that are 
following:

1. Utilizing existing control plane for distributed mobility functions.
2. Those mobility functions could be programmed through some interface, i.e: FPC
3. I’d see some similarity with MFA ideas.
4. SRv6 could be user plane protocol with the control plane protocol.

One question here is that whether the authors are interested in User Plane 
white paper which Kalyani lead files this solution.

Cheers,
--satoru

> 2018/03/06 22:17、Carlos Jesús Bernardos Cano のメール:
> 
> Hi,
> 
> We have submitted a revised version of our draft addressing the
> comments we got in Singapore:
> 
> - Added some statements about which model from draft-ietf-dmm-
> deployment-models our solution follows (addressing a comment received
> from Sri).
> - Added some text relating to draft-ietf-dmm-ondemand-mobility
> (addressing a comment received from Danny).
> 
> Additionally, we added some terminology from draft-ietf-dmm-deployment-
> models and other minor changes.
> 
> In Singapore we got quite good support of the document. I'd like to
> request feedback/reviews from the WG.
> 
> Thanks!
> 
> Carlos
> 
> 差出人: internet-dra...@ietf.org
> 件名: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt
> 日付: 2018年3月2日 17:16:29 GMT
> 宛先: 
> 返信先: internet-dra...@ietf.org
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>Title   : Proxy Mobile IPv6 extensions for Distributed 
> Mobility Management
>Authors : Carlos J. Bernardos
>  Antonio de la Oliva
>  Fabio Giust
>  Juan Carlos Zuniga
>  Alain Mourad
>   Filename: draft-bernardos-dmm-pmipv6-dlif-01.txt
>   Pages   : 32
>   Date: 2018-03-02
> 
> Abstract:
>   Distributed Mobility Management solutions allow for setting up
>   networks so that traffic is distributed in an optimal way and does
>   not rely on centralized deployed anchors to provide IP mobility
>   support.
> 
>   There are many different approaches to address Distributed Mobility
>   Management, as for example extending network-based mobility protocols
>   (like Proxy Mobile IPv6), or client-based mobility protocols (as
>   Mobile IPv6), among others.  This document follows the former
>   approach, and proposes a solution based on Proxy Mobile IPv6 in which
>   mobility sessions are anchored at the last IP hop router (called
>   mobility anchor and access router).  The mobility anchor and access
>   router is an enhanced access router which is also able to operate as
>   local mobility anchor or mobility access gateway, on a per prefix
>   basis.  The document focuses on the required extensions to
>   effectively support simultaneously anchoring several flows at
>   different distributed gateways.
> 
>   This document introduces the concept of distributed logical
>   interface, which is a software construct that allows to easily hide
>   the change of anchor from the mobile node.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bernardos-dmm-pmipv6-dlif/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-bernardos-dmm-pmipv6-dlif-01
> https://datatracker.ietf.org/doc/html/draft-bernardos-dmm-pmipv6-dlif-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-bernardos-dmm-pmipv6-dlif-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> ___
> 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] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Carlos Jesús Bernardos Cano]

Dear Daniel,

Thanks a lot for your review. Please see some comments inline below.

On Thu, 2018-03-15 at 21:37 +, Daniel Corujo wrote:
> Dear Carlos, all,
> 
> Just wanted to point out, and congratulate all authors, on a document
> well done: the partial schemes provide a clear mechanism for
> maintaining connectivity while distributing control and data plane
> aspects. Even though it’s a -01, it already shows good form by
> pointing out the necessary extensions to RFC 5213’s messages (I would
> recommend this part to have it’s own section on the document), 

[Carlos] OK, we'll evaluate this change of structure for -02.

> complemented with an interesting set of annexes showcasing
> implementation details, past experiences and even an on-look on
> future adaptability with edge-based mobility (we can even potentially
> bring some ideas to this discussion ourselves for consideration).
> 
> Some quick typos to be fixed:
> 
> * pg4, 3rd paragraph, line 2, “where the dataplane is only
> distributted”
> * pg5, last paragraph, line 1, “participate”
> * pg8, 2nd paragraph, 6th line from the end, “the CMD sends a PBA”
> * pg10, 1st paragraph, line 3 “reflects”
> * pg11, 1st paragraph, line 4 “possession”
> * pg15, 1st paragraph, 6th line from the end, “interface”
> * pg15, 3rd paragraph, 5th line from the end, “considered”

[Carlos] Thanks. We'll fix them all for -02.

Thanks!

Carlos

> 
> Best regards,
> 
> Daniel Corujo
> Instituto de Telecomunicações - Pólo de Aveiro
> http://www.it.pt
> 
> 
> 
> Watch our VIDEO: https://youtu.be/lI8DnmBnEtU
> Internet Technology Letters Journal is accepting publications: http:/
> /onlinelibrary.wiley.com/journal/10.1002/(ISSN)2476-1508
> 
> > On 12 Mar 2018, at 17:02, Carlos Jesús Bernardos Cano <cjbc@it.uc3m
> > .es> wrote:
> > 
> > Hi Akbar,
> > 
> > Thanks for the review. Comments inline below.
> > 
> > On Mon, 2018-03-12 at 16:41 +, Rahman, Akbar wrote:
> > > Hi Carlos,
> > > 
> > > 
> > > Thanks for the updates.  I think the document is in good shape
> > > and
> > > should be adopted.
> > > 
> > > I did have some small suggestions though for the next revision:
> > > 
> > > 1) Abstract - Suggest to remove the last paragraph on
> > > "distributed
> > > logical interface" as it appears to be a detail and is not very
> > > clear
> > > anyways at this point in the document what it implies.  If you
> > > want
> > > to keep the paragraph it should be further clarified as it is not
> > > clear what "a software construct" implies?
> > 
> > [Carlos] OK, well clarify this further.
> > 
> > > 2) Figures 2, 3, & 4  - Suggest to replace use of the "?" in the
> > > ASCII figure construction with another symbol (such as used in
> > > Figure
> > > 1).
> > 
> > [Carlos] This will be fixed in -02.
> > 
> > > 3) Section 3.6 - Need to better clarify in the 1st paragraph text
> > > in
> > > which node the "software construct" of the DLIF is located.  And
> > > also, not clear currently why a node internal software construct
> > > needs to be discussed in a protocol document.  So probably just
> > > my
> > > lack of understanding but points to the section requiring further
> > > clarity.
> > 
> > [Carlos] Will clarify in -02.
> > 
> > Thanks!
> > 
> > Carlos
> > 
> > > 
> > > Best Regards,
> > > 
> > > Akbar
> > > 
> > > 
> > > -Original Message-
> > > From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
> > > Sent: Wednesday, March 7, 2018 10:21 AM
> > > To: c...@it.uc3m.es; dmm@ietf.org
> > > Subject: Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-
> > > dlif-
> > > 01.txt]
> > > 
> > > Thanks Carlos.
> > > 
> > > Folks - Please review the document and post your feedback.
> > > 
> > > https://tools.ietf.org/id/draft-bernardos-dmm-pmipv6-dlif-01.txt
> > > 
> > > 
> > > 
> > > At IETF100, we polled the WG feedback for adopting this document
> > > and
> > > there was consensus for adopting this document. However, we chose
> > > not
> > > to adopt the document as there were no recent discussions in the
> > > mailer on this document. We therefore request the WG for feedback
> > > in
> > > the mailer. We plan to issue an adoption call post IETF101, but
> >

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Daniel Corujo]

Dear Carlos, all,

Just wanted to point out, and congratulate all authors, on a document well 
done: the partial schemes provide a clear mechanism for maintaining 
connectivity while distributing control and data plane aspects. Even though 
it’s a -01, it already shows good form by pointing out the necessary extensions 
to RFC 5213’s messages (I would recommend this part to have it’s own section on 
the document), complemented with an interesting set of annexes showcasing 
implementation details, past experiences and even an on-look on future 
adaptability with edge-based mobility (we can even potentially bring some ideas 
to this discussion ourselves for consideration).

Some quick typos to be fixed:

* pg4, 3rd paragraph, line 2, “where the dataplane is only distributted”
* pg5, last paragraph, line 1, “participate”
* pg8, 2nd paragraph, 6th line from the end, “the CMD sends a PBA”
* pg10, 1st paragraph, line 3 “reflects”
* pg11, 1st paragraph, line 4 “possession”
* pg15, 1st paragraph, 6th line from the end, “interface”
* pg15, 3rd paragraph, 5th line from the end, “considered”

Best regards,

Daniel Corujo
Instituto de Telecomunicações - Pólo de Aveiro
http://www.it.pt



Watch our VIDEO: https://youtu.be/lI8DnmBnEtU
Internet Technology Letters Journal is accepting publications: 
http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)2476-1508

> On 12 Mar 2018, at 17:02, Carlos Jesús Bernardos Cano <c...@it.uc3m.es> wrote:
> 
> Hi Akbar,
> 
> Thanks for the review. Comments inline below.
> 
> On Mon, 2018-03-12 at 16:41 +, Rahman, Akbar wrote:
>> Hi Carlos,
>> 
>> 
>> Thanks for the updates.  I think the document is in good shape and
>> should be adopted.
>> 
>> I did have some small suggestions though for the next revision:
>> 
>> 1) Abstract - Suggest to remove the last paragraph on "distributed
>> logical interface" as it appears to be a detail and is not very clear
>> anyways at this point in the document what it implies.  If you want
>> to keep the paragraph it should be further clarified as it is not
>> clear what "a software construct" implies?
> 
> [Carlos] OK, well clarify this further.
> 
>> 
>> 2) Figures 2, 3, & 4  - Suggest to replace use of the "?" in the
>> ASCII figure construction with another symbol (such as used in Figure
>> 1).
> 
> [Carlos] This will be fixed in -02.
> 
>> 
>> 3) Section 3.6 - Need to better clarify in the 1st paragraph text in
>> which node the "software construct" of the DLIF is located.  And
>> also, not clear currently why a node internal software construct
>> needs to be discussed in a protocol document.  So probably just my
>> lack of understanding but points to the section requiring further
>> clarity.
> 
> [Carlos] Will clarify in -02.
> 
> Thanks!
> 
> Carlos
> 
>> 
>> 
>> Best Regards,
>> 
>> Akbar
>> 
>> 
>> -Original Message-
>> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
>> Sent: Wednesday, March 7, 2018 10:21 AM
>> To: c...@it.uc3m.es; dmm@ietf.org
>> Subject: Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-
>> 01.txt]
>> 
>> Thanks Carlos.
>> 
>> Folks - Please review the document and post your feedback.
>> 
>> https://tools.ietf.org/id/draft-bernardos-dmm-pmipv6-dlif-01.txt
>> 
>> 
>> 
>> At IETF100, we polled the WG feedback for adopting this document and
>> there was consensus for adopting this document. However, we chose not
>> to adopt the document as there were no recent discussions in the
>> mailer on this document. We therefore request the WG for feedback in
>> the mailer. We plan to issue an adoption call post IETF101, but we
>> need some feedback and substantial comments.
>> 
>> 
>> Dapeng & Sri
>> 
>> 
>> 
>> 
>> On 3/6/18, 2:17 PM, "dmm on behalf of Carlos Jesús Bernardos Cano"
>> <dmm-boun...@ietf.org on behalf of c...@it.uc3m.es> wrote:
>> 
>>> Hi,
>>> 
>>> We have submitted a revised version of our draft addressing the
>>> comments we got in Singapore:
>>> 
>>> - Added some statements about which model from draft-ietf-dmm-
>>> deployment-models our solution follows (addressing a comment
>>> received
>>> from Sri).
>>> - Added some text relating to draft-ietf-dmm-ondemand-mobility
>>> (addressing a comment received from Danny).
>>> 
>>> Additionally, we added some terminology from draft-ietf-dmm-
>>> deployment-
>>> models and other minor changes.
>>> 
&g

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Carlos Jesús Bernardos Cano]

Hi Akbar,

Thanks for the review. Comments inline below.

On Mon, 2018-03-12 at 16:41 +, Rahman, Akbar wrote:
> Hi Carlos,
> 
> 
> Thanks for the updates.  I think the document is in good shape and
> should be adopted.
> 
> I did have some small suggestions though for the next revision:
> 
> 1) Abstract - Suggest to remove the last paragraph on "distributed
> logical interface" as it appears to be a detail and is not very clear
> anyways at this point in the document what it implies.  If you want
> to keep the paragraph it should be further clarified as it is not
> clear what "a software construct" implies?

[Carlos] OK, well clarify this further.

> 
> 2) Figures 2, 3, & 4  - Suggest to replace use of the "?" in the
> ASCII figure construction with another symbol (such as used in Figure
> 1).

[Carlos] This will be fixed in -02.

> 
> 3) Section 3.6 - Need to better clarify in the 1st paragraph text in
> which node the "software construct" of the DLIF is located.  And
> also, not clear currently why a node internal software construct
> needs to be discussed in a protocol document.  So probably just my
> lack of understanding but points to the section requiring further
> clarity.

[Carlos] Will clarify in -02.

Thanks!

Carlos

> 
> 
> Best Regards,
> 
> Akbar
> 
> 
> -Original Message-
> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
> Sent: Wednesday, March 7, 2018 10:21 AM
> To: c...@it.uc3m.es; dmm@ietf.org
> Subject: Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-
> 01.txt]
> 
> Thanks Carlos.
> 
> Folks - Please review the document and post your feedback.
> 
> https://tools.ietf.org/id/draft-bernardos-dmm-pmipv6-dlif-01.txt
> 
> 
> 
> At IETF100, we polled the WG feedback for adopting this document and
> there was consensus for adopting this document. However, we chose not
> to adopt the document as there were no recent discussions in the
> mailer on this document. We therefore request the WG for feedback in
> the mailer. We plan to issue an adoption call post IETF101, but we
> need some feedback and substantial comments.
> 
> 
> Dapeng & Sri
> 
> 
> 
> 
> On 3/6/18, 2:17 PM, "dmm on behalf of Carlos Jesús Bernardos Cano"
> <dmm-boun...@ietf.org on behalf of c...@it.uc3m.es> wrote:
> 
> > Hi,
> > 
> > We have submitted a revised version of our draft addressing the
> > comments we got in Singapore:
> > 
> > - Added some statements about which model from draft-ietf-dmm-
> > deployment-models our solution follows (addressing a comment
> > received
> > from Sri).
> > - Added some text relating to draft-ietf-dmm-ondemand-mobility
> > (addressing a comment received from Danny).
> > 
> > Additionally, we added some terminology from draft-ietf-dmm-
> > deployment-
> > models and other minor changes.
> > 
> > In Singapore we got quite good support of the document. I'd like to
> > request feedback/reviews from the WG.
> > 
> > Thanks!
> > 
> > Carlos
> 
> [Banner]
> This e-mail is intended only for the use of the individual or entity
> to which it is addressed, and may contain information that is
> privileged, confidential and/or otherwise protected from disclosure
> to anyone other than its intended recipient. Unintended transmission
> shall not constitute waiver of any privilege or confidentiality
> obligation. If you received this communication in error, please do
> not review, copy or distribute it, notify me immediately by email,
> and delete the original message and any attachments. Unless expressly
> stated in this e-mail, nothing in this message or any attachment
> should be construed as a digital or electronic signature.
> 

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

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Rahman, Akbar]

Hi Carlos,


Thanks for the updates.  I think the document is in good shape and should be 
adopted.  

I did have some small suggestions though for the next revision:

1) Abstract - Suggest to remove the last paragraph on "distributed logical 
interface" as it appears to be a detail and is not very clear anyways at this 
point in the document what it implies.  If you want to keep the paragraph it 
should be further clarified as it is not clear what "a software construct" 
implies?

2) Figures 2, 3, & 4  - Suggest to replace use of the "?" in the ASCII figure 
construction with another symbol (such as used in Figure 1).

3) Section 3.6 - Need to better clarify in the 1st paragraph text in which node 
the "software construct" of the DLIF is located.  And also, not clear currently 
why a node internal software construct needs to be discussed in a protocol 
document.  So probably just my lack of understanding but points to the section 
requiring further clarity.


Best Regards,

Akbar


-Original Message-
From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] 
Sent: Wednesday, March 7, 2018 10:21 AM
To: c...@it.uc3m.es; dmm@ietf.org
Subject: Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

Thanks Carlos.

Folks - Please review the document and post your feedback.

https://tools.ietf.org/id/draft-bernardos-dmm-pmipv6-dlif-01.txt



At IETF100, we polled the WG feedback for adopting this document and there was 
consensus for adopting this document. However, we chose not to adopt the 
document as there were no recent discussions in the mailer on this document. We 
therefore request the WG for feedback in the mailer. We plan to issue an 
adoption call post IETF101, but we need some feedback and substantial comments.


Dapeng & Sri




On 3/6/18, 2:17 PM, "dmm on behalf of Carlos Jesús Bernardos Cano"
<dmm-boun...@ietf.org on behalf of c...@it.uc3m.es> wrote:

>Hi,
>
>We have submitted a revised version of our draft addressing the 
>comments we got in Singapore:
>
>- Added some statements about which model from draft-ietf-dmm- 
>deployment-models our solution follows (addressing a comment received 
>from Sri).
>- Added some text relating to draft-ietf-dmm-ondemand-mobility 
>(addressing a comment received from Danny).
>
>Additionally, we added some terminology from draft-ietf-dmm-deployment- 
>models and other minor changes.
>
>In Singapore we got quite good support of the document. I'd like to 
>request feedback/reviews from the WG.
>
>Thanks!
>
>Carlos

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

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Carlos Jesús Bernardos Cano]

Hi Alex,

On Mon, 2018-03-12 at 11:06 +0100, Alexandre Petrescu wrote:
> 
> Le 12/03/2018 à 00:58, Carlos Jesús Bernardos Cano a écrit :
> [...]
> > > However, I have difficulty to grasp the term 'distributed
> > > logical 
> > > interface'.  It sounds as if the same interface name, e.g.
> > > 'mn1mar1', was present on both MAAR1 and MAAR2.  In reality, only
> > > the triplet 'MAC address', 'link-local address' and the 'global
> > > prefix' are same on MAAR1 and MAAR2 interfaces.  These latter are
> > > called differently, though: 'mn1mar1' and 'mn1mar2'.
> > 
> > [Carlos] The triplet are the same, but we also use the same name of
> > the interface in the diagrams (in the system, the name of the
> > interface does not matter, could be called in anyway, the important
> > point is the triplet you mentioned). 'mn1mar1' refers to the
> > logical
> > interface (i.e., triplet) exposed by MAAR1 to MN1 for the prefix
> > anchored by MAAR1 to MN1. 'mn1mar2' refers to the logical interface
> > (i.e., triplet) exposed by MAAR2 to MN1 for the prefix anchored by
> > MAAR2 to MN1. If the MN is using addresses from both the prefixes
> > anchored at MAAR1 and MAAR2, while the MN is attached to MAAR2,
> > 'mn1mar1' and 'mn1mar2' logical interfaces will be configured at
> > MAAR2.
> > 
> > > 
> > > Maybe the DLIF could be named 'mn1marx'.  But I dont think you 
> > > ifconfig 'mn1marx' whereas I am almost sure you do ifconfig
> > > mn1mar1
> > > and ifconfig mn1mar2.
> > 
> > [Carlos] Please check the previous and let me know if you agree.
> 
> Yes, I checked and I agree as long as DLIF is a concept, not one
> interface.

[Carlos] OK.

> 
> [...]
> 
> > > > Prefix Length
> > > > 
> > > > 8-bit unsigned integer indicating the prefix length of the
> > > > IPv6 
> > > > prefix contained in the option.
> > > 
> > > This 'Prefix Length' variable appears several times in the
> > > message 
> > > formats, yet all the examples of prefixes shown in the draft are
> > > of length precisely 64.  I do not understand why.
> > > 
> > > In order to illustrate that is true variable, can we have one of
> > > the examples that says '63' instead of '64'?
> > > 
> > > Otherwise, it may sound little logical to keep that as variable.
> > > Just use /64s everywhere and dont transmit Prefix Length in no
> > > message.
> > 
> > [Carlos] We include the Prefix Length option as in the HNP option
> > of 
> > RFC 5213 and the MNP option of RFC3963. But we foresee that this
> > value will be equal to 64 in most cases, as the prefix length in
> > IPv6
> > is typically 64-bits. Do you think we should also have examples
> > with
> > other prefix lengths?
> 
> I think other-than-64 prefix lengths should be feasible.
> 
> For RFC3963: the prefix length is variable in order to accommodate 
> mobile routers.
> 
> For RFC5213: why is there a variable prefix  length if this value is 
> foreseen to be equal to 64 in most cases?  What is the particular
> case 
> where that prefix length is not 64?

[Carlos] I think it was put there to be flexible and allow for other
cases in the future. We can document in our draft that other prefix
lengths are possible.

Thanks,

Carlos

> 
> Alex

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

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Alexandre Petrescu]

Le 12/03/2018 à 00:58, Carlos Jesús Bernardos Cano a écrit :
[...]
However, I have difficulty to grasp the term 'distributed logical 
interface'.  It sounds as if the same interface name, e.g.

'mn1mar1', was present on both MAAR1 and MAAR2.  In reality, only
the triplet 'MAC address', 'link-local address' and the 'global
prefix' are same on MAAR1 and MAAR2 interfaces.  These latter are
called differently, though: 'mn1mar1' and 'mn1mar2'.


[Carlos] The triplet are the same, but we also use the same name of
the interface in the diagrams (in the system, the name of the
interface does not matter, could be called in anyway, the important
point is the triplet you mentioned). 'mn1mar1' refers to the logical
interface (i.e., triplet) exposed by MAAR1 to MN1 for the prefix
anchored by MAAR1 to MN1. 'mn1mar2' refers to the logical interface
(i.e., triplet) exposed by MAAR2 to MN1 for the prefix anchored by
MAAR2 to MN1. If the MN is using addresses from both the prefixes
anchored at MAAR1 and MAAR2, while the MN is attached to MAAR2,
'mn1mar1' and 'mn1mar2' logical interfaces will be configured at
MAAR2.



Maybe the DLIF could be named 'mn1marx'.  But I dont think you 
ifconfig 'mn1marx' whereas I am almost sure you do ifconfig mn1mar1

and ifconfig mn1mar2.


[Carlos] Please check the previous and let me know if you agree.


Yes, I checked and I agree as long as DLIF is a concept, not one interface.

[...]


Prefix Length

8-bit unsigned integer indicating the prefix length of the IPv6 
prefix contained in the option.


This 'Prefix Length' variable appears several times in the message 
formats, yet all the examples of prefixes shown in the draft are

of length precisely 64.  I do not understand why.

In order to illustrate that is true variable, can we have one of
the examples that says '63' instead of '64'?

Otherwise, it may sound little logical to keep that as variable.
Just use /64s everywhere and dont transmit Prefix Length in no
message.


[Carlos] We include the Prefix Length option as in the HNP option of 
RFC 5213 and the MNP option of RFC3963. But we foresee that this

value will be equal to 64 in most cases, as the prefix length in IPv6
is typically 64-bits. Do you think we should also have examples with
other prefix lengths?


I think other-than-64 prefix lengths should be feasible.

For RFC3963: the prefix length is variable in order to accommodate 
mobile routers.


For RFC5213: why is there a variable prefix  length if this value is 
foreseen to be equal to 64 in most cases?  What is the particular case 
where that prefix length is not 64?


Alex

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

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Carlos Jesús Bernardos Cano]

Hi Alex,

Thanks a lot for your review. Comments inline below.

On Fri, 2018-03-09 at 18:29 +0100, Alexandre Petrescu wrote:
> 
> Le 06/03/2018 à 23:17, Carlos Jesús Bernardos Cano a écrit :
> > Hi,
> > 
> > We have submitted a revised version of our draft addressing the 
> > comments we got in Singapore:
> > 
> > - Added some statements about which model from draft-ietf-dmm- 
> > deployment-models our solution follows (addressing a comment
> > received
> > from Sri). - Added some text relating to 
> > draft-ietf-dmm-ondemand-mobility (addressing a comment received
> > from 
> > Danny).
> > 
> > Additionally, we added some terminology from 
> > draft-ietf-dmm-deployment- models and other minor changes.
> > 
> > In Singapore we got quite good support of the document. I'd like
> > to 
> > request feedback/reviews from the WG.
> 
> Carlos, here are some comments.
> 
> > Current IP mobility solutions, standardized with the names of
> > Mobile
> >  IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the
> > two
> >  most relevant examples, offer mobility support at the cost of 
> > handling operations at a cardinal point, the mobility anchor,
> 
> By mobility anchor I think you mean HA or LMA.

[Carlos] Yes. We can make this more clear in the next revision.

> 
> > (i.e., mobility is offered on a per-node basis, not being possible
> > to
> > define finer granularity policies, as for example per-application).
> 
> Just some thought: it's 'per-node(s)' basis vs 'per-application'
> basis,
> because there is also 'per-nodes' vs 'per-node', i.e per-MH vs per-
> MR.

[Carlos] The document assumes node/host mobility (not network
mobility).

> 
> > o  The LMA is relieved from the data forwarding role, only the 
> > Binding Cache and its management operations are maintained.  Hence 
> > the LMA is renamed into Central Mobility Database (CMD), which is 
> > therefore a Home-CPA.  Also, the CMD is able to send and parse
> > both 
> > PBU and PBA messages.
> 
> It's renamed, but it still is a single-point-of-failure?

[Carlos] Not from the point of view of data forwarding. It is still a
centralized point for the control plane, but some mechanisms could be
to distribute the operation of the LMD, so it is not a single-point of
failure.

> 
> > o  The MAG is enriched with the LMA functionalities, hence the
> > name 
> > Mobility Anchor and Access Router (MAAR).  It maintains a local 
> > Binding Cache for the MNs that are attached to it and it is able
> > to 
> > send and parse PBU and PBA messages.
> 
> Have you tried to disconnect CMD and the system still worked, just
> with
> MAARs?

[Carlos] We have not tried, but the system would only work if mobiles
do not move and only during the lifetime of the bindings.

> 
> [...]
> 
> > temporal
> 
>temporary
> 
> > definitely
> 
>definitively(?)
> 
> [...]
> 
> Overall, I have the feeling there are still some tunnels (MAAR1 to
> MAAR2), so still the paths are not shortest possible.

[Carlos] Yes, there are tunnels to the anchoring MAAR for the time an
address anchored there is in use.

> 
> > HSS
> 
>What it means?

[Carlos] Home Subscriber Server. It is a 3GPP entity. We have received
this comment from other reviewers, so we will expand the acronym and
explain it in the next revision. In any case, we use it as an example.
 
> 
> > In order to maintain the prefix anchored at MAAR1 reachable, a
> > tunnel between MAAR1 and MAAR2 is established and the routing is
> > modified accordingly.
> 
> When you say 'routing is modified accordingly' does it mean that
> tunnel-related entries in the routing tables of MAAR1 and MAAR2 are
> updated?  Or does it mean that entries _not_ related to the tunnels
> are
> updated?

[Carlos] Just the routing tables of MAAR1 and MAAR2.

> 
> > 3.6.  The Distributed Logical Interface (DLIF) concept
> 
> I like the idea of the network presenting itself as a same entity to
> the
> MN.  Whether the MN is attached to MAAR1 or to MAAR2, the MN sees the
> same MAC address and IP address of the default router.
> 
> However, I have difficulty to grasp the term 'distributed logical
> interface'.  It sounds as if the same interface name, e.g. 'mn1mar1',
> was present on both MAAR1 and MAAR2.  In reality, only the triplet
> 'MAC
> address', 'link-local address' and the 'global prefix' are same on
> MAAR1
> and MAAR2 interfaces.  These latter are called differently, though:
> 'mn1mar1' and 'mn1mar2'.

[Carlos] The triplet are the same, but we also use the same name of the
interface in the diagrams (in the system, the name of the interface
does not matter, could be called in anyway, the important point is the
triplet you mentioned). 'mn1mar1' refers to the logical interface
(i.e., triplet) exposed by MAAR1 to MN1 for the prefix anchored by
MAAR1 to MN1. 'mn1mar2' refers to the logical interface (i.e., triplet)
exposed by MAAR2 to MN1 for the prefix anchored by MAAR2 to MN1. If the
MN is using addresses from both the prefixes anchored at MAAR1 and

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Alexandre Petrescu]

Le 06/03/2018 à 23:17, Carlos Jesús Bernardos Cano a écrit :

Hi,

We have submitted a revised version of our draft addressing the 
comments we got in Singapore:


- Added some statements about which model from draft-ietf-dmm- 
deployment-models our solution follows (addressing a comment received
from Sri). - Added some text relating to 
draft-ietf-dmm-ondemand-mobility (addressing a comment received from 
Danny).


Additionally, we added some terminology from 
draft-ietf-dmm-deployment- models and other minor changes.


In Singapore we got quite good support of the document. I'd like to 
request feedback/reviews from the WG.


Carlos, here are some comments.


Current IP mobility solutions, standardized with the names of Mobile
 IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two
 most relevant examples, offer mobility support at the cost of 
handling operations at a cardinal point, the mobility anchor,


By mobility anchor I think you mean HA or LMA.


(i.e., mobility is offered on a per-node basis, not being possible to
define finer granularity policies, as for example per-application).


Just some thought: it's 'per-node(s)' basis vs 'per-application' basis,
because there is also 'per-nodes' vs 'per-node', i.e per-MH vs per-MR.

o  The LMA is relieved from the data forwarding role, only the 
Binding Cache and its management operations are maintained.  Hence 
the LMA is renamed into Central Mobility Database (CMD), which is 
therefore a Home-CPA.  Also, the CMD is able to send and parse both 
PBU and PBA messages.


It's renamed, but it still is a single-point-of-failure?

o  The MAG is enriched with the LMA functionalities, hence the name 
Mobility Anchor and Access Router (MAAR).  It maintains a local 
Binding Cache for the MNs that are attached to it and it is able to 
send and parse PBU and PBA messages.


Have you tried to disconnect CMD and the system still worked, just with
MAARs?

[...]


temporal

  temporary


definitely

  definitively(?)

[...]

Overall, I have the feeling there are still some tunnels (MAAR1 to
MAAR2), so still the paths are not shortest possible.


HSS

  What it means?


In order to maintain the prefix anchored at MAAR1 reachable, a
tunnel between MAAR1 and MAAR2 is established and the routing is
modified accordingly.


When you say 'routing is modified accordingly' does it mean that
tunnel-related entries in the routing tables of MAAR1 and MAAR2 are
updated?  Or does it mean that entries _not_ related to the tunnels are
updated?


3.6.  The Distributed Logical Interface (DLIF) concept


I like the idea of the network presenting itself as a same entity to the
MN.  Whether the MN is attached to MAAR1 or to MAAR2, the MN sees the
same MAC address and IP address of the default router.

However, I have difficulty to grasp the term 'distributed logical
interface'.  It sounds as if the same interface name, e.g. 'mn1mar1',
was present on both MAAR1 and MAAR2.  In reality, only the triplet 'MAC
address', 'link-local address' and the 'global prefix' are same on MAAR1
and MAAR2 interfaces.  These latter are called differently, though:
'mn1mar1' and 'mn1mar2'.

Maybe the DLIF could be named 'mn1marx'.  But I dont think you ifconfig
'mn1marx' whereas I am almost sure you do ifconfig mn1mar1 and ifconfig
mn1mar2.


Each serving MAAR exposes itself towards a given MN as multiple
routers, one per active anchoring MAAR associated to the MN.


'serving MAAR' vs 'active anchoring MAAR' ok, but sometimes you have 
just 'anchoring MAAR'.


One wonders whether the 'anchoring MAAR' is an S-MAAR or P-MAAR.

Overall, you have:
- Serving MAAR
- Previous MAAR
- [non-active] anchoring MAAR
- active anchoring MAAR

Not sure which is which since the latter two are not defined in Terminology.


This is similar to the LIPA scenario currently being
   consider by 3GPP. 


LIPA... appears just once, I do not know it.


These routes are advertised through the distributed
   logical interface representing the MAAR providing access to the local
   network (MAAR1 in this example).


By 'distributed logical interface' do you mean mn1marx or mn1mar1, 
mn1mar2...?  Do you mean there is an radvd on each of mn1mar1, mn1mar2 
advertising that prefix?  Do you mean you modify the radvd.conf file 
each time the MN moves, and restart the radvd daemon ?


Do you mean there is only one radvd that runs on the DLIF called 'mn1marx'?


 Prefix Length

  8-bit unsigned integer indicating the prefix length of the IPv6
  prefix contained in the option.


This 'Prefix Length' variable appears several times in the message 
formats, yet all the examples of prefixes shown in the draft are of 
length precisely 64.  I do not understand why.


In order to illustrate that is true variable, can we have one of the 
examples that says '63' instead of '64'?


Otherwise, it may sound little logical to keep that as variable.  Just 
use /64s everywhere and dont transmit Prefix Length in no message.


Alex

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Carlos Jesús Bernardos Cano]

Hi Xinpeng,

thanks a lot for the review. Please see inline below.

On Thu, 2018-03-08 at 03:59 +, Weixinpeng (Jackie) wrote:
> Hi Carlos,
> Thanks for the improvement of the document, I think the document is
> well structured and provide a good solution for distributed mobility
> management.
> The following are some of my comments:
> 1. Page7. "...MAAR1 definitely stores the temporal BCE previously
> allocated and unicasts a Router Advertisement (RA) to the MN
> including the prefix reserved before..."，The prefix allocation
>  to MN is restricted to RA mechanism, but there would be alternative
> methods, for instance in 4G, network can send prefix information
> through 3GPP-specific signaling. So i think it's better to 
> consider whether restricted to RA or not.

OK, we'll look into it in -02.

> 2. As MN moves across MAARs there could be many P-MAAR exist, It's
> better to give a brief description of how to cope with it.

OK. We'll add some text about that.

> 3. The solution doesn't differentiate different session continuity
> requirement, so how the solution coexist with the on-demand solution,
> or you want to promote a solution independent from the on-demand one?

The solution is compatible with on-demand, meaning that it can be used
only for those sessions that demand session continuity. We leave the
details on how to do this out-of-the-scope, but we can add some text.

> 4. Page13. There is no reference for "HSS", I suggest add a reference
> for it, or just remove it.

We use it as one example of control plane anchor. We will expand the
acronym in -02.

> 5. Page15. " ...sent over those logical interfaces playing the role
> of anchoring MAARs (different from the serving one) include a zero
> prefix lifetime... " Two lifetime related fields is included in RA
> message, Vaild Lifetime and Preferred Lifetime, I think the lifetime
> you mentioned is Preferred Lifetime. Maybe how to set the value of
> Valid Lifetime should be described.

Thanks, we will clarify in -02. We actually refer to the Valid
Lifetime, so the address is deprecated.

Thanks!

Carlos

> 
> Regards,
> -Xinpeng (Jackie)
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Carlos Jesús
> Bernardos Cano
> Sent: Wednesday, March 07, 2018 6:18 AM
> To: dmm@ietf.org
> Subject: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-
> 01.txt]
> 
> Hi,
> 
> We have submitted a revised version of our draft addressing the
> comments we got in Singapore:
> 
> - Added some statements about which model from draft-ietf-dmm-
> deployment-models our solution follows (addressing a comment received
> from Sri).
> - Added some text relating to draft-ietf-dmm-ondemand-mobility
> (addressing a comment received from Danny).
> 
> Additionally, we added some terminology from draft-ietf-dmm-
> deployment- models and other minor changes.
> 
> In Singapore we got quite good support of the document. I'd like to
> request feedback/reviews from the WG.
> 
> Thanks!
> 
> Carlos

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

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Carlos Jesús Bernardos Cano]

Hi Dirk,

Thanks a lot for the feedback. Please see inline below.

On Wed, 2018-03-07 at 12:54 +, dirk.von-h...@telekom.de wrote:
> Dear Carlos and co-authors, all,
> thanks for the improvements!
> I think the draft is quite well written and provides a good approach
> to real distribution of functionalities in DMM. What might be made
> clearer is the difference between partially and fully DMM you have
> introduced.
> See also as mentioned below in the list of detected nits:
> 
> Figs. 2 - 4: exhibiting ? instead of ' on Data packet Flow part ...

OK, fixed in -02.

> 
> p. 5: Home-CPA [I assume it means the same as H-CPA defined in ch. 2:
> I suggest to use one acronym only].

Agre, fixed.

> PMIPv6 DMM extenstions => PMIPv6 DMM extensions
> the entities that participates => the entities that participate
> p. 8: Also, the CMD send a PBA => Also, the CMD sends a PBA
> p.10: This procedure reflect => This procedure reflects
> address OS taken  => address is taken [??]

Thanks, all fixed.

> p.12: Partial DMM architecture - I wonder whether this should be
> introduced as new term in ch. 2 e.g.

Thanks, we have rewritten it a bit.

> 
> Partial DMM architecture. DMM architecture based on PMIP where MAGs
> and LMAs are distributed in Data Plane but Control Plane of LMA is
> centralized in CMD [if I understood correctly]
> Further more when fully DMM solutions are mentioned (later) - is that
> the (only) difference? Should one describe that in more detail?

We have rewritten the text to avoid the use of "Partial DMM".

>  
> of the mobile selecting   => of the mobile node selecting

Fixed.

> p.13: HSS [why not using 3GPP-independent term CMD here?] - same on 

When used as an example, I prefer to keep it. 

> p.15 ...
> p.15: mn1dgw2/mn1dgw1 [not used in Fig.6, shouldn't it say
> mn1mar2/mn1mar1 instead?]

Fixed.

> the serving MAAR (MAAR1) => the serving MAAR (MAAR2) [right? Since
> MAAR2 is the actual S-MAAR of MN1 in Fig. 6]

Right, fixed.

> consider by 3GPP => considered by 3GPP
> p.20: This field MUST be set to 34.=> This field MUST be set to
> 33.[according to format above unless an 8-bit Reserved field is
> included as in other formats ...]
> p.23: on the serving distributed gateway => on the S-MAAR [another
> left-over by previous version ...] 
> p.25: we describe =>  we describe
> p.27: ot the operators => of the operators

All fixed.

> both solution apply the same signalling scheme => meaning full and
> partial or rather operation of the solution in both (of mentioned
> multiple) domains here?

Meaning the solution in both domains. We have clarified it.

> p.28: then stop the BCE => then stops the BCE
> p.30: mobile edge computing (MEC) =>  multi-access edge computing
> (MEC) [as defined by ETSI which is explicitly mentioned!]
> edge ir the => edge or the [edge near the?]

All fixed.

Thanks a lot!

Carlos

> 
> Thanks and best regards
> Dirk
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Carlos Jesús
> Bernardos Cano
> Sent: Dienstag, 6. März 2018 23:18
> To: dmm@ietf.org
> Subject: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-
> 01.txt]
> 
> Hi,
> 
> We have submitted a revised version of our draft addressing the
> comments we got in Singapore:
> 
> - Added some statements about which model from draft-ietf-dmm-
> deployment-models our solution follows (addressing a comment received
> from Sri).
> - Added some text relating to draft-ietf-dmm-ondemand-mobility
> (addressing a comment received from Danny).
> 
> Additionally, we added some terminology from draft-ietf-dmm-
> deployment- models and other minor changes.
> 
> In Singapore we got quite good support of the document. I'd like to
> request feedback/reviews from the WG.
> 
> Thanks!
> 
> Carlos

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

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Sri Gundavelli (sgundave)]

Thanks Carlos.

Folks - Please review the document and post your feedback.

https://tools.ietf.org/id/draft-bernardos-dmm-pmipv6-dlif-01.txt



At IETF100, we polled the WG feedback for adopting this document and there
was consensus for adopting this document. However, we chose not to adopt
the document as there were no recent discussions in the mailer on this
document. We therefore request the WG for feedback in the mailer. We plan
to issue an adoption call post IETF101, but we need some feedback and
substantial comments.


Dapeng & Sri




On 3/6/18, 2:17 PM, "dmm on behalf of Carlos Jesús Bernardos Cano"
 wrote:

>Hi,
>
>We have submitted a revised version of our draft addressing the
>comments we got in Singapore:
>
>- Added some statements about which model from draft-ietf-dmm-
>deployment-models our solution follows (addressing a comment received
>from Sri).
>- Added some text relating to draft-ietf-dmm-ondemand-mobility
>(addressing a comment received from Danny).
>
>Additionally, we added some terminology from draft-ietf-dmm-deployment-
>models and other minor changes.
>
>In Singapore we got quite good support of the document. I'd like to
>request feedback/reviews from the WG.
>
>Thanks!
>
>Carlos

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

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Dirk.von-Hugo]

Dear Carlos and co-authors, all,
thanks for the improvements!
I think the draft is quite well written and provides a good approach to real 
distribution of functionalities in DMM. What might be made clearer is the 
difference between partially and fully DMM you have introduced.
See also as mentioned below in the list of detected nits:

Figs. 2 - 4: exhibiting ? instead of ' on Data packet Flow part ...

p. 5: Home-CPA [I assume it means the same as H-CPA defined in ch. 2: I suggest 
to use one acronym only].
PMIPv6 DMM extenstions => PMIPv6 DMM extensions
the entities that participates => the entities that participate
p. 8: Also, the CMD send a PBA => Also, the CMD sends a PBA
p.10: This procedure reflect => This procedure reflects
address OS taken  => address is taken [??]
p.12: Partial DMM architecture - I wonder whether this should be introduced as 
new term in ch. 2 e.g.

Partial DMM architecture. DMM architecture based on PMIP where MAGs and LMAs 
are distributed in Data Plane but Control Plane of LMA is centralized in CMD 
[if I understood correctly]
Further more when fully DMM solutions are mentioned (later) - is that the 
(only) difference? Should one describe that in more detail?
 
of the mobile selecting => of the mobile node selecting
p.13: HSS [why not using 3GPP-independent term CMD here?] - same on p.15 ...
p.15: mn1dgw2/mn1dgw1 [not used in Fig.6, shouldn't it say mn1mar2/mn1mar1 
instead?]
the serving MAAR (MAAR1) => the serving MAAR (MAAR2) [right? Since MAAR2 is the 
actual S-MAAR of MN1 in Fig. 6]
consider by 3GPP => considered by 3GPP
p.20: This field MUST be set to 34.=> This field MUST be set to 33.[according 
to format above unless an 8-bit Reserved field is included as in other formats 
...]
p.23: on the serving distributed gateway => on the S-MAAR [another left-over by 
previous version ...] 
p.25: we describe =>  we describe
p.27: ot the operators => of the operators
both solution apply the same signalling scheme => meaning full and partial or 
rather operation of the solution in both (of mentioned multiple) domains here?
p.28: then stop the BCE => then stops the BCE
p.30: mobile edge computing (MEC) =>  multi-access edge computing (MEC) [as 
defined by ETSI which is explicitly mentioned!]
edge ir the => edge or the [edge near the?]

Thanks and best regards
Dirk
-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Carlos Jesús Bernardos Cano
Sent: Dienstag, 6. März 2018 23:18
To: dmm@ietf.org
Subject: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

Hi,

We have submitted a revised version of our draft addressing the comments we got 
in Singapore:

- Added some statements about which model from draft-ietf-dmm- 
deployment-models our solution follows (addressing a comment received from Sri).
- Added some text relating to draft-ietf-dmm-ondemand-mobility (addressing a 
comment received from Danny).

Additionally, we added some terminology from draft-ietf-dmm-deployment- models 
and other minor changes.

In Singapore we got quite good support of the document. I'd like to request 
feedback/reviews from the WG.

Thanks!

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