Subject: Re: [netlmm] The way forward as discussed during the WG meeting

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 21 May 2008 13:58:51 -0700

Hello Jonne, Vidya,

I would like to propose the following to be added to the new
NETLMM charter.

Path Management and Failure Detection for PMIPv6
------------------------------------------------
If the LMA crashes or if there is a communication problem on the
path between the MAG and the LMA, the MAG discovers this only when
it sends the next proxy Binding Update and gets no response from
the LMA. If a MAG becomes unreachable, the LMA can detect it only
when it starts receiving ICMP unreachable messages from an
intermediate router in response to data traffic the LMA tunnels to
the MAG. For some deployments of Proxy Mobile IPv6 (for example
3GPP), it is desirable to detect the LMA or the MAG reachability
failure quickly, so that appropriate action can be taken. For this
we need some sort of heartbeat mechanism between the MAG and the
LMA. One such mechanism is described in
http://www.ietf.org/internet-drafts/draft-devarapalli-netlmm-pmipv6-heartbeat-01.txt

People willing to work on this
------------------------------
- Vijay Devarapalli
- Suresh Krishnan

Regards,
Vijay

Soininen Jonne (NSN FI/Espoo) wrote:
> Hello everybody,
> 
> Now that the IETF week is over, I think it is time to recap the meeting
> outcome related to the rechartering of our beloved working group.
> 
> The consensus of the meeting was to concentrate on the work for the next
> twelve months. We discussed in the meeting, which would be the work items we
> would think should be done first.
> 
> The meeting was able to identify the following:
> 
>  * GRE Keying
>  * PMIP6/MIP6 interactions
>  * AAA - Diameter & Radius
>  * LMA discovery
> 
> We'll have to see what is the right place to do the AAA work. It is either
> in netlmm or in the relative AAA working group (Dime or Radex).
> 
> LMA discovery on the other hand is something that might be either solved in
> AAA or specific separate procedure.
> 
> We couldn't find consensus on other work items, yet. Main reason was the
> lack of clarity of the work needed. Thus, if we want to do one or two items
> in addition to the now agreed work, we have to understand what the work is,
> and its importance.
> 
> Thus, we discussed that the right way of identifying other work items, we
> would need to have a paragraph or two describing the work, and listing the
> people that would be interested to work on the topic. I would like to ask
> the people that are interested to add work on the charter to
> 
> 1) Describe the topic with a paragraph or two (what is needed, not the
> solution itself)
> 2) Who would be the people who would be able and interested to invest to the
> work. 
> 
> I have to remind everybody that time is of essence in deciding the new
> charter. Our dear AD said that we should move quickly here. Thus, if you
> think additional work is needed, please, write the description quickly and
> list the people that would work on the topic.
> 
> Notice that the people who are listed as interested in additional topics
> will also commit to further the other work in the charter through
> contribution and review.
> 
> The consensus of the working group is tested on the mailing list. Thus, the
> described way forward should be considered as a proposal. However, if
> somebody would think this way forward is not the correct one, I would expect
> those individuals to justify their objections quite carefully.
> 
> I hope this helps.
> 
> Cheers,
> 
> Jonne.
> 

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

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 21 May 2008 16:32:55 -0500

I think this a needed functionality and I support adding it to the
charter.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Vijay Devarapalli
Sent: Wednesday, May 21, 2008 3:59 PM
To: Soininen Jonne (NSN FI/Espoo); [email-masked]
Cc: [email-masked]
Subject: Re: [netlmm] The way forward as discussed during the WG meeting

Hello Jonne, Vidya,

I would like to propose the following to be added to the new NETLMM
charter.

Path Management and Failure Detection for PMIPv6
------------------------------------------------
If the LMA crashes or if there is a communication problem on the path
between the MAG and the LMA, the MAG discovers this only when it sends
the next proxy Binding Update and gets no response from the LMA. If a
MAG becomes unreachable, the LMA can detect it only when it starts
receiving ICMP unreachable messages from an intermediate router in
response to data traffic the LMA tunnels to the MAG. For some
deployments of Proxy Mobile IPv6 (for example 3GPP), it is desirable to
detect the LMA or the MAG reachability failure quickly, so that
appropriate action can be taken. For this we need some sort of heartbeat
mechanism between the MAG and the LMA. One such mechanism is described
in
http://www.ietf.org/internet-drafts/draft-devarapalli-netlmm-pmipv6-hear
tbeat-01.txt

Regards,
Vijay

Soininen Jonne (NSN FI/Espoo) wrote:
> Hello everybody,
> 
> Now that the IETF week is over, I think it is time to recap the 
> meeting outcome related to the rechartering of our beloved working 
> group.
> 
> The consensus of the meeting was to concentrate on the work for the 
> next twelve months. We discussed in the meeting, which would be the 
> work items we would think should be done first.
> 
> We'll have to see what is the right place to do the AAA work. It is 
> either in netlmm or in the relative AAA working group (Dime or Radex).
> 
> LMA discovery on the other hand is something that might be either 
> solved in AAA or specific separate procedure.
> 
> We couldn't find consensus on other work items, yet. Main reason was 
> the lack of clarity of the work needed. Thus, if we want to do one or 
> two items in addition to the now agreed work, we have to understand 
> what the work is, and its importance.
> 
> Thus, we discussed that the right way of identifying other work items,

> we would need to have a paragraph or two describing the work, and 
> listing the people that would be interested to work on the topic. I 
> would like to ask the people that are interested to add work on the 
> charter to
> 

> solution itself)
> 2) Who would be the people who would be able and interested to invest 
> to the work.
> 

