Subject: [netlmm] WG Last-Call on Heartbeat Mechanism for Proxy Mobile IPv6 ( draft-ietf-netlmm-pmipv6-heartbeat)

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Mon, 10 Nov 2008 23:03:47 +0200

Hello Netlmm-WG,

The netlmm WG chairs would like to announce the following last call.

Title:  Heartbeat Mechanism for Proxy Mobile IPv6
Draft:  draft-ietf-netlmm-pmipv6-heartbeat
Start:  10.11.2008, 11pm EET
Due:    24.11.2008, 11pm EET
Duration: 2 weeks

Please, review the draft and provide comments on the list.

Regards,

Vidya & Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

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

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 10 Nov 2008 15:22:22 -0600

Jonne,

The two week WG LC period includes the IETF73 meeting days. At least in the
past the IETF meeting period could not be included in the last call. Hence
you may want to extend the deadline (if you want 14 days) to a week after
IETF73.

-Raj

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 11 Nov 2008 00:12:52 +0200

Here are my comments.....

- Is the need for heartbeat related to some specifics of PMIP6? For example,
would we also need the same for HA-FA? Could a protocol-agnostic heartbeat
mechanism be more useful? I don't mean to question the need for this work,
but these are the questions that come to my mind reading the I-D. 

- " If there are no proxy binding cache entries at the LMA
   for any of the mobile nodes attached to the MAG, then the heartbeat
   message MUST NOT be sent."

Is this restriction really necessary? 

- "  If the LMA or the MAG do not support the heartbeat messages, they
   should respond with an ICMP Parameter Problem, Code 0, message to the
   initiator.  "

Is this meant to be used for discovering heartbeat support on the peer? If
so, how can we expect the node to implement that if it does not implement
this spec? Before the node uses this protocol against a peer, it needs to
know if the peer really supports the protocol. 

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Soininen Jonne (NSN FI/Espoo)
> Sent: Monday, November 10, 2008 11:04 PM
> To: [email-masked]
> Subject: [netlmm] WG Last-Call on Heartbeat Mechanism for Proxy Mobile
> IPv6 ( draft-ietf-netlmm-pmipv6-heartbeat)
> 
> Hello Netlmm-WG,
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 11 Nov 2008 15:52:44 -0800

Hi Alper,

Alper Yegin wrote:
> mechanism be more useful? 

Perhaps. But we have never received a request for providing a path 
management mechanism for MIPv4 from those who have deployed MIPv4. We 
have such a request for PMIPv6.

It is hard to pick a mechanism that would work for both MIPv4 and PMIPv6 
since the two protocols use different transport protocols. If we try to 
do that, we might end up with something that nobody wants to use. :)

> Is this restriction really necessary? 

Well, it would be good to avoid the heartbeat messages if there is no 
active binding between a MAG and an LMA. But I agree with you. It is too 
restrictive. We can change "MUST NOT" to "SHOULD NOT".

> know if the peer really supports the protocol. 

If this draft is not supported, then it means that the LMA and the MAG 
would not understand the new MH type. When you don't understand a 
particular MH type, you have two choices 1) Send an ICMP parameter 
problem with Code set to '0'. 2) Send a binding error message with 
status set to '2'. Since the heartbeat messages are not tied to a 
particular binding, binding error does not make sense.

I expect a MAG and an LMA to already have support for sending an ICMP 
parameter problem message when they encounter an unknown MH type.

Vijay

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Wed, 12 Nov 2008 20:39:48 +0200

Hello everybody,

You are right, and if there is a feeling that there is not enough time to
comment we can extend the time. However, I just thought the document was
fairly simple, and thus, wouldn't need that much time.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Wed, 12 Nov 2008 20:47:43 +0200

Vijay and Alper,
<as an individual>

> do that, we might end up with something that nobody wants to use. :)

I agree with Vijay on this.

> restrictive. We can change "MUST NOT" to "SHOULD NOT".

Sounds good. There could be cases where it might be wished to checked
between two boxes that they are alive even though there are no bindings.
However, I don't think this is a general case.
> parameter problem message when they encounter an unknown MH type.

I think Alper has a point here: You cannot make the non-compliant node to do
anything but answer on a message as a box that has no knowledge of the
heartbeat mechanism. Vijay, you might want to write this from the point of
view of the sender - basically documenting what the sender could expect to
get as a response if the recipient doesn't understand the heartbeat
mechanism. You cannot put any requirements on the node that does not support
this functionality.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Nov 2008 11:22:54 -0800

> mechanism. You cannot put any requirements on the node that does not support

Sure, I can re-write the paragraph. Note that this would be applicable 
to any new MH type that we define in the IETF. If the receiver does not 
understand the MH type, an ICMP error parameter problem message should 
be sent. Maybe this text needs to be added to RFC 3775bis.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Nov 2008 11:33:02 -0800

