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

From: Suresh Krishnan <[email-masked]>
Date: Fri, 3 Jun 2011 18:52:36 -0400

Hi Carlos,
    Thanks for your comments. Please find responses inline.

Carlos Jesús Bernardos Cano wrote:
> Hi,
> 
> This is, as I promised in Prague, my review of the document. Sorry for
> being a bit late.
> 
> Overall, I think it is a good document. I have some comments/questions.
> Disclaimer: I might have missed some previous discussion on this
> document, so I may ask questions that have been already addressed. Sorry
> about that.
> 
> BTW, I've reviewed -02, though the WGLC was issued on -01.
> 
> Technical:
> - Section 4. "The LMA initiates a localized routing session by detecting
> a flow between two MNs attached to the same MAG." It seems (also by what
> the rest of the section says) that the LR could be done per-flow, while
> the signaling defined in the document clearly does not allow that, but
> just on HNP level (which I'm fine with it). I'd suggest to clarify the
> text there, and maybe not mention "flow", but rather "traffic".

OK. Sounds reasonable.

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

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

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

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

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

I have fixed all your editorial comments in -03.

Thanks
Suresh

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 06 Jun 2011 08:51:46 +0200

Hi Suresh,

Thanks Suresh. Some comments inline below.

> not cover application based triggering. Would you object to leave this 

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.

> configuration, but I am open to suggestions.

I'd remove the need for authorization in that case.

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

> > set to 0 used instead of the S=1 flag?

What about the previous four comments?

Thanks,

Carlos

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

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 06 Jun 2011 15:56:04 -0700

Hi Carlos,

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

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

> 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

---

From: Qin Wu <[email-masked]>
Date: Tue, 07 Jun 2011 11:00:56 +0800

[Qin]: No,I think both the MAG and the LMA should be allowed to refresh the lifetime.
However requiring U-LRA should be acknowlded by the subsequent LRI/LRA message
exchange looks like three time handshakes.
I am not sure the node sending U-LRA MUST wait for LRI back for confirmation
of refresh. But I think such complexity is not so much since refresh does not happen
all the time.

[Qin]: Agree.

-Rajeev

>> I have fixed all your editorial comments in -03.

_______________________________________________
netext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 07 Jun 2011 08:45:37 +0200

Hi Rajeev,

Some comments inline...

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

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

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

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

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 10 Jun 2011 18:31:51 -0400

Hi Carlos,
   Addressing the 4 open issues from the last mail.

>>> 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 
deterministic model where one entity can always be the initiator and we 
could not do so.

>>> that one of the MNs is no longer attached/delivery to one of the MNs

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.

>>> address? I guess for that case it is needed to define also a MAG IPv4

We left it out of scope since an IPv4-only MAG is explicitly ruled out 
by RFC5844

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

>>> set to 0 used instead of the S=1 flag?

Yes. This is possible, but is there any benefit to changing this?

Thanks
Suresh

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 12 Jun 2011 12:59:59 +0200

Hi Suresh,

> 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 

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

> MAG is the initiator and the text says that the initiator should tear 

OK, maybe I missed that.

> We left it out of scope since an IPv4-only MAG is explicitly ruled out 

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.

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

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

Carlos

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 27 Jun 2011 13:23:37 -0400

Hi Carlos,

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

> IPv4-based, then the LMA needs to know the IPv4 address of the MAG,

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.

> fields), the fair question would be IMHO, is there any benefit in

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 28 Jun 2011 01:14:24 +0200

Hi Suresh,

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

> you feel strongly about this, we can keep this issue open to present to 

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.

> remove the S flag like you suggested.

OK, thanks.

Carlos