> charter. Our dear AD said that we should move quickly here. Thus, if 
> you think additional work is needed, please, write the description 
> quickly and list the people that would work on the topic.
> 
> Notice that the people who are listed as interested in additional 
> topics will also commit to further the other work in the charter 
> through contribution and review.
> 
> The consensus of the working group is tested on the mailing list. 
> Thus, the described way forward should be considered as a proposal. 
> However, if somebody would think this way forward is not the correct 
> one, I would expect those individuals to justify their objections 
> quite carefully.
> 
> I hope this helps.
> 
> Cheers,
> 
> Jonne.
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 21 May 2008 16:40:05 -0500

Yes. I second!
I also would like to add that this functionality is simple enough to be
addressed in the next 12 months.

Cheers!

Regards,
Ahmad

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Khalil, Mohamed 
> (RICH2:2S20)
> Sent: Wednesday, May 21, 2008 4:33 PM
> To: Vijay Devarapalli; Soininen Jonne (NSN FI/Espoo); 
> [email-masked]
> Cc: [email-masked]
> I think this a needed functionality and I support adding it 
> to the charter.
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> If the LMA crashes or if there is a communication problem on 
> the path between the MAG and the LMA, the MAG discovers this 
> only when it sends the next proxy Binding Update and gets no 
> response from the LMA. If a MAG becomes unreachable, the LMA 
> can detect it only when it starts receiving ICMP unreachable 
> messages from an intermediate router in response to data 
> traffic the LMA tunnels to the MAG. For some deployments of 
> Proxy Mobile IPv6 (for example 3GPP), it is desirable to 
> detect the LMA or the MAG reachability failure quickly, so 
> that appropriate action can be taken. For this we need some 
> sort of heartbeat mechanism between the MAG and the LMA. One 
> such mechanism is described in

---

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 21 May 2008 17:58:56 -0400

+1. 

Cheers
Suresh 

> [mailto:[email-masked]] On Behalf Of Ahmad Muhanna
> Sent: May-21-08 5:40 PM
> To: Mohamed Khalil; Vijay Devarapalli; Soininen Jonne (NSN 
> FI/Espoo); [email-masked]
> Cc: [email-masked]
> I also would like to add that this functionality is simple 
> enough to be addressed in the next 12 months.
> 
> Cheers!
> 
> Regards,
> Ahmad
>  
> 
> > deployments of Proxy Mobile IPv6 (for example 3GPP), it is 
> desirable 
> > to detect the LMA or the MAG reachability failure quickly, so that 
> > appropriate action can be taken. For this we need some sort of 
> > heartbeat mechanism between the MAG and the LMA. One such 
> mechanism is 
> > described in

---

From: "fan zhao" <[email-masked]>
Date: Fri, 23 May 2008 19:16:43 -0700

Hi Vijay,

I think this is a useful draft. I just have a doubt and I appreciate
your clarification
on this.

Considering the following scenario

                                      |-------LMA3
MAG1 ---- LMA2/MAG2 ---|
                                      |-------LMA4

where the MAG1 connects to an entity that acts as a LMA (LMA2) to this MAG and
also as a MAG (MAG2) to LMA3 and LMA4 that ultimately provide network
connectivity.

If the MAG1 sends the heartbeat message to LMA2 to detect path
failure, and when
the LMA2 receives this message, does this trigger a heartbeat message
sent by MAG2
to either LMA3 or LMA4 or both?

If yes, is additional mobility option needed in the heartbeat message for MAG1
to only detect failure on the path up to LMA3 (because there is active session
with LMA4)? What do you think?

Sincerely,
fan

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 27 May 2008 19:54:04 -0400

Hi Fan,

(trimmed the cc list) 

> to either LMA3 or LMA4 or both?

The heartbeat mechanism is used independently for each MAG-LMA tunnel.
If there is a hierarchical use of PMIPv6, the two paths are managed
independently.

Vijay

---

From: "fan zhao" <[email-masked]>
Date: Tue, 27 May 2008 17:18:36 -0700

Hi Vijay,

Thanks for your clarification. I agree with you,

Another minor issue regarding "the use of IPsec protection for is optional":
In case of IPSec hop-by-hop security between the MAG and the LMA, PMIP
signaling messages
may be encapsulated with additional IP headers during transmission. If
there is no
IPSec protection for HB messages, the destination address in the HB
messages (i.e. the LMA)
could be different from those in the extenal IP headers encapsulating
PMIP singaling messages.
Therefore if the routing is purely based on the destination address,
the HB message could take a
different route from signaling messages. What do you think?

Sincerely,
fan

since the destination address (the LMA)
in the HB message is differe

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 27 May 2008 20:25:25 -0400

Hi Fan,

> may be encapsulated with additional IP headers during transmission. 

I am not sure I understand the scenario. For PMIPv6 signaling messages,
if IPsec is used, it is between the MAG and the LMA. 

> If
> there is no
> IPSec protection for HB messages, 

If IPsec is used between the MAG and the LMA to protect the signaling
messages, I assume it would be used in the same manner for
PBU/PBAck/Hearbeat message. The same IPsec SA could be used to protect
all these messages. The MH Type selector would need to include the
Heartbeat message type in addition to PBU and PBAck (basically the range
of values from BU to the Heartbeat message).

Vijay

the destination address in the HB

---

From: "fan zhao" <[email-masked]>
Date: Tue, 27 May 2008 17:32:02 -0700

Hi Vijay,

Please see below.

> if IPsec is used, it is between the MAG and the LMA.

That is what I thought before too. However, in addition to this end-to-end
security model, 3GPP also allows hop-by-hop security model.

> of values from BU to the Heartbeat message).
Fan> Agreed.

Sincerely,
fan