Subject: [MEXT] FW: [netlmm] comment ondraft-ietf-mext-binding-revocation-01

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 10 Oct 2008 08:08:29 -0500

**** Adding Mext mailing list. Also correcting the subject. Comment is
on binding revocation not GRE:) ***

Hi Domagoj,

I believe this is a valid concern. I guess either way should work, but I
believe the cleaner solution is to have some text to indicate that if
the alt-CoA included in the PBU, the revocation should be sent to the
same address the PBA is sent to. In this case the source of the PBU.

If people feels that is the best approach, we can add some clarification
to the draft.

What do you think?

Regards,
Ahmad

> -----Original Message-----
> From: Premec, Domagoj [mailto:[email-masked]]
> Sent: Friday, October 10, 2008 7:59 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Netlmm
> Subject: comment on draft-ietf-netlmm-grekey-option-01
> 
> Hi Ahmad,
> 
> I have a comment on the interactions between the binding revocation 
> mechanism and the alt-CoA usage as specified in RFC 5213. According to

> the RFC 5213, the MAG is allowed to use the alt-CoA to redirect the 
> downlink traffic to an address different from the source address of 
> the PBU. In this case the Binding revocation will get sent to the 
> alt-CoA address, but I think it should actually be sent to the source 
> address of the PBU, as this is where the signalling part of the MAG is

> located. Is this is a valid concern or should we assume that the MAG 
> also accepts signalling messages at the alt-CoA?
> 
> domagoj
> 
> 
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 10 Oct 2008 17:30:19 -0400

Hi Domagoj, Ahmad,

In MIPv6, if the binding update is successful, the binding ack is always
sent to the CoA and not to the source address of the BU. If the AltCoA
option is used, then the binding ack would go back to the address that
appeared in the AltCoA option. 

In PMIPv6, I don't believe there is a scenario where you would want to
use the AltCoA option. (if someone has a valid scenario, please let me
know).

> same address the PBA is sent to. In this case the source of the PBU.

*If* the AltCoA option is used, then the address that appears in the
AltCoA option would be stored as the proxy CoA in the binding cache
entry. When a binding revocation needs to be sent, it would be sent to
the proxy CoA in the binding cache entry. For the binding revocation
document, I think it is sufficient to say that the revocation message is
sent to the Proxy CoA. It shouldn't say anything about the source
address of the PBU or the address in the AltCoA option. In other words,
the binding revocation document should not care about the use of AltCoA
option.

Vijay

> 
> If people feels that is the best approach, we can add some
> clarification to the draft.
> 
> What do you think?
> 
> Regards,
> Ahmad
> 
>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 13 Oct 2008 13:00:10 +0200

Hi Vijay,

RFC 5213 mentiones the usage of alt-CoA at several places, for example:

      However, when there is an Alternate Care-of Address option present
      in the request, this address will be not be considered as the
      Proxy-CoA, but the address in the Alternate Care-of Address option
      will be considered as the Proxy-CoA. 

I thought that the scenario in mind here is the MAG with one control plane blade and several data plane blades, and the alt-CoA would contain the address of the data plane.

domagoj

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 10. listopad 2008 23:30
> To: Ahmad Muhanna; Premec, Domagoj
> Cc: Netlmm; [email-masked]
> Subject: RE: [netlmm] FW: comment 
> ondraft-ietf-mext-binding-revocation-01
> 
> Hi Domagoj, Ahmad,
> 
> In MIPv6, if the binding update is successful, the binding 
> ack is always sent to the CoA and not to the source address 
> of the BU. If the AltCoA option is used, then the binding ack 
> would go back to the address that appeared in the AltCoA option. 
> 
> In PMIPv6, I don't believe there is a scenario where you 
> would want to use the AltCoA option. (if someone has a valid 
> scenario, please let me know).
> 
> > I believe this is a valid concern. I guess either way 
> should work, but 
> > I believe the cleaner solution is to have some text to 
> indicate that 
> > if the alt-CoA included in the PBU, the revocation should 
> be sent to 
> > the same address the PBA is sent to. In this case the source of the 
> > PBU.
> 
> *If* the AltCoA option is used, then the address that appears 
> in the AltCoA option would be stored as the proxy CoA in the 
> binding cache entry. When a binding revocation needs to be 
> sent, it would be sent to the proxy CoA in the binding cache 
> entry. For the binding revocation document, I think it is 
> sufficient to say that the revocation message is sent to the 
> Proxy CoA. It shouldn't say anything about the source address 
> of the PBU or the address in the AltCoA option. In other 
> words, the binding revocation document should not care about 
> the use of AltCoA option.
> 
> Vijay
> 
> > 
> >> mechanism and the alt-CoA usage as specified in RFC 5213. 
> According 
> >> to
> > 
> >> address of the PBU, as this is where the signalling part 
> of the MAG 
> >> is
> >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 13 Oct 2008 14:09:57 -0400

