Subject: [Mipshop] Adoption of draft-yokota-mipshop-pfmipv6 as a WG document

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 2 Sep 2008 13:25:25 -0400

Hello,

At the MIPSHOP WG meeting at the last IETF, there was consensus to adopt
draft-yokota-mipshop-pfmipv6 as a WG document. We would like to confirm
that consensus on the mailing list. 

Please respond by September 16, if you support or do not support
adopting the document as a WG document. If you have already expressed
your opinion in the WG meeting, there is no need to send an email on
this.

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

---

From: Frank Xia <[email-masked]>
Date: Wed, 10 Sep 2008 12:54:03 -0500

Hi Folks

I support the adopting.

BR
Frank

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 11 Sep 2008 09:34:58 +0200

Hi Vijay,

I support draft-yokota-mipshop-pfmipv6 becoming a WG document. IMO it is a useful enhancement minimizing the handover latency in PMIP deployments.

domagoj

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: 02. rujan 2008 19:25
> To: [email-masked]
> draft-yokota-mipshop-pfmipv6 as a WG document. We would like 
> to confirm that consensus on the mailing list. 
> 
> Please respond by September 16, if you support or do not 
> support adopting the document as a WG document. If you have 
> already expressed your opinion in the WG meeting, there is no 
> need to send an email on this.
> 
> Vijay

---

From: "Syam Madanapalli" <[email-masked]>
Date: Thu, 11 Sep 2008 15:47:34 +0530

Hi,

I read this document and I think the draft is useful for reducing the
handover delays for proxy Mobiel IP.

I support this draft as a WG document.

Thanks,
Syam

---

From: Julien Laganier <[email-masked]>
Date: Fri, 12 Sep 2008 08:58:13 +0900

I support adoption of this draft as a WG item.

--julien

---

From: "BLUME, Oliver" <[email-masked]>
Date: Mon, 15 Sep 2008 19:09:15 +0200

Hello,

I support adopting draft-yokota-mipshop-pfmipv6 as a WG document.