Jonne, Alper,

Note that an IPv6 host/router would send an ICMP parameter problem any 
time it doesn't understand a fixed field in a protocol header. We are 
basically using that function.

Even RFC 3775 requires a receiver to send an ICMP parameter problem if 
it does not understand mobility header (protocol 135) and receives a 
message with the mobility header.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Nov 2008 15:34:07 -0800

Following up on my message again (sorry about that)..

I just chatted with Charlie. It looks like sending a Binding Error 
message with status set to '2' is the right option. Not ICMP parameter 
problem message. RFC 3775 says

    o  The MH Type field MUST have a known value (Section 6.1.1).
       Otherwise, the node MUST discard the message and issue a Binding
       Error message as described in Section 9.3.3, with Status field set
       to 2 (unrecognized MH Type value).

I updated the text in draft-ietf-netlmm-pmipv6-heartbeat to say

    If the LMA or the MAG do not support the heartbeat messages, they
    respond with a Binding Error message with status set to '2'
    (unrecognized MH type value) as described in [RFC3775].  When the
    Binding Error message with status set to '2' is received in response
    to Heartbeat Request message, the initiating MAG or the LMA MUST NOT
    use heartbeat messages with the other end again.

Vijay

Vijay Devarapalli wrote:
>> to any new MH type that we define in the IETF. If the receiver does 
>> not understand the MH type, an ICMP error parameter problem message 
>> should be sent. Maybe this text needs to be added to RFC 3775bis.
>>
>> Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 21 Nov 2008 22:28:53 +0100

Hi all,

I have read the draft-ietf-netlmm-pmipv6-heartbeat, I think that the draft is in good shape and ready to move forward. I haven't found any issues,  but please find below some comments...

Would it make sense that the last successful MIP signalling message exchange between the MAG and the LMA resets the heartbeat timer? This would be an optimization allowing to skip the heartbeat exchange when there is a lot of PBU/PBack messages going on between the MAG and LMA.

>  If a PMIPv6 node restarts and looses PMIPv6 session state, it SHOULD
>  send an unsolicited Heartbeat Response message with an incremented
>   Restart Counter to all the PMIPv6 nodes that had previously
>   established PMIPv6 sessions.

To be able to do this the PMIPv6 node must store the list of its active PMIPv6 peers into the non-volatile memory. As the non-volatile memory is mentioned in the context of a Restart Counter, maybe it should be also mentioned here?

Would it make sense to mandate that the PMIP6 must clear the corresponding BCEs/BULs when it detects that the peer node re-booted? In the current thext the action upon detection of a peer's re-boot is out of scope. I'm not sure why is that. 

domagoj

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Soininen Jonne 
> (NSN FI/Espoo)
> Sent: 10. studeni 2008 22:04
> To: [email-masked]
> Subject: [netlmm] WG Last-Call on Heartbeat Mechanism for 
> Proxy Mobile IPv6 ( draft-ietf-netlmm-pmipv6-heartbeat)
> 
> Hello Netlmm-WG,
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 21 Nov 2008 18:56:32 -0500

Hi Domagoj,

> I have read the draft-ietf-netlmm-pmipv6-heartbeat, I think that the
draft
> is in good shape and ready to move forward. I haven't found any
issues,
> but please find below some comments...

[RKo:>] Thank you for your comments.

> 
> Would it make sense that the last successful MIP signalling message
> exchange between the MAG and the LMA resets the heartbeat timer? This
> would be an optimization allowing to skip the heartbeat exchange when
> there is a lot of PBU/PBack messages going on between the MAG and LMA.

[RKo:>] This might be possible. OTOH, when there is a lot of PBU/PBA
signaling, you would end up re-setting the heartbeat timer a lot too. 

Also, the heartbeat request/response are used by both LMA and MAG,
whereas PBU/PBA sequence would be valid only for the MAG.

> To be able to do this the PMIPv6 node must store the list of its
active
> PMIPv6 peers into the non-volatile memory. As the non-volatile memory
is
> mentioned in the context of a Restart Counter, maybe it should be also
> mentioned here?

[RKo:>] That's okay with me.

> 
> Would it make sense to mandate that the PMIP6 must clear the
corresponding
> BCEs/BULs when it detects that the peer node re-booted? In the current
> thext the action upon detection of a peer's re-boot is out of scope.
I'm
> not sure why is that.

[RKo:>] A node may take actions all of which may not be specified in a
spec. 
This is a spec about reachability and failure detection. If it were also
about actions that follow failure detection, we could add procedures.

However, adding just a sentence that BCEs/BULs should be cleared seems
okay. 

Regards,

-Rajeev