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

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

Hi Suresh,

On Mon, 2011-06-27 at 13:23 -0400, Suresh Krishnan wrote:
> 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?

If that was the consensus, I'm fine. I don't want to delay the
publication process with issues that have been already discussed and
closed.

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

This is not that clear to me. I still fail to see how this fits with
RFC5844. We may have the case of IPv4-only transport, right? Maybe I'm
missing something.

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

OK, thanks.

Carlos

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