Subject: [netlmm] Few Comments on draft: draft-ietf-netlmm-pmipv6-heartbeat-00.txt

From: "Mohana Jeyatharan" <[email-masked]>
Date: Mon, 15 Sep 2008 16:23:55 +0800

Hi Vijay and Rajeev,

I have few comments on your draft.

Two small editorial ones.

Editorial
(1) In Introduction, the MAG is termed mobility anchor gateway. Think
should be mobility access gateway.

(2)In section 3.1, the MAG is written as MAR.

Few clarifications nothing major, but mainly about some optimizations:
If optimizations are not the motive of this draft, pls ignore the
comments.

(1)The node restart mechanism is actually useful for LMA re-start, so
that the MAG can learn it and perform the PBU and create new mobility
state at LMA. However, in the draft, it is mentioned that the MAG also
does the same and attach re-start counter in heartbeat response or in
unsolicited response. I think, this may not be necessary for the MAG
because, if it-restarts, it can send a PBU and need not send an
unsolicited heartbeat message with re-start counter value. PBU can
create the correct state.

(2)In section 3.1, it is mentioned that when path failure is detected,
some re-tries are done until MISSING_HEARTBEATS_ALLOWED. Is the interval
between these the same as the HEART-BEAT Interval. I think, the interval
should be narrowed down, to take appropriate actions at the PMIPv6
peers.

(3)Also, in section 3.1, it is mentioned that "If a Heartbeat Response
message is received, the
   MISSING_HEARTBEATS_ALLOWED counter is reset."
I think it should be MISSING_HEARBEAT counter should be reset.

(4)In this draft, both MAG and LMA can send heart beat to discover path
failures. Is there any synchronization between them. Since it is
mentioned in the draft, that these heartbeat messages can increase
signaling overhead, it may be appropraite for LMA not to be involved in
heartbeat tests if MAG is involved. Or for LMA to have a high
HEARTBEAT-INTERVAL to overcome this signaling issue.

(5)Another question, is: Is the HEART_BEAT Interval a static value. If
there are many data packets coming from the MAG, then the HEART_BEAT
interval can be longer. 

BR,
Mohana
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Wang Yungui <[email-masked]>
Date: Thu, 18 Sep 2008 16:29:06 +0800

> create the correct state.

[Yungui] MAG may not send PBU to LMA for all the UEs before it has
recovered their contexts. So that the heartbeat response may be
available for LMA to make all the UEs' BCEs associated with that
MAG in inactive state.

B.R.
Yungui

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 18 Sep 2008 16:45:22 +0800

Hi,

Thanks for the explanation. Well, as I said in my mail these comments
are mainly from optimization point
Of view and I believe the draft is written taking into account all
possible general cases of path failures and node-failures, rather than
focusing on optimizations. Hence I think such coverage for MAG is
essental. It is just that I could not really map the restart mechanism
so easily to MAG as I did to LMA. Anyway thanks.

BR,
Mohana 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wang Yungui
> Sent: Thursday, September 18, 2008 4:29 PM
> To: Mohana Jeyatharan; Vijay Devarapalli; Koodli, Rajeev
> Cc: [email-masked]
> Subject: Re: [netlmm] Few Comments on 
> draft:draft-ietf-netlmm-pmipv6-heartbeat-00.txt
> 
> 
> [Yungui] MAG may not send PBU to LMA for all the UEs before 
> it has recovered their contexts. So that the heartbeat 
> response may be available for LMA to make all the UEs' BCEs 
> associated with that MAG in inactive state.
> 
> B.R.
> Yungui
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 23 Sep 2008 13:09:48 -0400

Hello Mohana,

> should be mobility access gateway.

[RKo:>] Yes.

> (2)In section 3.1, the MAG is written as MAR.

[RKo:>] Will correct.

> create the correct state.

[RKo:>] The primary purpose of Restart mechanism is to clean up state
once a peer has restarted. MAG also has the state - BUL Entry.
Basically, a node  needs to determine that its peer has restarted so
that it can take appropriate actions (which are not specified in the
document).

> should be narrowed down, to take appropriate actions at the PMIPv6

[RKo:>] No, it's not re-tries. Every Request is matched to a Response.
Before sending a new Request, the node checks if it has received
Response for the previous Request. If not, it increments the
MISSING_HEARTBEAT variable. When this variable exceeds a threshold
MISSING_HEARTBEATS_ALLOWED, the node concludes that the peer is not
reachable.

> I think it should be MISSING_HEARBEAT counter should be reset.

[RKo:>] Agree. 

> HEARTBEAT-INTERVAL to overcome this signaling issue.

[RKo:>] This is already mentioned in the 3rd paragraph of Section 3. 
> there are many data packets coming from the MAG, then the HEART_BEAT

[RKo:>] It is a configurable parameter.

Thanks for your input.

Regards,

-Rajeev

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Wed, 24 Sep 2008 09:44:59 +0800

Hi Rajeev,

Thanks for reply. Please see in-line.

BR,
Mohana 

> [mailto:[email-masked]] On Behalf Of Koodli, Rajeev
> Sent: Wednesday, September 24, 2008 1:10 AM
> To: [email-masked]
> [RKo:>] The primary purpose of Restart mechanism is to clean 
> up state once a peer has restarted. MAG also has the state - 
> BUL Entry.
> Basically, a node  needs to determine that its peer has 
> restarted so that it can take appropriate actions (which are 
> not specified in the document).

[Mohana] Yes, I noted in the draft that the actions are not specified
and it is
up to deployment I guess. As you said, since BUL is maintained by MAG, a
symmetric
Mechanism is essential.
> Before sending a new Request, the node checks if it has 
> received Response for the previous Request. If not, it 
> increments the MISSING_HEARTBEAT variable. When this variable 
> exceeds a threshold MISSING_HEARTBEATS_ALLOWED, the node 
> concludes that the peer is not reachable.
> 
[Mohana] Sorry, I misunsderstood. It is normal heart beat operations.
Ok...

> [RKo:>] This is already mentioned in the 3rd paragraph of Section 3. 

[Mohana] Ok, I saw it. Thanks. 

> [RKo:>] It is a configurable parameter.

[Mohana] Yes, since the draft does not state a value for heart beat
interval, I think this can be configured
Based on state of the system.