Premec, Domagoj wrote:
> I thought that the scenario in mind here is the MAG with one
> control plane blade and several data plane blades, and the
> alt-CoA would contain the address of the data plane.

First of all, RFC 5213 did not extend the binding cache entry structure
to store both the control plane and data plane addresses. RFC 5213 does
not specify that the LMA should store both the source address of the PBU
and the address in the altCoA option in the binding cache. There is only
one address - the Proxy CoA, that is stored in the binding cache entry.
So trying to send the binding revocation indication message to any other
address, other than what is stored in the binding cache (Proxy CoA), may
not work. 

Secondly, the above scenario is not realistic, IMHO. The different IP
addresses for the control plane blade and the multiple data plane blades
is typically not exposed to the other network elements. Each blade
acting as a separate MAG is of course possible, but that is not relevant
to what we are talking about here.

Vijay

>>> **** Adding Mext mailing list. Also correcting the subject. Comment
>>> is on binding revocation not GRE:) ***
>>> 
>>> Hi Domagoj,
>>> 
>>> I believe this is a valid concern. I guess either way should work,
>>> but I believe the cleaner solution is to have some text to indicate
>>> that if the alt-CoA included in the PBU, the revocation should be
>>> sent to the same address the PBA is sent to. In this case the
>>> source of the PBU.
>> 
>> words, the binding revocation document should not care about the use
>> of AltCoA option. 
>> 
>> Vijay
>> 
>>> 
>>>> alt-CoA address, but I think it should actually be sent to the
>>>> source address of the PBU, as this is where the signalling part of
>>>> the MAG is
>>> 
>>>> located. Is this is a valid concern or should we assume that the
>>>> MAG also accepts signalling messages at the alt-CoA?
>>>> 
>>>> domagoj
>>>> 
>>>>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 14 Oct 2008 10:49:52 +0200

Vijay,

> First of all, RFC 5213 did not extend the binding cache entry 
> structure to store both the control plane and data plane 
> addresses. RFC 5213 does not specify that the LMA should 
> store both the source address of the PBU and the address in 
> the altCoA option in the binding cache.

This is not a problem from the perspective of RFC 5213 as the LMA does not send unsolicited messages to the MAG. In the context of RFC 5213 there is no need to store both the alt-CoA and the source IP of the PBU in the BCE, so I wouldn't expect RFC 5213 to specify any extensions to the BCE in this regard.

> Secondly, the above scenario is not realistic, IMHO. The 
> different IP addresses for the control plane blade and the 
> multiple data plane blades is typically not exposed to the 
> other network elements.

Well.. different designs are possible. I'm not going to argue that my interpretation of the intended alt-CoA usage is right. In fact, if I'm right then the mechanims for the other direction is missing (e.g. alt-CoA in PBAck) and we'd need to do something about it as this other direction is more important since the LMA has to deal with more load then the MAG.

So if I agree with you, then I'm confused about the purpose of the alt-CoA in the RFC 5213, what is the usage for it?

domagoj

