Subject: [netext] Review: draft-ietf-netext-pd-pmip-10

From: Michał Hoeft <[email-masked]>
Date: Fri, 18 Oct 2013 12:23:42 +0200

Hello

I am a researcher at Gdańsk University of Technology interested in mobility
management protocols, especially in PMIPv6. I would be very thankful if
authors of draft-ietf-netext-pd-pmip-10 could clarify my doubt.

I wonder, why Section 3 is not more general, why only three deployment
models are described in the draft and titled after DR location.
It seams that, DR don't have to be co-located with LMA (Section 3.2.2). In
this case, it can be run on an external server and it does not change
message flow.
It is similar in Section 3.2.1, in which LMA provides to DR prefixes by
means of DMNP option. It is very interesting protocol integrating solution.
However I'm a little confused considering implementation of DR co-located
with MAG. I can imagine a deployment model, in that DR is co-located with
MAG but obtains prefixes using more common methods e.g.
Delegated-IPv6-Prefix AVP (RFC 4818). Especially, if it could be aggregated
with other MAG-to-HAAA AVPs (RFC 5779).

In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be more
accurate and to describe MAG-LMA interaction instead of DR co-location. For
example:
3.2.1 DMNP provided during registration
3.2.2 Separated AR and DMNP registration
3.2.3 Aggregated AR and DMNP registration

In accordance with RFC5213, PBU/PBA messages have few mandatory options
(MNI,HNP,HI,AAT). Although some of them are easy to set (MNI with MNI of
AR, HI with 5. Handoff state not changed, AAT depends on access technology
- please correct me if I'm wrong), I see the problem with HNP in separate
AD and DMNP registration scenario. In my opinion, it should be defined how
to fill this option - either ALL_ZERO or HNP of AR.

Please, consider also revision of following typos:
 page 4:
is enabled is for => is enabled for
page 7,9:
proxy binding acknowledgment => Proxy Binding Acknowledgment
proxy binding update => Proxy Binding Update
page 9. Figure 2: Message 4):
PBU =>PBU(DMNP)
page 11:
from the mobile router from registering => from the mobile router for
registering

If you need any additional detail on my comments, please, do not hesitate
to contact me.

Best regards
Michal Hoeft

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 18 Oct 2013 18:05:10 +0000

Hi Michal,

Thanks for the good review comments… some comments inline ..Carlos can add/clarify more …

From: Michał Hoeft <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 18, 2013 3:23 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [netext] Review: draft-ietf-netext-pd-pmip-10

Hello

I am a researcher at Gdańsk University of Technology interested in mobility management protocols, especially in PMIPv6. I would be very thankful if authors of draft-ietf-netext-pd-pmip-10 could clarify my doubt.

I wonder, why Section 3 is not more general, why only three deployment models are described in the draft and titled after DR location.
It seams that, DR don't have to be co-located with LMA (Section 3.2.2). In this case, it can be run on an external server and it does not change message flow.
It is similar in Section 3.2.1, in which LMA provides to DR prefixes by means of DMNP option. It is very interesting protocol integrating solution.

[Sri] We covered the key deployment models.  DR function can be on the located in the home network and that is typically on the LMA. It can be certainly outside the LMA, but there is some interworking needed between the DR and the LMA and is out of scope for this spec. We did not explicitly cover that scenario, but a deployment can certainly make that work. But, that has no impact on the wire protocol between the LMA and MAG. We can add a note that this is certainly allowed. Carlos – Agree ?

>  However I'm a little confused considering implementation of DR co-located with MAG. I can imagine a deployment model, in that DR is co-located with MAG but obtains prefixes using more common methods e.g. Delegated-IPv6-Prefix AVP (RFC 4818). Especially, if it could be aggregated with other MAG-to-HAAA AVPs (RFC 5779).

