Subject: [netlmm] Some comments on draft-ietf-netlmm-proxymip6-08

From: Bedekar Anand-ABEDEKA1 <[email-masked]>
Date: Fri, 11 Jan 2008 16:53:41 -0600

Sri,

(sorry for the late email here, I have been out of town the
last few weeks)

Some comments that had been discussed earlier in the context
of v07 but don't seem to have been rolled into v08... These
relate to the scenario where MAG indicates a Proxy-CoA
in the PBU (with Alternate CoA option as per RFC3775) that 
is different from the
src address used by the MAG for sending the PBU.

-- Page 44, first line of "Figure 8: Proxy Binding Update
message format" :

Currently says "IPv6 header (src=Proxy-CoA, dst=LMAA)"

Since the src addr of PBU need not be the same as the Proxy 
CoA, it should be changed to
"IPv6 header (src=MAG-addr,dst=LMAA)"

-- Page 22, first line of "Figure 6: Proxy Binding
Acknowledgement message format" :

Currently says " IPv6 header (src=LMAA, dst=Proxy-CoA) "

It should be changed to
"IPv6 header (src=LMAA, dst=src-addr-of-PBU)"

As the second bullet after the Fig. 6 correctly says, "The
Destination Address field in the IPv6 header of the message
MUST be set to the source address of the received Proxy
Binding Update request." In particular, if the Alt-CoA was
used in the PBU to indicate a Proxy CoA different from the 
src addr of
the PBU, the dst addr of the PBA must be set to
the src addr of the PBU, not the Proxy CoA.

-- Page 22, second bullet in "Binding De-Registration:"

"    If the received Proxy Binding Update request with the 
lifetime
       value of zero, has a Source Address in the IPv6 
header different
       from what is present in the Proxy-CoA address field 
in the Binding
       Cache entry existing for that mobile node, the local 
mobility
       anchor MUST ignore the request."

To account for the scenario where the PBU with lifetime zero 
contains the Alt-CoA option, I suggest changing this to:

"    If the received Proxy Binding Update request with the 
lifetime
       value of zero, indicates a Proxy CoA different
       from what is present in the Proxy-CoA address field 
in the Binding
       Cache entry existing for that mobile node, the local 
mobility
       anchor MUST ignore the request."

Thanks,
Anand

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

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 11 Jan 2008 15:24:40 -0800 (PST)

Hi Anand,

When Alt-CoA option is present in the PBU, the considerations
from 3775 apply and I thought we dont have to specify any thing
here. If the option is present in the request, the LMA will
apply the considerations specified for that option. It will
be confusing if we change it in all these places here and
introduce a new term. May be we can add a blanket statement
that if the Alt-CoA option is present, the tunnel endpoint
and the destination address for the signaling messages will
be different. Even if we dont add this, the option properties
should just survive.

Sri

On Fri, 11 Jan 2008, Bedekar Anand-ABEDEKA1 wrote:

> in the PBU (with Alternate CoA option as per RFC3775) that is different from 
> the
> Since the src addr of PBU need not be the same as the Proxy CoA, it should be 
> changed to
> used in the PBU to indicate a Proxy CoA different from the src addr of
> "    If the received Proxy Binding Update request with the lifetime
>      value of zero, has a Source Address in the IPv6 header different
>      from what is present in the Proxy-CoA address field in the Binding
>      Cache entry existing for that mobile node, the local mobility
> To account for the scenario where the PBU with lifetime zero contains the 
> Alt-CoA option, I suggest changing this to:
>
> "    If the received Proxy Binding Update request with the lifetime
>      Cache entry existing for that mobile node, the local mobility

---

From: Bedekar Anand-ABEDEKA1 <[email-masked]>
Date: Fri, 11 Jan 2008 18:09:55 -0600

Hi Sri,

Yes, I agree, we shouldn't need to specify anything new for 
Alt-CoA and 3775 rules should hold. I was just trying to 
point out a couple of specific lines in the current draft 
which, as currently written, seem to contradict the 
operation with Alt-CoA , and am suggesting a relatively 
minor rephrasing to account for the alt-CoA possibility.

Anand

On 1/11/2008 5:24 PM, Sri Gundavelli wrote:
>> in the PBU (with Alternate CoA option as per RFC3775) that is 
>> different from the
>> Since the src addr of PBU need not be the same as the Proxy CoA, it 
>> should be changed to
>> To account for the scenario where the PBU with lifetime zero contains 
>> the Alt-CoA option, I suggest changing this to:
>>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 15 Jan 2008 01:01:29 -0800