> Sent: 13. listopad 2008 20:10
> To: Premec, Domagoj; Ahmad Muhanna
> > I thought that the scenario in mind here is the MAG with 
> one control 
> > plane blade and several data plane blades, and the alt-CoA would 
> > contain the address of the data plane.
> 
> First of all, RFC 5213 did not extend the binding cache entry 
> structure to store both the control plane and data plane 
> addresses. RFC 5213 does not specify that the LMA should 
> store both the source address of the PBU and the address in 
> the altCoA option in the binding cache. There is only one 
> address - the Proxy CoA, that is stored in the binding cache entry.
> So trying to send the binding revocation indication message 
> to any other address, other than what is stored in the 
> binding cache (Proxy CoA), may not work. 
> 
> Secondly, the above scenario is not realistic, IMHO. The 
> different IP addresses for the control plane blade and the 
> multiple data plane blades is typically not exposed to the 
> other network elements. Each blade acting as a separate MAG 
> is of course possible, but that is not relevant to what we 
> are talking about here.
> 
> Vijay
> 
> 
> 
> > 
> > domagoj
> > 
> > 
> >> In MIPv6, if the binding update is successful, the binding ack is 
> >> always sent to the CoA and not to the source address of the BU. If 
> >> the AltCoA option is used, then the binding ack would go 
> back to the 
> >> address that appeared in the AltCoA option.
> >> 
> would want 
> >> to use the AltCoA option. (if someone has a valid scenario, please 
> >> let me know).
> >> 
> should work, 
> >>> sent to the same address the PBA is sent to. In this case 
> the source 
> >>> of the PBU.
> >> 
> >> entry. When a binding revocation needs to be sent, it 
> would be sent 
> >> to the proxy CoA in the binding cache entry. For the binding 
> >> revocation document, I think it is sufficient to say that the 
> >> revocation message is sent to the Proxy CoA. It shouldn't say 
> >> anything about the source address of the PBU or the address in the 
> >> AltCoA option. In other words, the binding revocation 
> document should 
> >> not care about the use of AltCoA option.
> >> 
> >> Vijay
> >> 
> >>> 
> >>>> mechanism and the alt-CoA usage as specified in RFC 
> 5213. According 
> >>>> to
> >>>

---

From: Wang Yungui <[email-masked]>
Date: Wed, 15 Oct 2008 09:25:30 +0800

Hello Domagoj

Please see inline.

----- Original Message ----- 
From: "Premec, Domagoj" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; "Ahmad
Muhanna" <[email-masked]>
Cc: "Netlmm" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 14, 2008 4:49 PM
Subject: Re: [MEXT] [netlmm] FW: comment
ondraft-ietf-mext-binding-revocation-01

> This is not a problem from the perspective of RFC 5213 as
> the LMA does not send unsolicited messages to the MAG. In
> the context of RFC 5213 there is no need to store both the
> alt-CoA and the source IP of the PBU in the BCE, so I
> wouldn't expect RFC 5213 to specify any extensions to the
> BCE in this regard.
>
[Yungui] The LMA may send the unsolicited messages to the
MAG, such as heartbeat request message introduced in
draft-ietf-netlmm-pmipv6-heartbeat-00.txt.
However, I agree with Vijay's opinion in the last mail,
"...In other words, the binding revocation document should
not care about the use of AltCoA option."
It's okey to make the binding revocation document comply 
with
RFC3775 and RFC5213.

In fact, in RFC3775, section 9.5.4. Sending Binding
Acknowledgements, is described:
" ...If the Source Address field of the IPv6 header that
carried the Binding Update does not contain a unicast
address, the Binding Acknowledgement MUST NOT be sent and
the Binding Update packet MUST be silently discarded.
Otherwise, the acknowledgement MUST be sent to the Source
Address."
In RFC5213, there are some similiar description for PBA
(section 5.3.6).
Therefore, it seems the source address should be saved in
the BCE.

B.R.
Yungui

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Oct 2008 22:07:39 -0700

On 10/14/08 1:49 AM, "Premec, Domagoj" <[email-masked]> wrote:

> This is not a problem from the perspective of RFC 5213 as the LMA does not
> send unsolicited messages to the MAG.

Well, one could use the HA Switch mechanism (RFC 5142) for the LMA to
re-direct the MAG to another LMA.

> In the context of RFC 5213 there is no
> need to store both the alt-CoA and the source IP of the PBU in the BCE, so I
> wouldn't expect RFC 5213 to specify any extensions to the BCE in this regard.
> 
> Well.. different designs are possible. I'm not going to argue that my
> interpretation of the intended alt-CoA usage is right. In fact, if I'm right
> then the mechanims for the other direction is missing (e.g. alt-CoA in PBAck)
> and we'd need to do something about it as this other direction is more
> important since the LMA has to deal with more load then the MAG.
> 

Coming back the discussion we were having, I think it is sufficient for the
binding revocation document to say that the binding revocation indication
message should be sent to the Proxy CoA.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 15 Oct 2008 18:58:46 +0300

