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

[Suresh Krishnan <[e-mail]>]

Hi Carlos,

Carlos Jesús Bernardos Cano wrote:
> Hi Suresh,
> 
> On Fri, 2011-06-10 at 18:31 -0400, Suresh Krishnan wrote:
>> Hi Carlos,
>>    Addressing the 4 open issues from the last mail.
>>
>> On 11-06-06 02:51 AM, Carlos Jesús Bernardos Cano wrote:
>>>>> - 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).
>> Yes. There is complexity involved here, but not because of the messages 
>> being bidirectional. The root of the complexity is that the MAG and the 
>> LMA can both be initiators. We tried a lot to come up with a 
> 
> Right.
> 
>> deterministic model where one entity can always be the initiator and we 
>> could not do so.
> 
> But couldn't different messages be used? I think it makes the state
> machine more complex to use the same message type as initiator in
> different directions. Anyway, this is an implementation related comment,
> and I'm not that experienced in implementing stuff...

The consensus was that adding another message was more complex than the 
current mechanism. I can keep the issue open and present it again to the 
wg. Would you prefer that?

> 
>>>>> - 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?
>> This is exactly how it is done. In A12 (before it turns into A22) the 
>> MAG is the initiator and the text says that the initiator should tear 
>> down the session.
> 
> OK, maybe I missed that.
> 
>>>>> - 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?
>> We left it out of scope since an IPv4-only MAG is explicitly ruled out 
>> by RFC5844
> 
> In any case, if the MAG and LMA are separated by an IPv4 network (as
> explained in RFC5844), don't we need an MAG IPv4 address option as we do
> for the case of the MAG IPv6 address? I'm missing why if IPv4 transport
> between MAG and LMA is supported by RFC5844, we are ruling out that in
> the LR spec.
> 
>> "Both the mobility entities, the local mobility anchor and the
>>   mobile access gateway are dual-stack (IPv4/IPv6) enabled.
>>   Irrespective of the type of transport network (IPv4 or IPv6)
>>   separating these two entities, the mobility signaling is always
>>   based on Proxy Mobile IPv6 protocol."
> 
> One thing is the signaling being based on PMIPv6, and another is that
> packets are transported in IPv6 or IPv4 packets. If transport is
> IPv4-based, then the LMA needs to know the IPv4 address of the MAG,
> right?

Not necessarily. According to the agreed problem statement (RFC6279) 
deployments can assume that the IP version used for transport is 
consistent across MAGs and can be either IPv4 or IPv6. I think that 
specifying IPv4 transport as well would complicate the LR protocol. If 
you feel strongly about this, we can keep this issue open to present to 
the WG.

> 
>>>>> - Section 9.1 (page 17). In the LRI message, couldn't a lifetime value
>>>>> set to 0 used instead of the S=1 flag?
>> Yes. This is possible, but is there any benefit to changing this?
> 
> Well, if there is a simpler way of doing something (without defining new
> fields), the fair question would be IMHO, is there any benefit in
> defining the S flag?

I do not see a big difference either way. I think I will go ahead and 
remove the S flag like you suggested.

Thanks
Suresh