However, there may be scenarios where mobile nodes cannot take benefit from PFMIP. As discussed by Desire and Rajeev (in the "Question onuplinkpacket"- thread, http://www.ietf.org/mail-archive/web/mipshop/current/msg04077.html) for Handoff between two different interfaces of the mobile node the new interface will probably not start sending information until it receives the HNP in a RA, which will impede benefit from forwarding by PFMIP. tBCE may be a complementing mechanism that should be pursued in parallel to PFMIP to cover handover optimisations for both cases (as supported by the consensus poll in Dublin).

Oliver

>-----Ursprüngliche Nachricht-----
>Von: [email-masked] 
>[mailto:[email-masked]] Im Auftrag von Vijay Devarapalli
>Gesendet: Dienstag, 2. September 2008 19:25
>An: [email-masked]
>Betreff: [Mipshop] Adoption of draft-yokota-mipshop-pfmipv6 as 
>a WG document
>
>Hello,
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 15 Sep 2008 14:00:59 -0400

Hi Oliver,

> I support adopting draft-yokota-mipshop-pfmipv6 as a WG document.

[RKo:>] Thanks.

> 
> However, there may be scenarios where mobile nodes cannot take benefit
> from PFMIP. As discussed by Desire and Rajeev (in the "Question
> onuplinkpacket"- thread, http://www.ietf.org/mail-
> archive/web/mipshop/current/msg04077.html) for Handoff between two
> different interfaces of the mobile node the new interface will probably
> not start sending information until it receives the HNP in a RA, which
> will impede benefit from forwarding by PFMIP. 

[RKo:>] Well, this is not an accurate characterization. First, there seems to be no issue with deployments where MAC addresses are not used. Where they are used, it is not clear why a MN should stop sending uplink packets. As I have pointed out, a MN would do NUD/RS upon link change, but that should not stop it from sending uplink packets.

 > tBCE may be a complementing
> mechanism that should be pursued in parallel to PFMIP to cover handover
> optimisations for both cases (as supported by the consensus poll in
> Dublin).

[RKo:>] I don't think you can argue that you need tBCE because PFMIP is not able to handle uplink packets. On the contrary, it provides both uplink and downlink packet forwarding support. If you construct scenarios where a MN pauses uplink packet transmission, you are loosing uplink packets anyway until an RA is received; you can have nMAG supply the HNP (received via context transfer) to the MN to reduce those packet losses, yet forward the uplink packets using the PFMIP tunnel until PMIP registration is completed.

Regards,

-Rajeev

---

From: "BLUME, Oliver" <[email-masked]>
Date: Tue, 16 Sep 2008 16:45:55 +0200

Hi Rajeev,

Hi Rajeev,

I did not mean to start a new discussion in the adoption poll. So I took my answer into another subject. 

>[RKo:>] I don't think you can argue that you need tBCE because 
>PFMIP is not able to handle uplink packets.

Please don't get me wrong. I was not saying that PFMIP has a deficit. I only mentioned that the other solution that was presented in Dublin  also has its use cases. My vote for your draft does not mean tBCE is obsolete. 

>[RKo:>] ... Where [MAC addresses] are used, it is not clear 
>why a MN should stop sending uplink packets. As I have pointed 
>out, a MN would do NUD/RS upon link change, but that should 
>not stop it from sending uplink packets.

To me, the question is not whether the MN stops sending (in tBCE the old interface is still used during HO) but rather when MN starts sending on a new interface. Asuming that the stack in the MN is unchanged and the MN is unaware of the presence of PMIP services the start of sending requires reception of a RA with an IPv6 prefix with the HNP. As you wrote, this RA could either be constructed after PBA or by context transfer from pMAG.

Regards,

Oliver

>[mailto:[email-masked]] Im Auftrag von Koodli, Rajeev
>Gesendet: Montag, 15. September 2008 20:01
>An: [email-masked]
>Betreff: Re: [Mipshop] Adoption of 
>draft-yokota-mipshop-pfmipv6 as aWGdocument
>
>
>Hi Oliver,
>
>> 
>> different interfaces of the mobile node the new interface will 
>> probably not start sending information until it receives the 
>HNP in a 
>> RA, which will impede benefit from forwarding by PFMIP.
>
>[RKo:>] Well, this is not an accurate characterization. First, 
>there seems to be no issue with deployments where MAC 
>addresses are not used. Where they are used, it is not clear 
>why a MN should stop sending uplink packets. As I have pointed 
>out, a MN would do NUD/RS upon link change, but that should 
>not stop it from sending uplink packets.
>
>> mechanism that should be pursued in parallel to PFMIP to cover 
>> handover optimisations for both cases (as supported by the consensus 
>> poll in Dublin).
>
>[RKo:>] I don't think you can argue that you need tBCE because 
>PFMIP is not able to handle uplink packets. On the contrary, 
>it provides both uplink and downlink packet forwarding 
>support. If you construct scenarios where a MN pauses uplink 
>packet transmission, you are loosing uplink packets anyway 
>until an RA is received; you can have nMAG supply the HNP 
>(received via context transfer) to the MN to reduce those 
>packet losses, yet forward the uplink packets using the PFMIP 
>tunnel until PMIP registration is completed.
>
>Regards,
>
>-Rajeev
>
>
>> 
>> Oliver
>> 
>> >Betreff: [Mipshop] Adoption of draft-yokota-mipshop-pfmipv6 as a WG 
>> >document
>> >
>> >Hello,
>> >
>> >draft-yokota-mipshop-pfmipv6 as a WG document. We would like to 
>> >confirm that consensus on the mailing list.
>> >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 16 Sep 2008 10:56:31 -0400

Folks,

Just a reminder that the consensus call will be ending soon. Please
respond if you haven't so far.

There is one issue that has been raised during this consensus call. This
is on the use of ICMPv6-based HI and HACK messages vs MH-based HI and
HACK messages. I would like to hear more opinions on this. Please
respond if you haven't already expressed an opinion on this issue.

Vijay

> Sent: Tuesday, September 02, 2008 10:25 AM
> To: [email-masked]

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 16 Sep 2008 17:54:31 +0200

I do not see a big gain in using MH types here, at least nothing that 
could justify
using MH types now for integrating a recently approved proposed standard,
which uses ICMPv6, into PMIPv6. I do not have a very strong opinion, but the
argument about ease in implementing and bringing PMIPv6 together with
FMIPv6 is vague. I don't think coordinating MH-based protocols with
ICMP-based protocols is a big thing. The same argument applies vice versa,
where it seems to be more efficient to re-use possibly existing FMIPv6
implementations rather than doing a lot of re-coding.
So far, I think the HI/HACK exchange should stick to the FMIP types and 
format.

marco

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 16 Sep 2008 11:15:12 -0500

Thanks Marco. 
My thoughts exactly!

Regards,
Ahmad

> [mailto:[email-masked]] On Behalf Of Marco Liebsch
> Sent: Tuesday, September 16, 2008 10:55 AM
> To: Vijay Devarapalli
> Cc: [email-masked]
> Subject: Re: [Mipshop] Adoption of 
> draft-yokota-mipshop-pfmipv6 as a WG document
> 
> I do not see a big gain in using MH types here, at least 
> nothing that could justify using MH types now for integrating 
> a recently approved proposed standard, which uses ICMPv6, 
> into PMIPv6. I do not have a very strong opinion, but the 
> FMIPv6 is vague. I don't think coordinating MH-based 
> protocols with ICMP-based protocols is a big thing. The same 
> argument applies vice versa, where it seems to be more 
> efficient to re-use possibly existing FMIPv6 implementations 
> rather than doing a lot of re-coding.
> So far, I think the HI/HACK exchange should stick to the FMIP 
> types and format.
> 
> marco
> 
> Vijay Devarapalli wrote:
> > Folks,
> >
> > There is one issue that has been raised during this consensus call. 
> > This is on the use of ICMPv6-based HI and HACK messages vs 
> MH-based HI 
> > and HACK messages. I would like to hear more opinions on 
> this. Please 
> >> Subject: [Mipshop] Adoption of 
> draft-yokota-mipshop-pfmipv6 as a WG 
> >> document
> >>
> >> Hello,
> >>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 16 Sep 2008 13:33:17 -0400

Hi Marco,

> which uses ICMPv6, into PMIPv6. I do not have a very strong opinion,
but
> the
> FMIPv6 is vague.

[RKo:>] Well, I am for using ICMP as well, but I am against excluding
MH. I think there is merit in co-locating the state machines for PMIP
and PFMIP in the same space.

Besides, the request for MH is coming from a deployment consideration
where it is preferred over ICMP. Since we seem to have a choice of
selecting only one Type here, we have to consider MH. 

> I don't think coordinating MH-based protocols with
> ICMP-based protocols is a big thing. 

[RKo:>] See above. 
 
> The same argument applies vice versa,

[RKo:>] As the Editor of FMIPv6, ICMP would have been my choice as well.
However, I do think that a) there is benefit in co-locating PMIP and
PFMIP in MH, and b) we should respond to deployment considerations
pragmatically. 