Vijay,

> appeared in the AltCoA option.

That's interesting. Is there a technical reason why BA cannot be sent back
to the source address of the BU (other than not being specified so in RFC
3775)?

Mirroring the src/dst IP addresses between BU/BA appears logical, simple,
and useful. Not sure why it is not explicitly allowed in the RFC 3775.

> use the AltCoA option. (if someone has a valid scenario, please let me

Sending and receiving PMIP signaling using Alt-CoA provides the ability to
separate control plane and data plane. And that's useful for relocating the
PMIP6 tunnel while keeping the PMIP6 signaling anchored on a fixed MAG
(because moving that requires re-negotiation of security-related
parameters). 

This scenario is being examined by WiMAX Forum and use of Alt-CoA appears to
fit (module some wrinkles and clarifications).

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 15 Oct 2008 10:18:58 -0700

> fit (module some wrinkles and clarifications).

IMO, a clean solution for this would to define a new mobility option 
called the Data Plane Address option. When the LMA encounters the Data 
Plane Address option, it uses the address stored in that as the tunnel 
end point for data packets. The source address of the Proxy Binding 
Update would still be considered as the Proxy CoA and used for all 
control plane packets (Proxy Binding Ack, HA/LMA Switch Message and 
Binding Revocation Indication Message).

I think such an extension would be simple enough that we can standardize 
it quickly.

Trying to do the above with the AltCoA option, IMO, is a misuse of the 
AltCoA option. AltCoA option by definition is supposed to over ride the 
source address of the BU/PBU and be treated as the CoA/Proxy CoA.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 15 Oct 2008 23:31:33 +0300

Vijay,

> always

If I'm understanding you right, you are saying first the source address of
the BU is overwritten by Alt-CoA, and then the MIP6 implementation picks up
the "CoA" from that source address, and for that MIP6 does not even know the
original source address to respond to.... Are you referring to some specific
implementation or the standard? I'd like to understand the technical reason
for such implementation.

Also, see the below text from RFC 3775:

   Normally, a Binding Update specifies the desired care-of address in
   the Source Address field of the IPv6 header.  However, this is not
   possible in some cases, such as when the mobile node wishes to
   indicate a care-of address which it cannot use as a topologically
   correct source address (Section 6.1.7 and Section 11.7.2) or when the
   used security mechanism does not protect the IPv6 header (Section
   11.7.1).

If the reason is topological, how do you expect the MN to receive the BA
sent to such topologically-incorrect IP address if HA sends the response
back to the Alt-CoA, as opposed to the source address of the BU? 

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 15 Oct 2008 22:05:45 -0700

Hi Alper,

> back to the Alt-CoA, as opposed to the source address of the BU?

If you continue along with this reasoning, then the MN won't receive any
data packets that the HA tunnels to the topologically incorrect IP address
either. So the HA can't use the topologically incorrect IP address for both
the Binding Ack messages and for regular data traffic. So what was the point
in the MN sending this address to the HA in the AltCoA option?

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 16 Oct 2008 13:02:19 +0300

> in the MN sending this address to the HA in the AltCoA option?

The path followed by BU/BA does not have to be same as the path followed by
the HA-MN tunnel. That separation is possible with the use of Alt-CoA where
Alt-CoA dictates only the tunnel end-point on the MN side (not the
destination IP address of the BA).

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 16 Oct 2008 11:27:43 -0700

Hi Alper,

> destination IP address of the BA).

But if the MN is binding an address that it can't receive regular 
traffic at, then something is broken right? The BU/BAck exchange might 
succeed, but the MN is not able to receive any traffic that is sent for 
its home address. The Home Agent would be tunneling to the care-of address.

Lets step back a bit. The discussion started off with us trying to 
figure out where the binding revocation should be sent. RFC 3775 does 
not require the home agent to store the source address on the binding 
update if the source address does not match the address in the AltCoA 
option. There is only one address - the care-of address, stored in the 
binding cache entry. And the care-of address comes from the AltCoA 
option, if it is present. Data traffic and subsequent signaling messages 
initiated by the Home Agent would be sent to this care-of address.

The source address on the original BU might not even be valid anymore.

Then we started talking about the Home Agent/LMA being able to store two 
separate addresses, one for the control plane and one for the data 
plane, I think  defining a new mobility option to carry the data plane 
address is the cleanest solution.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 17 Oct 2008 01:04:15 +0300