> -----Original Message-----
> From: Bedekar Anand-ABEDEKA1 [mailto:[email-masked]] 
> Sent: Friday, January 11, 2008 4:10 PM
> Cc: Netlmm
> Subject: Re: [netlmm] Some comments on draft-ietf-netlmm-proxymip6-08
> 
> Hi Sri,
> 

Hi Anand,

The specified rules are when Alt-CoA option is not present
and that is correct. Any case, see inline comments for
your 3 change suggestions.

> -----Original Message-----
> From: Bedekar Anand-ABEDEKA1 [mailto:[email-masked]] 
> Sent: Friday, January 11, 2008 2:54 PM
> To: Netlmm
> Subject: [netlmm] Some comments on draft-ietf-netlmm-proxymip6-08
> 
> Sri,
> 

Fine.

> "IPv6 header (src=LMAA, dst=src-addr-of-PBU)"

Fine.

>        anchor MUST ignore the request."

Proxy CoA in the request is the source address. You mean from
the Alt-CoA option ? We need to rephrase this slightly.

Hope this helps.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Jan 2008 01:18:45 -0800 (PST)

>> "IPv6 header (src=MAG-addr,dst=LMAA)"

For PBA, Dest = Src Address from PBU appears reasonable, here
we may have to be careful, not to imply the option is always
present or introduce a new term. I think, in the explanation
text below this, we can add a note about Alt-CoA related
difference.

"When Alt-CoA option is present in the PBU, the source address
may be different from Proxy-CoA and is typically the address
configured on the outgoing interface of the MAG".

Sri

---

From: Bedekar Anand-ABEDEKA1 <[email-masked]>
Date: Tue, 15 Jan 2008 10:53:29 -0600

Sri,
Please see below.

> configured on the outgoing interface of the MAG".

[Anand] Ok. Thanks.

---

From: Bedekar Anand-ABEDEKA1 <[email-masked]>
Date: Tue, 15 Jan 2008 10:54:36 -0600

Sri,
Please see below.

Thanks,
Anand

On 1/15/2008 3:01 AM, Sri Gundavelli wrote:
<snip>
> the Alt-CoA option ? We need to rephrase this slightly.

[Anand] Yes, I did mean the Alt-CoA option. I was hoping 
that the wording
"If the received PBU ... indicates a Proxy CoA different 
from what is present in the Proxy CoA address in the BCE..."
captures the situations where Proxy CoA == Source address as 
well as Proxy CoA == Alt CoA.
But if that's not clear, then perhaps something like:

header (or Alt CoA, if the option is used) different

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jan 2008 13:58:43 -0800

>> "IPv6 header (src=LMAA, dst=src-addr-of-PBU)"

Why can't the Proxy Binding Ack be sent to the Proxy CoA?
Presumably the Proxy CoA is configured on the MAG, i.e., it
is one of the addresses of the MAG. I don't think we should
requiring storing yet another address (source address of the
PBU) in the binding cache entry.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 16 Jan 2008 14:09:02 -0800 (PST)

> PBU) in the binding cache entry.

This is not required to be stored in the BCE. Its the response
msg for the request message.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jan 2008 14:18:12 -0800

> msg for the request message.

In a MIPv6 implementation I have worked in the past, there are
times when I lose the reference to the mbuf that had the original
packet when I am about to send a Binding Ack. For example, when
you start a proxy DAD timer after accepting a BU, you come back
to sending a binding ack when the timer expires. So I used the
BCE to construct the binding ack, not the original BU. :)

The point I am trying to make here is that the Proxy CoA is an
address on the MAG. So it should be possible to send the proxy
binding ack to the Proxy CoA irrespective of whether the alt CoA
option was used.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 16 Jan 2008 14:23:58 -0800 (PST)

> binding ack to the Proxy CoA irrespective of whether the alt CoA

Its is technically correct that we send the response to the
source address of the request packet. That address when Alt-CoA
is not present is the Proxy-CoA. So, it is correct to say, we
send it to the Src address of the request as that is the Proxy-CoA,
when Alt-CoA is not present. Comming to implementation part,
the request message should not be lost till the response is
sent, because, not all requests will end up with a BCE. So, you
need that context some where.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jan 2008 14:26:15 -0800

