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

[Carlos Jesús Bernardos Cano <[e-mail]>]

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:
> Hi Michal,
> 
> 
> Thanks for the good review comments… some comments inline ..Carlos can
> add/clarify more …
> 
> 
> 
> 
> 
> 
> From: Michał Hoeft <[e-mail]>
> Date: Friday, October 18, 2013 3:23 AM
> To: "[e-mail]" <[e-mail]>
> 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 ?
> 
[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:
> 
> 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. 
> 
> 
> 
[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.
> 
> 
> Please, consider also revision of following typos:
> 
> 
> page 4:
> 
> is enabled is for => is enabled for

[Carlos] Fixed in -11, thanks.
> 
> page 7,9:
> 
> proxy binding acknowledgment => Proxy Binding Acknowledgment
> 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):
> PBU =>PBU(DMNP)

[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. 
> 
> page 11:
> 
> from the mobile router from registering => from the mobile router for
> registering
> 
[Carlos] Fixed in -11, thanks.

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

Again, thanks!

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