> traffic at, then something is broken right? 

I'll give you an example:

Consider an MN with two IP addresses: IP1 on if1, IP2 on if2.

IP2 is identified as CoA by the MN.
But for some reason, MN needs to send the BU out of if1. So, BU's source
address is set to IP1, Alt-CoA is set to IP2.

BA is sent back to IP1 and received on if1.

Tunneled packets are sent to IP2 and received on if2.

Everything is fine.

Alper

The BU/BAck exchange might

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 16 Oct 2008 15:57:16 -0700

> Tunneled packets are sent to IP2 and received on if2.

This would work.

In an earlier email, you had said IP2 is a topologically incorrect 
address and the MN is not able to receive packets at IP2.

Note that only IP2 will be stored in the binding cache entry. IP1 will 
not be stored. So IP1 would not be available for sending a binding 
revocation message later on. Even if the HA stores IP1, it might not be 
valid later on (i.e., the MN might not be reachable on IP1 later).

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 17 Oct 2008 11:25:00 +0300

> address and the MN is not able to receive packets at IP2.

Yes, there exist such scenarios. My above scenario is not one of them
because both interfaces are "up at the same time on the same MN".

Now remember the other scenario where one MAG is in charge of control
signaling (PBU/PBA) and the other in charge of being tunnel end-point. 

> not be stored. 

You are saying this because RFC 3775 does not state that source IP address
of the last received BU shall be stored. I think this is a bug in the light
of the following statement (at the least):

   If the Source Address field of the IPv6 header that carried the
   Binding Update does not contain a unicast address, the Binding
   Acknowledgement MUST NOT be sent and the Binding Update packet MUST
   be silently discarded.  Otherwise, the acknowledgement MUST be sent
   to the Source Address.

If we agree that the BA/PBA should be sent back to the source address of the
BA/PBA then the fix is simple.

> So IP1 would not be available for sending a binding

If the MN changes its point of attachment, then it is MN's responsibility to
notify the HA if it wants to receive revocation messages.

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 19 Oct 2008 21:11:36 -0700

> of the following statement (at the least):

No it is not. See below.

>    be silently discarded.  Otherwise, the acknowledgement MUST be sent

When you are responding to the BU, the context associated with the BU is 
still available when you construct the BAck message. The above statement 
cannot be read as if it indicates that the source address is stored. :)

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 20 Oct 2008 10:21:01 +0300

Vijay,

> cannot be read as if it indicates that the source address is stored. :)

Certainly "stored" at least for the duration of the "BU processing". In
other words, it is not blindly tossed away. I acknowledge that it does not
mean the address gets stored for an extended period of time. 

I couldn't trace back where the RFC said what you said "the binding ack is
always sent to the CoA and not to the source address of the BU. If the
AltCoA option is used, then the binding ack would go back to the address
that appeared in the AltCoA option." Wherever it is, it is in direct
conflict (a BUG) with the text quoted above. Don't you think so?

Alper

---

From: Brian Haley <[email-masked]>
Date: Mon, 20 Oct 2008 09:49:13 -0400

Hi Alper,

> mean the address gets stored for an extended period of time.

Yes, the BU is typically tossed away once the data in it is copied out. 
  In the typical case where a HA receives a BU and has to do DAD for the 
address, it can't save the BU since the buffer needs to be released back 
to the system.

> conflict (a BUG) with the text quoted above. Don't you think so?