offlist... but in my example, it was success BU, but I had to
wait a bit to send the BAck. So I might not have a reference
to the original packet all the time. :)

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 Jan 2008 00:24:34 -0600

> >> Presumably the Proxy CoA is configured on the MAG, i.e., 
> it is one of 
> >> the addresses of the MAG. I don't think we should 
> requiring storing 
> >> yet another address (source address of the
> > This is not required to be stored in the BCE. Its the 
> response msg for 
> > the request message.
> 
> In a MIPv6 implementation I have worked in the past, there 
> are times when I lose the reference to the mbuf that had the 
> original packet when I am about to send a Binding Ack. For 
> example, when you start a proxy DAD timer after accepting a 
> BU, you come back to sending a binding ack when the timer 
> expires. So I used the BCE to construct the binding ack, not 
> the original BU. :)

[Ahmad]
Vijay,

I see your point with respect to MIPv6. It makes a lot of sense.
Although, I could not think of a similar scenario in PMIPv6 but that
does not mean that there is not possibly one. Bottom line, I agree. I
basically do not see why we SHOULD NOT allow the LMA to send BA to the
Proxy CoA which is already saved in the BCE. 

On the other hand, if we allow this, we probably need to mention
something about the SPD @ MAG to allow receiving BA destined to the
Proxy CoA.

Regards,
Ahmad 

> 
> The point I am trying to make here is that the Proxy CoA is 
> an address on the MAG. So it should be possible to send the 
> proxy binding ack to the Proxy CoA irrespective of whether 
> the alt CoA option was used.
> 
> Vijay
> 
> > 
> > Sri
> 
> 
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 16 Jan 2008 22:50:33 -0800

> Proxy CoA which is already saved in the BCE. 

Hi Ahmad,

There is some confusion here. 

For PBA destination, We can say: 

a.) it should be sent to Proxy-CoA
b.) it should be sent to the src address of the PBU.

If we use the language per #b, it works for Alt-CoA option as well. It
does not mean "SHOULD NOT allow the LMA to send PBA to the Proxy CoA". 
Does it ????? When Alt-CoA option is not there, both are the same.

> something about the SPD @ MAG to allow receiving BA destined to the

Not sure I understand. Can you clarify.

Bottom line, the change is to ensure the language does not prevent
supporting Alt-CoA option, as requested by Anand. There is no point
in explicitly blocking Alt-CoA option, the option is valid for MIP6
and is valid for PMIP6, we say it or not. Let me know, if you are
suggesting, explicitly preventing Alt-CoA option usage here ?

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 Jan 2008 01:18:06 -0600

> If we use the language per #b, it works for Alt-CoA option as 
> well. It does not mean "SHOULD NOT allow the LMA to send PBA 
> to the Proxy CoA". 
> Does it ????? 

[Ahmad]
Hi Sri,

If that the case then it is fine. However, I think I read that you
suggested the change of the dst address in one of the examples from
Proxy CoA to BU Src. Address. I think being more explicit by capturing
an explanation of #b is not a bad idea. It would be clearer and helpful
to implementers.

> When Alt-CoA option is not there, both are the same.

[Ahmad]
Ok.

> Not sure I understand. Can you clarify.

[Ahmad]
I guess what I had in mind is that if a MAG does not use the Alt-CoA for
all Proxy BU for all MNs with a certain LMA, then we end up with a
possibility of the BA been sent by the same LMA to two of the MAG
different Addresses. If that is the case, then we need to make sure that
the MAG SPD is able to handle that. Hope this clarify my initial
comment.

> 
> Bottom line, the change is to ensure the language does not 
> prevent supporting Alt-CoA option, as requested by Anand. 
> There is no point in explicitly blocking Alt-CoA option, the 
> option is valid for MIP6 and is valid for PMIP6, we say it or 
> not. Let me know, if you are suggesting, explicitly 
> preventing Alt-CoA option usage here ?

[Ahmad]
No, that was not my intention.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 16 Jan 2008 23:21:54 -0800

Hi Ahmad,

Ok. Thanks. Its just the wording, to ensure we dont
prevent Alt-CoA option.

Thanks
Sri

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2008 11:18 PM
> To: Sri Gundavelli; Vijay Devarapalli
> Cc: Bedekar Anand-ABEDEKA1; Netlmm
> Subject: RE: [netlmm] Some comments on draft-ietf-netlmm-proxymip6-08
> 
> > Hi Ahmad,
> > 
> >