Re: [netext] WG LC: draft-ietf-netext-pmip-lr

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

Hi Rajeev,

Some comments inline...

On Mon, 2011-06-06 at 15:56 -0700, Rajeev Koodli wrote:
> Hi Carlos,
> 
> 
> On 6/5/11 11:51 PM, "Carlos Jesús Bernardos Cano" <[e-mail]> wrote:
> 
> >>> - Section 4. The example provided about an application-layer signaling
> >>> entity notifying the LMA about the possibility of LR and the end-points
> >>> does not seem very realistic to me. In this scenario (A11), I think
> >>> either MAG or LMA can easily detect this.
> >> 
> >> The idea of the leaving that text in there was that there are some
> >> classes of applications that would need LR and they could request
> >> initiation of LR if needed. There was some interest to allow this kind
> >> of triggering but to leave it as an implementation detail. The spec does
> >> not cover application based triggering. Would you object to leave this
> >> text in there?
> > 
> > No strong objection. I just think that application based trigggering is
> > not very realistic, but it's mainly a personal opinion. If there was
> > interest to allow it, I'm fine with that.
> > 
> 
> The "upper-layer" entity may provide the policy OK for LR for the two
> end-points in question. This is just an example trigger.

Fine, I just pointed out that the example trigger appeared as quite
complex to me (thinking of applications knowing about PMIPv6 being used
and enabling disabling LR seems a bit unrealistic, but I'm OK with
that).

> 
> 
> >> 
> >>> - Section 4 (page 5). What is the rationale behind the U-LRA message? To
> >>> me it is not clear and I see that it complicates the protocol (as
> >>> introduces unsolicited messages that impact on the state machine).
> >>> Besides, the draft should IMHO clearly state if the LRI message sent in
> >>> response to the U-LRA needs to be acknowledged with another LRA (so the
> >>> sequence is U-LRA (from MAG to LMA), LRI (from LMA to MAG) and the LRA
> >>> (from MAG to LMA).
> >> 
> >> OK. I have removed the U-LRA as it adds complexity for no reason.
> >> 
> 
> What about the case when the LR state at the MAG will expire? Will the
> refresh be always done by the LMA?
> 

To me it makes sense doing it that way, since we are putting in the LMA
a centralized role.

> 
> >>> - Why do the MAGs need to ask the LMA for authorization to perform LR
> >>> even when the MNs are both attached to the same MAG? I'm fine with that,
> >>> but it should be clear why that decision was taken, IMHO.
> >> 
> >> The intent was to centralize the policy decision and minimize
> >> configuration, but I am open to suggestions.
> > 
> > I'd remove the need for authorization in that case.
> > 
> 
> MNs may be attached to the same MAG, but the LR may not be offered to all
> such MNs. In fact, it may be explicitly disallowed if there are policy
> restrictions (for legal reasons). So, you need to have authorization.

And should that authorization be managed by the LR protocol itself? In
PMIPv6, the determination about whether an MN is authorized for
network-based mobility management service is done by the MAG itself (how
is left open, I guess). So I don't see the point of doing things
differently here...

> 
> -Rajeev
> 
> 
> 
> >> 
> >>> - Why do the MAGs check EnableMAGLocalRouting flag in A11 but not in
> >>> A12?
> >> 
> >> In the A11 scenario we are still within the bounds of RFC5213 that
> >> requires checking the flag. RFC5213 does not cover the 1 MAG 2 LMA case.
> > 
> > In my reading of RFC5213, the flag is not restricted to one single LMA
> > case. It just talks about visiting mobile node and correspondent node
> > locally attached to the same MAG.
> > 
> >> 
> >>> - Using LRI in both MAG-to-LMA and LMA-to-MAG makes the protocol a bit
> >>> complex, because they are not used exactly for the same thing (they are
> >>> more than just initiators, as I understand them).
> >>> - Section 7. Why cannot just the MAG stop performing LR when detects
> >>> that one of the MNs is no longer attached/delivery to one of the MNs
> >>> fails?
> >>> - Section 8. Isn't in the scope the case the MAG has an IPv4-only
> >>> address? I guess for that case it is needed to define also a MAG IPv4
> >>> address, right?
> >>> - Section 9.1 (page 17). In the LRI message, couldn't a lifetime value
> >>> set to 0 used instead of the S=1 flag?
> >>> 
> > 
> > What about the previous four comments?

BTW, I refer here to the comments just above (not yet addressed), not
the ones we are discussing now.

Thanks,

Carlos

> > 
> > Thanks,
> > 
> > Carlos
> > 
> >>> Editorial:
> >> 
> >> I have fixed all your editorial comments in -03.
> >> 
> >> Thanks
> >> Suresh
> >> 
> >> 
> 

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67