[Sri] From protocol point of view, MAG can include the DMNP option, with ALL_ZERO or with a specific value. MAG can learn about those prefixes, via AAA (with DMNP AVP's), local config, DHCP interworking and request the same. MAG has the ability to populate the DMNP option with a specific prefix value, or a 0 to allow LMA to do the allocation. If you see the protocol section, which is more generic, you will see this.

In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be more accurate and to describe MAG-LMA interaction instead of DR co-location. For example:
3.2.1 DMNP provided during registration
3.2.2 Separated AR and DMNP registration
3.2.3 Aggregated AR and DMNP registration

[Sri] That is certainly one way to drafting and is fine. What is there in section 3.2.1 to 3.2.1 are more covered along the lines of popular deployment model, but the protocol section is more generic. The key point is that protocol semantic clearly allow the negotiation in  a flexible manner covering all these variations.

In accordance with RFC5213, PBU/PBA messages have few mandatory options (MNI,HNP,HI,AAT). Although some of them are easy to set (MNI with MNI of AR, HI with 5. Handoff state not changed, AAT depends on access technology - please correct me if I'm wrong), I see the problem with HNP in separate AD and DMNP registration scenario. In my opinion, it should be defined how to fill this option - either ALL_ZERO or HNP of AR.

[Sri] Carlos can add. But, the protocol is not requiring changes to the base options. In all the scenarios covered by 5213, 5844, this allows a MAG to request a additional prefix set, for delegation, as supposed to hosting them on the MN-AR link.

from the mobile router from registering => from the mobile router for registering

If you need any additional detail on my comments, please, do not hesitate to contact me.

Best regards
Michal Hoeft

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 21 Oct 2013 00:07:10 +0200

Hi Sri, Michal,

Thanks a lot Michar for your comments.

Adding some additional comments inline below.

On Fri, 2013-10-18 at 18:05 +0000, Sri Gundavelli (sgundave) wrote:
> From: Michał Hoeft <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> I am a researcher at Gdańsk University of Technology interested in
> mobility management protocols, especially in PMIPv6. I would be very
> thankful if authors of draft-ietf-netext-pd-pmip-10 could clarify my
> doubt. 
> 
> It seams that, DR don't have to be co-located with LMA (Section
> 3.2.2). In this case, it can be run on an external server and it does
> not change message flow.
> 
> It is similar in Section 3.2.1, in which LMA provides to DR prefixes
> by means of DMNP option. It is very interesting protocol integrating
> solution.
> 
> 
> [Sri] We covered the key deployment models.  DR function can be on the
> located in the home network and that is typically on the LMA. It can
> be certainly outside the LMA, but there is some interworking needed
> between the DR and the LMA and is out of scope for this spec. We did
> not explicitly cover that scenario, but a deployment can certainly
> make that work. But, that has no impact on the wire protocol between
> the LMA and MAG. We can add a note that this is certainly allowed.
> Carlos – Agree ?
> 
[Carlos] Yes, agree. We'll add a note in -11.
> 
> >  However I'm a little confused considering implementation of DR
> co-located with MAG. I can imagine a deployment model, in that DR is
> co-located with MAG but obtains prefixes using more common methods
> e.g. Delegated-IPv6-Prefix AVP (RFC 4818). Especially, if it could be
> aggregated with other MAG-to-HAAA AVPs (RFC 5779). 
> 
> 
> [Sri] From protocol point of view, MAG can include the DMNP option,
> with ALL_ZERO or with a specific value. MAG can learn about those
> prefixes, via AAA (with DMNP AVP's), local config, DHCP interworking
> and request the same. MAG has the ability to populate the DMNP option
> with a specific prefix value, or a 0 to allow LMA to do the
> allocation. If you see the protocol section, which is more generic,
> you will see this.
> 
> 
> 
> In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be
> more accurate and to describe MAG-LMA interaction instead of DR
> co-location. For example:
> 
> [Sri] That is certainly one way to drafting and is fine. What is there
> in section 3.2.1 to 3.2.1 are more covered along the lines of popular
> deployment model, but the protocol section is more generic. The key
> point is that protocol semantic clearly allow the negotiation in  a
> flexible manner covering all these variations.
> 
> 
> 
> 
> In accordance with RFC5213, PBU/PBA messages have few mandatory
> options (MNI,HNP,HI,AAT). Although some of them are easy to set (MNI
> with MNI of AR, HI with 5. Handoff state not changed, AAT depends on
> access technology - please correct me if I'm wrong), I see the problem
> with HNP in separate AD and DMNP registration scenario. In my opinion,
> it should be defined how to fill this option - either ALL_ZERO or HNP
> of AR.
> 
> 
> 
> [Sri] Carlos can add. But, the protocol is not requiring changes to
> the base options. In all the scenarios covered by 5213, 5844, this
> allows a MAG to request a additional prefix set, for delegation, as
> supposed to hosting them on the MN-AR link. 
> 
> 
> 
[Carlos] Yes, I think it is better not to explicitly add that, so we
avoid not covering some potential case. As long as what we have in the
text is clear and allow for implementation of the spec, I think it is
better not to add more text.
> is enabled is for => is enabled for

[Carlos] Fixed in -11, thanks.
> proxy binding update => Proxy Binding Update

[Carlos] I think the RFC Editor prefers these terms to be in lowercase,
with the exception of the first time they appear and the acronym is
introduced.
> page 9. Figure 2: Message 4):

[Carlos] Here the intention is to highlight that the prefix is delegated
by the LMA and conveyed back in the PBA. Maybe we can explicitly show
that the DMNP option is present but with an ALL_ZERO value. 
> from the mobile router from registering => from the mobile router for
[Carlos] Fixed in -11, thanks.

> If you need any additional detail on my comments, please, do not

Again, thanks!

Carlos
> 
> 
> Best regards
> 
> Michal Hoeft
> 
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Michał Hoeft <[email-masked]>
Date: Tue, 22 Oct 2013 08:40:21 +0200

Hi Sri, Carlos

Thank you very much for answers and clarification. Now, I see your point of
view.
Best regards
Michal

2013/10/21 Carlos Jesús Bernardos Cano <[email-masked]>

> > Thanks for the good review comments... some comments inline ..Carlos can
> > add/clarify more ...
> >
> >
> >
> >
> >
> >
> > Carlos - Agree ?