Hence, I am willing to go with MH.

Regards,

-Rajeev

> > There is one issue that has been raised during this consensus call.
This

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 16 Sep 2008 15:16:45 -0500

Hi Marco,

There is no question that you can transport the HI/HACK messages over ICMP
or MH types. However there are a couple of issues to consider:
1. Do we really want to use ICMP for carrying critical signaling messages.
In certain deployments ICMP may face issues depending on how routers are
configured to handle ICMP messages vs other types.
2. There is a specific interest from at least one SDO in using MH-type for
HI/HACK messages. 

Is there a down-side to specifying MH-type for HI/HACK? Are MH-types a
scarce resource? Would this protocol not work if we use MH-types? Is there a
significant amount of work that needs to be done to specify MH-types? I
don't see any good reasons to not specify new MH-types here.
The only argument is that FMIP6 RFC5268 specifies ICMPv6 and hence we should
use the same. 
I think from a practical perspective, maybe the choice of ICMP for HI/HACK
in FMIP6 was not right. Whether to change that is a separate debate. But in
the context of this I-D I don't see any real good reason to use ICMP only.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 17 Sep 2008 08:09:24 -0500

Hi Raj,

> There is no question that you can transport the HI/HACK 
> messages over ICMP or MH types. However there are a couple of 
> issues to consider:
> In certain deployments ICMP may face issues depending on how 
> routers are configured to handle ICMP messages vs other types.

[Ahmad]
But that solution require that interface to be secure and that domain to
have certain security or a trust model, if I may say. The security
section in this draft reference the FMIP security consideration.
Frankly, I do not see this is an issue. We are not using ICMPv6 in an
open non secure domain. Therefore I am not sure if this argument is
valid. If it does, it should have been surfaced and addressed during
FMIP discussion. I believe we have discussed this back and forth already
Raj. :)