Looking at what I implemented I would have to agree with Alper, I always 
send the BAck to the source address, so unless the TAHI tests have 
changed recently (they haven't) that's probably the correct behavior. 
Alper quoted the text above from Section 9.5.4.  The CoA is going to be 
used for the remote tunnel end-point, so it's specifying where future 
packets should be sent.

-Brian

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 20 Oct 2008 17:18:14 +0200

Hi Alper,

I agree with others here that the source IP of the BU is available during the BU/Back transaction processing and once the transaction is completed,  the source IP of the BU is gone. IMO if we want the source IP of the BU to be saved in the BCE, this must be specified in some RFC.

domagoj

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Haley
> Sent: 20. listopad 2008 15:49
> To: Alper Yegin
> Cc: 'Netlmm'; [email-masked]
> Subject: Re: [netlmm] [MEXT] Alt-CoA and PMIP6 (was RE: 
> FW:comment ondraft-ietf-mext-binding-revocation-01)
> 
> Hi Alper,
> 
> Alper Yegin wrote:
> > Vijay,
> > 
> >>>  > Note that only IP2 will be stored in the binding cache 
> entry. IP1
> >> will
> >>>  > not be stored.
> >>>
> >>> of the last received BU shall be stored. I think this is a bug in 
> >>> the
> >> light
> >> When you are responding to the BU, the context associated 
> with the BU 
> >> is still available when you construct the BAck message. The above 
> >> statement cannot be read as if it indicates that the 
> source address 
> >> is stored. :)
> > 
> > Certainly "stored" at least for the duration of the "BU 
> processing". 
> > In other words, it is not blindly tossed away. I 
> acknowledge that it 
> > does not mean the address gets stored for an extended 
> period of time.
> 
>   In the typical case where a HA receives a BU and has to do 
> DAD for the address, it can't save the BU since the buffer 
> needs to be released back to the system.
> 
> > I couldn't trace back where the RFC said what you said "the binding 
> of the BU. 
> > If the AltCoA option is used, then the binding ack would go back to 
> > the address that appeared in the AltCoA option." Wherever 
> it is, it is 
> > in direct conflict (a BUG) with the text quoted above. 
> Don't you think so?
> 
> Looking at what I implemented I would have to agree with 
> Alper, I always send the BAck to the source address, so 
> unless the TAHI tests have changed recently (they haven't) 
> that's probably the correct behavior. 
> Alper quoted the text above from Section 9.5.4.  The CoA is 
> going to be used for the remote tunnel end-point, so it's 
> specifying where future packets should be sent.
> 
> -Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 20 Oct 2008 10:27:37 -0700

> mean the address gets stored for an extended period of time. 

Ok

> conflict (a BUG) with the text quoted above. Don't you think so?

I am not sure. This should perhaps be clarified in 3775bis. Practically 
thinking, the MN should be able to receive the binding ack irrespective 
of whether it was sent to the source address on the BU or to the address 
in the AltCoA option. It should be perfectly valid for a HA 
implementation to send a Binding Ack to the CoA always.

The FBU message in the predictive mode of FMIPv6 is the only scenario 
that I know of when the MN sends a BU with the source address being 
different from the contents of the AltCoA option. In FMIPv6, the 
previous access router sends an FBACK to both the oldCoA and the newCoA.

BTW, I am planning to submit a draft on the Data Plane Address mobility 
option, for separation of control and data plane, before the draft 
submission deadline. Let me know if you are interested in contributing.

Vijay

---

From: Brian Haley <[email-masked]>
Date: Mon, 20 Oct 2008 13:52:31 -0400

> I agree with others here that the source IP of the BU is available during the BU/Back transaction processing and once the transaction is completed,  the source IP of the BU is gone. IMO if we want…

I agree that we don't need the source address once we send the BAck, 
just the CoA, which is usually the source address.  But I don't think we 
need to specify if the address is saved in the conceptual data structure 
mentioned in 3775, implementations are free to store additional 
information in a BCE if they wish, and most do.  If some new draft needs 
the original source address saved, then it should specify it.  Maybe 
that's what you meant and I mis-understood?

-Brian

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 21 Oct 2008 01:28:24 -0700

Vijay,

> implementation to send a Binding Ack to the CoA always.

As Brian said that's not the case for TAHI-tested implementations.
Besides, according to the following RFC 3775 text, the destination address
of BA "MUST be" copied from the source address of BU. The text is clear.

> submission deadline. Let me know if you are interested in contributing.

I still think use of Alt-CoA already accomplishes that and no additional
spec is needed. Thank you nevertheless.

Alper

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 21 Oct 2008 00:43:51 +0200

Brian,

> If some new draft needs the 
> original source address saved, then it should specify it.  
> Maybe that's what you meant and I mis-understood?

Yes, that was my point. The original question in this thread was "where is the Binding revocation sent to if the PBU contained alt-CoA", and one option would be to specify in the Binding revocation draft that the alt-CoA must be saved in the BCE.

domagoj

> From: Brian Haley [mailto:[email-masked]] 
> Sent: 20. listopad 2008 19:53
> To: Premec, Domagoj
> Cc: Alper Yegin; Netlmm; [email-masked]
> > I agree with others here that the source IP of the BU is 
> available during the BU/Back transaction processing and once 
> the transaction is completed,  the source IP of the BU is 
> gone. IMO if we want the source IP of the BU to be saved in 
> the BCE, this must be specified in some RFC.
> 
> I agree that we don't need the source address once we send 
> the BAck, just the CoA, which is usually the source address.  
> But I don't think we need to specify if the address is saved 
> in the conceptual data structure mentioned in 3775, 
> implementations are free to store additional information in a 
> BCE if they wish, and most do.  If some new draft needs the 
> original source address saved, then it should specify it.  
> Maybe that's what you meant and I mis-understood?
> 
> -Brian
>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 21 Oct 2008 00:52:18 +0200

> > BTW, I am planning to submit a draft on the Data Plane Address 
> > mobility option, for separation of control and data plane, 
> before the 
> > draft submission deadline. Let me know if you are 
> interested in contributing.
> 
> I still think use of Alt-CoA already accomplishes that and no 
> additional spec is needed. Thank you nevertheless.

The alt-CoA works only in one direction,  MAG->LMA. If the LMA has several blades and would like to load balance between them, we need to specify how this is done in the other direction, too. 

domagoj

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: 21. listopad 2008 10:28
> To: 'Vijay Devarapalli'
> Cc: 'Ahmad Muhanna'; Premec, Domagoj; 'Netlmm'; [email-masked]
> Subject: RE: Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment 
> ondraft-ietf-mext-binding-revocation-01)
> 
> Vijay,
> 
> > > ack
> > > address that appeared in the AltCoA option." Wherever it 
> is, it is 
> > I am not sure. This should perhaps be clarified in 3775bis. 
> > Practically thinking, the MN should be able to receive the 
> binding ack 
> > irrespective of whether it was sent to the source address 
> on the BU or 
> > to the address in the AltCoA option. It should be perfectly 
> valid for 
> > a HA implementation to send a Binding Ack to the CoA always.
> 
> Besides, according to the following RFC 3775 text, the 
> destination address of BA "MUST be" copied from the source 
> address of BU. The text is clear.
> 
> > BTW, I am planning to submit a draft on the Data Plane Address 
> > mobility option, for separation of control and data plane, 
> before the 
> > draft submission deadline. Let me know if you are 
> interested in contributing.
> 
> I still think use of Alt-CoA already accomplishes that and no 
> additional spec is needed. Thank you nevertheless.
> 
> Alper
> 
> 
> 
> 
> 
>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 21 Oct 2008 00:54:16 +0200

