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

[Rajeev Koodli <[e-mail]>]

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.


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


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

-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?
> 
> Thanks,
> 
> Carlos
> 
>>> Editorial:
>> 
>> I have fixed all your editorial comments in -03.
>> 
>> Thanks
>> Suresh
>> 
>>