> 2. There is a specific interest from at least one SDO in 
> using MH-type for HI/HACK messages. 
>
[Ahmad]
Where is that interest located. 
Is there a liaison from that SDO which points to that preference. If I
recall correctly, this MH optionality was added to the draft before that
draft was referenced by that SDO.
 
> Is there a down-side to specifying MH-type for HI/HACK? Are 
> MH-types a scarce resource? Would this protocol not work if 
> we use MH-types? Is there a significant amount of work that 
> needs to be done to specify MH-types? I don't see any good 
> reasons to not specify new MH-types here.

> The only argument is that FMIP6 RFC5268 specifies ICMPv6 and 
> hence we should use the same. 

[Ahmad]
That argument makes sense. Because those router which support FMIP do
not need to unnecessarily support new messages. Even if FMIP is not
deployed yet, it makes a lot of sense to be consistent.

> I think from a practical perspective, maybe the choice of 
> ICMP for HI/HACK in FMIP6 was not right. Whether to change 
> that is a separate debate. But in the context of this I-D I 
> don't see any real good reason to use ICMP only.

[Ahmad]
I have not seen one for MH either; other than being a preference for an
SDO which probably was based on some unfounded and unrelated argument,
which is: some routers may be configured to drop ICMPv6 messages.

> nothing that 
> > could justify using MH types now for integrating a recently 
> approved 
> > proposed standard, which uses ICMPv6, into PMIPv6. I do not have a 
> > very strong opinion, but the argument about ease in 
> implementing and 
> > bringing PMIPv6 together with
> > ICMP-based protocols is a big thing. The same argument applies vice 
> > versa, where it seems to be more efficient to re-use 
> possibly existing 
> > FMIPv6 implementations rather than doing a lot of re-coding.
> > So far, I think the HI/HACK exchange should stick to the FMIP types 
> > and format.
> > 
> > marco
> > 
> > Vijay Devarapalli wrote:
> >> Folks,
> >> 
> MH-based 
> >> HI and HACK messages. I would like to hear more opinions on this. 
> >> Please respond if you haven't already expressed an opinion 
> on this issue.
> >> 
> >> Vijay
> >> 
> >>   
> >>> At the MIPSHOP WG meeting at the last IETF, there was 
> consensus to 
> >>> adopt
> >>> adopting the document as a WG document. If you have already 
> >>> expressed your opinion in the WG meeting, there is no 
> need to send 
> >>> an email on this.
> >>> 
> >>> Vijay

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 17 Sep 2008 22:24:55 +0900

Hi Marco,

> implementations rather than doing a lot of re-coding.

I see your point, but we also need to think about the efficiency gained
by using ICMPv6-based HI/HAck since the difference is merely the
conveyor of these messages. The logic for the fast handover won't change
by the protocol type.

> So far, I think the HI/HACK exchange should stick to the FMIP types and 

As you may know, PFMIPv6 started with the ICMPv6-based HI/HAck for
commonality to FMIPv6, but this seems to be the only reason to support
ICMPv6. In the course of hearing other implementors' opinions and
industry needs, I started to realize that the MH-based HI/HAck appear to
be more reasonable and wanted. I couldn't find any strong reason to
force ICMPv6-based one...

Regards,
-- 
Hidetoshi

>>> consensus to adopt

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 17 Sep 2008 16:25:32 +0200

Hi Hidetoshi,

> conveyor of these messages. The logic for the fast handover won't change
Sure, the logic will not change and technically it's not a big thing to 
use MH, everything
is possible. However, if MH-types are more preferable, why is RFC 5268
still based on ICMP? I just thought it's not appropriate for such 
protocol to take
MH here and ICMP there. This is very different from offering different 
transports in
other protocols, such as taking both TCP and SCTP into account for Diameter.

> force ICMPv6-based one...
Please see my comment above.

Thanks for your feedback,
marco

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 17 Sep 2008 16:33:33 +0200

Hi Rajeev,