there was a typo in my previous mail: 

[..] that the alt-CoA must be saved in the BCE

should have been

[..] that the source IP of the BU must be saved in the BCE.

domagoj

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Premec, Domagoj
> Sent: 21. listopad 2008 00:44
> To: Brian Haley
> Subject: Re: [MEXT] [netlmm] Alt-CoA and PMIP6 (was 
> RE:FW:comment ondraft-ietf-mext-binding-revocation-01)
> 
> Brian,
> 
> Yes, that was my point. The original question in this thread 
> was "where is the Binding revocation sent to if the PBU 
> contained alt-CoA", and one option would be to specify in the 
> Binding revocation draft that the alt-CoA must be saved in the BCE.
> 
> domagoj
> 
> > available during the BU/Back transaction processing and once the 
> > transaction is completed,  the source IP of the BU is gone. 
> IMO if we 
> > want the source IP of the BU to be saved in the BCE, this must be 
> > specified in some RFC.
> > 
> the BAck, 
> > just the CoA, which is usually the source address.
> > But I don't think we need to specify if the address is saved in the 
> > conceptual data structure mentioned in 3775, 
> implementations are free 
> > to store additional information in a BCE if they wish, and 
> most do.  
> > If some new draft needs the original source address saved, then it 
> > should specify it.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 21 Oct 2008 10:09:56 -0700

> The alt-CoA works only in one direction,  MAG->LMA. If the LMA has several
> blades and would like to load balance between them, we need to specify how
> this is done in the other direction, too.

If you want to go into such "advanced" scenarios (multi-CoA, load balancing,
etc.) you would need additional specification, of course. But for single CoA
case, I don't see what you need other than standard Alt-CoA usage.

Alper