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

[Michał Hoeft <[e-mail]>]

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