Koodli, Rajeev schrieb:
>> using MH types now for integrating a recently approved proposed
>>     
> standard,
>   
I guess you mean the 3GPP2 request when you say deployment 
consideration, right?
Well, when this is a strong argument in the IETF and the intention is to 
design a
tailor made protocol for this SDO, I do not strongly argue against. I just
posted my opinion.

> and
Ok, thanks,

marco

>>> is on the use of ICMPv6-based HI and HACK messages vs MH-based HI
>>>       
> and
>   
> expressed
>>>> your opinion in the WG meeting, there is no need to send an email
>>>>         
> on
>   
>>>> this.
>>>>
>>>> Vijay
> https://ww

---

From: Frank Xia <[email-masked]>
Date: Wed, 17 Sep 2008 09:50:34 -0500

Hi Marco

Sorry for my jumping in bluntly.

Please see my inline comments...

BR
Frank

----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Hidetoshi Yokota" <[email-masked]>
Cc: "Marco Liebsch" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 17, 2008 9:25 AM
Subject: Re: [Mipshop] Adoption of draft-yokota-mipshop-pfmipv6 as a WG 
document

>>> versa,
Frank=>IMHO, each of us involving the debate does not think that
it is a big difference regarding MH vs ICMP from technical
perpective.   I also would like to share my understanding when designing
protocols, that is, the more meaningful is the more acceptable by the 
industry.
Now, 3GPP2 chooses MH based on the discussion in that community,
so, I would rather help the industry than push this thing into deadlock.

BTW, I don't think you can show me strong arguments except some
general principles opposing the MH.

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 17 Sep 2008 10:00:12 -0500

Ahmad,

If an LS is what you want from PP2, we can ask PP2 to send one to the
MIPSHOP WG. 
Regarding the security discussion, I don't see a concern here (which I
believe is what you also conclude).

The only point that I see is that you are questioning the deployments which
drop ICMP messages for whatever reason. Well, deployments and routers may be
configured to deal with ICMP messages in case of congestion or other reasons
in a specific manner. Additionally ICMP messages may be treated differently
in terms of priority and handling in certain cases and if ICMP was used for
critical signaling, then it has an impact on handovers. Network planning and
deployments cannot be easily changed and hence it is easier to take such
implications into consideration rather than just being academic.

-Raj

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 17 Sep 2008 17:09:49 +0200

Hi Frank,

> general principles opposing the MH.
That was not my intention, not at all. Again: I simply posted my opinion..

marco

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 17 Sep 2008 11:34:33 -0400

Hi Marco,

> I guess you mean the 3GPP2 request when you say deployment

[RKo:>] eHRPD is the deployment, and 3GPP2 is the SDO.

> tailor made protocol for this SDO, I do not strongly argue against. 

[RKo:>] I don't know what you mean by "tailor made protocol".. PFMIP is
a general-purpose fast handovers protocol for PMIP that provides a)
(uplink, downlink) packet loss, b) context transfer and c) delay
support.

Choosing MH here because a deployment would benefit from it does not
make it "tailor made" for someone, unless I am missing something in your
statement.
The protocol is the same regardless of the transport used.

Also note that no one is asking us to drop ICMP other than ourselves.
 
> I just posted my opinion.

[RKo:>] Okay. Hope above is useful.

-Rajeev

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 17 Sep 2008 10:35:41 -0500

Hi Raj,
 
> If an LS is what you want from PP2, we can ask PP2 to send 
> one to the MIPSHOP WG. 

[Ahmad]
That will be a good idea and helpful. 
At least, we can understand what the SDO need and the reasons for that
choice. 

> Regarding the security discussion, I don't see a concern here 
> (which I believe is what you also conclude).
> 
> The only point that I see is that you are questioning the 
> deployments which drop ICMP messages for whatever reason. 

[Ahmad]
I never said that Raj and if I said that it must have been an accident!
I will be happy to retract that comment. Please point me where did I say
that or where my comment could have been interpreted as such.

Regards,
Ahmad

