Subject: Re: [Mipshop] Adoption of draft-yokota-mipshop-pfmipv6 asaWG document

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 4 Sep 2008 13:35:31 -0400

Hi Vijay,

Even though we could argue that ICMP is sufficient, I think there is a
case for MH here. As Yokota-san pointed out, PMIP deployments, where
this protocol is expected to be used, do use MH and having the same
format for PFMIP messages makes sense. So, I would say we need to
support MH type based on the anticipated deployment considerations. What
this means is getting Type definitions, the message format and
processing is exactly the same as in RFC 5268.

See more below..

> We are not talking about a regular router here. It is a PMIPv6 MAG
that
> is processing these HI and HACK messages.

[RKo:>] Nevertheless, deployments could argue that they should not be
forced to make this choice: They are okay if we define both ICMP and MH.
Looks like you are arguing that we have to have only one type. More on
this below..

> Hmm.. We have used ICMPv6 messages quite a bit for mobility protocols
in
> the IETF. For example, DHAAD messages, Mobile Prefix
> solicitations/Advertisements for MIPv6, HI and HACK in FMIPv6 [RFC
> 5268], Context Transfer protocol messages [RFC 4067], etc..

[RKo:>] Right. But we don't have any deployment experience say in an
operator network, do we? (Granted PMIP is not yet deployed, but the
request for MH type is coming from the same anticipated deployment
environments where PMIP is going to be deployed)
  
> We have to pick between the MH-based and ICMPv6-based HI and HACK
> messages. Specifying both only causes confusion and IOT problems.
> 

[RKo:>] This is moot! We should not underestimate industry's
intelligence.  3GPP2 spec X.P0057 relies on this PFMIP draft, and yet
they clearly indicated they will use MH. They did not say remove ICMP. 

So, if you think we should use ICMP, I am all for it. But, we also need
to include MH, for sure. I cannot understand the rationale here that *we
will not* support what a deployment of this protocol is requesting.
Sigh..

-Rajeev

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

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 4 Sep 2008 13:45:59 -0400

Hi Rajeev,

I was specifically responding to a couple of arguments in Yokota-san's
email. One was about routers not processing ICMPv6 messages and the
second was about ICMPv6 message being not suited for mobility signaling.
I don't think either of these two arguments are valid.  

The rest of the arguments presented by Yokota-san might be valid. We
need to discuss those on the mailing list. 

Without the working group chair hat on, I don't think we should specify
additional messages just because someone prefers MH-based HI and HACK
messages. This includes 3GPP2 as an SDO. There have to be good reasons
for specifying these new messages.

Vijay

> -----Original Message-----
> From: Koodli, Rajeev [mailto:[email-masked]] 
> Sent: Thursday, September 04, 2008 10:36 AM
> To: Vijay Devarapalli; Hidetoshi Yokota; Charles E. Perkins
> Cc: [email-masked]; Jari Arkko
> Subject: RE: [Mipshop] Adoption of 
> draft-yokota-mipshop-pfmipv6 asaWG document
> 
> 
> Hi Vijay,
> 
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 4 Sep 2008 14:05:24 -0400

Hi,

> I don't think either of these two arguments are valid.

[RKo:>] I do not see any deployment today where the DHAAD, Mobile Prefix
Sol/Adv, 5268 are being used. So, whereas we have defined them, we don't
have any feedback. As I said, where PMIP is being envisioned, I can see
why those deployments favor MH as opposed to ICMP.

> need to discuss those on the mailing list.

[RKo:>] We are doing that already :-)

> for specifying these new messages.

[RKo:>] Does a deployment count? I hope it does. It used to be that we
used to listen to such things..

So, what's at stake here? Inclusion of MH type for the reasons I cited
in the previous message (coherence with PMIP deployments). It does not
mean removal of ICMP. I am having a hard time understanding this
"one-size fits all", especially considering that the motivation is from
a deployment consideration.

I don't buy this IOT argument if we do enlist MH Types in addition to
ICMP.

If you insist on a single Type, I am even willing to go with it,
specifying MH since that's the clear case. I think not supporting MH is
like ignoring what a deployment would need; I would like to avoid that.

-Rajeev

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 4 Sep 2008 14:19:37 -0400

> why those deployments favor MH as opposed to ICMP.

Both MIPv6 and PMIPv6 are being considered for deployment only now. So
its true that we haven't seen any so far. But who has deployed PFMIPv6?
:) It's the same with PFMIPv6 too.

> [RKo:>] We are doing that already :-)

That's good. But, as WG chair, I want folks to focus on the real
arguments, for example, the one that argues for MH-based HI and HACK,
because the rest of the PMIPv6 messages that affect the operation of the
MAG are all MH-based. Not on arguments like routers don't process ICMPv6
messages and ICMPv6 not being suited for mobility signaling. First of
all we are not talking about regular routers. These are PMIPv6 MAGs. It
is also not entirely correct that routers don't process ICMPv6 messages.
Finally we have used ICMPv6 messages quite a bit in the IETF for
mobility protocols. 

> used to listen to such things..

On the contrary, we have a problem. I see many WG charters being driven
by SDOs. :) We are listening to them way too much, IMHO. 

Vijay

> > > Even though we could argue that ICMP is sufficient, I 
> think there is
> a
> > > Looks like you are arguing that we have to have only one 
> type. More
> on
> > > this below..
> > >

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Sep 2008 12:08:31 -0700 (PDT)

Hi Vijay,
  In our version of PFMIPv6 protocol at:
http://tools.ietf.org/id/draft-xia-netlmm-fmip-mnagno-02.txt
we have this statement

All the messages between PMAG and NMAG are ICMPv6 messages and are as
   defined in RFC5268.Kind regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>; Hidetoshi Yokota <[email-masked]>; Charles E. Perkins <[email-masked]>
Cc: [email-masked]; Jari Arkko <[email-masked]>
Sent: Thursday, September 4, 2008 1:19:37 PM
Subject: Re: [Mipshop] Adoption of draft-yokota-mipshop-pfmipv6 asaWG document

Vijay

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 4 Sep 2008 14:35:40 -0400

> :) It's the same with PFMIPv6 too.

[RKo:>] Did I say PFMIPv6 is deployed? I did not.. I only said in the
anticipated deployment of PMIP, PFMIP is being specified for deployment
(in GW - GW handovers).

> Finally we have used ICMPv6 messages quite a bit in the IETF for

[RKo:>] Agree. (I am not against ICMP, surely. I also want to listen to
practical concerns)
 
> by SDOs. :) We are listening to them way too much, IMHO.

[RKo:>] That does not mean that you respond by using the same hammer for
all cases at hand :-) 

Between a) listening to nothing but SDOs, and b) completely shutting off
any input from the ground, there surely is a middle ground, isn't it?
Specifically, here the argument is for the coherence of PMIP and PFMIP
in the common deployment scenarios envisioned. That makes sense as
input..

-Rajeev

> > > > [RKo:>] Nevertheless, deployments could argue that they should
not
> > be
> > > > intelligence.  3GPP2 spec X.P0057 relies on this PFMIP draft,
and
> > yet