> Well, deployments and routers may be configured to deal with 
> ICMP messages in case of congestion or other reasons in a 
> specific manner. Additionally ICMP messages may be treated 
> differently in terms of priority and handling in certain 
> cases and if ICMP was used for critical signaling, then it 
> has an impact on handovers. Network planning and deployments 
> cannot be easily changed and hence it is easier to take such 
> messages over 
> >> ICMP or MH types. However there are a couple of issues to consider:
> >> In certain deployments ICMP may face issues depending on 
> how routers 
> >> are configured to handle ICMP messages vs other types.
> > 
> > [Ahmad]
> > But that solution require that interface to be secure and 
> that domain 
> > to have certain security or a trust model, if I may say. 
> The security 
> > FMIP discussion. I believe we have discussed this back and forth 
> > already Raj. :)
> > 
> >> 2. There is a specific interest from at least one SDO in using 
> >> MH-type for HI/HACK messages.
> >> 
> > [Ahmad]
> > recall correctly, this MH optionality was added to the draft before 
> > that draft was referenced by that SDO.
> >  
> >> Is there a down-side to specifying MH-type for HI/HACK? 
> Are MH-types 
> >> a scarce resource? Would this protocol not work if we use 
> MH-types? 
> >> Is there a significant amount of work that needs to be done to 
> >> specify MH-types? I don't see any good reasons to not specify new 
> >> MH-types here.
> > 
> > 
> >> The only argument is that FMIP6 RFC5268 specifies ICMPv6 
> and hence we 
> >> should use the same.
> > 
> > [Ahmad]
> >> I think from a practical perspective, maybe the choice of ICMP for 
> >> HI/HACK in FMIP6 was not right. Whether to change that is 
> a separate 
> >> debate. But in the context of this I-D I don't see any real good 
> >> reason to use ICMP only.
> > 
> > [Ahmad]
> > I have not seen one for MH either; other than being a 
> preference for 
> > an SDO which probably was based on some unfounded and unrelated 
> > argument, which is: some routers may be configured to drop 
> ICMPv6 messages.
> > 
> >> 
> >> -Raj
> >> 
> protocols with

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 17 Sep 2008 10:41:58 -0500

Ahmad,

Inline:

> At least, we can understand what the SDO need and the reasons for that

Okay. I guess official communiques are more convincing than people on this
ML saying so ;)

> that or where my comment could have been interpreted as such.

Quoting you :
"
[Ahmad]
"

I don't know how else to interpret your statement above.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 17 Sep 2008 11:18:08 -0500

Hi Raj,

> >> Regarding the security discussion, I don't see a concern 
> here (which 
> >> I believe is what you also conclude).
> >> 
> deployments 
> >> which drop ICMP messages for whatever reason.
> > 
> > [Ahmad]
> > I will be happy to retract that comment. Please point me 
> where did I 
> > say that or where my comment could have been interpreted as such.
> 
> Quoting you :
> "
> [Ahmad]
> preference for an SDO which probably was based on some 
> unfounded and unrelated argument, which is: some routers may 
> be configured to drop ICMPv6 messages.
> "
> 

[Ahmad]
Hmmmm...

This comment can not be taken out of context Raj:) 
You made the argument in the same posting that ICMP could be dropped. I
responded that those ICMPv6 messages are secure and should not be
impacted, which you later agreed on. This comment in the context of that
discussion.

But If that was interpreted as if I am disputing the fact that some
routers MAY drop ICMPv6 messages for many reasons, then I would like to
say that was not my intention!

Best Regards,
Ahmad

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 24 Sep 2008 14:46:51 -0400

Folks,

The consensus call has concluded. There is consensus on adopting
draft-yokota-mipshop-pfmipv6 as a MIPSHOP WG document.

There is still one open issue on whether we should use ICMPv6-based HI
and HACK messages or define new mobility header based HI and HACK
messages. I was hoping we can reach a conclusion on that. FWIW, I
haven't see enough justification for defining new mobility header based
HI and HACK messages. It looks like we have to continue discussing that.
I will post a follow-up email in a couple of days to try to resolve this
issue.

Vijay

> From: Vijay Devarapalli 
> Sent: Tuesday, September 16, 2008 7:57 AM
> To: Vijay Devarapalli; [email-masked]
> Subject: RE: [Mipshop] Adoption of 
> Just a reminder that the consensus call will be ending soon. 
> Please respond if you haven't so far.
> 
> There is one issue that has been raised during this consensus 
> call. This is on the use of ICMPv6-based HI and HACK messages 
> vs MH-based HI and HACK messages. I would like to hear more 
> opinions on this. Please respond if you haven't already 
> expressed an opinion on this issue.
> 
> Vijay
>